Office 365'te hibrit dağıtım | Kontrol listesi ve ön gereksinimler | Bölüm 2/3

Aşağıdaki makale, Hibrit yapılandırma kontrol listesi ve ön gereksinimler makale serisinin 2. bölümüdür. Aşağıdaki makalede, Hibrit ortama dahil olan ve Hibrit ortamla ilgili ek "bileşenleri" inceliyoruz:

• Exchange şirket içi sunucu EWS hizmetleri
• Exchange şirket içi sunucu Otomatik Bulma hizmetleri
• Exchange şirket içi sunucusu ve Genel Sertifika

Hibrit dağıtım Office 365 - Makale serisi

Makale serisi aşağıdaki makaleleri içermektedir:

• Office 365'te hibrit dağıtım | Kontrol listesi ve ön gereksinimler | Bölüm 1/3
• Office 365'te hibrit dağıtım | Kontrol listesi ve ön gereksinimler | Bölüm 2/3
• Office 365'te hibrit dağıtım | Kontrol listesi ve ön gereksinimler | Bölüm 3/3

7. Exchange Şirket İçi Hibrit sunucu | Otomatik keşfetme hizmeti

Otomatik Keşfet hizmeti, Exchange On-Premise ile Exchange Online ve bunun tersi arasındaki "Karma ilişkiler" için bir "temel" görevi görür.

Otomatik bulma hizmeti, Hibrit ortamın ilk kez yapılandırılması (HCW kullanılırken) ve Şirket İçi ile bulut ortamı arasında devam eden iletişim için kullanılacaktır.
Bu nedenle, Hibrit ortamın doğrulanması ve kontrol edilmesi kritik öneme sahiptir. Otomatik Bulma hizmetleriyle ilgili aşağıdaki bölümler:

1. Otomatik bulma kaydı ve Genel Ağ

Kuruluşun genel etki alanı için Otomatik Bulma kaydının yayınlandığını ve Exchange Şirket İçi sunucusunu işaret ettiğini doğrulamamız gerekecek.
Ayrılmış bir adlandırma kuralını temel alan Otomatik Bulma kaydı Şu şekilde uygulanır: Otomatik Bulma

Örneğin, o365info.com genel alanı için Otomatik Bulma kaydı şöyledir: Autodiscover.o365info.com

Otomatik Bulma kaydının doğru şekilde yayınlandığını ve Otomatik Bulma kaydının Şirket İçi Exchange sunucusunu işaret ettiğini kontrol edip doğrulamamız gerekecek

Aşağıdaki şemada Otomatik Keşfet işleminin açıklamasını görebiliriz.
Örneğimizde Exchange Online'ın o365info.com organizasyonu hakkında bilgi alması gerekiyor.

Gerekli bilgileri almak için Exchange Online genel bir DNS'ye erişir ve Autodiscover.o365info.com kaydı hakkında sorgu yapar.
Otomatik Keşfet DNS kaydının doğru şekilde yapılandırılması durumunda, DNS Genel IP'yi sağlar ve Exchange Online, Exchange Şirket İçi Otomatik Bulma hizmetleriyle iletişim kurmak için bu IP'yi kullanır.

DNS kaydını otomatik bulma | Rekor

Hibrit bir ortamda Otomatik Bulma, Genel DNS sunucusu aracılığıyla yayınlanan bir A kaydı olarak uygulanmalıdır.

Bazı senaryolarda Exchange Şirket İçi Otomatik Bulma yapılandırması SRV kaydını temel alır. Bu senaryo Hibrit ortamda desteklenmez.

Başka bir deyişle: geçerli Exchange Şirket İçi Otomatik Bulma'nın bir SRV DNS kaydını temel alması durumunda, bu yapılandırmayı, genele işaret eden bir kayıt kullanılarak uygulanan bir "standart Otomatik Bulma yapılandırması" ile değiştirmeniz/güncellemeniz gerekecektir. Exchange Şirket İçi sunucusunun IP adresi.

