IE 6,7,8

Гром таки грянул. Сколько пришлось попариться для того, чтобы обновить IE на компьютерах домена до версии выше, чем 6 - почти все напрасно. Выяснилось, что один из компонентов используемого бизнес-приложения стабильно работать может только в версии 6. Во всех других он может завесить браузер намертво, что приводит к лишнему расстройству, потери набранных в форму данных (браузер нужно будет перезапустить без сохранения состояния). В общем, обещается много-много неприятного. В связи с чем встал вопрос - как бы версии 7+ снести с порядочного количества компьютеров максимально быстро и по возможности без лишних телодвижений и звонков. Немного ковыряния в предметной области показало, что у приложения Windows Internet Explorer 7/8 есть так называемая строка деинсталляции (в общем и целом, эта строка есть почти у всех продуктов, которые прописываются в апплете "Установка и удаление программ"). Оно и понятно, системе ведь нужно что-то запускать для процесса удаления ненужного приложения.
Что ж, это радикально меняет дело. Строка известна, стало быть нам нужен еще один скрипт, который будет запускаться на нужных компьютерах. В итоге получается следующий vbs-файл:

'Internet Exploer 7,8 Uninstallation
on error resume next
Set WshShell = CreateObject("WScript.Shell")
'Uninstall IE 8
WshShell.Run "C:\WINDOWS\ie8\spuninst\spuninst.exe /quiet /norestart",1,true

'Uninstall IE 7
WshShell.Run "C:\WINDOWS\ie7\spuninst\spuninst.exe /quiet /norestart",1,true

Вот такой небольшой сценарий.
Последний момент - после удаления всех старших версий компьютер нужно перезапустить. Проблема в том, что пользователи на это чаще всего забивают. Что делать? Выход прост - этот скрипт нужно выполнить в момент завершения работы компьютера.
Таким образом получаем довольно простой сценарий: групповая политика, область действия - выбранные компьютеры (а они известны), параметры политики - Shutdown sсript, именно туда нужно будет подставить указанный выше сценарий. Дело за малым, перезагрузить машины - и задача выполнена.

@музыка: Clannad - From Your Heart

@настроение: Scripts are my best friends

@темы: Scripting

---

Support

Есть на этом свете славная компания HTC, выпустившая немало славных коммуникаторов. Дорогих и не очень, навороченных, и менее функциональных. WM-based и Android-based. Вот о последних речь и пойдет.
Недавно возникла задача - подключить коммуникатор сотрудника (HTC Hero) к корпоративной почте. Все бы ничего, но при проверке соединений используется самоподписанный сертификат. Знающие люди поймут сразу, о чем сыр-бор, а для незнающих поясню. Дело в том, что таким сертификатам не доверяет ни одна система. Даже та, которая этот сертификат и подписала для себя. И для того, чтобы она стала ему доверять, корневой сертификат центра сертификации (сорри за тавтологию), должен быть напрямую импортирован в систему. Тогда последняя начнет доверять этому корневому, а следом за ним и всем сертификатам, которые этот корневой подписал.
Чем это неудобно для владельцев коммуникаторов. Эти устройства при обнаружении самоподписанного сертификата просто отвергают соединение с выводом сообщения об ошибке. WM-based коммуникаторы "пролечиваются" очень просто - сертификат копируется на них в их файловую систему, после чего в стандартном Проводнике добавляются в хранилище сертификатов. Все, устройство готово к работе.
В случае Android-based устройства (коим и является HTC Hero) получили самый настоящий геморрой. Дело в том, что у данной конкретной модели просто НЕТ Проводника или любого другого метода просмотра файловой системы. Можно обратиться к музыке, к картинкам, но только через соответствующие программы. Они работают на основе каталогов, которые сами же и составляют. Всякий, кто работал с библиотекой Windows Media Player - меня поймет. Но сертификат, лежащий на карте памяти телефона - это не картинка, не музыка, даже не какой-либо офисный документ. И никакая программа из поставляемых "в коробке" его не видит.
В интернете лежит куча шаманских методов сертификата, но 100%-но работающего нет ни одного. В итоге решил, как самый обычный пользователь обратиться в поддержку компании HTC, благо, на сайте есть специальная веб-форма. По логике вещей, уж компания-производитель должна что-то дельное подсказать. Сказано - сделано, написал, нажал кнопку отправить, и стал ждать. Дождался, ниже привожу запрос и ответ. Это феерия!

Запрос
Добрый день. Хотелось бы уточнить, каким образом можно настроить телефон HTC Hero так, чтобы он доверял самоподписанному сертификату Exchange, используемом в организации. В настоящее время телефон при попытке доступа к серверу через защищенное соединение выводит сообщение о том, что сертификат не является доверенным, и предлагает либо продолжить, либо отменить соединение. При продолжении снова появляется окно о недоверенном сертификате, и так повторяется бесконечно.
В общем случае для решения проблемы нужно импортировать на устройство корневой сертификат, но как это можно сделать на данном телефоне?
Заранее благодарен за ответ.

Ответ
Добрый день!
Спасибо за обращение в HTC.
Коммуникатор на базе ОС Android автоматически прописывает сертификаты. Если Ваш аппарат показал извещение об ошибке сертификата, то обязательно выбирайте пункт "продолжить" и коммуникатор загрузит нужные данные.
Пожалуйста, обратите ваше внимание, что вы можете также связаться с нами по телефону.Для более детальной информации пожалуйста перейдите по ссылке www.htc.com/uk/CA_Hotline.aspx
С уважением, НТС.

Если честно, после подобного ответа у меня не остается никакого другого выбора кроме закрытия запроса. И заодно я уверился во мнении, что если даже когда-то и приобрету себе смартфон, это не будет Android-based.

