Tricks & Traps: Ask the Doctor

Article from Windows 2000 Magazine

By Sean Daily

SEND US YOUR TIPS AND QUESTIONS.

For answers to more of your Windows 2000 and Windows NT questions, visit our online discussion forums at https://www.win2000mag.com/forums/.

Q: I'm having a problem with my dual-boot Windows NT installation. I recently bought a new system that came with Windows 98 preinstalled on a FAT32 6GB hard disk with a single partition. I used PowerQuest's PartitionMagic to reduce the FAT32 partition to about 4GB and create a 2GB extended partition. I also created a small (approximately 7MB) FAT partition in front of the FAT32 partition to house the BootMagic boot manager. Then, I used PartitionMagic to format the 2GB partition as NTFS. I tried to boot Win98 at this point, and everything was still working. Next, I booted from the NT setup disks, installed to my 2GB NT partition, and rebooted. At the end of the installation, when I attempted to boot into NT, I got only a blinking cursor. When I boot to a DOS boot disk and run PartitionMagic or Fdisk, the tools recognize the NTFS-formatted partition as a FAT16 partition. NT Setup formats the partition as FAT16, even though I'm telling setup to format the partition as NTFS. The \winnt directory appears to contain the proper contents, but the hard disk won't boot. I'm assuming that NT can boot from an extended partition. Any idea what is going on here?

A: You mention that you used both PartitionMagic and NT Setup to format the volume as NTFS. Setup reformats the disk first as FAT16, because the NTFS format comes from a FAT-to-NTFS conversion that occurs during Setup's second phase. NT basically lies to you when you choose to format a volume as NTFS during setup and sneaks in a FAT-to-NTFS conversion later. You can witness this process if you watch closely during the second phase of setup when it converts the volume to NTFS and reboots the system. (Unlike NT, Windows 2000 first formats partitions as NTFS; therefore, Win2K NTFS partitions don't require conversion.)

