Jeśli jesteś właścicielem tej strony, możesz wyłączyć reklamę poniżej zmieniając pakiet na PRO lub VIP w panelu naszego hostingu już od 4zł!
Strony WWWSerwery VPSDomenyHostingDarmowy Hosting CBA.pl

Office 365 – Exchange Online – rozwiązania często spotykanych problemów

  08 sierpień 2014
Oceń ten artykuł
(0 głosów)

Używając usługi Exchange Online napotykamy na szereg problemów, wynikających z innej logiki działania, naszej niewiedzy związanej z nowym środowiskiem i zmian, które zachodzą ciągle w usłudze firmy Microsoft. 

Części z nich można jednak uniknąć, inne wymagają od administratora odpowiedniego działania, które postaram się tutaj opisać na podstawie własnych doświadczeń.

Większość z przedstawionych problemów miało miejsce w środowisku hybrydowym, gdzie serwery Exchange 2010/2013 zainstalowane fizycznie połączone są z usługą Exchange Online. Obiekty Active Directory są replikowane a skrzynki pocztowe można swobodnie przenosić między serwerami w siedzibie („on premises”) i w chmurze Microsoftu.

Podczas czytania tych porad należy pamiętać, że z biegiem czasu mogą stracić aktualność z uwagi na ciągłe doskonalenie i wprowadzanie zmian w usłudze Office 365 przez firmę Microsoft.

• Nie można usunąć domeny z listy domen Office 365 

Jeżeli chcesz usunąć domenę dodatkową (domeny domyślnej w postaci firma.mail.onmicrosoft.com nie można usunąć), według zaleceń firmy Microsoft musisz usunąć wszystkie powiązania. Chodzi o konta użytkowników, grupy dystrybucyjne i inne obiekty korzystające z domeny. Nie jest to do końca prawdą. 

Rozwiązanie: 

Wystarczy usunąć wszystkie adresy SMTP i SIP domeny z obiektów, a użytkownikom przypisanym do domeny wyłączyć licencje.

Następnie należy połączyć się przy użyciu powershella do usługi Office365 oraz wykonać sprawdzenie:

Get-MsolUser -DomainName twojadomena.pl

oraz

Get-MsolGroup -All | where {$_.proxyaddresses -match "twojadomena.pl"}

Jeżeli listy wyników okażą się puste, powinno udać się usunąć domenę.

• Nie można zmigrować skrzynki z serwera w siedzibie do serwera Office 365 

Podczas próby migracji skrzynki do chmury pojawia się błąd: 

“The operation couldn't be performed because object couldn't be found on…”

Prawdopodobnie istnieje już obiekt o tej samej nazwie, lecz posiada inne atrybuty (ExchangeGuid). Możliwe, że ktoś przypisał użytkownikowi licencję Exchange Online przed przeniesieniem skrzynki, co skutkuje założeniem nowej, w chmurze i brakiem możliwości migracji.

Rozwiązanie: 

Należy usunąć obiekt z Office365.

Należy połączyć się z usługą Office365 za pomocą powershella oraz wykonać dwa polecenia:

Remove-MsolUser -UserPrincipalName uż Ten adres pocztowy jest chroniony przed spamowaniem. Aby go zobaczyć, konieczne jest włączenie w przeglądarce obsługi JavaScript.

Remove-MsolUser -UserPrincipalName uż Ten adres pocztowy jest chroniony przed spamowaniem. Aby go zobaczyć, konieczne jest włączenie w przeglądarce obsługi JavaScript. -RemoveFromRecycleBin


Po usunięciu problematycznej skrzynki, dokonać ponownej synchronizacji DirSync, lub poczekać aż dane zreplikują się same. Ponowna migracja powinna być już możliwa.

• Nie można zmigrować skrzynki z serwera w siedzibie do serwera Office 365. 

Pojawia się błąd: 

The call to 'https://xxx.twojadomena.pl/EWS/mrsproxy.svc' failed. Error details: The HTTP request is unauthorized with client authentication scheme 'Negotiate'. The authentication header received from the server was 'Negotiate,NTLM,Basic realm="xxx.twojadomena.pl"'. --> The remote server returned an error: (401) Unauthorized.. + CategoryInfo : NotSpecified: (:) [New-MoveRequest], RemoteTrans ientException + FullyQualifiedErrorId : [Server=DBXPR99MB999,RequestId=something,TimeStamp=1/20/2014 1:13:53 PM] [FailureCategory=Cmdle t-RemoteTransientException] B92B1723,Microsoft.Exchange.Management.Recipie ntTasks.NewMoveRequest + PSComputerName : pod999999psh.outlook.com

Powodów takiego błędu może być kilka, jednak w moim przypadku były dwa: Office365 przyjmuje poświadczenia tylko w postaci „Domena.lokalna\nazwa użytkownika” oraz drugim razem ten sam błąd spowodowało wygasłe hasło w punkcie końcowym migracji.

