Serbest/meşgul hatalarını çözme

Serbest/meşgul bilgileriyle ilgili bir hatayı gidermek için, bu makalenin üst kısmındaki içindekiler tablosundan (İçindekiler tablosu) ilgili hata iletisini seçin.

Sorun giderme adımları sorunu çözmenize yardımcı olmazsa Microsoft Desteği'ne başvurun.

İletinin güvenliği doğrulanırken bir hata oluştu

Sorun

Şirket içi kullanıcının serbest/meşgul bilgilerini görüntüleyemeyen bir bulut kullanıcınız var. Sorunu tanıladığınızda aşağıdaki hata iletisini bulursunuz:

Otomatik bulma, e-posta adresi <smtp adresi> için System.Web.Services.Protocols.SoapHeaderException hatasıyla başarısız oldu: System.Web'de iletinin güvenliği doğrulanırken bir hata oluştu. Services.Protocols. SoapHttpClientProtocol. System.Web.Services.Protocols.SoapHttpClientProtocol.EndInvoke(IAsyncResult asyncResult) konumunda ReadResponse(SoapClientMessage iletisi, WebResponse yanıtı, Stream responseStream, Boolean asyncCall)

WSSecurity kimlik doğrulaması etkinleştirilmediyse veya sıfırlanması gerekiyorsa ya da Exchange Server'da federasyon sertifikalarını yeniledikten sonra bu hata oluşabilir.

Sorun giderme adımları

Her adımı tamamladıktan sonra serbest/meşgul sorununun düzeltilip düzeltimediğini denetleyin.

1. Microsoft Federasyon Ağ Geçidi'ndeki meta verileri yenilemek için, şirket içi Exchange Yönetim Kabuğu'nda (EMS) iki kez aşağıdaki komutu çalıştırın:

   Get-FederationTrust | Set-FederationTrust -RefreshMetadata
   

   Daha fazla bilgi için bkz . Serbest/meşgul aramaları şirket içi ortamda veya Exchange Server karma dağıtımında çalışmayı durduruyor.

2. WSGüvenlik kimlik doğrulamasını değiştirmek için şu adımları izleyin:

   1. Şirket içi exchange sunucularındaki hem Otomatik Bulma hem de EWS sanal dizinlerinde WSGüvenlik kimlik doğrulamasını etkinleştirmek veya zaten etkinse sıfırlamak için federasyon kuruluşundaki kullanıcılar başka bir Exchange kuruluşunun serbest/meşgul bilgilerini göremez başlığı altında yer alan yordamı izleyin.

      Notlar

      • PowerShell cmdlet'lerinin Get-AutodiscoverVirtualDirectoryGet-WebServicesVirtualDirectory çıkışı WSSecurity kimlik doğrulamasının zaten etkin olduğunu belirtse bile bu adımı gerçekleştirin.

      • Yordam yalnızca şirket içi serbest/meşgul işlemlerini etkiler ve diğer istemci-sunucu bağlantılarını etkilemez.

   2. IIS'yi iisreset /noforce yeniden başlatmak için komutu her şirket içi Exchange sunucusunda bir PowerShell veya Komut İstemi penceresinde çalıştırın.

   3. Tüm şirket içi Exchange sunucularını yeniden başlatın.

3. Sistem olay günlüğündeki zaman dengesizliği uyarılarını veya hatalarını denetleyin ve çözün.

4. TargetSharingEpr Exchange Online PowerShell'de aşağıdaki cmdlet'i çalıştırarak kuruluş ilişkisindeki parametre değerini şirket içi dış Exchange Web Hizmetleri (EWS) URL'sine ayarlayın:

   Set-OrganizationRelationship "O365 to On-premises*" -TargetSharingEpr <on-premises EWS external URL>
   

   Parametre değerini ayarladıktan TargetSharingEpr sonra bulut posta kutusu Otomatik Bulma'yı atlar ve doğrudan şirket içi posta kutusunun EWS uç noktasına bağlanır.

   Not: Parametrenin TargetSharingEpr varsayılan değeri boş. Otomatik Bulma parametreleri TargetAutodiscoverEpr veya DiscoveryEndpoint genellikle şirket içi EWS dış URL'sini (Autodiscover uç noktası) içerir. ve DiscoveryEndpoint parametre değerlerini almak TargetAutodiscoverEpr için aşağıdaki PowerShell cmdlet'lerini çalıştırın:

   Get-OrganizationRelationship | FL TargetAutodiscoverEpr
   Get-IntraOrganizationConnector | FL DiscoveryEndpoint
   

5. Kuruluş ilişkisindeki parametre değerinin TargetApplicationUrifederasyon kuruluş tanımlayıcısında parametre değeriyle eşleştiğinden AccountNamespace emin olun. Parametre değerini bulmak TargetApplicationUri için Test-OrganizationRelationship PowerShell cmdlet'ini çalıştırın. Parametre değerini bulmak AccountNamespace için bkz. Karma serbest/meşgul ifadesini kaldırma.

Başa dön

Proxy web isteği başarısız oldu: Uzak sunucuya bağlanılamıyor

Sorun

Şirket içi kullanıcının serbest/meşgul bilgilerini görüntüleyemeyen veya tam tersi olan bulut kullanıcınız var. Sorunu tanıladığınızda aşağıdaki hata iletisini bulursunuz:

Proxy web isteği başarısız oldu. , iç özel durum: System.Net.WebException: Uzak sunucuya bağlanılamıyor ; System.Net.Sockets.SocketException: Bağlı taraf belirli bir süre sonra düzgün yanıt vermediğinden veya bağlı ana bilgisayar System.Net.Sockets.Socket.EndConnect(IAsyncResult asyncResult) konumunda CUSTOMER_IP:443 / MICROSOFT_IP:443 yanıt vermediğinden bağlantı kurulamadı.

Bu hata, ağ bağlantısı sorunları Exchange Online'daki IP adresleri ile Exchange Server'daki uç noktalar arasında gelen veya giden bağlantıları engelliyorsa oluşabilir.

Sorun giderme adımları

Her adımı tamamladıktan sonra serbest/meşgul sorununun düzeltilip düzeltimediğini denetleyin.

1. Her şirket içi Exchange sunucusundaki güvenlik duvarının Exchange Server uç noktaları ile Exchange Online IP adresleri arasında gelen veya giden bağlantılara izin verdiğinden emin olun. Güvenlik duvarı sorunlarını belirlemek için Exchange Online'dan serbest/meşgul isteğinde bulunup şirket içi güvenlik duvarını, ters ara sunucuyu ve ağ günlüklerini denetleyin. Güvenlik duvarı yapılandırma hakkında daha fazla bilgi için bkz. Federasyon temsilcisi ve Microsoft 365 URL'leri ve IP adresi aralıklarıiçin güvenlik duvarı konuları.

2. Exchange Online'dan gelen isteklerin şirket içi İstemci Erişimi sunucularına ulaştığını doğrulayın. Tüm şirket içi İstemci Erişimi sunucularında şu adımları izleyin:

   1. Exchange Online'dan serbest/meşgul isteğinde bulunabilirsiniz.

   2. Serbest/meşgul isteğinin günlüğe kaydedildiğini doğrulamak için varsayılan web sitesinin W3SVC1 klasöründeki IIS günlüklerini denetleyin. W3SVC1 klasör yolu şeklindedir%SystemDrive%\inetpub\logs\LogFiles\W3SVC1.

   3. Serbest/meşgul isteğinin günlüğe kaydedildiğini doğrulamak için aşağıdaki klasörlerdeki HTTP proxy günlüklerini denetleyin:

      • %ExchangeInstallPath%\Logging\HttpProxy\Autodiscover

      • %ExchangeInstallPath%\Logging\HttpProxy\Ews

3. Exchange Online PowerShell'de aşağıdaki cmdlet'i çalıştırarak Exchange Online'dan şirket içi Exchange Web Hizmetleri (EWS) uç noktasına bağlantıyı test edin:

   Test-MigrationServerAvailability -RemoteServer <on-premises mail server FQDN> -ExchangeRemoteMove -Credentials (Get-Credential)
   

   Notlar

   • Bu test, İnternet'ten gelen bağlantıları yalnızca Exchange Online IP adreslerinin şirket içi EWS uç noktanıza bağlanmasına izin verecek şekilde kısıtlarsanız yararlıdır.

   • Bu sorundan yalnızca birkaç bulut kullanıcısı etkileniyorsa ve posta kutuları Exchange Online'da aynı posta sunucusunda barındırılıyorsa, posta sunucusunun şirket içi uç noktalara bağlanıp bağlanamadığını denetleyin. Şirket içi uç noktanın, o posta sunucusunun giden dış IP adresinden gelen bağlantıları engellemesi mümkündür.

   • Kimlik bilgileri istendiğinde, etki alanı yöneticisi kimlik bilgilerinizi "etki alanı\yönetici" biçiminde girin.

Başa dön

E-posta adresi için otomatik bulma başarısız oldu: HTTP durumu 404

Sorun

Şirket içi kullanıcının serbest/meşgul bilgilerini görüntüleyemeyen bir bulut kullanıcınız var. Sorunu tanıladığınızda aşağıdaki hata iletisini bulursunuz:

Otomatik bulma, e-posta adresi <kullanıcısı SMTP adresi> için System.Net.WebException: İstek HTTP durum koduyla 404 Not Foundbaşarısız oldu hatasıyla başarısız oldu.

Otomatik Bulma uç noktaları işlev dışı veya yanlış yapılandırılmışsa bu hata oluşabilir.

Sorun giderme adımları

Her adımı tamamladıktan sonra serbest/meşgul sorununun düzeltilip düzeltimediğini denetleyin.

1. Otomatik Bulma uç noktasının geçerli olup olmadığını denetleyin:

   1. veya TargetAutodiscoverEpr parametresinden Otomatik Bulma uç noktası URL'sini DiscoveryEndpoint almak için aşağıdaki komutları çalıştırın:

      Get-IntraOrganizationConnector | FL DiscoveryEndpoint
      Get-OrganizationRelationship | FL TargetAutodiscoverEpr
      

   2. Web tarayıcısında Otomatik Bulma uç noktası URL'sine gidin. Geçerli bir Otomatik Bulma uç noktası HTTP durum kodunu 404 Not Founddöndürmez.

2. Şirket içi kullanıcının etki alanının bulut kullanıcısının kuruluş ayarlarında (kuruluş içi bağlayıcı veya kuruluş ilişkisi) belirtildiğinden emin olun:

   1. Exchange Online PowerShell'de aşağıdaki PowerShell cmdlet'lerini çalıştırın:

      Get-IntraOrganizationConnector | FL TargetAddressDomains
      Get-OrganizationRelationship -Identity <cloud to on-premises ID> | FL DomainNames
      

      Şirket içi kullanıcının etki alanının her iki komutun çıktısında listelendiğini doğrulayın. Örneğin, bulut kullanıcısı şirket içi kullanıcı user1@contoso.comuser2@contoso.roiçin serbest/meşgul ifadesini ararsa, şirket içi etki alanının contoso.ro listelendiğini doğrulayın.

   2. Şirket içi kullanıcının etki alanı bulut kullanıcısının kuruluş ayarlarında yoksa, aşağıdaki PowerShell cmdlet'ini çalıştırarak etki alanını ekleyin:

      Set-IntraOrganizationConnector -Identity <connector ID> -TargetAddressDomains @{add="<on-premises domain>"}
      

3. SVC işleyici eşlemesinin HEM Otomatik Bulma hem de EWS sanal dizinlerinde IIS Yöneticisi'ndeki Varsayılan Web Sitesi altında bulunduğundan emin olun. Daha fazla bilgi için bkz. FederationInformation alınamadı ve Hedef tarafından Özel Durum oluşturuldu.

   Not: Eşleme AutodiscoverDiscoveryHander (*.svc), federasyon serbest/meşgul araması için kullanılmaz.

Başa dön

Özel durum proxy web isteği başarısız oldu

KAPAK: 43532

Sorun

Şirket içi kullanıcının serbest/meşgul bilgilerini görüntüleyemeyen bir bulut kullanıcınız var. Sorunu tanıladığınızda aşağıdaki hata iletisini bulursunuz:

Özel durum Proxy web isteği başarısız oldu. , iç özel durum: İstek HTTP durumu 401: Yetkisiz tanılama: 2000005; reason= "Belirteçte kullanıcı bağlamı tarafından belirtilen kullanıcı belirsiz." ; error_category="invalid_user"

Şirket içi kullanıcının UPN, SMTP adresi veya SIP adresi başka bir şirket içi posta kutusu tarafından kullanılıyorsa bu hata oluşabilir.

Çözüm

Bu sorunu çözmek için şu adımları izleyin:

1. Özel LDAP sorguları kullanarak yinelenen BIR UPN, SMTP adresi veya SIP adresine sahip şirket içi kullanıcı nesnelerini arayın. LDP.exe veya Active Directory Kullanıcıları ve Bilgisayarları MMC ek bileşenini kullanarak LDAP sorguları çalıştırabilirsiniz.

   Örneğin, UPNuser@contoso.com, SMTP adresi veya user@contoso.com SIP adresi olarak sahip user@corp.contoso.com olan tüm kullanıcıları göstermek için aşağıdaki LDAP sorgusunu kullanın:

   (|(userPrincipalName=user@corp.contoso.com)(proxyAddresses=SMTP:user@contoso.com)(proxyAddresses=sip:user@contoso.com))
   

   Active Directory nesnelerini bulmak için LDP.exe veya Active Directory Kullanıcıları ve Bilgisayarları'nı kullanma hakkında daha fazla bilgi için bkz. LDP örnekleri.

2. Yinelenen adresi değiştirin veya yinelenen kullanıcı nesnesini silin.

