Миграция лесов и 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 назначены права на десятки сайтов, сотни библиотек, то как быть? Назначать права заново каждому пользователю (а их может быть несколько тысяч)? Это же десятки и сотни тысяч операций – очень трудоемко!

Читать далее