@темы: Этот безумный мир, Android

---

Oneliners

Oneliner - сценарий, состоящий из одной строки (one line). Их удобство в том, что для решения какой-то задачи достаточно открыть консоль, набрать нужную команду, запустить ее на выполнение и получить результат. Нет необходимости писать текст скрипта, сохранять его, затем писать команду на вызов этого сохраненного файла. Все просто.

Недавно понял, что нужно привести в порядок в нашем домене ограничения на максимальный размер передаваемого через почту сообщения. У кого-то стоит одно, у кого-то другое, у некоторых вообще десятое. Это неправильно. Два параметра (размер входящего письма и размер исходящего письма) хранятся непосредственно в записях Active Directory, следовательно, вытащить их достаточно просто. Вариантов довольно много, но в итоге я остановился на Powershell и его сторонней оснастке Quest Management Shell. Quest - это отдельный набор команд, облегчающих работу с Active Directory и делающих ее более прозрачной, чем обычные команды Powershell. Сами параметры зовутся так:
SubmissionContLength - размер исходящего сообщения;
DelivContLength - размер входящего сообщения.

После непродолжительного чтения справки удалось набросать сценарий, шаблон которого выглядит так:

foreach ($name in get-qaduser -searchroot 'INSERT IGNORE_ROOT_OF_SEARCH') {set-qaduser $name -objectattributes @{SubmissionContLength='INSERT IGNORE_VALUE';DelivContLength='INSERT IGNORE_VALUE'}}

Пара слов о том, что он делает.
foreach - это команда, которая выполняет определенный набор действий с каждым объектом какой-либо выборки. в общем случае она записывается так:
foreach (selection) {sсriрt}
где selection - это выборка, а sсript - то самое действие (или несколько действий), которые нужно произвести с объектами выборки.
$name - переменная, хранящая в себе имя пользователя.
get-qaduser - одна из ключевых команд сценария. она вытаскивает из Active Directory полную информацию о пользователе, чье имя хранится в переменной $name
-searchroot - модификатор, задающий область поиска. Сюда нужно подставить путь к ветке в Active Directory, в которой сценарий будет искать нужного нам пользователя. Формат записи: 'OU=TestOU,DC=Domain,DC=com'

Таким образом, первая часть сценария создает выборку объектов Active Directory, у которой нужно будет сменить пару свойств. Непосредственно сменой свойств занимается вторая часть скрипта, заключенная в фигурные скобки.
set-qaduser $name - изменить параметры учетной записи, имя которой указано в переменной $name,
-objectattributes @{SubmissionContLength='INSERT IGNORE_VALUE';DelivContLength='INSERT IGNORE_VALUE'} - здесь задается, что именно меняеть, как раз те самые два параметра. Следует обратить внимание, что набор параметров заключается в фигурные скобки.

@темы: PowerShell, Scripting, MS Exchange

---

Ключи...

... от квартиры, где деньги лежат.
Нет, на самом деле речь пойдет о ключах другого рода, лицензионных. Первое, что приходится учитывать компаниям, это ключи на ОС и офисный пакет, если используется MS Office. И может сложиться такая ситуация, когда нужно быстро собрать информацию о ключах на довольно большом количестве машин. Как это сделать?
На помощь может прийти утилита под названием Produkey. Свободно распространяемое мелкое приложение, которое позволяет узнать ключи Windows, MS Office и некоторых других пакетов. Сама эта утилита содержит в себе возможность сканирования удаленных машин с целью сбора информации о лизензиях. Но есть один момент - компьютер для этого должен быть включен. Другой же вариант решения проблемы - запустить Produkey в момент запуска компьютера. Это можно сделать сценарием запуска машины.
Групповые политики, Параметры компьютера, Сценарии запуска. Сюда нужно будет положить сценарий, шаблон которого представлен ниже:

GetKeys.vbs

'Get Keys on startup sсript
'set network-based Computer name - определяем имя компьютера
Set objNetwork = CreateObject("Wscript.Network")
strComputer = objNetwork.ComputerName

'set WshShell - определяем командную оболочку
Set WshShell = CreateObject("Wscript.Shell")

'Set objFSO - определяем объект "файловая система"
Set objFSO = CreateObject("Scripting.FileSystemObject")

'set local file for output - задаем имя файла, в который будет выводиться информация о компьютере
strOutputFileName = "produkey-" & strComputer & ".txt"

'Disable Security Warning for Network Files - на время отключаем предупреждение об открытии файла из нелокального источника
set oEnv = WshShell.Environment("PROCESS")
oEnv("SEE_MASK_NOZONECHECKS") = 1

'set command to execute - определяем команду, которая и будет выполняться при запуске системы (отчет создается в корне диска С
strCommand = "\\NETWORK-SHARE\produkey.exe /WindowsKeys 1 /OfficeKeys 1 /IEKeys 0 /SQLKeys 0 /ExchangeKeys 0 /stab c:\" & strOutputFileName

'execute command - исполнение команды.
WshShell.run strCommand,,true

'set source for copiyng report - переменная с расположением файла-источника для копирования отчета
strSource = "c:\" & strOutputFileName

'set destination for report - переменная с расположением файла отчета в папке отчетов
strReport = "\\REPORTS-FOLDER-SHARE\" & strOutputFileName

'copy report and delete local file - скопировать файл в папку отчетов и удалить локальный файл
objFSO.CopyFile strSource, strReport, true
objFSO.DeleteFile strSource

'Enable Security Warning for Network Files - возобновить предупреждения об открытии файлов из нелокальных источников
oEnv.Remove("SEE_MASK_NOZONECHECKS")