Bu kayıtları SAN sertifikasına da eklemeniz gerekir. Otomatik Bulma yeniden yönlendirmesi için CNAME kayıtlarını kullanabilirsiniz ancak bu, tüm Otomatik Bulma kayıtlarını SAN sertifikasına eklemeniz gerektiği gerçeğini değiştirmez. Ayrıca Exchange karma dağıtımları, SRV tabanlı Otomatik Bulma yeniden yönlendirmesini desteklemez.

Exchange Şirket İçi Otomatik Bulma işleminin başarılı bir şekilde çalıştığını doğrulama

Otomatik Bulma hizmetleri Kaydının ve Genel IP'nin yayınlanması, gerekli ayarların yalnızca ilk kısmıdır. Bir sonraki adımda, Exchange On-Premise Autodiscover hizmetine erişebildiğimizi + gerekli bilgileri aldığımızı doğrulamamız gerekiyor (Exchange On-Premise gerekli bilgileri bir XML dosyası kullanarak sağlayacaktır).

Aşağıdaki şemada, harici ana bilgisayarın (Exchange Online gibi) yerel Exchange On-Premise'a (Exchange on-Premises sunucusunun AutoDiscover hizmetleri) bağlanmaya çalıştığını görebiliriz.
Exchange on-Premises sunucusunun olması durumunda "Yanıtla", Exchange Online'ın tanımlaması gerekir ve başarılı bir kimlik doğrulamanın ardından Exchange On-Premise, autodiscover.xml adlı bir dosyayı kullanarak gerekli bilgileri sağlar.

Exchange Şirket İçi Otomatik Bulma hizmetinin kullanılabilirliğini doğrulama

Exchange On-Premise Autodiscover hizmetinin doğrulanması, Microsoft Remote Connectivity analyzer (MRCA) adlı çok güçlü ve önerilen bir araç kullanılarak uygulanabilir.

Aşağıdaki bölümde, Exchange Şirket İçi Otomatik Bulma hizmetinin kullanılabilirliğini doğrulamak için uygulamamız gereken gerekli adımların bir örneğini inceliyoruz.

1. Exchange sunucusu sekmesini seçin ve ardından “Microsoft Office Outlook Bağlantı Testleri” altında şu seçeneği seçin: Outlook Otomatik Keşfet

2. Exchange Şirket İçi kullanıcı kimlik bilgilerini sağlayın.
   Gerekli bilgileri alabilmek için, Exchange Şirket İçi posta kutusu olan kullanıcıların kullanıcı kimlik bilgilerini sağlamamız gerekecek.
   Örneğimizde, kullanıcıların kimlik bilgilerini kullanıyoruz adı: Kullanıcı2

3. Sonuç ekranında başlığın şöyle olduğunu görüyoruz: “Uyarı ile Bağlantı Testi Başarılı.”
   Sonuca rağmen bu “gerekli sonuç”tur. “Sarı ünlem işareti” içerir. Otomatik Bulma testi, varsayılan olarak Otomatik Bulma sürecinin "deneme yanılma" mekanizmasından kaynaklanan bazı küçük hataları içerecektir.
   "Yeşil simgeyi" almamız, Otomatik Bulma sürecinin başarılı bir şekilde uygulandığının göstergesidir. .

4. Daha detaylı bilgi almak istersek “Test Adımı”na tıklayabiliriz.
   Aşağıdaki ekran görüntüsünde Otomatik Bulma XML dosyasının içeriğini görebiliriz.

3. Otomatik Keşfet ve Şirket İçi Exchange sunucu sürümü

Birkaç Exchange On-Premise sürümünü içeren karma bir Exchange On-Premise ortamında, Otomatik Bulma kaydının en güncel Exchange On-Premise sunucu sürümünü "işaret ettiğini" doğrulamamız gerekecektir.

Teknik olarak, Exchange 2007 sürümünden bu yana Exchange sunucularının her biri Otomatik Bulma hizmetleri sağlayabilir, ancak Exchange sunucusunun gerekli verileri (XML dosyası) ve "Otomatik Bulma dosyasının" içeriğini "hazırlamasının" nedeni, bir Exchange sunucusu sürümlerinin her birinde farklı bir şekilde.

