Exchange Hibrit tabanlı ortamda taşınan posta kutularının geçirilen izinleri – Giriş | Bölüm 3#5


Exchange Karma ortamında Exchange izninin taşınan posta kutuları arasındaki ilişkisi konusu oldukça kafa karıştırıcı olabilir.
"Exchange izninin ilişkisi" terimi, aralarında mevcut izin yapısına sahip iki (veya daha fazla) posta kutusunu tanımlamaya çalışın.
Bu posta kutularını “yerel ortamlarından” “diğer ortama” taşıdığımızda cevaplamamız gereken temel soru şu: mevcut izinlere ne olacak?

Bu Exchange izni, posta kutusuyla birlikte diğer ortama mı taşınacak?
Yalnızca bir iş ortağını diğer Exchange ortamına taşıyarak mevcut Exchange izninin ilişkisini "kestiğimiz" bir senaryoda ne oldu?

Mevcut makalede, Exchange Hibrit ortamındaki farklı türdeki “posta kutusu geçişi” senaryosunu yüksek düzeyde inceleyeceğiz.

Sonraki makale, , posta kutularını grup olarak mevcut Exchange ortamından "diğer Exchange ortamına" taşıdığımız senaryoya ayrılmıştır.

Makale - Şirket İçi Exchange Posta Kutularını Ayrı Ayrı Taşıma | Exchange Hibrit tabanlı ortam | Taşınan izinler nelerdir? | Bölüm 5#5, posta kutularını taşıdığımız senaryoya ayrılmıştır, ancak şu anda posta kutularının yalnızca bir kısmını "diğer ortama" taşıyarak mevcut Exchange izin ilişkisini kesiyoruz.

Exchange Hybrid ortamının özel karakteri ve taşınan posta kutularının konusu

Exchange Hibrit, Şirket içi ortamdan (Şirket İçi Active Directory ve Şirket İçi Exchange) ve "bulut" ortamından (Windows Azure Active Directory ve Exchange Online) oluşur.

Exchange Hybrid'in en öne çıkan özelliklerinden biri, Exchange posta kutularının fiziksel konumunun "şeffaflığıdır". Exchange yöneticisi, mevcut posta kutusunu Exchange Şirket içi altyapısında tutmaya karar verebilir veya posta kutusunu "bulut"a (veya tam tersi) taşıyabilir.

Önümüzde duran zorluk, gerçekte iki farklı Exchange ortamı arasındaki "Exchange izinleri" altyapısının o kadar "şeffaf" olmamasıdır.

Exchange izinleri konusunu basitleştirebilmek için "Exchange izin ilişkisi" terimini kullanıyorum.

“Değişim izni ilişkisi” terimi teknik bir terim değildir. Bu terimi, diğer Exchange posta kutuları üzerinde açık izne sahip olan Exchange posta kutusunu tanımlamak için kullanıyorum.

Örneğin iki Exchange posta kutusunun "izin ilişkisi" olduğu göz önüne alındığında - posta kutusu A'nın posta kutusu B üzerinde belirli bir izne sahip olduğu göz önüne alındığında, aşağıdaki senaryolarda bu izinlere ne olacağı sorusu ortaya çıkar:

  • Durum 1 - posta kutusu B'yi buluta taşıdığımız ve posta kutusu A'nın Exchange şirket içi altyapısında "geride kaldığı" bir senaryo.
  • Durum 2 - posta kutularının kabinini (posta kutusu A + posta kutusu B) buluta taşıdığımız bir senaryo.

Bu senaryoda sorularımız:

İki posta kutusu arasında mevcut olan "Exchange izin ilişkisine" ne olacak?

"İzin ilişkisi" aynı mı kalacak yoksa "izin ilişkisi" "bağlantısı kesilecek" mi?

Exchange Karma ortamında posta kutusu geçişiyle ilgili iki ana senaryo.

Exchange Hibrit ortamında, "geçirilen Exchange izinleri" konusuyla ilgili olarak iki ana "posta kutusu geçişi" senaryosunu tanımlayabiliriz.

Senaryo 1 - “izin ilişkisine” sahip posta kutularını grup olarak taşıyın.

Bu senaryoda aralarında “izin ilişkisi” bulunan Exchange on-Premises posta kutuları birlikte buluta (Exchange Online) taşınır.

