Forefront güvenlik ürün ailesinin önemli bir üyesi olan Protection 2010 for Exchange Server, şirket organizasyonlarında Exchange Server kullanan sistem yöneticileri için vazgeçilmez bir üründür. Neden bu ürünü seçmemiz gerektiği ve temel bilgileri içeren makalemizi daha öncesinde yayınlamıştık, bu nedenle bu konulara değinemeyeceğim. Merak edenler için bu konuların anlatıldığı linki sizlerle paylaşıyorum

http://www.cozumpark.com/blogs/forefront/archive/2010/10/03/microsoft-forefront-protection-2010-for-exchange-server-fpe-ve-forefront-protection-2010-for-sharepoint-fpsp-ile-g-venli-mesajla-ma-g-venli-birli-inde-en-yi-z-m.aspx

Benim bu makaleyi yazmamdaki amaç ise detaylı bir kurulum ve bu temel makale sonrasında ürün hakkında seri bir şekilde diğer özelliklerini anlatan makaleler yazmak. Bu nedenle kurulum ile başlayalım.

Ürün için kurulum noktasında farklı senaryolar bulunmaktadır, hem bu senaryoları hemde ürün için sistem gereksinimlerini ilk olarak paylaşmak istiyorum.

Desteklenen işletim sistemleri

Windows Server 2003 SP2, Windows Server 2003 R2, Windows Server 2008 veya SP2 ve Windows Server 2008 R2 veya SP1

Desteklenen Exchange versiyonları

Exchange Server 2007 RTM, Exchange Server 2007 SP1, SP2, SP3 rollup1, Exchange 2010 RTM,  Exchange 2010, Exchange 2010 RTM SP1, Exchange Server 2010 SP1 Rollup1

Yükleme senaryolarında ise şirket organizasyonlarında iki temel senaryo görebilirsiniz.  Enterprise Reference Architecture ve Standart Reference Architecture. İlk senaryo gelişmiş şirket senaryolarında gözlemlenebilir. Ölçeklenebilir bir yapısı olmak ile beraber yüksek istemci sayılı yapılarda kullanılır.

Bu modelde gördüğünüz gibi bir edge server rolü kullanılmakta olup ayrıca yapıdaki tüm roller birbirinden ayrılmış ve mailbox server rolü de çoklu sunucular ile desteklenmektedir.

Standart model ise aşağıdaki gibidir

Bu modelde ise tüm roller tek bir sunucu üzerinde konumlandırılmıştır. Ancak Türkiye şartlarında edge kullanılmadığı yapıyı da görmeniz mümkündür. Forefront tüm bu senaryoları desteklemektedir. Temel olarak Edge, Hub ve mailbox sunucularına yüklenir ve buradan geçen tüm mail trafiğini izlemektedir. ( mailbox server üzerinden mail trafiği geçmemektedir ancak buradaki mailboxları taramakta ve policyleri uygulamaktadır, bu nedenle mailbox server üzerinde yüklenen bir FPE ürününde anti spam özelliğini göremezsiniz. Bunun tek istisnası Hub ile Mailbox rollerini aynı sunucuya kurmanızdır. )

Eğer FPE ürününü Edge veya Transport sunucularına yüklerseniz Realtime, Schduled ve on-demand tarama seçeneklerini göremezsiniz. Aynı şekilde mailbox server rolü üzerine yüklemeniz halinde de transport scan özeliğini göremezsiniz. Ancak hem mailbox hem de hub yüklü bir sunucuya yüklemeniz halinde hepsini görme şansına sahipsiniz.

Exchange Server organizasyonunuzu virüs, spyware ve spam lara karşı korumak istiyorsunuz, ancak bunun yanında temel şartınız yüksek performans, yani her mail alt yapısında olduğu gibi amacımız yüksek koruma ve yüksek performans. Oysaki bilinen yöntemlerde yüksek performans düşük korumayı, yüksek koruma ise düşük performansı tetikleyen bir durumdur. FPE ürünü ise bunu Exchange Server’ ın bize sunduğu rol tabanlı mimari ile aşmaktadır. Yani sahip olduğu birden çok taramam motoru ile tarama yaparak yüksek bir güvenlik sağlayabiliriz, ancak bu bize sunucu tarafında performans sorunları olarak geri dönecektir. Bu diğer tüm ürünlerde böyledir, ancak FPE sahip olduğunuz Edge, Hub ve Mailbox rollerine ayrı ayrı yüklenerek bu sorunu aşmaktadır. Bunun nasıl yapıyor derseniz hemen açıklayalım.

Yukarıdaki resimde görüldüğü üzere internet üzerinden gelen spyware, spam ve virüslü mailler ilk olarak Edge üzerindeki FPE ile taranmaktadır. Burada sahip olduğunuz tarama motorlarından iki tanesini seçerek dengeli bir tarama yaptınız ( performans – güvenlik dengesi ). Buradan geçen mail Hub transport üstüne düştü ve burada da ayrı iki motor ile daha taradınız ve aynı şekilde mailbox sunucusu üzerinde ayrı bir motor ile daha bu işlemi yaptınız. Baktığınız zaman her sunucuda ikiden fazla tarama motoru kullanmadığınız için performans sorunları yaşamadınız ancak toplam da farklı motorlar kullandığınız için de yüksek bir güvenlik senaryosuna sahip oldunuz. Benim tek sunucum var derseniz tabi ki bu durumda tek seçeneğiniz bize sunulan Intelligent Engine Management IEM özelliğini kullanmak olacaktır ki bu özelliğin detaylarını makalemizin devam serilerinde bulabilirsiniz. Buradaki kritik nokta aslında mailleri işaretlemekten geçmektedir ( stamp ). Örneğin Edge üzerinde malware içerikli veya spam olduğu işaretlenen bir mail header bilgisine yazıldığı için diğer bir server tarafından bir kez daha taranmaz. Bu sayede tek bir tarama aslında yeterli.

Sistem nasıl çalışıyor? Eğer gelen mail bir kez Edge veya Hub üzerinde taranmış ise antimalware header stamp yazılır ve bu mail bir sonraki uğrak yeri olan Hub, başka bir Hub veya mailbox server’ a geldiğinde ilk olarak header bilgisi kontrol edilir ve eğer bu bilgi bir şekilde düzenlenmiş ise bu mail bir kez daha taranmaz.

Bu durumun tek istisnası sunucu üzerinde “Optimize for performance by not scanning message already virus scanned” seçeneği pasif hale getirilir ise bu durumda aktif olan her engine ile taranma işlemine devam edilir.

Örneğin inbound yani şirket dışından şirket içine gönderilen mailler için varsayılan tarama senaryosu aşağıdaki gibidir;

Tarama Edge üzerinde yapılıp işaretleme yapıldığı için diğer sunucularda tarama yapılmaz.

Outbound mail yani şirket içerisinden şirket dışına gönderilen mailler ise sadece Hub ların üzerinde taranmaktadır

Son olarak ise internal dediğimiz yani şirket içerisindeki maillerin ( şirket içinden yine şirket içine gönderilen mailler ) taranması sadece Hub ların üzerinde gerçekleşmektedir.

FPE ürününü kurmak istiyorsanız eğer bilmeniz gereken bir noktada hangi sunucuların üzerine kurmamız gerektiğidir. Aslında bu konuda sizlere bilgi verdim ancak genel kabul göre senaryolardan da bahsetmek istiyorum.

Mail sisteminizin güvenliği için uygulayabileceğiniz iki temel güvenlik seviyesi vardır;

Baseline protection level

Global protection level

Baseline koruma seviyesinde FPE ürünü sadece Hub ve Edge sunucuları üzerine kurulur ve bu durumda yönlendirilen ( routed ) tüm mail objeleri taranmaktadır. Ancak dez avantajı yönlendirilmeyen öğelerin taranmayacak olmasıdır.

Global koruma seviyesinde ise hub ila edge sunucu rollerinin yanında mailbox sunucu rolüne de FPE kurulması gerekmektedir ve bu sayede hub üzerinden yönlendirilmeyen mail objeleri de yerinde taranabilir (public folders, Sent Items folder, Calendar folder ).

Mailbox sunucu rolü üzerinde temelde 3 tip tarama sunulmaktadır. Bunlar aşağıdaki şekilde özetlenebilir ;

Realtime scanning—Scans: Gerçek zamanlı taramada mail objelerine her erişimde tarama gerçekleşmektedir. Mail objesini okuma, görüntüleme veya indeksleme işlemlerinde bu tarama gerçekleşir.

Scheduled scanning—Scans: Zamanladığınız sürede otomatik olarak mailbox ların taranmasını sağlayan seçenektir.

On-demand scanning—Scans:  Malware outbreak dediğimiz yani malware yayılması durumunda yapılacak tarama yöntemidir. Bir nevi içeride kötü içerikli bir kod tespit edildiğinde nasıl bir tarama yapılacağını belirleyebiliriz.

Peki, biraz daha kurulum adımları ile devam edelim. FPE için temel yayınlama senaryolarını görmüştük ancak sonuç olarak şirket ihtiyaçları değişkenlik gösterdiği için donanım noktasındaki gereksinimlere iyi karar vermek gerekiyor. Bu nedenle size “Forefront Protection 2010 for Exchange Server Capacity Planning Tool

” aracını kullanmanızı tavsiye ederim.

Aşağıdaki tablo aracılığı ile de tavsiye edilen ram miktarlarını daha net görebilirsiniz

Örneğin 8 core ve 5 engine çalışan bir sunucu üzerinde tarama işlemini de 8 olarak ayarlarsanız 11.4 GB ram’ e ihtiyaç duymaktasınız.

Tarama süreci için birden çok tarama motoru kullanabilirsiniz. Her bir tarama süreci 350mb ram kullanmaktadır ( varsayılan olarak 5 tarama motoru kullandığınızı düşünürsek) . Eğer siz tarama süreci içerisindeki tarama motorlarının azaltırsanız bu ram miktarı tarama motoru başına 63mb düşmektedir. Örneğin bir tarama süreci için 3 adet tarama motoru kullanırsanız ortalama 224mb’ lık bir ram kullanımı söz konusu olacaktır. Bunun yanında tabi ki varsayılan olarak 4 tarama süreci geleceği için bu rakamları 4 ile çarpmanız gerekmektedir. Bu konudaki ayarları makalenin ilerleyen bölümlerinde bulabilirsiniz. Bunların yanında tabi ki destek servisleri için 650MB ram ve Exchange server için ayrıca ram gereksinimlerini unutmamak gerekmektedir. Yine bu hesaplamalar sadece tek bir rolün yüklü olduğu sunucular için verilmektedir ( sadece hub, sadece mailbox veya sadece edge gibi ).

Tavsiye edilen donanımlar ise aşağıdaki gibidir

4 veya 8 core cpu

4 GB ram ve mailbox başına 5mb ek ram gerekmektedir.

Ayrıca ürün Windows server 2003 üzerinde exchange 2007 ve Windows server 2008 R2 üzerinde Exchange 2010 desteklediği için bu konudaki performansını da sizlerle paylaşmak isterim.

Görüldüğü gibi en çok mesaj işleme ve en az cpu kullanımını fiziksel 2008R2 / Exchange 2010 ortamında gerçekleştirmektedir.

Performans konusundan devam edecek olursak yükleme öncesi yukarıdaki bilgilerin yanında birde kaynak kullanımında kullanacağınız filtrelerin çok büyük önem arz ettiğini belirtmek isterim. Örneğin Edge sunucu üzerine gelen bir mesaj ilk olarak Ip reputation servis üzerinde karşılanır, eğer mesaj burayı geçer ise  content filter, devamında diğer tanımlanmış olan filtreler ve malware taramasından geçirilir. Buradaki performansı etkileyen en önemli hususlardan biri kullandığınız filtrelerdir. Ne kadar çok filtre tanımlarsanız o kadar çok kaynak tüketimi yaparsınız.

Aşağıdaki şekilde filtre kullanımı ile doğru orantılı olarak artan cpu kullanımını görebiliriz

Resimdeki şekil için açıklama tablosu aşağıdaki gibidir

Evet şimdi yükleme için ön hazırlığa başlayabiliriz. Temiz bir yükleme olması için sistem gereksinimlerini kontrol etmenizi öneririm;

http://technet.microsoft.com/en-us/library/cc482970.aspx

Eğer gereksinimler tam ise yüklemeye başlayabiliriz.

Yükleme adımları çok basit olduğu için detaylandırma gereği duymuyorum, yani bu makalede asıl can alıcı nokta aslında buraya kadar anlattığım bölümlerdeydi çünkü dediğim gibi yükleme standart olarak next next şeklinde devam edecektir.

Sözleşmeyi kabul ediyoruz

Kurulum sırasında Transport Servisi durdurulacak ve tekrar başlatılacak, eğer yoğun bir Hub sunucusu ise bu kesintisi olmaması için mesai saatleri dışında bu kurulum işlemini yapabilirsiniz.

Kurulum dizinleri

İnternet erişimi için proxy var ise bilgileri girebilirsiniz , ancak bu işin en iyi yöntemlerinden biri sunucuların proxy den bağımsız internete çıkmaları olduğu için ( firewall dan direk izinli olmaları beklenir ).

Yükleme sonrası Anti Spam özelliği hemen aktif olmasını istiyorsanız buradaki seçeneği “Enable” olarak değiştirebilirsiniz, peki neden böyle bir seçenek var derseniz temel configleri yapmadan bu özelliği açmak istemeyebilirsiniz.

Otomatik güncellemeler.

Ve kurulumdan önceki son adım.

Kurulumun hemen ardından aşağıdaki gibi kullananlar için Forefront Online Protection for Exchange Gateway  kurulumu da yapma imkanına sahipsiniz.

Bu hizmet hakkında makalemizin ilerleyen bölümlerinde bilgi bulabilirsiniz.

Kurulumun ardından yukarıdaki gibi konsol ekranı bizi karşılıyor ve hemen aktivasyon ekranını görüyoruz.

Sahip olduğunuz seri numarasını girerek aktivasyonu tamamlayabilirsiniz

Bu son işlemden sonra artık FPE ürünü kullanmaya hazır hale geliyor. Bundan sonrası için detaylı kullanım makalelerini takip edebilirsiniz. Bu FPE üzerine hazırladığım seri makalelerin ilki olup devamından detaylı konfigürasyon bilgilerini alabilirsiniz.

Bir sonraki makalemizde görüşmek üzere.

Microsoft tarafından ücretsiz olarak bizlere sunulan bu araç sayesinde, biz sistem yöneticileri network üzerinden PST dosyalarını bulup istediğimiz kullanıcıların asıl posta kutularına veya arşiv posta kutularına bu PST içeriğini merkezi olarak import edebiliyoruz. Uzun süredir beklediğimiz bir araç olan PST Capture aslında farklı 3 parti yazılım üreticilerinin bazı ürünlerinde sunulmaktaydı. Ancak bu ürünlerin hem pahalı hem de kurulum – konfigürasyonunun zor olması ve en önemlisi asıl amaçlarının PST import olmaması işlerimizi zorlaştırmaktaydı.

Bu yazıyı okuyan bazı sistem yöneticilerinin aklına “neden PST dosyalarını import edeyim” sorusu gelebilir.

Aslında bu biraz yönettiğiniz yapılar ile ilgili bir durumdur. Kurumsal yapılarda tüm verilerin merkezi bir yerde saklanması, merkezi olarak yedeklenmesi ve bazı kanuni durumlar nedeni ile ( Legal Hold ) arşivlenmesi gerekmektedir. Ancak kobi tarzındaki küçük işletmelerde genel olarak mailler bu kadar önemli değildir ve pek çok kez Legal Hold vb arşivleme gereksinimlerini yerine getirmezler. Hatta sunucu üzerine alacakları disklerin pahalı olması veya bir Storage sahibi olmadıkları için mailleri Exchange Server diskleri üzerinde tutmak yerine kullanıcıların yerel disklerinde PST olarak tutmayı bilinçli bir şekilde tercih ederler.

