Why are we looking to use SCCM when there is an additional per-machine cost? Well, we see several advantages that we need in order to be able to continue to expand out Computer Management project:

• No MSIs required – SCCM will hopefully allow us to deploy software without needing an expensive packaging application such as WISE. Not to mention, there are a lot of applications that work very poorly when packaged with MSIs, such as Office 2007 and Adobe Creative Suite). Furthermore, there are some MSI packages that conflict with others and can inevitably make a machine build fail.
• Better software deployment management – Hopefully, SCCM will allow us to be more granular when it comes to choosing which computers get what software.
• Machine Inventory/Queries – Currently, we use applications developed in-house to perform WMI queries against machines for Inventory purposes. Inventory is stored in a SQL database and queries can be performed using a web page. Quite frankly, this is code we would rather not maintain in the future. The SCCM Configmgr interface should allow us to inventory machines while also to grant access to are partners to that they can query their machines. In other words, we no longer have to reinvent the wheel. Inventory should also be more reliable.
• Offsite deployment – Currently, any machines in CLM must be connected to the Penn State network in order to be managed and receive software. This makes managing offsite devices, such as laptops, impossible. SCCM has functionality that could allow us to manage and deploy software to offsite systems through HTTPS.
• Streamlined Operating System Deployments – Thanks to the Operating System Deployment (OSD) portion of SCCM, we will hopefully be able to rapidly create, configure, and deploy Windows to machines using a variety of distribution mechanisms including PXE, USB Drives, and DVD Media. We hope to incorporate all of the features of our current imaging process into this. SCCM OSD also uses ImageX to create images similar in the way that Symantec Ghost does. This should eliminate our dependency on Ghost licensing.

We’re still investigating SCCM and there are several experiments under way. One thing that I have found is SCCM does not support OS deployments via a restore partition on the physical disk. This is a requirement for us because we have a lab environmment where an entire lab of 50+ machines may need rebuilt over. Pushing out the OS over the network could eat up a lot more bandwidth than is necessary. We will have to find a way to work around this, which probably means throwing out the native SCCM boot shell (TSBootShell.exe) and writing a simple one that meets our needs.

WSUS has a lot of great features that System Administrators can take advantage of. More information on it is available at this address: http://technet.microsoft.com/en-us/wsus/default.aspx

One of the interesting outcomes of the SACITS meetings was that ITS has already looked at providing this service to users. In fact, the service is already being offered: http://aset.its.psu.edu/docs/windows/windows_sus . So why isn’t it advertised to students? The answer at the meeting seemed to be that there wasn’t a easy, foolproof way for students to configure their machine to use the Penn State WSUS server. Additionally, there wasn’t an easy way to set the update configuration such that when students took their machines off the Penn State network, the configuration would automatically revert back to Microsoft’s servers. I disagree.

In fact, I’m pretty sure that all of this can be configured easily using a few registry tweaks and a batch file, maybe two.

IMPORTANT: I haven’t confirmed that all of this works flawlessly yet, mainly because I don’t live in a residence hall. If you try it and run in to problems, please post them in the comments. This will only work in Windows XP/Vista

DISCLAIMER: How to Break Your Computer
It’s no secret that improperly making changes to the system registry can really mess things up on your computer. While making registry changes is normally straightforward, it isn’t foolproof. However, a small application or batch file can be written that helps automate the registry changes that need to be done to configure WSUS. An example is below. If you decide to make any changes manually, please do so at your own risk.

Also, if you decide to use any text or files from this article, please do so at your own risk. I take no responsibility for any problems you encounter with this information. By using the batch files on this page, you agree that I hold no responsibility for unintentional damage caused. You also agree that I am not obligated to provide technical support regarding this article or any files included in it. Sorry, had to get that out there.

We Don’t Need No GPO
For system administrators that manage computers through an Active Directory environment, configuring clients to use a WSUS server involves creating a fairly simple Group Policy Object (GPO). However, users in the residence halls aren’t joined to a domain, for better or worse. Fortunately, machines can still be manually configured to use a WSUS server by modifying the registry: http://technet2.microsoft.com/windowsserver/en/library/75ee9da8-0ffd-400c-b722-aeafdb68ceb31033.mspx?mfr=true. Once the needed registry settings are applied, the Automatic updates service needs to be restarted.

The Building Blocks
For this task, writing a small batch file is quicker (but also dirtier) than writing an actual program.  We can use commands that are readily available in DOS to make changes to the registry. The REG ADD command makes adding/updating registry entries easily scriptable.

