Link to home
Start Free TrialLog in
Avatar of arnold739
arnold739

asked on

Windows Update Services - Server Name on Client

We recently changed the Server for automatic distribution of Windows Updates on our network. Problem is that some (Not All) of our Client PCs keep reverting back to the old server to get the updates. The Registry keys ; HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Windows Update\ WUServer
and
HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Windows Update\ WUStatus Server
keep reverting back to the old server?
We have 2 domain controllers that manage Group Policies using Active Directory. Both Group Policies are pointing to the new server.
We have tried running GPUPDATE /Force several times and rebooting several time on most of these machine and sometimes it appears to hold the new server name but then flips back to the old.
We are really stumped on this one!!!!
Avatar of Maen Abu-Tabanjeh
Maen Abu-Tabanjeh
Flag of Jordan image

rename group policy folder from c:\windows\system32\groupPolicy to any name like ,
old.grouppolcy
you may need to boot in safe mode to that and note this folder is hidden , then try again and let me know
at a command prompt of a machine that has the old server listed, if you type inn gpresult, does it show the appropriate policy is being applied?
Avatar of arnold739
arnold739

ASKER

We are investigating based on these responses. Will advise results shortly.
"We recently changed the Server for automatic distribution of Windows Updates on our network."

Did you also update the GPO that "Specify intranet Microsoft Update service location"

http://technet.microsoft.com/en-us/library/cc708574%28WS.10%29.aspx


You can use rsop.msc to narrow down which GPO
Sorry jumped the gun a little with my response

Try running

wuauclt /resetauthorization /detectnow on them
FYI we have run wuauclt /resetauthorization /detectnow several times but this does not resolve the problem.
GPRESULT does show appropriate policy being applied.
Will advise shortly regarding jordannet response.
Renaming the Group Policy folder and rebooting did not change the WUServer. The Group Policy Folder was recreated.  
net stop wuauserv

delete the registry key

gpupdate /force

delete c: windows\softwaredistribution
check local machine policy for updateserver settings.

net start wuauserv

wuauclt /detecnot

wuauclt /reportnow

now there shouldn´t be the ip set anymore
Nope, keeps going back to old server. Seems to be flip flopping between servers. Tried these routines several times and sometimes the correct server appears but then a reboot or gpupdate flips it back again????????????
I guess the key here is to try and find where the old server name could possibly be coming from?
We have double checked the group policies on both DCs and they show the correct server for Windows Updates. Any other suggestions would be appreciated.
Did you run rsop.msc to narrow down which GPO is applying the wrong policy??
ok , read this article :

http://support.microsoft.com/kb/816100

its may help you
The GPOs from both DCs appear in rsop.msc
There are no local policies enabled on the clients.
did you read my link?
Yes, there are no restrictions under Delegation.
try to move user to other ou with new policy and check
"The GPOs from both DCs appear in rsop.msc" ??

You have 2 WSUS gpo's ??

@jordannet

"try to move user to other ou with new policy and check"

Windows update settings are computer settings, not user settings
"The GPOs from both DCs appear in rsop.msc" ??

You have 2 WSUS gpo's ??

To clarify... we do have 2 Domain Controllers (for redundancy in case one fails) and both have GPO that are both used redundantly. Running gpresult on individual clients may show either DC. The GPOs are identical on both servers and both point to the correct WSUS server.
That being said....there must be something else that overrides the correct WSUS server on the clients, to use the old WSUS server.
 I have noticed that running rsop on a client then trying to open Administrative Templates generates an error message attached.       RSOP-error.doc
I am thinking that the overriding parameter may be on the clients, although there appears to be no local policies enabled. also,we do have other policies set up in GPO management on the DCs. Is it possible that a different policy could be overriding the WSUS policies?
What else can we check?    
Format the PC its the last thing you have to do :-p
"To clarify... we do have 2 Domain Controllers (for redundancy in case one fails) and both have GPO that are both used redundantly."

Are both "Global Catalogs" ???

Are you having any replication errors between them??
You might want to go over

Troubleshooting Active Directory Replication Problems

http://technet.microsoft.com/en-us/library/bb727057.aspx


Initiating Replication Between Active Directory Direct Replication Partners

http://support.microsoft.com/kb/232072
We are investigating a possible cause of the problem and will advise. Might be a day or 2.      
Might be something to do with SYSVOL. We are likely bringing in a consultant that we use from time to time. The WUServer Name is definitely flip flopping from old to new to old to new. GPUPDATE /force is putting it to the correct server most of the time, usually with a reboot but then subsequent reboots will flip the server back and forth.  
We might have found the solution. Will post shortly.
the last reply from the asker :

We might have found the solution. Will post shortly.

so we might need to close the case without any point reward.
ASKER CERTIFIED SOLUTION
Avatar of Don
Don
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
yes dstewarjr , but i wish if the author come and post the answer here, its might be useful for others. just wait 2 days to give author chance to post his solution..

thank you
Ok, sorry for the delay, but with holiday season, etc. we were really backed up here. We resolved this problem with  Microsoft support help. The problem was caused by our two AD domain controllers not sychrnonizing properly. With their help, we managed to get the synchronization back working and now all machines are getting the same policies applied - prior it depended on which one of the two provided the policy.
thank you arnold for posting the solution it will be useful for other people ...

Regards

Maen Abu-Tabanjeh
I felt you partially anwered the question, we were unable to rectify the problem without MS Support help.
The correct accepted responses are here


http:#a37257369

and here

http:#a37257388


Which you verified with your response "The problem was caused by our two AD domain controllers not sychrnonizing properly."  


which I feel doesnt merit a "B" grade