Q: How can I get rid of the Network Neighborhood icon? I have a standalone system exclusively for development, and I want people using this machine to realize it is not on the network.
Actually, you can easily eliminate the Network Neighborhood icon. This question involves changing your Registry--remember, always have a backup of your Registry before you edit it. Warning: Using the Registry editor incorrectly can cause serious, systemwide problems. You might have to reinstall NT to correct them. Use this tool at your own risk.
Using regedt32.exe or regedit.exe, go to the following key, as shown in Screen 1:
Go to the Edit menu and add a new value, NoNetHood, of data type REG_BINARY. The default value for NoNetHood is 00 00 00 00. To get rid of the Network Neighborhood icon, set this value to 00 00 00 01. The network icon and network functions disappear when you reboot.
Q: I tried to reinstall TCP/IP by deleting the Tcpip key in the Windows NT Registry, but TCP/IP still won't install and I get the message, "Subkey already exists." What Registry subkeys do I need to delete?
Believe it or not, several Registry keys can cause the message you described. In addition to deleting the Tcpip Registry key, you must also delete any of the subkeys shown in Figure 1, on page 191, that appear on your system.
Q: I just installed Service Pack 2 (SP2) for Windows NT 4.0. Now I get memory exceptions for rpcss.exe, and my system crashes easily with any network-related activity. How can I fix this problem?
Microsoft is now using hotfixes for service packs. Go to Microsoft's FTP site at ftp://ftp.microsoft.com/bussys/
fixes-postsp2/rpc-fix/ to download the RPC hotfix. I have a machine that had this same problem. I ran the RPC hotfix, and I have not had any more problems with the machine. For more information about fixing bugs associated with SP2, see Jonathan Chau, "Service Pack 2," March 1997 and Mark Minasi, "Recovering from a Network Disaster," March 1997. We've also set up a special SP2 Information Center on our Web page at http://www.winntmag.com.
Q: Can you explain the concept of unattended installations and the use of sysdiff.exe? What options do I have to roll out Windows NT 4.0 Workstation on 3000 machines?
You need to realize that technically you can't perform an unattended installation. At best, you can automate your installation. I see why you are interested in unattended installation methods and sysdiff. Unattended installation is impossible because Microsoft wants all users to see and reply to the following agreement and screens:
* The Microsoft End User License Agreement (EULA)
* The Product Identification screen
* The Username and Company screen
Of these three screens, getting the machine to accept the EULA most seriously affects automated installation. You can avoid viewing the EULA online by printing the eula.txt file from the installation directory (e.g., \i386) of the NT 4.0 Server or Workstation CD-ROMs and giving the agreement to your users for approval. I'll show you how to perform an automated installation so that the machine accepts the EULA without user intervention.
To automate your installation, you need a boot disk that can access a network installation share (you can use Network Client Administrator to create this disk, as you see in Screen 2) and an unattend.txt script file. You can create an installation script by editing a sample script or using Setup Manager, which you see in Screen 3, from the Microsoft Windows NT Server Resource Kit CD-ROM. Make sure your script includes answers to all the NT Setup questions; otherwise, NT Setup will ask the user for the information. To perform the automated installation, enter the following syntax:
winnt\[32\] /b /u:<answer file> /s:<install source>
The /b switch eliminates floppy drive use and copies all boot and installation files directly to the local hard disk. You need the optional 32, shown in brackets, only if the installation proceeds from NT and not DOS. I've annotated a sample automated installation script file, as you see in Listing 1 (page 192), to help you understand what's happening during installation.
In the sample script shown in Listing 1, a response negates every possible request for user input. This example presupposes that you're using standard hardware and can use standard drivers from the NT installation CD-ROM.
At a minimum, you need to manually copy the \i386 directory to a distribution server and grant full access to everyone for that share. (You can use the whole CD-ROM drive as a share, but only if it's very fast. For large-scale rollouts, you need to use multiple distribution servers.) If you're using a DOS boot disk, the boot disk setup will load the realtime network drivers and map the distribution drive for local use.
Although the script in Listing 1 is completely functional, it has several major limitations. You can't use this script to do a mass rollout because all machines will have the same name. One solution is to create a small Visual Basic (VB) or similar application to change the computer name in the unattend.txt file and then save the edited unattend.txt file by the computer name (e.g., bob6.txt). If you save all these custom installation scripts in the distribution share, the automated installation will reflect the new filename for each machine.
Because each machine will boot to DOS when you use this installation script, the winnt.exe file will run. In the original example, with the distribution share mapped to Z, the command will be
winnt /b /u:unattended.txt /s:Z
With this approach, you need to prepare automated installation files for each environment you're installing to. For example, if you have various NICs, you need to create an answer file for each type of NIC. This approach emphasizes the necessity of inventorying the machines you're upgrading.
In addition to performing an automated installation of NT, you can install applications over the network using OEM syntax that Microsoft designed to let OEMs preinstall applications. If you select yes to the OemPreinstall option in the unattend.txt file, you can use a setup command or the sysdiff application (I assume Microsoft included this utility by accident) on the NT 4.0 Server and Workstation CD-ROMs to install applications.
Sysdiff is an application that lets you capture an image of a system, change the system, and capture any differences between the original configuration and the new configuration. You can then apply the difference file to other systems. You can use sysdiff in many ways, but let's look at the most direct use.
After you create the basic NT installation, don't make any changes. If you installed the Microsoft Windows NT Server Resource Kit, the installer puts sysdiff in the \system32 directory. At the command line, type
sysdiff /snap \[/log:log_file\] drive:\directory\snapshot_file
where drive is the drive and directory is the directory where you want to store the snapshot file (you typically create a \snap directory on the C drive). The \[/log:log_file\] parameter is optional and creates a log file of the transactions.
If you have more than one hard disk on your system, sysdiff takes a snapshot of all disks. Because the snapshot of everything on the disk must match the disk you apply the differences to, I recommend that you use sysdiff only on single-disk systems.
After sysdiff takes the snapshot of your master system with the basic NT install, as you see in Screen 4, you install the application, such as Office 95, on your master system. After the installation is complete, you run a second command
sysdiff /diff \[/log:log_file\] drive:\directory\snapshot_file drive:\directory\Sysdiff_file /C:"comment"
For this example, sysdiff puts all the snapshot files in the \snap directory. Sysdiff_file is the difference between the two snapshots, and comment is the name given to the sysdiff package, which in this case is Office 95.
Copy the sysdiff_file, sysdiff.exe, and sysdiff.ini to the \$OEM$ directory of the distribution share. Create a file, cmdlines.txt, and add the following line to it:
sysdiff /apply /m sysdiff_file
Apply incorporates the difference file, sysdiff_file, into the new system. The m parameter remaps the file changes to the default user profile so that they appear as Default User files. Move the cmdlines.txt file to the \$OEM$ distribution directory. The end-user setup will incorporate the sysdiff_file into the installation.
Note: CurrentControlSet is abbreviated as CCS in these subkeys.
where NetDriver x is the name of the network adapter
Simple Network Management Protocol
TCP/IP Network Printing Support
FTP Server Service
DHCP Server Service
WINS Server Service