NET STOP wuauserv

REG ADD HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate /v ElevateNonAdmins /t REG_DWORD /d 0 /f

REG ADD HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate /v TargetGroupEnabled /t REG_DWORD /d 0 /f

REG ADD HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate /v WUServer /t REG_SZ /d http://windowsupdate.aset.psu.edu /f

REG ADD HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate /v WUStatusServer /t REG_SZ /d http://windowsupdate.aset.psu.edu /f

REG ADD HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate\AU /v UseWUServer /t REG_DWORD /d 1 /f

NET START wuauserv

The last REG ADD command adds (or updates) the UseWUServer value. When this value is set to 1, the Automatic Updates service should use WSUS servers (if they have been specified). When set to 0, Microsoft Windows Update servers should be used. Finally, for the configuration to take effect, the Automatic Updates service (wuauserv) needs to be restarted using the NET STOP and NET START commands as shown above. The above code would be great if we wanted to always use the Penn State WSUS server. However, we want to use microsoft’s servers when we aren’t on campus. Also, Penn State may decide to block internet traffic from using the WSUS server in the future. This could potentially lead to a lot of missed updates. Alright, this will makes it a bit more complicated.

A Bit More Thorough
The above commands are probably the easiest way to do a one-time configuration of WSUS. However, if we want a “set it and forget it” approach that uses Windows Update when off-campus, things need to be a bit more advanced. The plan: write a batch file will “install” a scheduled task that checks to see if we’re in or out of the Penn State network. This one batch file should take care of installation and configuration:
Note: to use the code below, copy it and then paste it into blank notepad file. Save the file with a .BAT extension (ex: PSUWSUS.BAT). Then, browse to the file and double click it.

@ECHO OFF

ECHO WSUS Config Check Installer
ECHO Creating batch file in C:\WSUSCHECK.BAT
ECHO ping udrive.win.psu.edu > C:\WSUSCHECK.BAT
ECHO IF %%ERRORLEVEL%% NEQ 0 GOTO OFFCAMPUS >> C:\WSUSCHECK.BAT
ECHO IF %%ERRORLEVEL%% EQU 0 GOTO ONCAMPUS >> C:\WSUSCHECK.BAT
ECHO. >> C:\WSUSCHECK.BAT
ECHO :OFFCAMPUS >> C:\WSUSCHECK.BAT
ECHO NET STOP wuauserv >> C:\WSUSCHECK.BAT
ECHO REG ADD HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate\AU /v UseWUServer /t REG_DWORD /d 0 /f >> C:\WSUSCHECK.BAT
ECHO NET START wuauserv >> C:\WSUSCHECK.BAT
ECHO GOTO END >> C:\WSUSCHECK.BAT
ECHO. >> C:\WSUSCHECK.BAT
ECHO :ONCAMPUS >> C:\WSUSCHECK.BAT
ECHO NET STOP wuauserv >> C:\WSUSCHECK.BAT
ECHO REG ADD HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate\AU /v UseWUServer /t REG_DWORD /d 1 /f >> C:\WSUSCHECK.BAT
ECHO NET START wuauserv >> C:\WSUSCHECK.BAT
ECHO GOTO END >> C:\WSUSCHECK.BAT

ECHO :END >> C:\WSUSCHECK.BAT

ECHO Creating a Scheduled Task…
schtasks /create /tn WSUSCheck /tr c:\WSUSCHECK.BAT /sc hourly /mo 8 /ru SYSTEM

ECHO Applying WSUS Settings…

NET STOP wuauserv

REG ADD HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate /v ElevateNonAdmins /t REG_DWORD /d 0 /f

REG ADD HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate /v TargetGroupEnabled /t REG_DWORD /d 0 /f

REG ADD HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate /v WUServer /t REG_SZ /d http://windowsupdate.aset.psu.edu /f

REG ADD HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate /v WUStatusServer /t REG_SZ /d http://windowsupdate.aset.psu.edu /f

REG ADD HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate\AU /v UseWUServer /t REG_DWORD /d 1 /f

NET START wuauserv

ECHO Installation Complete. Please look through the script for errors and report them if necessary.
pause

