Bu sorun büyük olasılıkla Outlook Anywhere işlevinin bir parçası olan Outlook'un Otomatik Bulma hizmetinden kaynaklanmaktadır . Otomatik Bulma, son kullanıcının Outlook istemcisine Exchange tarafından sunulan çeşitli hizmetler ve bunların nerede bulunabileceği hakkında çeşitli bilgiler sağlar; bu çeşitli amaçlar için kullanılır:
Outlook'un ilk çalıştırılmasında Outlook profillerinin otomatik olarak yapılandırılması; bu, diğer bilgilerin otomatik olarak bulunduğu ve alındığı için Exchange hesabını yalnızca kullanıcının e-posta adresini ve parolasını kullanarak yapılandırabilir.
Ofis dışında asistanı, Birleşik Mesajlaşma işlevi, Exchange Denetim Masası'nın (ECP) konumu ve benzeri dahil olmak üzere Outlook istemcisi tarafından erişilen web tabanlı hizmetlerin dinamik konumu.
Bu, Microsoft'un tescilli RFC 6186 uygulamasıdır . Ne yazık ki, Outlook Anywhere'in tasarımında bu RFC'nin tavsiyelerini gerçekten takip etmediler, ancak HTTPS işlevselliği üzerinden Exchange ve RPC geleneksel IMAP / SMTP sunucusu olmadığından, bu beklenebilir.
Otomatik Bulma nasıl çalışır (harici * kullanıcılar için)?
Otomatik Bulma, bir istemci Erişim Sunucusundaki (bu durumda tüm roller SBS sunucusundadır) bir web hizmetiyle iletişim kurar /Autodiscover/Autodiscover.xmlve varsayılan web sitesinden çıkar. İletişim kurulacak sunucunun FQDN'sini bulmak için, e-posta adresinin kullanıcı kısmını kaldırır ve etki alanını terk eder (yani @ companyB.com). Sırasıyla aşağıdaki URL'lerin her birini kullanarak Otomatik Bulma ile iletişim kurmaya çalışır:
https://companyB.com/Autodiscover/Autodiscover.xmlhttps://autodiscover.companyB.com/Autodiscover/Autodiscover.xml
Bunlar başarısız olursa, SSL'yi devre dışı bırakarak ve 80 numaralı bağlantı noktasında (HTTP) iletişim kurmaya çalışarak güvenli olmayan bir bağlantı kurmayı dener, tipik olarak kullanıcıdan bunun kabul edilebilir bir eylem olduğunu onayladıktan sonra (benim görüşüme göre kusurlu bir seçenek olacaktır) genellikle bunu onaylar ve kimlik bilgilerini düz metin üzerinden gönderme riski vardır - ve kimlik bilgilerinin güvenli bir şekilde iletilmesini gerektirmeyen clueless sistem yöneticileri ve işe duyarlı veriler iş sürekliliği için bir risktir).
Son olarak, DNS'de companyB.comad alanı dışında iyi bilinen bir konumda bulunan ve Outlook'u sunucunun dinlediği doğru URL'ye yönlendirebilen bir hizmet kaydı (SRV) kullanılarak bir izleme denetimi yapılır .
Ne yanlış gidebilir?
Bu süreçte birkaç sorundan biri ortaya çıkabilir:
DNS girişi yok
Genellikle, etki alanının ( companyB.com) kökü DNS'deki bir ana bilgisayar kaydına çözümlenmeyebilir. Hatalı DNS yapılandırması (veya Outlook Anywhere hizmetini ifşa etmeme konusundaki bilinçli bir karar) autodiscover.companyB.comkaydın da bulunmadığı anlamına gelebilir .
Bu durumlarda, büyük bir sorun yoktur; Outlook, bilinen son yapılandırmayı kullanarak Exchange ile iletişim kurmaya devam eder ve URL'leri Otomatik Bulma (ofis dışı asistanı gibi) yoluyla alması gereken bazı web tabanlı işlevlere göre degrade olabilir. Çözüm, bu tür işlevlere erişmek için Outlook Web Access'i kullanmaktır.
Exchange hesaplarının yeni Outlook profillerinde otomatik olarak yapılandırılması da otomatik değildir ve HTTPS ayarları üzerinden RPC'nin el ile yapılandırılmasını gerektirir. Ancak bu, açıkladığınız soruna neden olmaz.
Hatalı SSL sertifikaları
Outlook'un Exchange Server ile bağlantı kurmak için kullandığı URL'nin bir İstemci Erişim Sunucusu olabilecek veya olmayabilecek bir ana bilgisayara çözümlenmesi tamamen mümkündür. Outlook, 443 numaralı bağlantı noktasında bu sunucuyla iletişim kurabiliyorsa, elbette Outlook ile uzak sunucu arasında güvenli bir kanal oluşturmak için sertifikalar değiştirilir. URL Outlook'un konuştuğuna inanıyorsa, ortak ad veya konu alternatif adı (SAN) olarak bu sertifikada listelenmiyorsa, bu, Outlook'un ilk yayınınızda açıkladığınız iletişim kutusunu sunmasını sağlar.
Bu, DNS'nin nasıl yapılandırıldığına ve yukarıda açıkladığım URL'lerin Outlook tarafından nasıl kontrol edildiğine bağlı olarak birkaç nedenden dolayı olabilir:
Eğer https://companyB.com/bir konak kaydına ... URL giderir ve 443 numaralı bağlantı noktasında o adres dinler de web sunucusu, ve öyle bir SSL sertifikası vardır değil listeyi companyB.comortak adı veya Konu Alternatif Adı içinde, sorun ortaya çıkar. Ana bilgisayarın bir Exchange Sunucusu olup olmadığı önemli değildir; düzgün yapılandırılmamış bir şirket web sitesini barındıran bir web sunucusu olabilir. Corrige ya:
companyB.comBölgenin kökündeki ana bilgisayar kaydını devre dışı bırakın (web sitesine veya başka bir hizmete gelen ziyaretçilerin girmesini www.companyB.comveya eşdeğer olmasını gerektirir) veyacompanyB.com443 numaralı bağlantı noktasından makineye erişimi devre dışı bırakarak, companyB.comsertifikalar değiş tokuş edilmeden ve devam etmeden önce Outlook'un URL'yi reddetmesine neden olur ; veya- Bu sertifikada listelendiğinden ve standart bir tarayıcıda ziyaret etme denemelerinin başarısız
companyB.comolduğundan emin olmak için sertifikayı düzeltin .companyB.comhttps://companyB.com
Yukarıdakiler companyB.com, Exchange Server için çözüm olup olmadığına bakılmaksızın uygulanır ; Outlook onunla iletişim kurabiliyorsa, daha sonra /Autodiscover/Autodiscover.xmlyolun bir HTTP 404 hatası verdiğini (mevcut değil) keşfedecek ve devam edecektir .
Eğer https://autodiscover.companyB.com/yine Exchange Server (veya başka bir sunucuda) ama, ... URL giderir autodiscover.companyB.comortak ad veya alternatif konu adı olarak listede yoksa, bu davranışı gözlemlemek olacaktır. Bu sertifika düzeltilerek yukarıdaki gibi sabitlenebilir, ya sen haklı göstermek gibi bir kullanabilir SRV kaydı bir URL'ye Outlook yönlendirmek olduğu sertifikasında listelenen ve hangi Outlook edebilir iletişim kurarlar.
Bu sorunla ilgili olası çözümünüz
Bu durumda, tipik düzeltme ikincisini yapmaktır; Outlook'un yeniden yönlendirildiğinden emin olmak için yeni DNS sağlayıcısında SRV kayıtları oluşturun autodiscover.companyA.com; bu, sertifikada bir SAN olarak listelendiği için (başka bir sorun varsa) başarıyla çalışacaktır. Bunun çalışması için şunları yapmanız gerekir:
- Bir
_autodiscover._tcp.companyB.comSRV kaydını belgelere uygun olarak yapılandırın .
autodiscover.companyB.comOutlook'un bunu çözmesini ve Otomatik Bulmaya bu şekilde erişmeye çalışmasını önlemek için, varsa ana bilgisayar kaydını silin .https://companyB.comOutlook , SRV kaydı yaklaşımına geçmeden önce kullanıcının e-posta adresinden türetilen URL'leri sıralayacağından HTTPS erişimiyle ilgili sorunları da yukarıdaki gibi çözün .
* Otomatik Bulma nasıl çalışır (dahili, etki alanına katılmış istemciler için)?
Bunu yalnızca tamlık için ekliyorum, çünkü bu sertifika istemlerinin oluşmasının bir başka yaygın nedeni.
Etki alanına katılmış bir istemcide, Exchange ortamına (yani iç LAN'da) yerel olduğunda, yukarıdaki teknikler kullanılmaz. Bunun yerine Outlook, Active Directory'deki (Exchange İstemci Erişimi ayarlarında listelenen), Outlook'un Otomatik Bulma hizmetini bulabileceği URL'yi listeleyen bir Hizmet Bağlantı Noktası ile doğrudan iletişim kurar.
Bu durumlarda sertifika uyarılarının olması yaygındır, çünkü:
- Bu amaçla yapılandırılan varsayılan URL , genellikle genel URL'den farklı olan Exchange'in dahili URL'sini belirtir .
- SSL sertifikaları, üzerlerinde dahili URL'yi listelemeyebilir. Şu anda sizinki öyle, ancak bu, gelecekte
.localglobal olmayan gTLD alan adı soneklerini kullanan ve benzer Active Directory etki alanları için gelecekte bir sorun haline gelebilir , çünkü ICANN tarafından verilen bir karar, 2016 sonrası bu tür etki alanları için SSL sertifikalarının verilmesini yasaklamaktadır.
- Dahili adres uygun sunucuya çözümlenmeyebilir.
Bu durumda, kaydedilen URL, Set-ClientAccessServercmdlet'i -AutodiscoverServiceInternalUrianahtarla çalıştırarak doğru, harici adrese (sertifikada listelenen) başvurmak üzere düzeltilerek sorun çözülür . Bunu yapan taraflar, aynı zamanda , ağ yapılandırmaları tarafından yapılması gerektiği ve / veya bir yukarı akış çözümleyicisi / bağlantı kesintisi durumunda çözümün sürekliliği için bölünmüş ufuk DNS'sini de yapılandırırlar .