WSUS — сверка списка компьютеров с AD


 

   Во многих корпоративных сетях внедрена система установки обновлений через WSUS сервер. Как правило клиенты настраиваются через групповую политику GPO. Система простая и довольно надежная. Но все же требует некоторого контроля. Вы его делаете? :-) Сейчас я предлагаю вам проверить все ли компьютеры, зарегистрированные в Active Directory, зарегистрированы на WSUS сервере: а вдруг политика не применяется к какому-нибудь контейнеру с учетными записями компьютеров или политика применяется, но компьютер не может подключиться к WSUS серверу из-за внутренних проблем или проблем с сетью?

   Текущая версия WSUS имеет API, который позволяет удаленное управление сервером. Чтобы его задействовать, необходимо установить на компьютер клиентскую часть сервера. После чего запускаем оболочку Powershell 2.0 и загружаем WSUS API:

[reflection.assembly]::LoadWithPartialName("Microsoft.UpdateServices.Administration")

   Теперь надо подключаемся к удаленному серверу по имени «WSUS»:

$wsus = [Microsoft.UpdateServices.Administration.AdminProxy]::GetUpdateServer("WSUS", $false)

   Второй параметр $false говорит о том, что будет использоваться HTTP протокол, а не HTTPS, т.е. не будет шифрования.

   Теперь получаем список всех компьютеров зарегистрированных на WSUS-сервере:

$WSUScomps = $wsus.GetComputerTargets()

   Каждый элемент массива $WSUScomps это объект, а нам нужны только имена компьютеров. Получаем FQDN имена компьютеров:

$WSUSCompNames = $WSUScomps | ForEach { $_.FullDomainName.ToUpper() }

   Перевод имени в верхний регистр не критичен (по умолчанию Powershell выполняет сравнение строк без учета регистра), но формально все же это надо сделать.

   Следующий шаг – получение списка учетных записей компьютеров из Active Directory:

$ADcomps = (new-object System.DirectoryServices.DirectorySearcher([ADSI]"LDAP://ou=DEPS,dc=DOMAIN,dc=RU","(&(objectCategory=computer)(!userAccountControl:1.2.840.113556.1.4.803:=2))")).findAll()

   Тут конструкция !userAccountControl:1.2.840.113556.1.4.803:=2 исключает запрещенные (disabled) учетные записи компьютеров. LDAP://ou=DEPS,dc=DOMAIN,dc=RU задает корень поиска в дереве AD. objectCategory=computer – выбираем только учетные записи компьютеров.

   Из объектов учетных записей компьютеров извлекаем имена компьютеров (также формально переводим их в верхний регистр):

$ADCompNames = $ADcomps | ForEach {$_.GetDirectoryEntry().dNSHostName.ToString().ToUpper()}

   И последний шаг – получаем имена компьютеров, которые есть в Active Directory, но отсутствуют в WSUS:

$NoWSUSCompNames = $ADCompNames | Where { $WSUSCompNames -notcontains $_ }

   Теперь нам остается проанализировать полученный список и разобраться почему выявленные компьютеры не получают обновления с WSUS.

Реклама

