Ask Dr. Bob Your NT Questions - 01 May 1997

Send us your tips and questions. You can also visit Bob Chronister's online Tricks & Traps at http://www.winntmag.com/forums/index.html.

Q:How can I get rid of the Network Neighborhood icon? I have a standalone system exclusively for development, andI 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 yourRegistry--remember, always have a backup of your Registry before you edit it. Warning: Using the Registry editorincorrectly can cause serious, systemwide problems. You might have to reinstall NT to correct them. Use this toolat your own risk.

Using regedt32.exe or regedit.exe, go to the following key, as shown in Screen 1:

HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionPoliciesExplorer

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 andnetwork 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'tinstall 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 TcpipRegistry 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 mysystem 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/
winnt/winnt-public/fixes/usa/nt40/hot
fixes-postsp2/rpc-fix/ to download the RPC hotfix. I have a machine that hadthis 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 MarkMinasi, "Recovering from a Network Disaster," March 1997. We've also set up a special SP2 Information Centeron 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 toroll 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 automateyour installation. I see why you are interested in unattended installation methods and sysdiff. Unattendedinstallation 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. Youcan avoid viewing the EULA online by printing the eula.txt file from the installation directory (e.g., i386) of the NT4.0 Server or Workstation CD-ROMs and giving the agreement to your users for approval. I'll show you how to perform anautomated installation so that the machine accepts the EULA without user intervention.

Automated Installations

To automate your installation, you need a boot disk that can access a network installation share (you can useNetwork Client Administrator to create this disk, as you see in Screen 2) and an unattend.txt script file. You cancreate an installation script by editing a sample script or using Setup Manager, which you see in Screen 3, from theMicrosoft Windows NT Server Resource Kit CD-ROM. Make sure your script includes answers to all the NT Setupquestions; otherwise, NT Setup will ask the user for the information. To perform the automated installation, enter thefollowing syntax:

winnt[32] /b /u: /s:

The /b switch eliminates floppy drive use and copies all boot and installation files directly to the local harddisk. You need the optional 32, shown in brackets, only if the installation proceeds from NT and not DOS. I've annotateda sample automated installation script file, as you see in Listing 1 (page 192), to help you understand what's happeningduring 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 toeveryone for that share. (You can use the whole CD-ROM drive as a share, but only if it's very fast. For large-scalerollouts, you need to use multiple distribution servers.) If you're using a DOS boot disk, the boot disk setup will loadthe 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 thisscript 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.txtfile 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 theoriginal 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. Forexample, if you have various NICs, you need to create an answer file for each type of NIC. This approach emphasizes thenecessity of inventorying the machines you're upgrading.

Using Sysdiff

In addition to performing an automated installation of NT, you can install applications over the network using OEMsyntax that Microsoft designed to let OEMs preinstall applications. If you select yes to the OemPreinstalloption in the unattend.txt file, you can use a setup command or the sysdiff application (I assume Microsoft includedthis 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 differencesbetween 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 NTServer Resource Kit, the installer puts sysdiff in the system32 directory. At the command line, type

sysdiff /snap [/log:log_file] drive:directorysnapshot_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 logfile of the transactions.

If you have more than one hard disk on your system, sysdiff takes a snapshot of all disks. Because the snapshot ofeverything on the disk must match the disk you apply the differences to, I recommend that you use sysdiff only onsingle-disk systems.

After sysdiff takes the snapshot of your master system with the basic NT install, as you see in Screen 4, youinstall the application, such as Office 95, on your master system. After the installation is complete, you run a secondcommand

sysdiff /diff [/log:log_file] drive:directorysnapshot_file drive:directorySysdiff_file /C:"comment"

For this example, sysdiff puts all the snapshot files in the snap directory. Sysdiff_file is the differencebetween the two snapshots, and comment is the name given to the sysdiff package, which in this case is Office95.

Copy the sysdiff_file, sysdiff.exe, and sysdiff.ini to the $OEM$ directory of the distribution share. Create afile, 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 remapsthe file changes to the default user profile so that they appear as Default User files. Move the cmdlines.txt file tothe $OEM$ distribution directory. The end-user setup will incorporate the sysdiff_file into the installation.

Note: CurrentControlSet is abbreviated as CCS in these subkeys.
Default Subkeys

Connectivity Utilities

HKEY_LOCAL_MACHINESOFTWAREMicrosoftNetBT
HKEY_LOCAL_MACHINESOFTWAREMicrosoftTcpip
HKEY_LOCAL_MACHINESOFTWAREMicrosoftTcpipCU
HKEY_LOCAL_MACHINESYSTEMCCSServicesDHCP
HKEY_LOCAL_MACHINESYSTEMCCSServicesLmHosts
HKEY_LOCAL_MACHINESYSTEMCCSServicesNetDriver xParametersTcpip

HKEY_LOCAL_MACHINESYSTEMCCSServicesNetBT
HKEY_LOCAL_MACHINESYSTEMCCSServicesTcpip

Optional Subkeys
Simple Network Management Protocol

HKEY_LOCAL_MACHINESOFTWAREMicrosoftRFC1156Agent
HKEY_LOCAL_MACHINESOFTWAREMicrosoftSNMP
HKEY_LOCAL_MACHINESYSTEMCCSServicesSNMP

TCP/IP Network Printing Support

HKEY_LOCAL_MACHINESOFTWAREMicrosoftLPDSVC
HKEY_LOCAL_MACHINESOFTWAREMicrosoftSNMP
HKEY_LOCAL_MACHINESYSTEMCCSServicesSNMP

FTP Server Service

HKEY_LOCAL_MACHINESOFTWAREMicrosoftFTPSVC
HKEY_LOCAL_MACHINESYSTEMCCSServicesFTPSVC
HKEY_LOCAL_MACHINESOFTWAREMicrosoftSimpTcp
HKEY_LOCAL_MACHINESYSTEMCCSServicesSimpTcp

DHCP Server Service

HKEY_LOCAL_MACHINESOFTWAREMicrosoftDhcpMibAgent
HKEY_LOCAL_MACHINESOFTWAREMicrosoftDhcpServer
HKEY_LOCAL_MACHINESYSTEMCCSServicesDhcpServer

WINS Server Service

HKEY_LOCAL_MACHINESOFTWAREMicrosoftWins
HKEY_LOCAL_MACHINESOFTWAREMicrosoftWinsMibAgent
HKEY_LOCAL_MACHINESYSTEMCCSServicesWins