• Powershell - Сброс SusClientId на проблемных клиентах Windows Update в домене

    imageПо мотивам борьбы с проблемой отображения в консоли WSUS некорректно клонированных клиентов, наткнулся на интересную заметку - ShS's Blog - Скрипт для удаленного сброса клиента службы Автоматического обновления. Представленный в этой статье скрипт был взят за основу и несколько переработан. В частности основные переменные были вынесены в отдельный блок, исключено использование временного файла, добавлена обработка исключения возникающего при обращении к 64-битным клиентским ОС, добавлена обработка исключений возникающих при удалении несуществующих ключей реестра, добавлен более детальный вывод хода выполнения скрипта на консоль.

    Скрипт работает в двух режимах, в зависимости от значения переменной $ResetSusClientId. Если значение переменной $ResetSusClientId = 0 (по умолчанию), - производится только сравнение данных о компьютерах полученных из AD и WSUS с выводом информации о значении ключа реестра SusClientId по всем проблемным клиентам. Если значение переменной $ResetSusClientId = 1, производится попытка сброса идентификационной информации клиента WU с последующей его перерегистрацией на сервере WSUS.

    ###############################################################
    # Требования: Powershell 2.0, WSUS API (Добавляется в систему при установке консоли WSUS) 
    #
    Write-Host  'Loading WSUS API...' -ForegroundColor Green
    [reflection.assembly]::LoadWithPartialName('Microsoft.UpdateServices.Administration') 
    Write-Host ''
    #
    # Блок переменных 
    # $WUSrvName – Имя сервера WSUS
    # $WUSrvPort – Порт подключения к серверу WSUS
    # $WUSrvHTTPS – Признак использования шифрования при подключении к серверу WSUS ($true или $false)
    # $ADSearchOU – ADSI путь к контейнеру с доменными учетными записями пользователей (в формате LDAP://distinguishedName)
    # $ADSearchFilter - Фильтр поиска объектов в AD (действующие учетные записи компьютеров)
    # $ResetSusClientId – Признак необходимости форсированной смены идентификатора SusClientId у отсутствующих на WSUS клиентов (1 или 0) 
    #
    $WUSrvName = 'KOM-AD01-SRV-WSUS'
    $WUSrvPort = 8530
    $WUSrvHTTPS = $false
    $ADSearchOU = 'LDAP://OU=Domain Computers,DC=mydom,DC=com'
    $ADSearchFilter = '(&(objectCategory=computer)(!userAccountControl:1.2.840.113556.1.4.803:=2))'
    $ResetSusClientId = 0
    #
    # Получаем список всех компьютеров зарегистрированных на WSUS-сервере: 
    Write-Host  'Getting WU clients data from Server' $WUSrvName 'on port' $WUSrvPort '...' -ForegroundColor Green
    $WSUS = [Microsoft.UpdateServices.Administration.AdminProxy]::GetUpdateServer($WUSrvName, $WUSrvHTTPS, $WUSrvPort)
    $WSUScomps = $WSUS.GetComputerTargets() 
    $WSUSCompNames = $WSUScomps | ForEach { $_.FullDomainName.ToUpper() } 
    #
    # Получаем список учетных записей компьютеров из Active Directory: 
    Write-Host  'Getting AD computers from OU' $ADSearchOU '...' -ForegroundColor Green
    $ADcomps = (New-Object System.DirectoryServices.DirectorySearcher([ADSI]$ADSearchOU, $ADSearchFilter)).findAll() 
    $ADCompNames = $ADcomps | ForEach {$_.GetDirectoryEntry().dNSHostName.ToString().ToUpper()} 
    #
    # Получаем имена компьютеров, которые есть в Active Directory, но отсутствуют в WSUS:
    Write-Host 'Matching...' -ForegroundColor Green
    $NoWSUSCompNames = $ADCompNames | Where { $WSUSCompNames -notcontains $_ } | Sort-Object
    #
    # Блок смены идентификатора SusClientId 
    If ($NoWSUSCompNames.Count -eq $null) 
    {Write-Host 'Good. No differences.' -ForegroundColor Green}
    Else
    {
    Write-Host 'Found problem computers...' -ForegroundColor DarkRed
    Write-Host ''
    ForEach ($PC in $NoWSUSCompNames)
    {
    $Ping = New-Object System.Net.NetworkInformation.Ping
    Trap {Write-Host $PC 'can not ping' -ForegroundColor DarkRed; continue}
    If ($Ping.send($PC).Status -eq 'Success' ) {
    Write-Host $PC 'available' 
    #
    # Для того чтобы данный метод обращения к удалённому реестру успешно отработал на 64 битных системах скрипт должен запускаться в 64 PS
    # Пример проверки битности - http://poshcode.org/2027
    $is64 = [bool](gwmi win32_operatingsystem -computer $PC | ?{$_.caption -like '*x64*' -or $_.OSArchitecture -eq '64-bit'})
    $isShell32 = [bool]((Get-Process -Id $PID | ?{$_.path -like '*SysWOW64*'}) -or !([IntPtr]::Size -eq 8))
    If ($is64 -and $isShell32)
    {Write-Warning 'Unable to open registry keys because PC is running an x64 OS. Script must be run from a PowerShell x64 shell' }
    Else
    {
    $Reg = [Microsoft.Win32.RegistryKey]::OpenRemoteBaseKey('LocalMachine', $PC)  
    $RegKey= $Reg.OpenSubKey('SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate',$true)  
    $RegKeyValue1 = $RegKey.GetValue('SusClientId')
    #Trap {Write-Host $PC 'can not get registry key value' -ForegroundColor DarkRed; continue}
    Write-Host 'current SusClientId -' $RegKeyValue1
    If ($ResetSusClientId -eq 1) 
    {
    Write-Host 'attempt to reset SusClientId...'
    #
    # Останавливаем на удаленном компьютере службу Windows Update
    Write-Host 'stop Windows Update service (wuauserv)...'
    [System.Reflection.Assembly]::LoadWithPartialName('system.serviceprocess')
    $wuauserv=New-Object System.ServiceProcess.ServiceController('wuauserv',$PC)
    $Stopped=$true
    If ($wuauserv.Status -ne 'Stopped') {
                Try {
                            $wuauserv.Stop()
                            $wuauserv.WaitForStatus('Stopped',(new-timespan -seconds 10))
                            }
                Catch {
                            Write-Warning 'can not stop Windows Update service (wuauserv).'
                            $Stopped=$false
                            }
    }
    #
    # Удаляем идентификационные ключи клиента Windows Update из реестра, предварительно проверив их наличие  
    If ($Stopped) {
                Write-Host 'delete Windows Update registry keys...'
                If($RegKeyValue1 -ne $null){$RegKey.DeleteValue('SusClientId')}
                $RegKeyValue2 = $RegKey.GetValue('SusClientIdValidation')
                If($RegKeyValue2 -ne $null){$RegKey.DeleteValue('SusClientIdValidation')}
                $RegKeyValue3 = $RegKey.GetValue('PingID')
                If($RegKeyValue3 -ne $null){$RegKey.DeleteValue('PingID')}
                $RegKeyValue4 = $RegKey.GetValue('AccountDomainSid')
                If($RegKeyValue4 -ne $null){$RegKey.DeleteValue('AccountDomainSid')}
                $Started=$true 
                }
    #
    # Запускаем на удаленном компьютере службу Windows Update
    Write-Host 'start Windows Update service (wuauserv)...'
    Try {
                $wuauserv.Start()
                $wuauserv.WaitForStatus('Running',(new-timespan -seconds 15))
                }
    Catch {
                Write-Warning 'can not start Windows Update service (wuauserv).'
                $Started=$false
                }
    #
    # Запускаем процедуру перерегистрации клиента Windows Update на сервере WSUS
    If ($Started) {
                Start-Sleep -Seconds 5
                Write-Host 'reset authorization of WU client...'
                $RemoteProcess=([wmiclass]"\$PCrootcimv2:Win32_Process").create('cmd /c wuauclt /resetauthorization /detectnow')
                Write-Host "running return code - $($RemoteProcess.ReturnValue), process ID - $($RemoteProcess.ProcessId)"
                }
    }
    }
    }
    Else 
    { 
    Write-Host $PC 'not available' -ForegroundColor DarkRed }
    Write-Host ''
    }                                 
    }
  • WSUS – Проблемы с клонированными клиентами с дублирующимися SusClientId

    WSUSПри вводе в эксплуатацию партии новых рабочих станций HP с предустановленной ОС Windows 7 Pro OEM столкнулись с ситуацией, когда новые клиентские компьютеры успешно обновлялись с локального сервера WSUS, но при этом не появлялись на консоли WSUS. Вернее сказать, на консоли отображался лишь один новый компьютер, который последним обратился на WSUS. Изучив WindowsUpdate.log на нескольких таких клиентских компьютерах, стало очевидно, что каждый из них использует один и тот же SusClientId, что и приводит к цикличному переписыванию на WSUS сведений о новых клиентах.

    Читать далее...

  • PowerShell – Поиск пользователей домена с устаревшими паролями

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

    Для этой задачи как отправную точку я использовал PS-скрипт User Counting and Password Age Checking с блога Steve Tibbetts, несколько переработав его. В частности была убрана ненужная мне в данной ситуации зависимость от командлетов Quest, добавлена возможность управления выводом отключенных учетных записей, изменён вывод  в удобоваримый вид с сортировкой по дате установки пароля, добавлена возможность установки признака смены пароля для учетных записей с «прокисшими» паролями. Вот что получилось:

    # Блок переменных

    # $LDAPPath - ADSI путь к контейнеру с доменными учетными записями пользователей (в формате LDAP://distinguishedName)

    # $CountDisabledUsers - Признак вывода сведений об отключенных учетных записях (1 или 0)

    # $PWAgeDaysLimit - Максимально возможный период действия пароля в днях

    # $PWDMustChange - Признак необходимости форсированной установки атрибута требующего смену пароля (1 или 0)

    #

    $LDAPPath = 'LDAP://OU=Domain Users,DC=mydom,DC=com'

    $CountDisabledUsers = 0

    $PWAgeDaysLimit = 90

    $PWDMustChange = 0

    #

    # Блок поиска

    #

    $RootDomainOU = [ADSI]$LDAPPath

    $Searcher = New-Object System.DirectoryServices.DirectorySearcher($RootDomainOU)

    $Filter = '(objectCategory=person)(objectClass=user)'

    If ($CountDisabledUsers -eq 0) { $Filter = $Filter + '(!(userAccountControl:1.2.840.113556.1.4.803:=2))' }

    $Filter = '(&' + $Filter + ')'

    $Searcher.Filter = $Filter

    $Searcher.PageSize = 5000

    [Void]$Searcher.PropertiesToLoad.Add("cn")

    [Void]$Searcher.PropertiesToLoad.Add("sAMAccountName")

    [Void]$Searcher.PropertiesToLoad.Add("pwdLastSet")

    $Users = $Searcher.findall()

    #

    # Блок основного вывода

    #

    $PWDays = (Get-Date).AddDays(-$PWAgeDaysLimit)

    $UsersOldPWD = $Users | Where-Object {[datetime]::FromFileTime(($_.properties.pwdlastset)[0]) -le $PWDays}

    $UsersOldPWD | Select `

    @{label='User Full Name';expression={$_.properties.cn}},`

    @{label='sAMAccountName';expression={$_.properties.samaccountname}},`

    @{label='Last Password Set';expression={[datetime]::FromFileTime(($_.properties.pwdlastset)[0])}}`

    | Sort -Property 'Last Password Set'`

    | Format-Table –AutoSize

     

    Write-Host '---------------------------------------------------'

    write-host 'Total user accounts in OU: ' $Users.Count

    write-host 'Users with passwords not changed in' $PWAgeDaysLimit 'days: ' $UsersOldPWD.Count

    Write-Host '---------------------------------------------------'

    #

    # Блок смены атрибута учетных записей

    #

    If ($PWDMustChange -eq 1) {

    Write-Host 'Set for users with old password - Change PWD at next Logon'

    If ($UsersOldPWD.Count -eq $null)

    { Write-Host 'Ops...No account needs to be changed.'}

    Else

    {

                ForEach ($User in $UsersOldPWD)

                {

                Write-Host 'Modify user:' $User.Properties.cn

                $Account=[ADSI]$User.Path

                $Account.put("pwdLastSet", 0)

                $Account.setinfo()

                }    

    }

    Write-Host '---------------------------------------------------'

    }

    По умолчанию скрипт настроен только на вывод статистической информации с итоговыми показателями и его вывод выглядит примерно так:

    image

  • Exchange Server 2007 – Включение почтовых ящиков для списка пользователей из файла

    Для массового включения почтовых ящиков для уже существующих в домене пользователей приготовим *.CSV файл с разделителем – запятая. В первой строке файла будут описаны заголовки значений, в последующих строках – сами значения.

    В нашем примере в качестве используемых значений будут имя пользователя в домене в формате DOMAINUser и алиас для создаваемого почтового ящика к этому имени пользователя. В обычном текстовом редакторе файл будет выглядеть так:

    DomainUser,mailAlias
    MYDOMivanov-ip,I.Ivanov
    MYDOMpetrov-sa,S.Petrov
    MYDOMsidorov-dg,D.Sidorov

    Чтобы убедиться в том, что PowerShell  действительно может разобрать наш файл по значениям выполним команду:

    Import-CSV C:Users.csv

    Результат вывода должен быть таким:

    image

    Непосредственно для импорта содержимого файла и включения на основе этих данных почтовых ящиков выполним:

    $DBId =  'MailboxServerStorageGroupDataBase'

    Import-CSV C:Users.csv | ForEach-Object { Enable-Mailbox -Identity $_.DomainUser -Alias $_.mailAlias –Database $DBId } | Get-Mailbox | Select Alias,WindowsEmailAddress

     

  • SCCM 2007 R2 – Использование Remote Tools для клиентов в рабочей группе

    imageЭта заметка о том, как организовать возможность механизма удалённого управления SCCM Remote Tools для клиентов не входящих в домен (являющихся членами рабочей группы). Всё нижеописанное относиться только к Смешанному режиму работы сайта SCCM (Mixed mode).

    Как обычно бывает на практике с SCCM, несмотря на довольно обширный объём доступной онлайн документации, мне нигде не удалось найти исчерпывающей информации обо всех подводных камнях этой задачи, поэтому решил написать для себя на будущее небольшую шпаргалку.

    Нормальное взаимодействие не доменного клиента SCCM и доменного сервера SCCM во многом зависит от корректной работы механизмов разрешения имён. В интернете можно встретить несколько способов организации разрешения имён для этой задачи. Мы пойдём по самому короткому и надёжному пути,  без всяких танцев с бубном вокруг серверов WINS, ковыряния конфигурационных файлов LMHOSTS и т.п. – то есть будем использовать DNS.. как звучит в гайде“We recommend DNS for workgroup clients”

    Для начала мы включим публикацию точки распространения нашего сайта SCCM в DNS. Сделать это можно в консоли SCCM, открыв свойства сайта на закладке “Advanced

    image

    После включения этой опции мы должны удостовериться в том, что SCCM сервер действительно создал в DNS в нашей основной зоне прямого просмотра в контейнере _tcp необходимую запись Service location resource record (SRV RR). В нашем примере это будет зона mydom.com

    image

    Если же по какой то причине сервисная учетная запись так и не появилась, мы можем создать её в ручную. Процесс создания такой записи описан в статье System Center TechCenter – How to Manually Publish the Default Management Point to DNS.

    Следующим шагом будет установка специальной серверной роли SCCM Server Locator Point (SLP), которая в нашем случае будет нужна для того чтобы не доменные клиенты могли общаться c нашим сервером SCCM внутри домена посредствам протокола HTTP.

    Процедура добавления роли  пошагово описана в статье System Center TechCenter – How to Create a Server Locator Point in Configuration Manager. В консоли SCCM развернём дерево настроек нашего сайта (Site Database > Site Management > SITENAME > Site Settings), перейдём в раздел Site Systems и в меню действий выберем пункт New Roles

    image

    Далее в открывшемся мастере добавления ролей отметим интересующую нас роль – SLP, остальные настройки мастера в большинстве случаев можно оставить неизменными.

    image

    image

    После того как мастер установки роли успешно завершит свою работу, мы можем проверить доступность Application-части добавленной роли, - для этого откроем в браузере специально сформированный URL формата:

    http://<SLPServerName>/sms_slp/slp.dll?site&sc=<SiteName>

    В нашем примере эта ссылка будет выглядеть так:
    http://kom-sccm01.mydom.com/sms_slp/slp.dll?site&sc=KOM

    Как минимум, мы не должны получать никаких ошибок веб-сервера, запросов авторизации и т.п. вещей. В качестве ответа SLP мы должны получить XML примерно такого содержания:

       <?xml version=”1.0” ?>

       <SiteAssignment>

         <Site Sitecode=”KOM BuildNumber=”6487 Version=”4.00.6487.2000 DefaultMP=”KOM-SCCM01.MYDOM.COM”>

            <Capabilities SchemaVersion=”1.0” />

      </Site>

    </SiteAssignment>

     

    Далее переходим непосредственно к настройке не доменного клиента. В первую очередь мы должны обеспечить адекватную работу DNS клиента. Для этого мы убеждаемся в том, что в качестве DNS серверов для клиента используется сервера обслуживающие нашу доменную зону, а в свойствах системы на клиенте задан Основной DNS-суффикс указывающий имя домена:

    image

    После этого с клиента проверяем доступность SCCM сервера по короткому имени (без указания DNS суффикса) и по полному FQDN имени:

    Ping KOM-SCCM01
    Ping KOM-SCCM01.mydom.com

    Затем регистрируем в DNS имя нашего не доменного клиента и затем проверяем его доступность по имени с SCCM сервера.

    Следующим шагом копируем дистрибутив SCCM клиента из подкаталога Client каталога установки серверных компонент SCCM на наш не доменный компьютер, например в папку «C:SCCMClientDistr»:

    image

    Необходимо чтобы  файлы установки клиента располагались именно на локальном ресурсе и оставались доступными в той же папке после установки клиента, так как они могут потребоваться в дальнейшем для процедур обновления/реконфигурации клиентского ПО.

    Открываем командную строку, переходим в каталог с указанными файлами и выполняем запуск программы установки с передачей ей всех необходимых параметров командой:

    CCMSetup.exe /Source:C:SCCMClientDistr” CCMHTTPPORT=80  SMSSITECODE=KOM” SMSMP=KOM-SCCM01.mydom.com” SMSSLP=KOM-SCCM01.mydom.com” DNSSUFFIX=mydom.com”

    Примечание: Полный список используемых ключей и их описания можно найти по ссылке на первоисточник в конце заметки. 

    Дожидаемся когда в системном журнале «Приложение» будет зафиксировано событие успешного окончания установки клиента:

    image

    Проверяем доступность дополнительных апплетов SCCM в Панели управления, которые должны появиться после окончания установки клиента:

    image

    После этого переходим на консоль SCCM, убеждаемся в том, что наш клиент там появился, и выполняем для него процедуру одобрения (Approve)

    image

    Всё теперь наш клиент «в строю». Для того чтобы успешно работал механизм Remote Tools в составе клиента SCCM, на клиентской системе в свойствах проводника необходимо отключить Использование простого общего доступа к файлам (simple file sharing)

    image

    После этого мы сможем подключаться к нашему не доменному клиенту через Remote Tools, указывая при запросе авторизации локальные учетные данные этого клиента (без указания имени домена):

    image

    И ещё один момент, если мы планируем использовать распространение ПО на таких клиентов , то на сервере SCCM обязательно должна быть сконфигурирована учетная запись Network Access Account, в противном случае не доменные компьютеры не смогут получить доступ к контенту точки распространения (distribution point).

    Дополнительные источники информации:

    System Center TechCenter Configuration Manager 2007 General Supported Configurations (Computers in Workgroups)

    System Center TechCenter - How to Install Configuration Manager Clients on Workgroup Computers

    System Center TechCenter - How to Specify the Server Locator Point for Configuration Manager Client Computers

    System Center TechCenter - About Configuration Manager Client Installation Properties

  • Windows Server 2008 R2 – Добавление скриптов входа на сервере RDS через ключ реестра AppSetup

    imageПри настройке сервера служб Remote Desktop Services (RDS) на Windows Server 2008 R2 c включённым UAC, столкнулся с интересной ситуацией. Стояла такая задача, чтобы при входе в систему для каждого пользователя отрабатывал *.cmd файл, в котором исполнялись бы все необходимые директивы дополнительной настройки пользовательского окружения.

    По старой памяти, запустив редактор реестра от имени Администратора, я открыл ветку реестра HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon и с удивлением обнаружил отсутствие строкового параметра AppSetup (параметр служит для запуска скриптов обеспечения совместимости приложений в многопользовательской среде). Без задней мысли я создал этот параметр, вписал в него имя моего командного файла (USRLOGON_2.CMD), расположенного в папке C:\Windows\System32 и перезагрузил систему. Но к моему удивлению после перезагрузки, при входе пользователей в систему, файл не отрабатывал.

    Читать далее...

  • PowerShell – Сравнение включённых правил брандмауэра на двух компьютерах

    Compare Windows Firewall rules with PowerShellСтолкнулся с ситуацией, когда в разборе полётов у одного из Hyper-V серверов с включенным брандмауэром Windows Firewall потребовалось сравнить  действующие правила с другим сервером. Первое, что пришло в голову - с помощью PowerShell удалённо через вызов Invoke-Command слить правила Windows Firewall с обоих серверов в текстовые файлы и затем сравнить их содержимое.

    Читать далее...

  • PowerShell – Получение информации о локальных пользователях и группах

    Чтобы быстро получить информацию о списке локальных пользователей на удалённом компьютере можно воспользоваться подключением через PowerShell к интерфейсу WMI с запросом в одну строку:

    Get-WmiObject Win32_UserAccount -ComputerName MyPC -Filter "Domain= MyPC'"

    Тоже самое, но уже при обращении к интерфейсу ADSI:

    $computerName = "MyPC"

    $computer = [ADSI]"WinNT://$computerName,computer" 

    $computer.psbase.Children | Where-Object { $_.psbase.schemaclassname -eq 'user' } | Format-Table Name, Description -autoSize

    Если нужно получить информацию с локального компьютера в переменной $computerName укажем значение "."

    По аналогии для получения списка локальных групп безопасности удалённого компьютера используем команду:

    Get-WmiObject Win32_Group -ComputerName MyPC -Filter "Domain='MyPC'"

    ..или

    $computerName = "MyPC"

    $computer = [ADSI]"WinNT://$computerName,computer" 

    $computer.psbase.Children | Where-Object { $_.psbase.schemaclassname -eq 'group' } | Format-Table Name, Description -autoSize

    Если же мы хотим получить картину в целом по всем существующим группам безопасности и членам, входящим в эти группы используем более сложную конструкцию:

    $computerName = "MyPC"

    $computer = [ADSI]"WinNT:// $computerName,computer"

    $computer.psbase.children | where { $_.psbase.schemaClassName -eq 'group' } | foreach {

        write-host "Group:" $_.Name

        write-host "Descr:" $_.Description

        write-host "-----"

        $group =[ADSI]$_.psbase.Path

        $group.psbase.Invoke("Members") | foreach {

        $ADSIName = $_.GetType().InvokeMember("AdsPath", 'GetProperty', $null, $_, $null)

            if ($ADSIName -match "[^/]/[^/]") {

            [String]::Join("", $ADSIName.Split("/")[-2..-1])

            }

            else {

            $ADSIName.Split("/")[-1]

            }

        }

        write-host

    }

    Источники информации:

    Janel Blog - Script pour l'énumération des membres d'un groupe

    Powershellcommunity Forum - Listing local user accounts on remote machines

  • HP System Management Homepage - Установка FQDN Local Server Certificate

    imageПри установке HP System Management Homepage (SMH) по умолчанию использует самоподписанный сертификат, что приводит к паническим предупреждениям веб-браузеров. Встроенный механизм управления локальным сертификатом HP System Management Homepage непосредственно через веб-интерфейс, несмотря на свой почтенный срок существования, до сих пор не умеет формировать запрос на создание цифрового сертификата с атрибутом commonName в формате FQDN. Если для сравнения взять, например веб-интерфейс управления iLO2, то там такая возможность появилась в одном из предпоследних релизов firmware, что само по себе подаёт надежду на то, что технари HP таки одумаются и добавят такую возможность и в функционал HP System Management Homepage… А пока такой возможности нет, мы попробуем использовать альтернативный метод установки сертификата SMH, имеющего в качестве commonName FQDN имя сервера, подписанного нашим локальным доверенным центром сертификации.

    Проделаем несколько несложных действий:

    • Сгенерируем запрос на сертификат средствами OpenSSL к ЦС Windows;
    • Получим от ЦС файла сертификата (.cer) в формате X.509 Base-64;
    • Заменим сертификат в встроенном веб-сервере HP System Management Homepage

    Для того чтобы создать запрос к ЦС Windows нам понадобиться OpenSSL, а именно 3 файла из его состава – openssl.exe, ssleay32.dll, libeay32.dll. Сложим их в один каталог (например в каталог C:ToolsOpenSSL).

    Для подготовки запроса к ЦС создадим конфигурационный файл для OpenSSL - текстовый файл myopenssl.cfg со следующим содержимым:

    [ req ]
    distinguished_name = req_distinguished_name

    [ req_distinguished_name ]
    commonName = FQDN of server
    commonName_default = SERVER.mydom.com
    countryName = Country Name (2 letter code)
    countryName_default = RU
    0.organizationName = Organization Name (eg, company)
    0.organizationName_default = MyCompany
    localityName = Locality Name (eg, city)
    localityName_default = Syktyvkar
    organizationalUnitName = Organizational Unit Name (eg, section)
    organizationalUnitName_default = KOMI

    Как вы понимаете, в этом файле мы указываем параметры, которые нужны для идентификации запроса сертификата в ЦС, т.е. указываем имя сервера, которому требуется сертификат, имя организации и т.п.
    Для формирования запроса с закрытым ключом нам нужно получить собственно сам закрытый ключ используемый сервером в данный момент – файл file.pem (по умолчанию расположен в каталоге C:hpsslshare).
    Далее создаем запрос на сертификат с учётом подготовленных ранее параметров и ключевого файла командой:

    C:ToolsOpenSSL >openssl req -config myopenssl.cfg -new -key file.pem -out myreq.req

    clip_image002

    Полученный файл запроса myreq.req загружаем в центр сертификации Windows Server, где выдаем сертификат на загруженный запрос. Выгружаем из ЦС новый сертификат в файл с именем cert.pem в формате X.509 в кодировке Base-64.

    Файл cert.pem копируем в каталог, где HP SMH хранит файл самоподписанного сертификата (по умолчанию каталог C:hpsslshare). При этом имеющийся там файл на всякий случай сохраняем и переименовываем в cert.back.

    После этого на сервере с HP SMH перезапускаем службу HP System Management Homepage командами:

    Net stop SysMgmtHp
    Net start SysMgmtHp

    В итоге открываем HP System Management Homepage в вэб-браузере (по умолчанию URL типа https://server.mydom.com:2381/) и убеждаемся в том, что HP SMH использует определенный нами сертификат и предупреждения безопасности браузера отсутствуют.

  • Ошибка обработки GPP: Group Policy object did not apply because its targeting item failed with error code 0x86012004

    imageРанее уже описывалась проблема с обработкой Group Policy Preferences (GPP) в части применения нацеливания (Item-level targeting) на OU - Долгая обработка GPP на этапе “Applying Group Policy Drive Maps policy” на клиентах RODC Windows Server 2008 R2

    В ходе дальнейшей эксплуатации GPP для изменения членства группы Администраторов на доменных компьютерах описанная проблема проявила себя по аналогичному сценарию (при нацеливании на доменные OU). Чтобы уйти от этого, приняли решение использовать нацеливание на группы безопасности, то есть изменять членство группы Администраторов в зависимости от членства учетной записи компьютера в той или иной доменной группе безопасности. Однако после настройки GPP и применения на клиентских компьютерах с Windows 7 и Windows Server 2008 R2 обнаружилось, что данная настройка GPP не отрабатывает. Сбор трейсов GPP выявил ошибку обработки типа:

    Failed filter [FilterGroup]. [ hr = 0x86012004 "Клиентское расширение перехватило необрабатываемое исключение "filter expand" в: "Access violation (0xc0000005) occurred at 0xca12dad1; the memory at 0xca12dad1 could not be ????."%100790275" ]

    Как выяснилось, эта проблема известна уже почти год и описана в статье KB976399 - FIX: You cannot apply Group Policy settings on a computer that is running Windows 7 or Windows Server 2008 R2 when security group filters are used in Group Policy preference settings.

    К удивлению для себя выяснил, что данное обновление через WSUS не раскатывалось и для его применения MS предлагает воспользоваться отдельно загружаемым файлом исправления

    Имеющийся на данный момент перечень исправлений включенных в готовящийся к выпуску SP1 для Windows 7 и Windows Server 2008 R2 - Documentation for Windows 7 and Windows Server 2008 R2 Service Pack 1 Release Candidate (KB976932) говорит нам о том, что этот фикс туда включен. Так что ждём релиза SP1, а пока можем выбрать для себя либо вариант с отдельной установкой фикса на проблемных клиентов, либо опять же нужно выбирать альтернативные методы нацеливания.