Что делает этот сценарий? При загрузке компьютера из папки \\NETWORK-SHARE\ вызывается программа produkey.exe с определенным набором параметров. Результатом ее выполнения будет созданный в корне диска С: файл с информацией об установленном на компьютере ПО (в той части, которую "распознает" produkey). Далее этот файл копируется в сетевую папку "\\REPORTS-FOLDER-SHARE\", после чего из корня диска С: файл будет удален. Таким образом в папке "\\REPORTS-FOLDER-SHARE\" создается набор файлов, каждый из которых соответствует одному компьютеру. Этот набор файлов уже можно анализировать в спокойной обстановке.
Отдельно об анализе этого набора файлов. Например, требуется узнать, что творится с ключами ОС (типичная в России ситуация для нового системного администратора на предприятии). Известно, что в отчетах produkey информация об ОС идет первой строкой. Значит, задача сводится к тому, чтобы пробежать по всему набору отчетов, вытащить из каждого отчета первую строку и внести ее в файл итоговой таблицы. Эту задачу можно легко решить при помощи Powershell, например:

$ReportPath = "\\REPORTS-FOLDER-SHARE\"
foreach ($name in ls $ReportPath) {get-content $ReportPath\$name -totalcount 1 | Out-file winkeys.txt -append}

Этот нехитрый сценарий пройдет по всем файлам в папке \\REPORTS-FOLDER-SHARE\, прочитает по одной строке из каждого файла в ней, после чего результат скинет в файл winkeys.txt, находящийся в домашней папке пользователя. Работать с единой таблицей же куда проще, чем с набором файлов.

@музыка: Stone Age - Maribrengall

@темы: PowerShell, Scripting, Security

---

Спам и антиспам.

Праздники кончились, начались суровые трудовые будни.
На корпоративную почту свалилось письмо. На первый взгляд - ничем не примечательный спам. Но только на первый. Читаем содержание письма и понимаем, почему оно было пропущено всеми фильтрами:

Spam detection software, running on the system "carin.vtelecom.ru", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see The administrator of that system for details.

