Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 348
  • Last Modified:

Can't get servers to connect to WSUS server via GPO or local policy

We have one WSUS server on the domain (hostname = wsus001) running Windows Server 2003 and WSUS v 2.0.0.2620.  Since Day 1, clients haven't really been connecting to the server properly or at all.

I have a few servers connected to it but all through local policy.  I have specified a group name called Commerce, but when I enter the group name to "Enable Client side targeting", it never gets added to that group.  That is happening on 2 of the 5 servers that were able to connect to the WSUS server.  

For some other machines, I have tried using GPO to connect them to wsus001 and the Commerce group.  But none of them have ever been able to connect.  I created an OU in AD, moved several servers into that OU including the 5 servers mentioned above, and set my policies.  Here are the options set:

1. Configure Automatic Updates
2. Specify intranet Microsoft update service location
3. Enable client-side targeting
4. No auto-restart for scheduled Automatic Updated installations

Any ideas?
0
AhDoi629
Asked:
AhDoi629
  • 7
  • 4
  • 2
  • +3
1 Solution
 
paintcheck200Commented:
sounds like your group policy is not being applied correctly - on one of the problem machines , run gpresult , make sure the policy you created is being applied.

If XP - Run Help and Support - Tools - Advanced System Information (on the right) - View Group Policy Settings Applied
When it shows the Registry  settings applied, look for UseWUServer - this should be wsus001 .  I would also be using the FQDN

Also, I would highly recommend moving to the current version of WSUS.
http://technet.microsoft.com/en-us/wsus/default.aspx
0
 
AhDoi629Author Commented:
I ran gpresult on one of the problem machines and it appears that the policy is not being applied.  I'm not a group policies expert, so I don't exactly know how to proceed
0
 
SridharMani12Commented:
To make the system report to WSUS server try these options
It works very good for me ( These systems should be in DOMAIN)

If it works for you,  you can create a batch file to update all the systems in the network

reg delete HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate /v AccountDomainSid /f
reg delete HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate /v PingID /f
reg delete HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate /v SusClientId /f
net stop wuauserv
net start wuauserv
wuauclt /resetauthorization /detectnow

Good Luck
0
Problems using Powershell and Active Directory?

Managing Active Directory does not always have to be complicated.  If you are spending more time trying instead of doing, then it's time to look at something else. For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why

 
Malli BoppeCommented:
Open the group policy management console and run a Resultant set of Policy wizard at the bottom.
Procedure
Right click on Group Policy Modelling  and click Group Policy Modelling Wizard  and follow the prompts.Run this on the problem machines and you should be able to find out why these machines are not joing the wsus
0
 
x_calibreCommented:
On a client, check c:\windows\windowsupdate.log
you should be able to troubleshoot from what you find here

script below blows away some additional keys to sridhar's, and clears the proxy winhttp proxy (which affected a couple of our machines)

haven't had any problems since


===========================================================
echo off
cls

net stop wuauserv

REG DELETE "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update" /v LastWaitTimeout /f
REG DELETE "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update" /v AUState /f
reg delete "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate" /v PingID
reg delete "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate" /v AccountDomainSid
reg delete "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate" /v SusClientId

proxycfg -d

net start wuauserv

wuauclt /resetauthorization /detectnow
0
 
AhDoi629Author Commented:
Digging into this a little more and I realize there is a problem with group policies on the domain.  The machines are all logging Event 1058 and 1030, saying it does not have permission to access gpt.ini.  What is the correct permissions for \\<doman name>\sysvol?
0
 
AhDoi629Author Commented:
I gave Everyone read/execute permissions to \\<domain name>\sysvol, then I ran gpupdate on one of the problem machines and checked the event log.  I didn't get Event 1030 or 1058 and there was a success event for GPO!   Moments later, I ran gpupdate again and checked the event viewer, and the events are coming back!  What's happening?

I went back into the permissions for the sysvol folder and saw that the Everyone has turned into "Account Unknown (S-1-5-32-547)".  This was what I was seeing before until I removed it and added Everyone with read permissions.  Now it's back.  Something is causing the user permissions to get corrupt.

What gives?
0
 
Malli BoppeCommented:
Install the fix as mentioned in this article
http://support.microsoft.com/kb/842804
0
 
AhDoi629Author Commented:
I don't think that hotfix would help.  I don't think DFS is the problem and our servers never go into standby mode.  

Something is making the permissions corrupt on the sysvol share
0
 
x_calibreCommented:
sysvol should generally be left alone
i'd try resetting syvol permissions as in this document - its in the context of having moved the sysvol folder, but it should be usable for you
http://technet2.microsoft.com/windowsserver/en/library/300796c6-8148-49af-a327-b5dca853ac4f1033.mspx?mfr=true
0
 
AhDoi629Author Commented:
Just noticed something that may be important.  Our PDC (BOS-DC01) has 4 GPO's in C:\Windows\SYSVOL\SYSVOL\<domain name>\Policies that do not exist on one of our older domain controllers (ADMIN001).  Admin001 also has a GPO that does not exist on BOS-DC01.  

I clicked into each GPO folder and looked at gpt.ini.  As seen in the description field, these are the GPOs that are not being applied.

Could I simply copy these folders to ADMIN001?
0
 
Malli BoppeCommented:
Seems like a problem with FRS service.In your DC check for any FRS errors in the event viewer.Try to resolve the issue than copying it manually.
0
 
AhDoi629Author Commented:
I did check FRS and from the File Replication Service log in the event viewer, I have a ton of warnings like this one:

Event Type:      Warning
Event Source:      NtFrs
Event Category:      None
Event ID:      13508
Date:            8/1/2007
Time:            10:27:24 AM
User:            N/A
Computer:      BOS-DC01
Description:
The File Replication Service is having trouble enabling replication from ADMIN001 to BOS-DC01 for c:\windows\sysvol\domain using the DNS name admin001.commerce. FRS will keep retrying.
 Following are some of the reasons you would see this warning.
 
 [1] FRS can not correctly resolve the DNS name admin001.commerce from this computer.
 [2] FRS is not running on admin001.commerce.
 [3] The topology information in the Active Directory for this replica has not yet replicated to all the Domain Controllers.
 
 This event log message will appear once per connection, After the problem is fixed you will see another event log message indicating that the connection has been established.
0
 
AhDoi629Author Commented:
Is it advisable to restart FRS on one of our domain controllers in the middle of a business day?
0
 
ChiefITCommented:
1) Check windows firewalls, if Your LAN is behind a hardware firewall, temporarily disable the windows firewalls on the domain controllers and clients and see if you can administer policy and/or get updates.

2) As you probably know, client machines also need to have the Genuine advantage and be at least up to service pack two for XP, and service pack IV for 2000 to work with WSUS.

3) Also, see if you have "management and monitoring" service installed under:
 Control Pannel>>Add/remove programs>>Windows components
On all client machines.

If none of those are the solution, run DCdiag and NetDiag to see if you can pinpoint the failures in FRS.
0

Featured Post

Simplify Active Directory Administration

Administration of Active Directory does not have to be hard.  Too often what should be a simple task is made more difficult than it needs to be.The solution?  Hyena from SystemTools Software.  With ease-of-use as well as powerful importing and bulk updating capabilities.

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