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: фичу надо развивать.

Опять это Сетевое окружение


 

   Уж сколько проблем возникает с Сетевым окружением не нужно рассказывать: помимо того, что часть компьютеров никак не хочет попадать в Сетевое окружение, протокол, реализующий Сетевое окружение, ощутимо загружает сеть широковещательными рассылками. Администраторы с опытом приходят к мысли, что надо рекомендовать пользователям не полагаться на Сетевое окружение, а использовать прямые линки на ресурсы и/или средства поиска AD. Тем не менее Сетевое окружение продолжает пользоваться спросом – уж больно оно наглядное и соответствует человеческой психологии. Если говорить про нагрузку на сеть широковещательными рассылками, то существует эмпирический предел в 20-30 компьютеров на сетевой сегмент: дальше надо делить сеть на сегменты разделенные роутером, например, организовывать VLAN-ы.

   С появлением Windows Vista, а сейчас Windows 7, Сетевое окружение претерпело некоторые изменения и превратилось в Network Map – совершенно иная сущность и работает не на основе протокола NetBIOS, а пачки других протоколов. Network Map это более безопасно, экономично и детерминированно, чем прежнее Сетевое окружение. Вот только как быть с компьютерами прежних версий? Варианта два: либо разрешить сервис Computer Browser со всеми недостатками присущими Сетевому окружению (для этого надо в Windows 7 включить File and Printer sharing ), либо научить XP говорить на современном языке. Да второй вариант предпочтительнее – и он реален!

   Компания Microsoft выпустила давным давно пакет обновления (KB922120) для XP, который представляет собой респондер протокола LLTD. Прикол в том, что на XP SP3 пакет этот обновления не ставится и нужен хотфикс, который надо получить по запросу!!! Но есть обходной путь в виде ручной установки http://www.tim.id.au/blog/2009/02/01/mapping-your-network-with-windows-7/ В этой же статье упоминается возможность приобщить к Network Map системы под Linux! После установки пакета обновления компьютеры XP появятся в Network Map на компьютерах Vista и Windows 7. Обратное в общем случае неверно, как я понимаю J, или все же появятся? Впрочем это не важно для тех, у кого домен: Network Map это для плоских сетей и в домене по умолчанию запрещена.

Новая фича Windows Server 2008 R2 – RemoteApp User Assignment


 

В Windows Server 2008 появилась такая интересная возможность работы с терминальным сервером как RemoteApp. Пользователь подключается к серверу, видит общий список опубликованных приложений, выбирает нужное и запускает его, работая с удаленным приложением практически также как локальным. Тут же администраторы стали задавать вопрос: а как сделать список приложений индивидуальным для каждого пользователя, чтобы он не видел приложений, которые ему не доступны. Windows Server 2008 не имел таких средств.

Но в Windows Server 2008 R2 реализовали эту фичу под именем RemoteApp User Assignment. Теперь администратор может настроить права доступа на RemoteApp приложения, и пользователь увидит в интерфейсе только те приложения, на которые он имеет права!

Подробности http://blogs.msdn.com/rds/archive/2009/06/12/introducing-remoteapp-user-assignment.aspx