Content preview: Bêëaäûâàéòe â ðåkëàìó - áóäåò ìíîãî êëèeíòoâ. Ñeðèÿ èç 3 ìaññoâûõ
ðàñcûëoê (Ìîñkâa è ÌÎ BÑÅÃO çà 5.000 ðóá. PACCÛËKA ïo ëþáoìó PEÃÈÎÍÓ Ðoñcèè
- ÂÑEÃO ça 1.800 póá. Ãoðÿ÷àÿ ëèíèÿ: 92O ____ I9 _ _ 98[/cyrlat] [...]

Content analysis details: (14.7 points, 8.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
2.0 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net
[Blocked - see ]
0.9 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL
[85.15.81.128 listed in zen.spamhaus.org]
3.0 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL
3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100%
[score: 1.0000]
0.0 FH_HELO_EQ_D_D_D_D Helo is d-d-d-d
2.4 HELO_DYNAMIC_IPADDR Relay HELO'd using suspicious hostname (IP addr
1)
3.2 FH_DATE_PAST_20XX The date is grossly in the future.
0.0 DATE_IN_PAST_03_06 Date: is 3 to 6 hours before Received: date
0.1 RDNS_NONE Delivered to trusted network by a host with no rDNS
-0.4 AWL AWL: From: address is in the auto white-list

И приложение к этому письму - другое письмо с уже типичным спам-заголовком "Кризис закончился!".
Признаться, это сообщение на минуту меня ввело в ступор. Все дело в том, что приведенный выше текст - типичный ответ антиспам-системы о том, что письмо, которое вы, якобы, отправили, расценено как спам. И единственное, что мне помогло опознать в этом письме спам - адрес отправителя, потому как в реальных ответах от антиспама будет стоять назначенный адрес этой системы, но никак не сочетание букв вида [email protected].
Вывод - уж если есть необходимость проверки спама - проверять надо все, и очень внимательно.

@темы: Viruses and Spam

---

Symantec Backup Exec

Система резервирования и архивирования информации. Очень мощная, довольно удобная, но требующая серьезной доработки напильником, то есть настройки. Причем настройка процесса резервирования - это отдельная песня, а сейчас хотелось бы рассказать о вот такой напасти:
The job failed with the following error: The media operation was terminated by the user.

Приход отчета с таким диагнозом для меня стал шоком, потому что я не мог физически отменить бекап. У меня доступа к серверу в тот момент не было.
Первоначальное курение мануалов подсказало, что нужно проверить настойки автоматической отмены заданий. Проверил - ничего не включено, все по-умолчанию, то есть работать до конца. Победного или нет, другой вопрос. Что ж, придется ковырять лог более подробно.
Открываем раздел Job History и смотрим, что происходило во время бекапа. Видно, что бекап снялся, но на стадии его проверки прошел какой-то сбой:
Set Detail Information - Backup
Set type: Backup
Set status: Completed

Set Detail Information - Verify
Set type: Verify
Set status: Completed
Error: e0000602 - A query for media on which the data set being read is continued was unsuccessful. Ensure that all media in the family have been inventoried and cataloged.
Byte count: 0
bytesRate: 0,00 MB/Min
Files: 0
Directories: 0
Skipped files: 0
Corrupt files: 0
Files in use: 0

К чему это приводит? К тому, что при формировании задачи восстановления этот бекап не виден среди всех остальных. Он есть, но к нему нет доступа.
Начинаем шерстить по указанной ошибке гугл, и только гугл, яндекс по ней не знает вообще ничего (надеюсь, теперь узнает). Все ссылки ведут на форумы Symantec, где внятного ответа нет в половине случаев, а то и больше. Но из всей информации ясно одно, проблема возникает на стадии составления каталога кассеты. Предлагается сбросить эти каталоги, сказав Backup Exec'у брать информацию непосредственно читая ленты - как это сделать, описано здесь: seer.entsupport.symantec.com/docs/200962.htm Попытка выполнить эту операцию заканчивается неудачей со следующим вердиктом:
Final error: 0xe0000900 - The requested media is not listed in the media index and could not be mounted. To add the media's catalog information to the disk-based catalogs, run an inventory operation on the media and resubmit the Catalog operation.
Получается цикл, в котором я провертелся в общем и целом около месяца, что является непозволительным сроком. Что делать - непонятно. Виноваты ли кассеты, виновато ли ПО, учитывая, что оно работало, может быть всему виной и сбойный накопитель (самый паскудный сценарий). Все это время пришлось полагаться на встроенный ntbackup, который, в принципе, спасает. Одновременно прокуривал форум Symantec на наличие сходных случаев. И только в одном топике натолкнулся на комментарий сотрудника компании Symantec - "проверьте системные логи на наличие ошибок с кодами ... Они говорят о неисправности с оборудованием"
Чем черт не шутит, не питая особой надежд на то, что это поможет (сам накопитель исправен, в этом я был уверен) открыл логи приложений в самой ОС. Каково же было мое удивление, когда причина всего бардака с каталогизацией появилась прямо перед глазами:
Event Type: Error
Event Source: Backup Exec CatErrorHandler Server
Event Category: None
Event ID: 34323
Date: 26.12.2009
Time: 11:10:31
User: N/A
Computer: %servername%
Description:
Update to catalog file C:\Program Files\Symantec\Backup Exec\Catalogs\%servername%\{01F7A24D-8B4B-4F36-9FDD-E627C9FE7575}_1.fh failed.
Reason: There is not enough space on the disk.
r:\corsica\2213r\becat\beplugins\commonfh\fhbuilder.cpp(772)

For more information, click the following link:
eventlookup.veritas.com/eventlookup/EventLookup...

Вот оно! Проблема была действительно на стадии каталогизации, потому что новосозданный каталог просто не мог записаться на диск, места не хватало. Окинув взглядом папку каталогов, понял, что ее жизненно необходимо убрать с системного раздела. Перенес на другой раздел, перезапустил службы, и заставил Backup Exec перестроить каталоги по описанному выше по ссылке методу. Итогом стало то, что все бекапы, которые были сняты за период сбоев, стали доступны. Что и требовалось.

Мораль истории - даже если приложение ведет достаточно подробные логи само по себе, забывать о логах ОС не рекомендуется. Иногда они все же информативнее.
Надеюсь, эта запись поможет людям, обслуживающим Symantec Backup Exec, сберечь много нервных клеток.

@музыка: Uttara - Winter Dance

---

WSUS and SQL Server

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

@темы: WSUS

---

Ghosts

Привидения. Фантомы, оставшиеся от когда-то существовавших объектов. Подчас их искать довольно утомительно, зато интересно.
Суть ситуации в следующем. При попытке отправки приглашения на встречу через Outlook отправителю приходит уведомление, что данное приглашение не может быть доставлено одному адресату. Вся соль ситуации в том, что этого адресата никто не указывал. Если объяснить на пальцах, то получится, что приглашение было направлено людям A, B, C, D, а не получил приглашение человек Е. Дополнительный разбор полетов (просмотр логов Exchange) показывает, что вместе с основным письмом было направлено еще одно, как раз тому самому Е. Но ни одного следа этого дополнительного письма в ящике отправителя. Забавно, правда? А самое смешное, что учетной записи, куда отсылается второе письмо, уже нет в AD, и само письмо почему-то отправляется не по SMTP-адресу, а по протоколу X400.
Вроде и забавно, но когда с этим сталкивается человек из руководства, становится не до смеха. Это проблема, и ее надо решать.
На первый взгляд все банально - где-то стоит перенаправление. Стоять оно может в следующих местах:
1. Безусловное перенаправление всей почты человека в учетной записи AD
2. Перенаправление писем посредством правила Outlook.
3. Назначение представителей.

Первым делом была проверена учетная запись в AD - все чисто. В представителях тоже ничего не значится. Остается проверка правил Outlook. Заход к пользователю и просмотр правил также ничего не дал - все пусто. В чем же дело?
Ковыряние гугля в первые два дня ничего не дало, но потом все же сообразил, что запрос можно поставить иначе. Вторая же ссылка привела к нужному результату. Все дело в представителях. У Outlook есть особенность, заключающаяся в том, что он не всегда корректно отображает список представителей, даже после того, как они были удалены. В итоге проблема решается следующим образом: через AD назначается представитель, после чего открывается Outlook и уже в нем этот представитель удаляется. Это приводит к полному обновлению информации о представителях в AD и в Outlook, после чего письма привидениям исчезают, равно как и сами привидения.

@музыка: En Voice - Hall of Dreams

@темы: MS Exchange

---

Exchange 2007 CAS

Вчерашний день был из разряда "Срыв покровов". Обсуждалось расположение серверов Exchange 2007 в сети, кто и в каком сегменте сети будет стоять. В голове прочно сидит положение о том, что сервер переднего плана располагается в DMZ. Копаю материалы по установке Client Access Server, который заменяет собой сервер переднего плана. После захода по ссылке: technet.microsoft.com/en-us/library/bb232184.as... волосы встали дыбом. Да и не только у меня. Ключевым моментом статьи было следующее:

Installation of a Client Access server in a perimeter network is not supported. The Client Access server must be a member of an Active Directory directory service domain, and the Client Access server machine account must be a member of the Exchange Servers Active Directory security group. This security group has read and write access to all Exchange servers within your organization. Communications between the Client Access server and the Mailbox servers within the organization occurs over RPC. It is because of these requirements that installing a Client Access server in a perimeter network is not supported.

Проще говоря, в плане установки CAS DMZ теперь в прошлом, подобная организация сети поддерживаться самим МС не будет. А при PSS звонке первое, что будут рекомендовать - перевести CAS в доверенную сеть. Причиной тому работа CAS с серверами почтовых ящиков через RPC, динамические порты с номерами выше 1024. Так что, лучше этот момент учитывать до того, как организация на базе платформы 2007 будет развернута.

@музыка: стук клавиш

@настроение: рабочее

@темы: MS Exchange

---

Windows 2008 Server RODC

RODC - Контроллер домена в режиме "Только для чтения". Новый режим работы КД, появившийся в Windows 2008. Предназначен для установки в филиалы, где нет достаточного уровня безопасности хоста контроллера (читай, самого компьютера). Этот режим выгоден тем, что не хранит на себе пароли пользователей, за исключением специально выбранных - как правило, работников того самого филиала. Чем выгодно? В самом паскудном сценарии - краже хоста (и такое бывает), нужно будет сбросить пароли только тех учетных записей, пароли которых кэшированы на этом контроллере, а не всего домена. Удобно? Удобно.
Еще одно преимущество работы контроллера в таком режиме кроется в самом его названии - Только для чтения. Это значит, что никакие операции над структурой домена с этого контроллера невозможны, он способен только читать информацию, но не изменять ее. Случайное удаление каталогов, атрибутов в этом случае исключается. Опять же - удобно? Да.
Однако, как и довольно часто, при установке такого контроллера есть свои нюансы. Про режим работы леса в целом и отдельных его доменов я говорить не буду. Это расписано в документации по RODC достаточно подробно.
Первый и главный момент - в домене уже должен быть полный КД уровня Windows 2008 Server. Полный - это значит способный записывать информацию в Active Directory. RODC в процессе своей работы будет общаться именно с таким контроллером, на КД предыдущих версий он даже не посмотрит. Если устанавливается новый домен на базе Windows 2008 Server - это требование будет выполнено автоматически. В случае же перехода с КД Windows 2003 Server этот момент нужно учитывать.
Второй момент - перед установкой RODC ко всему лесу нужно применить команду adprep /rodcprep. Эта команда расширяет текущую структуру каталога, добавляя в нее элементы, обеспечивающие репликацию данных с обычного контроллера на RODC. Если этого не выполнить, в процессе установки будет выдана ошибка следующего содержания:

You will not be able to install a read-only DC in this domain because "adprep /rodcprep" was not yet run.

Информативность текста ошибки стопроцентная. Что делать - ясно без подсказок.
И вот тут-то кроется главный подводный камень, рассчитанный на тех, кто переходит с домена 2003 на домен 2008. Для того, чтобы установить RODC в смешанной среде (где есть и КД 2003, и КД 2008), просто выполнить adprep /rodcprep недостаточно. После ее выполнения вы будете снова натыкаться на приведенную ошибку. В документации по RODC описания подобной проблемы мне найти не удалось, решение откопалось на одном из блогов - Клац!
Интерес на этой странице представляет следующий комментарий:
Just adding a Windows Server 2008 DC to the domain doesn’t mean that you can install RODC in it too – actually you can and that’s when you will experience problems. You have to make sure that the Windows Server 2008 DC is configured (and is really functioning) as a GC and the PDC master role has been transferred to it.
Если это перевести на русский язык, то получаем следующее: простой установки КД 2008 в текущую среду недостаточно. Для получения возможности установки RODC в текущий домен на контроллер домена под управлением Windows 2008 Server нужно передать роль Глобального Каталога (GC) и роль эмулятора первичного контроллера домена (PDC Emulator). Только в этом случае установщик RODC опознает текущий домен, как удовлетворяющий всем требованиям, и согласится на установку RODC.
Как всегда - все дело в волшебных пузырьках одной волшебной галочке. Но нужно знать, где ее искать. Надеюсь, кому-то эта информация позволит сэкономить свое время на поиск решения проблемы.

@музыка: Sleepthief - World Gone Crazy

@темы: Security

---

Море между городами - по колено, океан между континентами - по пояс.

Любопытная история. Как всегда - разбор полетов письма, почему не доходит до адресата. Все началось с получения отбойника вот такого вида:
**********************************************
** THIS IS A WARNING MESSAGE ONLY **
** YOU DO NOT NEED TO RESEND YOUR MESSAGE **
**********************************************
В общем-то, все просто и понятно. Письмо задержано, повторная попытка его доставить все таки будет. Проблема в том, что письмо срочное. Выискиваем номер телефона компании, в которую это письмо улетело, и начинаем выцарапывать информацию.
Приятный женский голос в трубке сказал, что по проблеме вряд ли что сказать сможет, ибо не в курсе, но может переключить на специалиста. Ну что же, спасибо, подожду. Разговор со специалистам позабавил. Суть в том, что письмо ушло на ящик [email protected]. На что с той стороны после минутного раздумья (видимо тоже у кого-то справлялся человек, что и как) был задан вопрос: А откуда вы узнали о существовании этого адреса?
Опа! Вот что б я еще знал, откуда наш сотрудник его узнал. На том конце меня просвещают, что все электронные адреса компании имеют вид [email protected], так что можно продублировать письмо, и оно должно дойти до места назначения. Благодарность за информацию и вежливое прощание. Стороны беседой удовлетворены.
А дальше - дальше трубку к уху и вызванивать сотрудника, где и как на адрес в RU домене напали. Ответ порадовал. Девушка на телефоне в той компании, куда письмо летит до сих пор, сообщила, что можно прислать информацию на адрес %login%. А на уточнение по поводу полного адреса был получен ответ вида: "ну %login%, а после собачки - как всегда". Поскольку звонили по России, легко предположить, что и адреса будут российские. Вот и полетело письмо "на деревню дедушке Константин Макарычу".
Люди, когда диктуете кому-то электронный адрес - диктуйте его полностью. Всегда. Это может сократить кучу времени и нервов в дальнейшем.

@темы: Этот безумный мир, MS Exchange

---

IE Error

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

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

@темы: WSUS

---

Limits.

And I push her to the limit
to see if she will break.
---
(c) Pink Floyd - Take it Back

Согласно политике почта сотрудников, покинувших компанию, не удаляется. Она перемещается из оперативной базы данных в специально выделенную, это снижает нагрузку на сервер. Лимитов на почтовые ящики нет. Пока нет, скоро будут, ибо размеры оперативной базы лично меня уже пугают. Буквально вчера перемещал хороший такой ящичек на 4 Гб весом, смотрю, какие папки перемещаются, сколько писем в них. 19 с плюсом тысяч сообщений, 6 тысяч из них находятся в папке Удаленные. Хочется сказать матерно, но сдержусь. Больше всего повеселил тот факт, что последней была перемещена папка "Важное", в которой находилось всего 14 писем. 14. важных. писем. Из более чем 19 тысяч. Получается, что вся остальная масса сообщений - есть ненужный балласт. Полагаю, после такого есть, над чем подумать.
Люди, пожалуйста, если у вас нет ограничений на размер почтового ящика на работе - не стоит хранить в нем переписку буквально за все время вашей работы. Пожалейте ваших админов, пожалейте ваши серверы, пусть даже вы их никогда не видите, и они железные. Чем больше база писем, тем она медленнее и неповоротливее. Тем хуже она будет проходить резервирование, и тем больше шансы на то, что в случае краха восстановить ДЕЙСТВИТЕЛЬНО важные письма не удастся. Пожалуйста, подумайте над этим.

@темы: Этот безумный мир, MS Exchange

---

Есть компьютеры...

... а есть люди.
Хорошая статья на эту тему - Клац!. Рекомендуется к ознакомлению и осмыслению.

@музыка: Aion OST - Attack the Unsion

---

Mailflow

Слежение за тем, как ходит почта от одного адресата к другому - занятие весьма интересное. Интерес там представляют ошибки, если таковые имеются. Совсем недавно пришлось разбираться с уникальным случаем в моей практике.
Ситуация: звонок сотрудника А с сообщением о проблеме: его письма доходят до стороннего человека Б. Но когда Б нажимает кнопку "ответить" и отправляет ответ, письмо уходит в ящик сотрудника В, о котором Б не имеет никакого понятия.
Вот такая вводная, дальше идет собственно разбор полетов.
Первое - ключевыми словами здесь для меня явились Б нажимает кнопку "ответить", это действительно важно. Те, кто использовал в своей практике почтовик The Bat, и помнят, как там настраиваются учетные записи почты, меня поймут. Для непосвещенных объясню. В The Bat можно менять значение поля Reply-to. Это поле содержит в себе тот адрес, на который будут отсылаться ответы на пришедшее письмо. Если объяснять на пальцах, получится следующее:
Вы настраиваете учетку на работу с адресом [email protected], это ваш основной адрес. В поле Reply-to ставите другой: [email protected]. Все. Ответы на все письма (именно ответы), будут идти к вам на адрес [email protected], в то время как в поле From будет светиться по-прежнему [email protected].
Навскидку я не смогу придумать примеров использования этой схемы, но если ее реализовали, стало быть кому-то это было нужно.
Второе - по уверению сотрудника А, человек Б использует веб-интерфейс Яндекса.
Третье - у нас на предприятии The Bat не используется, стало быть поле Reply-to можно списывать со счетов, тем более, что по-умолчанию оно содержит в себе основной адрес, а я не помню, чтобы хоть для кого-то когда-то его меняли специально.
Четвертое - после проверки учетной записи А выяснилось, что никаких пересылок, перенаправлений и тому подобного добра не установлено. Почта ДОЛЖНА приходить в почтовый ящик А.

Что ж, проводим следственный эксперимент. Отсылаю тестовое письмо с ящика А на свой собственный, расположенный на стороннем сервере. Письмо приходит. Давлю кнопку "ответить", вбиваю "Тест" в тело сообщения, жму "Отправить". Письмо падает в ящик А, как ему и положено. Уведомляю сотрудника, что с его учетной записью все в порядке, и он может спокойно отсылать почту. А сам думаю, ЧТО было не так.
Для того, чтобы письмо попало в какой-либо ящик вообще, необходимо, чтобы в этом письме было хоть одно упоминание адреса, куда это письмо доставить надо. В тексте письма нигде ящик В не встречался, но ведь текст - это еще далеко не все.
Опять же - спасибо почтовику The Bat и его полезнейшей функции Исходное Сообщение. Знаем, помним, любим. Благо, мой сторонний ящик поддерживает эту возможность - открываю код сообщения и в поиск вбиваю адрес ящика В. Нашелся. Угадайте, где. В ПОДПИСИ СОТРУДНИКА А!
В подписи по стандарту компании указывается электронный адрес каждого сотрудника. Обычно это ссылка почтового стандарта mailto:. Как правило пользователи не в курсе, что ссылка состоит из двух частей - текста ссылки и цели ссылки. В нашем случае текстом в подписи был прописан ящик А, а целью был ящик В. После того, как это было замечено в коде письма, все стало ясно.
Вот честно, я бы очень, ОЧЕНЬ хотел посмотреть на человека Б, который утверждал, что отсылал ответ на письмо А, используя функцию "Ответить". НЕ ИСПОЛЬЗОВАЛ ОН ЕЕ, ни разу. Он тупо клацал мышкой на ссылке в конце письма от А, а ссылка, как выяснилось, была битой.
И второй вопрос - кто и как настраивал распроклятую подпись у сотрудника А? Этого узнать, к сожалению, не удалось, хотя обычно сотрудники сами себе подписи ваяют...

Выводы - при разборе полетов старайтесь как можно меньше доверять на слово пользователям. В данном случае дезинформацией были слова об использовании функции ответа, сказали бы правду о том, как письма писали - сэкономили бы время и нервы.

@музыка: Rian Farish - Breakthrough

@темы: Этот безумный мир, MS Exchange

---

PsExec

Программа PsExec является частью пакета PSTools, разработанного компанией SysInternals. Представляет собой утилитку, которая способна запускать произвольные процессы на удаленной системе, чем и полюбилась системным администраторам. Ее удобство может превзойти разве что ssh протокол. Но есть и несколько подводных камней, одним из которых является вот такая ошибка:

Error establishing communication with PsExec service on XXX:
All pipe instances are busy.

Меня эти слова преследовали полтора года. Самое удивительное, что утилита процесс на удаленной машине запускает, но результат выполнения получить не может. А чаще всего именно результат и важен. Ковыряние интернета и гугля выдало одну из возможных причин: блокирование данной программы антивирусными средствами. В целях проверки истинности предположения антивирус на целевом компьютере был снесен, после чего была выполнена чуть ли не классическая команда:
psexec \\xxxx ipconfig

Результатом стали все те же строки об ошибке. Что за дьявольщина? Затем вспомнилось, что многие антивирусы считают практически весь набор PsTools зараженным вирусом вида Remote Admin. Вирусов там нет, но сами программы как раз и являются средствами удаленного администрирования. Дальше взгляд упал на красную букву K в системном трее на исходном компьютере, после чего файл psexec.exe был внесен в список доверенных. Ошибка исчезла.

Полтора года со мной был касперский. Полтора года он меня защищал от всякой напасти. Надо сказать, хорошо защищал )