Başa dön

Var olan bir bağlantı, uzak ana bilgisayar tarafından zorla kapatıldı

Sorun

Şirket içi kullanıcının serbest/meşgul bilgilerini görüntüleyemeyen bir bulut kullanıcınız var. Sorunu tanıladığınızda aşağıdaki hata iletisini bulursunuz:

Proxy web isteği başarısız oldu. , iç özel durum: System.Net.WebException: Temel alınan bağlantı kapatıldı: Alma sırasında beklenmeyen bir hata oluştu. System.IO.IOException: Aktarım bağlantısından veri okunamıyor: Var olan bir bağlantı uzak konak tarafından zorla kapatıldı. System.Net.Sockets.SocketException: Var olan bir bağlantı uzak konak tarafından zorla kapatıldı.

Bu hata, şirket içi güvenlik duvarı Exchange Online'da bir dış giden IP adresinden gelen bağlantıyı engellerse oluşabilir.

Sorun giderme adımları

Her adımı tamamladıktan sonra serbest/meşgul sorununun düzeltilip düzeltimediğini denetleyin.

1. Exchange Online'dan gelen serbest/meşgul isteklerinin Exchange sunucusunda IIS'ye ulaşıp ulaşmadığını denetleyin. Exchange Online'dan serbest/meşgul isteği oluşturun ve serbest/meşgul isteği sırasında yapılan aşağıdaki IIS günlük girdilerini arayın:

   • %ExchangeInstallPath%\Logging\HttpProxy\Autodiscover klasöründeki "ASAutoDiscover/CrossForest/EmailDomain" öğesini içeren bir Otomatik Bulma girdisi.

     Not: Kuruluş ilişkisindeki parametreyi TargetSharingEpr şirket içi dış Exchange Web Hizmetleri (EWS) URL'sine el ile ayarlarsanız, Otomatik Bulma atlanır ve bu girdi mevcut olmaz.

   • %ExchangeInstallPath%\Logging\HttpProxy\Ews klasöründe "ASProxy/CrossForest/EmailDomain" içeren bir EWS girdisi.

   Not: IIS günlüklerindeki zaman damgaları UTC saatini kullanır.

2. Her şirket içi Exchange sunucusundaki güvenlik duvarının Exchange Server uç noktaları ile Exchange Online IP adresleri arasında gelen veya giden bağlantılara izin verdiğinden emin olun. Güvenlik duvarı sorunlarını belirlemek için Exchange Online'dan serbest/meşgul istekleri yapın ve ardından şirket içi güvenlik duvarını, ters ara sunucuyu ve ağ günlüklerini denetleyin. Güvenlik duvarı yapılandırma hakkında daha fazla bilgi için bkz. Federasyon temsilcisi ve Microsoft 365 URL'leri ve IP adresi aralıklarıiçin güvenlik duvarı konuları.

3. Kuruluşunuz serbest/meşgul uygulamak için kuruluş ilişkilerini kullanıyorsa, her Exchange sunucusuna bir federasyon sertifikasının yüklendiğinden emin olun. Exchange Yönetim Kabuğu'nda (EMS) aşağıdaki komutları çalıştırın:

   Test-FederationTrustCertificate
   Get-FederatedOrganizationIdentifier -IncludeExtendedDomainInfo | FL
   

   Federasyon sertifikası yüklüyse, komut çıktısı herhangi bir hata veya uyarı içermemelidir.

4. WSGüvenlik kimlik doğrulamasını değiştirmek için şu adımları izleyin:

   1. Şirket içi exchange sunucularındaki hem Otomatik Bulma hem de EWS sanal dizinlerinde WSGüvenlik kimlik doğrulamasını etkinleştirmek veya zaten etkinse sıfırlamak için federasyon kuruluşundaki kullanıcılar başka bir Exchange kuruluşunun serbest/meşgul bilgilerini göremez başlığı altında yer alan yordamı izleyin. WSSecurity kimlik doğrulaması zaten etkin olsa bile bu adımı gerçekleştirin.

   2. IIS Yöneticisi'nde Otomatik Bulma ve EWS uygulama havuzlarını geri dönüştürebilirsiniz.

   3. IIS'yi iisreset /noforce yeniden başlatmak için komutu her şirket içi Exchange sunucusunda bir PowerShell veya Komut İstemi penceresinde çalıştırın.

5. Bu sorundan yalnızca birkaç bulut kullanıcısı etkileniyorsa ve posta kutuları Exchange Online'da aynı posta sunucusunda barındırılıyorsa, posta sunucusunun şirket içi uç noktalara bağlanıp bağlanamadığını denetleyin. Şirket içi uç noktanın, o posta sunucusunun giden IP adresinden gelen bağlantıları engellemesi mümkündür.

Başa dön

Active Directory'de orman/etki alanı yapılandırma bilgileri bulunamadı

KAPAK: 47932

Sorun

Şirket içi bir kullanıcının serbest/meşgul bilgilerini görüntüleyemeyen veya tam tersi olan bir bulut kullanıcınız var. Sorunu tanıladığınızda aşağıdaki hata iletisini bulursunuz:

Orman/etki alanı etki alanı <> yapılandırma bilgileri Active Directory'de bulunamadı.

Kuruluş ayarları yanlış yapılandırılmışsa bu hata oluşabilir.

Sorun giderme adımları

Her adımı tamamladıktan sonra serbest/meşgul sorununun düzeltilip düzeltimediğini denetleyin.

1. Serbest/meşgul bilgileri istenen bir kullanıcının etki alanının, serbest/meşgul bilgilerini görüntülemeye çalışan kullanıcının kuruluş ayarlarında mevcut olduğunu doğrulayın. Serbest/meşgul yönüne bağlı olarak aşağıdaki yordamlardan birini seçin.

   • Buluttan şirket içine

     Şirket içi bir kullanıcının serbest/meşgul bilgilerini görüntülemeye çalışan bir bulut kullanıcısı için şu adımları izleyin:

     1. Exchange Online PowerShell'e bağlanın ve federasyon etki alanlarını almak için aşağıdaki PowerShell cmdlet'lerini çalıştırın:

        Get-IntraOrganizationConnector | FL TargetAddressDomains
        Get-OrganizationRelationship -Identity <cloud to on-premises ID> | FL DomainNames
        

        Şirket içi kullanıcının etki alanının her iki komutun çıktısında listelendiğini doğrulayın. Örneğin, bulut kullanıcısı şirket içi kullanıcı user1@contoso.comuser2@contoso.roiçin serbest/meşgul ifadesini ararsa, şirket içi etki alanının contoso.ro listelendiğini doğrulayın.

        Not

        Etki alanı adlarını Exchange Online PowerShell'de çalıştırarak (Get-IntraOrganizationConfiguration).OnPremiseTargetAddresses veya şirket içi Exchange Yönetim Kabuğu'nda (EMS) çalıştırarak (Get-FederatedOrganizationIdentifier).Domains da bulabilirsiniz.

     2. Şirket içi kullanıcının etki alanı bulut kullanıcısının kuruluş ayarlarında yoksa, aşağıdaki PowerShell cmdlet'ini çalıştırarak etki alanını ekleyin:

        Set-IntraOrganizationConnector -Identity <connector ID> -TargetAddressDomains @{add="<on-premises domain>"}​
        

   • Şirket içi ortamdan buluta

     Bulut kullanıcısının serbest/meşgul bilgilerini görüntülemeye çalışan şirket içi bir kullanıcı için şu adımları izleyin:

     1. EMS'de aşağıdaki PowerShell cmdlet'lerini çalıştırın:

        Get-IntraOrganizationConnector | FL TargetAddressDomains
        Get-OrganizationRelationship -Identity <on-premises to cloud ID> | FL DomainNames
        

        Bulut kullanıcısının etki alanının komut çıkışında listelenen etki alanlarından biriyle eşleşip eşleşmediğini denetleyin. Örneğin, şirket içi kullanıcı bulut kullanıcısı user1@contoso.rouser2@contoso.comiçin serbest/meşgul bilgilerini ararsa, her iki komutun çıktısında bulut etki alanının contoso.com mevcut olduğunu doğrulayın.

     2. Bulut kullanıcısının etki alanı şirket içi kullanıcının kuruluş ayarlarında yoksa, etki alanını ekleyin. Aşağıdaki komutu çalıştırın:

        Set-IntraOrganizationConnector -Identity <connector ID> -TargetAddressDomains @{add="<cloud domain>"}​
        

2. Karma Exchange dağıtımınızın tam karma bir yapılandırmaya sahip olduğundan emin olun. Gerekirse Karma Yapılandırma Sihirbazı'nı (HCW) yeniden çalıştırın ve En Düşük Karma Yapılandırma yerine Tam Karma Yapılandırma'yı seçin. En düşük karma yapılandırma, kuruluş ilişkisi (federasyon güveni) veya kuruluş içi bağlayıcılar oluşturmaz.

Başa dön

Proxy web isteği başarısız oldu: HTTP durumu 401

Sorun

Şirket içi kullanıcının serbest/meşgul bilgilerini görüntüleyemeyen bir bulut kullanıcınız var. Sorunu tanıladığınızda aşağıdaki hata iletilerinden birini bulursunuz.

Hata iletisi 1

Proxy web isteği başarısız oldu. ,iç özel durum: İstek HTTP durumu 401: Yetkisiz ile başarısız oldu.

Hata iletisi 2

E-posta adresi için otomatik bulma başarısız oldu. ,iç özel durum: İstek HTTP durumu 401: Yetkisiz ile başarısız oldu.

Exchange Online'dan doğrudan Exchange Server'a istekleri geçirmek yerine Exchange Server'ın önündeki bir çevre cihazı önceden kimlik doğrulaması (kullanıcı adı ve parola gerektirme) için yapılandırılmışsa bu hata oluşabilir. Karma Exchange dağıtımlarındaki Otomatik Bulma ve EWS sanal dizinleri ön kimlik doğrulamayı desteklemez.

Çevre cihazlarına örnek olarak ters proxy'ler, güvenlik duvarları ve Microsoft Threat Management Gateway (TMG) verilebilir.

Hata iletisi 1, bir EWS isteğinin başarısız olduğunu gösterir.

Hata iletisi 2, otomatik bulma isteğinin başarısız olduğunu gösterir.

Sorun giderme adımları

Aldığınız hata iletisinden bağımsız olarak serbest/meşgul sorununu gidermek için aşağıdaki adımları kullanın. Her adımı tamamladıktan sonra serbest/meşgul sorununun düzeltilip düzeltimediğini denetleyin.

1. Ön kimlik doğrulamasının etkinleştirilip etkinleştirilmediğini denetleyin. Şu adımları izleyin:

   1. Ön kimlik doğrulamasının etkinleştirilip etkinleştirilmediğini denetlemek için Uzak Bağlantı Çözümleyicisi'nde Serbest/Meşgul testini çalıştırın. Bulut posta kutusu Kaynak Posta Kutusu, şirket içi posta kutusu ise Hedef Posta Kutusu'dur. Test tamamlandıktan sonra uç noktada geçiş kimlik doğrulaması durumunu denetleyin. Kırmızı bir onay işareti görürseniz, ön kimlik doğrulamayı devre dışı bırakın ve yeniden test edin. Yeşil bir onay işareti görürseniz, hatalı pozitif olabileceğinden sonraki adıma geçin.

   2. Exchange Online'dan gelen serbest/meşgul isteğinin IIS'ye ulaşıp ulaşmadığını denetleyin. Serbest/meşgul sorgusu gerçekleştirin ve sorgu sırasında aşağıdaki girdilerden herhangi birini Exchange Server'daki IIS günlüklerinde arayın:

      • %ExchangeInstallPath%\Logging\HttpProxy\Autodiscover klasöründe, HTTP durum kodunu 401 Unauthorized içeren ve "ASAutoDiscover/CrossForest/EmailDomain" metnini içeren bir Otomatik Bulma girdisi arayın.

        Not: Kuruluş ilişkisindeki parametre şirket içi EWS dış URL'sini belirtiyorsa TargetSharingEpr , Otomatik Bulma atlanır ve bu giriş görünmez.

      • %ExchangeInstallPath%\Logging\HttpProxy\Ews klasöründe, HTTP durum kodunu 401 Unauthorized içeren ve "ASProxy/CrossForest/EmailDomain" metnini içeren bir EWS girdisi arayın.

      Not: IIS günlüklerindeki zaman damgaları UTC saatini kullanır. HTTP durum koduna 401 Unauthorized sahip bazı girişler normaldir.

      Belirtilen girdiler, serbest/meşgul isteğinin IIS'ye ulaştığını ve genellikle ön kimlik doğrulama sorunlarının kurallarını belirlediğini gösterir. Belirtilen girişleri bulamazsanız, serbest/meşgul isteğinin nerede takıldığını anlamak için ters ara sunucu ve güvenlik duvarı günlüklerinizi denetleyin.

2. EWS ve Otomatik Bulma sanal dizinlerinde WSSecurity (Exchange Server 2010) veya OAuth kimlik doğrulamasını (Exchange Server 2013 ve sonraki sürümler) etkinleştirdiğinizden emin olun. Ayrıca, Otomatik Bulma ve EWS sanal dizinleri için IIS'de varsayılan kimlik doğrulama ayarlarını etkinleştirdiğinizden emin olun. Daha fazla bilgi için bkz. Exchange sanal dizinleri için varsayılan kimlik doğrulama ayarları ve Exchange sanal dizinleri için varsayılan ayarlar.

