Удаление старых топологий поиска в Sharepoint


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


$ssa = Get-SPEnterpriseSearchServiceApplication

$ssa.Topologies | ? {$_.State -eq "Inactive"} }

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


$ssa.Topologies | ? {$_.State -eq "Inactive"} | % {$_.Delete()}

Реклама

SharePoint и обновление временных зон


Еще раз о переводе времени. Нужны некоторые ручные правки в файлах Sharepoint 2013, чтобы появились новые временные зоны для России. Официальный патч на текущий момент отсутствует. Решение можно найти по ссылке https://rzhevsky.wordpress.com/2014/10/22/tzupdate-sharepoint/

Sharepoint Server 2013 и группы Active Directory


Чем проще ситуация, тем иной раз дольше соображаешь, как с ней справиться. Вот на днях нужно было настроить доступ к ресурсу на Sharepoint Server 2013 для пользователей, которые внесены в группу Active Directory. Вообще для Sharepoint предоставление доступа на основе групп AD рекомендуется при большом количестве пользователей: это увеличивает производительность. После настройки доступа и проверки, что он работает, прошло какое-то время, и от пользователей пришла жалоба: «Нет доступа». Выясняется странная ситуация: у части пользователей доступ есть, у части пользователей доступа нет. Причём все они в группе AD присутствуют. Читать далее

Exchange Server 2013 – High Resolution Photo. Разрешение фотографий.


Сводка используемых в клиентах Outlook, Lync и Sharepoint разрешений фотографий. Читать далее

Exchange Server 2013 – High Resolution Photo. Синхронизация.


Общая схема работы High Resolution Photo довольна проста: настраивается интеграция Exchange, Sharepoint и Lync, фотографии хранятся в Exchange, а Sharepoint и Lync используют их. Но как это работает внутри? Оказывается, существуют интересные нюансы. Читать далее

Миграция лесов и 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

 

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


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

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

Читать далее