Bu aracın aslında amacı böyle bir mimari ile kurulmuş ancak sonrasında kurumsal bir yönetime geçiş yapan sistemlerde aktif rol almaktır. Çünkü zaten yapısı oturmuş büyük firmalarda bırakın PST de dosya tutmayı kullanıcıların PST oluşturmaları bile yasaktır ( GPO ile bu yasaklanmıştır ). Doğal olarak tüm maillerin Exchange Server ve buradan da arşiv sistemlerinde tutulduğu bu yapılarda çok aktif rol alması beklenmez. Ancak başka bir MTA’ dan Exchange Server’ a geçişlerde veya mevcut yapısındaki PST leri temizleyerek merkezi bir sistem kurmak isteyen yöneticiler için çok yararlı bir araçtır.

Gelelim makalenin teknik kısmına. Öncelikle kurulum ile başlayacağız ve sonrasında PST import işlemlerine değineceğim.

Kurulum için aşağıdaki kurulum dosyalarını ediniyoruz

http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=28767

Burada görüldüğü gibi 3 kurulum dosyası bulunmaktadır.

PSTCapture.msi

PSTCaptureAgent.msi

PSTCaptureAgent_x86.msi

Kurulum dosyalarını indiriyoruz ancam kuruluma başlamadan önce size mimari hakkında bilgi vermek istiyorum.

PST Capture aracı aşağıdaki 3 temel bileşenden oluşmaktadır;

PST Capture Central Service

Bu Servis PST Capture aracının kalbidir. Bu servis sayesinde network üzerinde bulduğunu PST dosyalarının listeleri tutulur ve yine bu PST dosyalarının Exchange Server veya Exchange Online üzerine import edilmesini sağlar.

PST Capture Agent

Organizasyonunuz içerisindeki bilgisayarlara yüklenen küçük bir servistir. Bu servis sayesinde merkezi konsoldan tarama işlemi yapılabilmektedir. Bu tarama sonrasında konsol üzerinden import işleminin başlaması için PST dosyasını gönderme sürecini üstlenir.

PST Capture Console

Bu arayüz sayesinde merkezi olarak arama işlemleri, hedef mailbox belirleme, import işlemleri ve bunların durumu hakkında bilgi alabiliriz. Ayrıca yine bu konsol sayesinde Agent yüklemeden network attached storage (NAS) üzerindeki PST dosyalarıda import edilebilmektedir.

Burada size en önemli tavsiyem bu aracı ayrı bir sunucuya kurmanızdır. Yani PST import sunucusu gibi düşünebilirsiniz ve konsolu bu sunucu üzerine kurunuz. Eğer imkanınız yok ise tabiki diğer sunucu rolleri ile aynı sunucuda çalışabilir. Ancak burada önemli olan PST import etmek için bu bilgisayarda mutlaka Outlook programı (64bit ve 2010 sürümü ) kurulu olması gerekmektedir. Bu nedenle Exchange Server üzerine kurulmasını tavsiye etmiyoruz.

Organizasyonunuzdaki bilgisayarlara yüklemiş olduğunuz Agent’ lar her dakikada bir Central Service yani merkezi konsolun ve servisin yüklü olduğu sunucuya giderek bir değişiklik olup olmadığını kontrol eder. Eğer bir PST import işlemi var ise bunu alıp süreci başlatır ve bu bilgiyide yine Central Service yüklü bilgisayara gönderir.

Bu yoklama süresi ( polling ) sizin için çok kısa gelebilir ve bu durum için isterseniz bu değeri değiştirebilirsiniz. ( makalemin ikinci bölümünde ayarları detaylı incelerken göreceksiniz )

Yine konumuz network kullanımına gelmişken bir bilgi daha paylaşmak istiyorum. PST import işlemi sırasında PST dosyası istemci makinesinden Central Service barındıran host makinesine gönderilmektedir. Yani istemcilerden merkezi olarak konumlandırdığınız bu host makinesine alınmaktadır. Bundan sonra ise iki ayrı hedefimiz olabilir. Eğer import ettiğimiz PST için hedef gösterdiğimiz mailbox yerleşik exchange sunucularımızda ise bu istek CAS üzerinden gönderilirken, Cloud bazlı yani Exchange Online üzerindeki bir mailbox seçilmişse bu durumda bizim host makinemiz direk cloud sistemlerine bu datayı göndermektedir.

Şimdi gelelim kuruluma.

Öncelikle bu aracın sadece Exchange 2010, Office 365 ve Exchange BPOS desteklediğini belirtmek isterim. Bunu dışındaki Exchange sürümlerine destek vermemektedir.

Kurulum için merkezi servisin kurulacağı makinede mutlaka 64bit Outlook 2010 olmalı ve tabiki .net 3.5 yüklü olmalıdır.

Merkezi servis ve yönetim konsolunu kurmadan önce bize bir servis hesabı ve tabiki bu servis hesabı için bir takım izinler gerekmektedir.

Yapacağınız işlemler ve gereksinimlerini aşağıdaki tabloda bulabilirsiniz. Bu nedenle kurulumdan önce mevcut yetkili bir hesabı kullanmanız veya aşağıdaki gereksinimleri yerine getirecek yeni bir servis hesabı açmanız gerekmektedir.

Yetkilendirme kısmını tamamladıktan sonra merkezi yönetim konsolunu kuralım.

Son derece basit bir kurulumda tek detay aslında yukarıda bahsettiğimiz servis hesabını atamaktır.

Yetkili bir servis hesap bilgisi verdikten sonra kurulumu tamamlıyoruz.

Kurulum ardından start menüsünde programı görebiliyoruz

Bu kurulumdan hemen sonra agent kurulumunu yapıyoruz. Agent kurulumu için SCCM veya GPO kullanabilirsiniz.

Ben elle bir kurulum yapıyorum. Benzer şekilde kurulumda teknik bir detay yok. Sadece Central Service makinesinin ismini yazmanız yeterli

Server bölümüne Central Service yüklü olan bilgisayarın ismini yazıyoruz. Tabiki ilgili portun firewall tarafında açık olduğuna emin olun ( normal şartlarda domain ortamında firewall şirket içi kapalıdır ).

Agent kurulumu tamamlandıktan sonra Servislerin bulunduğu konsolu açtığımız zaman

“Microsoft Exchange PST Capture Agent Service” isimli servisini görebiliyoruz.

Evet yüklemeleri bitirdiğimize göre artık arama işlemine başlayabiliriz

Merkezi yönetim konsolumuzu açıyoruz

Konsol ilk açıldığında arama ve import işlemleri için iki ana seçenek sunmaktadır. Biz ilk olarak arama işlemini gerçekleştireceğiz. Bu nedenle “New PST Search” bölümüne tıklıyoruz

Aşağıdaki gibi bir sihirbaz karşımıza çıkmaktadır.

Bu arayüz sayesinde arama yapmak istediğimiz makineyi sağ üst köşedeki arama bölümünden bulabileceğimiz gibi tüm domain veya belirli bir OU altındaki bilgisayarları seçebiliriz.

Örneğin ben aşağıdaki gibi bir OU seçip içerisindeki makine üzerinde arama yaptırabilirim

Ancak burada bir konuya dikkatinizi çekmek istiyorum. Bilgisayar ikonuna bakacak olursanız kırmızı bir monitör resmi göreceksiniz. Bunun anlamı, ilgili bilgisayar üzerinde yüklü bir agent olmadığıdır.

Bende agent yüklediğim bilgisayarı buluyor ve seçiyorum

BU OU altında sadece bir makinede bu agent yüklü olduğunu görüyorum ve bunu seçiyorum, ardından “Next” diyerek ilerliyorum

Bu bölümde ise agent yüklü olan bilgisayarda PST dosyalarını nerede arayacağımızı seçiyoruz. İlk bölümde network ve harici sürücüler hariç tüm internal sürücülerde arama yapacak şekilde bir seçim yapıyoruz. İsterseniz bu süreci kısaltmak adına “These locations ( e.g. c: ; d:\myPSTs)” bölümünü seçerek örneklerde olduğu gibi sürüc veya yol belirtebiliyoruz. Veya local değil sadece çıkarılabilir medyaları taramak istiyorsak “None” diyerek bu bölümü geçebiliriz. Tabiki hemen altındaki “All removeable drivers” bölümü seçili olmalı.

Alt bölümde ise hangi dosyaların taramada görmezden gelineceğini seçebiliyoruz. Ayrıca yine bu bölümde sürücü veya yol belirterek o bölümlerin aranmamasını sağlayabiliriz.

Bu seçimleride yapıp next diyerek ilerliyoruz

Taramayı zamanlayabiliyoruz

Tarama işlemine açıklayıcı bir isim veriyoruz ve sonunda karşımıza aşağıdaki gibi bir ekran çıkıyor.

Burada 1 makine için henüz arama yapılmamış bir ekran görüyoruz. Aramayı başlatmak için sağ üst köşedeki “Search All Now” diyerek arama başlatabileceğimiz gibi birden çok makine olması halinde ve tek tek arama yapmak istersek bu bilgisayar üzerine sağ tıklayarak arama başlatabiliriz

Arama sonuçları ise aşağıdaki şekilde görülmektedir

Örneğin benim bilgisayarımda 10 adet PST bulduk ve istediğimiz PST yi import edebiliyoruz

İmport bölümünde iki seçenek bulunmaktadır. Online veya OnPrem yani yerleşik Exchange organizasyonu. Ben yerleşik Exchange organizasyonunu seçiyorum. Burada eğer online bir import yapmak istiyorsanız öncelikle bu araç üzerinde “Tools – Settings” altındaki aşağıdaki tanımlamaları yapmanız gerekmektedir.

Biz local exchange server ile devam ediyoruz. İmport seçeneğini seçtikten sonra durum aşağıdaki gibidir

Artık import işlemine hazırız ve yine benzer bir şekilde ister tek bir bilgisayar üzerinden ister birden çok olması durumunda sağ üst köşedeki buton yardımı ile import işlemini yapabiliriz. Ancak bundan önce hedef bir mailbox seçmemiz gerekmektedir.

Bunun için import edilecek pst dosyasının satırında sağ taraftaki “Set mailbox” linkine tıklıyoruz ve istediğimiz bir kullanıcı mailbox’ ını seçiyoruz

Ardından “import all now” tıklayarak süreci başlatıyoruz.

Yukarıdaki gibi sorunsuz bir şekilde PST dosyasını hedef posta kutsunu aldık.

Sonucu outlook programından görebilirsiniz

Bu sayede PST import işlemini tamamlamış olduk.

Makalemin ikinci bölümünde ise PST import aracının özellikleri ve NAS üzerinden PST import süreçlerini paylaşacağım.

Bence çok başarılı çalışan bir araç. Tabiki uygulamada sorunlar yaşayabilirsiniz, ben şirket ortamında test ettim ve gayet güzel çalışıyor, ancak gerek kurulum gerek kullanım noktasında sorunlar yaşamanız halinde makalelerimizin alt bölümünde yorumlar yerine forum sayfasına sorularınızı sorabilirsiniz.

Exchange Server 2010 SP2 ile beraber gelen ve dağınık mimarilere sahip Exchange organizasyonları için önemli bir yeniliktir. Bölge, şube, ekip veya birim bazlı ayrı adres defteri kullanmak veya görmek isteyen servisler için Address Book Policy ABP bizlere yardımcı olacaktır. Aslında ABP’ nin yaptığı işlem “Global address list (GAL) segmentation” veya “GAL segregation” da olarak bilinen herkes için tek olan ve tüm şirket çalışanlarını gösteren bu adres defterini segmentlere ayrımaya yarar. Yine benzer bir şekilde tek bir Exchange Server mimarisi üzerinden hosting hizmeti sunuyor ancak Exchange Server kurulumu sırasında hosting komut setini kullanmamış iseniz, bu yeni özellik ayrıca müşterilerinizin birbirlerinin mail adreslerini de görmesini engelleyecektir. Tabiki bu son örnek sağlıklı bir mimari değildir. Yani amacınız Exchange üzerinden hosting hizmeti sunmak ise kurulumu buna göre yapmak çok daha doğru olacaktır.

Bu konuda daha fazla bilgi için aşağıdaki linki inceleyebilirsiniz

http://social.technet.microsoft.com/wiki/contents/articles/exchange-2010-sp1-information-for-hosted-service-providers.aspx

GAL segregation işlemi tabiki Exchange Server 2007’ den beri yapabiliyorduk ancak bu işlem için Query Base DN veya access control lists (ACLs) kullanıyorduk ve bu da bir hayli zor bir yöntemdi. Şimdi ise ABP ile bunu kolaylıkla yapabilmekteyiz.

Ancak ABP kullanmak için bazı şartlar bulunmaktadır.

Öncelikle bu özelliği kullanmak isteyen kullanıcı mailbox’ ları Exchange 2010 SP2 yüklü bir mailbox sunucularında barındırılıyor olmak zorundadır.

Ayrıca ABP kullanmak istiyorsak Hierarchical Address Book (HAB) özelliği devre dışı olmalıdır. Son limitasyon ise Exchange Server GC olan bir DC üzerinde yüklü ise bu özellik kullanılamaz.

Not ; Outlook for Mac ve Entourage LDAP erişimleri olmayan ürünler olduğu için bu özelliği kullanamamaktadır. Çünkü şirket networklerine bağlık bu iki yazılım Microsoft Exchange Address Book service yerine direk olarak Global Catalog üzerinden Active Directory’ ye sorgu yapmaktadır. Fakat Outlook for Mac 2011 eğer internet üzerinden bağlantı kuruyor ise OAB veya Exchange Web Services (EWS) lerine bağlanabildiği için kendisine atanan ABP’ leri GAL bazlı olarak alabilmektedir.

Not ; ABP office 365 üzerinde çalışmamaktadır. Bu nedenle hybrid bir deployment yapmanız halinde office 365 üzerindeki kullanıcılarınız tüm adres defterini segmentlere ayrılmamış olarak yani varsayılan biçimde görecektir.

Peki bu yapı nasıl çalışır ?

Her bir ABP aşağıdaki bileşenlerden oluşur;

·         Bir adet GAL

·         Bir adet OAB

·         Bir adet room list

·         Bir veya daha fazla address lists

Yukarıda görüldüğü gibi şirket organizasyonu içerisinde pek çok GAL, Room Address List, Offline Address Book ve Address List’ ler olabilir.

Örneğin benim senaryomda Rize ve Antalya olmak üzere temelde iki ana OU altında toplanmış bir mimari bulunmaktadır.

Ayrıca bu yapı için açmış olduğum GAL, OAB, Address List ve Room Address List ise aşağıdaki gibidir.

OAB’ ları yukarıda görebiliyoruz.

Burada ise GAL, Address List ve Room Address List’ leri görebiliyoruz.

Son olarak ise iki adet ABP tanımladım.

Gelelim Bunları nasıl yaptığıma, bunlar için aşağıdaki powershell komutlarını kullandım.

Rize için gerekli adımlar

Rize isminde bir address list oluşturuyorum. Filtre bölümünde ise ofis bilgisinde “Rize” yazan kullanıcıların görüntülenmesini sağlıyorum.

New-AddressList -Name "Rize – Address List" -RecipientFilter {((RecipientType -eq ‘UserMailbox’) -or (RecipientType -eq "MailUniversalDistributionGroup") -or (RecipientType -eq "DynamicDistributionGroup")) -and (Office -eq "Rize")}

“Rize – Room List” isminde bir Room Address List oluşturuyorum. CustomAttribute1 bölümünde “Rize” yazan Odaların ( Room ) görüntülenmesini sağlıyorum.

New-AddressList -Name "Rize – Room List" -RecipientFilter {((Alias -ne $null) -and (CustomAttribute1 -eq "Rize") -and ((RecipientDisplayType -eq ‘ConferenceRoomMailbox’) -or (RecipientDisplayType -eq ‘SyncedConferenceRoomMailbox’)))}

