Резервное копирование фермы SharePoint 2016 от имени учётной записи gMSA и решение ошибок "The local farm is not accessible. Cmdlets with FeatureDependencyId are not registered" и "Object Search Service Application failed in event OnBackup"

SharePoint 2016 Backup scriptВ одной из прошлых заметок мы рассматривали пример скриптовой реализации задачи полного резервного копирования фермы SharePoint Server 2013. И в этом примере скрипт выполнялся в контексте учётной записи фермы (SharePoint Farm service account). В этой заметке мы рассмотрим решение аналогичной задачи применительно к SharePoint Server 2016, но вместо учётной записи фермы будем использовать выделенную управляемую служебную учетную запись Group Managed Service Account (gMSA).

Сразу отмечу тот факт, что никаких принципиальных отличий в самом ранее рассматриваемом скрипте резервного копирования при использовании в SharePoint Server 2016 нет. Основные нюансы, на которые мы обратим внимание в данной заметке, касаются особенностей выполнения задачи в контексте учётной записи gMSA и настройки прав доступа, требуемых для выполнения задачи.


Создание и установка учётной записи gMSA

Создание и установка учётной записи gMSA на сервере SharePoint, где планируется выполнять резервное копирование фермы, производится с помощью стандартных процедур, описанных в Вики.

В нашем примере для выполнения задачи резервного копирования фермы в домене Active Directory создана учётная запись gMSA с именем KOM\s-S02$.



Выдача прав локального администратора на сервере SharePoint

Установленную учётную запись gMSA в первую очередь необходимо включить в локальную группу администраторов на сервере SharePoint.

Add gMSA account to Local Administrators group in SharePoint Server

Если этого не сделать, то при попытке выполнения вызова командлета Backup-SPFarm из под учётной записи gMSA мы получим ошибку "You need to have Machine administrator priviliges to run this cmdlet"

SharePoint 2016 Backup-SPFarm error You need to have Machine administrator priviliges to run this cmdlet



Выдача привилегии SPShellAdmin 

Далее, не смотря на то, что наша сервисная учётная запись gMSA включена в группу локальных администраторов на сервере SharePoint WFE, при попытке проверочного запуска скрипта мы получим ошибку "The local farm is not accessible. Cmdlets with FeatureDependencyId are not registered" с последующей ошибкой "Backup-SPFarm : Object reference not set to an instance of an object"

SharePoint 2016 Backup-SPFarm error Object reference not set to an instance of an object

Данная ошибка может возникать безотносительно нашей задачи резервного копирования, при любой попытке обращения к ферме SharePoint Server через командлеты PowerShell от имени учётной записи, отличной от учётной записи фермы.

Связано это с тем, что для возможности использования PowerShell-командлетов на уровне фермы SharePoint Server, требуется отдельная привилегия SPShellAdmin (в системе безопасности баз данных SQL Server для SharePoint фигурирует, как роль SharePoint_Shell_Access).

Чтобы проверить список учётных записей, имеющий соответствующую привилегию, в консоли SharePoint 2016 Management Shell выполним команду:

Get-SPShellAdmin

Выдаём привилегию нашей служебной учётной записи gMSA и проверяем результат:

Add-SPShellAdmin -UserName KOM\s-S02$
Get-SPShellAdmin

SharePoint Add-SPShellAdmin

Однако без явного указания дополнительных параметров командлет Add-SPShellAdmin даст доступ только к конфигурации фермы, то есть учётная запись gMSA на уровне SQL Server будет добавлена в соответствующую роль к базе данных SharePoint_Config.

Чтобы дать доступ сразу для всех баз SharePoint, в том числе и контентых, потребуется выполнить команду типа:

Get-SPDatabase | ForEach-Object {Add-SPShellAdmin -UserName "KOM\s-S02$" -Database $_.Id}

Add-SPShellAdmin for all SharePoint databases


Назначение роли db_backupoperator на БД в SQL Server

Практика показала, что привилегии SPShellAdmin на уровне SQL Server всё же может не хватать, и это может вызывать дополнительные ошибки доступа к БД в ходе работы скрипта резервного копирования. Этот вопрос решается путём добавления роли db_backupoperator для учётной записи gMSA по каждой базе данных SharePoint.

Add gMSA user to SQL Server role db_backupoperator

Однако это ещё не всё.


Права доступа к каталогу размещения резервных копий

Уже после выдачи обозначенных выше привилегий, при очередном проверочном запуске скрипта резервного копирования, на этапе резервного копирования компонент поиска, мы снова можем получать ошибки типа:

[FatalError] Object Search Service Application failed in event OnBackup. For more information, see the spbackup.log or sprestore.log file located in the backup directory.
    FaultException: Management called failed with System.InvalidOperationException: 'Job failed: Have tried to perform backup/restore operation twice on all in-sync members in cluster SP25f34bf8b977.0, but none succeeded. Last failure message: Microsoft.Ceres.SearchCore.Seeding.SnapshotTransferException: Could not send chunk ms\%default\gen.0000000000000007.state: Localpath: [0-2426> to target BackupDirectoryTarget[directory=\\FS01\BACKUP-SharePointFarm$\KOM-WEB1\spbr0003\I.Part.0\FastServer.Ix.0\I.0.0,validateTransfers=False]
   at Microsoft.Ceres.SearchCore.Seeding.SnapshotSender.SendChunks(ISnapshot snapshot, ISeedSource source, ISeedTarget target, SeedStatus status, Func`1 checkAborted, Int32 targetFragIndex)
   at Microsoft.Ceres.SearchCore.Seeding.SnapshotSender.FirstPhaseTransfer(ISeedSource source, ISeedTarget target, Action`1 updateProgress, Func`1 shouldAbort)
   at Microsoft.Ceres.SearchCore.Seeding.BackupWorker.BackupWork.DoFirstPhaseWork()' at    at Microsoft.Ceres.SearchCore.IndexController.BackupService.ThrowOnFailure(JobStatus status)
   at Microsoft.Ceres.SearchCore.IndexController.BackupService.ProgressFirstPhase(String handle)
   at Microsoft.Ceres.SearchCore.IndexController.IndexControllerManagementAgent.WrapCall[T](Func`2 original)

...

[FatalError] Object Search_Service_Application_DB_cc511d419edd4eb695be5f0f5975bdae failed in event OnBackup. For more information, see the spbackup.log or sprestore.log file located in the backup directory. Aborted due to error in another component.
...

[FatalError] Object Crawl-0 (C: on KOM-WEB1) failed in event OnBackup. For more information, see the spbackup.log or sprestore.log file located in the backup directory. Aborted due to error in another component.

Возникло предположение, что это как-то может быть связано со спецификой работы служб поиска SharePoint, которые в конфигурации по умолчанию работают от имени учётной записи фермы. И только после того, как учётной записи фермы дополнительно были выданы полные права на целевой каталог размещения резервных копий (на уровне ACL NTFS и SMB), скрипт резервного копирования отработал без ошибок.

В итоге получилось, что на каталог размещения резервных копий требуется выдать полные права для:

  • Учетной записи, от имени которой выполняется скрипт. В нашем случае это учётная запись gMSA;
  • Учётной записи, от имени которой выполняется служба экземпляра SQL Server, в котором размещены базы данных SharePoint;
  • Учётной записи, от имени которой выполняется служба SharePoint Timer Service (SPTimerV4). Как правило, это учётная запись фермы (SharePoint Farm service account).

Такой требуемый набор прав доступа подтверждает и старая статья Backup failed due to insufficient permissions - Event 3353 (SharePoint 2010 Products).

После всех предоставленных прав, скрипт резервного копирования фермы SharePoint Server 2016 от имени выделенной учётной записи gMSA отработал успешно.

Success Backup-SPFarm as gMSA


Отладка процедуры резервного копирования

В случае возникновения проблем при выполнении скрипта резервного копирования фермы SharePoint, полезным может оказаться лог-файл spbackup.log, создаваемый командлетом Backup-SPFarm. Однако, учитывая то обстоятельство, что в конфигурации по умолчанию этот командлет пытается выполнять резервное копирование сразу в 3 потока, сбивчивый порядок появления записей в логе-файле может приводить к затруднению читаемости лога. В этом случае на время отладки работы скрипта в строке вызова командлета Backup-SPFarm достаточно добавить параметр, определяющий количество потоков выполнения -BackupThreads:

...
Backup-SPFarm -Directory $BackupFolder -BackupMethod Full -Verbose -BackupThreads 1 -Percentage 25
...

Задача планировщика Windows Task Scheduler

Настроить в планировщике Windows Task Scheduler периодический запуск скрипта в контексте учётной записи gMSA в Windows Server 2012 R2 можно только с помощью PowerShell. В нашем случае команды создания задачи будут выглядеть следующим образом:

$Action = New-ScheduledTaskAction -Execute "PowerShell.exe" -Argument "-NoProfile -command `"C:\Scripts\SP2016-Farm-Full-Backup.ps1`""
$Trigger = New-ScheduledTaskTrigger -Daily -At 5:30
$SvcUser = New-ScheduledTaskPrincipal -UserID KOM\s-S02$ -LogonType Password
Register-ScheduledTask -TaskName "SharePoint - Full Farm Backup" -TaskPath "\IT" -Action $Action -Trigger $Trigger -Principal $SvcUser

 New Scheduled Task with gMSA in PowerShell

Дополнительные примеры создания и настройки заданий планировщика от имени учётной записи gMSA можно найти в отдельной статье Вики.

Только один комментарий Комментировать

  1. Алексей Максимов / Автор записи

    Решение применимо к SharePoint Server 2016/2019

Добавить комментарий