Automate Conference-Room PC Maintenance

Based on readers' responses, one of the most popular scripting articles I've written is "Automate the Maintenance and Monitoring of Shared PCs," November 2001, InstantDoc ID 22710. In that article, I discuss how to clean up shared PCs, such as those used in conference rooms. Today, administrators have to deal with several new technologies (e.g., Active Directory—AD) and new problems (e.g., new security threats), so I want to give you some updated ideas on how to handle this special category of hard-working PCs.

Depending on the size of your organization, you might have many or just a few conference-room PCs. You might have PCs that are committed to specific conference rooms, or you might have a pool of laptops that users check out for presentations they conduct inside and outside the company building. Whether they're conference-room PCs or laptops, these presentation PCs introduce special challenges. If their hard disks are full or they have other problems that prevent proper operation, a high-visibility failure can result. As far as user impact and lost work hours, a presentation PC failure can negate the productivity of a room full of the company's highest-paid employees. As far as the impact on administrators, one of the most stressful jobs is trying to solve an emergency PC problem while meeting participants look over your shoulder. At some companies, the negative impact of a presentation PC failure is probably second only to a server failure. Thus, administrators need to regularly maintain presentation PCs through a scripted solution.

One of the client sites where I worked had a large presentation environment with more than 100 conference rooms, many of which had dedicated PCs connected to data projectors. It wasn't unusual to have the conference rooms utilized the entire workday, making it difficult to manually perform any maintenance.

Before I started scripting a solution, I analyzed the Help desk calls and even went out on a few calls to get a better assessment of the problems presenters were facing. I quickly discovered that the presenters were frustrated with the poor performance and reliability of the presentation PCs. Many of the presenters printed out and brought along overhead transparencies as a backup because they didn't trust the PCs. After analyzing the situation, I identified several key reasons why the presentation PCs performed so poorly:

During this time, I also discovered that the presenters were frustrated because they often couldn't locate the server resources they needed for their presentations. The desktop environment looked unfamiliar to them and the mapped drives they expected to see were "missing."

Obsolete User Profiles and Presentations
Presentation PCs often contain numerous user profiles as well as graphic-intensive presentations that users have copied to the PCs' hard disk. When I wrote "Automate the Maintenance and Monitoring of Shared PCs" in 2001, the hard disks were smaller, so the disks filled up quickly. Although today's larger disks have made this less of a problem, there are some new security-related reasons why you should reduce the number of user profiles and presentations stored locally.

Most presenters realize that running a 30MB to 100MB Microsoft PowerPoint presentation over the network can be risky if the network is slow or there's a network outage. So, they often log on to a conference-room PC with a roaming profile, then copy their presentations to the PC's desktop. I have observed conference-room PCs with as many as 100 user profiles and numerous PowerPoint files that presenters neglected to delete after they gave their presentations—and some of these files contained proprietary corporate data.

One of these PCs would yield a gold mine of confidential information if its hard disk were hacked and the contents fell into the wrong hands. The risk is even greater if the presentation PC is a laptop that's part of a pool. Such laptops are frequently taken outside the company's walls, where less physical security exists.

Because of such security concerns, the first part of a presentation-PC maintenance solution is to regularly clean out obsolete user profiles so that there are a minimal number of them. By deleting the user profiles, you also delete those users' presentation files. Thus, deleting obsolete user profiles not only reduces security risks but also frees up disk space.

You can't automatically delete every user profile because some presenters might have recently uploaded files to a PC for an upcoming presentation. Thus, you need to develop a solution that only deletes those profiles that exceed a specified threshold. In the original article, I used the Microsoft Windows NT Server 4.0 Resource Kit's profile deletion utility, Delprof, for this reason. The Microsoft Windows 2000 Server Resource Kit version of Delprof is still the best tool for the job; you can use it to delete both Win2K and NT user profiles.

To view Delprof's basic command syntax, run the command

Delprof /?

Make sure that you include the /? switch. If you start Delprof without this switch, it asks whether you want to begin deleting inactive profiles on your local machine.

Delprof supports remote profile deletions, so you can run it against local or remote PCs. Here's the basic command for running the Delprof utility against a list of remote PCs:

For /F "tokens=*" %%i in  (C:PClist.txt) Do  Delprof /Q /I /C:\%%i /D:30