“Rize – Global Address List” isminde yeni bir GAL oluşturuyorum. Filtre bölümünde ise ofis bilgisinde “Rize” yazan kullanıcıların görüntülenmesini sağlıyorum.

New-GlobalAddressList -Name "Rize – Global Address List" -RecipientFilter {(Office -eq "Rize")}

“Rize – Offline Address List” isminde bir OAB oluşturuyorum ve bu Offline Address Book içerisine sadece “Rize – Address List” i ekliyorum.

New-OfflineAddressBook -Name "Rize – Offline Address List" -AddressLists "Rize – Address List"

Şimdi ise yeni bir ABP yapıyorum ve bu ABP içerisine yukarıdaki oluşturduğum Adres listelerini ekliyorum

New-AddressBookPolicy -Name "Rize – ABP" -AddressLists "\Rize – Address List" -OfflineAddressBook "\Rize – Offline Address List" -GlobalAddressList "\Rize – Global Address List" -RoomList "\Rize – Room List"

Bu bölümü isterseniz ara yüz üzerinden de yapabilirsiniz;

Son olarak bu oluşturduğumuz ABP yi kullanıcılara uygulamak gerekli. İsterseniz tek tek kullanıcıların üzerinde bu değişiklikleri yapabilirsiniz.

Ancak tek tek kullanıcıların üzerinde bu tür ayarlamalar bir hayli zaman alacaktır. Bu nedenle ben topluca seçip ofis bilgisi yazdığım kullanıcılar için powershell kullanıyorum.

Get-Mailbox | where {$_.Office -eq "Rize"} | Set-Mailbox -AddressBookPolicy "Rize – ABP"

Bu powershell Office bilgisi olarak Rize yazan tüm mailboxları getirir ve bunun ABP değerini “Rize – ABP” olarak günceller.

Bu yukarıdaki adımlatın aynılarını Antalya içinde yapıyorum.

New-AddressList -Name "Antalya – Address List" -RecipientFilter {((RecipientType -eq ‘UserMailbox’) -or (RecipientType -eq "MailUniversalDistributionGroup") -or (RecipientType -eq "DynamicDistributionGroup")) -and (Office -eq "Antalya")}

New-AddressList -Name "Antalya – Room List" -RecipientFilter {((Alias -ne $null) -and (CustomAttribute1 -eq "Antalya") -and ((RecipientDisplayType -eq ‘ConferenceRoomMailbox’) -or (RecipientDisplayType -eq ‘SyncedConferenceRoomMailbox’)))}

New-GlobalAddressList -Name "Antalya – Global Address List" -RecipientFilter {(Office -eq "Antalya")}

New-OfflineAddressBook -Name "Antalya – Offline Address List" -AddressLists "Antalya – Address List"

New-AddressBookPolicy -Name "Antalya – ABP" -AddressLists "\Antalya – Address List" -OfflineAddressBook "\Antalya – Offline Address List" -GlobalAddressList "\Antalya – Global Address List" -RoomList "\Antalya – Room List"

Get-Mailbox | where {$_.Office -eq "Antalya"} | Set-Mailbox -AddressBookPolicy "Antalya – ABP"

Peki şimdi sonucu görelim.

Antalya çalışanlarından olan Hakan ile logon oluyorum ve adres defterini açıyorum;

Policy uygulanmadan önce

Uygulandıktan sonra

Görüldüğü gibi sadece Antalya GAL ve Antalya Room List geliyor ve yine bu GAL içerisinde sadece Antalya çalışanları bulunuyor. Diğer adres listelerini göster dersenizde Antalyaya ait olan Address List ler gelecektir.

Ancak burada unutulmaması gereken nokta artık bu kullanıcı diğer şubedeki kullanıcıları adres defteri üzerinden göremeyecektir.

Yukarıda görüldüğü üzere şirket organizasyonunda Serkan isimli bir çalışan olmasına rağmen kendi segmentinde olmadığı için bu isim “Check Names” kısmından da çözümlenmiyor.

Ancak Serkan veya sık görüştüğünüz kişileri kendi kişi listenize eklerseniz bu durumda check names çalışacaktır. Veya Ek adres listelerini OAB içerisine de ekleyebilirsiniz.

Umarım faydalı bir makale olmuştur. Bir sonraki makalemizde görüşmek üzere.

Relay bildiğiniz gibi “iletme” manasına gelen teknik bir terim olup, bir mail server’ın kendisine gelen bir maili gönderme isteğini yerine getirmesidir.

Burada mail server için genel olarak MTA kısaltması kullanılmaktadır. Örneğin Exchange Server, Mail Enable, Merak mai, Qmail vb. Yine bu MTA ya bağlı olan outlook, outlook express vb yazılımlara ise MUA denmektedir.

Bu bilgiler ışığında bir MUA, mail göndermek istediği zaman bu isteği MTA’ ya iletir, MTA bu isteği izinleri doğrultusunda kontrol ettikten sonra hedef MTA’ a iletir ve bu sayede “relay” yani iletim işlemi gerçekleşmiş olur.

Bunu bir örnek ile özetlemek gerekirse.

Hakan kullanıcısının mail adresi hakan@cozumpark.com ve mail göndermek istediği kişinin mail adresi serkan@uzuner.com. Bu yapıda ben kendi outlook programım üzerinden to kısmına Serkanın mail adresini yazıp send dediğim anda benim outlook programım bağlı olduğu MTA ya bu isteği gönderir. Bu MTA nın hangi ürün olduğu önemli değil sonuç olarak SMTP protokolü kullanılmaktadır ve MTA benim bu iş için iznim olup olmadığına bakar, eğer iznim var ise bu maili uzuner.com’ un MTA sunucusuna gönderir. Bu işleme relay yani iletme denir.

Ancak sektörde bu işlemden çok kimlik bilgisi olmadan sunucuların veya servislerin bizim MTA üzerinden mail göndermesi işlemine relay denmektedir. Tabiki yanlış bir tanım değil ancak işin doğrusu yukarıdaki gibidir.

Peki gelelim neden bu konu bu kadar önemli ? Relay isteği pek çok şirket organizasyonunda sık karşılaşılan bir istektir. Yedekleme yazılımları, yazıcılar, anti virüs programları, sharepoint, ve benzeri pek çok yazılım veya donanım kendi üzerindeki bilgileri yöneticiler veya kullanıcılar ile paylaşmak için bir mail server’ a ihtiyaç duyar. Bu servis veya donanımlardan bazıları MTA üzerinden relay yapmak için kimlik bilgisi verebilir, örneğin sizi sunucularını yönetmek için kullandığınız bir izleme programına aynı zamanda düşen uyarıları size mail atsın diye bir mail server ip adresi, kullanıcı adı ve şifresi verebilirsiniz. Aslında bu durumda bu yazılım bir outlook istemci programından farksızdır. Çünkü bu yazılımda aynı bir kullanıcı gibi kimlik bilgisini verir ve mail gönderim isteğinde bulunur. Ancak işler her zaman bu şekilde yürümez, dahası her servis, program veya donanım için ayrı ayrı hesap açmak, şifresini saklama, değiştirmek ve benzeri operasyonel işlerden dolayı insanlar kimlik bilgisi olmadan mail gönderim izni yani relay izni vermek ister.

Buradaki temel kural IP bazlıdır. Yani ben size bir mail server ip adresi veriyorum siz bunu SMTP server bölümüne yazıyorsunuz başka hiçbir kimlik bilgisi istemiyorum. Tek istediğim sizin bu mail server’ ı kullanacak olan servisin çalıştığı veya programın yüklü olduğu veya donanımın sahip olduğu ip adresini benimle paylaşmanız gerekiyor. Bende Exchange Server üzerinde relay için ayrı bir receive connector oluşturuyorum ve bu ip den gelen istekleri kabul et diyorum.

İşte bu makalemde bu konuyu detaylandırmak istiyorum.

Varsayılan olarak kurulan bir Exchange Server 2007 – 2010 mimarisinde iki adet connector bulunmaktadır. Bunlardan birisi "Default" isminde ve 25 nolu portu dinlemektedir, diğeri ise "Client" isminde ve 587 nolu portu dinlemektedir.

Ve bu connectorlerin izin gruplarına baktığımız zaman aşağıdaki detayları görüyoruz.

Bu resimden anladığımız, Exchange kullanıcıları ( yani kimliğini doğrulayan posta kutuları) veya Exchange Server’ ların kendileri bu connectorleri kullanabilmektedirler. Ancak hangi amaç ile kullanacaklarının detayını buradan göremeyiz.

Bu detaydan kastım şudur. Örneğin yeni kurulan bir Exchange Server nasıl dış dünyaya mail atmak için ilk olarak bir Send connector tanımlıyorsak benzer şekilde yeni kurulan bir Exchange 2007 – 2010 sistemininde dış dünyadan mail alması için Default connector üzerindeki "Anonymous" kutucuğunun işaretlenmesi gerekmektedir. Bunun amacı bu connector ile iletişim kurmak isteyen bir kişinin kimler olacağını seçebiliyoruz. Eğer bu connector üzerinde anonim kutucuğunu işaretlemez ise bu durumda dış dünyadan örneğin hotmail, gmail vb yerlerden bir smtp isteği geldiğinde bu connector “kimsin se?” sorusunu soracaktır ve alacağı cevap ya bir exchange server kullanıcı bilgisi olmalı yada içeride olan ve güvendiği bir exchange server bilgisayar hesabı. Ancak bunların her ikisininde hotmail veya gmail gibi sunucularda bulunmayacağı için biz ilk iş olarak anonim erişimi açıyoruz.

Ancak burada yanlış anlaşılma olmasın, bir anonim erişimi açıyoruz ancak bu relay amaçlı değil. Yani bu açmak terimi sadece mail kabul etmek anlamındadır.

Zaten siz bu anonim kutucuğunu işaretleyip sonra mail server ip adresi olarak bu connector ip adresini yazıp mail göndermeyi denerseniz başarızı olacağınızı göreceksiniz.

Bunu daha kolay anlatmak için aşağıdaki tabloyu kullanacağım. Gördüğünüz gibi bu tabloda Exchange Server receive connector üzerinde seçtiğiniz izin gruplarının arka tarafta hangi izinlere karşılık geldiğini görebiliyoruz.

Örneğin ben biraz önce dış dünyadan mail almak için Anonim kutucuğunu işaretledim bu durumda vermiş olduğum izinler aşağıdaki gibi oluyor

Ms-Exch-SMTP-Submit

Ms-Exch-SMTP-Accept-Any-Sender

Ms-Exch-SMTP-Accept-Authoritative-Domain-Sender

Ms-Exch-Accept-Headers-Routing

Dikkat ederseniz “Accept-Any-Sender” yani herhangi bir gönderici ( hotmail, gmail, msn vs ) için izin vermiş oldum ama aşağıdaki gibi herhangi bir alıcı için izin vermedim.

Ms-Exch-SMTP-Accept-Any-Recipient

Bu izin ise bu MTA yani Exchange server’ a gelen bir smtp oturumu içerisinde to kısmında yani alıcı kısmında kim olursa olsun kabul et anlamında bir izindir ki varsayılan olarak anonim kutucuğu ile gelmez.

Buraya kadar paylaştığım bilgiler ışığında şimdi örnek bir senaryo ile bunları uygulamaya geçelim.

Şirket organizasyonunuzda bir adet HUB transport sunucu olsun, bu durumda varsayılan olarak iki receive connector bulunmaktadır. Ben bu varsayılan connectorlere sadece anonim kutucuğunu işaretleyerek dış dünyadan mail almasını sağlıyorum. Birde send connector tanımlayarak dış dünyaya mail atmayı gerçekleştiriyorum.

Şimdiki amacım ise iş ailesinden gelen relay istekleri için yeni bir HUB kurmak veya var olan HUB üzerinde yeni connectorler tanımlamak.

Eğer reklam mailleri gibi toplu ve sık gönderilecek bir sistem için relay izni isteniyor ise size tavsiyem mutlaka şirket maillerinin trafiğinden sorumlu olan HUB transport sunucu rölünden bir tanede daha kurup bunun ip adresini sadece bu reklam mailleri gönderen sisteme verin. Bu sayede şirket kurumsal mailleri ile bu reklam mailleri bir sunucu üzerinden gönderilmeyeceği için bir mail trafik yoğunluğu yaşanmaz. Hatta elinizde imkan var ise bu yeni kurduğunuz sunucuyu ayrı bir ip adresinden internete çıkarırsanız RBL girme durumlarında kurumsal mail trafiğiniz bundan etkilenmez.

Peki biz ilk senaryomuza dönelim. Yani pek çok kobiye yararlı olması açışından tek bir HUB varmış gibi çözüm üretiyorum.

Tek HUB olduğu için var olan iki connector yanına iki adet daha connector ekleyeceğim, ancak zaten 25 nolu portu dinleyen bir connector olduğu için aynı portu dinleyen başka bir connector açmak için ip bazlı ayırım yapmalıyım.

Bu nedenle ilk olarak var olan connector için sunucnun var olan ip adresini kullanmasını istiyorum.

Bunun için Default Receive Connector üzerinde network sekmesinde aşağıdaki ip adreslerini kaldırıp elle sunucuya ait olan bir adresi ekliyorum

Veya bu ip adreslerini değiştirmek istemiyorsanız, olurda sunucu ip adresini değiştirdiğiniz zaman gelip buradaki ip adresinide değiştirmeniz gerekli çünkü bu ip leri bu şekilde bırakabilirsiniz. Ancak bir çakışma olmaması için yeni oluşturacağımız connectorler için mutlaka kaynak ip adreslerini elle yazmalıyız.

Yukarıdaki cümle karışık geldi ise özetle, bu var olan connector aynen olduğu gibi kalsın ve biz yeni bir connector oluşturalım.

Connector ismi “internalrelay” ve izin gruplarını ayarlayan aşağıdaki seçeneği ise “Custom” yapıyorum. Bunun temel sebebi bu izinleri kendim elle ayarlayacağım. Eğer siz bu bölümde internal veya internet gibi hazır şablonları kullanırsanız buna göre izin grupları eklenecektir bu connector üzerine.

Connector için bir isim verdikten sonra varsayılan olarak gelen tüm Ipv4 adresleri için 25 nolu portu dinle anlamına gelen “Local Network settings” kısmındaki “All Available Ipv4” ibaresini kaldırıyorum ve bu sunucunun TCP/IP ayarlarına bu yeni connector için eklediğim ikinci ip adresini yazıyorum.

Yukarıda görüldüğü gibi aslen kurulum sırasında 192.168.168.169 ip adresine sahip olan bu HUB sunucusu için ben ayrıca 170 ile biten bir ip daha ekledim ve bu ipyi bu connector’ e bağladım.

Bir sonraki bölümde ise bize bu connector hangi kaynaklardan gelen 25 nolu smtp isteklerine cevap vereceğini belirleyebiliyoruz. Şu anda tüm networklerden gelen ipler için 25 nolu portu dinlemek üzere ayarlanmış durumda ancak bu şekilde devam edemeyiz. Eğer bu şekilde devam edersek varsayılan connector ile çakışma olacağı için hangi sunucular relay yapacak ise en azından bir tanesinin ip adresini yazarak devam ediyoruz. Eğer henüz relay yapacak ip sunucu ip adresi bilmiyorsanız rastgele bir ip adresi yazın, sonra tekrar değiştirme imkanına sahibiz.

Örneğin ben 100 ile biten Anti Virüs sunucumu seçtim.

Son noktada artık 3 tane receive connector sahibiyiz. Şimdi bir dördüncü connector olan “externalrelay” connectorünü yukarıdaki adımlara dikkat ederek oluşturuyoruz.

External relay için ayrı bir ip adresi daha ekledim HUB sunucusuna.

Benzer şekilde dış dünyaya relay yapacak sunucu ip adresini yazıyorum. 192’ li ip bloğundan değil ama bu sorun değil, malum büyük network yapılarında vlan’ lar nedeni ile aynı ortamdaki pek çok sunucu bu şekilde farklı ip havuzları ile birbirinden ayrılmaktadırlar.