3. İletinin güvenliği doğrulanırken bir hata oluştu bölümünde yer alan çözüm adımlarını izleyin. WSSecurity yapılandırıldıysa, WSSecurity'yi geçiş yapan adımı gerçekleştirdiğinizden emin olun. WSSecurity yerine OAuth kimlik doğrulaması yapılandırıldıysa, aşağıdaki komutları çalıştırarak Otomatik Bulma ve EWS sanal dizinlerinde OAuth kimlik doğrulamasını değiştirin:

   Set-WebServicesVirtualDirectory "<ServerName>\ews (Exchange Back End)" -OAuthAuthentication:$False
   Set-WebServicesVirtualDirectory "<ServerName>\ews (Exchange Back End)" -OAuthAuthentication:$True 
   Set-AutodiscoverVirtualDirectory "<ServerName>\Autodiscover (Exchange Back End)" -OAuthAuthentication:$False 
   Set-AutodiscoverVirtualDirectory "<ServerName>\Autodiscover (Exchange Back End)" -OAuthAuthentication:$True 
   

4. Güncel bir federasyon güvenine sahip olduğunuzu doğrulayın. Exchange kuruluşunuzun federasyon güven bilgilerini almak için Exchange Online PowerShell'de aşağıdaki komutu çalıştırın:

   Get-FederationTrust
   

   Komut çıktısı aşağıdaki bilgileri içermelidir:

   Name	ApplicationIdentifier	ApplicationUri
   WindowsLiveId	260563	outlook.com
   MicrosoftOnline	260563	outlook.com

   Not: Güven WindowsLiveId , Microsoft Federasyon Ağ Geçidi'nin bir tüketici örneğidir. Güven MicrosoftOnline , Microsoft Federasyon Ağ Geçidi'nin bir iş örneğidir.

   Güncel bir federasyon güveni için, öğesinin ApplicationIdentifier olduğundan 260563 ve olmadığından 292841ve ApplicationUrioutlook.comoutlook.live.comdeğil olduğundan emin olun. Eski bir federasyon güveni varsa Microsoft Desteği'ne başvurun.

Başa dön

E-posta adresi için otomatik bulma başarısız oldu: InvalidUser

KAPAK: 33676

Sorun

Şirket içi kullanıcının serbest/meşgul bilgilerini görüntüleyemeyen bir bulut kullanıcınız var. Sorunu tanıladığınızda aşağıdaki hata iletisini bulursunuz:

'' konumundaki Otomatik Bulma hizmetinden gelen yanıt, 'https://Autodiscover/Autodiscover.svc/WSSecurityExternalEwsUrl' kullanıcı ayarındaki bir hata nedeniyle başarısız oldu. Hata iletisi: InvalidUser.

Uzak Bağlantı Çözümleyicisi'nde Serbest/Meşgul testini çalıştırdığınızda hata iletisi görünebilir.

Bulut posta kutusu veya Otomatik Bulma uç noktası yanlış yapılandırılmışsa bu hata oluşabilir.

Sorun giderme adımları

1. Aşağıdaki komutu çalıştırarak bulut kullanıcısının etki alanını içeren onmicrosoft.com ikincil bir SMTP adresine sahip olduğunu doğrulayın:

   Get-Mailbox -Identity <mailbox ID> | FL EmailAddresses
   

   Örneğin, birincil SMTP adresine user1@contoso.com sahip bir kullanıcının benzer user1@contoso.mail.onmicrosoft.comikincil bir SMTP adresi olmalıdır.

   Bulut kullanıcısı Exchange Server'dan yönetiliyorsa, ikincil SMTP adresini Exchange Server'a ekleyin ve ardından şirket içi ortamınızla Microsoft Entra Id arasında kimlik verilerini eşitleyin.

2. Kuruluş ilişkisindeki parametre değerini şirket içi dış Exchange Web Hizmetleri (EWS) URL'sine ayarlamak TargetSharingEpr için aşağıdaki komutları çalıştırın:

   Connect-ExchangeOnline
   Set-OrganizationRelationship "O365 to On-premises*" -TargetSharingEpr <on-premises EWS external URL>
   

   Parametre değerini ayarladıktan TargetSharingEpr sonra bulut posta kutusu Otomatik Bulma'yı atlar ve doğrudan şirket içi posta kutusunun EWS uç noktasına bağlanır.

Başa dön

Çağıranın serbest/meşgul verilerine erişimi yok

KAPAK: 47652, 44348, 40764

Sorun

Şirket içi bir kullanıcının serbest/meşgul bilgilerini görüntüleyemeyen veya tam tersi olan bir bulut kullanıcınız var. Sorunu tanıladığınızda aşağıdaki hata iletisini bulursunuz:

Microsoft.Exchange.InfoWorker.Common.Availability.NoFreeBusyAccessException: Çağıranın serbest/meşgul verilerine erişimi yok.

Serbest/meşgul bilgileri istenen kullanıcının posta kutusu yanlış yapılandırılmışsa bu hata oluşabilir.

Sorun giderme adımları

Her adımı tamamladıktan sonra serbest/meşgul sorununun düzeltilip düzeltimediğini denetleyin.

1. Aşağıdaki komutu çalıştırarak serbest/meşgul bilgileri istenen kullanıcının takvim izinlerini denetleyin:

   Get-MailboxFolderPermission -Identity <mailbox ID>:\Calendar
   

   AccessRights Komut çıktısındaki Default kullanıcının değeri veya LimitedDetailsolmalıdırAvailabilityOnly. AccessRights değer iseNone, bu değeri veya LimitedDetailsolarak ayarlamak için aşağıdaki PowerShell cmdlet'ini AvailabilityOnly çalıştırın:

   Set-MailboxFolderPermission -Identity <mailbox ID>:\Calendar -AccessRights <access rights value>
   

2. Kuruluş ilişkisini denetlemek için geçerli yöntemi kullanın:

   • Bulut kullanıcısı şirket içi kullanıcının serbest/meşgul bilgilerini görüntüleyemiyorsa:

     Şirket içi kuruluş ilişkisinin, şirket içi serbest/meşgul bilgilerine erişebilen bulut etki alanını belirttiğini doğrulayın. Örnek bir bulut etki alanıdır contoso.mail.onmicrosoft.com. Exchange Server'da kuruluş ilişkisini değiştirme hakkında bilgi için bkz. Kuruluş ilişkisini değiştirmek için PowerShell kullanma. Ayrıca bulut kullanıcısının Kimden e-posta adresinin, örneğin lucine.homsi@contoso.mail.onmicrosoft.comaynı bulut etki alanına sahip olduğunu doğrulayın.

   • Şirket içi kullanıcı bir bulut kullanıcısının serbest/meşgul bilgilerini görüntüleyemiyorsa:

     Bulut kuruluş ilişkisinin bulut serbest/meşgul bilgilerine erişebilecek şirket içi etki alanını belirttiğini doğrulayın. Örnek şirket içi etki alanıdır contoso.com. Exchange Online'da kuruluş ilişkisini değiştirme hakkında bilgi için bkz. Kuruluş ilişkisini değiştirmek için Exchange Online PowerShell kullanma. Ayrıca, şirket içi kullanıcının Kimden e-posta adresinin, örneğin lucine.homsi@contoso.comaynı şirket içi etki alanına sahip olduğunu doğrulayın.

Başa dön

İletideki güvenlik belirteçleri işlenirken bir hata oluştu

KAPAK: 59916

Sorun

Şirket içi kullanıcının serbest/meşgul bilgilerini görüntüleyemeyen bir bulut kullanıcınız var. Sorunu tanıladığınızda aşağıdaki hata iletisini bulursunuz:

ProxyWebRequestProcessingException ErrorProxyRequestProcessingFailed
Proxy web isteği başarısız oldu. , iç özel durum: İletideki güvenlik belirteçleri işlenirken bir hata oluştu.

Microsoft Federasyon Ağ Geçidi'ndeki sertifikalar veya meta veriler geçersizse bu hata oluşabilir.

Sorun giderme adımları

1. Aşağıdaki PowerShell cmdlet'lerini çalıştırarak şirket içi federasyon güven sertifikalarının sona erme tarihini ve parmak izlerini denetleyin:

   Get-FederationTrust | FL
   Test-FederationTrust
   Test-FederationTrustCertificate
   

2. Microsoft Federasyon Ağ Geçidi'ndeki meta verileri yenilemek için, şirket içi Exchange Yönetim Kabuğu'nda (EMS) iki kez aşağıdaki komutu çalıştırın:

   Get-FederationTrust | Set-FederationTrust -RefreshMetadata
   

   Daha fazla bilgi için bkz . Serbest/meşgul aramaları çalışmayı durduruyor.

Başa dön

İstekte bulunan farklı bir kuruluştan olduğundan, kuruluşlar arası isteğe izin verilmiyor

KAPAK: 39660

Sorun

Karma olmayan bir Exchange Online kiracısında bulunan bir bulut kullanıcısının, karma olan başka bir Exchange Online kiracısında bulunan bulut kullanıcısının serbest/meşgul bilgilerini görüntüleyebildiği karma ağ senaryonuz var. Sorunu tanıladığınızda aşağıdaki hata iletisini bulursunuz:

İstekte bulunan farklı bir kuruluştan olduğundan posta kutusu <SMTP adresi> için kuruluşlar arası isteğe izin verilmiyor
Alıcı: <SMTP adresi>
Özel Durum Türü: CrossOrganizationProxyNotAllowedForExternalOrganization
Özel Durum İletisi: İstekte bulunan farklı bir kuruluştan olduğundan SMTP adresi> için <kuruluşlar arası isteğe izin verilmiyor.

Örneğin, karma olmayan bir Exchange Online kiracısında bulunan bir kullanıcı lucine@adatum.com , karma kiracıdaki bir bulut kullanıcısının chanok@contoso.com serbest/meşgul durumunu görüntüleyemez. Bulut kullanıcısının chanok@contoso.com bir proxy e-posta adresi chanok@contoso.mail.onmicrosoft.comvardır. Bağımsız kiracının iki kuruluş ilişkisi vardır: contoso.com (şirket içi) ve contoso.mail.onmicrosoft.com (bulut). Exchange Server'a yönelik noktalar için contoso.com otomatik bulma ve Exchange Online'a yönelik noktalar için contoso.mail.onmicrosoft.com Otomatik Bulma. Puanlar için contoso.com Otomatik Bulma, Exchange Online'a işaret etmediğinden, kiracıdaki kullanıcı için chanok@contoso.comserbest/meşgul bilgilerini sorgularken hata iletisini alır.

Not

Eşdeğer şirket içi karma ağ senaryosu için bkz. Karma ağ.

Geçici Çözüm

Bu sorunu geçici olarak çözmek için kuruluşunuz aşağıdaki yöntemlerden birini kullanabilir:

• Otomatik Bulma'nın Exchange Online'a işaret ettiği e-posta adresini kullanarak, karma kiracıdaki bir bulut kullanıcısının serbest/meşgul durumunu sorgulaması gerekir. Örneğin, lucine@adatum.com için chanok@contoso.mail.onmicrosoft.comserbest/meşgul bilgilerini sorgular. Serbest/meşgul bilgilerini başarıyla sorgulamak için, karma kiracıdaki hangi kullanıcıların bulutta barındırıldığını ve bu kullanıcıların her biri için Otomatik Bulma'nın Exchange Online'ı işaret ettiği e-posta adresini öğrenmesi gerekir.

• Bağımsız Exchange Online kiracısının yöneticisi, karma kiracıdaki her bulut kullanıcısının dış e-posta adresini, Otomatik Bulma'nın Exchange Online'ı işaret ettiği e-posta adresine ayarlamalıdır. Örneğin, bağımsız olmayan Exchange Online kiracısında bir yönetici, karma kiracıdaki hedef e-posta adresini chanok@contoso.com olarak chanok@contoso.mail.onmicrosoft.comayarlar. Bu değişikliği yapmak için yöneticinin karma kiracıdaki hangi kullanıcıların bulutta barındırıldığı ve bu kullanıcıların her biri için Otomatik Bulma'nın Exchange Online'a işaret ettiği e-posta adresini bilmesi gerekir. Kullanıcı e-posta adreslerinin kiracılar arası eşitlemesi hakkında daha fazla bilgi için bkz. Kiracılar arası eşitleme nedir?

Daha fazla bilgi

Bir kullanıcı aşağıdaki senaryoda benzer bir sorunla karşılaşabilir:

• Kullanıcı, bağımsız bir Exchange Server kiracısındadır.
• Kullanıcı, karma kiracıdaki şirket içi bir kullanıcının serbest/meşgul durumunu görüntülemeye çalışır.
• Karma kiracı için otomatik bulma, Exchange Online'a işaret etti.

Örneğin, exchange server kiracısında yer alan bir kullanıcı karma kiracıdaki şirket içi kullanıcının chanok@contoso.com serbest/meşgul bilgilerini görüntüleyemiyor çünkü Exchange Online (autodiscover-s.outlook.com) noktaları için contoso.com Otomatik Bulma.

Başa dön

İstek HTTP durumu 401: Yetkisiz (imzalama sertifikası eksik) ile başarısız oldu

Sorun

Şirket içi kullanıcının serbest/meşgul bilgilerini görüntüleyemeyen bir bulut kullanıcınız var. Sorunu tanıladığınızda aşağıdaki hata iletisini bulursunuz:

System.Net.WebException: İstek HTTP durumu 401: Yetkisiz ile başarısız oldu.

Test-OAuthConnectivity cmdlet'ini çalıştırırsanız, komut çıkışında aşağıdaki hata iletisini görürsünüz:

Microsoft.Exchange.Security.OAuth.OAuthTokenRequestFailedException: İmzalama sertifikası eksik.

Örneğin, aşağıdaki komutu çalıştırırsınız:

Test-OAuthConnectivity -Service AutoD -TargetUri <on-premises Autodiscover URL> -Mailbox <mailbox ID> -Verbose | FL

