The first consideration is to see if the WSUS GPO has been configured
and linked to the proper OU in Active Directory. Frequently I will see
how the GPO might not be linked or configured. Often the WSUS server
name might be incorrect or WSUS server name are configured with the
incorrect port number in the WSUS GPO.
In GPO Management (or Active Directory Users and Computers), make sure the WSUS GPO is created and linked to the OU that contains the machines that is suppose to get the GPO settings for WSUS. Open up the GPU to:
Computer Configuration > Administrive Templates > Windows Components > Windows Update
As a minimum we have to enable 2 settings:
The above is the minimum needed in any GPO for WSUS to function.
Permissions:
We have 2 types of permissions to be concerned about: NTFS permissions on the WSUS Server as well as IIS permissions and security. Sometimes if these permissions are not correct it prevents the WSUS webservices in IIS from functioning correctly and thus WSUS clients can not report in.
HTTP 401.3: DENIED BY RESOURCE ACL:
Frequently if your WSUS client (Automatic Update Agent) is healthy and your GPO is offering the correct WSUS server and port information and you still do find that WSUS client are not reporting into the WSUS console, then permissions on the WSUS server are most likely the problem.
It is not always NTFS security that is the problem, but could be IIS permissions. If you are outright getting a 401.3 error you know to focus on NTFS permissions. But, I recommend to always run Process Monitor when you start troubleshooting WSUS to make sure WSUS has all the permissions it needs on the file system and in the registry.
On the WSUS server, download Process Monitor from. Follow the following steps:
1) Go to http://technet.microsoft.com/en-us/sysinternals/default.aspx
2) Look on the right-hand side and download "Process Monitor" (AKA: PocMon)
3) Extract it on the WSUS server and run "procmon.exe"
4) Click on "Filter" >>"Filter"
5) Set "Display Entries Matching These Conditions" to:
- RESULT - CONTAINS - DENIED (you have to type in the word DENIED) then INCLUDE
6) Click "Add"
7) ALSO Set "Display Entries Matching These Conditions" to:
- PATH - CONTAINS - CERTIFICATE (you have to type in the word CERTIFICATE) then EXCLUDE
8) Click "Add", "Apply" then OK
9) Stop and Start the "World Wide Web Publishing" Service
- Wait 30 seconds
10) Stop and Start the "Update Services" Service
- Wait 30 seconds
11) Go back to ProcMon
This filter will show all processes that issues an ACCESS DENIED event. For the most part your concern is to look at both W3WP.EXE (which is IIS) as well as both WSUSSERVICE.EXE and SQLSERVR.EXE.
Notice any ACCESS DENIED events and see if they were denied to a registry key or a file on the file system for the 3 above mentioned services. If you find any ACCESS DIENIED for any of the above processes denying the user account "Network Service" access, that registry key or file would need permissions set to allow the "Network Service" to have FULL CONTROL to the respective Registry Key or File. Give the permissions accordingly and keep track of the changes you make. Once you have assigned a permission, close ProcMon, run it again and see if the permission error comes up. By doing this you will make sure WSUS has all the NTFS permissions it needs to function.
** ALWAYS BACKUP YOUR REGISTRY BEFORE MAKING ANY CHANGES **
NOTE: To close ProcMon.exe properly, click on FILE >> (Uncheck) CAPTURE, then FILE >> EXIT
Some common files/folders for WSUS that needs to be confirmed that they have FULL CONTROL set for the "Network Service" account are:
In addition to NTFS permissions occasionally being incorrectly set for WSUS, from time-to-time we find IIS permissions being incorrect or out of sync. Ensure that IIS Virtual Directories (vDir's/webservices)) are set as shown below:
After you have confirmed the security and had to make a change to it in IIS, remember to do a IISRESET. If there are other websites on the server in addition to WSUS, do a stop/start of the WSUS website.
Confirming your WSUS server permissions and IIS security is healthy:
Once you have made all the needed security changes to NTFS as well as IIS, re-run ProcMon a few times and ensure no ACCESS DENIED events, it is time to test the health of the WSUS server.
Look in the Application Log to see if you had prior "Windows Update Services" errors. Open a command line and run the following:
CD c:\Program Files\Update Services\Tools
wsusutil checkhealth
This will initiate a WSUS healthcheck and force events to be written to the Application log. If all of the security changes you made earlier rectified the health of WSUS you should see no "Windows Update Services" errors. If the issue you were having were security related, most often prior to start fixing the issues you would have seen the following Event ID's: 12052, 12042, 12022, 12032, 12012 and/or 12002.
Re-run Procmon (with the same 2 filters we added before) and re-start IIS wait 30-seconds then re-start the "Update Services" service. If ProcMon still gives no more ACCESS DENIED events other than the CERTIFICATE events, you would have to look into resetting the IIS IUSR account.
How to identify what HTTP 401.x error you might be experiencing:
When we troubleshoot WSUS clients that are not reporting into the WSUS server we frequently might be experiencing a HTTP 401.x error. There are 2 ways to see which 401 error you might be having 401.1, 401,2, etc. One way is to open one of the URL's below from the WSUS-client and see if you are getting a HTTP 401 error:
2009-01-27 16:45:10 W3SVC310782280 10.10.1.10 HEAD /selfupdate/wuident.cab 0901271645 8530 - 10.10.1.43 Windows-Update-Agent 401 1 0
Above you can see an HTTP 401.1 being generated on the SelfUpdate webservice.
HTTP 401.1: DENIED BY INVALID USER CREDENTIALS:
This error code will have you focus on the credentials of the IUSR account. If you are receiving a 401.1, from a WSUS perspective it means we have to go and look at IIS to make sure the IUSR username and password is correct for Anonymous access on all the WSUS vDir's. Occasionally the IIS guest account (IUSR_ account) has it's password out of sync between the IIS Metabase, Active Directory OR SAM (depending if the IUSR account is a local or domain account) and the credentials entered as the Anonymous user and password for the WSUS Virtual Directories in IIS. We need to make sure that the correct user account and credentials are used at 3 places:
Edit c:\Inetpub\AdminScripts\ADSutil.vbs
Search for the line that reads "IsSecureProperty = True" and change it to "IsSecureProperty = False". Save and close the file.
From command line run:
Cscript adsutil.vbs get w3svc\anonymoususerpass
This will return an output like this:
anonymoususerpass : (STRING) "ThisIsTheIUSRaccountPassword"
Take note of the password, INSIDE of the quotes. The quotes are not part of the password. For safety, copy it into notepad.
Go to either Active Directory (if a domain account is used for the IUSR account) or find the LOCAL ACCOUNT for IUSR. In most cases IUSR will be a local account. Reset the password for your IUSR account with the password we just pulled from the IIS Metabase.
Open IIS Manager and expand the WSUS (or default) website where the WSUS Virtual Directories are located. Right-click on the vDir >>Properties >>Directory Security >>EDIT. Update the IUSR account with the password we pulled from the IUSR Metabase. Do this for each of the below vDir's:
IMPORTANT: If WSUS is the only website on your server you will be safe to reset the IUSR account. If it is not the only web application running on your server, consider copying the old IUSR account and create a new account called something like IUSR_WSUS and use this account and its password to configure your WSUS vDIR's in IIS.
HTTP 401.2: DENIED BY SERVER CONFIGURATION
If you are getting a 401.2 HTTP error it will steer you in the direction of looking at IIS configuration once again. Most often you will have to review your IIS webservices for WSUS and look at the Authentication Configuration that has been set for them. Make sure they are configured as per the above table named * WSUS website IIS webservices configuration. Look at the properties of a webservice >>Directory Security tab >>EDIT (Authentication and Access Control), and make sure they are set as explained in the above table named: * WSUS website IIS webservices configuration.
Source:
www.technet.microsoft.com
Published by
S.G.Godwin Dinesh.MCA
Sr.System Administrator
In GPO Management (or Active Directory Users and Computers), make sure the WSUS GPO is created and linked to the OU that contains the machines that is suppose to get the GPO settings for WSUS. Open up the GPU to:
Computer Configuration > Administrive Templates > Windows Components > Windows Update
As a minimum we have to enable 2 settings:
- "Configure Automatic Updates"
- "Specify intranet Microsoft update service location"
The above is the minimum needed in any GPO for WSUS to function.
Permissions:
We have 2 types of permissions to be concerned about: NTFS permissions on the WSUS Server as well as IIS permissions and security. Sometimes if these permissions are not correct it prevents the WSUS webservices in IIS from functioning correctly and thus WSUS clients can not report in.
HTTP 401.3: DENIED BY RESOURCE ACL:
Frequently if your WSUS client (Automatic Update Agent) is healthy and your GPO is offering the correct WSUS server and port information and you still do find that WSUS client are not reporting into the WSUS console, then permissions on the WSUS server are most likely the problem.
It is not always NTFS security that is the problem, but could be IIS permissions. If you are outright getting a 401.3 error you know to focus on NTFS permissions. But, I recommend to always run Process Monitor when you start troubleshooting WSUS to make sure WSUS has all the permissions it needs on the file system and in the registry.
On the WSUS server, download Process Monitor from. Follow the following steps:
1) Go to http://technet.microsoft.com/en-us/sysinternals/default.aspx
2) Look on the right-hand side and download "Process Monitor" (AKA: PocMon)
3) Extract it on the WSUS server and run "procmon.exe"
4) Click on "Filter" >>"Filter"
5) Set "Display Entries Matching These Conditions" to:
- RESULT - CONTAINS - DENIED (you have to type in the word DENIED) then INCLUDE
6) Click "Add"
7) ALSO Set "Display Entries Matching These Conditions" to:
- PATH - CONTAINS - CERTIFICATE (you have to type in the word CERTIFICATE) then EXCLUDE
8) Click "Add", "Apply" then OK
9) Stop and Start the "World Wide Web Publishing" Service
- Wait 30 seconds
10) Stop and Start the "Update Services" Service
- Wait 30 seconds
11) Go back to ProcMon
This filter will show all processes that issues an ACCESS DENIED event. For the most part your concern is to look at both W3WP.EXE (which is IIS) as well as both WSUSSERVICE.EXE and SQLSERVR.EXE.
Notice any ACCESS DENIED events and see if they were denied to a registry key or a file on the file system for the 3 above mentioned services. If you find any ACCESS DIENIED for any of the above processes denying the user account "Network Service" access, that registry key or file would need permissions set to allow the "Network Service" to have FULL CONTROL to the respective Registry Key or File. Give the permissions accordingly and keep track of the changes you make. Once you have assigned a permission, close ProcMon, run it again and see if the permission error comes up. By doing this you will make sure WSUS has all the NTFS permissions it needs to function.
** ALWAYS BACKUP YOUR REGISTRY BEFORE MAKING ANY CHANGES **
NOTE: To close ProcMon.exe properly, click on FILE >> (Uncheck) CAPTURE, then FILE >> EXIT
Some common files/folders for WSUS that needs to be confirmed that they have FULL CONTROL set for the "Network Service" account are:
- <%windir%>\Microsoft .NET\Framework\
\Temporary ASP.NET Files - <%windir%>\Microsoft .NET\Framework\
\CONFIG - <%windir%>\Temp
- C:\temp
- C:\WSUS\WSUSContent
- C:\Program Files\Update Services\WebServices
In addition to NTFS permissions occasionally being incorrectly set for WSUS, from time-to-time we find IIS permissions being incorrect or out of sync. Ensure that IIS Virtual Directories (vDir's/webservices)) are set as shown below:
After you have confirmed the security and had to make a change to it in IIS, remember to do a IISRESET. If there are other websites on the server in addition to WSUS, do a stop/start of the WSUS website.
Confirming your WSUS server permissions and IIS security is healthy:
Once you have made all the needed security changes to NTFS as well as IIS, re-run ProcMon a few times and ensure no ACCESS DENIED events, it is time to test the health of the WSUS server.
Look in the Application Log to see if you had prior "Windows Update Services" errors. Open a command line and run the following:
CD c:\Program Files\Update Services\Tools
wsusutil checkhealth
This will initiate a WSUS healthcheck and force events to be written to the Application log. If all of the security changes you made earlier rectified the health of WSUS you should see no "Windows Update Services" errors. If the issue you were having were security related, most often prior to start fixing the issues you would have seen the following Event ID's: 12052, 12042, 12022, 12032, 12012 and/or 12002.
Re-run Procmon (with the same 2 filters we added before) and re-start IIS wait 30-seconds then re-start the "Update Services" service. If ProcMon still gives no more ACCESS DENIED events other than the CERTIFICATE events, you would have to look into resetting the IIS IUSR account.
How to identify what HTTP 401.x error you might be experiencing:
When we troubleshoot WSUS clients that are not reporting into the WSUS server we frequently might be experiencing a HTTP 401.x error. There are 2 ways to see which 401 error you might be having 401.1, 401,2, etc. One way is to open one of the URL's below from the WSUS-client and see if you are getting a HTTP 401 error:
- http://servername/SimpleAuthWebService/SimpleAuth.asmx
- http://servername/selfupdate/wuident.cab
- http://servername/clientwebservice/susserverversion.xml
- http://servername/content/
/
2009-01-27 16:45:10 W3SVC310782280 10.10.1.10 HEAD /selfupdate/wuident.cab 0901271645 8530 - 10.10.1.43 Windows-Update-Agent 401 1 0
Above you can see an HTTP 401.1 being generated on the SelfUpdate webservice.
HTTP 401.1: DENIED BY INVALID USER CREDENTIALS:
This error code will have you focus on the credentials of the IUSR account. If you are receiving a 401.1, from a WSUS perspective it means we have to go and look at IIS to make sure the IUSR username and password is correct for Anonymous access on all the WSUS vDir's. Occasionally the IIS guest account (IUSR_ account) has it's password out of sync between the IIS Metabase, Active Directory OR SAM (depending if the IUSR account is a local or domain account) and the credentials entered as the Anonymous user and password for the WSUS Virtual Directories in IIS. We need to make sure that the correct user account and credentials are used at 3 places:
- In Active Directory or Local Account.
- In the IIS Metabase.
- In IIS for each of the 9 WebServices under the "WSUS Administration" (or Default) Website.
Edit c:\Inetpub\AdminScripts\ADSutil.vbs
Search for the line that reads "IsSecureProperty = True" and change it to "IsSecureProperty = False". Save and close the file.
From command line run:
Cscript adsutil.vbs get w3svc\anonymoususerpass
This will return an output like this:
anonymoususerpass : (STRING) "ThisIsTheIUSRaccountPassword"
Take note of the password, INSIDE of the quotes. The quotes are not part of the password. For safety, copy it into notepad.
Go to either Active Directory (if a domain account is used for the IUSR account) or find the LOCAL ACCOUNT for IUSR. In most cases IUSR will be a local account. Reset the password for your IUSR account with the password we just pulled from the IIS Metabase.
Open IIS Manager and expand the WSUS (or default) website where the WSUS Virtual Directories are located. Right-click on the vDir >>Properties >>Directory Security >>EDIT. Update the IUSR account with the password we pulled from the IUSR Metabase. Do this for each of the below vDir's:
- ClientWebService
- Content
- DSSAuthWebService
- Inventory
- ReportingWebService
- ServerSyncWebService
- SimpleAuthWebService
- SelfUpdate
IMPORTANT: If WSUS is the only website on your server you will be safe to reset the IUSR account. If it is not the only web application running on your server, consider copying the old IUSR account and create a new account called something like IUSR_WSUS and use this account and its password to configure your WSUS vDIR's in IIS.
HTTP 401.2: DENIED BY SERVER CONFIGURATION
If you are getting a 401.2 HTTP error it will steer you in the direction of looking at IIS configuration once again. Most often you will have to review your IIS webservices for WSUS and look at the Authentication Configuration that has been set for them. Make sure they are configured as per the above table named * WSUS website IIS webservices configuration. Look at the properties of a webservice >>Directory Security tab >>EDIT (Authentication and Access Control), and make sure they are set as explained in the above table named: * WSUS website IIS webservices configuration.
Source:
www.technet.microsoft.com
Published by
S.G.Godwin Dinesh.MCA
Sr.System Administrator
No comments:
Post a Comment