Karma Exchange ortamında, "geriye doğru hesaplanabilirlik" kavramı uygulanır.
"En yeni" Exchange sunucusu sürümü, Otomatik Bulma bilgilerine yönelik sorguları alabilir ve gerekli yanıtın nasıl biçimlendirileceğini "anlayabilir".

Örneğin, Otomatik Bulma kaydını Exchange 2013 sunucusuna yönlendirdiğimizde ve harici istemci, Exchange 2007 sunucusunda barındırılan bir alıcının (Kullanılabilirlik hizmetleri) Serbest\meşgul süresini sorduğunda, Exchange 2013 bunu nasıl "bilir"? Exchange 2007 sunucusundan gönderilen isteğin ve yanıtın uygun şekilde biçimlendirilmesi.

4. Exchange Şirket İçi sunucusuna işaret eden otomatik bulma kaydı

Otomatik Bulma kaydı ve Hibrit uygulamalarla ilgili en yaygın hatalardan biri, Otomatik Bulma kaydının "bulut"u (autodiscover.outlook.com) işaret edecek şekilde güncellenmesidir.
Bu varsayım mantıklı görünebilir, ancak bu güncelleme uygulanmaz.
Karma yapılandırmada, Genel etki alanı adını "temsil eden" Otomatik Bulma kaydı, Exchange Şirket İçi sunucusunu işaret etmelidir.

Not - Office 365'te Otomatik Bulma hizmetlerinin gerekli tüm yapılandırmaları, "hizmet etki alanı" veya Tenet Office kullanılarak otomatik olarak yapılandırıldığından, "bulut" ile ilgili Otomatik Bulma ayarlarından herhangi birini yapılandırmamıza veya güncellememize gerek yoktur. o365info.mail.onmicrosoft.com gibi 365 alan adı

8. Exchange Şirket İçi Hibrit sunucu | EWS hizmeti

Hibrit ortam, iki ayrı Exchange organizasyonunun tek bir varlık olarak faaliyet göstermesi konseptine dayanmaktadır. Örneğin, Şirket içi Exchange kullanıcılarının, Exchange Online alıcıları hakkındaki Serbest/Meşgul zaman bilgilerini görmesine, Ofis dışında iletilerini almasına ve çok daha fazlasına olanak tanıyın.
Şirket içi Exchange sunucusu ile Exchange Online arasındaki bu "işbirliğinin" altyapısı Exchange EWS (Exchange Web Hizmetleri) hizmetini temel alır.
Anlamı şudur:

• Exchange On-Premise'ın genel ağdan erişilebilir olması gerekecektir.
• Exchange Şirket İçi EWS hizmetlerinin doğru şekilde yapılandırılması gerekir.

Not - Hibrit yapılandırma, Exchange On-Premise'in aynı zamanda Exchange Online EWS'ye erişmesinin gerekeceği "iki yönlü bir ilişkiye" dayanmaktadır ancak temel varsayım, "bulut altyapısının" (Exchange Online) doğru şekilde yapılandırıldığı ve Çok nadir görülen olayların yanı sıra, bulut tarafının da izin verdiğini ve doğru şekilde yapılandırıldığını varsayıyoruz.

Doğrulayın - şu hizmetlerin kullanılabilirliğini kontrol edin: Exchange Şirket İçi Hibrit sunucu EWS hizmeti

Aşağıdaki seçeneklerden birini kullanarak Exchange On-Premise ve EWS hizmetinin kullanılabilirliğini kontrol edebilir veya doğrulayabiliriz:
Seçenek1: Exchange On-Premise ve EWS hizmetinin kullanılabilirliğini EWS URL'sini kullanarak doğrulayın\kontrol edin
Bu seçenekte, Exchange Şirket İçi Web hizmetlerinin (EWS) URL'sine erişmeyi deneyebiliriz.

Varsayılan URL, aşağıdaki adlandırma konuşmasını temel alır: https://ews/exchange.asmx

Senaryomuzda, Şirket İçi Exchange'in Genel adı şu şekildedir: mail.o3655info.com
Bir web tarayıcısı açacağız ve şu URL adresini kullanacağız: https://mail.o365info.com/ews/exchange.asmx

