Случай - перестала работать команда export-spweb. (А также некоторые размышления о том, почему важна настройка package version и настройка DeploymentServerType)
Еще один случай, который произошел у последнего клиента.
У клиента есть стороннее приложение, в котором создана веб часть и шаблон списка (list template). Судя по всему созданы для Sharepoint 2010 (14) и просто перекомпированы под SharePoint 2013. А может даже и не перекомпилированы. Исходный текст есть но я не имею права ничего менять в решении.
У клиента ферма на 4 сервера, 2 - Application Role (APP1 и APP2), 2 - Web Front End (WEB1 и WEB2)
APP1 содержит центр администрирования.
Еще одно стороннее решение выполняет гранулярный бекап, в котором внутри используется команда Export-SPWeb.
Export-SPWeb не работает.
Ошибка примерно такая
Error: Feature 'blalba-guid' for list template '100' is not installed in this farm. The operation could not be completed.
Feature blalba-guid - находится в стороннем решении и развернута!
В ходе исследования выяснилось несколько моментов.
Первый - стороне решение ставится в 14 Hive.
Что - Что? Hive?
Файлы из решения были развернуты сюда "C:\Program Files\Common Files\microsoft shared\Web Server Extensions\14\TEMPLATE\FEATURES\" но НЕ БЫЛИ развернуты сюда "C:\Program Files\Common Files\microsoft shared\Web Server Extensions\15\TEMPLATE\FEATURES\"
Кажется, что решение просто было скомпилировано с неверной опцией Compatibility (14, а должно быть 15).
Думается, что ходить и копировать файлы вручную все-таки не очень хорошая идея, так что нужно как то сказать Sharepointу, чтобы решение поставилось в 15 hive. Проще всего было бы перекомпилировать, но раз такое возможности нет, то можно установить решение вот такое командой.
Install-SPSolution -Identity <yoursolution.wsp> -AllWebApplications -GacDeployment -CompatibilityLevel {14,15}
Итак, файлы появляются в 15 Hive.
Остается одна проблема - файлы появились только на WEB1 и WEB2. Команда Export-SPWeb на них начала работать, но по-прежнему не работает на APP1/2.
Клиент запускать экспорт на фронт ендах не хочет. Там сотни гигабайт, дополнительную нагрузку на фронт енды никто не хочет.
Чтобы понять, почему же файлы не появились на веб фронтендах, давайте взглянем еще на одну настройку.
Настройка говорит нам, устанавливать ли решение на сервера с ролью Web Front End или ApplicationServer, но как Sharepoint определяет кто есть who?
Можно было бы подумать, что это server role.
https://msdn.microsoft.com/en-us/library/microsoft.sharepoint.administration.spserverrole.aspx
Но кажется,что для For SP2013 это не важно. В моем случае самое логичное объяснение в том, что Sharepoint определяет фронт енд как сервер, на котором запущена служба "Microsoft Sharepoint Foundation Web Application" service.
То есть если решение развёртывается как "WebFrontEnd" - его файлы развертываются на сервера, на которых служба "Microsoft Sharepoint Foundation Web Application" запущена.
Итого все просто - запустить службу Microsoft Sharepoint Foundation Web Application ?
Еще один тонкий момент - запуск или остановка этой службы вызывает перезапуск IIS. При этом перезапускается Центр Администрирования. Если запустить перезапуск из центра Администрирования то это может вызывать ошибку.
В этом случае запустите команду
Get-SPServiceInstance | where {$_.TypeName.Contains('Web Application')} | ft -Property Id,TypeName,Server,Status -Autosize
Найдите нужные вам экземпляры службы и запустите их командой
Start-SPServiceInstance -Identity <guid> command
Итак, кейс разрешен. Клиент доволен. То есть мы исправили версию при развертывании и добавили веб роль на серверах приложений.
Стоп! Что?
Что??
Добавили веб роль на серверах приложений.???
Верно, но при этом мы не нарушили логическую топологию. Служба "Microsoft Sharepoint Foundation Web Application" действительно запущена на серверах APP1 и APP2 но мы из не используем как Web Front Ends. Наш балансировщик просто не в курсе, что на них можно перенаправлять запросы.
Просто мы решили проблему заказчика.