Peki son durumda artık 4 tane receive connector’ üm var. Bunlarda biri şirket içi relay yapmak için biri ise şirket dışı relay yapmak için kullanılacak.

Yani şirket içi relay yapmak isteyen bir sharepoint sunucusu için smtp server olarak 192.168.168.170 ip adresini kullanırken şirket dışına mail göndermek isteyen sistemler için ise smtp server olarak 192.168.168.171 ip adresini kullanabiliriz. Hatta bunları dns üzerinde “internalrelay” “externalrelay” şeklinde A kaydı açarak diğer adminlere ip yerine isimde verebilirsiniz.

Gelelim ince ayarlara.

Öncelikle bu connector’ lerin kimlik doğrulama ve izin gruplarını kontrol edelim

Yukarıda görüldüğü gibi TLS dışında hiçbir kimlik doğrulama kullanılmıyor. Bunun temel sebebi bu connector’ e kimse gelip kimlik bilgisi vermeyecek yada versede biz kabul etmeyeceğiz. Çünkü bu connector’ lerin amacı relay yapmak yani ip bazlı gelen istekleri iletmektir. Bu hem internal hemde external connector için geçerli bir durumdur.

Permissions Groups bölümünde ise hem internal hemde external için “Anonymous users” kutucuğu işaretli gelmez, biz bunu işaretliyoruz.

Şimdi bu durumda internalrelay için yapacaklarımız bitti. Yani bir sistem sadece şirket içine mail atmak isterse 192.168.168.170 nolu ip yi mail server ip adresi olarak yazabilir. Bizde bu mail atmak isteyen mail sisteminin ip adresini tabiki connector üzerindeki “Network” sekmesinde bulunan “Receive mail from remote servers that have these IP address” bölümüne ekliyoruz.

Peki gelelim externalrelay kısmına. Aslında external relay içinde için aynı internalrelay de olduğu gibi insanlara externalrelay connector ip adresini paylaşıyor olmanız gerekli ( tabiki ihtiyaç duyanlara ). Ardından benzer şekilde bu connector üzerinden mail göndermek isteyen sistemlerin ip adreslerini yukarıdaki şekilde olduğu gibi externalrelay isimli connector içinde tanımlıyor olmalısınız. Son olarak ise aşağıdaki izni vererek bu connector’ ü dış dünyaya relay için açabiliriz

Get-ReceiveConnector "externalrelay" | Add-ADPermission -User "NT AUTHORITY\ANONYMOUS LOGON" -ExtendedRights "Ms-Exch-SMTP-Accept-Any-Recipient"

Bu izin görüldüğü gibi anonim istekler için “Ms-Exch-SMTP-Accept-Any-Recipient” yani alıcı kim olursa olsun hotmail,gmail önemli değil kabul ederim, yani dış dünyaya gelen isteği ayen iletirim noktasındaki izindir.

Bu konuyu daha detaylı incelemek isterseniz aşağıdaki komutları inceleyebilirsiniz.

Örneğin internalrelay connectorü için izin durumu aşağıdaki gibidir

Get-ADPermission "internalrelay" | select user,extendedrights

Gördüğünüz gibi sadece “Any-Sender” bulunmakta olup “Any-Recipient” yoktur.

Bu komutun tam çıktısı ise aşağıdaki gibidir

User ExtendedRights

—- ————–

NT AUTHORITY\ANONYMOUS LOGON {ms-Exch-SMTP-Accept-Any-Sender}

NT AUTHORITY\ANONYMOUS LOGON {ms-Exch-Accept-Headers-Routing}

NT AUTHORITY\ANONYMOUS LOGON {ms-Exch-SMTP-Submit}

NT AUTHORITY\ANONYMOUS LOGON {ms-Exch-SMTP-Accept-Authoritative-Domain-Sender}

COZUMPARK\Delegated Setup {Send-As}

COZUMPARK\Delegated Setup {Receive-As}

COZUMPARK\Delegated Setup

COZUMPARK\Exchange Servers {ms-Exch-Store-Constrained-Delegation}

COZUMPARK\Exchange Servers {ms-Exch-Store-Transport-Access}

COZUMPARK\Exchange Servers {ms-Exch-Store-Read-Access}

COZUMPARK\Exchange Servers {ms-Exch-Store-Read-Write-Access}

NT AUTHORITY\NETWORK SERVICE {ms-Exch-EPI-Token-Serialization}

COZUMPARK\EXCH2010SP2$

COZUMPARK\Delegated Setup

NT AUTHORITY\SYSTEM

NT AUTHORITY\NETWORK SERVICE

COZUMPARK\Exchange Servers {Receive-As}

COZUMPARK\Organization Management {ms-Exch-Recipient-Update-Access}

COZUMPARK\Public Folder Management {ms-Exch-Recipient-Update-Access}

NT AUTHORITY\SYSTEM {ms-Exch-Recipient-Update-Access}

COZUMPARK\Domain Admins {Send-As}

COZUMPARK\Enterprise Admins {Send-As}

COZUMPARK\Organization Management {Send-As}

COZUMPARK\administrator {Send-As}

COZUMPARK\Domain Admins {Receive-As}

COZUMPARK\Enterprise Admins {Receive-As}

COZUMPARK\Organization Management {Receive-As}

COZUMPARK\administrator {Receive-As}

COZUMPARK\Domain Admins {ms-Exch-EPI-Impersonation}

COZUMPARK\Schema Admins {ms-Exch-EPI-Impersonation}

COZUMPARK\Enterprise Admins {ms-Exch-EPI-Impersonation}

COZUMPARK\Organization Management {ms-Exch-EPI-Impersonation}

COZUMPARK\Domain Admins {ms-Exch-EPI-Token-Serialization}

COZUMPARK\Schema Admins {ms-Exch-EPI-Token-Serialization}

COZUMPARK\Enterprise Admins {ms-Exch-EPI-Token-Serialization}

COZUMPARK\Organization Management {ms-Exch-EPI-Token-Serialization}

COZUMPARK\Domain Admins {ms-Exch-Store-Constrained-Delegation}

COZUMPARK\Enterprise Admins {ms-Exch-Store-Constrained-Delegation}

COZUMPARK\Domain Admins {ms-Exch-Store-Transport-Access}

COZUMPARK\Enterprise Admins {ms-Exch-Store-Transport-Access}

COZUMPARK\Domain Admins {ms-Exch-Store-Read-Access}

COZUMPARK\Enterprise Admins {ms-Exch-Store-Read-Access}

COZUMPARK\Domain Admins {ms-Exch-Store-Read-Write-Access}

COZUMPARK\Enterprise Admins {ms-Exch-Store-Read-Write-Access}

NT AUTHORITY\Authenticated Users

COZUMPARK\Organization Management {ms-Exch-Create-Top-Level-Public-Folder}

COZUMPARK\Public Folder Management {ms-Exch-Create-Top-Level-Public-Folder}

COZUMPARK\Organization Management {ms-Exch-Store-Visible}

COZUMPARK\Public Folder Management {ms-Exch-Store-Visible}

COZUMPARK\Organization Management {ms-Exch-Store-Admin}

COZUMPARK\Public Folder Management {ms-Exch-Store-Admin}

COZUMPARK\Organization Management {ms-Exch-Store-Create-Named-Properties}

COZUMPARK\Public Folder Management {ms-Exch-Store-Create-Named-Properties}

COZUMPARK\Organization Management {ms-Exch-Modify-PF-ACL}

COZUMPARK\Public Folder Management {ms-Exch-Modify-PF-ACL}

COZUMPARK\Organization Management {ms-Exch-Mail-Enabled-Public-Folder}

COZUMPARK\Public Folder Management {ms-Exch-Mail-Enabled-Public-Folder}

COZUMPARK\Organization Management {ms-Exch-Modify-Public-Folder-Quotas}

COZUMPARK\Public Folder Management {ms-Exch-Modify-Public-Folder-Quotas}

COZUMPARK\Organization Management {ms-Exch-Modify-PF-Admin-ACL}

COZUMPARK\Public Folder Management {ms-Exch-Modify-PF-Admin-ACL}

COZUMPARK\Organization Management {ms-Exch-Modify-Public-Folder-Expiry}

COZUMPARK\Public Folder Management {ms-Exch-Modify-Public-Folder-Expiry}

COZUMPARK\Organization Management {ms-Exch-Modify-Public-Folder-Replica-List}

COZUMPARK\Public Folder Management {ms-Exch-Modify-Public-Folder-Replica-List}

COZUMPARK\Organization Management {ms-Exch-Modify-Public-Folder-Deleted-Item-Retention}

COZUMPARK\Public Folder Management {ms-Exch-Modify-Public-Folder-Deleted-Item-Retention}

COZUMPARK\Organization Management {ms-Exch-Create-Public-Folder}

COZUMPARK\Public Folder Management {ms-Exch-Create-Public-Folder}

COZUMPARK\Exchange Servers

COZUMPARK\Exchange Servers

COZUMPARK\Exchange Servers

COZUMPARK\Exchange Servers

COZUMPARK\Exchange Servers

COZUMPARK\Exchange Servers

COZUMPARK\Exchange Servers

COZUMPARK\Exchange Servers

COZUMPARK\Exchange Servers

COZUMPARK\Exchange Servers

COZUMPARK\Exchange Servers

COZUMPARK\Exchange Servers

COZUMPARK\Exchange Servers

COZUMPARK\Exchange Servers

COZUMPARK\Exchange Servers

COZUMPARK\Exchange Servers

COZUMPARK\Exchange Servers

COZUMPARK\Exchange Servers

COZUMPARK\Exchange Servers

COZUMPARK\Exchange Servers

COZUMPARK\Exchange Servers

COZUMPARK\Exchange Servers

COZUMPARK\Exchange Servers

COZUMPARK\Exchange Servers

Everyone {ms-Exch-Store-Create-Named-Properties}

NT AUTHORITY\ANONYMOUS LOGON {ms-Exch-Store-Create-Named-Properties}

Everyone {ms-Exch-Create-Public-Folder}

NT AUTHORITY\ANONYMOUS LOGON {ms-Exch-Create-Public-Folder}

Everyone

NT AUTHORITY\ANONYMOUS LOGON

Everyone

NT AUTHORITY\ANONYMOUS LOGON

COZUMPARK\Exchange Servers

COZUMPARK\Organization Management

COZUMPARK\Public Folder Management

NT AUTHORITY\SYSTEM

COZUMPARK\Exchange Servers

COZUMPARK\Organization Management

COZUMPARK\Exchange Trusted Subsystem

COZUMPARK\administrator

COZUMPARK\Enterprise Admins

COZUMPARK\Domain Admins

External Relay için bakalım

Externalrelay isimli connector’ de ise “Accept-Any-Recipient” bulunmaktadır.

Bu konfigürasyon ile birlikte “internalrelay” isimli connector sadece şirket içine mail atabilirken, “externalrelay” isimli connector hem şirket dışına hemde şirket içine mail gönderebilmektedir.

Evet bu şekilde orta be büyük ölçekli tüm firmaların relay ihtiyaçlarına cevap verecek bir yapı kurmuş oluyorsunuz. Tabiki makalemin başında da belirttiğim gibi bu tür relay işlemleri için ayrı HUB sunucular kullanıyor olmanız çok daha doğru olacaktır.

Umarım faydalı bir makale olmuştur.

Bir sonraki makalemizde görüşmek üzere.

Aslında bu makalede sizlere Exchange Server 2010 SP2 ile beraber gelen Cross-Site Redirection özelliğinden bahsetmek istiyordum. Ancak direk olarak bu konuya başlamadan önce genel olarak OWA için prox, redirection gibi kavramlarında detaylandırılmasını yapacağım. Bu şekilde yeni gelen bu özelliğinden faydaları daha net anlaşılacaktır.

Exchange Server OWA yönlendirme konusunda bilmemiz gereken kavramlar aşağıdaki gibidir.

Internet-facing Active Directory Site
Regional Internet-facing Active Directory Site
Non-Internet-facing Active Directory Site
Direct Connect
Proxy
Redirection
Silent Redirection
Single Sign-On (SSO) Redirection

Internet-facing Active Directory Site

İçerisinde OWA için External URL tanımlı bir CAS server barındıran ve internete bağlı olan AD site yapısını ifade eden kavramdır. Genellikle bu site hem internet bağlantıları için hemde MX için asıl site olarak kullanılır.

Regional Internet-facing Active Directory Site

İçerisinde OWA için External URL tanımlı bir CAS server barındıran ve internete bağlı olan AD site yapısını ifade eden kavramdır.

Non-Internet-facing Active Directory Site

İçerisinde OWA için External URL tanımlı olmayan bir CAS server barındıran AD site yapısını ifade eden kavramdır.

Direct Connect

Bir CAS Server’ ın RPC üzerinden Mailbox Server’ e bağlandığı durumu ifade eder.

Proxy

Internet-facing Active Directory Site içerisine gelen bir erişim isteğini bu site içerisindeki CAS server rolünün mailbox veri tabanının bulunduğu Non-Internet-facing Active Directory Site içerisindeki CAS server’ e yönlendirmesidir. Özetle internete bağlı olan siteye gelen isteğin bu site içerisindeki CAS serverdan internet bağlantısı olmayan site içerisindeki CAS server’ a yönlendirilme işlemidir.

Redirection

Bu senaryoda ise Internet-facing bir CAS sunucusu gelen istek yerine gelen kullanıcıyı yine ayrı bir Internet-facing CAS sunucusuna yönlendirmektedir. Proxy’ den en büyük farkı yönlendirilen istek değil kullanıcının kendisidir. Yani kullanıcı bir OWA adresinden diğer bir OWA adresine yönlendirilir. Örneğin https://rize.cozumpark.com dan doğru site olan https://antalya.cozumpark.com adresine yönlendirme için kullanıcıya bir bilgi ve link verir.

Silent Redirection

Yukarıdaki gibi bir durumda yönlendirmeyi kullanıcıya bilgi vermeden otomatik olarak yapar. Yani adres çubuğundaki rize, otomatik olarak antalya adresine dönüşür. ( Bu antalya adresini hedef CAS server external URL den almaktadır ). Ancak yeni adreste kullanıcı bir kez daha logon bilgisi girmek zorundadır.

Single Sign-On (SSO) Redirection

Bu ise yine yukarıdaki gibi bir yönlendirme işlemi yapar, yani adres çubuğu otomatik olarak yönlendirilir, ancak kullanıcıdan tekrar bir logon bilgisi istemez, ilk logon bilgisi ile otomatik olarak posta kutusuna erişimi sağlar.

Peki Exchange 2010 SP2 öncesi bu sistem nasıl çalışıyordu ?

1 – Kullanıcı OWA URL adresini browser’ a yazarak logon sayfasına ulaşıyor.

2 – Bu sayfada kullanıcı kimlik bilgilerini giriyor.

3 – Eğer kimlik bilgisi doğru ise CAS server aşağıdaki iki temel bilgiyi topluyor

a.User’s mailbox version

b.User’s mailbox location (Active Directory site)

Bu bilgiler ışığında ise aşağıdaki gibi durumlar oluşmaktadır

4         – Gelen bilgiler ışığında;

a. Eğer kullanıcı mailbox versiyonu Exchange 2010 ve aynı site içerisinde ise direk mailbox sunucusuna bağlantı gerçekleşir.

b. Eğer kullanıcı mailbox versiyonu 2007 ve aynı site içerisinde ise öncelikle Exchange 2010 CAS server 2007 CAS server’ ın ExternalURL adresini öğrenir, eğer yok ise internal URL adresine silent redirection yapılır.

c. Eğer kullanıcı mailbox versiyonu 2003 ve aynı site içerisinde ise bu durumda istek Exchange2003URL adresine silent redirection yapılır.

Not; Eğer 2003 mimarinizde FE / BE yok ise direk istek BE server’ a gönderilir.

