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


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

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

Если вы посмотрите командлеты Get/SetCMBoundary, то увидите, что значение сети или диапазона записывается в атрибут 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 сервера, которые резервируют друг друга, с большим числом диапазонов и с относительно большим числом резервирований адресов, резервирования должны быть сделаны одинаково на двух серверах, т.к. адрес клиенту может выдать любой из серверов.

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

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

Читать далее

Вот чем хорош Windows Server 2012 так это своими Powershell командлетами


 

Вот чем хорош Windows Server 2012 так это своими Powershell командлетами. В прежних версиях некоторые операции иной раз не сделаешь просто так: ни утилита управления не поддерживает, ни netsh, ни WMI. Теперь же каждая продуктовая группа обязана сделать управление своим продуктом (компонентом, ролью) с помощью Powershell. И это очень упрощает жизнь.

Вот например как можно на DHCP сервере легко изменить параметр Lease Duration на всех диапазонах, пусть их даже несколько сотен:

$ServerName = «dhcp.domain.ru»

$scopes = Get-DhcpServerv4Scope -ComputerName $ServerName

$scopes | % {Set-DhcpServerv4Scope -ComputerName $ServerName  -ScopeId $_.ScopeId -LeaseDuration «32.00:00:00»}

 

Аналогично сейчас дело с DNS: раньше что-то автоматизировать при его настройке было очень сложно – сейчас есть более 130 командлетов настройки DNS!

Ситуация хороша еще тем, что командлеты Windows Server 2012 (и RSAT Windows 8) работают для серверов прежних версий: по крайней мере мне удалось настроить удаленно DHCP и DNS на Windows Server 2008 R2.