Проблема с загрузкой адресной книги Lync при миграции в другой лес


При миграции учетных записей из одного леса в другой у некоторых пользователей появилась проблема: Lync клиент стал запрашивать логин и пароль, более того не работал поиск по адресной книге. (Уточнение: учетная запись пользователя переехала в новый лес, а Lync сервер остался в исходном лесе.) Когда число мигрированных пользователей перевалило за тысячу, количество обращение в тех. поддержку по этой проблеме стало слишком большим. Потребовалось решение.

Читать далее

Реклама

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, но сегодня только об этой).

Читать далее

Миграция лесов и Sharepoint 2010. Часть 2.


В статье Миграция лесов и Sharepoint 2010 описана суть вопроса: миграция из двух лесов в один новый. Здесь я просто привожу доработанный скрипт, который можно использовать при миграции пользователей изо дня в день. Скрипт сохраняет в файле список уже обработанных учетных записей и при последующей итерации не выполняет их повторную обработку. Это сильно снижает время работы скрипта. Если вы мигрируете сотни учетных записей в день, то заметите ощутимую экономию времени.

 

Import-Module Activedirectory

 

$cmdpath=«C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\BIN\»

$cmd = $cmdpath+«stsadm.exe»

 

$dserver = «dc0.TOdomain.ru»

$list=Get-ADUser -Filter * -SearchBase «OU=Deps,DC=TOdomain,DC=ru» -Server $dserver | select -ExpandProperty SamAccountName

 

 

$listold = Get-Content c:\install\list-old.txt

$list0 = $list | ? {$listold -notcontains $_ }

 

 

$dserver = «dc.FROMdomain1.ru»

$list1=$list0 | ? { Get-ADUser -Filter {samaccountname -eq $_} -SearchBase «DC=FROMdomain1,DC=ru» -Server $dserver }

 

$dserver = «dc.FROMdomain2.ru»

$list2=$list0 | % { Get-ADUser -Filter {samaccountname -eq $_} -SearchBase «DC=FROMdomain2,DC=ru» -Server $dserver } | select -ExpandProperty SamAccountName

 

$listconflict = $list1 | ? {$list2 -contains $_ }

 

$list11 = $list1 | ? { $listconflict -notcontains $_ }

$list22 = $list2 | ? { $listconflict -notcontains $_ }

 

 

$list11 | % { & $cmd -o migrateuser -oldlogin FROMdomain1\$($_) -newlogin TOdomain\$($_) -ignoresidhistory }

$list22 | % { & $cmd -o migrateuser -oldlogin FROMdomain2\$($_) -newlogin TOdomain\$($_) -ignoresidhistory }

 

$list11 | Out-File -FilePath c:\install\list-old.txt -Append

$list22 | Out-File -FilePath c:\install\list-old.txt -Append

 

Powershell – поиск конфликтов при миграции лесов


При миграции учетных записей из одного леса (домена) в другой может возникнуть неприятная ситуация – одинаковые samaccountname у учетных записей пользователей. В случае использования ADMT в режиме merge обе записи склеиваются (!) – вообще забавно получается, а режиме replace – поди потом пойми кто есть кто. С почтовыми ящиками Exchange тоже будет пазл (нет ничего страшного, но все же неприятно).

В любом случае надо сделать правильно и до миграции найти все возможные конфликты и устранить их. В поиске совпадающих samaccountname поможет следующий скрипт:

$dserver = «domain1.ru«

$list1= Get-ADUser -Filter * -SearchBase «DC=domain1,DC=ru» -Server $dserver  | select -ExpandProperty SamAccountName

 

$dserver = «domain2.ru»

$list2= Get-ADUser -Filter * -SearchBase «DC=domain2,DC=ru» -Server $dserver  | select -ExpandProperty SamAccountName

 

$listconflict = $list1 | ? {$list2 -contains $_ }

 

Миграция лесов и Sharepoint 2010


(Продолжение Миграция лесов и Sharepoint 2010. Часть 2.)

При миграции из одного леса в другой традиционно используется ADMT Active Directory Migration Toolkit. Этот инструмент позволяет мигрировать не только учетные записи пользователей, но и компьютеры и профили пользователей. Вот только он не мигрирует приложения. Поэтому для каждого приложения надо найти свой путь миграции. Такие инструменты есть, например, для Exchange Server. А вот как быть с Sharepoint? Если пользователю дали права на какие-то ресурсы в Sharepoint, то после миграции он теряет к ним доступ.  А если на пользователя в Sharepoint назначены права на десятки сайтов, сотни библиотек, то как быть? Назначать права заново каждому пользователю (а их может быть несколько тысяч)? Это же десятки и сотни тысяч операций – очень трудоемко!

Читать далее