d. Eğer kullanıcı mailbox local değil farklı bir site içerisinde ise hedef site içerisindeki Exchange Server CAS External URL adresine ulaşmaya çalışır, Eğer bu adres tanımlı ise bu istek redirect edilir, eğer tanımlı değil ise proxy görevi görülür.

Exchange 2010 Sp1 ile beraber ise aşağıdaki 3 temel yönlendirme seçeneği gelmiştir.

Manual Redirection

Temporary Manual Redirection

Legacy Silent Redirection

Manual Redirection

Eğer gelen istek farklı bir AD site içerisinde ise bu durumda SP1 öncesi benzer bir durum söz konusu olup bu site için OWA External URL bulunur ve kullanıcı bu alana aşağıdaki gibi bir link ile yönlendirilir.

Burada kullanıcı linke tıklar ve bir kez daha logon olur.

Temporary Manual Redirection

Not: Bu yönlendirmeyi anlamak için öncelikle FailbackURL kousunu incelemenizi öneririm

http://www.cozumpark.com/forums/post/313184.aspx

Bu özellik aslında direk SP1 ile eklenmiş ek bir yönlendirme seçeneğidir. Bu özellik için temel iki senaryo bulunmaktadır.

İlk senaryomuzda eğer bir datacenter activation switchback süreci yaşanmış ise kullanıcı browser cache inde hala eski ip adresi kaldığı için mailbox’ I aktif olmayan bir site üzerindeki CAS server adresine yönleneceği için buradaki CAS kullanıcıyı mailbox’ ı aktif olduğu site içerisindeki CAS server’a “manual redirect” edecektir. Ancak kullanıcı cache’ inde hala o adres için eski ip olduğundan kullanıcı aslında tekrar logon olduğu OWA sayfasına dönecektir. Bu ikinci dönüş web canary özelliği sayesinde çerezler üzerinden tespit edilecek ve kullanıcı hedef CAS server’ ın failbackurl adresine yönlendirilecektir.

Ancak hedef CAS için bir FailbackURL adresi yok ise OWA logon sayfası hata verecektir.

İkinci senaryo ise, benzer şekilde farklı site’ lar bulunmaktadır. Yine bir kullanıcı “A site” içerisinde mailbox mount durumunda iken “B site” CAS server’ a logon olmak ister ve bu CAS “A site” içerisindeki mailbox veri tabanının özel tanımlanmış bir “RpcClientAccessServer” adresi var ise bu durumda yine Temporary Manual Redirection süreci başlar. Bu değer bir CAS server’ I işaret eder ve sistemde bu CAS server’ ın ExternalURL adresine yönlendirme yapar.

Legacy Silent Redirection

Ortamda eski sürüm Exchange rollerinin olduğu durumlarda CAS sunucularının yönlendirme seçenekleri aşağıdaki gibidir

Exchange 2007 Posta kutularına erşimek için bir kullanıcı Exchange 2010 CAS sunucusuna gelirse ve bu posta kutusu bu CAS 2010 ile aynı site içerisinde ise bu istek CAS 2007 sunucusuna silent redirection yapılır.

Eğer kullanıcı posta kutusu başka bir Internet-facing Active Directory Site içerisinde ise bu durumda CAS 2010, hedef site içerisindeki CAS 2007 te manual redirection yapar.

Eğer kullanıcı posta kutusu 2007 sürümü ve non-internet facing bir AD site içerisinde ise, CAS 2010 bu isteği diğer site içerisindeki 2007 CAS sunucusuna proxy eder.

Son olarak, eğer posta kutusu bir Exchange 2003 sürümü ise önceden tanımlanmış olan “Exchange2003Url” URL adresine silent redirection yapılır.

Bu son senaryo için tek şart aynı site içerisinde olmasıdır.

Özetlemek gerekirse Legacy Silent Redirection sadece aynı site içerisinde çalışmaktadır. Yukarıdaki örneklerde de gördüğünüz gibi eğer farklı bir site işin içine giriyor ise manual redirection veya proxy söz konusudur. Ancak aynı site içerisinde ise Legacy Silent Redirection çalışmaktadır.

Ancak Legacy Silent Redirection çalışması içinde temel iki şart bulunmaktadır.

Eğer yönlendirilecek sistem 2003 ise mutlaka CAS 2010 üzerinde “Exchange2003Url” tanımlı olmalıdır.

Eğer yönlendirilecek sistem 2007 ise mutlaka hedef yaniş 2007 CAS üzerinde ExternalURL tanımlu olmalıdır ( eğer değil ise internalURL kullanılır )

Legacy Silent Redirection aynı zamanda şartların sağlanması durumunda Single Sign-on SSO desteği sunmaktadır. Bu şartlar aslında 2007 ve 2003 tarafındaki sertifika ve FBA ayarlarının düzgün yapılması gerekliliğidir.

Burada sistem 2010 CAS server’a verilen kullanıcı adı, şifre, public veya private seçeneği gibi tüm bilgileri bir form olarak hedef 2007 / 2003 OWA ya yönlendirir, bu bilgiler birebir hedef OWA ya girildiği için tek bir kullanıcı adı ve şifre ile beraber SSO özelliği çalışmış olur. Bu arka tarafta kullanılan form “hidden FBA form” olarak isimlendirilir.

Evet buraya kadar olan süreç sonrası SP2 ile gelen yeni yönlendirme özelliğine geçeceğim ancak bundan önceki süreci aşağıdaki gibi özetlemek istiyorum

Manual redirection yönteminde aşağıdaki adımlar gerçekleşir

1 – Kullanıcı web browser üzerinden yanlış OWA URL adresini yazar

2 – Kullanıcı bu yanlış URL adresi üzerinden kimlik bilgilerini girer

3 – Yanlış site içerisindeki bu CAS server “service discovery” sayesinde kullanıcının posta kutusunun hangi site içerisinde aktif olduğunu bulur.

4 – Bu bilgi ışığında doğru site içerisindeki CAS server URL adresini öğrenir ve bunu kullanıcıya web sayfası üzerinden gösterir.

5 – Kullanıcı bu linkte tıklar ve doğru CAS sunucusu üzerinde tekrar kullanıcı adı şifre bilgisi paylaşır.

6 – Bu sayede kullanıcı posta kutusuna ulaşmış olur ancak bu kullanıcı deneyimi olarak kötü bir sonuçtur. Çünkü kullanıcı posta kutusuna erişmek için iki kez logon olmuştur.

Peki bu temel yönlendirme durumlarını bildiğimize göre gelelim SP2 ile bize sunulan Cross-Site Silent Redirection detaylarına.

Exchange organizasyonunuz site yapısına sahipse ve her site için ayrı CAS sunucularımız var ise aslında bizim birden çok OWA URL adresimiz var demektir. Böyle bir durumda bir kullanıcı yanlışlıkla bulunduğu site ( posta kutusunun bulunduğu site ) yerine başka bir AD site içerisindeki CAS server’ a OWA erişimi için logon olmak isterse bu durumda CAS Server kullanıcıyı doğru site içerisindeki CAS Server’ e yönlendirecektir. Ancak yönlendirilen CAS server ayarlarında OWA için External URL tanımlı değil ise kullanıcı doğrudan posta kutusuna ulaşabilecekken tanımlı bir URL olması durumunda kullanıcı bir kez daha bu URL’ e yönlendirilecek ve ikinci bir logon işlemi gerçekleştirecekti. Bu konuları zaten makalemin başında detaylandırmıştım.

Benim yapımda iki adet AD site bulunmaktadır. Bunlar Antalya ve Rize. Yine her site içerisinde bir HUB- CAS- Mailbox rolü barındıran Exchange Server bulunmaktadır.

Böyle bir yapıda OWA virtual directory bilgileri aşağıdaki gibidir.

Get-OwaVirtualDirectory |fl Servername,InternalURL,ExternalURL,OriginatingServer,CrossSiteRedirectedType

Görüldüğü gibi iki ayrı URL bulunmaktadır. Her iki CAS Server içinde “CrossSiteRedirectType” Manual olarak ayarlıdır.

Şimdi bu durumu test edelim.

Öncelikle Hakan kullanıcısının posta kutusunun hangi mailbox da tutulduğuna bakalım

Hakan kullanıcısının posta kusutu “Antalya” ismindeki bir Mailbox veri tabanında bulunuyormuş. Şimdi bu veri tabanının hangi mailbox server üzerinde tutulduğuna bakalım

Antalya mailbox veri tabanı “EXCH2010SP2” isimli mailbox sunucusunda tutuluyor ve son olarak bu sunucunun hangi site içerisinde olduğuna bakalım

EXCH2010SP2 sunucusu Antalya, EXCH2010SP2RIZE ise Rize site içerisindedir.

Hakan kullanıcısı ( hakanuzuner ) posta kutusu Antalya site içerisindeki mailbox sunucusunda bulunmaktadır. Bu nedenle Hakan kullanıcısı adres olarak aşağıdaki URL’ i kullanmaktadır

https://antalya.cozumpark.com

Daha sonra açılan ekranda kimlik bilgilerini vererek aşağıdaki gibi posta kutusuna ulaşabilmektedir.

Peki Hakan kullanıcısı çok büyük bir şirkette çalışıyor ve kendi posta kutusunun hangi site içerisinde olduğunu bilmiyor veya site ismini biliyor olsa bile URL adresini bilmiyor olabilir. Bu durumda generik olan mail.cozumpark.com gibi bir adres kullanabileceği gibi aşağıda olduğu gibi farklı bir site adreside kullanıyor olabilir.

Yukarıda görüldüğü gibi Antalya site içerisinde posta kutusu olan Hakan yanlışlıkla Rize URL adresini yazıyor ve logon olmak istediği zaman ona aşağıdaki gibi bir uyarı çıkıyor

Yönlendirme ayarını hatırlayacak olursanız “Manual” olduğu için kullanıcı bu linke tıklamalı ve bir kez daha logon işlemini gerçekleştirmelidir.

Görüldüğü gibi adres otomatik olarak Antalya dönmekte ancak bizden bir kez daha kimlik bilgisi istemektedir.

SP2 ile beraber gelen Cross-Site Silent Redirection özelliği sayesinde aşağıdaki gibi bir PowerShell ile bu işlemin kullanıcıya sorulmadan ve ek bir kimlik bilgisi istenmeden gerçekleşmesini sağlayabiliyoruz.

Set-OWAVirtualDirectory -Identity "EXCH2010SP2\owa (Default Web site)" -CrossSiteRedirectType Silent

Set-OWAVirtualDirectory -Identity "EXCH2010SP2RIZE\owa (Default Web site)" -CrossSiteRedirectType Silent

Not ; Bu değişikliğin olması için mutlaka sahip olduğunuz sitelardaki CAS Serverların OWA dizinlerinde External URL tanımlı olmalıdır.

Bu değişiklik sonrası artık hangi site URL adresini kullanırsanız kullanın yönlendirme işlemi otomatik olarak gerçekleşecek ve siz https://antalya.cozumpark.com adresine logon olduğunuzda posta kutunuza erişecek ancak adresin https://rize.cozumpark.com’ a döndüğünü fark edeceksiniz.

Bu son bölümüde toparlamak gerekirse.

Kullanıcı CAS sunucusuna logon olduktan sonraki süreç aşağıdaki gibi özetlenebilir;

Kullanıcı logon olduktan sonra ilk olarak kullanıcınsını mailbox versiyonu kontrol edilir. Yani 2007 mi yoksa 2010 mu olduğu.

Ardından bu posta kutusunun nerede aktif olduğuna bakılır ( hangi site içerisinde mount olduğuna )

Daha sonra bu aktif olan site içerisindeki CAS için ErternalURL adresi tespit edilir.

Daha sonra ise bu istek yönlendirilir. Eğer OWA ayarlarında “CrossSiteRedirectType=Manual” şeklinde ise bu yönlendirme manual redirection şeklinde yapılır. Yani kullanıcıya bir link verilir ve kullanıcı tıklayarak ikinci kez logon bilgisi girer.

Eğer “CrossSiteRedirectType=Silent” şeklinde ayar yapılmış ise kullanıcı otomatik olarak mailbox sunucusuna erişir. Çünkü CAS yönlendirmesi otomatik olur ve SSO desteğide olduğu için ikinci bir logon isteği olmayacaktır ( Bunun için kaynak ve hedef CAS üzerinde FBA açık olmalıdır. Eğer değil ise 302 yönlendirme hatasını alırsınız ).

Ayrıca SSO için ek birkaç bilgi paylaşmak istiyorum.

Aşağıdaki durumlarda SSO özelliği devre dışı kalacaktır

1 – OWA Virtual Directory üzerinde Basic Authentication kullanmanız durumunda

2 – Kaynak ve hedef OWA üzerinde farklı kimlik doğrulama ayarlarının olması durumunda

3 – Kaynak veya hedef OWA üzerinde two-factor kimlik doğrulama uygulamalarının olması durumunda

4 – OWA logon işleminden önce bir logon sürecinden geçtiğinizi durumlarda. Örneğin her iki OWA’ nın Microsoft Threat Management Gateway 2010 üzerinde farklı listener’ lar üzerinden publish edilmesi durumunda.

5 – Local bir CAS sunucusunun farklı bir AD site içerisindeki CAS sunucusuna Temporary Manual Redirection yapması durumunda.

Evet bu makalemizinde sonuna geldik. Son derece detaylı anlatmaya çalıştığım bu makale umarım sizler için yararlı olmuştur.

Bir sonraki makalemizde görüşmek üzere esen kalın.

Exchange Server 2010 sürümü diğer pek çok Microsoft ürününde olduğu gibi bir önceki nesil ürüne göre çok fazla yenilik içermektedir. Gerek SP1 ve SP2 ile beraber gelen özellikler olsun gerekse ürün ile beraber gelen özellikler konusunda çok fazla paylaşım yaptık ve bunları makale bölümündeki makalelerden takip edebilirsiniz. Ancak bu yenilikleri incelediğiniz zaman aslında en çok geliştirilen konuların başında “Yüksek Erişilebilirlik” yani “HA” konusu gelmektedir. Belki “DAG” çok konuşuldu çok yazılıp çizildiği için hep ön plana çıktı ama aslında DAG mimarisinin sağlıklı çalışması için arka planda çok fazla özellik ona destek vermektedir.

Bu makalemde benim anlatacağım konu olan OWA FailBackURL ilk bakıldığında bir OWA özelliği gibi gelsede aslında yine bu özellikte DAG mimarisini destektedir.

Nedir OWA FailBackURL? Temelde Exchange Server site’ larından birinin komple down olması ve bir süre sonra tekrar bu site’ ın ayağa kaldırılması durumunda son kullanıcıların OWA ile mailboxlarına en doğru site üzerinden ulaşmasına yardımcı olan bir özelliktir. Tatbiki böyle yazınca karışık ve anlamsız gelebilir ama ben bunu gerçek bir hayat senaryosu ile anlatacağım.

Örneğin iki site bulunan bir şirket organizasyonunu düşünelim.

Bu sitelerdan birisi "Merkez" diğeri ise "Rize" olsun. OWA URL adresleri ise aşağıdaki gibidir.

Merkez Site için OWA ExternalURL adresi: https://mail.cozumpark.com/owa

Rize Site için OWA ExternalURL adresi: https://mail.rize.cozumpark.com/owa

Merkez Site için FailbackURL adresi: https://failback.cozumpark.com/owa

Rize Site için FailbackURL adresi: https://failback.rize.cozumpark.com/owa

Senaryo gereği eğer Merkez site komple down olması durumunda mail.cozumpark.com dns kaydına karşılık gelen IP adresini mail.rize.cozumpark.com IP adresi ile aynı yapıyoruz. Bu sayede bu adrese gelen istekler rize site üzerindeki CAS sunucuları tarafından karşılanmaktadır. CAS Server redirection veya proxy özelliğini biliyorsanız eğer zaten rize içerisindeki CAS Server’ a login olan bir kullanıcı ki bu merkez site içerisinde ise bu istek Merkez site içerisindeki CAS sunucusuna yönlendirilmesi gerekli idi. Ancak DAG mimarisi gereği artık Merkez site içerisindeki tüm mailbox db leri dismount konumunda olduğu için bu mailbox db leri rize site içerisinde mount konumuna getirilmiştir. Bu nedenle merkezdeki kullanıcılar rize cas server üzerinden rahatça login olabileceklerdir.