Aşağıdaki ekran görüntüsünde Exchange On-Premise'ın EWS hizmetlerini başarılı bir şekilde bağlayabildiğimizi görebiliriz.
Cevap olarak Exchange on-Premises sunucusu kimlik doğrulama için bir gereksinim gönderir.
Ayrıca şunu görebiliriz: Kilit simgesinde hata bulunmadığından sunucu sertifikası "uygundur".
Sağlamamız gereken kimlik bilgileri, Exchange Şirket İçi sunucusunda posta kutusu bulunan herhangi bir alıcının yalnızca basit bir kullanıcı kimlik bilgisidir.

Exchange Şirket İçi "yanıtı", Exchange Şirket İçi Web Hizmetleri hakkında gerekli bilgileri veya açıklamayı içeren bir XML dosyasıdır.

Bizim için gerçek bir anlamı yok. Tek anlamı Exchange On-Premise EWS hizmetine erişip Exchange sunucusu yanıtını alabilmemizdir.

2. Seçenek: Microsoft Uzaktan Bağlantı Analiz Aracı'nı kullanarak Exchange Şirket İçi ve EWS hizmetinin kullanılabilirliğini doğrulama/kontrol etme

Exchange Şirket İçi EWS hizmetinin Doğrulanması, Microsoft Uzaktan Bağlantı Analizcisi (MRCA) adlı çok güçlü ve önerilen bir araç kullanılarak uygulanabilir.

Aşağıdaki ekran görüntüsünde Exchange On-Premise EWS hizmetinin kullanılabilirliğini doğrulamak için uygulamamız gereken adımların bir örneğini görebiliriz.

1. Exchange sunucusu sekmesini seçin ve ardından “Microsoft Exchange Web Hizmetleri Bağlantı Testleri” altında seçeneği belirleyin : Senkronizasyon, Bildirim, kullanılabilirlik ve Otomatik yanıt

2. Exchange Şirket İçi kullanıcı kimlik bilgilerini sağlayın
Gerekli bilgileri alabilmek için, Exchange Şirket İçi posta kutusu olan kullanıcıların kullanıcı kimlik bilgilerini sağlamamız gerekecek.
Örneğimizde, kullanıcılar adı: Kullanıcı2

3. Sonuç ekranında başlığın şu şekilde olduğunu görüyoruz: “Uyarı ile Bağlantı Testi Başarılı.”
Bu, sonuçta bir "Sarı Ünlem işareti" bulunur.

Exchange Şirket İçi Web hizmeti testi, Otomatik Bulma işleminin "deneme yanılma" mekanizmasının neden olduğu bazı küçük hataları varsayılan olarak içerecektir.

“Yeşil simge”yi almamız, Exchange Şirket İçi Web hizmeti sürecinin başarılı bir şekilde uygulandığının göstergesidir.

4. Daha detaylı bilgi almak istersek “Test Adımı” seçeneğine tıklayabiliriz.
Aşağıdaki ekran görüntüsünde içeriği görebiliriz. Otomatik Bulma XML dosyasının.

9. Exchange Şirket İçi Hibrit sunucu | Kamu Sertifikası

Exchange Online ile Exchange On-Premise arasındaki iletişim kanalı, iletişim kanalının “güvenli” olduğu temel varsayımına dayanmaktadır. İletişim kanalının güvenliğinin sağlanması ihtiyacı, iki uç nokta arasındaki bilginin genel ağ üzerinden aktarılmasından kaynaklanmaktadır.

HTTPS ve SMTP\TLS gibi güvenli bir protokol ve veri şifrelemeyi oluşturmak için kullanılan bileşen kullanılarak gerçekleştirilen güvenli iletişim kanalının oluşturulması. Veri bütünlüğü, karşılıklı kimlik doğrulama vb., her iki tarafın da (Exchange Online ve Exchange On-Premise) kullandığı bir Genel sertifikaya dayanır.

Temel varsayım, Exchange Online Genel sertifikasının doğru yapılandırılmış ve kullanılabilir olmasıdır.

