Error:
The following error was generated when "$error.Clear();
         $name = [Microsoft.Exchange.Management.RecipientTasks.EnableMailbox]::DiscoveryMailboxUniqueName;
         $dispname = [Microsoft.Exchange.Management.RecipientTasks.EnableMailbox]::DiscoveryMailboxDisplayName;
         $dismbx = get-mailbox -Filter {name -eq $name} -IgnoreDefaultScope -resultSize 1;
         if( $dismbx -ne $null)
         {
         $srvname = $dismbx.ServerName;
         if( $dismbx.Database -ne $null -and $RoleFqdnOrName -like "$srvname.*" )
         {
         Write-ExchangeSetupLog -info "Setup DiscoverySearchMailbox Permission.";
         $mountedMdb = get-mailboxdatabase $dismbx.Database -status | where { $_.Mounted -eq $true };
         if( $mountedMdb -eq $null )
         {
         Write-ExchangeSetupLog -info "Mounting database before stamp DiscoverySearchMailbox Permission...";
         mount-database $dismbx.Database;
         }

         $mountedMdb = get-mailboxdatabase $dismbx.Database -status | where { $_.Mounted -eq $true };
         if( $mountedMdb -ne $null )
         {
         $dmRoleGroupGuid = [Microsoft.Exchange.Data.Directory.Management.RoleGroup]::DiscoveryManagement_InitInfo.WellKnownGuid;
         $dmRoleGroup = Get-RoleGroup -Identity $dmRoleGroupGuid -DomainController $RoleDomainController -ErrorAction:SilentlyContinue;
         if( $dmRoleGroup -ne $null )
         {
           trap [Exception]
           {
             Add-MailboxPermission $dismbx -User $dmRoleGroup.Name -AccessRights FullAccess -DomainController $RoleDomainController -ErrorAction SilentlyContinue;
             continue;
           }
           
           Add-MailboxPermission $dismbx -User $dmRoleGroup.Identity -AccessRights FullAccess -DomainController $RoleDomainController -WarningAction SilentlyContinue;
         }
         }
         }
         }
       " was run: "Microsoft.Exchange.Data.Common.LocalizedException: Couldn't resolve the user or group "gencom.tatenergo.corp/Microsoft Exchange Security Groups/Discovery Management." If the user or group is a foreign forest principal, you must have either a two-way trust or an outgoing trust. ---> System.SystemException: The trust relationship between the primary domain and the trusted domain failed.

  at System.Security.Principal.NTAccount.TranslateToSids(IdentityReferenceCollection sourceAccounts, Boolean& someFailed)
  at System.Security.Principal.NTAccount.Translate(IdentityReferenceCollection sourceAccounts, Type targetType, Boolean forceSuccess)
  at System.Security.Principal.NTAccount.Translate(Type targetType)
  at Microsoft.Exchange.Configuration.Tasks.SecurityPrincipalIdParameter.GetUserSidAsSAMAccount(SecurityPrincipalIdParameter user, TaskErrorLoggingDelegate logError, TaskVerboseLoggingDelegate logVerbose)
  --- End of inner exception stack trace ---
  at Microsoft.Exchange.Configuration.Tasks.Task.ThrowError(Exception exception, ErrorCategory errorCategory, Object target, String helpUrl)
  at Microsoft.Exchange.Configuration.Tasks.Task.WriteError(Exception exception, ErrorCategory category, Object target)
  at Microsoft.Exchange.Configuration.Tasks.SecurityPrincipalIdParameter.GetUserSidAsSAMAccount(SecurityPrincipalIdParameter user, TaskErrorLoggingDelegate logError, TaskVerboseLoggingDelegate logVerbose)
  at Microsoft.Exchange.Configuration.Tasks.SecurityPrincipalIdParameter.GetSecurityPrincipal(IRecipientSession session, SecurityPrincipalIdParameter user, TaskErrorLoggingDelegate logError, TaskVerboseLoggingDelegate logVerbose)
  at Microsoft.Exchange.Management.RecipientTasks.SetMailboxPermissionTaskBase.InternalValidate()
  at Microsoft.Exchange.Management.RecipientTasks.AddMailboxPermission.InternalValidate()
  at Microsoft.Exchange.Configuration.Tasks.Task.<ProcessRecord>b__b()
  at Microsoft.Exchange.Configuration.Tasks.Task.InvokeRetryableFunc(String funcName, Action func, Boolean terminatePipelineIfFailed)".

Группу discovery management не может найти пишет

Лес многодоменный?

Этой рекомендации уже сто лет в обед. Это не требование, просто рекомендация. Я понимаю, что при расширении схемы штатными продуктами MS словить проблему сложно. Поэтому этому редко кто следует. Да и нужно реально кастомизировать AD под себя, чтобы проблему словить. Но рекомендация эта не взялась ниоткуда, как не сложно догадаться. Заказчики, у которых есть ресурсы и возможность, предпочитают этому следовать до сих пор.

Если поломаешь, мало не покажется. Но будет поздно уже.

Нет, один домен. Два сервера до этого обновились штатно

А третий, самый важный вот так! DAG нет

Ошибку бы полностью на какой-то ресурс

Начо очень сильно шашкой в схеме махать, чтобы что-то при штатном расширении схемы поломать

Я думаю, времена, когда кто-то шашкой махал лет 15 назад закончились

Ну...дело ваше. Вы ж сами за это ответственность несете. Если уверены - welcome. Это не значит, что данную рекомендацию не стоит в принципе озвучить 😊

Конечно уверены!

если сам ничего не кастомил в схеме, т.е. делал что-то не продуктами от MS, то ошибку не словишь, но если ты сам добавлял какие-то атрибуты или менял права там, то тут уже понятно что к расширению надо точечно подходить и всегда надо смотреть что обнова делает в схеме, ms это пишет какие атрибуты добавляются и т.д. и уже от этого смотреть, надо изолировать или нет

Я у Кибы курс про AD слушал, мне ничего не страшно!

У нас такие перлы встречаются в рамках аудита, что просто ужас. И да, история AD тянется годами

Cmdlet failed. Cmdlet Add-MailboxPermission, parameters -DomainController "dc-gencom-002.genсom.ta*.corp" -WarningAction "SilentlyContinue" -Identity "gencom.tatenergo.corp/Users/DiscoverySearchMailbox {D919BA05-46A6-415f-80AD-7E09334BB852}" -User "gencom.ta*.corp/Microsoft Exchange Security Groups/Discovery Management" -AccessRights ("FullAccess").

Ну вам за это деньги платят 😁 были бы все пряморукие - сидел бы консалтинг без работы 😁

во во

Тока не консалтинг) они за другое деньги получают)

Можно не махать, а просто иметь какое-то древнее ПО, которое это сделает за тебя)