Bu konu hakkında detaylı bilgi için aşağıdaki makaleyi okumanızı öneririm;

http://www.cozumpark.com/blogs/exchangeserver/archive/2012/03/18/owa-proxy-redirection-ve-cross-site-silent-redirection-for-outlook-web-app.aspx

Bir kaç gün aradan sonra merkez site tekrar ayağa kalktığından ve

kesintisiz çalıştığından emin olduktan sonra tekrar mail.cozumpark.com adresi için dns üzerinde eski ip adresini gösterebiliriz. Ancak bu süreçte hala dns cache nedeni ile bu adrese gitmek isteyen ancak aslen posta kutusu merkez site içerisindeki bir mailbox server üzerinde tutulan bir kullanıcı login olmaya çalışırsa eğer OWA üzerinden redirection yapılacaktır. Uyarı ise aşağıdaki gibi olacaktır.

Şimdi buradaki durum şudur, kullanıcı mailbox aslen merkez site içerisinde aktif durumdadır, çünkü sorun giderilmiş ve merkez site ayağa kalkmıştır. Ancak sorun nedeni ile mail.cozumpark.com adresi için dns üzerindeki ip adresi mail.rize.cozumpark.com ismine karşılık gelen ip adresine yönlendirilmiş ve bu istemcide hala dns cache yüzünden bu adrese gitmektedir. Rize üzerindeki CAS’ da kullanıcıya yukarıdaki gibi bir uyarı çıkarmaktadır. Çünkü Rize üzerindeki CAS bu gelen kullanıcı mailbox’ ının merkez site üzerinde olduğunu görüyor ve ona daha iyi bir performans için bu linki kullanmasını öneriyor. Sorun ise kullanıcı yani bu teknik detaylardan uzak olan son kullanıcı zaten adres çubuğuna mail.cozumpark.com yazmıştı J doğal olarak kullanıcıda biraz şaşırıyor. Bir kez daha bu adrese tıklıyor ancak nasıl ilk seferinde dns cache hala Rize ip adresini gösteriyor ise bu adres için şu anda da o cache devrede ve aslında yine Rize CAS sunucusuna logon oluyor, ancak bu ikinci logon isteği sistem tarafından farklı yorumlanmaktadır ( bunu web canary özelliği ile yani çerezler üzerindeki bilgilerden anlamaktadır ). Bu ikinci logon isteğinden sonra sistem kullanıcı cache sorunu olduğunu anlıyor ve kullanıcı karşısına çıkan ekranda sadece “Continue” diyerek FailbackURL adresine yönlendiriliyor. Tabiki kullanıcı bu durumda 3. Kez login oluyor ve artık posta kutusuna erişebiliyor.

İşte FailbackURL adresinin tanımlanması bu gibi bir senaryoda kullanıcıların posta kutularına erişmelerinde büyük önem taşımaktadır. Baktığınız zaman ince bir konu ve günlük hayatta belki pek çok şirket tarafından kullanılmaz, ancak banka, telko, gsm gibi büyük organizasyonları yönetiyor veya bunlara danışmanlık veriyorsanız bu tür ince konuları biliyor veya kullanıyor olmanız gerekmektedir.

Umarım faydalı bir makale olmuştur.

Bir sonraki makalemde görüşmek dileği ile esen kalın.

Bu makalemde sizlere Microsoft tarafından 4 Aralık 2011 tarihinde yayınlanan Exchange Server 2010 SP2 ile beraber gelen yenilikleri anlatacağım.

Exchange Server ile ilgili pek çok kaynak paylaşımında bulunduğumuz için bu konudaki genel bilgiler için ÇözümPark Bilişim Portalı üzerindeki makaleleri okumanızı tavsiye ederim.

İlk olarak Exchange Server 2010 SP2’yi aşağıdaki adresten indirelim.

http://www.microsoft.com/download/en/details.aspx?id=28190

Kurulumda ise aşağıdaki sıralamaya dikkat etmeniz gerekmektedir.

·         Client Access Servers

·         Hub Transport Servers

·         Unified Messaging Servers

·         Mailbox Servers

·         Edge Transport Servers

Eğer birden çok rol tek bir server üzerinde yüklü ise bu durumda sıralama bir önem taşımamaktadır. Örneğin HUB – CAS bir server, Mailbox bir server ise HUB-CAS için ilk yükleme sonrasında Mailbox server için yükleme yapabilirsiniz.

Yüklemeye başlamadan önce ise alışık olmadığımız bir durum ile karşı karşıya olduğumuzu belirtmek isterim. Malum SP’ ler genelde sunucu tarafında rol veya özellik istememekteydi ancak Exchange Server SP2 CAS server rolü üzerindeki yükleme için IIS’ in “IIS 6 WMI Compatibility” bileşenini istemektedir.

Eğer bu yüklemeyi yapmazsanız aşağıdaki gibi bir hata alıyorsunuz.

Bunun için CAS Server rolü yüklemesinden önce ilk olarak aşağıdaki şekilde bu bileşeni ekliyoruz.

PowerShell konsolunda aşağıdaki iki komutu kullanıyoruz.

Import-Module ServerManager

Add-WindowsFeature Web-WMI

Bu yüklemeden sonra standart bir SP yüklemesi gibi devam edebiliriz.

Kurulum sonrasında ise aşağıdaki powershell komutu ile versiyon bilgisini kontrol edebiliriz

Exchange Management Shell içerisinde aşağıdaki komutu çalıştırıyoruz.

GCM exsetup |%{$_.Fileversioninfo}

Tüm sürümler için versiyon bilgisi için aşağıdaki linki kullanabilirsiniz.

http://social.technet.microsoft.com/wiki/contents/articles/240.exchange-server-and-update-rollups-builds-numbers.aspx

Bizim versiyonumuz 14.01.0339.001 yani Exchange 2010 SP2.

Evet temiz bir yükleme sonrası yeni gelen özellikleri inceleyebiliriz.

·         Hybrid Configuration Wizard

·         Address Book Policies

·         Cross-Site Silent Redirection for Outlook Web App

·         Mobile Web App (Owa Mini)

·         Mailbox Replication Service

·         Mailbox Auto Mapping

·         Multi-Valued Custom Attributes

·         Litigation (Legal) Hold

Hybrid Configuration Wizard

Microsoft’ un bulut bilişim tabanlı bir çözümü olan office 365 ile ortak çalışma noktasındaki iyileştirmelerden biridir. Exchange 2010 RTM ve SP1 yardımı ile organizasyonumuzdaki posta kutularının bir bölümünü on-premises yani yerleşik sistemlerde tutarken bir bölümünüde office 365 online posta kutularında tutabiliyorduk. Bu yapıyı kurmak için SP2 öncesinde powershell üzerinden bir hayli zor bir yöntem ile oluşturduğumuz fedarasyon yapısını kullanıyorduk. Ancak SP2 ile beraber artık bu ortak kullanım son derece kolay bir hal almıştır. Arayüze gelen yeni bir sibirbaz sayesinde kolaylıkla bu entegrasyonu yapabiliyoruz.

Peki süreç nasıl işliyor ?

Öncelikle EMC üzerinde HCW çalıştırdığınız zaman ilk olarak Active Directory üzerinde “HybridConfiguration” objesi oluşturulmaktadır. Bu obje ise bu konfigürasyon ile ilgili bilgileri saklamaktadır. Ve yine konsol üzerinden “Manage Hybrid Configuration wizard” yardımı ile bu bilgiler değiştirilebilir.

Address Book Policies :

Dağınık mimarilere sahip Exchange organizasyonları için önemli bir yeniliktir. Bölge, şube, ekip veya birim bazlı ayrı adres defteri kullanmak veya görmek isteyen servisler için Address Book Policy ABP bizlere yardımcı olacaktır. Aslında ABP’ nin yaptığı işlem “Global address list (GAL) segmentation” veya “GAL segregation” da olarak bilinen herkes için tek olan ve tüm şirket çalışanlarını gösteren bu adres defterini segmentlere ayrımaya yarar.

Bu işlemi tabiki Exchange 2007’ den beri yapabiliyorduk ancak bu işlem için Query Base DN veya access control lists (ACLs) kullanıyorduk ve bu da bir hayli zor bir yöntemdi. Şimdi ise ABP ile bunu kolaylıkla yapabilmekteyiz.

Ancak ABP kullanmak için bazı şartlar bulunmaktadır.

Öncelikle bu özelliği kullanmak isteyen kullanıcı mailbox’ ları Exchange 2010 SP2 yüklü bir mailbox sunucularında barındırılıyor olmak zorundadır.

Ayrıca ABP kullanmak istiyorsak Hierarchical Address Book (HAB) özelliği devre dışı olmalıdır. Son limitasyon ise Exchange Server GC olan bir DC üzerinde yüklü ise bu özellik kullanılamaz.

Not ; Outlook for Mac ve Entourage LDAP erişimleri olmayan ürünler olduğu için bu özelliği kullanamamaktadır. Çünkü şirket networklerine bağlık bu iki yazılım Microsoft Exchange Address Book service yerine direk olarak Global Catalog üzerinden Active Directory’ ye sorgu yapmaktadır. Fakat Outlook for Mac 2011 eğer internet üzerinden bağlantı kuruyor ise OAB veya Exchange Web Services (EWS) lerine bağlanabildiği için kendisine atanan ABP’ leri GAL bazlı olarak alabilmektedir.

Not ; ABP office 365 üzerinde çalışmamaktadır. Bu nedenle hybrid bir deployment yapmanız halinde office 365 üzerindeki kullanıcılarınız tüm adres defterini segmentlere ayrılmamış olarak yani varsayılan biçimde görecektir.

Bu konuda daha fazla bilgi için aşağıdaki makaleyi inceleyebilirsiniz.

Exchange Server 2010 Address Book Policy

Cross-Site Silent Redirection for Outlook Web App

Bu özellik içinde hazırlanmış detaylı bir makalem bulunmakta olup yeni gelen bu özelliğin detayları için aşağıdaki makaleyi okumanızı öneririm.

OWA Proxy-Redirection ve Cross-Site Silent Redirection for Outlook Web App

Mobile Web App (Owa Mini)

Aslında Exchange Server 2003 sürümünde Outlook Mobile Access OMA olarak kullandığımız ve Excange Server 2007 sürümü ile kaldırılan bu özelliğe geri dönüş söz konusudur. Bunun temel sebebi uzak doğru ülkelerinde halen yaygın olarak kullanılan ve active sync desteği olmayan telefonların mail ihtiyaçları yüzünden SP2 sürümünde bu özellik “Mobile Web App” ismi ile geri dönmüştür.

Bu özelliğin kullanılabilmesi için CAS üzerinde IIS 6 WMI Compatibility özelliğinin kurulması gerekmektedir.

https://mail.cozumpark.com/owa/oma

Adresi ile ulaştığımız Mobile Web App kimlik doğrulama sonrasında posta kutumuza erişim sağlamaktadır.

Eğer OWA mini’ ye giriş yaptıktan sonra aşağıdaki gibi bir hata alıyorsanız .

Bunun sebebi henüz posta kutusu oluşmamış yani ne OWA nede Outlook üzerinden Exchange Server’ a hiç bağlanmamış bir kullanıcı ile logon olmaya çalışıyorsunuz demektir.

Peki OMA ile bize sunulan özellikler nelerdir bunlara bakacak olursak bu liste aşağıdaki gibidir.

E-posta, takvim, kişiler, görevler ve GAL’e erişim

Alt klasörler dahil tüm e-postalara erişim

Yeni e-posta oluşturma, ilet ve yanıtlama yapılması

Takvim, kişi ve görev oluşturma ve düzenleme

Toplantı isteği gönderme

Out of Office) ve Time Zone ayarlamaları yapılabilir.

Bir detay bilgide OMA kodlarının Exchange Server 2010 için baştan yazılmış olmasıdır. Aslında bu gayet normal bir durum olup aklınızda soru işareti kalmasın diye paylaştığım bir bilgidir.

İsterseniz aynı OWA özelliğinin kapatılıp açıldığı gibi OWA mini de kullanıcı veya Virtual Directory bazlı olarak kapatılıp açılabilmektedir. Benzer şekilde OWA için kullanabildiğimiz yasaklamalar ve dil desteği OWA mini için geçerlidir ( Outlook Web App Mailbox Policy ile ).

Kullanıcı bazlı OWA mini yasaklama

Öncelikle bu kullanıcılar için bir Outlook Web App Mailbox Policy oluşturuyoruz.

New-OwaMailboxPolicy -Name ‘OMA_YASAK’

Bu oluşturduğumuz policy üzerinde ise yasaklamak istediğimiz bölümleri seçiyoruz. Benim amacım sadece OWA Mini olduğu için onu yasaklıyorum.

Set-OwaMailboxPolicy OMA_YASAK -OWAMiniEnabled $False

Son olarak istediğimiz kullanıcıları bu policy’ ye bağlıyoruz

Set-CasMailbox -OwaMailboxPolicy ‘OMA_YASAK’ -Identity hakanu

Bundan sonra kullanıcı OWA Mini ye erişmek isterse aşağıdaki gibi bir hata alacaktır.

Policy oluşturma ve oluşturduğunuz bir policy’ yi bir kullanıcıya atama ara yüzde bulunmaktadır. Ancak bu policy içerisinden OWA Mini özelliğini ara yüzden kapatamıyorsunuz.

Yukarıdaki bölümde pek çok alanı kapatabiliyoruz ancak OWA Mini için bir seçenek yoktur.

Virtual Directory bazlı yasaklama komutları ise aşağıdaki gibidir.

Set-OwaVirtualDirectory –Identity “owa (Default Web Site)” –OWAMiniEnabled $False

Bu özelliğin yine Virtual Directory bazlı açılması için ise aşağıdaki komutu kullanabilirsiniz.

Set-OwaVirtualDirectory –Identity “owa (Default Web Site)” –OWAMiniEnabled $True

Mailbox Replication Service

Exchange Server 2010 SP1 bir sistemde forestlar arasında veya Cloud sisteme bir mailbox taşımak isterseniz öncelikle CAS Server Rolü üzerinde MRSProxy özelliğini "Enable" yapmalıyız. Bunun için her bir CAS sunucusu içerisinde bulunan web.config dosyasında elle bir değişiklik yapmak zorundayız.

“C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\exchweb\ews”

Bu dosyanın “MRSProxy” bölümü ile ilgili içeriği ise aşağıdaki gibidir;

<!– Mailbox Replication Proxy Service configuration –>

                <MRSProxyConfiguration

IsEnabled="false"

MaxMRSConnections="100"

DataImportTimeout="00:01:00" />

</configuration>

Oysaki Exchange Server 2010 SP2 ile beraber iki yeni cmdlets gelmiştir. Bunlar aşağıdaki gibidir.

New-WebServicesVirtualDirectory

Set-WebServicesVirtualDirectory

Bu komut setleri sayesinde artık web.config içerisinde MRSProxyEnabled ve MaxMRSProxyConnections değerlerini değiştirmemize gerek yoktur.

Aşağıdaki komut seti ile bu değişikliği yapabilirsiniz.

Set-WebServicesVirtualDirectory -Identity "EWS (Default Web Site)" -MRSProxyEnabled $true -MRSMaxConnections 50

Yukarıdaki komutun açıklaması, Exchange Web Services (EWS) default Web site üzerinde MRSProxy özelliğini açılması ve eş zamanlı olarak maksimum 50 kullanıcının kabul edilmesini sağlar. ( Varsayılan olarak bu değer 100 dür )

Version 14.2 (Build 247.5) versiyonu için komut aşağıdaki gibidir.

Set-WebServicesVirtualDirectory -Identity "EWS (Default Web Site)" -MRSProxyEnabled $true -MRSProxyMaxConnections 50