@музыка: Runestone - The Well of Secrets

@темы: Security

---

Fonts

Установка шрифтов - дело весьма нехитрое. Цапнул файл шрифта да бросил его в папку %windir%\Fonts. Только права для этого администраторские нужны, но это уже факт само собой подразумевающийся.
Уже довольно давно была поставлена задача - установить корпоративные шрифты на все компьютеры домена. Компов достаточно много, намного больше одной сотни. Что делать будем? Как что - использовать все те же групповые политики. Раскидаем при помощи сценария запуска компьютера файлы шрифтов куда надо, и дело с концом. Не тут-то было.
Есть в этом процессе одна тонкость. Для того, чтобы операционная система новый шрифт узнала, его мало просто скопировать в папку шрифтов. Сам шрифт должен быть прописан в системном реестре вот в этом ключе: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Fonts. Если установку шрифта производить при помощи Проводника Windows, все нужные записи в этом ключе создаются автоматически, а вот в случае использования сторонних утилит вида Total Commander этого не произойдет. Что делать в таком случае?
Сайт Hey, Scripting Guy! поведал о замечательной функции CopyHere, которая и позволяет запрограммировать взаимодействие с реестром ОС для установки шрифта - Клац!. В общем случае код будет выглядеть так:

Set objShell = CreateObject("Shell.Application")
Set objFolder = objShell.Namespace(FONTS)
objFolder.CopyHere "FONT-NAME"

