DCPROMO Problems; A VPN/ISA Server Conflict
Paula Sharick discusses a problem that arises when you demote a domain controller (DC), a VPN/ISA Server conflict, a RRAS problem, and more.
January 21, 2002
Cleaning Up After a DC Move
If you use DCPROMO to move a domain controller (DC) from the source domain to a destination domain, you might receive continual nagging messages from Netlogon. The messages, which appear in the DC's event log, have Event ID 5781 and the text, "Dynamic registration or deregistration of one or more DNS records failed because no DNS servers are available." During the demotion process, DCPROMO is supposed to remove all the DC-specific Netlogon service records on the DNS server that performs name resolution for the source domain. The messages indicate that DCPROMO didn't remove all the DC-specific Netlogon names from the DNS server.
To eliminate the messages and properly register the Netlogon service names, you must delete the old, invalid Netlogon service names that DCPROMO skipped and reregister the DC’s Netlogon service records in the new domain. Find the file %Systemroot%system32configetlogon.dns on the DC you moved. This file contains all the Netlogon service names the DC must register to function properly. Scan the file and find lines that begin with a semicolon, as in the following example:
;5175a911-d70b-4d3c-8df1-024ca6cd6a50._msdcs.company.net. 600 IN CNAME server.child-domain.company.net
On the DNS server, remove all the invalid Netlogon records that conform to the format in the example and restart the DC’s Netlogon service. Restarting the Netlogon service forces the DC to reregister the Netlogon service names, which will stop the nagging messages. I haven't tested this workaround, so let me know whether it works for you. For more information, see Microsoft article Q311354.
VPN/ISA Server Conflict
Here’s a bug that occurs on VPN servers running RRAS with Internet Security and Acceleration Server 2000 (ISA Server). A race condition between the two services causes a deadlock that prevents the RRAS service from starting. When the deadlock occurs, Layer Two Tunneling Protocol (L2TP) clients can't connect to the server because the RRAS service isn't running. If you have this problem on your VPN server, you’ll see the following message in the event log:
Event Type: Warning Event Source: RemoteAccess Event Category: None Event ID: 20171 Description: Failed to apply IP Security on port because of error:The RPC server is unavailable. No calls will be accepted to this port.
No bug fix is available for the deadlock. To work around the problem, you can set the RRAS service startup to Manual. After you reboot the VPN server, you must manually start the RRAS service before the server will accept incoming connections.
RRAS Ignores More Than 35 Input or Output Filters
If you’re heavily leveraging RRAS’s packet-filtering feature, you can easily exceed 35 input or output filters, especially when you're limiting remote traffic to and from multiple subnets. You can configure more than 35 input and output packet filters, but RRAS only processes the first 35, regardless of how many are present. Unfortunately, RRAS doesn't inform you that it's ignoring the remaining filters. I presume from Microsoft's description of this problem that RRAS ignores all filters that occur after 35 in either the input or output filter list, not 35 total from both lists. If this describes your combination VPN/firewall, call Microsoft Support Services (MSS) and ask for the new version of rasppp.dll with a file release date of August 23, 2001. For more information, see Microsoft article Q300962.
Resource Kit Printer Migration Utility
Microsoft recently released the Windows 2000 Resource Kit Supplement One (Win2K Server and Win2K Professional versions). Supplement 1 includes a new GUI-based printer-migration utility called printmig.exe that expedites the process of moving a print server to a new system. You can use the utility to migrate printers from one Windows NT 4.0 system to another or from one Win2K system to another. You use prinmig.exe to back up the configuration of the print server you want to move to a cabinet (.cab) file and then restore the backup .cab file to a new system. The source and destination platforms must be identical, which means that you can't back up an NT 4.0 print server and restore the backup on a Win2K system, or vice versa.
The utility creates a .cab file with the default name of pm.cab that contains all configured printers and associated print queues, printer drivers, supporting registry entries, published print shares and share point ACLs, and printer monitor ports, including Hewlett-Packard network ports, LexMark IP/Data Link Control (DLC) ports, Jet Admin ports, Line Print Remote (LPR) ports, Digital Network ports, and Apple Talk ports. The documentation states that the migration tool backs up only the defined ports, not the actual monitor. Before you restore the configuration on the destination system, you must install the original set of port monitors. The tool displays a warning message for each monitor that isn't present after it completes the restore procedure. Microsoft article Q315983 describes this new utility and includes simple directions for backing up and restoring the configuration on a new machine. I’m sure many of you will appreciate this time-saving tool.
A NetWare Printer Bug Fix
Microsoft just released a fix that corrects a Novell NetWare printing problem in the Gateway Service for NetWare (GSNW) component. The code fix lets the GSNW administrator change the default NetWare printer options, including the banner page and whether the print driver should append a trailing form feed to the print job. Without this update, Windows 2000 clients are restricted to the NetWare printer's default options. After you install the update, log on to GSNW using the GSNW gateway account, which must have local administrator rights, and configure the printer options you want. The options you select will then be available to all Win2K users who send print jobs to the NetWare printer. To get the update, call Microsoft Support Services (MSS) and ask for the new version of nwprovau.dll with a file release date of January 10, 2002. For more information, see Microsoft article Q314264.
About the Author
You May Also Like