Первым делом я захотел выяснить какое из используемых нами приложений производит эту дополнительную нагрузку. Для этого я попробовал вынести все приложения в отдельные виртуальные каталоги, задав для каждого отдельный пул приложений, они же Application pool (для каждого пула приложений используется отдельный процесс w3wp.exe), попутно определяя какой из процессов к какому пулу относится. Сделать это можно довольно просто при помощи утилиты Sysinternals Process explorer. Для этого достаточно зайти в свойства процесса (при этом подсказкой может служить то, что приложения написанные при помощи ASP.NET будут подсвечены жёлтой строкой), и на вкладке Image посмотреть строку Command line, из которой видно, что название пула приложений передаётся процессу w3wp.exe через параметр «ap». Так например команда запуска для пула приложений с именем «dotnet4» будет выглядеть так:

c:\windows\system32\inetsrv\w3wp.exe -a \\.\pipe\iisipmceXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX -t 20 -ap "dotnet4"

Впоследствие эти действия оказались по большему счёту бесполезными, но умение определять нужный процесс w3wp оказалось впоследствии полезным и мне и нашим разработчикам выполняющим удалённую отладку в Visual Studio.

Отличным инструментом позволившим решить мою проблему оказалось приложение IIS Tracer, от компании Motobit Software. Для быстрой отладки сервера достаточно пробной 60 дневной версии, которую можно загрузить на сайте производителя. Данная программа позволяет наблюдать за состоянием IIS в режиме реального времени. Настройку можно осуществить как при помощи текстового файла конфигрурации, так и графической утилитой, входящей в инсталляционный пакет. После установки программа будет доступна (если вы не меняли настройку Config script) по адресу http://your-site-address/iistracer. По этому адресу, кроме всего прочего, можно увидеть какие запросы клиентов выполняются в данный момент, их состояние и длительность обработки запросов сервером. Именно эта информация позволила мне обнаружить скрипт выполнявшийся вплоть до истечение таймаута, потребляя непомерное количество ресурсов. Скрипт оказался ответственнен за отправку комментариев на форум. При ближайшем рассмотрении было обнаружено что форум разрешал отправку анонимных комментариев в нескольких местах, чем и воспользовались спаммеры, постоянно пытавшиеся использовать этот скрипт. После закрытия возможности отправки анонимных комментариев и удаления нескольких тысяч записей спама в базе сервер вернулся в своё обычное состояние и проблем с производительностью больше не возникает, а как бонус пользователи были избавлены от спама.

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

Использование стандартных элементов управления не только позволяет очень быстро реализовывать пользовательские интерфейсы, но и влечёт за собой наследование всего стандартного функционала, являющегося частью операционной системы. Так неактивность какого-либо элемента является всего-лишь флагом стиля этого элемента. Справка по WinAPI говорит что состояние окна неактивно является следствием выставления флага WS_DISABLED, тут же в справке говорится что для удаления этого стиля необходимо использовать функцию EnableWindow. В качестве параметров эта функция принимает хендл окна или элемента управления (являющийся глобальным) и логическое значение отвечающее, собственно, за включение/отключение элемента. Таким образом мы видим, что функция носит глобальный характер и не выполняет никаких хакерских действий. Такой механизм был создан ещё во времена Windows 2000 и работает по сей день. Тут надо сделать оговорку, что выполнять такие действия пользователь может только с запущенными от его имени процессами, но и с этими процессами можно выполнить множество вредоносных действий.

Таким образом любой пользователь при помощи нехитрых утилит (например являющихся частью Visual Studio или InqSoft Window Scanner) пользователь может активировать функциональность, защищённую только посредством дезактивации элемента управления. В этом случае если при проектировании и создании приложения данная особенность не учитывалась, то у злонамеренного пользователя появляется возможность выполнить некоторые привилегированные действия. Какие – зависит уже от конкретного приложения.

Так например непривелигированный пользовательй службы терминалов Windows Sever 2003 может активировать неактивный по умолчанию для него переключатель “Отображать процессы всех пользователей” в Диспетчере Задач и успешно просмотреть процессы других пользователей (завершить правда он их не сможет, по причине дополнительных проверок прав при попытке закрытия процесса). Данный пример не показывает всей глубины проблемы, но вот следующий пример более нагляден.

Ещё одним примером уязвимой архитектуры может служить Kaspersky Anti-Virus 6.0 for Windows Workstation, входящий в состав Kaspersky EnterpriseSpace Security. С помощью политики устанавливаемой централизованно возможно запретить пользователям самостоятельно останавливать защиту ПК, но при этом такой запрет осуществляется только посредством деактивации флага отвечающего за работу защиты. При помощи указанных выше утилит, совершенно любой пользователь может сделать элемент управления активным и отключить антивирусную защиту своего ПК, а это уже намного более серьёзная брешь в безопасности, по сравнению с просмотром списка чужих процессов.