TargetUri Parametre değeri, şirket içi Otomatik Bulma hizmeti URL'sidir. Bu URL'ye örnek olarak .https://mail.contoso.com/Autodiscover/Autodiscover.svc

Kimlik doğrulama yapılandırması geçersiz bir OAuth sertifikasına sahipse bu hata oluşabilir.

Çözüm

Bu sorunu çözmek için şu adımları izleyin:

1. Kimlik doğrulama yapılandırması tarafından kullanılan OAuth sertifikasının parmak izini almak için Exchange Yönetim Kabuğu'nda (EMS) aşağıdaki PowerShell cmdlet'ini çalıştırın:

   Get-AuthConfig | FL CurrentCertificateThumbprint
   

   Komut çıkışı bir sertifika parmak izi döndürmezse 3. adıma gidin. Aksi takdirde, sonraki adıma geçin.

2. 1. adımda tanımlanan sertifikanın Exchange Server'da var olup olmadığını denetlemek için aşağıdaki PowerShell cmdlet'ini çalıştırın:

   Get-ExchangeCertificate -Thumbprint (Get-AuthConfig).CurrentCertificateThumbprint | FL
   

   Exchange Server herhangi bir sertifika döndürmezse, yeni sertifika oluşturmak için 3. adıma gidin.

   Exchange Server bir sertifika döndürürse ancak parmak izi 1. adımda aldığınız parmak izinden farklıysa, 4. adıma gidin. 4. adımda, Exchange Server'ın döndürdüğünü sertifikanın parmak izini belirtin.

3. Yeni bir OAuth sertifikası oluşturmak için aşağıdaki PowerShell cmdlet'ini çalıştırın:

   New-ExchangeCertificate -KeySize 2048 -PrivateKeyExportable $true -SubjectName "CN=Microsoft Exchange Server Auth Certificate" -FriendlyName "Microsoft Exchange Server Auth Certificate" -DomainName <Domain> -Services SMTP
   

   Not

   SMTP sertifikasını değiştirmeniz istenirse, istemi kabul etmeyin.

   4. adımda, bu adımda oluşturduğunuz yeni sertifikanın parmak izini belirtin.

4. Kimlik doğrulama yapılandırmasını belirtilen sertifikayı kullanacak şekilde güncelleştirmek için aşağıdaki PowerShell cmdlet'lerini çalıştırın:

   $date=Get-Date 
   Set-AuthConfig -NewCertificateThumbprint <certificate thumbprint> -NewCertificateEffectiveDate $date
   Set-AuthConfig -PublishCertificate
   

   Not

   Geçerlilik tarihinin şu andan itibaren 48 saatten az olduğu konusunda uyarılırsanız devam etmeyi seçin.

5. Önceki sertifikaya yapılan başvuruları kaldırmak için aşağıdaki PowerShell cmdlet'ini çalıştırın:

   Set-AuthConfig -ClearPreviousCertificate
   

Başa dön

Uygulamada RBAC rolleri için bağlı bir hesap eksik veya bağlı hesapta RBAC rol ataması yok veya arayan kullanıcı hesabı oturum açma devre dışı

Sorun

Şirket içi kullanıcının serbest/meşgul bilgilerini görüntüleyemeyen bir bulut kullanıcınız var. Sorunu tanıladığınızda aşağıdaki hata iletisini bulursunuz:

System.Web.Services.Protocols.SoapException: Uygulamada RBAC rolleri için bağlı bir hesap eksik veya bağlı hesapta RBAC rol ataması yok veya arayan kullanıcı hesabı oturum açma devre dışı bırakıldı.

Sorun giderme adımları

Hata iletisinde belirtilen sorunları gidermek için aşağıdaki adımları kullanın. 1. ve 2. adımları tamamladıktan sonra serbest/meşgul sorununun düzeltilip düzeltimediğini denetleyin.

1. Exchange Server iş ortağı uygulamaları listesinde "Exchange Online-ApplicationAccount" girişinin bulunduğundan emin olun. Denetlemek için Exchange Yönetim Konsolu'nda (EMS) aşağıdaki PowerShell cmdlet'ini çalıştırın:

   Get-PartnerApplication | FL LinkedAccount
   

   Hesap girişi olarak <root domain FQDN>/Users/Exchange Online-ApplicationAccountgörünmelidir. Girdi listeleniyorsa 2. adıma gidin.

   Hesap girişi listelenmiyorsa, şu adımları izleyerek hesabı ekleyin:

   1. Hesabı şirket içi Active Directory'de bulmak için aşağıdaki PowerShell cmdlet'lerini çalıştırın:

      Set-ADServerSettings -ViewEntireForest $true 
      Get-User "Exchange Online-ApplicationAccount" 
      

      Hesap Active Directory'de listeleniyorsa 1b. adıma gidin.

      Hesap Active Directory'de listelenmiyorsa silinmiş olabilir. Hesap durumunu denetlemek ve silinmişse geri yüklemek için ADRestore kullanın. Hesabı ADRestore kullanarak geri yüklediyseniz 1b. adıma gidin.

      ADRestore kullanarak hesabı geri yükleyemiyorsanız, Active Directory'de ve Exchange Server etki alanlarında açıklanan yordamı izleyin. Bu yordam hesabı geri yüklemezse, hesabı Active Directory'de el ile oluşturun ve 1b. adıma geçin.

   2. Active Directory hesabını Exchange Server iş ortağı uygulamaları listesine eklemek için aşağıdaki PowerShell cmdlet'ini çalıştırın:

      Set-PartnerApplication "Exchange Online" -LinkedAccount "<root domain FQDN>/Users/Exchange Online-ApplicationAccount"
      

   3. Tüm şirket içi Exchange sunucularını yeniden başlatın veya komutu her sunucudaki bir PowerShell veya Komut İstemi penceresinde çalıştırarak iisreset /noforce IIS'yi yeniden başlatın.

2. Rol tabanlı erişim denetimi (RBAC) atamalarını denetlemek için EMS'de aşağıdaki PowerShell cmdlet'ini çalıştırın:

   Get-ManagementRoleAssignment -RoleAssignee "Exchange Online-ApplicationAccount" | FL Name,Role
   

   Örneğin, komut çıktısı aşağıdaki rol atamalarını listeleyebilir:

   

3. Hata iletisinde belirtilen sorunlar için aşağıdaki günlüklerde arama yapın:

   • %ExchangeInstallPath%\Logging\Ews klasöründe bulunan Exchange Web Services (EWS) günlükleri
   • Uygulama olay günlükleri
   • Sistem olay günlükleri

4. 3. adımda listelenen günlüklerde AuthzInitializeContextFromSid'e başvuran bir hata iletisi arayın. Bu hata iletisini bulursanız aşağıdaki kaynaklara bakın:

   • Bazı uygulamalar ve API'ler, hesap nesnelerindeki yetkilendirme bilgilerine erişim gerektirir

   • Erişim denetimleri AuthZ nedeniyle başarısız oldu

Başa dön

Girilen ve depolanan parolalar eşleşmiyor

Sorun

Şirket içi kullanıcının serbest/meşgul bilgilerini görüntüleyemeyen bir bulut kullanıcınız var. Sorunu tanıladığınızda aşağıdaki hata iletisini bulursunuz:

Soap hatası özel durumu alındı. Girilen ve depolanan parolalar eşleşmiyor.

Bulut kullanıcısının şirket içi kullanıcı posta kutusu için temsilci belirteci alıp alamayacağını denetlemek için aşağıdaki cmdlet'i çalıştırdığınızda aynı hata iletisini görürsünüz:

Test-OrganizationRelationship -Identity "O365 to On-premises*" -UserIdentity <cloud mailbox ID> -Verbose

Neden

Belirli bulut kullanıcıları için Azure kimlik bilgileri içinde bir tutarsızlık vardır.

Çözüm

Bu sorunu çözmek için şu adımları izleyin:

1. Bulut kullanıcısının parolasını sıfırlayın. Aynı parolayı veya farklı bir parolayı seçin.

2. Etki alanını kullanmak için bulut kullanıcısının kullanıcı asıl adını (UPN) güncelleştirin onmicrosoft.com ve ardından UPN'yi eski değerine geri döndürin. Örneğin, bulut kullanıcısının UPN'i ise user@contoso.com, bunu geçici UPN olarak user@contoso.mail.onmicrosoft.comdeğiştirin ve UPN'yi olarak user@contoso.comgeri alın. Bunu yapmak için Azure AD PowerShell veya MSOL hizmetini kullanın.

   • Azure AD PowerShell kullanma

     Aşağıdaki PowerShell cmdlet'lerini çalıştırın:

     Connect-AzureAD
     Set-AzureADUser -ObjectID <original UPN> -UserPrincipalName <temporary UPN>
     Set-AzureADUser -ObjectID <temporary UPN> -UserPrincipalName <original UPN>
     

   • MSOL hizmetini kullanma

     Aşağıdaki PowerShell cmdlet'lerini çalıştırın:

     Connect-MsolService
     Set-MsolUserPrincipalName -UserPrincipalName <original UPN> -NewUserPrincipalName <temporary UPN>
     Set-MsolUserPrincipalName -UserPrincipalName <temporary UPN> -NewUserPrincipalName <original UPN>
     

3. Şirket içi kullanıcı nesnesinin değerinin null olduğundan emin ImmutableId olun. ImmutableId Exchange Yönetim Kabuğu'nda (EMS) aşağıdaki komutu çalıştırarak şirket içi kullanıcı nesnesinin değerini denetleyin:

   Get-RemoteMailbox -Identity <cloud mailbox> | FL UserPrincipalName,ImmutableId
   

   Değere bağlı olarak ImmutableId aşağıdaki yöntemlerden birini kullanın.

   • ImmutableId değeri null

     ImmutableId Değer null ise değerini değiştirin:

     1. EMS'de ImmutableId aşağıdaki PowerShell cmdlet'ini çalıştırarak uzak posta kutusu nesnesini bulut kullanıcısının UPN'sine ayarlayın:

        Set-RemoteMailbox -Identity <cloud mailbox> -ImmutableId <UPN>
        

        Örneğin: Set-RemoteMailbox user@contoso.com -ImmutableId user@contoso.onmicrosoft.com.

     2. EMS'de aşağıdaki PowerShell cmdlet'lerini çalıştırarak değişikliği buluta eşitleyin:

        Import-Module ADSync
        Start-ADSyncSyncCycle -PolicyType Delta
        

        Değerin ImmutableId güncelleştirildiğini doğrulamak için Exchange Online PowerShell'de aşağıdaki PowerShell cmdlet'ini çalıştırın:

        Get-Mailbox -Identity <cloud mailbox> | FL UserPrincipalName,ImmutableId
        

     3. EMS'de ImmutableId aşağıdaki PowerShell cmdlet'ini çalıştırarak uzak posta kutusu nesnesini null olarak geri döndürün:

        Set-RemoteMailbox -Identity <cloud mailbox> -ImmutableId $null
        

     4. EMS'de aşağıdaki PowerShell cmdlet'ini çalıştırarak değişikliği buluta eşitleyin:

        Start-ADSyncSyncCycle -PolicyType Delta
        

        Değerin ImmutableId güncelleştirildiğini doğrulamak için Exchange Online PowerShell'de aşağıdaki PowerShell cmdlet'ini çalıştırın:

        Get-Mailbox -Identity <cloud mailbox> | FL UserPrincipalName,ImmutableId
        

   • ImmutableId değeri null değil

     ImmutableId Değer null değilse EMS'de aşağıdaki komutu çalıştırarak ImmutableId değeri null olarak ayarlayın:

     Set-RemoteMailbox -Identity <user> -ImmutableId $null
     

     Exchange Online PowerShell'de aşağıdaki PowerShell cmdlet'ini çalıştırarak değerin güncelleştirildiğini doğrulayabilirsinizImmutableId:

     Get-Mailbox -Identity <cloud mailbox> | FL UserPrincipalName,ImmutableId
     

Başa dön

Parolanın değiştirilmesi gerekiyor veya hesabın parolasının süresi doldu

Sorun

Şirket içi kullanıcının serbest/meşgul bilgilerini görüntüleyemeyen bir bulut kullanıcınız var. Sorunu tanıladığınızda aşağıdaki hata iletilerinden birini bulursunuz.

Hata iletisi 1

Hesabın parolasının süresi doldu

Hata iletisi 2

Parolanın değiştirilmesi gerekiyor

Bulut kullanıcısının şirket içi kullanıcı posta kutusu için temsilci belirteci alıp alamayacağını denetlemek için aşağıdaki cmdlet'i çalıştırdığınızda aynı hata iletisini görürsünüz:

Test-OrganizationRelationship -Identity "O365 to On-premises*" -UserIdentity <cloud mailbox ID> -Verbose

Belirli bulut kullanıcıları için Azure kimlik bilgileri içinde bir tutarsızlık varsa bu hata oluşabilir.

Çözüm

Hata iletisiyle eşleşen çözümü seçin.

Hata iletisi 1 için çözüm

Sorunu çözmek için Azure AD PowerShell veya MSOL hizmetini kullanın.

• Azure AD PowerShell kullanma

  Aşağıdaki PowerShell cmdlet'lerini çalıştırın:

  Connect-AzureAD
  Set-AzureADUser -ObjectId <account UPN> -PasswordPolicies DisablePasswordExpiration
  

• MSOL hizmetini kullanma

  Aşağıdaki PowerShell cmdlet'lerini çalıştırın:

  Connect-MsolService
  Set-MsolUser -UserPrincipalName <account UPN> -PasswordNeverExpires $true
  

Hata iletisi 2 için çözüm

Sorunu düzeltmek için aşağıdaki PowerShell cmdlet'lerini çalıştırın:

Connect-MsolService
Set-MsolUserPassword -UserPrincipalName <UPN> -ForceChangePassword $false