Örneğin:

  • Posta Kutusu A ve posta kutusu B, Exchange şirket içi sunucusunda barındırılır.
  • Posta Kutusu A'nın posta kutusu B üzerinde özel bir izni vardır.
  • Exchange yöneticisi posta kutularının kabinini buluta taşır.

Senaryo 2 - başka bir posta kutusuyla "izin ilişkisi" olan belirli bir posta kutusunu taşıyın.

Bu senaryoda buluta yalnızca bir posta kutusu taşınır. Örneğin, posta kutusu B üzerinde izne sahip olan posta kutusu A, Şirket içi Exchange'de kalır ve posta kutusu B, buluta taşınır.

Örneğin:

  • Posta Kutusu A ve posta kutusu B, Exchange şirket içi sunucusunda barındırılır.
  • Posta Kutusu A'nın posta kutusu B üzerinde özel bir izni vardır.
  • Exchange yöneticisi, posta kutusu B'yi buluta geçirir ve posta kutusu A, Exchange şirket içi sunucusu tarafından barındırılmaya devam eder.

Mevcut Exchange izninin posta kutuları arasındaki ilişkisini “kırdığımız” bu senaryoyu uygularken “siteler arası izinler” olarak tanımlanan senaryoyu oluşturuyoruz.

Bu durumda iznin altyapısı, Exchange şirket içi sunucusunda barındırılan bir posta kutusu ile bulutta (Exchange Online) barındırılan diğer posta kutuları arasında uygulanır.

Buluta taşınan Exchange iznine ilişkin resmi bilgiler

Exchange Hibrit ortamında posta kutusu geçişi ve taşınan izinler hakkındaki sorularımıza yanıt alabilmek için Microsoft'un bu konuyla ilgili makalelerinden bir alıntıyla başlayalım:

Posta kutusu izinlerinin geçişi Farklı Gönder, Farklı Al ve Posta kutusuna açıkça uygulanan Tam Erişim gibi şirket içi posta kutusu izinleri Exchange Online'a taşınıyor.
Devralınan (açık olmayan) posta kutusu izinleri ve dağıtım listeleri veya postası etkin bir kullanıcı gibi posta kutusu olmayan nesneler taşınmaz.
Bu nedenle, kuruluşunuz için geçerliyse bu izinleri Office 365'te yapılandırmayı planlamanız gerekir. Örneğin, Office 365'teki izinleri ayarlamak için Add-RecipientPermission ve Add-MailboxPermission Windows PowerShell cmdlet'lerini kullanabilirsiniz.
Şirketler arası posta kutusu izinleri desteği Exchange karma dağıtımları, yerleşik posta kutuları arasında Tam Erişim posta kutusu izninin kullanımını destekler. şirket içi Exchange organizasyonunda ve Office 365'te bulunan posta kutularında. Şirket içi Exchange sunucusundaki bir posta kutusu, Office 365 posta kutusuna Tam Erişim izni verebilir veya bunun tersi de geçerlidir. Örneğin, bir Office 365 posta kutusuna şirket içi paylaşılan bir posta kutusuna Tam Erişim izni verilebilir.

Posta kutusuna açıkça uygulanan Farklı Gönder, Farklı Al ve Tam Erişim gibi şirket içi posta kutusu izinleri, Exchange Online'daki kiracının Dirsync veya AAD Sync kullanılarak tam olarak senkronize edilmesi durumunda Exchange Online'a taşınır.
Devralınan (olmayan) Posta kutusu veritabanına uygulanan izinler gibi açık) posta kutusu izinleri ve posta kutusu olmayan nesnelere (dağıtım listeleri veya postası etkinleştirilmiş bir kullanıcı gibi) ilişkin izinler taşınmaz. Bu nedenle, Add-MailboxPermission veya Add-RecipientPermission cmdlet'lerini kullanarak bu izinleri Exchange Online'da yeniden oluşturmalısınız.

Senaryo 1 - Şirket içi Exchange posta kutularını bir "grup" olarak geçirme.

İki (veya daha fazla) Şirket içi Exchange posta kutusunun "izin ilişkileri" olduğu ve Exchange yöneticisinin bu posta kutularını bir grup olarak (birlikte) taşıdığı göz önüne alındığında, açık olmayan (Devralınan) izinlerin yanı sıra mevcut tüm izinler buluta taşınır.

Aşağıdaki tabloda buluta taşınacak Exchange izninin özetini görebiliriz.

"İzin ilişkileri" olan Şirket içi Exchange posta kutularını taşımamız durumunda aşağıdaki izinlerin taşınması gerekir:

  • Tam Erişim izni
  • Farklı Gönderme izni
  • Adına gönderme izni