Rozwiązanie 1: 

Sprawdzić czy konto użytkownika służące do powiązania organizacji punktem końcowym działa prawidłowo

1. Sprawdzenie, które konto jest odpowiedzialne za połączenie organizacji punktem migracji:

 

Z poziomu powershell:

Get-MigrationEndpoint |fl

W polu User znajdują się dane o koncie użytkownika.

Z poziomu Office365:

W oknie nawigacji centrum administracyjnego usługi Exchange Online, w zakładce adresaci/migracja, w prawym dolnym rogu znajdziemy „skojarzony punkt końcowy”. Klikamy na „Pokaż szczegóły”. 

 

W polu „skojarzony administrator” znajduje się nazwa użytkownika.

2. Należy sprawdzić w panelu użytkowników Active Directory, czy konto nie jest zablokowane, a hasło jest ustawione na niewygasanie, bądź czy zostało zmienione.

3. Jeżeli trzeba zmienić konto lub hasło, wchodzimy poprzez przeglądarkę do Office365, w opcję Skojarzony administrator: „Aktualizuj” (pkt. 1). Wpisujemy dane logowania użytkownika.

Rozwiązanie 2: 

Zalogować się loginem domena.lokalna\użytkownik do procesu migracji.

1. Zapisujemy poświadczenia do Office365:

$cred = Get-Credential 

Gdy pojawi się okienko logowania podajemy dane w formacie uż Ten adres pocztowy jest chroniony przed spamowaniem. Aby go zobaczyć, konieczne jest włączenie w przeglądarce obsługi JavaScript. .

2. Następnie uruchamiamy sesję:

$Session = New-PSSession -ConfigurationName Microsoft.Exchange
-ConnectionUri https://ps.outlook.com/powershell/ -Credential $cred 
-Authentication Basic -AllowRedirection 
Import-PSSession $Session
 


3. Po połączeniu do Office365 zapisujemy nowe poświadczenia, do domeny lokalnej: 

$cred=get-credential Tutaj podajemy poświadczenia w formacie firma.internal\jan.kowalski 

4. Uruchamiamy migrację skrzynki: 

New-MoveRequest -identity użytkownik -Remote -RemoteHostName 
poczta.twojadomena.pl -TargetDeliveryDomain firma.mail.onmicrosoft.com 
-RemoteCredential $cred
 


• Nie można skonfigurować automatycznie profilu użytkownika programu Outlook tylko dla niektórych użytkowników. 

Rozwiązanie: 

1. Aktualizacje systemu Windows dla Outlooka: powinny być zastosowane ServicePack2 dla pakietu Office2010, ServicePack3 dla Office2007. 
2. Ustawienia połączeń proxy Outlooka. Oto prawidłowe:


3. Dla środowiska hybrydowego adres routowalny skrzynki użytkownika: powinien być w domenie Ten adres pocztowy jest chroniony przed spamowaniem. Aby go zobaczyć, konieczne jest włączenie w przeglądarce obsługi JavaScript. (lub innej, domyślnej, otrzymanej od Microsoft dla całej organizacji) 

Aby to sprawdzić, na serwerze fizycznym („w siedzibie”) wykonujemy komendę: 

Get-RemoteMailbox |select name, remoteroutingaddress 

4. Dla środowiska hybrydowego z serwerem w siedzibie – atrybuty homeMDB i homeMTA konta. 

Uwaga: Do edycji używamy zaawansowanego i potężnego narzędzia ADSIEDIT, którym łatwo coś zepsuć!

a. Łączymy się do Default Naming Context
b. Szukamy obiektu użytkownika
c. Wchodzimy do edycji właściwości i szukamy atrybutów homeMDB i homeMTA.
d. Jeżeli są – kasujemy.


Przedstawione problemy, to tylko część z tych, z którymi możemy się spotkać zarządzając usługą Microsoft Office 365. Jest ona ciągle doskonalona, pojawiają się nowe funkcjonalności, np. firmowy system społecznościowy Yammer. 

Z racji przechodzenia dużej części firm do usług w chmurze, dokumentacja dostępna w Internecie jest coraz bardziej obszerna. 

W rozwiązaniu kłopotów z działaniem i zarządzaniem Office 365 w znacznej mierze może pomóc sam producent. Udostępnia on forum użytkowników oraz pomoc techniczną. Zalecany jest również kontakt z rekomendowanym partnerem Microsoft – firmą Support Online Sp. z o.o, która specjalizuje się we wdrożeniach Office 365, konfiguracjach skrzynek pocztowych oraz serwisie usługi Office 365. Dedykowany konsultant dostępny jest pod nr. tel. 22 335 28 28.

Artykuł opracował Maciej Ochal,

Źródła:

  1. Opracowanie własne
  2. http://community.office365.com

Popularne