Надеюсь в ближайшем будущем производители ПО займутся исправлением этого архитектурного недостатка.

Большинство советов в Интернет советовало попробовать дать право, на исполнение файла someprogram.exe, пользователю Internet Guest Account (IUSR_ИМЯСЕРВЕРА). Однако этого оказалось недостаточно и ошибка не пропадала. После изучения поведения программы при помощи Process Monitor оказалось, что PHP также не хватает прав на командный интерпритатор cmd.exe. После добавления пользователя Internet Guest Account (IUSR_ИМЯСЕРВЕРА) в список доступа cmd.exe скрипт получил доступ к программе и ошибка исчезла.

Live Mesh предоставляет следующие сервисы пользователям.

Хранение файлов в облаке.

Пользователю предоставляется в пользование 5 Gb свободного места на Интернет серверах,  для хранения практически любых файлов (исключения составляют файлы с расширением используемым для пометки временных файлов таких как bak, tmp, а также системные файлы Windows). Файлы хранимые вами в облаке Live Mesh никак не проверяются и не имеют ограничений, что имеет 2 стороны: с одной стороны вы можете быть уверены, что никакой из ваших файлов не пропадёт во время закачки/синхронизации, с другой стороны этот сервис может стать ещё одним способом распространения вирусов.

Доступ к хранимой в облаке информации возможен как при помощи включения желаемого устройства в вашу сеть синхронизируемых устройств, так и более простым способом: при помощи Live Desktop, который доступен на любом копьютере с браузером. На данный момент Live Desktop позволяет производить манипуляции с файлами (добавление, удаление, скачивание на локальный компьютер) и просматривать некоторые типы медиа файлов (MP3, JPG просматриваются без проблем).  Для просмотра медиа файлов необходим плагин SilverLight для вашего браузера.

Синхронизация файлов между устройствами

Следующим пунктом идёт возможность синхронизировать файлы между любыми устройствами. Производить это можно как в режиме он-лайн, в этом случае можно не производить синхронизацию с облаком, так и в режиме оффлайн – просто укажите, что одним из синхронизируемых устройств будет ваше облако – Live Desktop (что впрочем сделано по умолчанию). В качестве клиентов сети Live Mesh могут выступать PC с ОС Windows 32 и 64 бита, Macintosh находится на данный момент в стадии CTP, поддержка Windows Mobile ожидается в будущем.  Для всех неподдерживаемых устройств доступ осуществляется через Live Desktop.

Совместное использование файлов

Для всех файлов хранящихся в облаке существует возможность настраивать списки доступа для пользователей. Существует три типа пользователей: Owner (Имеет полный доступ к файлам и имеет возможность управлять пользователями), Contributor (Имеет полный доступ к файлам), Reader (Доступ к файлам только для чтения) доступных для назначения и тип Creator (Может создавать, считывать, обновлять и удалять файлы; управлять доступом для пользователей а также настраивать параметры синхронизации) устанавливаемый по умолчанию при создании папки в Live Mesh. Существует возможность ведения ленты комментариев к любой директории Live Mesh, что хорошо подойдёт, например, для обмена впечатлениями о фотографиях размещённых при помощи данного сервиса.

Удалённое администрирование/доступ к ПК

Одной из замечательных возможностей Live Mesh является возможость доступа к рабочему столу любого из ваших устройств под управлением ОС Windows. Доступ возможен как при помощи специального клиента Live Mesh Remote Desktop, так и при помощи ActiveX компоненты для Internet Explorer. Несомненное преимущество этого решения является гибкость при поиске маршрута от точки управления до точки подключения. В случае если возможно прямое подключение (оба компьютера имеют белый IP адрес, или же находятся в одной сети с серым IP адресами), соединение производится традиционно как в случае VNC или же RDP. В случае же, если прямое соединение не возможно (компьютеры имеют серые IP и находятся в разных сетях, например за 2 различными NAT), соединение происходит многоступенчато с использованием серверов Microsoft. Происходит это абсолютно прозрачно для пользователя и единственная разница, которую может заметить пользователь – это немного более длительное время соединения с устройством. При входе нужно будет пройти аутентификацию пользователя средствами ОС. На время вашего вашего соединения доступ к ОС будет заблокирован.

Это основные заявленные на данный момент возможности Live Mesh. В последующей серии статей я постараюсь рассмотреть их исопользование более подробно.

Присоедениться к открытой программе Beta-тестирования Live Mesh Вы можете на официальном сайте www.mesh.com

HKLM\SOFTWARE\Microsoft\Update Services\Server\Setup\wYukonInstalled