(Although this command appears on several lines here, you would enter it on one line in the command-shell window. The same holds true for the other multiline commands in this article.) In this command, the /Q switch runs the tool in quiet mode, which means that the utility won't prompt you for confirmation before deleting each profile. The /I switch tells Delprof to ignore any errors and continue deleting profiles. The /D:30 switch tells Delprof to delete profiles that have been inactive for 30 days or longer. The /C switch specifies the name of the remote computer on which to run the tool. In this case, the For command is being used to read in the computer names from the C:PClist.txt file.

The use of the For command to read in names works well in NT 4.0 systems because the PCs typically reside in only a few domains. Alternatively, you can run the code locally on the presentation PCs as a scheduled task. However, you need to regularly update the list of PCs or the scheduled task when presentation PCs are introduced or redeployed.

If you're running Windows Server 2003 or Win2K, I recommend that you use AD to separate your presentation PCs. You probably already set up server and workstation organizational units (OUs). I suggest that you create a separate OU for the presentation PCs and put that OU under your workstation OU. This structure lets you manage the presentation PCs separately and easily because you can make changes either by applying Group Policy Objects (GPOs) or by using DsQuery to identify the PCs so that you can apply changes to them. For example, the ProfileCleaner.bat script, which Listing 1 shows, is a GPO computer-startup script that you run locally to make changes. The ProfileCleanerRemote.bat script, which Listing 2 shows, uses DsQuery to identify all the presentation PCs in the OU named ConfRoomPCsWorkstationsMyCompany.com. Windows XP introduced DsQuery, a command-line tool that queries AD. You can also use this tool in Windows 2003 and Win2K systems.

ProfileCleaner.bat and ProfileCleanerRemote.bat bring to light two important items to remember when you're writing scripts:

Undeleted Temporary Files
Like other PCs, presentation PCs can have problems with errant applications writing temporary files that aren't cleaned up when the application closes. Documents, images, and other recoverable files might end up in the Temp folder, exposing proprietary corporate data. Consequently, a regular cleanup of the Temp folder is a good practice to follow. However, there is a complication: The Temp folder is inside the C:Documents and SettingsLocal Settings folder, so you need to access each user profile's Temp folder.

Because each presentation PC will have different user profiles, you need to run the Dir command against each presentation PC's Documents and Settings folder to get the usernames. With these names, you can construct the folder name for each profile, then delete the files in its Temp folder.

The Documents and Settings folder contains some hidden folders (i.e., LocalService, NetworkService, and Default User) and the All Users folder, which doesn't contain a Temp folder. So, the command sequence to empty the Temp folders needs to take that into account. You can use the Dir command's /A switch with the D and -H attributes to specify that you want a list of nonhidden folders and the Find command's -V switch with the "All Users" string to eliminate the All Users folder from the list. Thus, the command sequence is

For /F %%i in ('Dir /AD-H /B  "C:DOCUME~1"^| Find /I  /V "All Users"') Do Echo  "C:DOCUME~1%%i  LOCALS~1TEMP*.*"

Note that this sequence uses 8.3-formatted folder names to make it more readable. Also note that it uses the Echo command instead of the Del command. When you initially write code that deletes items, it's a good idea to use Echo rather than Del so that when you test the code, you can see how it works without any unintended deletions.

Another way to empty the Temp folders is to use the following For command:

For /D %%i in ("C:DOCUME~1*")Do If /I Not "%%i"=="All Users"  Echo "%%iLOCALS~1TEMP*.*"

When you use the For command's /D switch with a file set that contains a wildcard, the For command iterates through folders rather than files. By default, only nonhidden folders are included. Thus, the first line in the For /D command performs the same function as the Dir /AD-H command. The second line performs the same function as the Find command's -V switch with the "All Users" string. For more information about this usage of For /D, see the For command's online Help file.

You can use the For /D command to delete the Temp folder's contents in all the profiles while a user is logged on. However, you might encounter in-use temporary files. Generally, an in-use file is going to be locked and can't be deleted, so the user won't be affected. It will, though, produce an error message that the deletion wasn't possible. If you want to avoid such error messages, you can use the Forfiles tool, which you can find in any Windows resource kit. Forfiles lets you perform date-based deletions. For example, TempFolderCleanup.bat, which Listing 3, shows, uses Forfiles to target only those files that are at least 2 days old. (For more information about Forfiles, see Rem "Use Forfiles to Delete Old Files," page 9.) After TempFolderCleanup.bat deletes the files, it removes any leftover folders.

