Сага о WSUS

Я подозреваю, что мало есть компаний, в которых существуют более десяти рабочих станций с установленной Windows и хотя бы одним сервером, где не используется WSUS. Замечательный образчик софта, правда. Однако любую “замечательность” что-нибудь, как-нибудь и когда-нибудь может испортить. Если Вы – системный администратор, то этот недостаток означает для Вас необходимость начать расследование, найти решение, уткнуться в следующую проблему, избавиться от нее и все это только для того, чтобы раскопать новое приключение на свою голову.

Как Вы уже поняли, мое повествование как раз об одном таком случае из моей практики. Все началось, когда я решил создать вторичный WSUS сервер, который синхронизировал бы “одобрения” с основным. Весьма простая процедура (особенно на Windows 2008 R2), которую я оказался в состоянии проделать (включая успешную первую синхронизацию) без всяких проблем. Однако уже вторая синхронизация… Она не прошла. Event Log меня “порадовал”:

SqlException: Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection) at System.Data.SqlClient.TdsParse

Более того, начало заметно глючить саму консоль:

Это сообщение появлялось в консоли то тут, то там с все той же ошибкой в Event Log и еще одной для пущей радости:

    The WSUS administration console was unable to connect to the WSUS Server via the remote API.
   
    Verify that the Update Services service, IIS and SQL are running on the server. If the problem persists, try restarting IIS, SQL, and the Update Services Service.
   
    System.Net.WebException -- The operation has timed out
   
    Source
    System.Web.Services
        Stack Trace:
       at System.Web.Services.Protocols.WebClientProtocol.GetWebResponse(WebRequest request)
       at System.Web.Services.Protocols.HttpWebClientProtocol.GetWebResponse(WebRequest request)
       at Microsoft.UpdateServices.Internal.DatabaseAccess.ApiRemotingCompressionProxy.GetWebResponse(WebRequest webRequest)
       at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)
       at Microsoft.UpdateServices.Internal.ApiRemoting.ExecuteSPGetUpdateServerStatus(Int32 updateSources, Boolean includeDownstreamComputers, String updateScopeXml, String computerTargetScopeXml, String preferredCulture, Int32 publicationState, Int32 propertiesToGet)
       at Microsoft.UpdateServices.Internal.DatabaseAccess.AdminDataAccessProxy.ExecuteSPGetUpdateServerStatus(UpdateSources updateSources, Boolean includeDownstreamComputers, String updateScopeXml, String computerTargetScopeXml, String preferredCulture, ExtendedPublicationState publicationState, UpdateServerStatusPropertiesToGet propertiesToGet)
       at Microsoft.UpdateServices.Internal.BaseApi.UpdateServer.GetStatus(UpdateSources updateSources, Boolean includeDownstreamComputers, UpdateScope updatesToInclude, ComputerTargetScope computersToInclude, UpdateServerStatusPropertiesToGet propertiesToGet)
       at Microsoft.UpdateServices.Internal.BaseApi.UpdateServer.GetReplicaStatus(UpdateSources updateSources)
       at Microsoft.UpdateServices.UI.SnapIn.Common.CachedUpdateServerStatus.GetFreshObjectForCache()
       at Microsoft.UpdateServices.UI.AdminApiAccess.CachedObject.GetFromCache()

   at Microsoft.UpdateServices.UI.SnapIn.Pages.ServerSummaryPage.backgroundWorker_DoWork(Object sender, DoWorkEventArgs e)

(Я знаю, что в чтении такого рода нет смысла, но кто-то может прийти сюда и по поисковику )

Вот так так… Таймаут соединения с SQL на вполне приличном железе и в относительно неплохой сети? С чего бы вдруг? Спустя какое-то время и после некоторого гугления я, казалось бы, нашел решение: “просто скачайте и запустите скрипт”. К сожалению инсталлятор WSUS не устанавливает никаких средств по работе с базой данных, так что мне нужно было что-то придумать. Выставлять сиквел в сеть без особой необходимости это вовсе не то поведение, которое кажется мне лучшей практикой администрирования и я предпочитаю GUI командной строке, где это возможно (да, я ленивый сукин сын, хотя и начинал в свое время с Linux/FreeBSD), так что я решил скачать MS SQL Server Management Studio Express. Что я люблю в продуктах от MS, так это тот факт, что их инсталляция проходит в стиле NextNextNext и достаточно редко оканчивается неудачей, но только не в этом случае: я запустил мастер установки, прошел через все опции, ответил “Yes” на просьбу повысить уровень полномочий и…

Можно было бы скачать другую утилиту, но к тому моменту я решил, что мой девиз дня “никогда не сдавайся” и попытался решить и эту задачу. Решение оказалось несложным: просто запустить cmd с повышенными привилегиями и начать установку из этой консоли:

 

Теперь, имея нужную утилиту, я мог, наконец-таки, запустить скрипт, но присоединиться к базе данных? Это ведь не обычный сиквел, это Windows Server Internal Database, опыта работы с которой я толком не имел. Но и тут меня спас друг сисадмина, выдав мне строку подключения

\\.\pipe\MSSQL$MICROSOFT##SSEE\sql\query

Начиная с этого момента все было весьма несложно: скопировать скрипт, вставить скрипт, запустить скрипт. Эта задача успешно завершилась без всяких ошибок спустя некоторое время, но как Вы думаете – решила ли она проблему? Да вот “щаз”! Я все так же получал сообщения об ошибках, хотя и чуть реже.

Долго ли, коротко ли, однако я все-таки нашел решение этой проблемы: оказывается, БД наших WSUS достаточно давно не проходила очистку от мусора, так что после того, как я запустил Server Cleanup Wizard на всех серверах, проблема оказалась решенной. Вот такой вот долгий путь к победе