Mailbox Auto Mapping

Exchange Server 2010 SP1 sistemde, eğer bir posta kutusuna "Full Access permissions" yetkisi verirseniz bu durumunda outlook 2007 veya Outlook 2010 istemciler otomatik olarak bu posta kutusunu kendi hesabınıza bağlar. Bu işlem otomatik olarak gerçekleşmektedir. Aslında ilk baktığınız zaman güzel bir özellik gibi gelebilir. Yani siz başka bir kullanıcı üzerinde tam yetkili olduğunuz zaman ek bir işlem yapmadan bu mailbox içeriği sizin outlook hesabınıza bağlanmaktadır. Ancak sorun birden çok hatta çok sayıda posta kutusu üzerinde tam yetkiye sahip kullanıcıların outlook programlarını açarken yaşadıkları yavaşlık ve hatta kilitlenme sorunudur. Böyle bir durumda her outlook programını açarken yaşanılan bu sorunlar müşteri tarafından Microsoft’ a iletilmiştir. Çok ciddi sayıda gelen şikayetler nedeni ile bu özellik SP2 ile beraber kaldırılmıştır. Yani isterseniz artık tam yetki verdikten sonra eskisi gibi outlook üzerinden elle ekleyebilirsiniz.

SP2 öncesinde ise bu özelliği kapatmak için adsiedit aracı ile "msExchDelegateListLink" özniteliğini değiştirmek gerekiyordu.

Bu öznitelikte hangi hesap var ise o otomatik olarak eklenmekteydi. Eğer boş kalırsa tabiki eklenmiyor

SP2 sonrası ise izin verirken bunu ayarlayabiliyorsunuz.

Add-MailboxPermission SerkanUzuner -User ‘HakanUzuner’ -AccessRights FullAccess -AutoMapping:$false

Yukarıdaki komut ile "SerkanUzuner" kullanıcısı için HakanUzuner kullanıcısına FullAccess izni vermiş oluyoruz.

Multi-Valued Custom Attributes

Exchange Server SP2 ile beraber Mailbox, DistributionGroup, DynamicDistributionGroup, MailContact, MailPublicFolder, RemoteMailbox’ lar için ek özelliklerin barındırılmasını sağlayan yeni 5 adet "multi-value custom attribute" gelmiştir. Bunlar aşağıdaki gibidir.

ExtensionCustomAttribute1

ExtensionCustomAttribute2

ExtensionCustomAttribute3

ExtensionCustomAttribute4

ExtensionCustomAttribute5

Buna bir örnek vermek gerekirse,

Aşağıda bir powershell komutu vardır.

Set-TransportConfig -MaxSendSize 12MB

Bu komut mail gönderim tarafındaki limit değerini 12MB olarak değiştirmektedir. Aslında siz bu komutu çalıştırana kadar burada bir değer vardı, belki 10MB belki 15MB belkide farklı bir değer. Ama artık bunun bir önemi yok çünkü siz mesaj gönderim boyutunu 12MB olarak sınırlamak istediniz ve komutu çalıştırdınız.

Ancak Exchange server yapısında her zaman durum bu kadar basit değildir.

Örneğin bir dağıtım grubunun AD üzerindeki "ManagedBy" attribute ( özniteliği ) için var olan değerleri aşağıdaki powershell komutu ile görebiliriz.

Get-DistributionGroup Muhasebe | Format-List ManagedBy

Bu komut “Muhasebe” isimli dağıtım grubunun yöneticilerini listeler. Çıktı aşağıdaki gibidir;

ManagedBy : {cozumpark.com/Users/Administrator, cozumpark.com/Users/Hasan, cozumpark.com/Users/Hakan Uzuner}

Yukarıdaki çıktı veya şekildende görüldüğü üzere bu grubun 3 farklı yöneticisi bulunmaktadır.

Şimdi amacımız bu grubun yöneticilerine bir ek yapmak. Bunun için aşağıdaki gibi bir komut yazıyorum;

Set-DistributionGroup Muhasebe -ManagedBy Elif

Ancak bunu sonucunda ek olarak "Elif" kullanıcısını eklemek isterken diğerleri silinmiştir.

ManagedBy : {cozumpark.com/Users/elif}

Yukarıdaki şekilde de görüldüğü gibi eski yöneticiler silinmiş ve sadece yönetici olarak Elif kullanıcısı kalmıştır. Gerçi benim eşim olan Elif için bu durum gayet güzel olmalı, tek başına yönetici olmak ama malum dengeyi kurmak lazım bu nedenle var olan bu 3 yönetici yanına 4. Yöneticiyi nasıl ekleyeceğimizi görelim.

Multi-valued özellikler aslında single-valued özellikler gibi kullanılır, ancak powershell içerisinde ekleme veya çıkarma yapmak istediğinizi belirtmek için birkaç tane ek syntax kullanıyoruz.

Eklemek için

@{Add="<value1>", "<value2>", "<value3>"}

Çıkarmak için

@{Remove="<value1>", "<value2>", "<value3>"}

Bizim örneğimiz için powershell’ i düzenlemek gerekirse aşağıdaki gibi olacaktır.

Set-DistributionGroup Sales -ManagedBy @{Add="serkan"}

Bu komutun sonucunda artık bu grubun yöneticilerine Elif’ in yanında Serkan’ da eklenmiştir.

Litigation (Legal) Hold

Aslında bu özellik mevcut olarak kullanılıyordu, ancak SP2 ile beraber Legal Hold özelliğindeki bir açık kapatıldı. Legal Hold’ un mantığı zaten yasal zorunluluklardan dolayı şirket kullanıcı maillerinin belirli bir süre saklanması. Örneğin şirkete gelen ve giden tüm maillerin 10 yıl saklanmasını isteyebilirsiniz. Fakat SP2 öncesi Legal Hold kuralı atanmış bir kullanıcı mailbox disable veya delete işlemlerine tabi tutulabiliyordu. SP2 den sonra ise bunu artık direk olarak yapamıyoruz.

Eğer bu bilgiye rağmen yani yasal zorunluluklara rağmen siz kullanıcı posta kutusunu silmek istiyorsanız ( Örneğin Symantec EV vb başka bir arşiv yazılımı var ise) “IgnoreLegalHold” parametresi yardımı ile disable veya delete işlemlerini yapabiliriz.

Bunun denemesi için öncelikle bir kullanıcıya Legal Hold özelliğini açıyorum.

Set-Mailbox serkan -LitigationHoldEnabled $true

Silme işlemini deniyorum.

Remove-Mailbox serkan

Veya ara yüzdende deneyebilirsiniz.

Fakar parametre kullanıyor olmam halinde aşağıdaki gibi silme işlemini başarılı bir şekilde gerçekleştirebiliyoruz.

remove-mailbox serkan –IgnoreLegalHold

Evet bu son özellik ile birlikte Exchange Server 2010 SP2 yeniliklerine değinmiş olduk.

Umarım faydalı bir makale olmuştur.

Bir sonraki makalemde görüşmek üzere esen kalın.

Makalemizin ilk bölümünde temel anlamda PST Capture aracının amaçlarını, kurulum ve kullanım detaylarını sizlerle paylaşmıştım. Bu bölüm ile ise daha çok teknik özellikler, gelişmiş ayarlar ve NAS üzerinden PST import anlatacağım.

İlk olarak sahip olduğumuz konsol üzerinden Tool – Settings ile başlayalım.

İlk bölüm “Online Connection” bölümüdür ve bu bölümü sahip olduğumuz PST dosyalarının Office 365 veya BPOS ürünlerine import etmek için kimlik doğrulama noktasında kullanıyoruz.

Burada önemli olan bir nokta Server isminin bulunmasıdır. Eğer office 365 kullanıyorsanız OWA’ ya logon olduktan sonra seçenekler sayfasını açıyoruz.

Bu bölümde “POP, IMAP ve SMTP erişimi ayarları” linkine tıkladığımız zaman sunucu ismimiz karşımıza çıkmaktadır.

Sunucu ismi pod51016.outlook.com olarak aşağıdaki bölüme yazıyoruz.

Grant delegate access to this mailbox kutucuğunu işaretlemeniz demek, PST import edeceğiniz tüm posta kutuları için otomatik olarak “Full Access ” izni verilmektedir. Eğer bu kutucuğu işaretlemezseniz öncesinde tüm bu kullanıcılar için ( PST import etmek istediğiniz ) elle bu yetkiyi vermeniz gerekli.

Hemen altındaki son kutucuk ise “The above is an Office 365 server”, Eğer verdiğiniz bilgiler Office 365 hesabı için ise bu kutucuğu işaretlemeniz gerekmektedir. Eğer Exchange Online yani BPOS kullanıyorsanız bu kutucuğu işaretlemiyorsunuz.

Bu ayarlamadan sonra artık isterseniz mevcut PST lerinizi Cloud üzerindeki posta kutularınada import edebilirsiniz.

Bunun için pst dosyalarını buluyoruz ve istediğimiz pst dosyalarını işaretliyoruz.

Bu aşamadan sonra ise artık bu PST leri bulut üzerindeki bir posta kutusuna taşıyoruz.

Bu bölümde Set Mailbox kısmından cloud üzerindeki bir kullanıcıyı buluyor ve import diyerek bu klasötleri bulut üstüne çekiyoruz.

Bu bölümde ise aldığınız PST leri nereye import edeceğinizi seçebiliyorsunuz. Varsayılan olarak Mailbox seçilidir ve size zaten ilk makaleden hatırlayacağınız gibi hangi mailbox’ a import edeceğinizi soruyordu. Ancak bunu yerine varsayılan bu ayarları değiştirme şansına sahipsiniz.

Aynı ekranın alt bölümünde ise import ettiğimiz PST içerisindeki dosya isimleri ile mevcut mailbox içerisinde dosya isimleri olması halinde programın nasıl bir yol izleyeceğini seçebiliyoruz. Ya bu klasör içeriğini var olan klasör içerisine ekler veya yeni bir klasör açarak ismin sonuna numaralı bir son ek ekler.

Bu bölümde Arşiv posta kutularına PST lerin import edilmesini aktifleştirebiliyoruz. Varsayılan olarak bu kapalı gelmektedir. Yani siz PST import etmek için bir hedef kullanıcı seçtiğiniz zaman bu varsayılan olarak o kullanıcının aktif posta kutusu olmaktadır. Ama bu kutucuğu işaretlerseniz bu durumda varsayılan olarak bu PST içeriği arşiv posta kutusuna alınmaktadır.

Eğer seçtiğiniz kullanıcının arşiv posta kutusu yok ise bu durumda araç PST içeriğini varsayılan posta kutusuna ekleyecektir.

Bu bölümde ise mail öğeleri dışındaki diğer öğelerin ( ajanda, kontak, notlar, görevler vb ) import edilip edilmeyeceğini seçebiliyorsunuz. Varsayılan olarak bu araç sadece mail öğelerini almaktadır.

Bu dizin Central Servisin yüklü olduğu yani merkezi sunucumuz üzerindeki bir alandır. Zaten sistem bunun local bir disk olmasını istemektedir. Araç bu alanı PST import ederken geçici olarak kullanmaktadır ve varsayılan olarak 20GB dan büyük bir PST yi import edememekteyiz.

PST import işlemi sırasında oluşabilecek hatalara karşı bir tolerans değeri belirleyebiliyoruz. Varsayılan olarak 30 hataya kadar import işlemi sürecek olup bunun üstüne bir hata alınması durumunda işlem durdurulacaktır. ( 30 dan fazla bozuk yani hatalı mail varsa gibide düşünebilirsiniz )

Bu bölümde ise genel ayarlar yer almaktadır.

İlk olarak sunucunun agent’ lar ile konuştuğu portu değiştirebilirsiniz. Ancak bunu yapmanız halinde kurulu olan agent’ ların bir kez daha kurulması gerekecektir. ( SCCM ile yeniden konfigüre edebilirsiniz, yani illaki kurulum şart değil ancak sonuç olarak tüm agentlardaki bu port bilgisini bir şekilde GPO –SCCM vb değiştirmek gerekecektir. )

Alt bölümde ise konsol için tazeleme zamanı ve en önemlisi agent’ ların hangi sıklıklıa sunucuya gelerek değişiklik olup olmadığını kontrol ettikleri bölümdür. Bu alanı maksimum 24 saat olacak şekilde ayarlayabilirsiniz. ( bu alan için detaylı açıklamayı makalemin ilk bölümünde anlatmıştım )

Evet genel olarak ayarlar bölümünü bitirdik.

Peki bu araç ile başka neler yapabiliyoruz ? Sadece uzak lokasyondaki PST leri değil elinizin altındaki yani bu sunucu üzerindeki PST dosyalarını elle göstererek ( birden çok olabilir ) yine istediğiniz bir posta kutusuna import edebilirsiniz.

Yukarıda görüldüğü gibi PST dosyalarını lokal bilgisayara çektim ve aşağıdaki menü yardımı ile onları ekleyerek istediğim posta kutusuna import edebiliyorum.

Eklenmesi ile outlook aşağıdaki gibi görünmektedir.

Bu tarz yoğun ve çok sayıdaki import işlemini mesai saatleri dışında yapmanızı tavsiye ediyorum. Sahip olduğumuz bu araç sayesinde bu işlemleri zamanlayabiliyoruz.

Arayüz üzerindeki “Set Schedule” butonu yardımı ile bu süreci mesai saatleri dışında otomatik taşınmasını sağlayabiliriz.

Bu aracı bir süre kullanmaya başladıktan sonra aslında yaptığımız tüm işlemlerin ayrı ayrı kayıt edildiğini ve istediğimiz bir anda eklediğimiz bir PST yi önceden yaptığımız bir import işlemine tekrar ekleyebileceğimizi görüyoruz. Yani öncesinde yaptığımız tüm arama ve import işlemlerini liste halinde görmemiz mümkün.

İsterseniz bunların hepsini silme şansına da sahipsiniz.

Bir diğer konu ise PST import işlemi. Malum bundan önceki bölümlerde hep agent yüklü bilgisayarlar üzerinden öncelikle bir arama işlemi yapıyor ve bulduğumuz PST dosyalarını import ediyorduk. Şimdi ise PST dosyalarının yerini biliyor olduğumuzu düşünüyor ve onları direk import edeceğiz.

Örneğin NAS gibi bir cihaz üzerinde veya ortak bir alandaki PST leri import edeceğiz.

Bunun için ilk olarak bir adet “import list” oluşturmamız gerekmektedir.

Eğer bundan önce hiç import list oluşturmadıysanız PST Capture Tool ana panelinde sağ bölümde yukarıdaki gibi “New Import List” kısa yolunu göreceksiniz ve istediğiniz bir ortam için bu listeyi oluşturabilirsiniz.

Ardından açılan pencerede “Add From Folder” düğmesine tıklıyoruz.

Ardından açılan pencereden PST dosyaların olduğu dizine gidiyor ve PST leri seçiyoruz.

Son olarak ise bu PST leri hangi mailboxlara bağlayacak isek onları seçerek toplu import işlemini tamamlamış oluyoruz.

Umarım faydalı bir makale serisi olmuştur.

Bir sonraki makalemde görüşmek dileği ile esen kalın.

Microsoft Outlook Configuration Analyzer Tool, aslında pek çok Exchange uzmanı tarafından bilinen ve kullanılan bir araç olmasına karşın kendisini bu konuda geliştirmek isteyen bilişim gönüllüleri için gözden kaçan ancak onların bu gelişiminde katkı sağlayacağına inandığım bir araçtır. Bu nedenle bu konuda bir makale yazmak istedim. Aslında kendi bloğum üzerinden bir kısa yazı ile aracı tanıtmak istedim ancak hali hazırda bildiğiniz gibi ÇözümPark forumlarında çok fazla Exchange soruları bulunmakta ve bu sorular için referans bir makale yazmak yine bizim işimizi kolaylaştıracaktır.