Aşağıdaki izinler\seçenekler taşınmayacak:

  • Açık Olmayan (Devralınan) izinler taşınmayacaktır.
  • Tam Erişim izni senaryosunda Otomatik Harita özelliği taşınmayacaktır.

Makalenin - Yetki verilen izin ve Klasör izni (takvim paylaşımı).
Bu Exchange izinlerini aşağıdaki makalelerde test edeceğiz - Şirket içi Exchange posta kutularını grup olarak geçirme | Exchange Hibrit tabanlı ortam | Taşınan izinler nelerdir? | Bölüm 4#5

Senaryo 2 - Belirli bir Şirket içi Exchange posta kutularını buluta taşıma

Microsoft makalesindeki bilgiler, Şirket içi Exchange posta kutularının yalnızca bir kısmının buluta taşındığı bu tür bir senaryoyla doğrudan ilişkili değildir.

Genel olarak konuşursak, makale, mevcut Exchange izin ilişkisini "bozacak" bir geçiş sürecinin uygulanmasını önermiyor (öneri, posta kutularının grup olarak taşınmasıdır).

Makalede bulunan tek "ipucu", desteklenen siteler arası izinle ilgilidir;
Tam Erişim izni.

"Olumsuzlaştırma yöntemini" kullanırsak, "izin ilişkileri" olan Şirket içi Exchange posta kutularını "ayırmamız" durumunda çalışacak (geçirilecek) tek izinlerin olduğu mantıksal sonucudur. >Tam Erişim izni.

Makalenin Farklı Gönderme izni ile ilgisi yoktur ve bu nedenle şunu varsayabiliriz:< br>Farklı Gönder izni çalışmaya devam etmeyecektir.

Başka bir deyişle, Şirket İçi Exchange alıcısının, buluta geçirilen posta kutusunda Farklı Gönder iznine sahip olması durumunda, Exchange Karma ortamında siteler arası izinler Farklı Gönder izninin kaldırılması gerekiyor ="color: #800080;">Farklı Gönderme izni.

Aşağıdaki tabloda buluta taşınacak Exchange izninin özetini görebiliriz.

Şu anda Farklı Gönder izninin
veya Adına Gönderme izni kaldırılacak.

"İzin ilişkileri" olan Şirket içi Exchange posta kutularını taşımamız durumunda aşağıdaki izinlerin taşınması gerekir:

  • Tam Erişim izni

Aşağıdaki izinler\seçenekler taşınmayacak:

  • Farklı Gönder izni.
  • Adına gönderme izni.
  • Açık Olmayan (Devralınan) izinler taşınmayacaktır.
  • Tam Erişim izni senaryosunda Otomatik Harita özelliği taşınmayacaktır.

Makalenin - Yetki verilen izin ve Klasör izni (takvim paylaşımı).
Bu Exchange izinlerini aşağıdaki makalede test edeceğiz - Şirket İçi Exchange Posta Kutularını Ayrı Ayrı Taşıma | Exchange Hibrit tabanlı ortam | Taşınan izinler nelerdir? | Bölüm 5#5

Klasör izni ve takvim paylaşımı

Belirtildiği gibi Microsoft makalesi, takvim paylaşımı vb. senaryolarda kullanılan Klasör izni konusuyla ilgili değildir. .

Örneğin aşağıdaki senaryolarda ne olacak?:

Senaryo 1 - "izin ilişkisi" olan posta kutularını grup olarak taşıyın

Bu senaryoda, aralarında “izin ilişkisi” bulunan Exchange şirket içi posta kutuları birlikte buluta (Exchange Online) taşınmıştır.

Örneğin:

  • Alıcı B, takvimini alıcı A ile paylaşır; Alıcıların standı Exchange on-Premise sunucusunda barındırılıyor.
  • Exchange yöneticisi posta kutularının kabinini buluta taşır.

S1: Klasör izni buluta taşınacak mı? Başka bir deyişle, A alıcısı B alıcısının takvimine hâlâ erişebilecek mi?

C1: Microsoft makalelerinde bu tür izinlere ilişkin resmi bir referans yoktur. Gerçekleştirdiğim teste göre, Klasör izni başarıyla buluta taşınacak.
Testi görüntüleyebilirsiniz makaledeki sonuç - Şirket içi Exchange posta kutularını grup olarak geçirme | Exchange Hibrit tabanlı ortam | Taşınan izinler nelerdir? | Bölüm 4#5

