• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 267
  • Last Modified:

Removed last exchange 2000 server now the domain policy permissions appear to be incorrect

I setup a 2007 exchange server a month ago.  all is working.  I was cleaning up and removed the exchange 2000 server we previously used from the domain.  I used the disk to uninstall and ran the server for a month to make sure all functions had transferred to the new server. After removing, I experienced the following errors throughout the day on clients and the 2003 domain controller.

on domain controller:
error: 1030
Windows cannot query for the list of Group Policy objects. Check the event log for possible messages previously logged by the policy engine that describes the reason for this.

Error: 1058
Windows cannot access the file gpt.ini for GPO CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=mydomain,DC=corp. The file must be present at the location <\\mydomain.corp\sysvol\mydomain.corp\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\gpt.ini>. (Access is denied. ). Group Policy processing aborted.

XP clients:
Error: 1054
Windows cannot obtain the domain controller name for your computer network. (An unexpected network error occurred. ). Group Policy processing aborted.

The unique identifier in the 1058 error is the default domain policy for the domain.  I have checked the links to make sure it was linked to an OU.  I have checked to make sure the GPT.ini file was in the proper location and confirmed that it was similar to another domain.

The problems we are experiencing are difficult to track.  People at some sites are able to authenticate and access resources while other sites are not.  I am losing contact with software, machines, ....

The only thing that i can think of that would cause this is the removal of the exchange 2000 server from the domain and the uninstall process messed up the permissions on the policy/domain controller.  Since the gpt.ini file is confirmed as there and it states that "access is denied,"  it seems directly related to a permissions issue.  The 2007 server that we have in production is working.

Anyone have ideas about where to look or where to test with an everyone permission to make it work.  I have looked all day and not found a match or a fix for the issue.  I am operating with a very dysfunctional domain at this point.  Any help would be appreciated.

  • 3
  • 2
1 Solution
There is a specific procedure for migrating domain controllers from 2000 to 2003.  If you do not follow the procedure exactly, you will get these problems.  They won't show while the old 2000 DC is on the network, because the new is accessing the data on the old.  But once you unplug the old, everything goes wrong.

Netbios is a non-routable protocol. GPOs are populated in the SYSVOL record and distributed out to clients and servers using Netbios broadcasts.  By non-routable, this means it will not go over a VPN connection, through a firewall, or across NIAT.

If you have a route to go over, then you should use WINS as the transporter. A quick and very easy test for routing problems is to go into MY NETWORK PLACES and see if the server with the SYSVOL SHARE,  that holds the GPO you are trying to get, is listed. Since the browser service will also not work, (because it uses Netbios broadcasts), you shouldn't see the server in MY NETWORK PLACES.  

Netbios broadcasts are done on a local lan. Enabling Netbios over TCP/IP is the protocol and WINS is the transport to remote comptuers. An example:

Clients and servers site 1 all using netbios over TCP/IP____WINS connection between the servers____ Servers and clients at site 2 all using netbios over TCP/IP

An alternative fix to the transport is to use DNS for Distributive File shares (DFS). DFS is used to populate a list of shares and GPOs in sysvol that is shared out to the lan, like group policy objects. It is similar to Apple talk in that respect.

If the inability to route Netbios is your problem, there are two fixes to this:

FIX 1) So, here is what you do. You can configure WINS. Below, is an article on how to configure WINS for the Master browser service. All you want is a transport through the VPN tunnel.

Alternative fix: Fix 2) An alternative fix is to use DNS as the transport for DFS:
PLEASE NOTE: Please look at the key ports used by Windows 2003 anything using ports 137, for WINS and Netbios datagram ports 138 and 139 are effected if you do not use WINS. If all you are after is DFS, then you could use DNS. So, there are drawbacks to using DNS.
I didn't see any mention of netbios, and it would be unusual to have it on a win2000 win2003 network.  It is archaic for that platform.  Normal IP addressing suffices.
Making Bulk Changes to Active Directory

