Для быстрого поиска в домене давно не используемых учетных записей пользователей можно использовать оснастку ‘Active Directory Users and Computers’ (dsa.msc), создав в ней запрос.
Потому что у меня сейчас версия вообще 5.3
Собрание заметок об информационных технологиях
Для быстрого поиска в домене давно не используемых учетных записей пользователей можно использовать оснастку ‘Active Directory Users and Computers’ (dsa.msc), создав в ней запрос.
При использовании контроллеров домена «только на чтение» (RODC) для каждого RODC должна быть определена доменная группа безопасности, в которую входят учетные записи пользователей, чьи учетные данные могут реплицироваться на этот RODC. В крупной географически распределённой инфраструктуре с большим количеством контроллеров домена задача поддержания состава этих групп безопасности «в рукопашную» может стать проблемой, особенно если учесть «человеческий фактор», когда например, в каком-то из удалённых подразделений местный администратор создаёт новую учетную запись доменного пользователя, а включить в группу репликации паролей эту запись забывает. Для того чтобы исключить в данном случае «человеческий фактор», можно автоматизировать данный процесс с помощью PowerShell. Рассмотрим пример скрипта, который можно включить в планировщик задач на контроллере домена на периодическое выполнение.
По мотивам применения Password Settings objects (PSOs) с нацеливанием объектов PSO на доменные группы безопасности встаёт вопрос о поддержании состава этих групп в актуальном состоянии. В моём окружении все учетные записи, находящиеся в определённом OU, должны быть включены в доменную группу безопасности, к которой применяется PSO, что само по себе уже есть критерий, по которому можно автоматизировать задачу поддержания группы в актуальном состоянии с помощью PowerShell. Представляю соответствующий скрипт.
В службах AD DS Windows Server 2008 появился новый механизм AD DS Fine-Grained Password and Account Lockout Policy, позволяющий в рамках домена создавать несколько разных политик паролей, применяемых к конкретным доменным пользователям или доменным глобальным группам безопасности. Такой механизм может быть полезен в случае, если, например, необходимо для определенной группы пользователей иметь ослабленные/усиленные политики безопасности, отличающиеся от тех, что заданы на уровне всего домена в Default Domain Policy.
Рассмотрим сценарий создания объекта PSO в домене соответствующего следующим критериям:
Для начала создадим в домене глобальную группу безопасности, в которую будут включены все пользователи, для которых необходимо переопределить политики безопасности паролей:
Создание объекта PSO с помощью MMC-оснастки Active Directory Services Interface editor (ADSI Edit)
Откроем оснастку ADSIEDIT.MSC и подключимся к контексту именования по умолчанию нашего домена указав в поле Name FQDN имя нашего домена
Перейдём в контейнер DC=holding, DC=com -> CN=System -> CN=Password Settings Container
И в контекстном меню на контейнере Password Settings Container выберем создание нового объекта PSO (msDC-PasswordSettings)
Укажем имя нашего нового объекта PSO
Укажем значение атрибута msDS-PasswordSettingsPrecedence. Значение этого атрибута определяет приоритет в случае конфликта нескольких PSO, применяемых к одной и той же группе безопасности или пользователю.
Значение атрибута msDS-PasswordReversibleEncryptionEnabled определяет возможность обратимого шифрования пароля для учетных записей пользователей. Устанавливаем его в false как рекомендуемое.
Зададим значение атрибута msDS-PasswordHistoryLength определяющего количество неповторяемых паролей для учетных записей пользователей.
Значение атрибута msDS-PasswordComplexityEnabled, установленное нами в true, определяет включение требования соблюдения сложности паролей и является рекомендуемым.
Значение атрибута msDS-MinimumPasswordLength, установленное нами в 8, определяет минимальную длину паролей учетных записей пользователей.
Значение атрибута msDS-MinimumPasswordAge, установленное нами в 1:00:00:00 (1 день), определяет минимальный срок действия паролей учетных записей пользователей.
Значение атрибута msDS-MaximumPasswordAge, установленное нами в 90:00:00:00 (90 дней), определяет максимальный срок действия паролей учетных записей пользователей.
Значение атрибута msDS-LockoutThreshold, установленное нами в 5, определяет порог блокировки учетных записей пользователей (после 5 неудачных попыток авторизации срабатывает механизм блокировки учетной записи).
Значение атрибута msDS-LockoutObservationWindow, установленное нами в 0:00:30:00 (30 минут), определяет период сброса счетчика блокировок учетных записей пользователей.
Значение атрибута msDS-LockoutDuration, установленное нами в 0:00:30:00 (30 минут), определяет продолжительность блокировки заблокированных учетных записей пользователей.
На этом работа мастера создания PSO завершается.
После того как только что созданный объект PSO появляется в консоли, открываем его свойства.
Среди списка атрибутов находим атрибут msDS-PSOAppliesTo и убедившись в том что его значение не определено, открываем его редактирование.
В окне редактирования Multi-valued Distinguished Name With Security Principal Editor нажимаем Add Windows Account и выбираем соответствующую доменную глобальную группу безопасности, которую мы создали ранее.
Сохраняем свойства объекта PSO и убеждаемся в том, что привязка к соответствующей группе безопасности произведена (для этого можно проверить значение атрибута msDS-PSOApplied в свойствах самой группы безопасности).
Теперь на всех пользователей, включенных в эту группу безопасности, будут действовать параметры, заданные в нашем объекте 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 наносекунд). Преобразование в данный формат производится по следующей схеме
<
p align="center">
| Единица времени | Множитель |
| 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
Более подробную информацию об использовании утилиты LDIFDE можно найти в статье KB237677 - Использование средства LDIFDE для импорта и экспорта объектов каталогов в Active Directory
Дополнительные источники информации:
По мотивам борьбы с проблемой отображения в консоли 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 '' } }
При вводе в эксплуатацию партии новых рабочих станций HP с предустановленной ОС Windows 7 Pro OEM столкнулись с ситуацией, когда новые клиентские компьютеры успешно обновлялись с локального сервера WSUS, но при этом не появлялись на консоли WSUS. Вернее сказать, на консоли отображался лишь один новый компьютер, который последним обратился на WSUS. Изучив WindowsUpdate.log на нескольких таких клиентских компьютерах, стало очевидно, что каждый из них использует один и тот же SusClientId, что и приводит к цикличному переписыванию на WSUS сведений о новых клиентах.
В некоторых случаях может возникнуть ситуация, когда по какой либо причине в домене не работают глобальные парольные политики безопасности. При этом, исходя из нормальных соображений поддержания должного уровня безопасности учетных данных, требуется найти всех доменных пользователей, у которых срок действия пароля больше определённого периода.
Для этой задачи как отправную точку я использовал 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 '---------------------------------------------------'
}
По умолчанию скрипт настроен только на вывод статистической информации с итоговыми показателями и его вывод выглядит примерно так:
Для массового включения почтовых ящиков для уже существующих в домене пользователей приготовим *.CSV файл с разделителем – запятая. В первой строке файла будут описаны заголовки значений, в последующих строках – сами значения.
В нашем примере в качестве используемых значений будут имя пользователя в домене в формате DOMAINUser и алиас для создаваемого почтового ящика к этому имени пользователя. В обычном текстовом редакторе файл будет выглядеть так:
DomainUser,mailAlias
MYDOMivanov-ip,I.Ivanov
MYDOMpetrov-sa,S.Petrov
MYDOMsidorov-dg,D.Sidorov
Чтобы убедиться в том, что PowerShell действительно может разобрать наш файл по значениям выполним команду:
Import-CSV C:Users.csv
Результат вывода должен быть таким:
Непосредственно для импорта содержимого файла и включения на основе этих данных почтовых ящиков выполним:
$DBId = 'MailboxServerStorageGroupDataBase'
Import-CSV C:Users.csv | ForEach-Object { Enable-Mailbox -Identity $_.DomainUser -Alias $_.mailAlias –Database $DBId } | Get-Mailbox | Select Alias,WindowsEmailAddress
Эта заметка о том, как организовать возможность механизма удалённого управления SCCM Remote Tools для клиентов не входящих в домен (являющихся членами рабочей группы). Всё нижеописанное относиться только к Смешанному режиму работы сайта SCCM (Mixed mode).
Как обычно бывает на практике с SCCM, несмотря на довольно обширный объём доступной онлайн документации, мне нигде не удалось найти исчерпывающей информации обо всех подводных камнях этой задачи, поэтому решил написать для себя на будущее небольшую шпаргалку.
Нормальное взаимодействие не доменного клиента SCCM и доменного сервера SCCM во многом зависит от корректной работы механизмов разрешения имён. В интернете можно встретить несколько способов организации разрешения имён для этой задачи. Мы пойдём по самому короткому и надёжному пути, без всяких танцев с бубном вокруг серверов WINS, ковыряния конфигурационных файлов LMHOSTS и т.п. – то есть будем использовать DNS.. как звучит в гайде – “We recommend DNS for workgroup clients”
Для начала мы включим публикацию точки распространения нашего сайта SCCM в DNS. Сделать это можно в консоли SCCM, открыв свойства сайта на закладке “Advanced”
После включения этой опции мы должны удостовериться в том, что SCCM сервер действительно создал в DNS в нашей основной зоне прямого просмотра в контейнере _tcp необходимую запись Service location resource record (SRV RR). В нашем примере это будет зона mydom.com
Если же по какой то причине сервисная учетная запись так и не появилась, мы можем создать её в ручную. Процесс создания такой записи описан в статье 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
Далее в открывшемся мастере добавления ролей отметим интересующую нас роль – SLP, остальные настройки мастера в большинстве случаев можно оставить неизменными.
После того как мастер установки роли успешно завершит свою работу, мы можем проверить доступность 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-суффикс указывающий имя домена:
После этого с клиента проверяем доступность SCCM сервера по короткому имени (без указания DNS суффикса) и по полному FQDN имени:
Ping KOM-SCCM01
Ping KOM-SCCM01.mydom.com
Затем регистрируем в DNS имя нашего не доменного клиента и затем проверяем его доступность по имени с SCCM сервера.
Следующим шагом копируем дистрибутив SCCM клиента из подкаталога Client каталога установки серверных компонент SCCM на наш не доменный компьютер, например в папку «C:SCCMClientDistr»:
Необходимо чтобы файлы установки клиента располагались именно на локальном ресурсе и оставались доступными в той же папке после установки клиента, так как они могут потребоваться в дальнейшем для процедур обновления/реконфигурации клиентского ПО.
Открываем командную строку, переходим в каталог с указанными файлами и выполняем запуск программы установки с передачей ей всех необходимых параметров командой:
CCMSetup.exe /Source:“C:SCCMClientDistr” CCMHTTPPORT=80 SMSSITECODE=“KOM” SMSMP=“KOM-SCCM01.mydom.com” SMSSLP=“KOM-SCCM01.mydom.com” DNSSUFFIX=“mydom.com”
Примечание: Полный список используемых ключей и их описания можно найти по ссылке на первоисточник в конце заметки.
Дожидаемся когда в системном журнале «Приложение» будет зафиксировано событие успешного окончания установки клиента:
Проверяем доступность дополнительных апплетов SCCM в Панели управления, которые должны появиться после окончания установки клиента:
После этого переходим на консоль SCCM, убеждаемся в том, что наш клиент там появился, и выполняем для него процедуру одобрения (Approve)
Всё теперь наш клиент «в строю». Для того чтобы успешно работал механизм Remote Tools в составе клиента SCCM, на клиентской системе в свойствах проводника необходимо отключить Использование простого общего доступа к файлам (simple file sharing)
После этого мы сможем подключаться к нашему не доменному клиенту через Remote Tools, указывая при запросе авторизации локальные учетные данные этого клиента (без указания имени домена):
И ещё один момент, если мы планируем использовать распространение ПО на таких клиентов , то на сервере 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 - About Configuration Manager Client Installation Properties
При настройке сервера служб 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 и перезагрузил систему. Но к моему удивлению после перезагрузки, при входе пользователей в систему, файл не отрабатывал.
Последние комментарии