Daha fazla bilgi için bkz. Şirket içi Exchange'den geçirildikten sonra serbest/meşgul bilgilerini göremiyorum.

Başa dön

Federasyon hesabının oturum açılabilmesi için sağlama gereklidir

Sorun

Şirket içi kullanıcının serbest/meşgul bilgilerini görüntüleyemeyen bir bulut kullanıcınız var. Sorunu tanıladığınızda aşağıdaki hata iletisini bulursunuz:

Federasyon hesabının oturum açılabilmesi için sağlama gereklidir. ErrorWin32InteropError

Bulut kullanıcısının şirket içi kullanıcı posta kutusu için temsilci belirteci alıp alamayacağını denetlemek için aşağıdaki cmdlet'i çalıştırdığınızda da aynı hata iletisini alırsınız:

Test-OrganizationRelationship -Identity "O365 to On-premises*" -UserIdentity <cloud mailbox ID> -Verbose

Microsoft Entra Id'de federasyon kullanıcılarının yapılandırmasında tutarsızlık varsa bu hata oluşabilir.

Çözüm

Not

Sorun kuruluşunuzdaki bulut kullanıcılarının çoğunu veya tümünü etkiliyorsa Microsoft Desteği'ne başvurun.

Sorunu çözmek için, bulut kullanıcısının kullanıcı asıl adını (UPN) etki alanını kullanacak şekilde güncelleştirin onmicrosoft.com ve ardından eski değerine (federasyon etki alanı) geri dönün. Örneğin, bulut kullanıcısının UPN'i ise user@contoso.comgeçici UPN'ye user@contoso.mail.onmicrosoft.com geçin ve sonra öğesine geri dönün user@contoso.com. Bunu yapmak için aşağıdaki yaklaşımlardan birini kullanın (Azure AD PowerShell veya MSOL hizmeti):

• Azure AD PowerShell kullanma

  Aşağıdaki PowerShell cmdlet'lerini çalıştırın:

  Connect-AzureAD
  Set-AzureADUser -ObjectID <original UPN> -UserPrincipalName <temporary UPN>
  Set-AzureADUser -ObjectID <temporary UPN> -UserPrincipalName <original UPN>
  

• MSOL hizmetini kullanma

  Aşağıdaki PowerShell cmdlet'lerini çalıştırın:

  Connect-MsolService
  Set-MsolUserPrincipalName -UserPrincipalName <original UPN> -NewUserPrincipalName <temporary UPN>
  Set-MsolUserPrincipalName -UserPrincipalName <temporary UPN> -NewUserPrincipalName <original UPN>
  

Başa dön

İstek zaman aşımına uğradı

KAPAK: 43404

Sorun

Şirket içi kullanıcının serbest/meşgul bilgilerini görüntüleyemeyen bir bulut kullanıcınız var. Sorunu tanıladığınızda aşağıdaki hata iletisini bulursunuz:

İstek zaman aşımına uğradı
İstek zamanında işlenemedi. Zaman aşımı 'İstek-Tamamlanma Bekleniyor' sırasında oluştu.
Microsoft.Exchange.InfoWorker.Common.Availability.TimeoutExpiredException: İstek zamanında işlenemedi. Zaman aşımı 'İstek-Tamamlanma Bekleniyor' sırasında oluştu.
Özel durumun kaynaklandığı sunucunun adı: <sunucu adı>.

Bulut kullanıcısının şirket içi kullanıcı posta kutusu için temsilci belirteci alıp alamayacağını denetlemek için aşağıdaki cmdlet'i çalıştırırsanız da aynı hata iletisini alırsınız:

Test-OrganizationRelationship -Identity "O365 to On-premises*" -UserIdentity <cloud mailbox ID> -Verbose

Ağ veya geçici sorunlar varsa bu hata oluşabilir. Hata iletisi geneldir.

Sorun giderme adımları

Her adımı tamamladıktan sonra serbest/meşgul sorununun düzeltilip düzeltimediğini denetleyin.

1. Geçici sorunları ekarte etmek için, şirket içi kullanıcının serbest/meşgul bilgilerini alma girişimleri sırasında bulut kullanıcısının sürekli olarak aynı hata iletisini aldığını doğrulayın.

2. Aşağıdaki cmdlet'lerin her birini çalıştırdığınızda temsilci belirtecini alıp alamayacağınızı denetleyin:

   Test-OrganizationRelationship -Identity "O365 to On-premises*" -UserIdentity <cloud mailbox ID> -Verbose
   Test-FederationTrust -UserIdentity <on-premises mailbox ID> -Verbose
   Test-FederationTrustCertificate
   

   Not: Test-FederationTrust cmdlet'ini tüm şirket içi Exchange sunucularında çalıştırın.

3. Exchange Server'ın aşağıdaki kaynakların her ikisine de giden İnternet erişimi olduğunu doğrulayın:

   • Microsoft Federasyon Ağ Geçidi (veya OAuth kullanıyorsanız bir yetkilendirme sunucusu)

   • Microsoft 365 için kullanılabilirlik URL'si: https://outlook.office365.com/ews/exchange.asmx

   Daha fazla bilgi için bkz. Microsoft 365 URL'leri ve IP adresi aralıkları ve Federasyon Temsilcisi için Güvenlik Duvarı Konuları.

4. Exchange Server'daki sistem hesabının aşağıdaki URL'lere İnternet erişimi olduğundan emin olun. Her Exchange sunucusunda şu adımları izleyin:

   1. Sistem hesabından bir web tarayıcısı başlatan bir PowerShell oturumu başlatmak için aşağıdaki PsExec komutunu çalıştırın:

      PsExec.exe -i -s "C:\Program Files\Internet Explorer\iexplore.exe"
      

   2. Sistem hesabından aşağıdaki Microsoft Federasyon Ağ Geçidi URL'lerine tarayıcı erişimini (OAuth olmadan) test edin:

      • https://nexus.microsoftonline-p.com/federationmetadata/2006-12/federationmetadata.xml

        Tarayıcı bir xml sayfası görüntülemelidir.

      • https://login.microsoftonline.com/extSTS.srf

        Tarayıcı sizden dosyayı indirmenizi istemelidir.

      • https://domains.live.com/service/managedelegation2.asmx

        Tarayıcı ManageDelegation2 tarafından desteklenen işlemlerin listesini görüntülemelidir.

   3. Sistem hesabından aşağıdaki Microsoft yetkilendirme sunucusu URL'lerine tarayıcı erişimini (OAuth) test edin:

      • https://outlook.office365.com/ews/exchange.asmx

        Tarayıcı bir oturum açma istemi göstermelidir.

      • https://login.windows.net/common/oauth2/authorize

        Tarayıcı, "Üzgünüz, ancak oturum açmada sorun yaşıyoruz" oturum açma hatasını görüntülemelidir.

      • https://accounts.accesscontrol.windows.net/<tenant guid>/tokens/OAuth/2

        Tarayıcı HTTP durum kodunu 400 Bad Requestveya "Üzgünüz, ancak oturum açarken sorun yaşıyoruz" oturum açma hata iletisini görüntülemelidir.

5. Exchange Web Services (EWS) günlüklerini denetleyerek serbest/meşgul isteğinin ayrıntılarını alın:

   1. Exchange Online'dan serbest/meşgul isteğinde bulunabilirsiniz.

   2. EWS günlüklerinde girdiyi bulun ve sütundaki time-taken değeri denetleyin. EWS günlükleri %ExchangeInstallPath%\Logging\Ews klasöründe bulunur.

   3. Serbest/meşgul isteğinin günlüğe kaydedildiğini doğrulamak için varsayılan web sitesinin W3SVC1 klasöründeki IIS günlüklerini denetleyin. W3SVC1 klasör yolu şeklindedir%SystemDrive%\inetpub\logs\LogFiles\W3SVC1.

Başa dön

Belirtilen üye adı geçersiz veya boş

Sorun

Şirket içi kullanıcının serbest/meşgul bilgilerini görüntüleyemeyen bir bulut kullanıcınız var. Sorunu tanıladığınızda aşağıdaki hata iletisini bulursunuz:

S:Fault xmlns:S="http://www.w3.org/2003/05/soap-envelope"><S:Code><S:Value>S:Sender</S:Value><S:Subcode><S:Value>wst:FailedAuthentication</S:Value></S:Subcode></S:Code><S:Reason><S:Text xml:lang="en-US">Authentication Failure</S:Text></S:Reason><S:Detail><psf:error xmlns:psf="http://schemas.microsoft.com/Passport/SoapServices/SOAPFault"><psf:value>0x80048821</psf:value><psf:internalerror><psf:code>0x80041034</psf:code><psf:text>Belirtilen üye adı geçersiz veya boş. </psf:text></psf:internalerror></psf:error></S:Detail></S:Fault> Microsoft.Exchange.Net.WSTrust.SoapFaultException: Soap hatası özel durumu alındı. Microsoft.Exchange.InfoWorker.Common.Availability.ExternalAuthenticationRequest.Complete(IAsyncResult asyncResult) konumundaki Microsoft.Exchange.Net.WSTrust.SecurityTokenService.EndIssueToken(IAsyncResult asyncResult) adresinde

Hata aşağıdaki nedenlerden biri nedeniyle oluşabilir:

• Temsilci belirteci isteyen kullanıcılar için Microsoft Entra Kimliği'nde tutarsızlık
• Active Directory Federasyon Hizmetleri'nde (AD FS) federasyon kullanıcılarının yapılandırmasında tutarsızlık

Sorun giderme adımları

Her adımı tamamladıktan sonra serbest/meşgul sorununun düzeltilip düzeltimediğini denetleyin.

1. Etki alanını kullanmak için bulut kullanıcısının kullanıcı asıl adını (UPN) güncelleştirin onmicrosoft.com ve ardından UPN'yi eski değerine geri döndürin. Örneğin, bulut kullanıcısının UPN'i ise user@contoso.com, bunu geçici UPN user@contoso.mail.onmicrosoft.comolarak değiştirin ve UPN'yi olarak user@contoso.comgeri alın. Bunu yapmak için aşağıdaki yöntemlerden birini kullanın (Azure AD PowerShell veya MSOL hizmeti):

   • Azure AD PowerShell kullanma

     Aşağıdaki PowerShell cmdlet'lerini çalıştırın:

     Connect-AzureAD
     Set-AzureADUser -ObjectID <original UPN> -UserPrincipalName <temporary UPN>
     Set-AzureADUser -ObjectID <temporary UPN> -UserPrincipalName <original UPN>
     

   • MSOL hizmetini kullanma

     Aşağıdaki PowerShell cmdlet'lerini çalıştırın:

     Connect-MsolService
     Set-MsolUserPrincipalName -UserPrincipalName <original UPN> -NewUserPrincipalName <temporary UPN>
     Set-MsolUserPrincipalName -UserPrincipalName <temporary UPN> -NewUserPrincipalName <original UPN>
     

2. AD FS kurallarını, uç noktalarını ve günlüklerini denetleyin.

3. Aşağıdaki PowerShell cmdlet'inin komut çıkışında bulut kullanıcısının hatasıyla ilgili ImmutableID bir hata arayın:

   Test-OrganizationRelationship -Identity "O365 to On-premises*" -UserIdentity <cloud user ID> -Verbose
   

   Örneğin, komut çıktısı aşağıdaki hata iletisini içerebilir:

   ""XGuNpVunD0afQeVNfyoUIQ==" e-posta adresi doğru değil. Lütfen şu biçimi kullanın: kullanıcı adı, @ işareti ve ardından etki alanı adı. Örneğin, tonysmith@contoso.com veya tony.smith@contoso.com.
   + CategoryInfo : NotSpecified: (:) [Test-OrganizationRelationship], FormatException"

   Benzer bir hata iletisi alırsanız, değerin null (boş değer) olduğundan emin olmak ImmutableId için aşağıdaki yöntemlerden birini kullanın:

   • Bulut kullanıcısı şirket içinden eşitlenmemişse, Exchange Online PowerShell'de aşağıdaki PowerShell cmdlet'ini çalıştırarak değeri denetleyinImmutableId:

     Get-Mailbox -Identity <cloud mailbox> | FL ImmutableId
     

     ImmutableId Değer null değilse, Exchange Online PowerShell'de aşağıdaki PowerShell cmdlet'ini çalıştırın:

     Set-Mailbox -Identity <cloud mailbox> -ImmutableId $null
     

   • Bulut kullanıcısı şirket içinden eşitlenmişse, Exchange Yönetim Kabuğu'nda (EMS) aşağıdaki komutu çalıştırarak şirket içi kullanıcı nesnesinin değerini denetleyin ImmutableId :

     Get-RemoteMailbox -Identity <cloud mailbox> | FL UserPrincipalName,ImmutableId
     

     Değere bağlı olarak ImmutableId aşağıdaki yöntemlerden birini kullanın:

     • ImmutableId değeri null

       ImmutableId Değer null ise değerini değiştirin:

       1. EMS'de ImmutableId aşağıdaki PowerShell cmdlet'ini çalıştırarak uzak posta kutusu nesnesini bulut kullanıcısının UPN'sine ayarlayın:

          Set-RemoteMailbox -Identity <cloud mailbox> -ImmutableId <UPN>
          

          Örneğin: Set-RemoteMailbox user@contoso.com -ImmutableId user@contoso.onmicrosoft.com.

       2. EMS'de aşağıdaki PowerShell cmdlet'lerini çalıştırarak değişikliği buluta eşitleyin:

          Import-Module ADSync
          Start-ADSyncSyncCycle -PolicyType Delta
          

          Değerin ImmutableId güncelleştirildiğini doğrulamak için Exchange Online PowerShell'de aşağıdaki PowerShell cmdlet'ini çalıştırın:

          Get-Mailbox -Identity <cloud mailbox> | FL UserPrincipalName,ImmutableId
          

       3. EMS'de ImmutableId aşağıdaki PowerShell cmdlet'ini çalıştırarak uzak posta kutusu nesnesini null olarak geri döndürün:

          Set-RemoteMailbox -Identity <cloud mailbox> -ImmutableId $null
          

       4. EMS'de aşağıdaki PowerShell cmdlet'ini çalıştırarak değişikliği buluta eşitleyin:

          Start-ADSyncSyncCycle -PolicyType Delta
          

          Değerin ImmutableId güncelleştirildiğini doğrulayın. Bunu yapmak için Exchange Online PowerShell'de aşağıdaki PowerShell cmdlet'ini çalıştırın:

          Get-Mailbox -Identity <cloud mailbox> | FL UserPrincipalName,ImmutableId
          

     • ImmutableId değeri null değil

       ImmutableId Değer null değilse EMS'de aşağıdaki komutu çalıştırarak ImmutableId değeri null olarak ayarlayın:

       Set-RemoteMailbox -Identity <user> -ImmutableId $null
       

       Değerin ImmutableId güncelleştirildiğini doğrulamak için Exchange Online PowerShell'de aşağıdaki PowerShell cmdlet'ini çalıştırın:

       Get-Mailbox -Identity <cloud mailbox> | FL UserPrincipalName,ImmutableId
       