Watch this video to see how easy it is to make mass changes to Active Directory from an external text file without using complicated scripts.

DFS (Distributive File Service) uses Netbios to send out the Sysvol records to other nodes on the network. If a VPN is involve Wins needs to send it out the Sysvol shares to the remote stations.

Archaic is right. Netbios and WINS were suppose to be taken out of service when DNS came around. This is why SBS enables WINS by default:

So, here is a review of all the services that currently use netbios by default:
137 UDP NetBIOS Name Resolution Computer Browser
137 UDP NetBIOS Name Resolution Server
137 UDP NetBIOS Name Resolution Windows Internet Name Service
137 UDP NetBIOS Name Resolution Net Logon
137 UDP NetBIOS Name Resolution Systems Management Server 2.0
138 UDP NetBIOS Datagram Service Computer Browser
138 UDP NetBIOS Datagram Service Messenger
138 UDP NetBIOS Datagram Service Server
138 UDP NetBIOS Datagram Service Net Logon
138 UDP NetBIOS Datagram Service Distributed File System
138 UDP NetBIOS Datagram Service Systems Management Server 2.0
138 UDP NetBIOS Datagram Service License Logging Service
139 TCP NetBIOS Session Service Computer Browser
139 TCP NetBIOS Session Service Fax Service
139 TCP NetBIOS Session Service Performance Logs and Alerts
139 TCP NetBIOS Session Service Print Spooler
139 TCP NetBIOS Session Service Server
139 TCP NetBIOS Session Service Net Logon
139 TCP NetBIOS Session Service Remote Procedure Call Locator
139 TCP NetBIOS Session Service Distributed File System
139 TCP NetBIOS Session Service Systems Management Server 2.0
139 TCP NetBIOS Session Service License Logging Service

Now, with that said, some of these services can be reconfigured to use DNS. For instance DFS:
Example: http://support.microsoft.com/kb/314494

I have yet to find a fix to the browser service to use DNS.

~~~~~As archaic as it might be, Netbios might be a necessary evil.

Below is a free body diagram I have been using to fix many people with browser issues over a VPN. This is how they connect using netbios to broadcast out to the clients and WINS to go over a VPN or WAN connection.

Regardless, NETBIOS has NOTHING to do with the correct migration of DCs to a different platform, like going from W200 to W2003.  The crucial part here is the correct migration procedure.  The problems he is seeing is from not following the correct migration procedure.  If you do not do it right (see links I gave) then the new DC will be looking to the old DC for routing, DNS and client login data, and this is NOT what he wants.

If / when he replies, I can outline the correct procedure.  Netbios has actually NOTHING to do with a correct DC migration.
rbnetworkadminAuthor Commented:
I want to, first of all, thank everyone for their participation in working on this problem.  I have found the solution.  Unfortunately, coincedence led me to believe the issue was with the removal of the exchange server.  At almost the exact same time that I completed the exchange removal, the network circuti provider updated the IOS on a core services router.  One of the OC3 cards on the router did not set correctly on reload.  This issue caused a black hole router situation for packets coming into our primary datacenter.

I called microsoft on the errors that were receiving and they worked on the issue.  They found that the MTU was forced to 1420 accross the core routers somewhere.  I initiated a work around for critical machines until we could get the problem fixed. We tested the lan interfaces and wan interfaces at a remote site and the datacenter site.  the lan mtu was ok to the router interfaces, but the datacenter would not accept the standard MTU setting (1500) past the serial interface on the datacenter router.  The problem was in the core somewhere.  After complaining, begging, griping, convincing, and pinging my brains out - I finally convinced the provider that something was wrong with their equipment and they reset the card.  Everything was working again.

Thanks again and I apologize for the misdirection.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Has Powershell sent you back into the Stone Age?

If managing Active Directory using Windows Powershell® is making you feel like you stepped back in time, you are not alone.  For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why.

  • 3
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now