Archive for January, 2013

Brakujące konto FederatedEmail.4c1f4d8b-8179-4148-93bf-00a95fa1e042@domena i nieudana instalacja Exchange 2010

0
Podczas instalacji serwera Exchange Server 2010 w środowisku mieszanym (Exchange Server 2007, Exchange Server 2003) pojawił się problem podczas instalacji roli Hub Transport lub Client Access. Problem związany jest z brakiem lub problemem z wbudowanym kontem email FederatedEmail.4c1f4d8b-8179-4148-93bf-00a95fa1e042@domena.
“This problem occurs because the federated built-in e-mail account that links to the computer account no longer exists. Or, the federated built-in e-mail account in the Active Directory directory service is corrupted.”
Żeby instalator przeszedł trzeba konto zweryfikować konto z poziomu ADSIEdita, a najlepiej utworzyć je od nowa, bo pewnie ktoś je usunął :). By default jest ono tworzone podczas przygotowania środowiska AD za pomocą setup /prepareAD.
Konta można wyciągnąć PowerShellem:
Get-Mailbox –Arbitration
Jak zatem naprawić problem z usuniętym lub uszkodzonym kontem FederatedEmail?
1) Konto mogło być wyłączone – wtedy możemy wydać polecenie: Enable-Mailbox SystemMailbox{e0dc1c29-89c3-4034-b678-e6c29d823ed9} –Arbitration. Problem zostaje naprawiony.
2) Jeśli konto jest włączone i nie działa możemy utworzyć je na nowo – usuwamy FederatedEmail.4c1f4d8b-8179-4148-93bf-00a95fa1e042 z poziomu ADSIEDIT. Default Naming Context i lokalizujemy kontener CN=Users. Usuwamy konto.
3) Teraz możemy wykonać PowerShella, który utworzy nam konto: New-Mailbox -Arbitration -Name FederatedEmail.4c1f4d8b-8179-4148-93bf-00a95fa1e042 -UserPrincipalName FederatedEmail.4c1f4d8b-8179-4148-93bf-00a95fa1e042@<Default_Accepted_Domain> lub Setup.Com /PrepareAD.
Podobna procedura obowiązuje, jeśli ktoś przypadkiem usunie nam konta systemowe Exchange:

– FederatedEmail.4c1f4d8b-8179-4148-93bf-00a95fa1e042”

-“SystemMailbox{1f05a927-8668-4003-adad-9b80758e86db}”

– “SystemMailbox{e0dc1c29-89c3-4034-b678-e6c29d823ed9}”

Exchange Server 2010 SP2 RU5 v.2 ended prematurely because of an error. Your system has not been modified…

0

Ostatnio natknąłem się na dany problem przy aktualizacji serwerów z rolą CAS na Exchange Server 2010 SP2 (bez Rollup Updates) do zbiorczego zestawu aktualizacji Rollup Update 5 version 2. Uruchomiłem instalator .msp  z uprawnieniami użytkownika będącego w grupie Enterprise Admin, Domain Admins, Exchange Organization Admin, itd., czyli wszelkie wymagane uprawnienia. Niestety widać, że instalator pomija fazę tworzenia obrazów macierzystych dla zestawów .NET.

Po zainstalowaniu tego pakietu zbiorczego aktualizacji na komputerze, który nie jest połączony z Internetem, mogą pojawić się instalacji długie czasy. Ponadto może zostać wyświetlony następujący komunikat: “Tworzenie obrazów macierzystych dla zestawów .net.” – u mnie wyglądało to tak, że tak etap został pominięty (pytanie dlaczego)?

Diagnozę rozpocząłem od kilku rzeczy:

1) sprawdzenie Event Loga – pojawił się błąd informujący o nieudanej instalacji Rollup Update 🙂

2) przeanalizowałem zawartość loga ServiceControl.log z lokalizacji C:\ExchangeSetupLogs

3) przeanalizowałem zawartość loga UpdateOwa.log z lokalizacji C:\ExchangeSetupLogs.

W pliku ServiceControl.log znalazłem wpisy informujące o niewystarczających uprawnieniach do przeprowadzenia tej operacji. Podążając tym tropem uruchomiłem PowerShella w trybie Run as Administrator i z tego poziomu uruchomiłem plik instalatora .msp. Pliku .msp niestety nie można wykonać w trybie Run As.., więc zrobiłem to z PowerShella i zadziałało. Instalacja przebiegła prawidłowo.

Rozwiązanie problemu:

Powershell (Run As Administrator) i uruchamiamy instalator .msp.

Go to Top