I upgraded one Windows Server 2008 R2 machine to Windows Server 2012 R2 the other day and had a bit hard time getting WSUS to work again. WSUS is now part of Windows Server 2012 family serving as a role, instead of a standalone software that needs to be installed separately in previous Windows.
After I successfully added WSUS as a service role to the server, I need to run the Post-installation process to complete the whole installation. And that’s where the issue started.
Fatal Error: Failed to start and configure the WSUS service
After looking at the log file indicated in the Notification window, here is what I found:
2016-12-21 10:06:27 CreateDefaultSubscription failed. Exception: System.InvalidOperationException: Client found response content type of 'text/html; charset=utf-8', but expected 'text/xml'.
The request failed with the error message:
--
<html>
<head>
<title>Could not load file or assembly 'Microsoft.UpdateServices.WebServices.ApiRemoting' or one of its dependencies. This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded.</title>
<style>
body {font-family:"Verdana";font-weight:normal;font-size: .7em;color:black;}
p {font-family:"Verdana";font-weight:normal;color:black;margin-top: -5px}
b {font-family:"Verdana";font-weight:bold;color:black;margin-top: -5px}
H1 { font-family:"Verdana";font-weight:normal;font-size:18pt;color:red }
H2 { font-family:"Verdana";font-weight:normal;font-size:14pt;color:maroon }
pre {font-family:"Lucida Console";font-size: .9em}
.marker {font-weight: bold; color: black;text-decoration: none;}
.version {color: gray;}
.error {margin-bottom: 10px;}
.expandable { text-decoration:underline; font-weight:bold; color:navy; cursor:hand; }
</style>
</head>
It took me at least one hour to finally figure it out. It’s basically the setup in Application Pools in IIS that messed things up. To fix it up, open IIS Manager, head over to Application Pool, and set WsusPool to use .Net v4.0 instead of v2.0 in my case.
Once done, I started the Post-installation again and it went all the way to the end successfully without any further issues.
On another note, there is another different error that also causes post-installation to fail.
CreateDefaultSubscription failed. Exception: System.Net.WebException: The request failed with HTTP status 503: Service Unavailable.
If that’s the case for you, all you need to do is to remove WSUS Administration site in IIS and start the post-installation process again.
That’s about it. Hopefully, it helps.
Добрый день.
После установки компонентов WSUS на Windows Server 2012 запуск дополнительных задач настройки завершается ошибкой. Вот такую картину вы можете при этом наблюдать:
“Сбой настройки. Создан файл журнала в C:\Users\..”
Открываем этот файл журнала и видим сообщение “Config file did not contain a value “ContentDirectory“. Для решения данной ошибки надо в командной строке под администратором выполнить wsusutil postinstall CONTENT_DIR=C:\WSUS , где вместо C:\WSUS указываете свой путь, где будут храниться обновления. Команда должна выполниться успешно и тогда можно запускать консоль WSUS для дальнейшей настройки. Если же и эта команда завершается с ошибкой, загляните в новый файл лога, расположения которого будет показано. Возможно там будет ошибка такого типа:
“System.Data.SqlClient.SqlException (0x80131904): Changes to the state or options of database ‘SUSDB’ cannot be made at this time. The database is in single-user mode, and a user is currently connected to it.”
В таком случае необходимо удалить внутреннюю базу данных командой uninstall-windowsfeature -name windows-internal-database, удалить роль WSUS, перезагрузить сервер и удалить содержимое папки “c:\windows\wid”. После этого можно заново устанавливать роль WSUS.
После апгрейда с Windows server 2008 R2 на Windows server 2012 R2 и повторной установки WSUS выходила постоянно ошибка, что не удается выполнить послеустановочную задачу WSUS.
Очистка диска и удаление предыдущей базы ничего не дало.
По прежнему выходило послеустановочное уведомление об ошибке.
Решение кроется в удалении сайта Администрирования WSUS в IIS.
После удаления сайта Администрирования WSUS и запуска WSUS, установка успешно завершается.
Далее запускается Мастер настройки служб WSUS, как обычно.
Выходит предложение принять участие в программе улучшения качества Центра обновления.
На следующем шаге есть возможность выбора с чего будет происходить обновление: с Центра обновления Microsoft или вышестоящего сервера WSUS.
Далее можно настроить WSUS на прокси-сервер.
Только после этого можно начать подключение.
Процесс подключения не быстрый.
Далее можно выбрать языки, для продуктов Microsoft.
На следующем шаге необходимо выбрать продукты для обновлений.
Далее выбираем классы обновлений.
Далее выбирается время, для скачивания обновлений.
Запускаем первоначальную синхронизацию.
Предлагается прочитать инструкции по дальнейшей настройке WSUS.
Все хорошо — WSUS работает.
Posted by
on February 20, 2017
This post will cover some basic methods to troubleshoot and fix common problems with Microsoft’s Windows Server Update Services (WSUS).
This post is part of our Microsoft 70-744 Securing Windows Server 2016 exam study guide series. For more related posts and information check out our full 70-744 study guide.
WSUS Server Checks
First we’ll cover some things to check and confirm on the WSUS server itself.
Check WSUS Service
The first thing you’ll want to do is check that WSUS is actually running and working as expected.
PS C:\Users\Administrator> Get-Service -name WsusService Status Name DisplayName ------ ---- ----------- Running WsusService WSUS Service
In this instance the WSUS service is reporting as running. If it’s not you can run the ‘Restart-Service -name WsusService’ to attempt to restart it. This service runs as the Network Service user by default.
Check IIS Service
Additionally we need to ensure that the W3SVC service is running which is IIS, as this is the service that actually listens for incoming connections on TCP ports 8530 for HTTP and 8531 for HTTPS. This service runs as the local system account by default.
PS C:\Users\Administrator> Get-Service -name W3SVC Status Name DisplayName ------ ---- ----------- Running W3SVC World Wide Web Publishing Service
Again if this service is not running, try the ‘Restart-Service -name W3SVC’ command to restart it. Once it’s running, we can use the netstat command to confirm that the WSUS server is correctly listening for incoming traffic on these ports as demonstrated below.
PS C:\Users\Administrator> netstat -an | findstr 8530* TCP 0.0.0.0:8530 0.0.0.0:0 LISTENING TCP 0.0.0.0:8531 0.0.0.0:0 LISTENING TCP [::]:8530 [::]:0 LISTENING TCP [::]:8531 [::]:0 LISTENING
Here we can see that our WSUS server is indeed listening on both 8530 and 8531 on both IPv4 and IPv6, so it looks good in that regard.
Check Port Connectivity
Just because the WSUS server is listening for connections on the correct ports does not mean that your client machines are able to connect in. By default Windows firewall will be running on the WSUS server, however when you installed WSUS it would have automatically configured two inbound rules called “WSUS” that allow both TCP 8530 and 8531 through, as shown below.
Check that these allowed inbound rules are still in place, and if not either enable them or create new ones as needed.
Check Log Files
Finally if everything on the server side is looking good, take a look at the WSUS log files. If you find any specific error messages here they should be detailed enough for you to perform further investigation (aka stick the error into Google).
- C:\Program Files\Update Services\LogFiles\Change.log – This file contains information about things that have changed in WSUS, it may be useful for seeing any recent changes that have taken place and caused the problem you’re having.
WSUS Client Checks
Now that we have confirmed that things look good from the perspective of the server we’ll perform some checks from the client, that is the Windows computer that connects to the WSUS server to download updates from.
Check Windows Update Service
In order for the Windows client system to actually perform Windows update, the wuauserv service should be running. If this service is not running, Windows update will not be able to run so restart it if required. This service runs as the local system account by default.
PS C:\Users\Administrator> Get-Service -name wuauserv Status Name DisplayName ------ ---- ----------- Running wuauserv Windows Update
Check Port Connectivity
As we have confirmed that the WSUS server is both listening on TCP ports 8530 and 8531 with appropriate Windows firewall rules, we will now confirm that we can connect to these from the client system. By default Windows firewall allows all outbound traffic, so by default Windows firewall on the client system should not prevent the outbound connectivity unless you’re running custom rules.
Additionally this does not cover any other firewalls that you may be running between the client and WSUS server, so check these are also configured with appropriate rules if you have them.
My favourite way to quickly test port connectivity in Windows is with the telnet client which must first be installed. Once installed it’s as simple as specifying the WSUS server and the port that you want to test, as shown below.
PS C:\Users\Administrator> telnet wsus.example.com 8530
This can be run through either Command Prompt or PowerShell. If it is successful, the screen will go blank. You can quit the telnet client by pressing the Control and ] keys, followed by typing quit and pressing enter.
For further information on how to test port connectivity, see our guide on pinging ports.
Alternatively you could also try to load the http://wsus.example.com:8530/Selfupdate/ (replacing wsus.example.com with your own WSUS server) page from a clients browser, if successful the page should just be plain white with no source. If you get some other error connecting then this may indicate a problem.
Check Group Policy
If the connectivity is looking good then you may next want to confirm the correct group policy is actually being applied to the client that is having problems updating. We can view the Resultant Set of Policy (RSoP) with the gpresult command, as shown below. The /r parameter is used to show the summary data only.
Applied Group Policy Objects
-----------------------------
Default Domain Controllers Policy
Default Domain Policy
WSUS
We can see that our ‘WSUS’ GPO is indeed applied to this client computer that we ran gpresult on.
We can take this a step further and also check that the registry entries have been set as per the GPO. In the image below we are looking at HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate which shows us the name of our specified WSUS server and target group that are set in the WSUS GPO.
Check Log Files
Finally if everything on the client side is looking good, take a look at the Windows update log files. To generate these, run the ‘Get-WindowsUpdateLog’ PowerShell cmdlet. This will write the WindowsUpdate.log file to C:\Users\<user>\Desktop\
Summary
The information here should give you some ideas of things to check when you encounter problems with WSUS so that you can fix common issues. The important things to remember are the location of the log files so that you can quickly identify what the problem actually is and then investigate further from there.
This post is part of our Microsoft 70-744 Securing Windows Server 2016 exam study guide series. For more related posts and information check out our full 70-744 study guide.
В день распространения обновлений было подмечено, что обновления не устанавливаются, хотя распространенение их было настроенно корректно. Пришлось сразу разбираться.
Первым делом были проверены Component Status в разделе Monitring консоли SCCM. Были обнаружны следущие ошибки, которые повториялись раз в час:
Component SMS_WSUS_CONFIGURATION_MANAGER
Description: WSUS Configuration Manager failed to configure upstream server settings on WSUS Server "SCCMServer".
Component: SMS_WSUS_CONTROL_MANAGER
Description: WSUS Control Manager failed to monitor WSUS Server "server-sccm2012.ab.ru".
Possible cause: WSUS Server version 3.0 SP2 or above is not installed or cannot be contacted.
Solution: Verify that the WSUS Server version 3.0 SP2 or greater is installed. Verify that the IIS ports configured in the site are same as those configured on the WSUS IIS website.
Component: SMS_WSUS_SYNC_MANAGER
Decription: WSUS Synchronization failed.
Message: WSUS server not configured. Please refer to WCM.log for configuration error details..
Source: CWSyncMgr::DoSync.
The operating system reported error 2147500037: Unspecified error
Затем был изучен WCM.log, однако, какие-то однозначные выводы сделать не удалось. На клиентских компьютерах в WindowsUpdate.log присутствовала ошибка с кодом 0x80072ee2
Дальше были изучены журналы системы и приложений. В журнале приложений с определенного момента постоянно фиксировалась ошибка:
Event ID: 1309
Source: ASP.NET 2.0.50727.0
Description:
Event code: 3001
Event message: The request has been aborted.
Event time: 11.11.2015 14:44:34
Event time (UTC): 11.11.2015 9:44:34
Event ID: dcdc2c862ba540fcbee58673db93dcde
Event sequence: 6540
Event occurrence: 2117
Event detail code: 0
Application information:
Application domain: /LM/W3SVC/1/ROOT/SimpleAuthWebService-1-130917058349967500
Trust level: Full
Application Virtual Path: /SimpleAuthWebService
Application Path: C:\Program Files\Update Services\WebServices\SimpleAuthWebService\
Machine name: SERVER-SCCM2012
Process information:
Process ID: 2112
Process name: w3wp.exe
Account name: NT AUTHORITY\NETWORK SERVICE
Exception information:
Exception type: HttpException
Exception message: Request timed out.
Request information:
Request path: /SimpleAuthWebService/SimpleAuth.asmx
User host address: 10.0.201.33
User:
Is authenticated: False
Authentication Type:
Thread account name: NT AUTHORITY\NETWORK SERVICE
Thread information:
Thread ID: 66
Thread account name: NT AUTHORITY\NETWORK SERVICE
Is impersonating: False
Stack trace:
Custom event details:
В итоге, появилось ошибочное предположение, что неработоспособное состояние WSUS оказалось следствием ошибок в IIS и ASP. В ходе поисков решения проблемы ничего дельного найдено не было. Включенный в IIS “Failed Request Tracing Rules” показал, что в результате запроса к странице
http://SCCMServer/SimpleAuthWebService/SimpleAuth.asmx, возникает ошибка:
An operation was attempted on a nonexistent network connection. (0x800704cd)
Но и это не давало каких бы то ни было зацепок для решения проблемы. После всего этого я поделилися проблемой с коллегой. Возникли новые версии и предположения. Правильным оказалось то что прблемы с базой SQL WSUS. Оказалось, что экземпляр SQL, содержащий базу данных WSUS был запущен, но не работал. В результате просто были остановлены службы SQL Server (WSUS) и SQL Server Reporting Services (WSUS) и запущены обратно. Проблема исчезла, клиенты начали обновляться.