Казалось бы, проблема решена. Почти так. Последнее препятствие - уже имеющийся шрифт. В этом случае система выкинет предупреждение, что шрифт уже имеется, и для установки его новой версии нужно снести старый. Этого хотелось бы избежать. Значит, нужно проверять наличие шрифта перед копированием его в папку %windir%\fonts. Сделать это легко:

Set objFSO = CreateObject("Scripting.FileSystemObject")
If not objFSO.FileExists (FONT-IN-SYSTEM) then objFolder.CopyHere "FONT-NAME"

Сначала смотрим, есть ли указанный файл в системе. Если нет - копируем. Если есть - оставляем его в покое.
Cобрав все в один сценарий, получаем примерно следующее:

Install Corporate Fonts.vbs

'Install Corporate Fonts.vbs
Const FONTS = &H14&

Set WshShell = CreateObject("Wscript.Shell")
Set objShell = CreateObject("Shell.Application")
Set objFolder = objShell.Namespace(FONTS)
Set objFSO = CreateObject("Scripting.FileSystemObject")

'set fonts directory
strFontsDir = WshShell.ExpandEnvironmentStrings("%SYSTEMROOT%") & "\Fonts\"

'install font
strFontFile = strFontsDir & "MyFont.ttf"
If not objFSO.FileExists (strFontFile) then objFolder.CopyHere "\\NETWORK-SHARE\MyFont.ttf"