You can modify TempFolderCleanup.bat to clean up the Temporary Internet Files folder if this folder resides outside the Temp folder on your presentation PCs. In both the file-deletion and folder-deletion code, replace the LOCALS~1TEMP path with the appropriate path on your PCs. Forfiles has some challenges being run remotely, so you shouldn't adapt this script to run remotely.

Out-of-Date PCs
Because presentation PCs typically aren't assigned to one user and aren't accessible during normal business hours, they're often missing service packs, hotfixes, or standard installed software. Sometimes they even have vital services shut down or they need a hardware upgrade. To make sure that your presentation PCs are up-to-date, you need to regularly capture PC information. I have two favorite tools that I use: Sysinternals' PsInfo freeware (http://www.sysinternals.com/ntw2k/freeware/psinfo.shtml) and the Microsoft Windows 2000 Server Resource Kit's srvinfo.exe. Both tools support local and remote usage, but the types of information they provide differs.

By default, PsInfo provides system information. You can also retrieve information about the disk volume, hotfixes, and installed software by using the -d, -h, and -s switches, respectively. PsInfo supports input files and provides .txt and .csv output files. Figure 1 shows sample output from running PsInfo with the -h switch. However, I shortened the hotfix list for space reasons.

Srvinfo gives a slightly different picture of PC resources and hotfixes. And, unlike PsInfo, Srvinfo provides service information. However, Srvinfo doesn't support input files or provide .cvs output files. Figure 2 shows sample output from Srvinfo. I suppressed the service information by using the -ns switch and shortened the hotfix and protocol lists for space reasons.

The scripts ReportBuilder.bat (a GPO computer-startup script) and ReportBuilderRemote.bat (a version of ReportBuilder.bat for remote PCs) run PsInfo, Srvinfo, or both, then write the results to a .txt file. You can download these scripts as well as the other scripts I mention in the article from the Windows Scripting Solutions Web site. Go to http://www.windowsitpro.com/windowsscripting, enter InstantDoc ID 44889 in the InstantDoc ID text box, then click the 44889.zip hotlink. All the scripts were tested on PCs running Win2K Professional Service Pack 4 (SP4) and XP SP1.

Solving the Mystery of the "Missing" Mapped Drives
By using scripts to delete obsolete user profiles, clean out the temp folder, and gather PC information, I was able to improve the performance and reliability of the presentation PCs at the client site. Eventually, the presenters had enough confidence to bring only the electronic version of their presentations to meetings.

After the presentation PC environment was stabilized, one of the most common remaining Help desk calls was about not being able to find presentation files on the server. After a little investigation, I realized that presenters were manually mapping drives on their desktop PCs, checking the Reconnect at Logon box, then forgetting the Universal Naming Convention (UNC) path that the mapped drive pointed to. When they sat down at a presentation PC, they expected to see their mapped drive. If they didn't see it, panic set in because they had no clue about the name of the server or share on which their files were located. I realized that I needed to transition users off of mapped drives and into using UNC path—based shortcuts.

First, I identified the commonly used shared-folder resources on the servers. On one of those servers, I created a folder and added shortcuts to all the key shares. I then wrote a simple script that created a desktop shortcut to the shortcuts folder. Originally, under NT 4.0, the shortcut creation script was circulated to the user community. Now, a GPO computer-startup script named MkDesktopShortcut.bat is used to create a desktop shortcut on every user's PC and every presentation PC. MkDesktopShortcut.bat ensures users are presented with a consistent access interface, even when they sit down at an unfamiliar presentation PC. Another benefit is that administrators can easily modify or add shortcuts. They simply change the shortcut in the shortcut folder on the server; they don't need to touch the users' desktops.

You can find MkDesktopShortcut.bat as well as a version of the script for remote PCs (MkDesktopShortcutRemote.bat) in the article's 44889.zip file. These two scripts use the shortcut.exe tool, which you can find in Microsoft Windows NT Server 4.0 Resource Kit, Supplement One or the Microsoft Windows 95 Resource Kit.

Protect Your Assets
Presentation PCs are important computing assets. I've given you seven scripts and some scripting techniques that you can use to keep these crucial PCs running smoothly and securely.