На днях “поймал” интересную ошибку в SCSM. При установке дополнительных серверов управления я получал ошибку “An error occurred while executing a custom action:RollbackCleanup” (“При выполнении настраиваемого действия произошла ошибка:RollbackCleanup” в русском варианте). Ошибки из серии RollbackCleanup всегда не просто диагностировать, т.к. происходит она в самом конце установки, и лог-файл установки получается довольно объемным.

При диагностике, на основном сервере управления в журнале Operaions Manager нашел следующую ошибку:

Log Name:      Operations Manager
Source:        OpsMgr SDK Service
Date:          10/12/2011 10:34:50 PM
Event ID:      26319
Task Category: None
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      *****************
Description:
An exception was thrown while processing UpsertUserRoles for session ID uuid:d74fa9f5-6f1f-43c2-b4a3-566278dfc6be;id=648.
Exception message: The creator of this fault did not specify a Reason.
Full Exception: System.ServiceModel.FaultException`1[Microsoft.EnterpriseManagement.Common.UserRoleUserUnresolvedException]: The creator of this fault did not specify a Reason. (Fault Detail is equal to Microsoft.EnterpriseManagement.Common.UserRoleUserUnresolvedException: Не удалось разрешить пользователя NT AUTHORITY\Authenticated Users, связанного с данной ролью пользователя. Код ошибки 1332. Проверьте конфигурацию Active Directory.).

После исследования лог-файла такая же ошибка была найдена и в нем:

Service Manager Role GUID: 0CDDEB2B-5AC7-4E9b-8918-F73A5A5DC5FA
Account to add: S-1-5-11
Account to add: NT AUTHORITY\Authenticated Users
AddUserGroupToSmRole: Error: Не удалось разрешить пользователя NT AUTHORITY\Authenticated Users, связанного с данной ролью пользователя. Код ошибки 1332. Проверьте конфигурацию Active Directory.
StackTrace:    at Microsoft.EnterpriseManagement.Common.Internal.ServiceProxy.HandleFault(String methodName, Message message)
   at Microsoft.EnterpriseManagement.Common.Internal.SecurityConfigurationServiceProxy.UpsertUserRoles(ICollection`1 urUpdateResults, ICollection`1 urScopeUpdateResults, ICollection`1 urViewScopeUpdateResults, ICollection`1 urTaskScopeUpdateResults, ICollection`1 urConsoleTaskScopeUpdateResults, ICollection`1 urTemplateScopeUpdateResults, ICollection`1 urUserUpdateResults)
   at Microsoft.EnterpriseManagement.SecurityConfigurationManagement.UpdateUserRoles(ICollection`1 userRoles)
   at Microsoft.EnterpriseManagement.Security.UserRole.Update()
   at Microsoft.MOMv3.Setup.MOMv3ManagedCAs.AddUserGroupToSmRole(Session session)

После чего проблема прояснилась. Дело в том, что при установке дополнительного сервера происходит перестроение ролей для передачи в Authorization Manager. К сожалению, этот процесс не документирован, и я лишь могу догадываться, что происходит “за сценой”. Но суть в том, что SDK не работает с SID-ами пользователей, а получает их имена из ролей SCSM. И обработка ролей происходит на основной сервере в текстовом виде.

В моем случае учетная запись, от имени которой запускалась служба SCSM на основном сервере, имела русский язык интерфейса. Но более важно, что и системная локаль (язык UI для системной учетной записи) была выставлена в русский. А в этом случае имя специальной группы  “NT AUTHORITY\Authenticated Users” (как и вообще всех специальных учетных записей) также локализовано и выглядит как “NT AUTHORITY\Прошедшие проверку”, а инсталлятор пытался передать её в виде текста “NT AUTHORITY\Authenticated Users”.

Собственно, для исправления ситуации необходимо зайти в региональные настройки на основном сервере SCSM, для текущей учетной записи установить английский язык для интерфейса (потребуется перелогиниться), а затем скопировать эти настройки для системной учетной записи, чтобы стало как на картинке:

После этого потребуется перегрузка. Для текущей учетной записи настройки языка интерфейса можно вернуть обратно.

После этого установка дополнительных серверов SCSM проходит в штатном режиме.

PS. Спасибо Тёме за помощь и моральную поддержку )

Tweet