Сценарий этот расширяем. Необходимо лишь добавлять блоки 'install font с изменением имени шрифта и пути к нему.
Остальное тривиально - групповые политики, сценарии запуска, подстановка полученного сценария, применение политики, перезапуск системы...

@музыка: Blue Stone - Take Flight

---

Runas command + Internet Explorer 7

IE 6 для администраторов был очень удобен. Тем, что если требуется запустить на клиентской машине несколько программ, от своей учетной записи, не нужно было использовать команду Runas для каждой программы. Достаточно было открыть административный сеанс IE, а в нем уже, набрав, например, С: переместиться к файловой системе компьютера. Типичное применение подобного трюка - установка новых шрифтов в систему, особенно если выгружать сеанс пользователя нельзя, а быстрое переключение выключено (доменная среда).
С приходом Internet Explorer 7 все идет к чертям. Нет, сам браузер по-прежнему можно запустить от административного логина, но возможность ходить по файлам в таком виде компания MS убрала. Зачем - неясно. Но ясен сам факт - дела обстоят не самым удобным для администратора образом.
Логично было бы поступить так: Пуск, Выполнить, и далее ввести команду:
runas /user:< MACHINE or DOMAIN NAME >\< USER NAME > explorer.exe
Но не тут то было. Эта команда не возымеет эффекта.
Решением может стать запуск какой-либо сторонней файловой оболочки, например, того же Total Commander или Free Commander. И в большинстве случаев это даже удобнее. Но есть моменты, где и этот подход бессилен - например, все та же установка шрифтов, простого копирования в каталог %systemroot%\fonts там мало, при установке через проводник происходит еще и регистрация шрифтов в реестре, тот же Тотал на такое неспособен.
Что делать?
Пуск, Выполнить, taskmgr.exe. В появившемся окне Менеджера Задач нужно перейти на вкладку Процессы и завершить процесс explorer.exe, это потушит оболочку, но оставит в фоне все запущенные пользователем программы. Далее необходимо выбрать Файл, Новая задача. А уже там вводить знакомое до боли: runas /user:< MACHINE or DOMAIN NAME >\< USER NAME > explorer.exe. В этом случае открывшееся окно проводника будет в том самом elevated-режиме, то есть с правами того пользователя, от чьего имени было запущено. При этом у нас все так же будет открыто окно диспетчера задач. Его не выключаем. После того, как все административные действия будут выполнены, нажимаем Пуск, Выйти из системы. А после выхода в имеющемся диспетчере задач через меню Файл, Новая задача снова запускаем explorer.exe, но уже в обычном режиме. Все довольны. Пользователь не потерял свои данные и программы, администратор выполнил все необходимые действия с "минимальными потерями".