Senaryomuzda “Exchange On-Premise sunucu tarafında” Public sertifikanın konusunu doğrulamamız gerekecek.

Not: Sertifika isteğinin nasıl oluşturulacağı, Exchange On-Premise vb. üzerinde genel sertifika yüklenebileceği hakkında ayrıntılara girmeyeceğiz.
Temel varsayım, Exchange On-Premise'ın Genel sertifika izolasyonu içerdiği ve sadece Genel sertifikanın kurulu olduğunu doğrulamak ve gerekli bilgileri eklemek istiyoruz.

Exchange On-Premise genel sertifikası, AutoDiscover hizmetinin bir parçası olarak ve aslında Exchange On-Premise Sunucusu ile Exchange Online sunucusu arasındaki posta akışının (SMTP/TLS) şifrelenmesi için kullanılacaktır.

Aşağıdaki şemada Exchange On-Premise genel sertifikasına dahil edilmesi gereken “Ana Bilgisayar adları” için bir örnek görebiliriz.

Senaryomuzda, Exchange Şirket İçi genel sertifikası ana bilgisayarın adını içermelidir: Otomatik bulma hizmetleri için Autodiacover.o3655info.com ve ek ana bilgisayar adı - mail.o3655info.com
Bu, Exchange Online sunucusu tarafından Exchange Şirket İçi sunucusunu adreslemek için kullanılacak ana bilgisayar adıdır (Exchange Şirket İçi sunucusuna güvenli bir iletişim kanalı oluşturur).

Genel sertifika türleri

Birkaç Genel sertifika türü vardır. En yaygın türler şunlardır:
Joker karakter sertifikası ve SAN (Konu Alternatif Adı) sertifikası.
Bu iki tür arasındaki en büyük fark şudur: joker karakter sertifikası, belirli bir ana bilgisayarın adı ve SAN hakkında bilgi içermez Sertifikayı kullanmasına izin verilen "Ana Bilgisayar"ın belirli bir adını içermesi gereken sertifika.

Genel sertifika gereksinimleri

Exchange On-Premise'da Genel sertifika ayarını kontrol edebilmek/doğrulayabilmek için Exchange MMC, Sunucu yapılandırmasını kullanın, Exchange Sertifikası Sekmesine bakarak Hibrit sunucu adını (senaryomuzda EX01) seçin.

Exchange On-Premise sertifikasıyla ilgili üç ana gereksinim vardır:

1. Genel sertifika

“Genel sertifika” teriminin anlamı, Genel CA (Sertifika Yetkilisi) tarafından oluşturulan sertifikadır.
Aşağıdaki ekran görüntüsünde, Genel sertifika hakkında bilgi almak için Exchange 2010 On-Premise MMC arayüzünü kullanıyoruz.< br>"Kendinden İmzalı" bölümünde sertifikanın değerinin şu şekilde olduğunu görebiliriz: Yanlış (ekran görüntüsünde 1 sayısı).
Anlamı, bu sertifikanın olmadığıdır. Exchange Şirket İçi sunucusu tarafından oluşturulmuştur (kendinden İmzalıdır ancak bunun yerine bir Genel Sertifika sağlayıcısı tarafından oluşturulmuştur).

2. Sertifika ataması

Genel Sertifika şu Exchange hizmetlerine atanmalıdır: IIS ve SMTP (ekran görüntüsünde 2 sayısı).

3. SAN Genel sertifikası

SAN (Konu Alternatif Adı) sertifikası, sertifikayı kullanmasına "izin veren" ana bilgisayarların adını içerir. "Konu" terimi, SRV1 gibi basit bir ana bilgisayar adı veya mail.o3655info.com gibi FQDN olarak uygulanabilecek Ana Bilgisayar Adını tanımlar.

