Utilizatorul nu poate vizualiza informațiile liber/ocupat pentru un utilizator la distanță într-o implementare hibridă local Exchange Server și Exchange Online în Office 365

IMPORTANT: Acest articol este tradus cu ajutorul software-ului Microsoft de traducere automată și poate fi corectat prin intermediul tehnologiei Community Translation Framework (CTF). Microsoft oferă articole traduse automat, post-editate de comunitate și articole traduse de oameni, pentru a permite accesul la toate articolele din Baza noastră de cunoștințe în mai multe limbi. Articolele traduse automat și post-editate pot conține greșeli de vocabular, sintaxă și/sau gramatică. Microsoft nu este responsabil de inexactitățile, erorile sau daunele cauzate de traducerea greșită a conținutului sau de utilizarea acestuia de către clienți. Găsiți mai multe informații despre traducerea în colaborare la http://support.microsoft.com/gp/machine-translation-corrections/ro.

Faceți clic aici pentru a vizualiza versiunea în limba engleză a acestui articol: 2667844
Notă Expertul de configurare hibridă care este inclus în Consolă de gestionare Exchange în Microsoft Exchange Server 2010 nu mai este acceptată. De aceea, nu mai trebuie să utilizați expertul de configurare hibridă vechi. În schimb, utilizați expertul de configurare de hibrid Office 365 care este disponibil la http://aka.MS/HybridWizard. Pentru mai multe informații, consultați Expert de configurare hibridă Office 365 pentru Exchange 2010.
PROBLEMA
Aveți o implementare hibridă local Microsoft Exchange Server și Microsoft Exchange Online în Microsoft Office 365 în care serverul Hibrid se execută Exchange Server 2010. Cu toate acestea, utilizatorii nu pot vizualiza informațiile liber/ocupat pentru un utilizator la distanță. Când un utilizator încearcă să vedeți informațiile liber/ocupat pentru un utilizator la distanță, nu este afișat informațiile liber/ocupat. În schimb, utilizatorul poate să apară una sau mai multe dintre următoarele simptome:
  • Informațiile liber/ocupat pentru utilizatorii la distanță se afișează ca semn (#) numărul de caractere în Calendar.
  • În Outlook Web App, se afișează "eroare 5037".
  • Microsoft Outlook <FileName>-fb.log și <FileName>-as.log fișiere conțin un mesaj de eroare asemănător cu următorul:</FileName> </FileName>
    <FreeBusyResponse><ResponseMessage responseclass="Error"><MessageText>Apelantului nu are acces la datele liber/ocupat.</MessageText> <ResponseCode>ErrorNoFreeBusyAccess</ResponseCode> <DescriptiveLinkKey>0</DescriptiveLinkKey><MessageXml><> </MessageXml></ResponseMessage></FreeBusyResponse>
    xmlns = "http://schemas.microsoft.com/exchange/services/2006/errors" > Microsoft.Exchange.InfoWorker.Common.Availability.NoFreeBusyAccessException<>
    xmlns = "http://schemas.microsoft.com/exchange/services/2006/errors" > 5037<>
    xmlns = "http://schemas.microsoft.com/exchange/services/2006/errors" >Nume server<>
    xmlns = "http://schemas.microsoft.com/exchange/services/2006/errors" > https://<Server>.outlook.com/EWS/Exchange.asmx/WSSecurity<FreeBusyView> <><b00> </b00></> </FreeBusyView> </Server>
    xmlns = "http://schemas.microsoft.com/exchange/services/2006/types" > None
De exemplu, un utilizator Office 365 nu puteţi vizualiza informațiile liber/ocupat pentru un utilizator local. Cu toate acestea, alți utilizatori pot vizualiza informațiile liber/ocupat pentru acel utilizator local același.
CAUZA
Această problemă se produce dacă nume de sign-in de domeniu pentru adresa Simple Mail Transfer Protocol (SMTP) al utilizatorului care încearcă să vedeți informațiile liber/ocupat nu este inclusă printre nume de sign-in de domeniu în relație de organizație. De exemplu, atunci când executați cmdletul Test-OrganizationRelationship , se afișează următorul rezultat:
RunspaceId: a6c3799f-2ecd-4d79-ae4b-6c470ddd1dee
Identitate:
ID: LocalFederatedDomainsAreMissingFromTheRemoteOrganizationRelationsipDomains
Stare: avertisment
Descriere: Există local federativ domenii care nu sunt prezente în Listă tabel de domenii pentru
obiect relație la distanță organizației.
IsValid: adevărat
Aceasta se întâmplă dacă domeniul SMTP manual nu a fost adăugat la relația organizației. Acest lucru, de asemenea, se poate produce dacă următoarele condiții sunt adevărate:
  • Contul de utilizator Office 365 a fost creat înainte să faceți upgrade de la mediul local la Exchange Server 2010.
  • Se utilizează Expertul hibrid configurație în Exchange Server 2010 în mediul local pentru a configura federation trust.
De exemplu, nume de sign-in de domeniu Office 365 utilizatorului este contoso.com. În acest scenariu, Office 365 contul de utilizator nu are @contoso.mail.onmicrosoft.com ca unul dintre său adresele proxy. Solicitare de la mediul local utilizează @contoso.com în loc de @contoso.mail.onmicrosoft.com pentru contul de utilizator Office 365. Solicitarea este respinsă deoarece relația organizației în mediul local nu are contoso.com adăugat la acesta.
SOLUȚIE
Pentru a rezolva această problemă, editați relația organizației în mediul local pentru a include domeniul SMTP a utilizatorului care manifestă problema. Pentru aceasta, utilizați una dintre următoarele metode.

Metoda 1: Utiliza Consolă de gestionare Exchange

  1. Pe serverul Exchange local, deschideți Consolă de gestionare Exchange și apoi faceți clic pe Configurare organizaţie sub Microsoft Exchange local.
  2. Faceți clic pe fila Organizație relații și vizualizați proprietățile relației organizației.
  3. Faceți clic pe fila Extern Organizației , tastați nume de sign-in de domeniu federativ în caseta de domenii federalizat extern organizaţiei Exchange și apoi faceți clic pe Adăugare.
  4. Repetați Pasul 3 pentru fiecare domeniu pe care doriți să adăugați.
  5. Faceți clic pe OK.

Metoda 2: Utilizaţi Componentă de administrare Exchange

  1. Pe server local, deschideți Componentă de administrare Exchange.
  2. Configurați relația organizație ca o variabilă. De exemplu, executaţi următoarea comandă

    $OrgRel = Get-OrganizationRelationship Contoso
  3. Adăugare nume de domeniu suplimentare pe care doriți să variabila. De exemplu, executaţi următoarea comandă:
    $OrgRel.DomainNames += "contoso.com"
  4. Actualizați relația organizație utilizând valoarea nouă de nume de domeniu. De exemplu, executaţi următoarea comandă:
    Set-OrganizationRelationship $OrgRel.Name -DomainName $OrgRel.DomainNames
MAI MULTE INFORMAȚII
Pentru a ajuta la identificarea problemei în Office 365, urmați acești pași:
  1. Conectarea la Exchange Online utilizând remote PowerShell. Pentru mai multe informații despre cum se face acest lucru, mergeţi la următorul site Web Microsoft:
  2. Comparați adresa SMTP a utilizatorului cu relația organizației. Pentru aceasta, executaţi următoarea comandă:
    if ( (Get-OrganizationRelationship).DomainNames -contains (Get-Mailbox user).PrimarySmtpAddress.Domain) { write-host "The domain was found" -ForegroundColor Green } else { write-host (Get-Mailbox user).PrimarySmtpAddress.Domain "was not found" -ForegroundColor Yellow}
    Notă De asemenea, puteţi compara fiecare domeniu care este listat în domenii acceptate cu nume de sign-in de domeniu care se află în relație de organizație. Pentru aceasta, executaţi următoarea comandă:
    Get-AcceptedDomain | ForEach-Object { if ( (Get-OrganizationRelationship).DomainNames -contains $_.DomainName) { write-host $_.DomainName "was found" -ForegroundColor Green } else { write-host $_.DomainName "was not found" -ForegroundColor Yellow} }
MAI MULTE INFORMAȚII
Încă mai aveți nevoie de ajutor? du-te la Comunitatea Microsoft sau Forumuri TechNet Exchange.

Ghid pentru a depana această problemă.

Avertisment: acest articol a fost tradus automat

Proprietăți

ID articol: 2667844 - Ultima examinare: 11/11/2016 00:25:00 - Revizie: 18.0

Microsoft Exchange Online, Microsoft Exchange Server 2010 Standard, Microsoft Exchange Server 2010 Enterprise

  • o365 hybrid gwt guided walk through kbtshoot kbmt KB2667844 KbMtro
Feedback