4. Kuruluş ilişkisi ayarlarını denetleyin. Daha fazla bilgi için bkz. Karma Serbest/Meşgul'ün yetkisini kaldırma.

5. Hata iletisi, şirket içi bir kullanıcının serbest/meşgul bilgilerini görüntüleyemeyen bir bulut kullanıcısı için oluşturulduysa şu adımları izleyin:

   1. Aşağıdaki PowerShell cmdlet'ini çalıştırın:

      Test-FederationTrust -UserIdentity <on-premises user> -Verbose -Debug
      

   2. Federasyon güvenini yeniden oluşturun. Daha fazla bilgi için bkz. Federasyon güvenini kaldırma ve Federasyon güveni yapılandırma.

Başa dön

Sonuç kümesi çok fazla takvim girdisi içeriyor

KAPAK: 54796

Sorun

Başka bir bulut kullanıcısının serbest/meşgul bilgilerini görüntüleyemeyen bir bulut kullanıcınız var. Sorunu tanıladığınızda aşağıdaki hata iletisini bulursunuz:

Özel durum: Sonuç kümesi çok fazla takvim girdisi içeriyor. İzin verilen boyut = 1000; gerçek boyut = 5009.

Tek bir zaman grafiğindeki takvim girdilerinin sayısı 1.000 öğeyi aşarsa bu hata oluşur. Tek bir serbest/meşgul isteği 1.000'den fazla öğe alamaz.

Çözüm

Tek bir serbest/meşgul isteğinde alınabilecek 1.000 öğe sınırını aşmamak için takvim öğelerinin bazılarını zaman grafiğinden kaldırın.

Daha fazla bilgi için bkz. Exchange Online'da başka bir kullanıcının Takviminde serbest/meşgul bilgilerini görüntüleyemezsiniz.

Başa dön

Çalışma saatleri başlangıç saati bitiş saatinden küçük veya buna eşit olmalıdır

Sorun

Oda listesi için serbest/meşgul bilgilerini görüntüleyemeyen bir bulut kullanıcınız var. Sorunu tanıladığınızda aşağıdaki hata iletisini bulursunuz:

Özel durum: Microsoft.Exchange.InfoWorker.Common.InvalidParameterException: Çalışma saatleri başlangıç saati bitiş saatinden küçük veya buna eşit olmalıdır.
Microsoft.Exchange.InfoWorker.Common.MeetingSuggestions.AttendeeWorkHours.Validate(TimeSpan startTime, TimeSpan endTime).

Bir oda listesindeki bir oda posta kutusu için aşağıdaki takvim ayarlarından biri veya daha fazlası geçersizse bu hata oluşabilir:

• WorkingHoursStartTime
• WorkingHoursEndTime
• WorkingHoursTimeZone

Çalışma saatlerinin başlangıç saati, çalışma saatleri bitiş saatinden küçük veya buna eşit olmalı ve çalışma saatlerinin saat dilimi ayarlanmalıdır.

Çözüm

Bu sorunu çözmek için şu adımları izleyin:

1. Aşağıdaki PowerShell cmdlet'ini çalıştırarak oda listesindeki her posta kutusunun takvim ayarlarını denetleerek geçersiz ayarları olan oda posta kutusunu belirleyin:

   Get-DistributionGroupMember -Identity <room list name> | Get-MailboxCalendarConfiguration | FL Identity,WorkingHours* 
   

2. Oda posta kutusu için gerekli parametre değerlerini ayarlamak için aşağıdaki PowerShell cmdlet'ini çalıştırın:

   Set-MailboxCalendarConfiguration -Identity <room ID> -WorkingHoursStartTime <start time> -WorkingHoursEndTime <end time> -WorkingHoursTimeZone <time zone>
   

   Daha fazla bilgi için bkz. Set-MailboxCalendarConfiguration.

Başa dön

İstek HTTP durumu 401: Yetkisiz (belirtecin imzası geçersiz) ile başarısız oldu

Sorun

Şirket içi kullanıcının serbest/meşgul bilgilerini görüntüleyemeyen bir bulut kullanıcınız var. Sorunu tanıladığınızda aşağıdaki hata iletisini bulursunuz:

System.Net.WebException: İstek HTTP durumu 401: Yetkisiz ile başarısız oldu.

OAuth kimlik doğrulamasını test etmek için aşağıdaki PowerShell cmdlet'ini çalıştırdığınızda:

Test-OAuthConnectivity -Service EWS -TargetUri <external EWS URL> -Mailbox <cloud mailbox ID> -Verbose | FL

Aşağıdaki komut çıkışını alırsınız:

System.Net.WebException: The remote server returned an error: (401) Unauthorized. Boolean reloadConfig, diagnostics: 2000000; reason="The token has an invalid signature.";error_category="invalid_signature".

Not: TargetUri Test-OAuthConnectivity komutundaki parametre değeri, gibi https://mail.contoso.com/ews/exchange.asmxbir dış Exchange Web Hizmetleri (EWS) URL'dir.

Microsoft yetkilendirme sunucusu ayarları geçersizse bu hata oluşabilir.

Sorun giderme adımları

Her adımı tamamladıktan sonra serbest/meşgul sorununun düzeltilip düzeltimediğini denetleyin.

1. Exchange tarafından güvenilen belirtilen Microsoft yetkilendirme sunucusundaki yetkilendirme meta verilerini yenileyin. EMS'de (şirket içinde) aşağıdaki PowerShell cmdlet'ini çalıştırın:

   Set-AuthServer <name of the authorization server> -RefreshAuthMetadata 
   

   Komutun tam olarak etkili olması için yaklaşık 15 dakika bekleyin veya komutu her Exchange Server'daki bir PowerShell veya Komut İstemi penceresinde çalıştırarak iisreset /noforce IIS'yi yeniden başlatın.

2. EMS'de aşağıdaki PowerShell cmdlet'ini çalıştırarak Exchange kuruluşunuzdaki Microsoft yetkilendirme sunucusu ayarlarını denetleyin:

   Get-AuthServer | FL Name, IssuerIdentifier, TokenIssuingEndpoint, AuthMetadataUrl, Enabled
   

   Aşağıdaki komut çıktısı geçerli ayarların bir örneğidir:

   Name : WindowsAzureACS
   IssuerIdentifier : 00000001-0000-0000-c000-000000000000
   TokenIssuingEndpoint : https://accounts.accesscontrol.windows.net/XXXXXXXX-5045-4d00-a59a-c7896ef052a1/tokens/OAuth/2
   AuthMetadataUrl : https://accounts.accesscontrol.windows.net/contoso.com/metadata/json/1
   Enabled : True
   

   Microsoft yetkilendirme sunucusu ayarları geçerli değilse, Microsoft yetkilendirme sunucusu ayarlarını geçerli değerlere sıfırlamak için Karma Yapılandırma Sihirbazı'nı yeniden çalıştırmayı deneyin.

Başa dön

İstek HTTP durumu 401: Yetkisiz (anahtar bulunamadı) ile başarısız oldu

Sorun

Bulut kullanıcısının serbest/meşgul bilgilerini görüntüleyemeyen bir şirket içi kullanıcınız var. Sorunu tanıladığınızda aşağıdaki hata iletisini bulursunuz:

System.Net.WebException: İstek HTTP durumu 401: Yetkisiz ile başarısız oldu.

OAuth kimlik doğrulamasını test etmek için EMS'de aşağıdaki PowerShell cmdlet'ini çalıştırdığınızda:

Test-OAuthConnectivity -Service EWS -TargetUri https://outlook.office365.com/ews/exchange.asmx -Mailbox <on-premises mailbox ID> -Verbose | FL

Aşağıdaki komut çıkışını alırsınız:

System.Net.WebException: Uzak sunucu bir hata döndürdü: (401) Yetkisiz.
Hata: Kimlik Doğrulama Sunucusundan belirteç alınamıyor. Hata kodu: 'invalid_client'. Açıklama: 'AADSTS70002:
Kimlik bilgileri doğrulanırken hata oluştu. AADSTS50012: İstemci onaylama işlemi geçersiz bir imza içeriyor. [Neden - Anahtar bulunamadı., İstemci tarafından kullanılan anahtarın parmak izi: '<parmak izi>'.

Exchange Server'daki OAuth sertifikası Exchange Online'da yoksa bu hata oluşabilir.

Çözüm

Sorunu çözmek için aşağıdaki adımları kullanın:

1. Şirket içi Exchange Server OAuth sertifikanızın Exchange Online kuruluşunuzda mevcut olup olmadığını belirleyin:

   1. Exchange Server'da OAuth sertifikasını almak için Exchange Yönetim Kabuğu'nda (EMS) aşağıdaki PowerShell cmdlet'ini çalıştırın:

      Get-ExchangeCertificate -Thumbprint (Get-AuthConfig).CurrentCertificateThumbprint | FL
      

      Komut çıktısı Thumbprint değerini içerir.

   2. MSOL hizmetini kullanarak Exchange Online OAuth sertifikasını almak için aşağıdaki PowerShell cmdlet'lerini çalıştırın:

      Connect-MsolService
      Get-MsolServicePrincipalCredential -ServicePrincipalName "00000002-0000-0ff1-ce00-000000000000" -ReturnKeyValues $true
      

      Komut çıktısındaki Value parametre değeri boşsa, Exchange Online'da bir OAuth sertifikası yoktur. Bu durumda, şirket içi sertifikayı Exchange Online'a yüklemek için 3. adıma gidin.

      Value Parametre değeri boş değilse, değeri ".cer" uzantısına sahip bir dosyaya kaydedin. Exchange Online OAuth sertifikasını görüntülemek için dosyayı Microsoft Sertifika Yöneticisi aracında açın. Thumbprint Exchange Online sertifikasındaki değeri, 1a adımında aldığınız şirket içi sertifikanın parmak iziyle karşılaştırın. Parmak izi değerleri eşleşiyorsa 4. adıma gidin. Parmak izi değerleri eşleşmiyorsa aşağıdaki seçeneklerden birini belirleyin:

      • Var olan şirket içi sertifikayı Exchange Online sertifikasıyla değiştirmek için 2. adıma gidin.

      • Var olan Exchange Online sertifikasını şirket içi sertifikayla değiştirmek için 3. adıma gidin.

2. Var olan şirket içi sertifikayı Exchange Online sertifikasıyla değiştirin:

   1. Şirket içi sertifika parmak izini güncelleştirmek için aşağıdaki PowerShell cmdlet'ini çalıştırın:

      Set-AuthConfig -NewCertificateThumbprint <thumbprint of Exchange Online certificate> -NewCertificateEffectiveDate (Get-Date) 
      

      Sertifika geçerlilik tarihinin şu andan itibaren 48 saatten kısa olduğu bildirilirse devam etmek için istemi kabul edin.

   2. Şirket içi sertifikayı yayımlamak için aşağıdaki PowerShell cmdlet'ini çalıştırın:

      Set-AuthConfig -PublishCertificate  
      

   3. Önceki sertifikaya yapılan başvuruları kaldırmak için aşağıdaki PowerShell cmdlet'ini çalıştırın:

      Set-AuthConfig -ClearPreviousCertificate 
      

   4. 4. adıma gidin.

3. Şirket içi yetkilendirme sertifikasını dışarı aktarın ve ardından sertifikayı Exchange Online kuruluşunuza yükleyin.

4. Şirket içi kimlik doğrulama yapılandırmasındaki 00000002-0000-0ff1-ce00-000000000000SPN'nin olup olmadığını denetlemek için aşağıdaki PowerShell cmdlet'ini çalıştırın:

   Get-AuthConfig | FL ServiceName
   

   SPN değeri farklıysa, aşağıdaki PowerShell cmdlet'ini çalıştırarak SPN'yi güncelleştirin:

   Set-AuthConfig -ServiceName "00000002-0000-0ff1-ce00-000000000000"
   

Başa dön

Proxy web isteği başarısız oldu: Yanıt iyi biçimlendirilmiş XML değil

Sorun

Şirket içi kullanıcının serbest/meşgul bilgilerini görüntüleyemeyen bir bulut kullanıcınız var. Sorunu tanıladığınızda aşağıdaki hata iletisini bulursunuz:

Ara sunucu web isteği başarısız oldu., iç özel durum: Yanıt iyi biçimlendirilmiş XML değil

Şirket içi kullanıcı için Eşitleme, Bildirim, Kullanılabilirlik ve Otomatik Yanıtlar testini çalıştırırsanız aşağıdaki hata iletisini alırsınız:

Hizmetten alınan yanıt geçerli XML içermiyordu

Bu hatalar aşağıdaki nedenlerden herhangi biri nedeniyle oluşabilir:

• Dış Exchange Web Hizmetleri (EWS) sorunu
• Ters ara sunucu veya güvenlik duvarı gibi ağ cihazlarının yanlış yapılandırılması

Sorun giderme adımları

Her adımı tamamladıktan sonra serbest/meşgul sorununun düzeltilip düzeltimediğini denetleyin.

1. Exchange Online'dan gelen serbest/meşgul isteklerinin Exchange sunucusunda IIS'ye ulaşıp ulaşamadığını denetleyin. Serbest/meşgul sorgusu gerçekleştirin ve ardından IIS günlüklerinde HTTP durum kodu 200 OK olan veya 401 Unauthorized sorgu sırasındaki girdileri arayın. Bu girdiler, serbest/meşgul isteğinin IIS'ye ulaştığını gösterir. Not: IIS günlüklerindeki zaman damgaları UTC saatini kullanır.

   Bu girdileri bulamazsanız, serbest/meşgul isteğinin nerede takıldığını belirlemek için ters ara sunucuyu ve güvenlik duvarı günlüklerini denetleyin.

2. Serbest/meşgul sorgusu gerçekleştirin ve sorunun nedenini daraltmaya yardımcı olmak için Windows Olay Görüntüleyicisi'ndeki Exchange Server uygulama günlüğünde sorgu sırasında yapılan girişleri arayın.

Başa dön

Uzak sunucuya bağlanılamıyor

Sorun

Bulut kullanıcısının serbest/meşgul bilgilerini görüntüleyemeyen bir şirket içi kullanıcınız var. Sorunu tanıladığınızda aşağıdaki hata iletisini bulursunuz:

., iç özel durumu ile https://login.microsoftonline.com/extSTS.srfiletişim kurulamıyor: Uzak sunucuya bağlanılamıyor.

Bir veya daha fazla Exchange sunucusu Microsoft Federasyon Ağ Geçidi URL'sine bağlanamıyorsa bu hata oluşabilir.

Sorun giderme adımları

Her adımı tamamladıktan sonra serbest/meşgul sorununun düzeltilip düzeltimediğini denetleyin.

1. Temsilci belirtecini alıp alamayacağınızı denetlemek için Exchange Yönetim Kabuğu'nda (EMS) aşağıdaki PowerShell cmdlet'lerini çalıştırın:

   Test-OrganizationRelationship -Identity "On-premises to O365*" -UserIdentity <on-premises user ID> -Verbose
   Test-FederationTrust -UserIdentity <on-premises user ID> -Verbose
   Test-FederationTrustCertificate
   

2. Şirket içi Exchange sunucularınızın aşağıdaki kaynakların her ikisine de giden İnternet erişimine sahip olduğunu doğrulayın:

   • OAuth kimlik doğrulaması kullanıyorsanız Microsoft Federasyon Ağ Geçidi veya Microsoft yetkilendirme sunucusu.

   • Microsoft 365 için kullanılabilirlik URL'si: https://outlook.office365.com/ews/exchange.asmx.

   Daha fazla bilgi için bkz. Microsoft 365 URL'leri ve IP adresi aralıkları ve Federasyon temsilcisi için güvenlik duvarı konuları.

3. Exchange Server'daki Sistem hesabının aşağıdaki URL'lere İnternet erişimi olduğunu doğrulayın. Kuruluşunuzdaki tüm Exchange Sunucularında şu adımları izleyin:

   1. Sistem hesabından bir web tarayıcısı başlatan bir PowerShell oturumu başlatmak için aşağıdaki PsExec komutunu çalıştırın:

      PsExec.exe -i -s "C:\Program Files\Internet Explorer\iexplore.exe"
      

   2. Sistem hesabından aşağıdaki Microsoft Federasyon Ağ Geçidi URL'lerine tarayıcı erişimini test edin (OAuth kimlik doğrulaması yok):

      • https://nexus.microsoftonline-p.com/federationmetadata/2006-12/federationmetadata.xml

        Tarayıcı bir xml sayfası görüntülemelidir.

      • https://login.microsoftonline.com/extSTS.srf

        Tarayıcı sizden dosyayı indirmenizi istemelidir.

      • https://domains.live.com/service/managedelegation2.asmx

        Tarayıcı ManageDelegation2 tarafından desteklenen işlemlerin listesini görüntülemelidir.

   3. Sistem hesabından aşağıdaki Microsoft yetkilendirme sunucusu URL'lerine tarayıcı erişimini (OAuth kimlik doğrulaması) test edin:

      • https://outlook.office365.com/ews/exchange.asmx

        Tarayıcı bir oturum açma istemi göstermelidir.

      • https://login.windows.net/common/oauth2/authorize

        Tarayıcı, "Üzgünüz, ancak oturum açarken sorun yaşıyoruz" hata iletisini görüntülemelidir.

      • https://accounts.accesscontrol.windows.net/<tenant guid>/tokens/OAuth/2

        Tarayıcı HTTP durum kodunu 400 Bad Request veya "Üzgünüz, ancak oturum açmada sorun yaşıyoruz" hata iletisini görüntülemelidir.

Başa dön

E-posta adresi için otomatik bulma başarısız oldu: Uzak ad çözümlenemedi

Sorun

Şirket içi kullanıcının serbest/meşgul bilgilerini görüntüleyemeyen bir bulut kullanıcınız var. Sorunu tanıladığınızda aşağıdaki hata iletisini bulursunuz:

Otomatik Bulma, System.Net.WebException: Uzak ad çözümlenemedi: '<şirket içi ana bilgisayar adı>' hatasıyla E-Posta Adresi <kullanıcı e-posta adresi> için başarısız oldu.

Şirket içi Otomatik Bulma uç noktası URL'si veya genel DNS ayarları yanlışsa bu hata oluşabilir.

Sorun giderme adımları

Her adımı tamamladıktan sonra serbest/meşgul sorununun düzeltilip düzeltimediğini denetleyin.

1. Parametresinin değerini TargetAutodiscoverEpr almak için Exchange Online PowerShell'de aşağıdaki PowerShell cmdlet'lerini çalıştırın:

   Get-IntraOrganizationConnector | FL TargetAutodiscoverEpr
   Get-OrganizationRelationship | FL TargetAutodiscoverEpr
   

   Örneğin, hata iletisindeki şirket içi ana bilgisayar adı değeri ise mail.contoso.com, Otomatik Bulma uç noktası URL'si büyük olasılıkla olacaktır https://autodiscover.contoso.com/autodiscover/autodiscover.svc.

   TargetAutodiscoverEpr Parametre değeri doğruysa 3. adıma gidin. Aksi takdirde 2. adıma gidin.

2. Aşağıdaki yöntemlerden birini kullanarak Otomatik Bulma uç noktası URL'sini güncelleştirin:

   • Varsayılan Otomatik Bulma uç noktasını geri yüklemek için Karma Yapılandırma Sihirbazı'nı (HCW) çalıştırın.

   • Aşağıdaki PowerShell cmdlet'lerinden DiscoveryEndpoint birini çalıştırarak parametreyi veya TargetAutodiscoverEpr parametreyi el ile güncelleştirin:

     • Set-IntraOrganizationConnector -Identity <cloud connector ID> -DiscoveryEndpoint <Autodiscover endpoint URL>

     • Set-OrganizationRelationship <O365 to On-premises*> -TargetAutodiscoverEpr <Autodiscover endpoint URL>

3. Hata iletisindeki şirket içi ana bilgisayar adının (örneğin: mail.contoso.com) genel DNS'de çözümlenebilir olduğundan emin olun. Ana bilgisayar adı için DNS girdisi, Otomatik Bulma uç noktası URL'sinde şirket içi Otomatik Bulma hizmetine işaret etmelidir.

   Not: Sorunu çözemiyorsanız ve geçici bir geçici çözüm istiyorsanız, parametre değerini dış Exchange Web Hizmetleri (EWS) URL'sine el ile güncelleştirmek TargetSharingEpr için aşağıdaki PowerShell cmdlet'lerinden birini çalıştırın. Dış EWS URL'si DNS'de benzer https://<EWS hostname>/ews/exchange.asmx ve çözümlenebilir olmalıdır.

   • Set-IntraOrganizationConnector <cloud connector ID> -TargetSharingEpr <external EWS URL>

   • Set-OrganizationRelationship <O365 to On-premises*> -TargetSharingEpr <external EWS URL>

   Not

   Parametre değerini ayarlarsanız TargetSharingEpr bulut posta kutusu Otomatik Bulma'yı atlar ve doğrudan EWS uç noktasına bağlanır.

Başa dön

ASURL alınamadı. Hata 8004010F

Sorun

Bulut kullanıcısının serbest/meşgul bilgilerini görüntüleyemeyen bir şirket içi kullanıcınız var. Sorunu tanıladığınızda aşağıdaki hata iletisini bulursunuz:

ASURL alınamadı. Hata 8004010F.

Bu, Otomatik Bulma hizmetiyle ilgili genel bir hatadır.

Sorun giderme adımları

Her adımı tamamladıktan sonra serbest/meşgul sorununun düzeltilip düzeltimediğini denetleyin.

1. Etkilenen kullanıcı için Otomatik Bulma'nın kullanıcının Exchange Web Services (EWS) URL'sini döndürdüğünden emin olun.

2. Otomatik Bulma'nın kullanıcının EWS URL'sini döndürdüğünden emin olmak için etkilenen kullanıcının Outlook istemcisinde e-posta otomatik yapılandırma testini çalıştırın.

3. Serbest/meşgul seçeneğinin farklı Exchange sunucularında barındırılan şirket içi kullanıcılar arasında çalıştığından emin olun.

4. Yük dengeleyicileriniz varsa soruna yük dengeleyicilerin neden olup olmadığını denetleyin. Bunu yapmak için Windows Konakları dosyasını (kullanıcının Outlook istemcisinin yüklü olduğu bilgisayarda) yük dengeleyicileri atlayacak ve belirli bir İstemci Erişim sunucusuna işaret eden şekilde değiştirin.

5. Serbest/meşgul şirket içi kullanıcılar arasında çalışıyorsa, tüm şirket içi Exchange sunucularının Microsoft 365 URL'lerine ve IP adresi aralıklarına giden erişimi olup olmadığını denetleyin.

6. Her Exchange sunucusunun temsilci belirteci alıp alamayacağını denetleyin. Bunu yapmak için, tüm şirket içi Exchange sunucularında EMS'de aşağıdaki PowerShell cmdlet'ini çalıştırın:

   Test-FederationTrust -UserIdentity <on-premises user ID> -Verbose
   

   Komut temsilci belirtecini alamazsa, sunucunun ara sunucu veya güvenlik duvarı düzeyinde Office 365'e bağlanıp bağlanamadığını denetleyin.

Başa dön

Proxy web isteği başarısız oldu: Nesne taşındı

Sorun

Şirket içi kullanıcının serbest/meşgul bilgilerini görüntüleyemeyen bir bulut kullanıcınız var. Sorunu tanıladığınızda aşağıdaki hata iletisini bulursunuz:

Proxy web isteği başarısız oldu. , iç özel durum: System.Net.WebException: İstek şu hata iletisiyle başarısız oldu: Nesne taşındı.

Kuruluş ayarlarındaki TargetSharingEpr parametre değeri yanlış bir Exchange Web Services (EWS) uç noktası URL'sine ayarlanırsa bu hata oluşabilir.

Kuruluş ayarlarından parametre değerini almak TargetSharingEpr için aşağıdaki PowerShell cmdlet'lerini çalıştırabilirsiniz (kuruluş içi bağlayıcı veya kuruluş ilişkisi):

Get-IntraOrganizationConnector | FL TargetSharingEpr
Get-OrganizationRelationship | FL TargetSharingEpr

Parametre değerinin TargetSharingEpr genel DNS'de çözülmediğini doğrulayın.

Not: Karma Aracı yüklemek için Exchange Modern Karma Teknolojisini Kullan'ı seçmediğiniz sürece Karma Yapılandırma Sihirbazı (HCW) parametre için TargetSharingEpr bir değer ayarlamaz. Bu senaryoda, HCW parametresini TargetSharingEpr benzer https://<GUID>.resource.mailboxmigration.his.msappproxy.net/ews/exchange.asmxbir dış EWS URL uç noktası değerine ayarlar. Parametre değerini el ile de ayarlayabilirsiniz TargetSharingEpr . TargetSharingEpr Değer bir uç noktaya ayarlanırsa, Outlook Otomatik Bulma'yı atlar ve doğrudan bu uç noktaya bağlanır.

Çözüm

Sorunu düzeltmek için aşağıdaki komutlardan birini çalıştırarak parametre değerini DNS'de çözülen bir dış EWS URL'sine el ile güncelleştirin TargetSharingEpr :

• Set-IntraOrganizationConnector <cloud connector ID> -TargetSharingEpr <external EWS URL>
• Set-OrganizationRelationship <O365 to On-premises*> -TargetSharingEpr <external EWS URL>

Başa dön

İstek durduruldu: SSL/TLS güvenli kanalı oluşturulamadı

Sorun

Şirket içi bir kullanıcının serbest/meşgul bilgilerini görüntüleyemeyen veya tam tersi olan bir bulut kullanıcınız var. Sorunu tanıladığınızda aşağıdaki hata iletisini bulursunuz:

İstek durduruldu: SSL/TLS güvenli kanalı oluşturulamadı.

Neden 1: Bulut kullanıcısı şirket içi kullanıcının serbest/meşgul bilgilerini görüntüleyemez

TLS 1.2, Exchange Server veya güvenlik duvarı gibi Microsoft 365'in bağlanabileceği şirket içi uç noktada yanlış yapılandırılmış veya devre dışı bırakılmışsa sorun oluşabilir.

Neden 2: Şirket içi kullanıcı, bulut kullanıcısı için serbest/meşgul bilgilerini görüntüleyemez

Sorun aşağıdaki nedenlerden herhangi biri nedeniyle de oluşabilir:

• Güvenilen kök Sertifika Yetkilileri (outlook.office365.comCA) deposunda Microsoft 365 sertifikası () eksik.
• Cypher paketi uyuşmazlığı var.
• Diğer SSL/TLS sorunları.

Sorun giderme adımları

Şirket içi TLS 1.2 sorunlarını tanılamak için aşağıdaki araçları kullanın:

• SSL sunucu testini Microsoft Uzak Bağlantı Çözümleyicisi'nde çalıştırın.
• Her Exchange sunucusundaki Exchange Yönetim Kabuğu'nda (EMS) HealthChecker betiğini çalıştırın.

TLS yapılandırması hakkında bilgi için bkz. Exchange Server TLS yapılandırma en iyi yöntemleri ve TLS 1.2 için hazırlanma.

Güvenilen kök CA deposunda sertifikaları denetleme hakkında bilgi için bkz. MMC ek bileşeniyle sertifikaları görüntüleme.

Desteklenen TLS şifreleme paketleri hakkında bilgi için bkz. Microsoft 365 tarafından desteklenen TLS şifreleme paketleri.

Başa dön

Belirteçte kullanıcı bağlamı tarafından belirtilen kullanıcı yok

Sorun

Bulut kullanıcısının serbest/meşgul bilgilerini görüntüleyemeyen bir şirket içi kullanıcınız var. Sorunu tanıladığınızda aşağıdaki hata iletisini bulursunuz:

Belirteçte kullanıcı bağlamı tarafından belirtilen kullanıcı yok. error_category="invalid_user". 401: Yetkisiz.

Test-OAuthConnectivity PowerShell cmdlet'ini çalıştırırsanız aynı hata iletisini alırsınız.

Şirket içi kullanıcı posta kutusu ve Microsoft Entra Id'deki ilgili posta kullanıcısı nesnesi eşitlenmediyse hata oluşabilir. Eşitlenene kadar, Microsoft Entra Id'deki posta kullanıcısı nesnesi sağlanmamış olabilir.

Çözüm

Sorunu çözmek için Microsoft Entra Connect'i kullanarak şirket içi kullanıcıyı ve Microsoft Entra Id'deki ilgili posta kullanıcısı nesnesini eşitleyin.

Başa dön

hedef kitle talep değerinin ana bilgisayar adı bileşeni geçersiz

Sorun

Şirket içi kullanıcının serbest/meşgul bilgilerini görüntüleyemeyen bir bulut kullanıcınız var. Sorunu tanıladığınızda aşağıdaki hata iletisini bulursunuz:

'https://< hybrid.domain.com>' hedef kitle talep değerinin ana bilgisayar adı bileşeni geçersiz; error_category="invalid_resource"

Hata aşağıdaki nedenlerden biri nedeniyle oluşabilir.

Neden 1

SSL boşaltma ve OAuth kimlik doğrulamasının her ikisi de etkindir. OAuth kimlik doğrulaması etkinse SSL boşaltma çalışmaz.

Neden 2

Exchange Server'ın önündeki bir ağ cihazı serbest/meşgul isteklerini engelliyor.

Çözüm

Neden 1 için geçici çözüm

Aşağıdaki geçici çözümlerden birini seçin:

• Şirket içi ortamda hem Exchange Web Hizmetleri (EWS) hem de Otomatik Bulma için SSL boşaltmayı devre dışı bırakın. Daha fazla bilgi için bkz. Otomatik Bulma için SSL boşaltmayı yapılandırma ve EWS için SSL boşaltmayı yapılandırma ve varsayılan SSL ayarları.

• Bulut kuruluş içi bağlayıcısını devre dışı bırakarak OAuth kimlik doğrulamasını devre dışı bırakmak için aşağıdaki PowerShell cmdlet'ini çalıştırın:

  Set-IntraOrganizationConnector "HybridIOC*" -Enabled $false
  

  Kuruluş içi bağlayıcı devre dışı bırakıldığında, kuruluş ilişkisi aracılığıyla DAuth kimlik doğrulaması etkinleştirilir. Kuruluş ilişkisini denetlemek için aşağıdaki PowerShell cmdlet'ini çalıştırın:

  Get-OrganizationRelationship
  

  Kuruluş ilişkisi ayarları hakkında daha fazla bilgi için bkz. Karma Serbest/Meşgul'ün yetkisini kaldırma.

Neden 2 için çözüm

Exchange'in önündeki ağ cihazını serbest/meşgul isteklerini engelleyecek şekilde yapılandırın.

Başa dön

Proxy web isteği HTTP durumu 503 ile başarısız oldu: Hizmet kullanılamıyor

Sorun

Şirket içi kullanıcının serbest/meşgul bilgilerini görüntüleyemeyen bir bulut kullanıcınız var. Sorunu tanıladığınızda aşağıdaki hata iletisini bulursunuz:

Proxy web isteği başarısız oldu, iç özel durum: System.Net.WebException: İstek HTTP durumu 503: Hizmet Kullanılamıyor...

Durdurulmuş bir Microsoft Windows hizmeti, sunucu bileşeni, IIS uygulama havuzu veya yanlış yapılandırılmış bir uç nokta varsa bu hata oluşabilir.

Sorun giderme adımları

Her adımı tamamladıktan sonra serbest/meşgul sorununun düzeltilip düzeltimediğini denetleyin.

1. Exchange Server'ın gerektirdiği Windows hizmetlerinin çalıştığından emin olun. Hizmetlerin durumunu denetlemek için, kuruluşunuzdaki her Exchange sunucusunda aşağıdaki PowerShell cmdlet'ini çalıştırın:

   Test-ServiceHealth
   

   Exchange Server'ın gerektirdiği durdurulmuş hizmetleri başlatmak için Hizmetler konsolunu kullanın.

2. Gerekli Exchange Server bileşenlerinin etkin olup olmadığını denetleyin. Bileşenlerin durumunu denetlemek için, kuruluşunuzdaki her Exchange sunucusunda aşağıdaki PowerShell cmdlet'ini çalıştırın:

   Get-ServerComponentState <server name>
   

   Etkin olmayan bir bileşeni etkinleştirmek için Set-ServerComponentState PowerShell cmdlet'ini kullanın.

3. Exchange Web Services (EWS) ve Otomatik Bulma için aşağıdaki IIS uygulama havuzlarının başlatıldığından emin olun:

   • MSExchangeServicesAppPool
   • MSExchangeSyncAppPool
   • MSExchangeAutodiscoverAppPool

4. Otomatik Bulma uç noktasının geçerli olup olmadığını test edin. Şu adımları izleyin:

   1. veya TargetAutodiscoverEpr parametre değerlerinden Otomatik Bulma uç noktası URL'sini almak için aşağıdaki PowerShell cmdlet'lerini DiscoveryEndpoint çalıştırın:

      Get-IntraOrganizationConnector | FL DiscoveryEndpoint
      Get-OrganizationRelationship | FL TargetAutodiscoverEpr
      

   2. Url'nin geçerli olduğundan emin olmak için web tarayıcısında Otomatik Bulma uç noktası URL'sine gidin veya PowerShell cmdlet'ini çalıştırın Invoke-WebRequest -Uri "<endpoint URL>" -Verbose . Tercihen, bir dış ağdan URL'yi denetleyin.

5. Aşağıdaki adımları izleyerek EWS URL'sinin geçerli olup olmadığını test edin:

   1. Kuruluş ayarlarında parametre değerinden EWS URL'sini TargetSharingEpr almak için aşağıdaki PowerShell cmdlet'lerini çalıştırın:

      Get-IntraOrganizationConnector | FL TargetSharingEpr
      Get-OrganizationRelationship | FL TargetSharingEpr
      

   b. Web tarayıcısında EWS URL'sine gidin veya URL'nin Invoke-WebRequest -Uri "<endpoint URL>" -Verbose geçerli olduğundan emin olmak için PowerShell cmdlet'ini çalıştırın. Tercihen, bir dış ağdan URL'yi denetleyin.

6. HTTP durum kodu 503 Service Unavailabledöndüren serbest/meşgul istekleri için IIS günlüklerini denetleyin:

   1. Exchange Online'dan serbest/meşgul isteğinde bulunabilirsiniz.

   2. Her Exchange sunucusundaki varsayılan web sitesi için W3SVC1 klasöründeki IIS günlüklerindeki HTTP durum kodu 503 Service Unavailable girdilerini denetleyin. W3SVC1 klasör yolu şeklindedir%SystemDrive%\inetpub\logs\LogFiles\W3SVC1. Bu girdiler, sorunu olan sunucuyu tanımlamaya yardımcı olabilir.

   3. Serbest/meşgul isteği W3SVC1 klasörüne kaydedilmemişse, isteğin her Exchange sunucusundaki HTTPERR klasöründeki hata günlüklerinde günlüğe kaydedilip kaydedilmediğini denetleyin. HTTPERR klasör yolu şeklindedir%SystemRoot%\System32\LogFiles\HTTPERR. Serbest/meşgul isteği HTTPERR günlüklerinde günlüğe kaydedildiyse yanlış yapılandırılmış IIS ayarlarını denetleyin.

7. Iis'nin (farklı bir web sunucusu değil) yanıtı gönderdiğini doğrulamak için şirket içi EWS URL'sine bağlandığınızda aldığınız sunucu yanıtının üst bilgisini denetleyin. Bunu yapmak için, şirket içi EWS'ye bağlı olmayan bir PowerShell oturumunda aşağıdaki komutları çalıştırın (Exchange Yönetim Kabuğu'nda komutları çalıştırmayın):

   $req = [System.Net.HttpWebRequest]::Create("<EWS URL>") 
   $req.UseDefaultCredentials = $false $req.GetResponse()
   $ex = $error[0].Exception
   $ex.InnerException.Response $resp.Headers["Server"]
   

   Örneğin, komut çıkışında "Microsoft -IIS/10.0" yerine "Microsoft-HTTPAPI/2.0" ifadesini görüyorsanız, büyük olasılıkla bir Web Uygulaması Ara Sunucusu (WAP) hizmeti (IIS değil) isteğe yanıt verdi. WAP hizmetinin devre dışı olup olmadığını denetleyin.