Exchange şirket içi sunucusu, genel sertifikasını Exchange Online'a "sunduğunda", Exchange Online'ın, Exchange Online alma bağlayıcısında yapılandırılan posta sunucusu adının, Exchange şirket içi sunucusunun sağladığı Genel sertifikaya dahil edilip edilmediğini kontrol etmesi gerekecektir.
(Senaryomuzda: Exchange şirket içi sunucu sağlayıcısının ana bilgisayar adını içermesi gereken Genel sertifika: mail.o3655info.com.

Konu Alternatif Adı alanını destekleyen bir Birleşik İletişim sertifikası kullanarak gerekli tüm DNS adlarını aynı sertifikada sağlamanızı öneririz. Birleşik İletişim sertifikasının kullanılması, Otomatik Bulma hizmetinin ve Exchange hizmetleri URL'lerinin yapılandırılması ve yönetilmesindeki karmaşıklığı azaltır. Ancak, bu tür bir sertifika halihazırda sahip olduğunuz tek isimli sertifikalardan daha pahalı olabileceğinden, Birleşik İletişim sertifikası kullanmak maliyeti artırabilir.

Sertifikalar - şirket içi ve Exchange Online kuruluşları arasında güvenli posta aktarımı için kullanılan dijital sertifika, tüm şirket içi İstemci Erişimi sunucularına kurulmalı, bir üçüncü taraf sertifika yetkilisinden (CA) verilmiş olmalı, süresi dolmuş olmalı ve IIS ve SMTP hizmetlerinin atanmış olması gerekir. Bu sertifika gereksinimleri karşılanmazsa Exchange Online kuruluşundan şirket içi kuruluşa güvenli posta aktarımı düzgün çalışmayacaktır.

Devamını oku: Karma dağıtım sorunlarını giderme.

Exchange şirket içi sunucusunun içeriğini doğrulayın ve denetleyin Genel sertifika

Seçenek 1: Exchange MMC'yi kullanarak Kamu Sertifikası hakkında bilgi edinin
Genel sertifikaya dahil edilen adı verilen ana bilgisayarları doğrulayabilmek için genel sertifikayı ve ayrıntı sekmesini çift tıklayın. alanı arayın - Konu Alternatif Adı

Aşağıdaki ekran görüntülerinde genel sertifikanın gerekli tüm ana bilgisayar adlarını içerdiğini görebiliriz.

2. Seçenek: OWA URL'sine erişerek Exchange Şirket İçi Genel sertifikasını kontrol edin
Exchange Şirket İçi genel sertifikasını kontrol etmenin diğer bir seçeneği de, Exchange Şirket İçi Genel sertifikasını kontrol etmek için kullanılan Exchange Şirket İçi URL'sine erişmektir. OWA erişimi.

Senaryomuzda OWA URL'si şu şekildedir: https://mail.o365info.com/owa

Aşağıdaki ekran görüntüsünde URL kullandığımızı görebiliriz, URL Çubuğunun sağ köşesinde sitenin sertifika sağladığı gerçeğini temsil eden kilit simgesini görebiliriz.

Kilit simgesine çift tıkladığımızda Exchange on-Premises sunucusunun sağladığı genel sertifikanın “içeriğini” görebileceğiz.

10. Microsoft MFG sunucusu ve sahiplik sürecinin kanıtı

Hibrit yapılandırma oluşturmamız gerektiğinde ilk adım, Exchange On-Premise sunucusunun Microsoft Federasyon Ağ Geçidi (MFG) ile güven ilişkileri oluşturduğu adımdır.
Bu güven ilişkisi Federasyon güveni

Not: Hibrit yapılandırmayı kullanırken her iki tarafın da (Exchange On-Premise ve Exchange Online) MFG'ye "güvenmesi" gerekir. Office 365 bulut altyapısı, MFG sunucusuna otomatik olarak güvenecek şekilde ayarlanmıştır; dolayısıyla tek gereksinim, Exchange On-Premise ile MFG arasında yeni bir güven "inşa etmektir".

Federasyon güveninin Microsoft MFG sunucusuyla "oluşturulması", kullandığımız genel alan adı için bir "sahiplik kanıtı" sürecinin uygulanmasıyla oluşturulur.

Örneğin: Karma yapılandırmayı genel alan adını kullanarak yapılandırmak istediğimiz durumda: o3655info.com, bu alanın sahibi olduğumuzu kanıtlamamız gerekir.

"Sahiplik kanıtı" süreci şu şekilde uygulanır: HCW kullanılırken Exchange On-Premise, Microsoft MFG sunucusuyla iletişim kurar.
MFG sunucusu bir "TXT dizesi" ile yanıt verir.

Bu metin dizesini kopyalamamız, genel DNS sunucumuza gitmemiz, MFG sunucusu tarafından sağlanan değeri içeren yeni bir TXT kaydı eklememiz gerekecek ve yalnızca "kanıtı" oluşturduktan sonra MFG sunucuları genel DNS'mize erişecektir. sunucu bu TXT dizesini arıyor.

Aşağıdaki diyagramda Microsoft MFG sunucusuyla güven oluşturmak için gereken akışın açıklamasını veya adımları görebiliriz.

HCW (Exchange Hibrit Yapılandırma sihirbazı) kullanıldığında, MFG sunucusundan gönderilen gerekli TXT dizisi ekranda görüntülenecektir.

Herhangi bir nedenle gerekli TXT dizesinin gösterilmemesi durumunda, TXT dizesini (TXT Etki Alanı Kanıtı) görüntülemek için PowerShell komutunu kullanabiliriz.

Kullandığımız PowerShell aşağıdaki sözdizimine dayanmaktadır:

Get-FederatedDomainProof -DomainName "<Domain name>"

Aşağıdaki ekran görüntüsünde Domain Proof Text dizisini görebiliriz.

1. Seçenek: Nslookup komutunu kullanarak TXT kaydının Genel DNS'de doğru yapılandırıldığını da doğrulayınl

TXT kaydının (TXT Etki Alanı Kanıtı) Genel DNS'de doğru yapılandırıldığını doğrulamak istediğimiz takdirde, bir TXT kaydı için sorgu oluşturabiliriz.
TXT kaydının (TXT Etki Alanı Kanıtı) Genel DNS'de yapılandırıldığını doğrulamak için Genel DNS'de, NSLOOKUP komutunu kullanarak bilgileri kontrol edebilirsiniz.

Örneğin - o3655info.com
alanında yapılandırılmış olan TXT kaydı hakkında bilgi almak için NSLOOKUP aracını kullanabiliriz, yazdığımız komut isteminden:

Nslookup
Set type=txt
Sonra sorgulamak istediğimiz alan adının adını yazacağız.
o365info.com

Aşağıdaki ekran görüntüsünde Nslookup komutunun sonucunu görebiliriz

2. Seçenek: Web aracını kullanarak Genel DNS'de TXT kaydının doğru şekilde yapılandırıldığını doğrulayın.
DNS sunucusunu sorgulamamıza yardımcı olabilecek birçok ücretsiz web aracı vardır.
Aşağıda örnek olarak MxToolbox sitesini kullanacağız.

1. Diğer menüsünü seçin

2. TXT seçeneğini seçin ve sorgulamak istediğiniz alan adını yazın.

Örneğimizde o365info.com alanındaki tüm TXT kayıtları hakkında bilgi almak istiyoruz.
Aşağıdaki ekran görüntüsünde sorgunun sonucunu görebiliriz. o365info.com etki alanı altında iki TXT kaydı bulunmaktadır.
Bu TXT kayıtlarından biri, Microsoft MFG sunucusu tarafından sağlanan ve o365info.com etki alanında TXT kaydı olarak güncellenen Metin dizesidir.

11. Doğrudan iletişim kanalı | Şirket içi sunucuyu Exchange Online'a değiştirin

Hibrit konfigürasyonda posta akışı konusu, gelen posta akışı ve giden posta akışına ilişkin birçok senaryoyla ilgilidir.

Örneğin -

• “Bulut altyapısından” genel ağa gönderilen posta.
• "Bulut altyapısından" Şirket içi Exchange alıcılarına gönderilen posta.
• Şirket içi Exchange'den genel ağa gönderilen posta.
• Şirket içi Exchange'den Office 365 alıcılarına gönderilen posta.

Mevcut tüm posta akışı senaryolarının ayrıntılarına girmeyeceğiz; bunun yerine yalnızca Şirket içi Exchange sunucusu ile Exchange Online arasındaki (ve bunun tersi) posta akışını vurgulamak istiyorum.

Daha önce de belirtildiği gibi, Hibrit yapılandırmada Şirket içi Exchange Sunucusu ve Exchange Online, tek bir birim veya tek bir varlık olarak hareket eder.

Exchange Şirket İçi Sunucusu ile Exchange Online arasında SMTP\TLS ve HTTPS protokolünü temel alan doğrudan bir iletişim yolu oluşturularak uygulanan yapılandırma.

Exchange on-Premises Server ile Exchange Online arasındaki tüm posta akışı bu güvenli iletişim kanalından geçmektedir.

Örneğin, Bob'un posta kutusunun Şirket içi Exchange sunucusunda bulunması ve Bob'un Alice'e posta kutusunun Exchange Online sunucusunda bulunduğunu belirten posta göndermesi durumunda, posta, Exchange Şirket İçi Sunucusu ile Exchange Online arasında mevcut olan "doğrudan güvenli iletişim bağlantısı" kullanılarak Exchange Şirket İçi sunucusu tarafından Exchange Online'a "aktarılacaktır" (bu "güvenli kanal", HCW - Exchange Hibrit tarafından oluşturulmuştur) Yapılandırma sihirbazı)