значение 0 (ноль), а также переименовав папку UpdateServicesDbFiles, я смог без проблем удалить и установить заново WSUS.
Надеюсь данное решение поможет кому-нибудь сэкономить время на поиск решения в случае поломки WSUS.

@echo off

setlocal

rem Subversion sends through the path to the repository and transaction id
set REPOS=%1
set TXN=%2

rem check for an empty log message
svnlook log %REPOS% -t %TXN% | findstr . > nul
if %errorlevel% gtr 0 (goto err) else exit 0

:err
echo. 1>&2
echo Your commit has been blocked because you didn’t give any log message 1>&2
echo Please write a log message describing the purpose of your changes and 1>&2
echo then try committing again. — Thank you 1>&2
exit 1

Пример взят скрипта взят в блоге Anuj Gakhar.

Для корректной загрузки по сети в настройках вашего DHCP сервера необходимо указать 3 опции:

1. Next Server – тут должен быть указан следующий сервер участвующий в сетевой загрузке, так написано в RFC-2131.  Тут необходимо указать IP адрес нашего WDS сервера. Тут я при настройке совершил ошибку и долго искал данную настройку в стандартных опциях DHCP.  Данная настройка является, опцией самого DHCP сервера и не входит в стандартные опции.
2. DHCP option 66 – имя TFTP сервера, на котором находятся образы загрузки. Тут по-умолчанию необходимо указать имя нашего WDS сервера (и конечно же сам DHCP сервер обязан отдавать корректный DNS-сервер).  Тут можно использовать альтернативный TFTP сервер и я видел несколько статей в Интернет, где это использовалось, например, для ведения логов подключения клиентов.
3. DHCP option 67 – путь к загрузочному файлу отдаваемому клиенту сервером загрузки. Эта опция является константой и должна быть равной «boot\x86\wdsnbp.com»

Так же я видел сообщения о том, что необходимо установить стандартные настройки № 43 (Специфичная информация от производителя) =»010400000000FF» и 60 (Идентификатор класса производителя)=»PXEClient», но моя инсталляция заработала и без этих настроек.

Более подробную информацию о взаимодействии WDS с DHCP можно почерпнуть по следующим адресам (англ):

http://nssadoc.blogspot.com/2008/06/differential-analysis-wds-dhcp.html

http://nssadoc.blogspot.com/2008/06/revisit-differential-analysis-wds-wds.html

Для развёртования WDS нам понадобятся:

1. Сервер на котором находится WDS, должен быть либо членом Active Directory, либо контроллером домена. При этом версия Active Directory не имеет значения.
2. В сети должен быть DHCP сервер, в случае использования DHCP от Microsoft процедура установки и настройки упрощается, но можно использовать и DHCP сторонних производителей
3. Так же необходим DNS сервер
4. Образы из которых мы будем устанавливать систему должны храниться на разделе NTFS.
5. Для установки самой роли, нам будут необходимы права локального администратора на сервере который будет выполнять роль WDS
6. Windows Automated Installation Kit for Vindows Vista и файл boot.wim с установочного диска Windows Vista. Так же можно использовать Windows Automated Installation Kit for Windows 7 и файл boot.wim из дистрибутива Windows 7, но в этом случае необходимо помнить, что утилита wdscapture.exe находится не в образе WinPE, а в образе boot.wim.

После проверки что у нас установлено всё необходимое для добавления роли можно начинать процедуру. Заходим Пуск->Панель Управления->Установка и удаление программ->Установка компонентов Windows (Start->Control Panel->Add or Remove Programm->Add/Remove Windows Components) и там выбрать Windows Deployment Services.

Установив роль, можно запустить оснастку Windows Deployment Services, которая является основным инструментом работы с WDS.  После первого запуска в группе серверов наш сервер будет показан с предупреждением о том, что он до сих пор не сконфигурирован. Конфигурация WDS предельно проста:

1. Выбираем место, где будут храниться наши образы, используемые WDS.
2. Так как в своей инсталляции я использовал альтернативный DHCP сервер (встроенный в файерволл D-Link DFL-800), то галочки связанные с DHCP я не устанавливал.
3. Выбираем режим в котором WDS будет отвечать на запросы сетевой загрузки (всем клиентам, никому, только разрешённым)
4. Выбираем хотим ли мы добавить образы в WDS немедленно, после чего начальную настройку можно считать завершённой.

Попытался узнать версию Powershell в свежеустановленном Windows Server 2008 R2 методом найденном в Интернет.

Powershell Version

Безусловно радует то, что это вторая версия Powershell. Это вам и красивый отладчик, и Remotings, и многое другое. Но не могу не придраться к тому, что в финальной версии так и не убрали признак CTP выпуска.