Running gpresult on the offending machines give you any clues ?
Running gpresult on the offending machines give you any clues ?
just a long shot, but try this:
create a new OU, different name, and move all the objects from the OU where its not pulling the policy.
either recreate or link the policy you want to enforce and then try the gpupdate/secedit and a few reboots.
we had the same problem, thought it was domain replication (it was that also), and in the end i created a new OU, and it all worked.
You also have to think about the FSMO roles... were any stored on the old server. If so, you have to force the current servers to not to look for them and force a move.
We dont seem to have a problem with the gigabit network cards in our machines.
You might also want to look at your DNS'
You said you cleared out the OLD GC server. Does this mean you used the NTDSUtil to remove the left-over schema if the dcpromo had not been run before-hand.
Replmon will give you who owns each of the FSMO roles.
OK, to update people so far, though I am still examining a few other possibilities.
In order to clear out the old GC Server, we did indeed use NTDSUtil, I have used replmon to examine the FSMO roles and they report to be the current GC server.
Despite purging the old GC, when searching for domain controllers its NETBIOS name still shows up. This is proving to be a little curious for me, although it does have to be said that there is no other sign of the machine anywhere else.
Running the Group Policy Result tool has initially been unhelpful. At this time at least, the report indicates that all of the policies have been applied successfully. Now it is true that some of the policies have been successful, but certainly not all. I will be looking into this further though, as I am bound to have missed something.
Oh and to HodgeHi, no the DC was not down for a long time, but as I am sure you have gathered we have manually purged it from the other computers.
Thank you all so much for your help, I will keep you updated as I try some more approaches later on.
How about running the Group Policy modelling wizard and specifying the PC and user($) with the problems ?
OK, I have now created a new OU for the affected users, unfortunately the problem remains unabated. I'm calling off the problem for a few hours until I can think of something new. This requires some out of the box thinking.
This is a common occurance when DNS pollution happens.
Make sure you can ping a suspect machine both forwards and reverse.
(ping and ping -a xxx.xxx.xxx.xxx)
Check for dupes in your forward/reverse DNS zones especially reverse if you have been imaging systems.
The DNS fails to scavenge correctly or in a timely fashion, multiple hosts appear in DNS to have the same IP when in fact they do not.
Your policies fail to apply because the hostnames are not resolved correctly.
If you were capable of orphaning a DC I suspect that a back to basics approach is needed to retrace your steps.
check your firewalls if they are on. I think if you cannot ping the clients then the firewall will most likely be on
If the XP Firewall was on, you would still get Group Policy through it, we have the XP Firewall disabled via GPO here and we have new PCs, we boot 'em up - log 'em in and viola - no firewall.
Things to try:
1) WINS - Clear everything out of your WINS Database - NETBIOS will eventually repopulate this itself.
2) DNS - Can't be stressed enough, fire up DNS and check through the _msdcs.domain container and everything therein. If you didn't manage to remove the old server via DCPROMO, it may still have some footprints in DNS.
3) RSoP - See if an RSoP on an affected machine gives you anything back.
4) Event Viewer - Check this on Server and Client (try to use the same client for all testing, so you have a reference point).
I'm guessing when you used NTDSUtil - did you clear out metadata, seize any FSMO roles and such?
We had a similar issue when a 'middle' PC was used to upgrade one of our DCs from NT 4 to 2003 - what fun that day was. If only county had known about ADMT.
Oh... try running 'netdiag /v' on a DC and 'dcdiag /v' - these are always good things to check.
Let us know how it goes.
To update you all;
Have been through DNS with a fine tooth comb, it really does appear to be working perfectly. Forward and reverse pinging works perfectly, including the affected machines. Myself and my colleagues have examined the DNS servers carefully and there appears to be absolutely no sign of trouble on that front.
I and another colleague have also checked that the old DC has been completely purged from the system thoroughly enough for me to say with confidence that the operation was completely successful.
I will be running through some of your other suggestions and will report back presently.
Thank you all once again for your assistance.
I also have the GPO disable the firewall but on occasions i could not ping the clients at all. For some unknown reason the firewall seemed to block everything. I could not get a group policy to come down and apply because of the firewall.
I tried rsop and group policy results wizard from the DC and could not connect to the RPC.
I then checked the firewall. I was sure that it had been disabled but it was on and stopping all connections. I could ping the server from the client but i couldn't ping the client. Disabling it resulted in GPOs being applied again.
Sorry, did forget to mention that all PC firewalls have been deactivated.
Just as an update, a colleague of mine discovered the solution. It appears that our the aspects of the policies that were not being pulled across required administration rights in order to apply. An old 'everyonetoadministrator' script on the server put it all to rights and we live in policy harmony once more. Thank you all for your help.
just casually browsing this thread and would be doubtful that everyone-to-admin-rights would be the correct solution even if it does get the desired results.
I think personally that something has been missed and since you state that these problems occur on the new machines even after re-imaging etc then I would be looking at bios, ...and to me the only obvious thing in that case is that your clocks may be out of sync with your server (this would cause all sorts of unobvious faults). You might find that your login script has a command that resyncs time with the server but the command fails when the user doesnt have admin rights.
Worth a look.