Подводные камни миграции с SharePoint 2013 на SharePoint 2019

[AndrewBond]

Странная какая-то инструкция, ну да ладно. Дополню чуть-чуть.

1. Практически Sharepoint можно обновлять с 2013 до 2019 напрямую. Более того, можно обновлять чуть ли не с 2010 напрямую. По крайней мере, сайты, работающие на 2013 в режиме совместимости с 2010 прекрасно обновляются сразу на 2019. Для этого в таблице AllSites в записях значение поля PlatformVersion меняется на 15.0.35.0. Затем запускается Test-SPContentDatabase и т.д.

   Проверено на десятках баз с десятками кастомных WSP.

2. Если версия Windows Server меньше 2019, может не ставиться NET 3.5, сообщая, что на сервере уже есть более новая версия. Для обхода этой ошибки в реестре меняется версия в HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4 на что-то, начинающееся с 4.5. После установки возвращается та версия, что была до этого.

3. На сервере, начиная с версии 2019 можно сократить подготовку, запустив пару команд:
   Import-Module ServerManager

   Add-WindowsFeature Net-Framework-Features,Web-Server,Web-WebServer,Web-Common-Http,Web-Static-Content,Web-Default-Doc,Web-Dir-Browsing,Web-Http-Errors,Web-App-Dev,Web-Asp-Net,Web-Net-Ext,Web-ISAPI-Ext,Web-ISAPI-Filter,Web-Health,Web-Http-Logging,Web-Log-Libraries,Web-Request-Monitor,Web-Http-Tracing,Web-Security,Web-Basic-Auth,Web-Windows-Auth,Web-Filtering,Web-Digest-Auth,Web-Performance,Web-Stat-Compression,Web-Dyn-Compression,Web-Mgmt-Tools,Web-Mgmt-Console,Web-Mgmt-Compat,Web-Metabase,WAS,WAS-Process-Model,WAS-NET-Environment,WAS-Config-APIs,Web-Lgcy-Scripting,Windows-Identity-Foundation,Server-Media-Foundation,Xps-Viewer –Source <путь к sxs>

4. Если просто запустить установку пререквизитов, врядли что-то получится, большинство пакетов устаревшие и убраны с сайта MS. Храните их локально и ставьте одной командой:
   .\prerequisiteinstaller.exe /SQLNCli:d:\2019\prereq\sqlncli.msi
   /Sync:d:\2019\prereq\Synchronization.msi
   /AppFabric:d:\2019\prereq\WindowsServerAppFabricSetup_x64.exe
   /IDFX11:d:\2019\prereq\MicrosoftIdentityExtensions-64.msi
   /MSIPCClient:d:\2019\prereq\setup_msipc_x64.exe
   /WCFDataServices56:d:\2019\prereq\WcfDataServices56.exe
   /MSVCRT11:d:\2019\prereq\vcredist_x64.exe
   /MSVCRT141:d:\2019\prereq\vc_redist.x64.exe
   /KB3092423:d:\2019\prereq\AppFabric-KB3092423-x64-ENU.exe
   /DotNet472:d:\2019\prereq\NDP472-KB4054530-x86-x64-AllOS-ENU.exe

5. Самый быстрый способ восстановить сайт (базы предварительно импортированы):
   $wa = New-SPWebApplication -Name "SP2019" -ApplicationPool "SP2019AppPool" -ApplicationPoolAccount DOMAIN\SP2019AppPool -HostHeader sp2019 -Url http://sp2019 -Port 80 -Path C:\Inetpub\wwwroot\wss\VirtualDirectories\sp2019
$wa= Get-SPWebApplication http://sp2019
Mount-SPContentDatabase -WebApplication $wa wss_content

6. Перед миграцией будет нелишним сохранить кастомные WSP одной командой, затем так же одной командой их восстановить (есть нюансы)

7. Если на старом сайте были внешние подключения, нужно озаботиться бэкапом и восстановлением ключей Secure store

8. Сервис метаданных мигрируется восстановленим старой базы и запуском команд:$ap = New-SPServiceApplicationPool -Name "MetadataAppPool" -Account DOMAIN\SP2019AppPool
$mmsa = New-SPMetadataServiceApplication -Name "2019 Metadata Service" -ApplicationPool $ap -DatabaseName "WSS_Metadata"
New-SPMetadataServiceApplicationProxy -Name "2019 Metadata Service" -DefaultProxyGroup -ServiceApplication $mmsa
Get-SPServiceInstance | where-object {$.TypeName -eq "Managed Metadata Web Service" -and $.Server -eq $srv1} | Start-SPServiceInstance

9. Остальные сервисы восстанавливаются приблизительно так же.

10. Не потеряйте passphrase, пригодится при добавлении серверов в ферму.

11. В целом, даже сложный сайт можно мигрировать одним скриптом (двумя. бэкап-восстановление баз отдельным SQL-скриптом. Но, наверное, можно было и powershell)
    

Это что навскидку вспомнил

[ioccy]

Когда коммент лучше, чем статья

[chistyakov1907]

Спасибо за развернутый комментарий.

У нас была попытка скриптами (минимальным их количеством) сделать перенос, но жизнь оказалась куда суровее, и многие вещи пришлось делать вручную. Хотя по итогу некоторые блоки работы и были объединены в скрипты.

В пункте 6 вы написали, что есть нюансы по восстановлению кастомных wsp пакетов. У нас с кастомными пакетами как раз по минимуму было проблем, хотя в некоторых из них пришлось делать изменения в плане совместимости версий, но это в любом случае требуется. Можно даже сначала установить обновленные пакеты на текущую ферму 2013, проверить, что они работают, а потом произвести их экспорт\импорт в 2019. А вы с какими нюансами пакетов wsp сталкивались?

[AndrewBond]

Про нюансы я чтобы не отвлекаться написал. На самом деле, всего лишь проверяется, не является ли wsp солюшеном уровня приложения (if(!$solution.ContainsWebApplicationResource)), и всё. Такие ставятся отдельно с указанием конкретных приложений. Остальные - циклом foreach.

Для остальных донастроек - Post-deploy congif на уровне wsp.

Если при миграции меняются версии dll солюшенов, в web.config дописываются совместимости, чтобы вебчасти не полетели. Типа такого:

      <dependentAssembly>
        <assemblyIdentity name="SPSolution" publicKeyToken="1234465e5b2fb35" culture="neutral" />
        <bindingRedirect oldVersion="15.0.0.0" newVersion="16.0.0.0" />
      </dependentAssembly>

В целом, основной скрипт миграции выполняет до 90% работы, остатки - в отдельных скриптах (миграция поиска или создание службы поиска). Просто чтобы разделить стадии.

[evgeny_sss]

вот и он, старый добрый Шарик :))) а как лицухи-то планируете покупать? :)))

[AndrewBond]

До 2019 можно пользоваться старыми корпоративными :)