Regarding the question of whether NT can boot from an extended partition, the \winnt folder can reside on an extended partition. This partition is called the NT boot partition. However, the system partition (i.e., the partition that x86 systems actually boot from) must always reside on an active primary partition that in turn resides within the first 4GB of the hard disk (i.e., within the disk's first logical 1024 cylinders). For more information about NT Setup partition limits, see the Microsoft articles "Boot Partition Created During Setup Limited to 4 Gigabytes" (https://support.microsoft.com/default.aspx?scid=kb;en-us;119497&sd=tech) and "Windows NT Partitioning Rules During Setup" (https://support.microsoft.com/default.aspx?scid=kb;en-us;138364&sd=tech).

Q: One of my company's domains contains several BDCs that we'd like to move into a different domain. However, we've installed several applications on these BDCs, and we'd prefer not to reinstall the machines. Can we move these machines into the new domain without reinstalling them?

A: Until now, my answer to this popular question has always been the standard Microsoft response: You must reinstall a domain controller server to join it to a different domain. However, I recently found a new utility that might change my answer and provide new hope in situations such as yours. Microsoft doesn't support the following procedure, which entails some risk to your system, so be certain that you have a full system backup before you attempt this procedure.

For some time, Systems Internals has offered a SID-modification utility called NewSID that lets you change computer SIDs on machines that you've used disk-duplication software to clone. The latest version of the tool, NewSID 3.0, includes an interesting twist: the ability to copy to the local machine the SID of a machine residing on the network. Unlike workstations and member servers, all domain controllers within a domain share the same SID (which represents that domain's SID). Because NewSID, which Figure 1 shows, lets you synchronize the local machine's SID with a remote system's SID, you can move a BDC to another domain simply by synchronizing it with any other domain controller in the target domain. Although using this option might present unexpected consequences in some applications, it might be worth trying if you find the prospect of reinstalling the BDC daunting. (You'll need to test each application to verify functionality.) You can download NewSID from Systems Internals' Web site (https://www.sysinternals.com/ntw2k/source/newsid.shtml).

Figure 1: NewSID's new Synchronize SID option

If you're wary about using such a radical tool, consider trying DC Mover from Fastlane Technologies (https://www.fastlane.com/). DC Mover, which is part of Fastlane's DM/Manager, lets you save a domain controller's important system-configuration data (e.g., file and print share configuration information) before migration, then restore the configuration data to the server after you reinstall it to the new domain. Although this utility can save you time and effort, using it to move a domain controller from one domain to another still requires that you reinstall NT and all server applications on the server.

Q: Over the past few years, my company has been using Symantec's Norton Ghost to roll out Windows NT Workstation 4.0 clients. However, we haven't been using the accompanying Ghost Walker utility to change machine SIDs after duplication. This situation presents an obvious security problem—the duplication of machine and user SIDs. How can I identify NT system SIDs on my machines to locate duplicates? I tried using the Microsoft Windows NT Server 4.0 Resource Kit 's getsid.exe utility, but I could obtain reports only on users—not machines. Can you help me with this problem?

A: As you mentioned, getsid.exe identifies user SIDs, not machine SIDs. (Whoami.exe is another resource kit utility that lets you identify user SIDs when you use the utility with the /sid option.) Your question prompted me to search the Internet for a utility that might accomplish your task, but I found none. However, one clunky method to identify a local machine's SID is to inspect the Registry: The computer's SID resides in the HKEY_LOCAL_MACHINE \SECURITY \SAM \Domains \Account Registry subkey. Because you can't see the SECURITY hive's contents by default (even as an administrator), you need to trick NT so that it lets you see the contents. To do so, simply use NT's At command or the resource kit's Soon or WinAt utilities to schedule the startup of a Registry editor session. Make sure that you schedule the task as Interactive and that the Scheduler service runs in the security context of the System (aka LocalSystem) account, because this account—unlike a regular user account—has privileges to view the SAM and SECURITY hives. This subkey contains two values, F and V. Figure 2 shows a sample Registry editor session that displays these values .The V value is a REG_BINARY value in which the computer SID is embedded (at the end of its data). However, because the data is in binary format, it's difficult to read. For this information to be useful, you also need to know the format of a machine SID in NT 4.0: three 32-bit subauthorities, preceded by three 32-bit authority fields. By comparing the V value on different machines, you can identify whether the machines have duplicate SIDs.

Figure 2: Viewing a machine's SID in the Registry

This method of obtaining machine SID information didn't satisfy me, so I asked Windows 2000 Magazine columnist Mark Russinovich if he knew of any relevant utilities. Mark has written one SID-related utility (NewSID, which I discuss in the previous question), so I thought he might know of a SID-examination utility. He couldn't recommend any tools, but based on your question and similar recent requests for this type of utility, Mark decided to write his own version of getsid.exe—one that not only identifies the local machine SID but can also query a remote computer's SID. You can download GetSID from the Systems Internals Web site.

Q: My company is experiencing a recurring problem with laptops that use DHCP. Our employees use modems to connect to the network and dial in to our RAS servers. For some reason, a laptop will suddenly fail to pick up an address from the local DHCP server. Technically adept users can make the laptop release and renew the IP address (e.g., by using the Winipcfg utility), but on restricted laptops, users must log on before they can do anything—which they can't do until they release and renew the IP address. I've applied the Windows 95 Dial-Up Network 1.3 upgrade, but to no avail. Can you recommend a solution for this problem?

A: The problem you describe has at least three possible causes. First, in the Control Panel Network applet's Bindings tab on the RAS server, the Microsoft DHCP Server might be bound to RAS before the binding to the NIC. For proper operation of DHCP and other services (e.g., WINS), always be sure that RAS follows any NICs in a system's bindings order.

Second, your DHCP scope might be saturated, so you have no more addresses to provide to RAS clients. After you manually release addresses on the client, an address becomes available and the client can then obtain the released address. If your DHCP scope is saturated, consider extending your DHCP scope on the affected segments or shortening your DHCP lease lengths.

Finally, a device on your network**—such as a router or a bridge—might be interfering with DHCP's operation. For example, I've seen some routers' DHCP spoofing option wreak havoc with Windows NT DHCP servers. (In one case, this feature caused an NT DHCP server to give out its own address.) Therefore, you need to verify that you haven't enabled a DHCP spoofing option on any such equipment, and that no competing DHCP servers exist on your network. Also, be sure to install Service Pack 5 (SP5) or later—preferably SP6a—**on all your DHCP and RAS servers because these service packs provide better stability for these services than their predecessors do.

Q: My company locally hosts its own DNS, but our ISP recently discovered problems in the configuration of the DNS zone file that supports our domain name. The ISP said we shouldn't use Canonical Names (CNAMEs) for our two DNS servers. In our current setup, we use CNAMEs for two DNS servers—ns1 and ns2. I don't think we've had any name-resolution problems, so the ISP's statements confuse me. Can you shed light on this situation?

A: A Name Server (NS) record in a DNS zone file typically shouldn't point to a CNAME**—**just as a mail exchanger (MX) record shouldn't point to a CNAME. Although using a CNAME entry for an NS record is possible, it's not the best choice. The primary reason you should avoid using CNAME records in the MX, NS, and Source of Authority (SOA) records is performance: Internet hosts make frequent queries to these records, so you want them to require as little time and as few resources as possible to complete. If you reference a CNAME, you generate additional queries, which impedes performance. Instead, consider another strategy.

First, for each DNS server, you can create two address (A) records that point to the same IP address on the server. An A record is the name you used in the SOA and NS records (e.g., ns1.ntsol.com), and the other is the real or descriptive name of the server (e.g., calvin.win2kinfo.com). These different A records associate the IP address with each name you want the host to use. This process is only necessary if you want to give the DNS server more than one name—for example, one name for the name server entries in the NS or SOA records in the zone file (e.g., ns1), and another name (e.g., Calvin) for your LAN clients.

Second, you can simply use one name for each server in the zone file, including references in the A, NS, and SOA records. This solution requires no additional lookups to resolve CNAME records to their backing A records. You could still use CNAME records to create additional aliases for these hosts, as long as you remember to reference only the A record name in the MX, NS, and SOA records. Figure 3 shows an example of this method.

Figure 3: Using only one name for each server in the zone file

Sean Daily is a contributing editor and columnist for Windows 2000 Magazine. He is the technology lead at Xcedia, a consulting firm specializing in Windows 2000 deployment and migrations. His most recent book is Optimizing Windows NT (IDG Books). You can reach him at sean@xcedia.com.

The above article is courtesy of Windows 2000 Magazine. Click here

to subscribe to Windows 2000 Magazine.

We at Microsoft Corporation hope that the information in this work is valuable to you. Your use of the information contained in this work, however, is at your sole risk. All information in this work is provided "as -is", without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by Microsoft Corporation. Microsoft Corporation shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages. All prices for products mentioned in this document are subject to change without notice.

Click to subscribe