kittensizedbulldozer
asked on
Domain Group Policy won't update
Hi guys, here's something I'm hoping you can help me with.
We had a domain controller that recently died, and because there was no backup domain controller in place at the time, we had to seize all the roles from the old on onto our current one. Everything is working fine as far as that goes, but I've noticed recently that the domain group policy won't update. We don't rely on it heavily which is why it's gone under the radar until now. I think it has to do with the fact that the original default domain policy doesn't exist anymore. When in the Group Policy Management snap-in, if I try to edit it it says "The system cannot find the path specified"
I've also noticed the path it's referring to, the "Unique ID" no longer exists anymore (this is the big 20 or so digit number) and it's not longer a valid directory in the Sysvol. Is there a way to delete this old policy and its references? I believe this is why DGP no longer syncs, since it's probably failing accessing that directory and then stopping
We had a domain controller that recently died, and because there was no backup domain controller in place at the time, we had to seize all the roles from the old on onto our current one. Everything is working fine as far as that goes, but I've noticed recently that the domain group policy won't update. We don't rely on it heavily which is why it's gone under the radar until now. I think it has to do with the fact that the original default domain policy doesn't exist anymore. When in the Group Policy Management snap-in, if I try to edit it it says "The system cannot find the path specified"
I've also noticed the path it's referring to, the "Unique ID" no longer exists anymore (this is the big 20 or so digit number) and it's not longer a valid directory in the Sysvol. Is there a way to delete this old policy and its references? I believe this is why DGP no longer syncs, since it's probably failing accessing that directory and then stopping
ASKER
Well we did not bring on a new online, the old one and all its rolls when it died was immediately seized by the new one. The DHCP scope is configured to point to the new active directory controller as the primary DNS, and I've gone through and made sure all references to the old AD controller are gone. The server that died died completely and has no chance of being resurrected and put back into service.
I'm still looking for a way to delete the invalid path to the original DGP and create a new one in its place.
I'm still looking for a way to delete the invalid path to the original DGP and create a new one in its place.
Go to active directory sites and services>>default first site and see if there any references within there to your bad DC.
ASKER
Nope, that's all been cleaned out. It refers to my primary and secondary controllers that are both online, I removed references to the old one after we'd seized the roles from it.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
You brought an old domain controller back into the system. If that DC has been out of the system for over 30 days, it will be considered a tombstoned server. If you siezed the roles of the server that crapped out on you to a tombstoned server, you are effectively creating a new domain with the same name domain name.
How will this effect your domain, you ask?
It appears that AD authentication is working. I don't know how bringing back a tombstoned server will interact with domain services. I think what you need to do is go into DHCP scope options and see if your clients are getting the old preferred DNS server of the server that doesn't exist. For Fixed IPs, go to the nic configuration and remove the server that doesn't exist from being the preferred DNS server. Then, on this old server that was recently put back into action, make sure that server doesn't exist as the preferred DNS server and that server also doesn't have SRV, Host A, SOA, and NS records withing its DNS.
IMPOTATNT NOTE: Removing DNS and FRS metadata is just as important as removing AD metadata of a failed DC.
The error you are seeing usually comes from not seeing the preferred DNS server that points the way to your group policies. But, the false impression that you can bring in a decommissioned server without issues is something I haven't seen much of and errors may come up as time goes by. Just count your blessings that AD works while you work expiditiously to get the other server up and going back into the domain.