Reader to Reader - September 2000

[Editor's Note: Share your Windows 2000 and Windows NT discoveries, comments, problems, solutions, and experiences with products and reach out to other Windows 2000 Magazine readers (including Microsoft). Email your contributions (400 words or less) to [email protected]. Please include your phone number. We edit submissions for style, grammar, and length. If we print your submission, you'll get $100.]

Net Config Server Gotcha
A common practice is to hide a server while you're configuring it, then make it available when it's ready for users to access. This process lets you configure and reboot the machine without worrying about users who might connect to and explore it before you complete the machine's configuration. However, this method has one problem, as the Microsoft article "How to Display Network Registry Parameters" (http://support.microsoft.com/support/kb/articles/q102/4/69.asp) warns: "When you run NET CONFIG SERVER (or NET CONFIG SRV), server related parameters that are normally autoconfigured each time you boot (for example, maxworkitems) are permanently set in the Registry to whatever values Windows NT is currently using."

Thus, if you later add memory or another processor to the server, the system won't automatically configure the new resources. The only way to avoid this problem is to manually add the AutoShareServer subkey with a REG_DWORD value of 1 to the HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesLanmanServerParameters Registry key and stop and restart the Server service. After you complete the server's configuration, delete this Registry key, then stop and restart the Server service. The machine will again be visible to users.

—Peter Stubbs
[email protected]

Creating a New NT Installation
When creating a new Windows NT installation, I always use the following procedure. First, I install NT on a 511MB FAT partition mapped as drive C, then I apply the most recent service pack. Next, I use Disk Administrator to partition the rest of the hard disk as one NTFS partition. I rerun the NT Setup program and install NT to drive D. I set drive D as the default startup option in boot.ini, apply the most recent service pack to this installation, and install my applications to drive D.

This installation approach provides many benefits. First, NT requires the system partition to be within the first 7.8GB of the first partition, which is the partition that includes NT Loader (NTLDR) and boot.ini. My installation method places these files on the 511MB C drive, which I create first, so installing another OS on the system won't move these files beyond the first 7.8GB boundary.

Second, if I ever have problems with the main NT installation on the D drive, I might be able to fix the problem by booting to the C drive. In addition, if I have problems with the installation on the C drive, I can boot from a DOS disk to fix the problem because the C drive is a FAT partition.

Third, the first partition is smaller than 512MB, so the cluster size is only 8KB. This setup reduces wasted space.

Fourth, by partitioning and formatting the main working partition (i.e., the D drive) from within an NT installation (i.e., the C drive), I avoid two common NT installation problems. The maximum size of a FAT partition under NT is 4GB, and to create an NTFS partition, NT actually creates a FAT partition that it later converts to NTFS. So during an NT installation, you can create a maximum NTFS partition of only 4GB. In addition, when NT converts a partition from FAT to NTFS, the conversion fragments the Master File Table (MFT), which slows the system's performance. By creating the working partition from within an existing NT installation, I can create an NTFS partition that is larger than 4GB without being concerned about the conversion process fragmenting the MFT.

After I complete this installation process, I apply new service packs and updated drivers to both NT installations on my system. That way, I have a better chance of repairing one installation by using the alternative installation's files.

—Chris Taylor
[email protected]

Adding a PDC to an Existing Domain
I faced a situation similar to the one that Craig Rhinehart described in Reader to Reader: "Adding a BDC to an Existing Domain" (April 2000). I discovered a solution that is simpler and quicker than Craig's method.

My organization's PDC was dying, and I got the OK to order a new one. The new PDC's vendor was 300 miles away and had no physical access to our network, so I had to figure out how to add the new PDC to the domain without reinstalling everything. The vendor was loading, configuring, and testing Windows NT Server and the accompanying software before shipping the system, so I asked the vendor to load and configure the system as a member server because you can move a member server from one domain to another without reinstalling NT. When the server arrived, I added the system to the domain, then used Algin Technology's U-Promote to change the server's role from member server to BDC. This process was easy and completed in less than 5 minutes. Next, I used NT's promotion option to promote the system to a PDC. This process demoted my current PDC to a BDC, kept the server's SAM intact and current, and transferred what I needed from the old PDC to the new PDC.

—Melissa Wise
[email protected]

Determining NT Servers' Uptime
My clients often request a method for determining the uptime and availability of Windows NT Server systems in their enterprises. Microsoft provides a little-known utility that administrators can use to ascertain NT Server systems' availability statistics. Uptime.exe works best when NT Service Pack 4 (SP4) or later is installed on the server and the user has Administrator privileges. Uptime.exe is available at http://www.microsoft.com/ntserver/nts/downloads/management/uptime/default.asp.

You can use uptime.exe to display the current uptime of a local or remote server. Running uptime.exe with the /s switch provides additional details, including percentage of availability, total downtime, total number of reboots, mean time between reboots, and total number of blue screens. The following data is sample uptime.exe /s output:

Since 1/10/2000:System Availability: 99.9620%Total Uptime: 73d 3h:8m:53sTotal Downtime: 0d 0h:40m:4sTotal Reboots: 10Mean Time Between Reboots: 7.32 daysTotal Bluescreens: 0

Uptime.exe obtains this information from the NT event logs. Therefore, you might need to increase the size of the system's event logs to provide uptime.exe with adequate historical data. The utility is measuring the time that the OS is in typical operation, and its output doesn't reflect when the server is unavailable for reasons such as power or network outages. However, this limitation doesn't overshadow the fact that the utility is free and provides a quick report about NT Server systems' availability.

—Brandon Smith
[email protected]

Enabling Users to Install Software During an Automated Installation
If you want to write to the Registry, Windows NT 4.0 requires Administrator privileges. Thus, a standard user can't run a batch file or an ordinary Microsoft Systems Management Server (SMS) package to install software during an automated installation. To overcome this limitation, I use the Microsoft Windows NT Server 4.0 Resource Kit Su utility.

First, install the Su service on every workstation. Next, to install software that NT requires Administrator privileges to install, run a batch script that executes su.exe with an Administrator account, followed by the required command line (the command line depends on what the script is installing). For example, you run the following batch file to install NT Service Pack 5 (SP5):

SET SU_PASSWORD=adminpasswordSU adminaccount "filepathsp5i386.exe -u -f -o" domainnameSET SU_PASSWORD=

I ran this script from a source folder on the C drive, which permits only Administrator access rights to prevent users from customizing their OS installations.

I used the following script to add a local account to all PCs, then added the account to the LocalAdmin group:

SET SU_PASSWORD=adminpasswordNET USER helpdeskaccount >c:ull || SU adminaccount "net user helpdeskaccount accountpassword /add " domainname -v >c:ullSU adminaccount "NET LOCALGROUP administrators helpdeskaccount /add" domainname -v >c:ullSET SU_PASSWORD=

However, having an Administrator password in a text file creates a potential security hazard. To secure the password, I put the batch script in a folder that has only execute privileges to prevent users from viewing the password. In addition, I use SMS Installer to compile an executable, a one-line batch file that calls the main script file, so that users can't see where I stored the batch file or what it's called. I send the executable to all users through an SMS package (preceded by an email message that warns users to run the executable only after they close all applications).

—Thomas Hazlett