Powershell и SCCM – проверка опубликованных сетей

При миграции SCCM одна из операций заключалась в переносе Boundary – сетей границ сайта. Сети описывались как IP Ranges. После переноса сетей и прочих настроек SCCM была включена публикация в лес. В результате в контейнере CN=System Management,CN=System должны были появится объекты вида SMS-<код сайта>-<число1>-<число2>, клиенты получить эту информацию, подключиться к сайту и т.д.

Но ничего подобного не произошло. Выяснилось, что при переносе границ в скрипте Powershell мой была допущена ошибка.

Если вы посмотрите командлеты Get/Set—CMBoundary, то увидите, что значение сети или диапазона записывается в атрибут Value. Оказалось, что при записи в этот атрибут системой не выполняется должным образом контроль значения. В результате вместо значения <начало сети>-<конец сети> я записал вместе  с тире пару пробелов по обе стороны от него <начало сети><пробел>-<пробел><конец сети>. Получилось красиво… Командлет это проглотил, GUI отобразил значение правильно (!!!) – вот она засада!- но само ядро системы не стало обрабатывать такое значение и просто его игнорировало!

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

$sitecode=«S12121212«

$baseSMS = [ADSI]«LDAP://CN=System Management,CN=System,DC=domain,DC=ru»

 

$filter = «(&(objectClass=mSSMSRoamingBoundaryRange)(cn=SMS-$($sitecode)*))»

$findSMS = new-object System.DirectoryServices.DirectorySearcher($baseCTE, $filter)

$SMSRanges = $findSMS.findAll()

#$SMSRanges

$SMSRanges[0] | % {[pscustomobject]@{cn=$_.properties.cn[0]; `

              mssmsrangediplow=[Net.IPAddress]([Net.IPAddress]::NetworkToHostOrder(([int64]$_.properties.mssmsrangediplow[0])*256*256*256*256)); `

              mssmsrangediphigh=[Net.IPAddress]([Net.IPAddress]::NetworkToHostOrder(([int64]$_.properties.mssmsrangediphigh[0]*256*256*256*256)))}}

 

 

Реклама

Powershell – назначить права на групповые политики

Понадобилось мне редактировать групповые политики из другого леса. Доверие между лесами настроено. Самое простое подключить дополнительный домен в оснастку GPMC. Так и делаю. И с удивлением обнаруживаю, что прав не то, что на редактирование, даже на отображение политик не хватает, несмотря на наличие административных прав в дружественном лесе.

Оказывается права редактирование групповых политик предоставляются группе Domain Admin, которая является глобальной группой, а административные права можно получить только включением учетки (группы) во встроенную локальную группу Builtin\Administrators. В результате административные права вроде как есть и в то же время их нет!

Проводить эксперимент по прямому назначению прав на SYSVOL и служебные ветки AD через ADSIEDIT в рабочей среде я не рискнул, а просто назначил права на политики с помощью Powershell. Можно это сделать ручками, но при большом числе политик это слишком долго и утомительно, поэтому Powershell очень помог:

$domainname = «domain.ru»

$targetname = «FriendForest\Domain Admins»

Get-GPO -All -DomainName $domainname | Set-GPPermission -TargetType Group -TargetName $targetname `

        -PermissionLevel GpoEditDeleteModifySecurity -DomainName $domainname

 

Powershell – приводим в порядок настройки резервирований адресов на DHCP серверах

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

Проблема: со временем резервирования на двух серверах приходят в хаос из-за ошибок администраторов – на одном сервере резервирование адреса может быть сделано, а на другом нет.

Задача: сделать резервирования адресов на обоих серверах одинаковым.