\[Editor's Note: Do you have something to share with other readers who visit Windows NT Magazine online? We want to know about it. Write for Reader to Reader online, and you can tell others about your NT discoveries, comments, problems, solutions, and experiences. Email your contributions (300 to 700 words) to [email protected] along with your name and phone number. We edit submissions for style, grammar, and length. If we print your submission, you'll get $100. Reader to Reader submissions are the reader's opinion and do not necessarily represent the views of Windows NT Magazine.\]
I recently went on a quest to find a custom-fit, inexpensive solution to a problem my organization was having with our network. Keep in mind that although this solution worked for my needs, it might present a security risk on your network. Our IT department just doesn't have the resources to continuously update our PCs with all the latest software, so I needed to find a way to simplify installation on our network. I was lucky enough to find an article on Windows NT Magazine's Web site (many thanks to Clayton Johnson) that started me off with a new idea for network installations.
Originally I thought I could let users update their systems when they had the time. Unfortunately, NT typically requires that you have administrative rights to install most software and their relevant updates. Therefore, I decided to create a domain administrative account for installations. The account uses the following logon batch file, which makes the appropriate network shares and Registry edits:
Install.cmd net time /domain /set /y net use S: /delete net use S: \Install\ /PERSISTENT:NO Regedit /s \\server1\netlogon\apps.REG
Install.cmd maps a drive to a share that stores the information about all the files I want to install. This batch file also uses Regedit to import a Registry file. The /s switch silences the successful import dialog, which otherwise accompanies the Registry file import. The Registry file has the following entry:
Apps.reg Registry File to Create Network Install REGEDIT4
I created the Registry file by adding this information to the Registry and using regedit's export function to export the relevant information into a file that I could import with a logon script. I stored the Registry file under the Netlogon directory so that I can import this file with the logon batch file, which is far more efficient than copying the Registry file to the hard disk of each workstation. The apps.reg file sets the Registry to read an apps.inf file that I copied from the server for redundancy reasons to the top of the shared directory that I log on to with the install account.
Apps.inf Section from Apps.inf File
\[appinstalllist\] Sp4=\\server1\install\NT4_hu_sp4\i386\update\sp4.cmd Office97 SR-1=\\server1\install\off97sr1\sr1.cmd Office97 SR-2=\\server1\install\off97sr2\sr2.cmd IE5=\\cdserver\IE5hun\ie5setup.exe
This file originally resides in the winnt\inf folder on the server and holds information about the whereabouts of the installation setup. Notice that I use the Universal Naming Convention (UNC) name and full path. The command files are simple batch files that run with switches to suppress user input (e.g., update.exe -u for Service Pack 4—SP4—unattended installation, sr1off97.exe /q for Office 97 Service Release 1's—SR1's—and SR2's quiet installation). Another matter of interest is that the setup files are on a CD-ROM server, so the command files also contain the paths to this server (e.g., \\cdserver\cd\ie50hun\ie5setup.exe, \\cdserver\cd\off97sr1\sr1off97.exe /q). This way, I don't have to keep several hundred megabytes worth of install files on our server—I simply write a few CD-ROMs with concise setup information.
After I log on with all the above modifications, a new tab appears under Control Panel, Add/Remove Programs called Network Install. Next, I introduced this new tab to several departmental power users by performing a demo install session. This process taught these users how to apply this tab and the linked updates to their PCs. Once these users were comfortable adding the software updates to their PCs, I had them perform the same task on other PCs within their respective departments. We all agreed upon an end date to finish the software setup, and I later disabled the install account because I wasn't comfortable leaving the power users with administrative rights. A relatively simple change to the Registry and some departmental teamwork helped get some long overdue updates to each PC before the Y2K problems start to bite.