Windows 7 –новый BITS 4.0 внутри!


 

   Неожиданно обнаружил для себя, что в Windows 7 и в Windows Server 2008 R2 обновилась служба BITS – Background Intelligent Transfer Service предназначенная для фоновой передачи файлов.

   Скорее всего до конца года появятся пакеты обновления, которые установят эту версию BITS на системы предыдущих версий (XP/2003/Vista/ 2008).

   Поэтому интересно посмотреть, что это нам сулит.

   Появившийся в Vista/2008 кэш с соседями (peer caching) расширен и теперь поддерживает BranchCache. Если раньше BITS мог использовать только собственный кэш с соседями, то теперь он умеет использовать кэш BranchCache, что может позитивно сказаться на эффективности работы в сегменте сети, где включен BranchCache.

   Поддержка дополнительного дескриптора безопасности. Если раньше заданию (job) можно было назначить только один дескриптор безопасности, который использовался для доступа и к локальным ресурсам и к удаленным, то теперь можно назначить второй дескриптор: одни используется, например, для доступа к локальной папке, а второй для аутентификации на удаленном сервере или прокси.

   BITS Compact Server. Сам по себе BITS это клиент, а в качестве сервера обычно выступает IIS с серверным компонентом BITS. А как быть с несерверными, а клиентскими компьютерами? Теперь на клиентах можно поставить BITS Compact Server, который работает как сервис, базируется на HTTP.SYS и поддерживает одновременно несколько защищенных передач больших файлов. Это позволяет передавать файлы между клиентскими компьютерами. BITS Compact Server поддерживает управление через WMI, в том числе удаленное. Я думаю, вы понимаете, насколько теперь проще администратору управлять удаленными системами с помощью скриптов!

   Остается добавить, что BITS 4.0 имеет командлеты PowerShell 2.0! Теперь из PowerShell можно создавать задания BITS и управлять ими.

   Как видите BITS 4.0 значительно продвинулся фенкционально: поддерживает расширенное кэширование, а главное заточен для удаленного управления (remote management).

   Источник: http://msdn.microsoft.com/en-us/library/aa363167(VS.85).aspx

   Дополнительно: Managed Reference for BITS PowerShell Commands

image

Windows Server 2008 R2 – рендеринг в Remote Desktop Services


 

   Windows Server 2008 R2 только-только стал RTM, а уже есть обо что ломать копья. Вот например по сравнению с версией RC поменяли кое-что в Remote Desktop Services (бывший Terminal Services), а точнее в реализации рендеренга (Changes to Remoting Model in RDP 7)

   Собственно дело в том, что в предварительной версии сделали client-based рендеринг для GDI, DirectX 10.1/DXGI 1.1, Direct2D, Aero Glass experience, и media with Windows Media Player, а для WPF, Silverlight, Flash, and DirectX 9 приложений был использован host-based рендеринг.

   Различие в том, то при client-based рендеринге для оптимизации используются возможности GPU клиента, а в случае host-based рендеринга механизмы самого сервера «bitmap acceleration feature in R2».

   Так вот в RTM версии рендеринг для DirectX 10.1 / DXGI 1.1 and Direct 2D applications сделали только host-based.

   Чем это вызвало недовольство части пользователей? Дело в том, что уменьшилась возможность для масштабирования приложений написанных на новом DirectX 10.1 / DXGI 1.1 – вместо GPUs клиентов будет использован GPU сервера. Если пользователи планировали переписать свои приложения на новый DirectX 10.1 / DXGI 1.1 и запускать их на виртуальных машинах, то теперь их планы нарушены: они не смогут запустить большое количество графических приложений на сервере – он просто не потянет сотни клиентов.

   Пока разработчики RDS рекомендуют использовать на сервере специальные аппаратные графические ускорители, пользователи просят оставить фичу как хотя бы экспериментальную.

   В чем причина такого решения разработчиков? Сами они не пишут, и можно только предполагать. Видно, что для приложений Microsoft (media with Windows Media Player, Aero Glass, да еще приложения GDI) рендеренг на стороне клиента сохранен. Из этого можно сделать вывод, что механизм работает хорошо только в частном случае, но разработчикам не удалось добиться желаемых результатов для произвольных приложений, которые могут быть написаны для DirectX 10.1 / DXGI 1.1.

   Насколько все это принципиально и важно? Собственно мы имеет дело с достаточно специфическим случаем. По крайней мере пока. Большинство пользователей при работе с удаленным рабочим столом запускают не графические приложения собственной разработки, а обычные офисные приложения, которые используют GDI или для которых достаточно оптимизации графики на стороне сервера (enhanced bitmap acceleration feature in R2).

   Тем не менее ясно, что со временем число приложений DirectX 10.1 / DXGI 1.1, а особенно приложений WPF, будет стремительно расти и вопрос о рендеренге на стороне клиента станет более актуальным. Так что считаю, нам есть что сказать разработчикам RDS: фичу надо развивать.