• ↓
  • ↑
  • ⇑
 
Записи с темой: wsus (список заголовков)
10:55 

Scheduled AU in Windows 2008

В Dash'e под Chronostasis'ом.

Когда я только пришел на текущее место работы, мне рассказали много страшных историй о том, к чему приводила установка пакетов обновлений на серверы. В частности, позабавила байка о том, что после установки очередного апдейта на Exchange у пользователей слетели права на общие почтовые ящики (да, были и такие). С тех пор заплатки на серверные системы у нас ставятся исключительно руками и очень выборочно. А если уж говорить прямо - их всего 4 штуки: последний Service Pack для какой-либо платформы, и те самые три заплатки против Kido, без них уже никуда и никогда.
На прошлой неделе мне этот факт все же надоел. Проверив политику обновлений, нашел, что ее текущий вид полностью удовлетворяет моим требованиям на данный момент: уведомлять о загрузке доступных обновлений, уведомлять об установке загруженных обновлений. В этом режиме сервер никаких действий сам по себе не исполняет, а ждет команды от администратора. Таким образом я собирался по одному пройти все серверы, поставить обновления, убедиться, что функционал не нарушен. Политика в норме, осталось только на WSUS одобрить все имеющиеся обновки для серверов, чтобы последние могли их увидеть. Сказано, сделано. Было это под вечер.
На следующее утро я был шокирован. С самого начала рабочего дня поступило довольно много звонков с одной и той же проблемой - нет ни одного сетевого диска. Такая ситуация может быть обусловлена двумя факторами - сбоем в работе AD или сбоем (серьезным) в работе файлового сервера, папками которого наши сетевые диски и являются. Так оно и было, на пинги файлопомоечка не отзывалась. Спускаюсь в серверную, смотрю на экран, вижу, что scandisk уже в течение 6 часов весело проверяет на ошибки диск, лежащий на подключенной к этому серверу СХД (2 Тб данных), понимаю, что это надолго - 56% проверки индексов (и только лишь!). Прерываю проверку, перезапускаю сервер и отменяю ее на старте. Файлопомойка поднимается, пользователи довольны. Вернувшись к себе проверяю, почему файловик ушелв перезагрузку. А в голове вертится подозрение о причине. Оно и подтвердилось. Обновления. Одновременно с этим проверил мелкую файлопомойку (тоже под Windows 2008 работает), понимаю, что перезагружалась и она. Получается просто безумная картина. Политика обновлений (параметры были указаны выше) действует на все серверы вне зависимости от их платформы. Те серверы, что крутятся под Windows 2003, как им и предписано, ждут команды. А вот те, что работают под Windows 2008, решили, что политика им не указ, и стали действовать согласно базовому расписанию обновлений, каждый день в три часа ночи. Перезагрузка, если она нужна, выполняется автоматически.
Дела, однако. Причину такого их поведения я пока не выяснил, но для себя все же решил, что обновлять серверы надо. Просто НАДО. И с перезагрузкой придется мириться. Выделю им какой-либо день на неделе, и пусть веселятся.
Занимал только один вопрос - что делать с файловым сервером, который при каждом своем старте порывается проверять раздел на СХД, который он считает сбойным (да, был факт нештатного отключения). Пять минут поиска - и решение найдено:
chkntfs /x %Drive letter% - это исключит нужный нам диск из списка проверки scandisk при старте системы. Как раз то, что нужно.

@музыка: Louisa John-Krol - The Witch In The Wood

@темы: WSUS

10:38 

WSUS and SQL Server

В Dash'e под Chronostasis'ом.

Во время развертываения WSUS на сервере в филиале случилось странное - установщик выдал ошибку о невозможности продолжения и послал изучать логи. В логах обнаружилось следующее:
Error 0x80070643: Fatal error during installation
Такая ошибка обычно говорит о том, что у пользователя, выполняющего установку WSUS нет необходимых прав в базе данных, в которую WSUS будет складывать все сведения. Решение довольно простое - добавить этому пользователю роль в базе SysAdmin и повторить установку. Не тут-то было, не помогло.
При повторной установке выянсяется, что, действительно, падение происходит на стадии Configuring Databasе, стало быть, нужно смотреть и логи SQL Express. Читаю и нахожу фееричное - невозможно создать файл базы, так как он уже есть, и он используется. Стереть файл базы так просто не получится, потому что его всегда использует служба сервера баз данных SQL Server. Но можно отключить службу, тогда файл будет освобожден. Проверка состояния службы показала, что последняя действительно запущена. Для верности решаю сделать еще одну чистую установку, только на этот раз не запуская службу. Все устанавливается с пол-пинка.
Сижу, хихикаю, и много думаю... Получается, что в процессе установки WSUS сам запускает службу базы данных, но тогда как быть с тем случаем, если используется не SQL Express, как у меня, а большой SQL, службу которого просто так не остановить...

