Ask Dr. Bob Your NT Questions - 01 Sep 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: Can you summarize the steps for using Windows NT's Directory Replicator service and tell me how to troubleshoot this service?

Creating the Directory Replicator service does not have to be difficult. Keeping it working properly, however, can be frustrating.

To install NT's Directory Replicator service, you need to have an export server and one or more import servers.

1. On the export server, open User Manager for Domains in the Administrative Tools. At the Primary Domain Controller (PDC), create a new user that is a default member of the Domain Users group. I named this user REPL. Be sure you clear the "User must change password at next logon" checkbox.

2. Open Control Panel and run the Services applet. Choose Startup for the Directory Replicator service, and change the Startup Type from Manual to Automatic. In the Log On As control, choose This Account. Click the browse button on the right side of the window, and locate the new user account you added in step 1. Double-click the account name, add the appropriate password, and click OK. The system will display the message that NT has granted the domain user the right to Log On As Service and added this user account to the Replicator local group, as you see in Screen 1. (NT also adds the user account to the local Backup Operators group.) Click OK on the message box.

3. Open Server Manager in the Administrative Tools, and double-click the name of the server on your network that you want to export files from. Click the Replication button, and select Export Directories, as you see in Screen 2. The \winnt\system32\repl\export directory is the default export directory. Click the Add button, and add the names of the machines (either workstations or servers) that you want to export files to. Choose Manage to conFigure specific directories for export. By default, NT replicates (exports) the scripts directory. In addition, I usually click the entire subtree setting.

4. Choose OK to exit the dialog box. A message will appear that tells you NT is attempting to start the Directory Replicator service. If it does not start, check the application log in Event Viewer for application or network errors related to this service.

5. The final step is to log on to the import computers and repeat step 3 for the import directories. Open Server Manager, and click the Replication button. Choose Add, and specify the name of the export server.

Close the dialog box after you specify the export server and conFigure the import path. Replication will begin within several minutes. Screen 3 shows files successfully replicated to an import client from an export server.

I always give the replication user explicit full control permissions to the import directories on the import systems and the export directories on the export system.

What if replication does not work? Check the following settings:

• Does the application log in Event Viewer show any messages for the Directory Replicator service? I have seen both application and network errors. Try to determine the cause of the message (most messages are numbers; go to a command prompt and type

  Net Helpmsg "msg#"

  to get an explanation of the problem). Check the application logs on the import and export systems.
  If you are importing files to multiple systems, check whether all the machines exhibit the same problems. If not, you know the problem is system specific and probably relates to a permission or setup issue.

• What time zones are the import and export computers running in? Replication is time dependent, so time delays could affect the replication of your files. In local domains, always synchronize the time between the export and import computers.

• Does the import computer have Backup Operator privileges. At a minimum, the \import directory and \import\scripts directory must have change permissions. The Backup Operators group must also have permission to back up and restore files and directories. If these permissions are not set, you will see errors 5, 1300, and 1307 in the application log in Event Viewer.

• Are the import and export computers in different domains? If so, make sure the password and username are the same in both domains, and that the domains trust each other.

• Make sure the files or directories you are replicating don't have any extended attributes (e.g., special access). These extended attributes can cause replication problems.

• If either the export directory or the import directories are on an NTFS partition, use NT Explorer or File Manager to look at the access control lists (ACLs) on the import and export trees. Make sure the Replicator local group has at least change permissions for these directories.

• Check to see whether a user account has a file always open on either the import or export computer. If so, you will see a file open error (error 32) as a sharing violation in the Event Log on both of the machines.

• Make sure you can locate a REPL$ share on the export computer (the Directory Replicator service creates this share). The Directory Replication dialog box also sets an ACL for the REPL$ share. Using the Net command or other means to create the REPL$ share will probably cause problems.

• Run the Net Start command on the export and import computers, and make sure both computers list the Directory Replicator (or equivalent) service.

• If either the import directory or the export directory is on an NTFS partition, do any of the same files in these directories differ only by case? Unfortunately, you can't predict which file NT will replicate in this situation. For example, the export computer may send a file with a lowercase filename, and the import computer may receive a file with an uppercase filename. This situation results in the replication being out of sync.

• If the export computer is running OS/2 or UNIX and the import computer is running NT, is the export computer's local time within half an hour of the import computer's time? If not, the NT network redirector will produce time conflicts and cause the system to try to copy everything again and again. In this situation, replication may never occur.

• Some versions of the OS/2 importer leave the archive bit set for all files imported, regardless of whether the bit was set on the export side. This situation can result in continuous copying. One workaround is to set the archive bit for all files on the export computer (NT to NT replication correctly clones the archive bit).

