• PowerShell – Поддержание группы безопасности для Password Settings objects (PSOs) в актуальном состоянии

    imageПо мотивам применения Password Settings objects (PSOs) с нацеливанием объектов PSO на доменные группы безопасности встаёт вопрос о поддержании состава этих групп в актуальном состоянии. В моём окружении все учетные записи, находящиеся в определённом OU, должны быть включены в доменную группу безопасности, к которой применяется PSO, что само по себе уже есть критерий, по которому можно автоматизировать задачу поддержания группы в актуальном состоянии с помощью PowerShell. Представляю соответствующий скрипт.

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

  • AD DS - Создание нескольких политик паролей Password Settings objects (PSOs) в домене Windows Server 2008/2008 R2

    imageВ службах AD DS Windows Server 2008 появился новый механизм AD DS Fine-Grained Password and Account Lockout Policy, позволяющий в рамках домена создавать несколько разных политик паролей, применяемых к конкретным доменным пользователям или доменным глобальным группам безопасности. Такой механизм может быть полезен в случае, если, например, необходимо для определенной группы пользователей иметь ослабленные/усиленные политики безопасности, отличающиеся от тех, что заданы на уровне всего домена в Default Domain Policy.

    Рассмотрим сценарий создания объекта PSO в домене соответствующего следующим критериям:

    clip_image001

    clip_image002

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

    clip_image003

     

    Создание объекта PSO с помощью MMC-оснастки Active Directory Services Interface editor (ADSI Edit)

    Откроем оснастку ADSIEDIT.MSC и подключимся к контексту именования по умолчанию нашего домена указав в поле Name FQDN имя нашего домена

    clip_image004

    Перейдём в контейнер DC=holding, DC=com -> CN=System -> CN=Password Settings Container

    clip_image005

    И в контекстном меню на контейнере Password Settings Container выберем создание нового объекта PSO (msDC-PasswordSettings)

    clip_image006

    Укажем имя нашего нового объекта PSO

    clip_image007

    Укажем значение атрибута msDS-PasswordSettingsPrecedence. Значение этого атрибута определяет приоритет в случае конфликта нескольких PSO, применяемых к одной и той же группе безопасности или пользователю.

    clip_image008

    Значение атрибута msDS-PasswordReversibleEncryptionEnabled определяет возможность обратимого шифрования пароля для учетных записей пользователей. Устанавливаем его в false как рекомендуемое.

    clip_image009

    Зададим значение атрибута msDS-PasswordHistoryLength определяющего количество неповторяемых паролей для учетных записей пользователей.

    clip_image010

    Значение атрибута msDS-PasswordComplexityEnabled, установленное нами в true, определяет включение требования соблюдения сложности паролей и является рекомендуемым.

    clip_image011

    Значение атрибута msDS-MinimumPasswordLength, установленное нами в 8, определяет минимальную длину паролей учетных записей пользователей.

    clip_image012

    Значение атрибута msDS-MinimumPasswordAge, установленное нами в 1:00:00:00 (1 день), определяет минимальный срок действия паролей учетных записей пользователей.

    clip_image013

    Значение атрибута msDS-MaximumPasswordAge, установленное нами в 90:00:00:00 (90 дней), определяет максимальный срок действия паролей учетных записей пользователей.

    clip_image014

    Значение атрибута msDS-LockoutThreshold, установленное нами в 5, определяет порог блокировки учетных записей пользователей (после 5 неудачных попыток авторизации срабатывает механизм блокировки учетной записи).

    clip_image015

    Значение атрибута msDS-LockoutObservationWindow, установленное нами в 0:00:30:00 (30 минут), определяет период сброса счетчика блокировок учетных записей пользователей.

    clip_image016

    Значение атрибута msDS-LockoutDuration, установленное нами в 0:00:30:00 (30 минут), определяет продолжительность блокировки заблокированных учетных записей пользователей.

    clip_image017

    На этом работа мастера создания PSO завершается.

    clip_image018

    После того как только что созданный объект PSO появляется в консоли, открываем его свойства.

    clip_image019

    Среди списка атрибутов находим атрибут msDS-PSOAppliesTo и убедившись в том что его значение не определено, открываем его редактирование.

    clip_image020

    В окне редактирования Multi-valued Distinguished Name With Security Principal Editor нажимаем Add Windows Account и выбираем соответствующую доменную глобальную группу безопасности, которую мы создали ранее.

    clip_image021

    clip_image022

    Сохраняем свойства объекта PSO и убеждаемся в том, что привязка к соответствующей группе безопасности произведена (для этого можно проверить значение атрибута msDS-PSOApplied в свойствах самой группы безопасности).

    clip_image023

    Теперь на всех пользователей, включенных в эту группу безопасности, будут действовать параметры, заданные в нашем объекте PSO независимо от текущих настроек в Default Domain Policy.

    Создание объекта PSO с посмощью CLI-утилиты LDIF Directory Exchange (LDIFDE)

    Помимо создания объекта PSO через оснастку ADSIEDIT.MSC, мы можем создать его с помощью утилиты командной строки LDIFDE. В некоторых сценариях это может быть более быстро и удобно. Для этого нам предварительно нужно подготовить файл в формате *.LDF (LDAP Data Interchange Format) следующего содержания:

    dn: CN=KOM-SRV-PSO-Users,CN=Password Settings Container,CN=System,DC=holding,DC=com
    changetype: add
    objectClass: msDS-PasswordSettings
    msDS-MaximumPasswordAge: -77760000000000
    msDS-MinimumPasswordAge:-864000000000
    msDS-MinimumPasswordLength:8
    msDS-PasswordHistoryLength:5
    msDS-PasswordComplexityEnabled:TRUE
    msDS-PasswordReversibleEncryptionEnabled:FALSE
    msDS-LockoutObservationWindow:-18000000000
    msDS-LockoutDuration:-18000000000
    msDS-LockoutThreshold:5
    msDS-PasswordSettingsPrecedence:1
    msDS-PSOAppliesTo:CN=KOM-SRV-PSO-Users,CN=Users,DC=holding,DC=com

    Обратите внимание на то, что значения атрибутов связанных со временем указываются в формате I8 (интервалы по -100 наносекунд). Преобразование в данный формат производится по следующей схеме

    Единица времени

    Множитель

    1 минута

    -60*(10^7) = - 600000000

    1 час

    -60*60* (10^7) = -36000000000

    1 день

    -24*60*60*(10^7) = -864000000000

    То есть, например, чтобы установить значение атрибута msDS-LockoutDuration равным 30 минутам, для получения значения в формате I8 нужно умножить 30 на -600000000 (в этом примере значение равно -18000000000). Более подробную информацию по этому поводу можно получить в приложении Appendix B: PSO Attribute Constraints

    После того как мы подготовили LDF файл, произведём импорт указанной в нём информации командой:

    LDIFDE -i -f NewPSO.ldf

    clip_image024

    Более подробную информацию об использовании утилиты LDIFDE можно найти в статье KB237677 - Использование средства LDIFDE для импорта и экспорта объектов каталогов в Active Directory

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

    Windows Server TechCenter - AD DS Fine-Grained Password and Account Lockout Policy Step-by-Step Guide

    TechDays.ru - Active Directory: политика паролей

  • 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