@темы: WSUS

17:17 

IE Error

В Dash'e под Chronostasis'ом.

Один из сотрудников сегодня "порадовал" ошибкой следующего содержания:
Указанный ключ соответствия не обнаружен ни в одном из активных контекстов активации.

И это при том, что буквально день назад ему был установлена совершенно свежая машина. В логах системы все чисто, ошибок больше никаких. Сеть работает нормально, все ключи на месте. Вопрос - что бы это могло быть...
Быстрое гугление результатов почти не дает. Почти, потому что все сходятся в одном, это ошибка исключительно IE, и после такого его надо переустанавливать. Переустановка! Спрашиваю, КОГДА это начало происходить? Ответ обнадежил - во второй половине сегодняшнего дня. В этот же момент взлядом выхватываю желтенький щит в панели задач. Во второй половине дня проходит установка обновлений через WSUS. А щит говорит о том, что обновления установились, но требуют перезагрузки (на что пользователи практически всегда забивают, что плохо). Перезапускаем систему, вижу, что IE обновился до следующей версии, после чего все исправно заработало.
Вывод из истории - если система говорит о том, что ей надо перезапуститься, лучше предоставить ей эту возможность.

@темы: WSUS

22:47 

Windows Update Services #5

В Dash'e под Chronostasis'ом.

Итак, имеем рухнувший WSUS. Сервис, который пользователям не виден, о котором большинство даже не догадывается, неработоспособность которого никак не отражается на жизни людей. Но чинить-то надо.
Принято решение перенести этот сервис на другой хост, выделенный. Так оно надежнее. Все подготовлено, ОС установлена, введена в домен, все необходимые сопутствующие программы и службы выставлены и настроены. Этап установки WSUS, завершение копирования файлов. Следующий этап - открытие консоли WSUS (автоматическое) и начальная конфигурация. Не тут-то было. Открытие завершается с ошибкой, предлагается открыть консоль заново и подцепиться к серверу WSUS. Выполняем рекомендации и натыкаемся на очень странную ошибку: The server may be using another port. Естественно, первым делом проверяется указанный порт, он указан верно. Для пущей уверенности лезем в настройки сайта: как был 8530, так и есть. Просмотр логов приложений дает вот такую картину:
Event Type: Warning
Event Source: ASP.NET 2.0.50727.0
Event Category: Web Event
Event ID: 1310
Date: 05/08/2008
Time: 08:06:31
User: N/A
Computer:
Description:
Event code: 3007
Event message: A compilation error has occurred.
Event time: 05/08/2008 08:06:31
Event time (UTC): 05/08/2008 07:06:31
Event ID: 3481465fab33408892a10fa495bf839f
Event sequence: 3
Event occurrence: 1
Event detail code: 0

Application information:
Application domain: /LM/W3SVC/1508003121/ROOT/ServerSyncWebService-89-128623935909687500
Trust level: Full
Application Virtual Path: /ServerSyncWebService
Application Path: C:\Program Files\Update Services\WebServices\ServerSyncWebService\
Machine name:

Process information:
Process ID: 4488
Process name: w3wp.exe
Account name: NT AUTHORITY\NETWORK SERVICE

Exception information:
Exception type: HttpCompileException
Exception message: (0): error CS0016: Could not write to output file 'c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\serversyncwebservice\00648bbe\3d8ad8e4\App_global.asax.k-otecjd.dll' -- 'Access is denied. '

Request information:
Request URL: <вырезано цензурой>
Request path: /ServerSyncWebService/serversyncwebservice.asmx
User host address: <вырезано цензурой>
User:
Is authenticated: False
Authentication Type:
Thread account name: NT AUTHORITY\NETWORK SERVICE