To summarize, this script outputs text to C:\WSUSCHECK.BAT. This text, when executed, is what actually checks to see if the machine is on campus or off campus. The check is done by pinging udrive.win.psu.edu. This is a server uses a private, non-routable IP address that should only respond to ping when the machine is connected to the Penn State network. The script adds the Penn State WSUS server to the registry and creates scheduled task that runs C:\WSUSCHECK.BAT every 8 hours.

A Few Notes
There is one caveat to this batch file: If for some reason the ‘udrive.win.psu.edu’ stops responding to ping requests, the batch file will always think that it is off the Penn State network. This is not the perfect solution but instead a working example of how one might approach the problem. If you have a better method, please post it in the comments. Ping was just the first thing to come to mind.

Another thing I don’t like about this batch file is that it restarts the Automatic Update service every 8 hours regardless of whether or not settings are modified. I debated trying to make the batch file smarter by checking if the UseWUServer is actually being set to a different value and then restarting the service if it is. However, I couldn’t find any reason why restarting the Automatic Update service periodically would be a bad thing. Feel free to convince me otherwise in case I missed something.

What is WebAccess?

(via https://webaccess.psu.edu/help.html)
“The WebAccess system, which uses the University of Michigan’s Cosign technology (a development effort that is funded by the National Science Foundation’s National Middleware Initiative-Enterprise and Desktop Technologies program), provides an environment in which users authenticate/login once with their respective Access Account userids and password to a central server in order to access multiple services protected with WebAccess without needing to re-authenticate. For example, a user can authenticate via Penn State WebAccess and then access services such as the Penn State Portal, Penn State WebMail, and a variety of other WebAccess-enabled, without needing to authenticate again to those services.”

In a Nutshell:

WebAccess allows those with Penn State Access Accounts (or Friends of Penn State accounts) to use the same username and password for multiple websites. This document will help explain how you can incorporate WebAccess into your websites to help protect content that you want or need to limit access to.

Reasons for using WebAccess

If you need a way to protect content on your club website you should consider using Penn State WebAccess for some of the following reasons:
• Secure – WebAccess is a secure way for your users to authenticate and access content on your club site. Additionally, passwords are sent over the internet in encrypted form using Secure Sockets Layer (SSL).
• Liability – Storing user credentials could potentially make you liable if your club website were compromised. With WebAccess, user credentials are never stored in your club web space and no one (including yourself) has access to those credentials.
• Easy – Using WebAccess for authentication is usually much easier than trying to implement a secure login program for you club website on your own.
• Improved User Experience – WebAccess is part of Penn State’s Single Sign-on Solution (SSO) which means users don’t need to register or log in with a different username and password before they gain access to protected content. As long as the user has a Penn State (or Friends of Penn State) access account they will be able to log in.

Reasons for NOT using WebAccess

Of course, WebAccess shouldn’t be used for everything. Here are some examples:
• Public Information – If there is information on your club website that you want the general public to see, you may not want to use WebAccess since guests as well as search engines will not be able to access it. However, if there is certain information on your site that you would like to restrict access to, you may want to try keeping it in a separate folder that you can apply WebAccess authentication to. Deciding what should be public and private content is an important consideration when designing your club site.
• Integration – Integrating WebAccess into an existing web script (such as a discussion forum) can sometimes be difficult and may require programming knowledge. If you’re looking to replace an application’s preexisting registration/login mechanism, prepare to dive into some code. However, if you just need to restrict access to a specific folder on your website, WebAccess is still the way to go and relatively easy.

Requirements

Currently, the only way to enable WebAccess is through php.scripts.psu.edu. Therefore, you must forward all traffic to this server. If you’re already writing your site in PHP, you can skip this step since files ending in ‘.php’ are automatically redirected to the php.scripts server.

Installation Steps

1. Put all of the content you want to protect in a subfolder on your website.
2. Send an e-mail to dbadmin@aset.psu.edu with the url to the folder that you want webaccess enabled on.
3. You’ll receive a reply with the new URL to that folder. You’ll probably also be given the option to either continue to allow access to the folder from the old URL (unauthenticated) or disable that access. In most cases, you want to disable this access otherwise it sort of defeats the purpose.

Limiting Access to Certain Penn State Users

In many cases, you may want to grant access to private content to only a few Penn State users. This can be done quickly and easily using .htaccess. In the folder that’s protected by WebAccess, create a new file named .htaccess. Open .htaccess and paste the following:

AuthType Cosign
require user abc000 def548 ghi984

Replace the fake usernames in the second line with the names of the users that you want to grant access. You may add as many users as needed to that line.