Aşağıdaki şemada, Exchange On-Premise ile Exchange Online sunucusu arasındaki güvenli iletişim bağlantısı için gerekli yapılandırmanın bir örneğini görebiliriz.
Senaryomuzda, paylaşılan etki alanı - o365info.com
Her biri Exchange On-Premise alıcısından “bulut alıcısına” (Exchange Online) ve tersi yönde gönderilecek olan o365info.com alan adını içeren postaların tamamı, mevcut doğrudan güvenli iletişim kanalı üzerinden yönlendirilecektir.

Desteklenen başka bir senaryo, Exchange Şirket İçi ortamının bir Uç Aktarım sunucusu içerdiği bir senaryo olabilir. Bu durumda Şirket İçi tarafta Edge Transport sunucusunun “uç nokta” veya ağ geçidi olarak kullanılmasıyla doğrudan güvenli iletişim kanalı oluşturulacaktır.

Desteklenmeyen bir senaryo | Exchange dışı sunucuyu "Şirket İçi Uç Nokta" olarak kullanma

Kaçınmamız gereken, desteklenmeyen bir senaryo: Şirket İçi ortamda uç nokta olarak "Exchange dışı sunucu" kullandığımız bir senaryo.
Örneğin: aşağıdaki diyagramda bir senaryo görebiliriz. bir posta güvenlik ağ geçidi (“Exchange dışı sunucu”) ile Exchange Online arasında oluşturulan doğrudan güvenli iletişim kanalıdır.

Teknik olarak konuşursak, bu senaryoyu uygulayabiliriz, ancak bu yapılandırma desteklenmemektedir ve birçok türde sorunla karşılaşmanız (belirli bir şans olmasa da) makul bir ihtimaldir.

Bu senaryonun desteklenmemesinin nedeni, hibrit ortamdaki "doğrudan güvenli iletişim kanalının" yalnızca iki ayrı posta sunucusu arasındaki basit bir bağlayıcı değil, bunun yerine doğrudan ilgili birçok yapılandırma ayarını ve parametreyi içeren bir iletişim kanalı olmasıdır. “Değişim sunucuları.”

Şirket içi Exchange 2013 İstemci Erişimi sunucuları veya Exchange 2013/2010 SP3 Edge Aktarım sunucusu ile EOP arasında başka SMTP ana bilgisayarları veya hizmetleri olamaz. Karma aktarım özelliklerini etkinleştiren iletilere eklenen bilgiler, Exchange 2013 olmayan bir sunucudan, Exchange 2010 SP3 öncesi sunuculardan veya bir SMTP ana bilgisayarından geçtiklerinde kaldırılır.

Devamını oku: Exchange hibrit dağıtımlarındaki taşıma seçenekleri.