Powershell, ADMT и проверка административных шар


В статье Powershell – параллельное выполнение операций – меняем настройки DNS я немного описал Workflow и как использовать это средство для выполнения параллельных операций на множестве компьютеров на примере настройки DNS.

Вот еще один пример. При миграции компьютеров с помощью ADMT важно обеспечить удаленный доступ к компьютеру с сервера миграции. Фактически используются административные шары. И ADMT имеет режим PreCheck – выполнение проверки перед запуском фактической миграции. Но запускать проверку из ADMT не совсем удобно, т.к. ошибки он покажет, но их еще надо исправить, либо исключить проблемные компьютеры из списка миграции. Поэтому лучше проверку делать заранее, исправить ошибки доступа, потом только приступать к миграции. И поможет нам в этом простой скрипт:

workflow  checkAdmShares {

 

param($computerName)

 

foreach -parallel($computer in $computerName) {

   if  (Test-Connection  -Count 2  -ErrorAction SilentlyContinue -ComputerName $computer.DNSHostName)

             { if ( Test-Path  -Path «\\$($computer.DNSHostName)\admin$» ) {«$($computer.DNSHostName) — Ok»} else {«$($computer.DNSHostName) — not path»} } else { «$($computer.DNSHostName) — not ping»}

   }

 

}

 

$comps = Get-Content C:\list.txt | % {$_.Trim()} | % { Get-ADComputer  $_ }

checkAdmShares $comps

 

За счет распараллеливания скрипт работает очень быстро даже для большого списка компьютеров.

Powershell – параллельное выполнение операций – меняем настройки DNS


В современном (назовем его так) Powershell есть потрясающе удобная вещь – Workflow, которая позволяет выполнять работу параллельно (есть и другие приятности в Workflow, но сегодня только об этой).

Читать далее

Вот чем хорош 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.

Рудименты в DNS на Windows Server 2012


На днях поднимал новый лес на Windows Server 2012. Автоматически поставил DNS. Заглянул в его настройки и ужаснулся: в Forwarders прописаны три адреса fec0:0:0:ffff::1, fec0:0:0:ffff::2, fec0:0:0:ffff::3. Мало того, что они уже давным давно объявлены в RFC 3879 как depredicated, так еще и логики в этом нет никакой.

Посудите сами. Если клиенты получили адреса DNS fec0:0:0:ffff::1 и т.п., то эти DNS в конце-концов должны прямо или косвенно резолвить доменные имена. Лучше прямо, т.е. адреса должны быть привязаны к домен-контроллерам. Но домен-контроллер сам ссылается на эти адреса. Получаем петлю. Или подразумевается косвенность? Но если есть DNS посредник, то он должен ссылаться на домен-контроллер для разрешения доменных имен – опять петля. Как ни крути получается ерунда.

В общем при установке DNS в Windows Server 2012 нужно удалить эти «чудные» forwarders-ы и настроить DNS как обычно либо рекурсивным через рутовые серверы Интернет, либо корневым для леса и аккуратно настроить forwarders-ы и/или условные forwarders-ы, если они нужны.

Тесты с помощью nslookup для всех зон покажут вам, правильно ли все работает при распознавании имен.