Exchange Server 2013 ile beraber uzun zamandır kullandığımız ve yakından tanıdığımız Offline Address Book mimarisinde bir takım değişiklikler yapılmıştır.
Bende bu makalemde bu değişikliklerden bahsedeceğim.
Öncelikle Exchange Server 2013 EAC üzerinde OAB yönetimi olmadığını ve bu nedenle 2013 platformunda OAB yönetimi için tamamen powershell kullanmamız gerektiğini sizler ile paylaşmak istiyorum.
Exchange Server 2013 den önce ilk kurduğunuz mailbox server, OAB için generation server olarak atanmaktadır. Bildiğiniz gibi OAB aslında sizin belirlediğiniz adres defterlerinin güncel içeriğini alarak kendini oluşturur ve daha sonra Outlook programı gelip bu içeriği kendi üzerine indirir ( cache mode kullanıcıları için ). Bu işlem varsayılan durumda her sabah saat 5 de olur. Bu nedenle gün içerisinde açılan yeni bir kullanıcı cache mode ile çalışan Outlook adres defterine gelmez. Bunun için bu güncelleme işlemini günde bir kaç kez olacak şekilde ayarlayabilirsiniz ancak ciddi bir kullanıcı trafiği yok ise AD tarafında bu değişiklik gereksiz iş yükü olarak Exchange sistemine geri dönecektir. Veya bu şekilde çok kritik bir kaç kişi var ise yeni açılan kişileri, grupları görmek isteyen, bu kişilerin Outlook programını “online mode” şeklinde çalıştırabilirsiniz.
Oluşturduğunuz OAB için generation server bilgisini aşağıdaki komut seti ile görebilirsiniz;
Get-OfflineAddressBook “Default Offline Address Book” | fl name,server
Bu yapının dezavantajı ise bu işlem için tek bir sunucunun seçili olmasıdır. Yani “Single point of failure”, tek nokta hatası meydana gelir. Yani siz CAS Array kurduğunuz, DAG kurdunuz ve bu sayede Exchange tarafında “yüksek erişilebilirlik” çözümü sağlamış olduğunuz. Ancak OAB tarafında bir sunucunun down olması bu hizmetin kesilmesi olarak geri dönmektedir.
Exchange Server 2013 de ise bu generation işlemi artık “arbitration mailbox” tutan herhangi bir mailbox server tarafından yapılmaktadır. Bildiğiniz gibi Exchange Server tarafında organizasyon mailbox olarak bildiğimiz “arbitration mailbox” artık bu işlemden sorumludur.
Bu nedenle yeni Exchange 2013 OAB için aynı komutu çalıştırmanız halinde sonuç aşağıdaki gibi olacaktır.
Get-OfflineAddressBook “Default Offline Address Book (Ex2012)” | fl name,server
Gördüğünüz gibi Exchange 2013 üzerindeki OAB için tanımlı bir sunucu yoktur.
Bunun sebebi artık sunucu bağımlı değildir, artık arbitration mailbox hangi sunucuda ise sorumlu olan sunucu odur. Bu durumda bu mailbox’ ı DAG içerisine alarak herhangi bir şekilde Mailbox sunucularından birinin kapanması durumunda OAB generation işlemi kesintisiz devam edecektir.
Aşağıdaki komut seti yardımı ile arbitration mailbox’ ın OAB generation işleminden sorumlu olduğunu görebiliriz.
get-mailbox -arbitration | select identity,persistedcapabilities | fl
Peki, şu anda hangi mailbox server üzerinde tutuluyor bu arbitration posta kutusu derseniz aşağıdaki powershell i kullanabilirsiniz.
Get-Mailbox -Arbitration | where {$_.PersistedCapabilities -like “*oab*”} | ft name,servername
Yukarıdaki çıktıdan arbitration posta kutusunu ve tutulduğu mailbox server’ ı görebilirsiniz.
Eğer ortamda DAG var ise bu durumda arbitration mailbox’ in bulunduğu mailbox veri tabanının en az iki kopyası var demektir, ve bu kopyalarsan aktif olan hangisi ise OAB generation server o demektir.
İlk olarak arbitration posta kutsununun bulunduğu veri tabanı ismini alalım;
Get-Mailbox -Arbitration | where {$_.PersistedCapabilities -like “*oab*”} | ft name,database
Sonrada bu mailbox veri tabanının hangi sunucuda aktif olduğunu bulabiliriz.
E2013 isimli mailbox sunucusu üzerinde olduğunu tespit ediyoruz.
Exchange Server 2010 zamanında OAB belirli aralıklar ile güncellenmekteydi. Yani bu güncelleme işlemini zamanlıyorduk. Bu süreçten sorumlu olan servis ise “Microsoft Exchange System Attendant” dir. Biz OAB özellikler sekmesinden sunuculara en az yük bindireceği saati veya saatleri seçebiliyorduk. Genellikle günde bir kere çalışan OAB generation işlemi istenirse daha fazla kez çalıştırılabilir.
Exchange Server 2013 mimarisinde ise bu generation işleminden “Microsoft Exchange Mailbox Assistants service” altında çalışan OABGeneratorAssistant bu süreçten sorumludur. Sunucu yoğunluğuna göre kendisi çalışmakta ve durmaktadır.
Bu süreç “workload Policy” tarafından yönetilmektedir.
Get-WorkloadPolicy *OAB*
Exchange workload, temel olarak Exchange sunucu kaynaklarının daha iyi kullanılması için varsayılan olarak tanımlanmış bir takım policyleri temsil etmektedir.
Biz OAB ile ilgili olan policyleri merak ettiğimiz için ona göre komut setini çalıştırıyorum.
Get-WorkloadPolicy OABGeneratorAssistant | fl
Mevcut durumu kontrol etmek için Exchange 2010 da ara yüzü kullanabiliyorduk.
Get-Mailboxserver –Identity E2013 |fl *oab*
Yani günde bir kere OAB üretilecek şekilde varsayılan olarak ayarlanmıştır.
Eğer bunu mesela 4 saatte bir yapmak istiyorsanız aşağıdaki komut setini kullanabilirsiniz.
Set-MailboxServer E2013 -OABGeneratorWorkCycle 01.00:00:00 -OABGeneratorWorkCycleCheckpoint 04:00:00
OAB Generation sürecini Event ID 17002 ile takip edebilirsiniz.
Peki, OAB nerede saklanıyor.
Exchange 2010 sürümünde Mailbox sunucusu üzerinde aşağıdaki dizinde yer almaktaydı.
%ExchangeInstallPath%\ExchangeOAB
Bu klasör paylaşımda olup CAS Sunucusu bu dosyaları kendi üzerine alarak IIS altındaki Virtual Directory yardımı ile istemcilere dağıtmaktadır.
Bu oluşturulan OAB, CAS sunucuların üzerindeki “virtual directory” üzerinden “File Distribution Service” yardımı ile dağıtılmaktadır.
Zaten yeni mimaride bu servis CAS üzerinden kaldırılmıştır.
Exchange 2013 üzerinde bu servisi göremiyoruz.
Peki, Exchange 2013 üzerinde OAB nerede saklanıyor?
‘2013 mimarisinde OAB ilk olarak Organization Mailbox içerisinde üretilir ve saklanır. Bu OAB nin bir kopyası dosya bazında “%ExchangeInstallPath%\ClientAccess\OAB\”dizininde saklanır.
Ek bir değişiklik, Exchange Server 2007 ve 2010 iki temel dağıtım yöntemi desteklemekteydi, Web tabanlı ve public folder üzerinden. Exchange 2013 ise sadece web tabanlı bir dağıtım desteklemektedir.
Exchange 2010 zamanında sistem aşağıdaki şekilde çalışmaktaydı.
CAS sunucusu üzerindeki “Microsoft Exchange File Distribution” servisi dosya bazında mailbox sunucusu üzerindeki paylaşımdan güncel OAB dosyalarını alır ve kendi yerel dizinine kayıt eder.
Outlook ise Autodiscover özelliği sayesinde OAB için URL adresini alır ve bu CAS URL adresi üzerinden IIS yardımı ile bu OAB dosyalarına erişir.
Bu yöntemin dezavantajları nelerdir?
CAS sunucusu eğer yerel olarak OAB nin bir kopyasını alamamış ise outlook oab download işleminde hata verecektir.
CAS sunucusu üzerindeki File Distribution servisi bir şekilde çalışmıyor ise bu durumda outlook’ lar eski yani güncel olmayan OAB dosyalarına erişmiş olacaklardır.
Exchange 2013 de artık CAS sunucuları üzerinde herhangi bir OAB dosyası tutulmamaktadır. Bunun nedeni ise CAS artık gelen tüm OAB istekleri için Proxy görevi görerek bu istekleri Mailbox sunucusuna yönlendirmektedir. Bu sayede artık CAS üzerindeki File Distribution servisi kaldırıldı.
2013 altında ise sistem aşağıdaki gibi çalışmaktadır.
Eski sistemde olduğu gibi yine Autodiscover yardımı ile OAB URL bilgisini alan Outlook CAS sunucusuna başvurur.
CAS sunucusu ise sırası ile aşağıdaki gibi bir süreci başlatır.
1 – OAB için temel kimlik doğrulama yapılır.
2 – OAB isteyen kullanıcıya en yakın organizasyon mailbox’ ı tespit edilir. ( AD Query )
3 – Ardından bu organizasyon mailbox’ ını tutan mailbox veri tabanı tespit edilir. ( AD Query )
4 – Daha sonra ise bu veri tabanının hangi mailbox sunucusunda aktif olduğun tespit edilir. ( Query Active Manager )
5 –Ardından istek bu mailbox sunucusuna yönlendirilir.
6 – OAB dosyalarına ulaş ve bunu istemciye iletir.
Peki, yukarıdaki gibi bir yapıyı gerçek hayat senaryosuna göre canlandıracak olursak.
Öncelikle yüksek erişilebilirlik için DAG mimarinizin olduğunu düşünüyorum.
Örneğin CAS1, MBX1 ve MBX2 olan bir ortamda organizasyon posta kutusu MBX1’ in üzerinde olan bir mailbox database içerisinde tutuluyor olsun.
Bu durumda OAB üretiminden sorumlu olan sunucu MBX1 dir. Ancak biz kesintisiz bir üretim için organizasyon posta kutusunun tutan mailbox database için DAG mimarisini kullanıyoruz. Yani Bu mailbox database’ in pasif kopyası MBX2 sunucusunda tutulmaktadır.
Normal şartlarda outlook autodiscover üzerinden aldığı URL ile CAS1’ e ulaşır ve CAS1 de organizasyon mailbox’ ını tutan MBX1 için yönlendirmeyi yapar. Ancak olurda MBX1 down olursa bu durumda DAG mimarisi gereği organizasyon posta kutusunun bulunduğu mailbox database otomatik olarak MBX2 üzerinde ayağa kalkar. Bundan sonra CAS1 e yeni bir OAB isteği geldiğinde her zaman olduğu gibi CAS1, Active Manager’ a organizasyon posta kutusunu tutan mailbox database’ inin hangi mailbox sunucusunda aktif olduğunu sorar, bu sefer aldığı cevap MBX2 olduğundan istemcileri buraya yönlendirecektir.
Eğer elle generation server değiştirmek istiyor isek aslında arbitration mailbox’ ı bir sunucu üzerindeki mailbox database’ den diğer mailbox sunucusu üzerindeki başka bir mailbox database’ e taşımak yeterli olacaktır.
Get-Mailbox -Arbitration -database db1| where {$_.PersistedCapabilities –like “*oab*”} | New-MoveRequest -TargetDatabase db2
Yukarıdaki komut, arbitration posta kutusunu DB1 den DB2 ye taşımaktadır. Tabiki bu senaryoda DB1 MBX1 gibi bir mailbox server da iken DB2, MBX2 gibi ayrı bir mailbox server2 ı temsil etmektedir.
Eğer bu posta kutusunu barındıran mailbox database bir DAG yapısı içerisinde ise bu durumda move komutu yerine bu veri tabanının aktif kopyasını diğer mailbox sunucuda aktifleştirmek yeterli olacaktır.
Move-ActiveMailboxDatabase DB1 -ActivateOnServer MBX2
Aynı senaryo ile, DB1 mailbox database’ ini MBX1 isimli sunucu yerine MBX2 isimli sunucuda aktifleştiriyoruz. Bu durumda arbitration posta kutusu sunucu değiştirmiş olacağı için artık generation server MBX2 dir.
Eğer büyük bir mimariye sahipseniz isterseniz ayrı site’ lar için ayrı organizasyon mailboxları oluşturabilirsiniz. Bu sayede OAB generation işlemi için de site bazında hata toleransı sağlamış olursunuz.
New-Mailbox -Arbitration -Name “OAB Ankara” -Database DB2ANK -UserPrincipalName [email protected] –DisplayName “OAB Mailbox for Ankara”
Bu sayede yeni bir posta kutusu açmış oluyoruz.
Şimdi ise OAB generation işlemini açalım
Set-Mailbox -Arbitration oabank -OABGen $true
“oabank” ile kendi açmış olduğum yeni organizasyon posta kutusunu tanımlamış oldum.
Peki, gelelim OAB konsun da sorun çözümleme adımlarına.
Öncelikle bu konuda her zaman olduğu gibi ilk başvuracağımız nokta log dosyalarıdır. CAS sunucuları bildiğiniz gibi Outlook isteklerini doğru MBX sunucusuna yönlendirmekten sorumludur. Bu yönlendirme işlemlerini de loglamaktadır.
%ExchangeInstallPath%\Logging\HttpProxy\OAB\
Bu log dosyaları bize sorun çözmede yardımcı olacaktır. Önemli olduğuna inandığım başlıklar aşağıdaki gibidir.
UrlStem: OAB URL adresini ve indirme işleminin full veya incremental olduğunu gösterir.
AuthenticatedUser: OAB isteğinde bulunan kullanıcı adı.
AnchorMailbox: OAB isteği için en yakın olan Organization Mailbox’ ın DN bilgisini gösterir.
ServerHostName: OAB isteğini yönlendiren CAS Server ismi
HttpStatus: Sonuç olarak ortada bir HTTP isteği bulunmaktadır. Bundan dolayıda aynı internet tarayıcılarında olduğu gibi HTTPStatus code görüntülenmektedir. Örneğin siz bir web saysafını açmak için talep yaptığınızda sayfa sorunsuz açılıyor ise 200 kodu atılır. Ama bir sorun var ise 500 ve benzeri pek çok farklı kod görebilirsiniz.
ProxyAction: CAS yönlendirme yaptığı için burada genellikle “Proxy” görürürüz.
TargetServer: OAB isteğinin yönlendirildiği mailbox sunucu ismi.
Bir diğer konu ise elle OAB güncelleme işlemini tetiklemek. Malum Exchange 2010 üzerinde konsol ile bunu yapabiliyorken Exchange Server 2013 EAC üzerinde OAB yönetimi ile ilgili herhangi bir bölüm bulunmamaktadır.
Bunun için aşağıdaki gibi bir powershell kullanabiliriz.
Update-OfflineAddressBook “default offline address book”
Tabiki sizin OAB isminizi biliyor olmanız gerekli.
Get-OfflineAddressBook
Görüldüğü gibi iki tane var. Exchange 2013 üzerinde olan sonu “Ex2012” olandır. Bu nedenle benim komutum aşağıdaki gibi olacaktır.
Update-OfflineAddressBook “default offline address book (Ex2012)”
Loglardan durumu takip edebiliriz
Generation işlemi başlatıldı.
Ve tamamlandı.
Veya ikinci bir yöntem olarak, organizasyon posta kutusunu tutan mailbox sunucu üzerindeki “Mailbox Assistant” servisini restart edebiliriz.
CAS sunucusunun OAB çalışmasındaki sorumluluklarından en önemli bölümü, gelen isteğe karşılık ilk olarak en yakın organizasyon posta kutusunu bulmaktır.
Eğer bir Active Directory site içerisinde birden çok organizasyon posta kutusu var ise ve bu posta kutuları OAB generation için tanımlı ise bu durumda round robin mantığı ile rast gele bir tanesine yönlendirme yapacaktır. Ama bu durumun bir sonucu olarak A kullanıcısının kullandığı outlook farklı Mailbox sunucularına bağlanacağı için OAB leri sürekli olarak “Full” download etmek zorunda kalacaktır.
Bundan dolayı eğer dağınık bir site yapınız olması durumunda yeni organizasyon posta kutuları oluşturarak OAB kullanımını iyileştirebiliriz.
Örnek bir senaryo üzerinden konuyu detaylandırmak gerekir ise.
CozumPark domaininde Exchange Server 2013 CAS ve MBX sunucuları, İstanbul ve Rize olmak üzere iki tane AD site yapısı içerisinde kurulmuş durumdadır.
Bu yapıda varsayılan olarak tek bir organizasyon posta kutusu olmaktadır. İlk kurulan mailbox sunucu hangisi ise onun üzerinde olacaktır ( değiştirilmediyse ). Bizim örneğimizde bu organizasyon posta kutusu “İstanbul” site içerisindeki Mailbox sunucusu üzerinde saklanmaktadır.
Bu durumda eğer CAS OAB loglarına bakarsanız, Rize site içerisindeki tüm outlook kullanıcılarının sürekli olarak İstanbul site içerisindeki Mailbox sunucusuna yönlendirildiğini göreceksiniz.
Bu da mimari olarak doğru bir yapılandırma olmaz.
Bu nedenle Rize site için ek bir organizasyon posta kutusu oluşturuyorum. Bu konuda zaten komut setlerini paylaşmıştım.
New-Mailbox -Arbitration -Name “OAB Rize” -Database DB2RIZE -UserPrincipalName [email protected] –DisplayName “OAB Mailbox for Rize”
Bu sayede yeni bir posta kutusu açmış oluyoruz.
Şimdi ise OAB generation işlemini açalım
Set-Mailbox -Arbitration oabrize -OABGen $true
“oabrize” ile kendi açmış olduğum yeni organizasyon posta kutusunu tanımlamış oldum.
Bunun gibi sizde her bir AD site için organizasyon posta kutusu oluşturabilirsiniz.
Buraya kadar daha çok teknik ve karmaşık olan konulara değinmeye çalıştım. Ancak malum çok temel OAB ihtiyaçları içinde artık powershell kullanmamız gerekmektedir.
Bu nedenle makalemin bu bölümünde ise temel OAB ihtiyaçları için kullanabileceğiniz komut setlerini paylaşacağım.
İlk olarak makalemin başlarında yeni bir OAB oluşturmayı hali hazırda anlattığım için şimdi var olan bir OAB ye adres listelerini ekleme komutunu paylaşıyorum.
İlk olarak RIZE site için yeni bir adres listesi oluşturuyorum.
Şimdi ise OAB ye bunu ekliyorum.
Set-OfflineAddressBook -Identity “Default Offline Address Book (Ex2012)” -AddressLists RIZE
Son durumu kontrol edelim.
Get-OfflineAddressBook –Identity “Default Offline Address Book (Ex2012)” |fl *Address*
Gördüğünüz gibi RIZE eklenmiş durumda.
Bu şekilde birden çok ekleme yapabilirsiniz.
Set-OfflineAddressBook -Identity “Default Offline Address Book (Ex2012)” -AddressLists RIZE,ANK,IST
Kaldırmak için ise sadece kaldırmak istediğinizi yazmamanız yeterlidir.
Bir diğer konu ise varsayılan OAB yi değiştirmek.
Set-OfflineAddressBook -Identity "Default Offline Address Book (Ex2012)" -IsDefault $true<?xml:namespace prefix = "o" />
Peki bir site içerisinde birden çok OAB olması durumunda ne tür bir yönetim yapmamız gerekmektedir.
Bu tür bir mimariniz var ise aşağıdaki seçeneklerden birini yapabilirsiniz.
Mailbox başına OAB tanımlayabilirsiniz – EAC
Kullanıcı başına OAB tanımlayabilirsiniz – PowerShell
Çoklu kullanıcıları yine komut yardımı ile seçip OAB belirleyebilirsiniz
Address Book Policy ile OAB belirleyebilirsiniz.
OAB silmek için ise aşağıdaki powershell komut setini kullanabilirsiniz.
Remove-OfflineAddressBook -Identity "My OAB"<?xml:namespace prefix = "o" />
<?xml:namespace prefix = "o" />
Update işlemi için<?xml:namespace prefix = "o" />
<?xml:namespace prefix = "o" />
Update-OfflineAddressBook -Identity "My OAB"<?xml:namespace prefix = "o" />
<?xml:namespace prefix = "o" />
Bildiğiniz ve makaleminde başında anlattığım gibi OAB yönlendirmesinde IIS’ in büyük bir önemi vardır. CAS üzerindeki IIS altında OAB virtual directory bulunmaktadır. Bir şekilde bunun ayarlarının bozulması veya çalışamaz duruma gelmesi durumunda aşağıdaki powershell ile bu directory’ yi yeniden uluşturabiliriz.<?xml:namespace prefix = "o" />
<?xml:namespace prefix = "o" />
New-OABVirtualDirectory -Server CAS1 -RequireSSL $true -ExternalURL "https://www.cozumpark.com/OAB"<?xml:namespace prefix = "o" />
<?xml:namespace prefix = "o" />
Umarım faydalı bir makale olmuştur. Bir sonraki makalemde görüşmek üzere.