Thread information:
Thread ID: 5
Thread account name: NT AUTHORITY\NETWORK SERVICE
Is impersonating: False
Stack trace: at System.Web.Compilation.AssemblyBuilder.Compile()
at System.Web.Compilation.BuildProvidersCompiler.PerformBuild()
at System.Web.Compilation.ApplicationBuildProvider.GetGlobalAsaxBuildResult(Boolean isPrecompiledApp)
at System.Web.Compilation.BuildManager.CompileGlobalAsax()
at System.Web.Compilation.BuildManager.EnsureTopLevelFilesCompiled()
at System.Web.Hosting.HostingEnvironment.Initialize(ApplicationManager appManager, IApplicationHost appHost, IConfigMapPathFactory configMapPathFactory, HostingEnvironmentParameters hostingParameters)

Ковыряние Гугла на работе дало отрицательный результат (который, впрочем, также является результатом). Решения нет. Есть шаманство. У кого-то помогает простая переустановка WSUS, кто-то переставляет ASP.NET/.NET Framework, кто-то еще что-то...
В моем случае ни одна из этих мер не помогла. А помогла проверка разрешений на каталог %windir%\Temp. В том наборе разрешений, который уже имеется, было следующее:
Network Service. Уровень доступа - нулевой.
Простановка туда уровня доступа Full Access решило проблему в один миг. Да, я знаю, что полного доступа этой службе в данный каталог не требуется, но решил перестраховаться.

Итак, резюме случая.
Ошибка ID 1310 от источника ASP.NET 2.0.50727.0 - нехватка прав. Точка возникновения - каталог %Windir%\temp. Решение - простановка пользователю NETWORK SERVICE прав уровня Modify.
Всем, кто столкнулся с подобным - Hope this help. Удачи!

@музыка: Yasunori Mitsuda - Chrono Cross OST - Voyage, Another World

@темы: WSUS

21:56 

Windows Update Services #4 (продолжение банкета)

В Dash'e под Chronostasis'ом.

Итак, Client-side targetting. А если по-русски - клиент сам лезет в назначенную ему группу на сервере WSUS, а не администратор его туда определяет руками. Как этого добиться?
1. Создать все требуемые группы на WSUS. Сами они создаваться не будут.
2. При помощи групповых политик назначить компьютерам их группы.
3. Перевести сам WSUS в режим Client-side Targetting, задав еще пару параметров автоматического одобрения обновлений (немаловажный процесс, кстати).
Создание групп на WSUS - дело тривиальное, щелкай себе правой кнопкой в списке групп да имена новосозданным задавай. Переключение режима работы WSUS - не сложнее: Options - Computers - Use Group Policy or Registry setting on computers.
С назначением же групп компьютерам интереснее. Не то, чтобы процесс сильно сложен, просто нужно учитывать один момент, который из моей дырявой головы все же вылетел. Назначение групп политиками делается все там же, где и вся остальная работа с GPO домена - оснастке групповых политик. В том GPO, который регулирует механизм автоматического обновления нужно лишь включить параметр Enable Client-Side Targetting. Там же задается и имя группы, куда будут помещены компьютеры, к которым данная политика применяется. Путь к этой настройке выглядит так:
Computer Configuration, Administrative Templates, Windows Components, Windows Update, Enable Client-Side Targetting.

После того, как политика будет применена к группе компьютеров, все они во время следующего сеанса связи с WSUS переползут в определенную им группу. Все просто. А теперь о том нюансе, который важно не забыть.
Если до включения рассматриваемой настройки компьютеры уже были распределены по группам руками, а после применения оной для определенного числа компьютеров группа оказалась не заданной, то все эти сиротливые машины вовсе не останутся на своих местах (на что я, признаться, очень надеялся). Они довольно быстро переползут в стандартную группу под названием Unassigned Computers, где и будут находиться вплоть до момента назначения им какой-либо группы на WSUS. Признаться, для меня было довольно неслабым шоком, когда я увидел, что все серверы из группы Servers куда-то подевались, а на месте осталась лишь файлопомойка - она просто не успела по-тихому смыться. Пришлось политиками перетаскивать их за шкирки назад.

@музыка: Roxette - Fireworks

@темы: Этот веселый мир, WSUS, Security

21:46 

Windows Automatic Updates #3

В Dash'e под Chronostasis'ом.