Еще один вариант решения проблемы кроется в особенности установки IE 7 или IE 8 (если последний был установлен сразу поверх шестой версии). Дело в том, что седьмой и восьмой "ослики" позволяют откатиться назад на шестую версию, и ради обеспечения этой возможности копируют IE 6 в папку %systemroot%\ien, где n - текущая версия IE. И именно оттуда можно достать старый добрый шестой браузер.

@темы: Security

---

WebMarshal 6.x

Что такое WebMarshal? Это контент-фильтр, работающий в паре с прокси-сервером, хотя и сам может выступать в роли последнего. Его задача - более детальное исследование трафика, который идет в Интернет и оттуда, с целью отсечения нежелательного материала. Отличие от обычного прокси в том, что контент-фильтрация режет пользователей не только и не столько по адресам, а по содержанию тех страниц, что пользователи пытаются посетить.
Поработав немного с этой программой и вникнув в ее логику построения правил, нашел ее очень удобной, но есть одна ошибка, которая в последнюю неделю мне попортила изрядное количество крови. Суть ее в следующем.
В своей работе WebMarshal может использовать как свою собственную базу пользователей, так и базу Active Directory. Последнее весьма удобно, не нужно "плодить сущности", как многие говорят. Не буду вдаваться в тонкости организации этой структуры, перейду сразу к делу.
Если пользователь, будучи уже импортированным из Active Directory меняет свое расположение в структуре OU (организационных единиц - читай, в другую перекинули его), при следующем же сеансе обновления информации из Active Directory WebMarshal такого пользователя не найдет. Он упорно будет пытаться найти его в старой OU. Эта ситуация разобрана на самом сайте WebMarshal - вот ссылка на страницу:
Moving Active Directory users between OUs - Клац!

В статье указывается, что проблема эта была решена в версии программы 6.1.6. Не подтверждаю. Используется версия 6.1.7 - ошибка сохраняется. В качестве решения предлагается связаться с технической поддержкой WebMarshal.
Что ж, разумно. В конце концов, тех. поддержка на то и нужна, чтобы решать такие вопросы. Но ведь хочется самому понять, в чем неприятность.
А неприятность заключается в следующем. WebMarshal не работает напрямую с учетными записями в Active Directory. Он создает их реплику в собственной базе. И именно эту реплику он каждый раз обновляет во время синхронизации с Active Directory. Вот только почему-то если WebMarshal видит, что запись в AD обновлена, у себя он не изменяет существующую запись, а создает новую. И все бы ничего, но если попытаться показать список группы, которая содержит переехавшую учетку, это приведет к чтению базы из WebMarshal с ее одновременным обновлением из AD. А в базе WebMarshal будет прочитан сбойный элемент, которого в AD уже нет на старом месте. После чего программа впадает в ступор и выкидывает сообщение об ошибке.
Ручная очистка базы из консоли WebMarshal нужного результата не дает. Сбойная запись по-прежнему где-то сидит и мешает жить. Наконец, было принято решение на свой страх и риск залезть напрямую в SQL базу. Найдя там таблицу dbo.User и открыв ее, я пришел в ужас. Сколько раз была добавлена та учетка, будучи в разных OU, столько раз она и содержалась в базе, несмотря на все сеансы очистки из консоли. Дальнейшее уже тривиально. Смоделировать еще раз ошибочную ситуацию, выписать ID той записи, что сбоит, и грохнуть ее из всех таблиц, которые к этой записи могут относиться.
Согласен, метод весьма жесткий, но иногда приходится действовать и так.

UPD. Только сейчас пришло в голову, что можно и не удалять сбойную запись, а всего лишь выправить значение в поле Name, там, где указывается DN этой записи. В итоге исправление нужно будет вносить только в одной таблице. А это уже куда проще и приятнее для базы в целом.

@темы: Этот безумный мир, Security

---

Windows Update Services #5

Итак, имеем рухнувший 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