Senaryo 2 - başka bir posta kutusuyla "izin ilişkisi" olan belirli bir posta kutusunu taşıyın.

Bu senaryoda buluta yalnızca bir posta kutusu taşınır. Örneğin, posta kutusu B üzerinde izne sahip olan posta kutusu A, Şirket içi Exchange'de kalır ve posta kutusu B, buluta taşınır.

Örneğin:

  • Alıcı B, takvimini alıcı A ile paylaşır; Alıcıların standı Exchange şirket içi sunucusunda barındırılmaktadır.
  • Exchange yöneticisi, posta kutusu B'yi buluta geçirir ve posta kutusu A, Exchange şirket içi sunucusu tarafından barındırılmaya devam eder.

2. Soru: Klasör izni buluta taşınacak mı? Başka bir deyişle, A alıcısı B alıcısının takvimine hâlâ erişebilecek mi?

C1: Microsoft makalelerinde bu tür izinlere ilişkin resmi bir referans yoktur.

Teknik olarak, Klasör izni buluta taşınmamalıdır çünkü Exchange Karma siteler arası izinlerin Tam Erişim iznini atarız.

Açık olmayan izin

Exchange ortamında "açık olmayan izin" (Devralınan) terimi, izni "yönlendirilmemiş bir şekilde" atadığımız bir yöntemi tanımlar.
Bu durumda, ikiden fazla "öğemiz vardır" ” söz konusu.

Örneğin, B Öğesindeki A öğesine Exchange izni atarız, ancak A öğesi, C öğesi gibi diğer öğeleri içeren bir grup gibi bir "kapsayıcı nesnedir".

Örneğin-

  • Yardım Masası adlı bir güvenlik grubuna Bob'un posta kutusuna Tam Erişim izni atarız.
  • Alice, bu Yardım Masası güvenlik grubunun bir üyesidir.

Alice güvenlik grubunun bir üyesi olduğundan ve güvenlik grubu Bob'un posta kutusunda
Tam Erişim iznine sahip olduğundan, sonuç, Alice
Bob'un posta kutusunda Tam Erişim iznine sahip olmasıdır.

Bu durumda Alice'in İzinlerini güvenlik grubundan devraldığını söyleyebiliriz.
Aynı şeyi söylemenin bir başka yolu da Alice'in açık olmayan izinlere sahip olduğudur. Bob'un posta kutusu.

Seçenek 2 - Exchange veritabanındaki bir alıcıya izin atayın.

Exchange ortamında ek bir "açık olmayan izin" (Devralınan) türü, Exchange alıcı posta kutularını barındıran bir Exchange sunucusu veritabanında belirli bir alıcıya Exchange izinleri atamamız durumunda gerçekleştirilebilir.

Örneğin, Alice ve Exchange şirket içi veritabanı adlı bir kullanıcıya Tam Erişim iznini atadığımız bir senaryo.

Belirli Exchange şirket içi veritabanı şu alıcıların posta kutularını barındırır: Bob, Robert ve Emma.

Sonuçta Alice, Bob, Robert ve Emma'nın posta kutularına Tam Erişim iznine sahip olacak.

Başka bir deyişle, Alice'in posta kutularının her biri için açık izni yoktur, bunun yerine bu posta kutularını barındıran veritabanı üzerinde izinleri vardır.

Exchange veritabanına ek posta kutuları eklememiz durumunda, Alice otomatik olarak
Tam Erişim iznine “yeni posta kutuları”nda.

Sonuç olarak

Exchange Hibrit ortamında, belirli bir posta kutusuna “açık olmayan izin” (Inherited) atadığımız ve bu posta kutusunu buluta taşıdığımız bir senaryomuz olması durumunda; izinlerin posta kutusuyla birlikte taşınması beklenmez.

Daha sonra böyle bir senaryoyu şu makalede göstereceğiz: Şirket içi Exchange posta kutularını grup olarak geçirme | Exchange Hibrit tabanlı ortam | Taşınan izinler nelerdir? | Bölüm 4#5 ve sonucun "resmi beklenen sonuçtan" biraz ama farklı olduğunu görün

Güncel makale serisinin bir sonraki makalesi

Şirket içi Exchange posta kutularını grup olarak geçirme | Exchange Hibrit tabanlı ortam | Taşınan izinler nelerdir? | Bölüm 4#5

İlgili makaleler