Снова WSUS, будь он неладен. Хотя нет, WSUS-то как раз спокойно работает, раздает обновки и есть не просит. А вот тот самый разношерстный бардак на клиентской стороне...
Windows XP Service Pack 3, SP3 в просторечии так же, как и обычные мелкие заплатки может быть распространен посредством системы обновлений. Но поскольку эта "запчасть" весьма немалая, с ней могут возникнуть проблемы. Одна из таких, весьма неприятных, выглядит следующим образом. Клиент закачивает к себе файлы обновления, ждет условленного времени на установку. После наступления минуты "Х" начинает инсталляцию и буквально сразу прерывает ее, снова становясь в режим ожидания следующего интервала установки. В журналах при таком развитии событий пишется ошибка с кодом 0x80070005. Код этот обозначает нехватку прав.
МС написали по данной проблеме весьма подробную статью в базе знаний, вот она:
При попытке установить пакет обновления 3 (SP3) для Windows XP выводится сообщение об ошибке: "Отказано в доступе" или "Установка пакета обновления не завершена" - Клац!

Сценарий, описанный в третьем способе, сбрасывает разрешения на реестр и файлы на "заводские". Это и обеспечивает неограниченный доступ службы обновлений к нужным ей ресурсам.
Все бы ничего, но указанный скрипт некорректен для Windows XP. В нем указывается файл defltbase.inf, которого в системе просто не существует. Как быть? Поиски во всемирной сети снова дали свой результат, скрипт преобразился вот к такому виду:
Reset.cmd

Как это все запустить? Прежде всего, понадобится установочный диск с Windows XP. В дистрибутиве есть хороший набор утилит, называемый Windows Resource Kit. Устанавливаем этот набор, после чего копируем из него одну программу - subinacl.exe Именно она и является ключевым инструментом. Создаем cmd-файл, приведенный выше, сохраняем его рядом с subinacl.exe. Пакет для ремонта разрешений готов. Осталось только его запустить на том компьютере, где наблюдается проблема. Исполняться сценарий будет довольно долго, до десятка минут.

@музыка: G.E.N.E. - Faru Love Affair

@темы: Security, WSUS

21:02 

Windows Automatic Updates #2

В Dash'e под Chronostasis'ом.

Итак, после атаки Kido эту службу требуется снова поднять из пыли, отряхнуть и поставить на место. Проблема решаема при помощи принудительной установки типа запуска службы в "Автоматически". В этом случае после перезагрузки компьютера служба поднимется сама.
Easier said than done. На выходе получаем ошибку следующего содержания: Ошибка 0x80004015: Класс настроен на использование идентификатора безопасности, отличного от используемого вызывающей стороной.
После чего служба послушно становится автоматически запускаемой, но запускаться не желает, в списке служб гордо красуется надпись Stopped.
С этой проблемой я столкнулся еще ранее, как раз пытаясь службу включить принудительно, но поняв, что политика рушит функционал, просто снял ее, тем самым восстановив статус-кво. На этот раз надо все же докопаться до причины. В прошлый раз у меня на руках не было кода ошибки, теперь же он есть.
Что делать? Правильно, спросить решение у всемогущего Google. Великий и тут не подвел, ответ нашелся довольно быстро:
WU client failed to initialize with error 0x80004015 - Клац!
Если по-русски, то получается следующее.
При принудительном включении службы через доменные политики изменяется набор прав на эти самые службы. Политика по умолчанию предлагает проставить следующие разрешения:
Система (System) - полный доступ;
Администраторы (Administrators) - полный доступ;
Интерактивный вход (Interactive, читай, зашедший пользователь, не относящийся к первым двум категориям) - только чтение состояния.
Все. А на деле нужно проставить еще одну сущность, имя которой NetworkService:
В результате должно получиться:
System - полный доступ;
Administrators - полный доступ;
NetworkService - полный доступ;
Interactive - только чтение состояния.
Дальнейшее - тривиально. Определить область действия политики, подключить ее к домену и просто подождать, пока перезагрузятся системы.

Важно! Функционал автоматического обновления системы использует в своей работе две службы - Automatic Updates (Автоматическое обновление) и Background Intellegent Transfer Service (Фоновая интеллектуальная передача данных). Соответственно, принудительно включать надо их обе.

@музыка: Nickelback - If Today Was Your Last Day

@темы: WSUS, Security

Записная книжка

главная