• Some LAN Manager 2.1a import computers do not set their status file to OK.RP$ (replication is OK). The Directory Replicator service won't recopy files each time the export computer sends files to the import computer, but the service will compare the files. Except for not establishing the correct state of the status file, the service correctly replicates the files. This behavior does not occur on LAN Manager 2.2 importers.

• Some versions of LAN Manager for OS/2 and UNIX allow hard disk files with reserved names, such as LPT1 or COM1. Do not use such file names.

• LAN Manager for OS/2 has a design limitation that prevents it from using more than one set of credentials (a username and password) at a time. That way, for example, if a user interactively logs on with one user ID and the Directory Replicator service tries to use a different user ID, the Directory Replicator service can't replicate any files until the interactive user logs off. However, if the interactive user and the Replicator user have the same user ID, replication is possible, depending on the value of the TryUser value in the lanman.ini file. (The system determines the setting of the TryUser value.)

• Import computers running LAN Manager for OS/2 and UNIX are generally limited to 1000 files per directory (keep in mind that the "." and the ".." directory entries use 2 of these 1000 entries).

• Are you replicating files from a High-Performance File System (HPFS) partition (written by OS/2) to an NT server? If any of these files have extended attributes, you might run into problems. OS/2 might have written the extended attributes in discontiguous parts of the export hard disk, and NT does not support this structure. The Directory Replicator service includes the extended attributes sizes in its checksums, and these values may be wrong in this situation. Wrong values could cause directory replication to stay out of sync permanently. You can use NT to rewrite the same values for the extended attributes to one contiguous area, if you know their original values.

• If a router separates the import and export computers, go to Replication under the Server applet in the Control Panel and add their machine names to the export To List and the export machine name to the import From List. This step forces name resolution across the router and should synchronize the computers with the domain.

I've had good luck using NT's Directory Replicator service across a local domain. However, I've encountered problems when trying to replicate files across multiple domains where routers and switches are involved. In these situations, I recommend an application such as Octopus Super Automatic Switch Over (SASO) 2.0 (for a review, see Carlos Bernal, "Octopus SASO 2.0," June 1997).

Q: How can I use an unattended script to add a password for an Administrator account?

In the conventional sense, you can't add a password for an Administrator account in an unattended script. However, you can put a Net Use Password /user:Administrator command in cmdlines.txt and place the net.exe file in the $OEM$ directory.

Q: Windows NT's Domain Name System (DNS) is one of the most undocumented aspects of NT. How do I conFigure DNS to show Windows Internet Name Service (WINS) reverse lookups?

A reverse lookup means that a user has an IP address and that the user wants to find the corresponding DNS name. Unfortunately, you have to manually create a special domain to find the corresponding DNS name. To create the domain, use the New Domain command in DNS to select a server to store the new domain and specify in-addr.arpa as the name of the new domain, as you see in Screen 4. This domain holds the pointer (PTR) record. Each PTR record corresponds to an Address record somewhere in the network's zone.

To enable WINS reverse lookups, open the Zone properties dialog box for the in-addr.arpa zone and click the WINS Reverse Lookup tab. Select the Use WINS Reverse Lookup box, as you see in Screen 5.

Q: I've noticed that Microsoft advocates the use of Windows Internet Name Service (WINS) files over LMHOSTS files, particularly when browsing a domain is an issue. Can you explain the difference in using each on networks and specifically for browsing capabilities?

Microsoft provides an excellent Knowledge Base white paper on this issue at http://www.microsoft.com/kb/articles/q150/8/00.htm. According to the white paper, Microsoft suggests that all large, multisegmented TCP/IP networks that use routers will run best with WINS. In such situations, WINS typically handles the complex browsing and configuration for these diverse and complex LANS or WANS. However, some large networks still need static mapping, and LMHOSTS files work well in these situations. (Because many of today's networks include Windows 95 machines, you need to realize that a Win95 client will participate in domain browsing only when the client is using a workgroup name that is equivalent to the domain name. Windows NT computers can either be part of a domain or a workgroup to participate in browsing the network.)

Browsing a Microsoft network is a distributed service that one or more computers provide. Each computer can take on several browser roles. The most important roles are the segment master browser (SegMB) and the domain master browser (DomMB).

The SegMB can be any NT Server, NT Workstation, domain controller, Win95, or Windows for Workgroups (WFW) 3.11 computer. The SegMB maintains a browse list of the computers within its local segment and forwards this list to the DomMB. The SegMB then requests the domain browse list from the DomMB. The SegMB merges the domain list with the local list, and makes the combined list available to local clients.