Gelelim aracın hikayesine, 30 yıldan uzun bir süredir Microsoft Office, Microsoft Outlook ve Microsoft Exchange Server tarafında uzmanlığa sahip olan mühendis ekibi tarafından yazılmış olan OCAT sayesinde Outlook programı ile Exchange server arasındaki bağlantı sorunlarının detaylı bir şekilde tespit edebilmekteyiz. Özetle bu şekilde tarif ettiğim programın detaylarını ise makalemde anlatacağım.

İlk olarak aracı kuralım ve adım adım kullanımını görelim, kurulum için aşağıdaki linki kullanabilirsiniz.

OCAT_Setup.zip

Kurulumdan önce sizlere sistem gereksinimleri listelemek istiyorum.

Supported operating systems:

o   Windows 7

o   Windows Vista Service Pack 2

o   Windows XP Service Pack 3

This download works with the following Microsoft Office programs:

o   Microsoft Office Outlook 2007

o   Microsoft Outlook 2010 (32-bit or 64-bit)

The following minimum version of the Microsoft .NET Framework is required:

o   Microsoft .NET Framework Version 2.0

Yükleme son derece kolay, birkaç adımda tamamlayacağınız bu yükleme aşamasından sonra aşağıdaki dizinden OCAT.exe yi çalıştırabiliriz veya start menüsünde OCAT yazarak hızlıca ulaşabiliriz.

C:\Program Files (x86)\Microsoft OCAT

Karşımıza aşağıdaki gibi bir karşılama ekranı gelmektedir.

Görüldüğü gibi yeni bir tarama, var olan bir taramayı görme veya import etme yada son olarak Microsoft Exchange için hali hazırda kullandığımız bir web sitesi olan Connectivity sitesine bir link bulunmaktadır.

Burada önemli bir nokta OCAT’ ı çalıştırmadan önce mutlaka Outlook programını açmış olmanız gerekmektedir. Eğer Outlook programını açmayı unutursanız OCAT sizi bu konuda aşağıdaki gibi uyaracaktır.

Bende hemen ilk olarak Outlook programımı açıyorum ardından OCAT’ ı çalıştırıyorum ve yeni bir tarama başlatıyorum.

Eğer burada domainde olmayan bir Outlook için Outlook anywhere gibi bir bağlantı yapıyorsanız size tavsiyem testin sağlıklı sonuçlar vermesi için “Show Credentials” ile başlayan oka tıklayıp kullanıcı adı, şifre ve domain bilgisini bu arada verin.

Taramayı başlatıyorum.

Ve taramanın sonuçlarını listeliyorum.

İlk sekme genel olarak bize Outlook programımız hakkında bilgi vermektedir. Bizim için önemli olan bölüm ise sorunların raporlandığı “All issues” sekmesidir.

Yukarıda görüldüğü gibi bende temelde 3 durum söz konusu.

İlk olarak yazılabilir bir Global Catalog olmadığı, ikinci olarak Outlook loglarında bundan önce outlook’ un bir veya birden çok kez crash olduğu ve son olarakta Outlook Secure temp dizininde öksüz objelerin bulunduğu belirtilmiştir. Bu aslında sağlıklı çalışan bir sistemde olası raporlardan biridir.

Bu araç ile ayrıca offline rapor almanız da mümkün. Yani eğer Outlook programınız o anda Exchange Server’ a bağlanamıyor ise bu durumda offline scan yapabilirsiniz.

Bu durumda program sadece Outlook’ un çalıştığı bilgisayar üzerinden, olay günlüklerini, kayıt defteri verilerini, mevcut Outlook dosyalarını ve yüklenmiş güncelleme paketlerini inceleyip sizlere yine detaylı bir rapor sunabilmektedir.

Raporlar bölümü ise bizim uzun yıllardır kullanmakta olduğumuz Exchange BPA’ ile aynı olduğu için uzun uzun detaylandırmıyorum ancak aşağıdaki gibi temel özelliklerinden bahsetmek istiyorum

Öncelikle OCAT arasını açtıktan sonra aşağıdaki gibi mevcut raporları görebiliriz.

Veya yine “Select a Configuration scan to view” bölümündeki sağ üst köşedeki “Import scan” linki yardımı ile başka bir bilgisayardaki taranmış ve aşağıdaki bölümden export edilmiş raporları alabiliyoruz.

Mevcut bir raporu görüntülemek için üzerine tıklıyoruz.

Açılan menüden “View a report of this scan” diyerek raporu görüntüleyebiliyoruz.

Bu rapor içerisinde eğer bir konu hakkında detay istiyorsak arama menüsünü kullanabiliyoruz.

Örneğin ben adres defteri ile ilgili bir bilgi arıyordum ve bunu hızlı bir şekilde buldum.

Evet özetlemek gerekir ise özellikle sorun çözümlerinde sıklıkla kullanabileceğimiz bir araç olan OCAT ile sorunsuz Outlook – Exchange bağlantıları diliyorum.

Bir sonraki yazımda görüşmek dileği ile…

Performans tabiki başlı başına bir konu, ancak hep bu şekilde yaklaşıldığı için genellikle en az kaynak bulunan konular performans ve sorun çözümüdür. Bende eğer sonunu getirebilirsem çok güzel bir makale serisine başladığımı düşünüyorum.

Konumuz çok net, MTA noktasında çok yüksek bir pazar payına sahip olan Exchange Server 2010 için yaşanan pek çok yönetim zorluğunun yanında büyük organizasyonlarda ek olarak performans sorunları da gözlemlenmektedir. Malum küçük yapılarda temel olarak satın alması yapılan sunucular Exchange server mimarisine hizmet etmek için yerli iken, 500, 1000 veya 5000 üstü kullanıcısı olan kurumlar için çok ciddi sunucu alt yapılarının tasarlanması gerekmektedir.

Her ne kadar bu şekilde bir alt yapı tasarlanmış olsa da bu tür büyük yapılarda ani veya uzun süreli performans sorunları yaşanabilmektedir.

Aslında bu performans problemleri daha çok istemci tarafında yani outlook yazılımlarının direkt olarak exchange server üzerinden çalıştığı senaryolarda gözlemlenmektedir ( online mode ).

Online mode olarak isimlendirdiğimiz bu mode ciddi manada sistem kaynağı kullanan bir çözümdür. Bunun temel sebebi her bir outlook istemci programındaki hareket ( mail okuma, silme, değiştirme, taşıma vb ) aslında direkt olarak Exchange Server mailbox sunucularının diskleri üzerinde I/O yapmaktadır. Oysaki cache mode kullandığınız zaman bu tüm hareketler kullanıcı lokal disklerinde olup kısa gecikmeler ile bu tüm hareketler exchange server üzerindeki kullanıcı posta kutusu ile replike olur.

Yukarıdaki resimde cache mode çalışacak şekilde ayarlanmış bir outlook programını görüyoruz.

Eğer terminal server gibi bir yapı kullanıyorsanız cache mode kullanmanız bir hayli zor olacaktır. Bu zorluğun en temel kaynağı bir sunucuya 50, 100 belki 250 kullanıcı bağlanacak ve hepsinin ortalama 1GB lık posta kutusu olsa cache mode nedeni ile 250GB lık disk kullanımı olacaktır. Dahası bu disk kullanımı işletim sistemi performansına da yansıyacaktır. Ek olarak Load balance cihazları ile yönetilen bir RDS sisteminde yine keza cache mode sorun teşkil edecektir.

Bu nedenle bu ve benzeri durumlarda cache mode yerine online mode kullanmak zorunda olabilirsiniz. Durum böyle olunca zaman zaman kullanıcılardan outlook ların yavaş çalıştığına dair geri dönüşler alabilirsiniz. Eğer sadece Exchange Server’ a özel bir storage mimariniz yok ise bu muhtemel disk sorunlarıdır. Ancak her zaman disk sorunu demek doğru olmaz. Genel olarak bu şekilde yorum yapmamın sebebi aşağıdaki gibi bir kullanım alışkanlığımızın olmasıdır.

1 Fiziksel server üzerindeki lokal disklerde kurulu sanal makine içindeki exchange server’ ın sanal disklerinde mailbox data base açtığımız için

1 fiziksel server üzerindeki lokal disklerde kurulu exchange server içerisinde mailbox database açtığımız için

1 fiziksel server üzerindeki RAID yapılı lokal disklerde kurulu exchange server içerisinde mailbox database açtığımız için

1 veya daha fazla fiziksel sunucuya bağlı ortak ( file server, portal, exchange, sql, backup vb ) storage diskleri üzerinde mailbox database açtığımız için

En doğru ve ideali ise tabiki maliyetli bir durum, birden çok exchange server mailbox role yükleyip, bunlara sadece exchange server için dedike edilmiş bir storage bağlamaktır.

Durum bu olsa bile yinede bu yavaşlık noktasında kontrol etmeniz gereken noktaları iyi biliyor olmanız gerekmektedir.

Performans problemleri temel iki nedenden ortaya çıkmaktadır

1 – Beklenmeyen yükler

2 – Sistem kaynaklarındaki Darboğazlar

Beklenmeyen yüklerden kastımız, örneğin gün içerisinde posta kutularının arşivlenmesi, yine gün içerisinde yedek alınması, gün içerisinde kullanıcı posta kutularının taşınması, yani aslında gün içerisindeki rutin yoğunluğun dışında ek olarak sistemlere getirecek her yük beklenmeyen yük ve performans problemi olarak görülebilir. Net bir örnek vermek gerekir ise, arşivleme için Symantec EV programını kullandığınızı düşünün, rutin bir şekilde çalışan bu sistem birden yönetici tarafından rapor alınmak için kullanılabilir. Yani tüm posta kutularındaki arşiv yüzdesi nedir diye bir rapor çekmeniz demek her bir posta kutusuna bağlanıp boş alan ve kota bilgisinin kontrol edilmesi demektir. Bu da size performans problemi olarak dönebilir.

Diğer başlık ise mevcut sistem kaynaklarınızdaki dar boğaz. Örneğin sahip olduğunuz üzerinde yüklü olan bir backup, log yönetimi, izleme programları ve benzeri bir agent’ ın aniden aşırı ram veya başka bir sistem kaynağı kullanması ile mevcut exchange hizmetlerinde performans yaşanacaktır. Veya gündüz yedek alınması disklere iki kat yük bindireceği için, veya ortak bir storage kullanıyorsanız bu storage üzerindeki diğer sistemlerin anormal bir şekilde disk kullanımı ve benzeri mevcut kaynaklardaki dar boğaz performans sorunlarına neden olacaktır.

Burada çözüm için eğer ortamınızda SCOM ürünü var ise bunun üzerinden rapor almanız mümkündür.

Bu işin biraz kolay yanı, ancak taktir edersiniz ki her şirket ortamında SCOM veya benzeri bir monitoring yazılımı bulamayabiliriz.

Bu durumda biz Windows Server tarafından bize sunulan performans counter ları ile çözüm yolunu bulmamız gerekmektedir.

İlk olarak Exchange Server istemci tarafında bir yavaşlık söz konusu ise, ben ilk olarak aşağıdaki counter’ ı kontrol ederim

MSExchangeIS Client (*)\RPC Average Latency

Sunucu için RPC isteklerindeki gecikme değerini ms olarak gösterir. Bu değer son 1024 paket içerisindeki geçikme süresinin ortalamasını ms cinsinden gösterir. Bu her bir istemci için 50ms den düşük olmalıdır. Bu süre sunucuya gelen bir isteğin store.exe tarafından işlenip cevap dönülmesi için geçen süredir. Ancak burada önemli olan bu sürenin network gecikmeleri ile ilgili bir bilgi içermiyor olmasıdır. Bunu yazmamın sebebi latency yani gecikme kavramı network tarafında çok kullanıldığı için öyle yanlış bir algı oluşuyor bu süre tam olarak yukarıda yazdığım gibi “sunucuya gelen bir isteğin store.exe tarafından işlenip cevap dönülmesi için geçen süredir” tabiki son 1024 paket için ortalama bir değer verir.

MSExchangeIS Client\ RPC Average Latency

All instances seçmemin sebebi tüm mailbox veri tabanları için ortak bir değer öğrenmek istememdir.

Yukarıdaki şekilde kırmızı ile işaretlediğim counter benim için kritik bir counter olup istemcilerin outlook programlarının yavaş cevap almalarının temel sebebidir.

Tabiki bu değer 90 iken aslında çok ciddi sorunlar yaşamazsınız. Her ne kadar 50ms değerinden bahsediyorsak bile bunu aslında aşağıdaki gibi bir tablosu bulunmaktadır.

500 Kullanıcıdan az olan ortamlarda bu değer 15ms den düşük olmalı

500 – 3000 kullanıcı arasındaki ortamlarda bu değer 30ms den düşük olmalı

3000 ve üzeri için ise 50ms den düşük olmalıdır.

Bu değer 100ms ve üzerinde ise bu durumda outlook programında istemci tarafında aşağıdaki gibi bir pop-up çıkacaktır.

Bu da kullanıcıların mail okumalarını, işlemelerini ve benzeri operasyonlarını ciddi manada etkileyecektir.

Burada bir önemli noktayı daha sizlerle paylaşmak istiyorum. RPC Average Latency bazen yanıltıcı değerler sunmaktadır. Eğer istemcileriniz online mode kullanıyorsa ve çok büyük boyutlu posta kutularında son derece kompleks aramalar yapıyorlar ise bu durumda geçici olarak counter değeri yüksek çıkar. Ancak bu genel bir sorun olduğu anlamına gelmez. RPC değeri uzun bir süre örneğin yarım saat boyunca yüksek çıkıyor ise bu durumda sebeplerini kontrol etmeliyiz. Ancak anlık pikler için aksiyon almaya gerek yoktur.

Bu tür kullanıcı aksiyonlarından doğacak ve geçici olan değerleri görmezden gelebilirsiniz.

Peki gelelim bunun nedenlerine. Yani kullanıcılardan bir isyan noktasına gelen dönüşler almaya başladınız. Hemen counterları kontrol ettiniz ve RPC Average Latency değerinin 150ms lerde dolaştığını gördünüz. Bu durumda ne yapmalı?

Yukarıda bahsettiğim gibi iki ana sebep ile böyle bir sorun yaşıyorsunuzdur

1 – Beklenmeyen yükler

2 – Sistem kaynaklarındaki Darboğazlar

Yük noktasını kesinleştirmek için size tavsiyem PAL aracını en az yarım gün veya iş çok kritik ise en azından bir yarım saat çalıştırın ve rapor alın. Rapor size zaten son derece net bilgiler verecektir.

Örnek bir kaç tane rapor görüntüsü paylaşıyorum ( PAL için detaya girmedim çünkü bu konuda yazılmış bir makale hali hazırda portalımızda var ve bende yukarıdaki Sözlük linki içerisinde bunun olduğunu bildiğim için ek olarak burada paylaşmıyorum. )

Yukarıda da görüldüğü gibi son derece detaylı raporlar sunmakta olup disk okuma yazma hızları başta olmak üzere, CPU, RAM ve benzeri tüm kaynakların raporunu sunmaktadır. Bu rapor size aşırı bir yük mü yoksa sistem tarafındaki bir dar boğaz mı olduğunu gösterir.

Örneğin yukarıda örnek raporlarını paylaştığım sunucu için durum ciddi manada disk yetersizliği gibi görünmektedir.

Bu durum eğer uzun süre devam ediyor ise yeni bir disk kümesi, yeni bir LUN veya yeni bir storage mimarisine geçmeniz gerekmektedir. Veya mevcut bir sunucu üzerinde ise tüm mailbox veri tabanları bunu ek bir sunucu + storage ile ikiye bölebilirsiniz.

Evet, makalemin bu ilk bölümünde genel olarak istemci tarafındaki bağlantı sorunlarına değinmeye çalıştım. Malum söz konusu Exchange server olunca yazacak, anlatacak çok şey var ama bende zamanımın ve tecrübemin el verdiği ölçüde makalenin ilk bölümünü tamamladım. Bir sonraki bölümde görüşmek üzere.