Başa dön

Proxy web isteği HTTP durumu 504: Ağ geçidi zaman aşımı ile başarısız oldu

KAPAK: 43532

Sorun

Şirket içi kullanıcının serbest/meşgul bilgilerini görüntüleyemeyen bir bulut kullanıcınız var. Sorunu tanıladığınızda aşağıdaki hata iletisini bulursunuz:

Proxy web isteği başarısız oldu, iç özel durum: İstek HTTP durumu 504: Ağ Geçidi Zaman Aşımı ile başarısız oldu...

Kuruluşunuzdaki bir Karma Aracı yanlış yapılandırılmışsa bu hata oluşabilir.

Çözüm

Sorunu düzeltmek için aşağıdaki adımları kullanın. Her adımı tamamladıktan sonra serbest/meşgul sorununun düzeltilip düzeltimediğini denetleyin.

1. TargetSharingEpr Kuruluş ayarlarında parametre değerini denetleyin. Değeri benzer https://<GUID>.resource.mailboxmigration.his.msappproxy.net/EWS/Exchange.asmxolmalıdır. parametresinin TargetSharingEpr değerini belirlemek için aşağıdaki PowerShell cmdlet'lerini çalıştırın:

   Get-IntraOrganizationConnector | FL TargetSharingEpr
   Get-OrganizationRelationship | FL TargetSharingEpr
   

   TargetSharingEpr Parametre değeri yanlışsa:

   1. Karma Yapılandırma Sihirbazı'nı (HCW) çalıştırın ve Exchange Klasik Karma Topolojisini Kullan'ı seçin.

   2. HCW'yi yeniden çalıştırın ve Exchange Modern Karma Topolojisi Kullan'ı seçin. Bu yordam, HCW'yi parametre değerini sıfırlamaya zorlar TargetSharingEpr .

2. Karma Aracı'nın yüklü olduğu sunucuda Microsoft Karma Hizmeti'nin durumunu denetleyin . Hizmet durdurulduysa başlatın.

3. Karma Aracı'nın durumunu denetleyin. Durum Etkin Değil ise:

   1. Karma Yapılandırma Sihirbazı'nı (HCW) çalıştırın ve Exchange Klasik Karma Topolojisini Kullan'ı seçin.

   2. HCW'yi yeniden çalıştırın ve Exchange Modern Karma Topolojisi Kullan'ı seçin. Bu yordam, HCW'yi Karma Aracı'nın yeniden yüklenmesine zorlar.

   3. Karma Aracı PowerShell modülünü yükleyin ve ardından Karma Aracı'nın işaret yaptığı iç URL'yi bulmak için Get-HybridApplication PowerShell cmdlet'ini çalıştırın.

4. 3. adımda bulduğunuz iç URL'ye göz atın. Sertifika hataları gibi bulduğunuz hataları düzeltin.

5. Karma Aracısı'nı, microsoft Exchange Server çalıştıran bir sunucu yerine bir yük dengeleyiciye istekleri yönlendirecek şekilde yapılandırarak bu sunucuda mevcut olabilecek sorunları eleyin.

6. Karma Aracı'nın serbest/meşgul isteklerini ve posta kutusu geçişini desteklediğini doğrulayın.

Başa dön