The DomMB is the NT Primary Domain Controller (PDC). It maintains the browse list for its local segment (i.e., it acts as a SegMB) and collects browse lists from other (remote) SegMBs with the same domain name (or Workgroup Name = DomainName). The DomMB merges the lists it collects with its local list and redistributes the combined list to all remote SegMBs. Thus, the Dom MB serves as the central hub for maintaining the domainwide browse list. To determine which machine is the Dom MB, the SegMBs locate the computer with the registered NetBIOS name of Domain<1b> (only the PDC, which is the DomMB, can register this name).

Browsing with WINS
In a WINS environment, a SegMB queries WINS to determine which machine registered the NetBIOS name of Domain<1b>. In this case, WINS provides a convenient central resource for this information.

WINS can help browsers in a multidomain browsing environment. A PDC set up to query WINS periodically requests the list of all domains registered in the database. A domain is identified by a Domain<1b> registration in the WINS database and the associated IP address of the PDC that registered it. The PDC combines this list with its domain browse list to build a complete list of computers in the PDC's domain and other domains across the WAN. The PDC provides this complete list to its SegMBs. Once the PDC has distributed this list, you see all the computers on the browse list when you use File Manager or Network Neighborhood to view the network.

(Providing information to the browsers in a network is the extent of WINS's involvement with browsing. It does not participate in the browser election process or help clients determine which computer is the SegMB or the DomMB. The process of identifying the DomMB occurs when the SegMB first contacts the DomMB.)

Browsing with LMHOSTS
In contrast to browsing with WINS, using LMHOSTS files requires special LMHOSTS entries that designate which machines are the domain controllers. Specifically, LMHOSTS files use the following convention:

199.199.199.1 ComputerName #PRE #DOM:DomainName

When you boot a computer, it reads these entries and stores them in the NetBIOS name cache until you turn off the computer. Therefore, storing these entries last in the LMHOSTS file is best for subsequent LMHOSTS parsing efficiency. All computers in the domain need one of these entries for each local domain controller and one for the PDC. Also, note the order and capitalization of #PRE and #DOM in the entry (the other names in the entry are not case sensitive).

Having these LMHOSTS entries is sufficient for an NT computer: An NT-based SegMB computer determines which machine is the PDC by sending a query (using the NetGetDcName API) to all LMHOSTS entries with the #DOM:<localdomain> designation. Only the PDC responds to this command. The NT-based SegMB computer then contacts the PDC, informs the PDC that it is a master browser, and continues the process of getting the domain browse list. The PDC then contacts the SegMB computer to get the SegMB's local segment browse list. This process of exchanging lists repeats every 12 to 15 minutes.

Win95 and WFW SegMBs are different. They do not perform the NetGetDcName API, so they need entries in the LMHOSTS file that identify which machine is the PDC. Assuming the example LMHOSTS entry above is the PDC, you would have two entries for a Win95 or WFW client:

199.199.199.1 controller1 #PRE #DOM:domainname

199.199.199.1 "domainname,,,,,\0x1b" #PRE

The first entry lets the PDC act as a logon domain controller for the client, and the second entry lets the client browser service find the PDC. You will probably have multiple entries similar to the first line (for multiple domain controllers), but only one entry with the \0x1b directive (to designate the PDC). Note that the domain name must be in quotes and padded with spaces for a total of 15 characters before the \0x1b portion (the example above shows commas for visual placeholders; however, these commas would be replaced with spaces in a real LMHOSTS file). Let's look at an LMHOSTS example.

LMHOSTS Example

If your domain name is bobsplace, your PDC NetBIOS name is bob1, and you have other various backup domain controllers (BDCs), your LMHOSTS file will look like

199.199.199.1 "globe \0x1b" #PRE

199.199.199.1 bob1 #PRE #DOM:bobsplace

199.199.199.2 otherdc1 #PRE #DOM:bobsplace

199.199.199.3 otherdc2 #PRE #DOM:bobsplace

LMHOSTS files are limited in multidomain environments because they don't automatically provide multidomain browsing as WINS does. In a WINS environment, the PDC will query WINS for a list of remote domains and add that information to its browse list. However, in an LMHOSTS environment, the PDC doesn't parse the LMHOSTS file for the same information, and it doesn't include other \0x1b entries with the #PRE (cache) directive. If your PDC does not query WINS, you can't see other domains through File Manager or Network Neighborhood. However, you can still browse other domains manually, based on broadcasts if you know the domain name and if you have special entries in your LMHOSTS file.