当前位置：首页 > 编程日记 > 正文

WSUS Troubleshooting guide

编程日记 2024-11-08 00:40:00

Troubleshooting guide for issues where WSUS clients are not reporting in

来自于WSUS TEAM BLOG

This guide is written to assist specifically in troubleshooting WSUS when clients are not reporting in. We will examine common troubleshooting considerations that needs to be looked at on the WSUS server only, not on the WSUS client.

GPO considerations:

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:

"Configure Automatic Updates"
"Specify intranet Microsoft update service location"

For the latter setting, often the server name is incorrect or the port number is not included. Confirm the port number in IIS and ensure it is included if it is not port 80. Example: "http://update.server.com:8530" . Remember to set the "update server" and the "statistics server" 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 [url]http://technet.microsoft.com/en-us/sysinternals/default.aspx[/url]. Follow the following steps:

1) Go to [url]http://technet.microsoft.com/en-us/sysinternals/default.aspx[/url]

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\<version>\Temporary ASP.NET Files
<%windir%>\Microsoft .NET\Framework\<version>\CONFIG
<%windir%>\Temp
C:\temp
C:\WSUS\WSUSContent
C:\Program Files\Update Services\WebServices

Permissions Related - IIS:

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:

[url]http://servername/SimpleAuthWebService/SimpleAuth.asmx[/url]
[url]http://servername/selfupdate/wuident.cab[/url]
[url]http://servername/clientwebservice/susserverversion.xml[/url]
[url]http://servername/content/<valid-sub-folder>/<valid-filename.CAB[/url]

The second way is to open the IIS Log on the WSUS server. This file is located in C:\WINDOWS\system32\LogFiles\W3SVC1. Find the log file with the most recent date. In the log file you will see references to the WSUS vDir's: APIRemoting32, Selfupdate, SimpleAuthWebservice, Content, etc. To see if you are Getting 401.x errors you must look at the complete line of the log entry. Here is an example:

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.

Ensure that the IUSR account is not locked. Sometimes a 401.1 error could be caused by a locked IUSR account. Then query the IIS Metabase to establish what the existing IUSR password is:

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

If WSUS is the only website on this server, do a IISRESET. If it is not, just stop/start the WSUS Administration website in IIS.

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.

For More Information see KB907273 - Troubleshooting HTTP 401 Errors in IIS

Justin Luyt | Senior Support Engineer

本文转自 rickyfang 51CTO博客，原文链接：http://blog.51cto.com/rickyfang/134618，如需转载请自行联系原作者

https://www.dkcj.cn/info/26533.html

WSUS Troubleshooting guide

相关文章：

在PHP语言中使用JSON

【动态规划】最长公共子序列与最长公共子串

限量！“Java成长笔记”Spring Boot/Sentinel/Nacos高并发

时区切换导致quartz定时任务没有触发问题

C#之消息队列的简要说明

Arm收购进展、元宇宙、GPU涨价……听听黄仁勋怎么说

要立刷金组flag了T_T

Centos7更改root密码

C＃实现Des加密和解密

10 行代码玩转 NumPy！

秘钥加密码的登录模式

【C#小知识】C#中一些易混淆概念总结（七）---------解析抽象类，抽象方法

关于C语言中的malloc和free函数的用法

爱购,你的最爱

「深度学习知识体系总结(2021版)」开放下载了！

自定义通知与系统通知的学习（详解）

Quick Cocos2dx 初步战斗

C#简介- 类和对象

普诺飞思获创新工场新一轮投资，加速神经拟态视觉传感技术商业化

YYHS-魏传之长坂逆袭（梦回三国系列T1）

Linux中/proc目录下文件详解

Swift常量和变量

Openpose+Tensorflow 这样实现人体姿态估计 | 代码干货

主动防病毒内容篇

icinga服务器系统监控软件的安装

size_t与ssize_t

自动驾驶中实时车道检测和警报

OSS.Core基于Dapper封装(表达式解析+Emit)仓储层的构思及实现

GNU Make chapter 2 —— Makefile 介绍

C#编写的生成缩略图程序