Detaylar

http://egitim.cozumpark.com/index.php/exchange-server-2013-egitimi.html

Özellikle Exchange Server, Lync ve benzeri ürünlere sahip şirketlerin karşılaştığı SAN sertifika taleplerinde 31 Ekim 2015 itibari ile internal domain yazmamız mümkün olmayacak.

Malum kullanıcılarımıza sunduğumuz hizmetlerde birden fazla end point yani URL adresi olması durumunda tek bir Web Server sertifikası – SSL yetmiyordu. Çünkü minimum iki isimden sekiz isime kadar değişen yapılarda değişen URL adreslerimiz oluyordu. Bu durumda da bizler SAN olarak isimlendirdiğimiz sertifikaları satın alıyor ve bu şekilde sorunsuz bir hizmet sunabiliyorduk. Ancak 31 ekim 2015 den sonra artık sertifikalarda bu internal isimleri görmek mümkün değil.

Peki şu anda bir sertifika almak isterseniz ne olur? iki yıl boyunca almaya devam edebilirsiniz, hatta 3 yıllık bile alabilirsiniz ama bu sertifika iki yıl sonra geçerli olmaz.

Satın alma yaptığınız yere bağlı olarak ücretsiz internal isimleri çıkarıp tekrar sertifikayı yükleyebilirsiniz.

Ancak bundan önce daha önemlisi exchange mimarinizi buna hazır hale getirmeniz gerekmektedir. Bu nedenle sahip olduğunuz Virtual Directory URL adreslerini değiştirmelisiniz.

Exchange 2013 örnek powershell komutları;

Not; komutları öncelikle bir not defterine alınız ve tek satır olacak şekilde hazırlayınız, yani birden çok satırlı şekilde bu komutlar çalışmaz.

Sonra sizin şirket yapınıza göre isimleri değiştirip çalıştırabilirsiniz.

Get-OutlookAnywhere | Set-OutlookAnywhere -ExternalHostname mail.cozumpark.com -InternalHostname mail.cozumpark.com -ExternalClientsRequireSsl $true -InternalClientsRequireSsl $true -DefaultAuthenticationMethod NTLM

Get-OwaVirtualDirectory | Set-OwaVirtualDirectory -ExternalUrl https://mail.cozumpark.com/owa -InternalUrl https://mail.cozumpark.com/owa

Get-EcpVirtualDirectory | Set-EcpVirtualDirectory -ExternalUrl https://mail.cozumpark.com/ecp -InternalUrl https://mail.cozumpark.com/ecp

Get-ActiveSyncVirtualDirectory | Set-ActiveSyncVirtualDirectory -ExternalUrl https://mail.cozumpark.com/Microsoft-Server-ActiveSync -InternalUrl https://mail.cozumpark.com/Microsoft-Server-ActiveSync

Get-WebServicesVirtualDirectory | Set-WebServicesVirtualDirectory -ExternalUrl https://mail.cozumpark.com/EWS/Exchange.asmx -InternalUrl https://mail.cozumpark.com/EWS/Exchange.asmx

Get-OabVirtualDirectory | Set-OabVirtualDirectory -ExternalUrl https://mail.cozumpark.com/OAB -InternalUrl https://mail.cozumpark.com/OAB

Get-ClientAccessServer | Set-ClientAccessServer -AutoDiscoverServiceInternalUri https://mail.cozumpark.com/Autodiscover/Autodiscover.xml

Daha fazla bilgi için

http://www.digicert.com/internal-names.htm

Sahip olduğumuz Exchange Server üzerindeki mail trafiği her zaman sorunsuz işlemeye devam etmeyebilir. Olası kötü durumlara karşı kendimizi hazırlamamız gerekmektedir. İyi bir sistemci olarak her zaman düzenli yedeklerimizi alsak ta bazı sorunlar yedek ile çözümlenemez. Servisin yavaşlaması ,gönderilen maillerin kuyrukta beklemesi , mail alma ve gönderme işleminin çok geç gerçekleşmesi , istemci mail alma programlarında ki tutarsızlık , servislerin çok fazla kaynak tüketmesi gibi durumlar bize Exchange Server’ın sorun çıkarmak üzere olduğunu ve bunun için yedekten fazlasını yapmamız gerektiğini göstermektedir . Bu gibi durumlarda Microsoft un bize sunduğu “ESEUTIL” aracını iyi bir şekilde kullanabilmemiz gerekmektedir. Ben de bu makalemde bu komut seti ile neler yapabileceğimizi anlatacağım .

ESEUTIL komut seti, ek bir yardımcı program yüklemeye gerek kalmadan Exchange Server yüklemesi ile beraber gelmektedir. Bu komut setini iyi derecede kullanabilmek için öncelikle Exchange Server ın veri dosyalarını nerede ve ne şekilde sakladığını bilmek gerekmektedir. Exchange Server standart olarak veri dosyalarını aşağıdaki dizine kurulmaktadır;

“C:\Program Files\Exchsrvr\MDBDATA”

Bu dizinde aşağıdaki dosyalar bulunmaktadır.

Bu dosyaları sırası ile incelemek gerekirse;

EDB ve STM = Exchange Server 2003 üzerinde bir depolama birimine ait veri tabanı dosyalarıdır ( priv1 = depolama birimi için, pub1 = ortak klasörler için ) . Bu depolama birimi üzerindeki mailler ve bunlara ait olan ekler bu iki veri tabanı dosyasında tutulmaktadır. Bu her iki dosya farklı istemci tiplerine göre kullanılmaktadır. Yani bir MAPI client eğer Exchange Server üzerinden bir mail almak isterse bu bilgi ona “edb” veri tabanından verilirken, internet tabanlı bir protokol ile Exchange Server dan mail alan istemci “ stm ( Streaming) “ dosyasından bilgi almaktadır. “Edb” dosyasında maillere ait başlıklar, maillerin metinleri ve ekleri bulunmaktadır. “Stm” dosyasında ise; ses, görüntü ve benzeri multimedya öğeler yer almaktadır.

E00, Exx = Bu dosyalar Exchange Server ın “Transaction Log” dosyalarıdır. Her depolama grubu için oluşturulan bu log dosyaları yeni açılan her depolama biriminde numarası bir artarak oluşturulur; E00, E01, E02 vb. Bu dosyaların kullanım amacı ise Exchange Server ın hızlı çalışmasını sağlamaktır. Exchange üzerinde yapılan mail gönderimi ve mail düzenleme gibi işlemler direk olarak veritabanına yazılmaz, bu değişiklikler bilgisayarınızın fiziksel RAM i ile log dosyalarında tutulur. Bu Exchange Server ın daha hızlı çalışmasını sağlamaktadır, ancak olası log dosyası silinmesi veya zarar görmesi durumunda veri kaybı kaçınılmazdır. Çünkü çalışmakta olan bir Exchange Server ın sunduğu hizmet; veri tabanı dosyaları, RAM ve log dosyalarının oluşturduğu bir bütündür. Bu nedenle bu bütüne ait bir parçada olan sorunlar bütüne yansımaktadır. Bu log dosyalarının her biri beş’er MB ile sınırlandırılmıştır. Yani her 5mb tan sonra yeni bir log dosyası açılmaktadır. Birinci depolama grubu için artış;

E0000001, E0000002, E0000003 şeklinde ilerlemektedir.

Res1.log, Res2.log = Exchange Server ın kullandığı fiziksel diskte yer kalmaması durumunda loglama işlemi yapılamaz. Bu da olası veri kayıplarına yol açacağı için böyle bir durumda kullanılmak üzere iki adet beş er mb lık iki dosya rezerve için kullanılmaktadır.

E00.chk , Exx.chk = Chk dosyası kontrol dosyası olarak görev yapmaktadır . Bildiğimiz üzere işlemler öncelikle RAM ve log dosyaları üzerine yazılmaktadır . Kontrol dosyası da verilerin veri tabanı üzerine kayıt edilmesini kontrol etmektir.

E00.tmp, tmp.edb = Her depolama birimi için kullanılmak üzere geçici dosyaları temsil ederler. E00.tmp ilk depolama birimi için geçici log dosyasıdır. Exchange üzerinde çalışan “Extensible Storage Engine” servisi üzerinde gerçekleşen işlemler bu log dosyasında tutulur. Veri tabanı üzerinde gerçekleşen “full-text index” gibi işlemlerde ise verilerin geçici olarak tutulduğu dizin ise “temp.edb” dir.

Exchange veri tabanı dosyalarını ve bunların görevlerini anladıktan sonra artık komut setinin kullanımına geçebiliriz. Bu komut setini çalıştırmak için DOS ortamında aşağıdaki dizine kadar gitmeliyiz veya bu dizini path olarak tanımlayabiliriz.

“C:\Program Files\Exchsrvr\bin>” Bu dizinde “ESUTIL” yazarak komut setine ait parametreleri görebiliyoruz.

Bu parametrelerden en çok kullanılanlarını örneklemek istiyorum .

Yoğun çalışan bir Exchange Server ın zamanla veritabanı şişecek ve çok fazla yer kaplamaya başlayacaktır. Bunun sonucu olarak ise aldığınız yedeklerin boyutu büyüyecek , veritabanının bulunduğu diskteki yer azalacak , Exchange server ın çalışma performansı kötü yönde etkilenecektir . Exchange Server üzerinde Günlük bakım işlemleri ile beraber online bir defrag yapılmakta ancak bu çok ta yeterli olmamaktadır . ESEUTIL ile yapacağımız defrag ise offline defrag tır ve veritabanı üzerinde son derece etkilidir. Defrag işlemi sırasında Eseutil, veritabanın yapısını inceler ve veri tabanı üzerinde ; tarama , okuma , onarım ve birleştirme yapar.

Defrag yapmak için öncelikle Mailbox Store u Dismount etmemiz gerekmektedir.

Bu işlem için ESM üzerinden şekilde gösterildiği gibi Store un üzerine gelerek “Dismount Store” seçeneğini seçiyoruz.

( Not : Eğer bu işlemi unutur ve komut satırında işlemi yaparsanız Operation terminated with error -550 <JET_errDatabaseInconsistent, Database is in inconsistent state>” şeklinde bir hata alacaksınız )

Bu işlemin ardından komut satırınsa aşağıdaki komutu çalıştırıyoruz ;

eseutil /d "c:\program files\exchsrvr\mdbdata\priv1.edb"

Burada önemli bir nokta ya dikkat çekmek istiyorum . Offline defrag yapmak için diskinizin veritabanını barındıran bölümünde veritabanı boyutunun %110 u kadar bir boş alan olmak zorundadır .

İşlem başarı ile sonuçlandıktan sonra artık Mailbox Store u tekrar mount edebiliriz

Bu işlem sayesinde artık veri tabanı gözle görülür bir şekilde küçülmektedir. ( Eğer veri tabanı parçalanmamış ise zaten defrag sonucu da boyut pek değişmeyecektir . )

Eğer defrag işlemi sırasında veritabanı birleştirme yanında diğer ek özelliklerinde kullanılmasını istiyorsanız , Defrag parametrelerinin switchlerini kullanabilirsiniz

Örneğin Defrag işlemi sonucu olası sorunlara karşılık veritabanının bir kopyasını almak isteyebilirsiniz . Bunun için aşağıdaki komutu kullanabiliriz

eseutil /d "c:\program files\exchsrvr\mdbdata\priv1.edb" /b c:\deneme

Komutun çalıştırılması yukarıdaki gibidir . Yedek dosyası ise aşağıdaki şekildedir ;

Eğer farkında olmadan Exchange Server şişmiş ve veritabanının bulunduğu diskte yer kalmamış ise Exchange Server çalışmaya devam edemeyecektir. Bu durumda en iyi çözüm hızlı bir şekilde defrag yapmak ve yer açmaktır . Ancak sorun ise defrag için gerekli olan %110 boş alanın zaten elinizde olmaması . Böyle bir durumda ise yine kullanacağınız bir ESEUTIL switch i ile bu sorunu aşabilirsiniz.

Defrag sırasında “t” switch i kullanılmaz ise eğer veritabanının bulunduğu dizinde “Tempdfrgxxx.edb” isminde geçici veritabanı dosyası oluşturulur .

Eğer veritabanının bulunduğu disk üzerinde yeriniz yok ise geçici veri tabanı dosyasını isterseniz “t” komutu ile başka bir dizin üzerine alabilirsiniz . Örneğin aşağıdaki komut ile geçici veri tabanı ismini ve konumunu değiştirmiş oluyorum . Bu komuta göre geçici veri tabanı bilgisayarımın “D” dizininde “temp.edb” isminde olacaktır .

eseutil /d "c:\program files\exchsrvr\mdbdata\priv1.edb" /t d:\temp.edb

Kullandığım “t” komutu ile defrag için gerekli olan geçici veritabanı dosyası artık belirtilen dizine alınabilir . ( not : eğer tek disk var ise map network drive üzerinde de sorunsuz çalışmaktadır. )

ESEUTIL ile aynı zamanda bozulmuş data dosyalarını da düzeltme şansınız bulunmaktadır .

Örneğin virüs programları sonucu zarar görmüş ve mount olmayan db yi /P komutu ile onarabiliriz.

eseutil /p "c:\program files\exchsrvr\mdbdata\priv1.edb"

Komutu çalıştırdığımızda karşımıza yukarıdaki gibi bir uyarı ekranı gelecektir. Bu ekranda bize Repair işleminin loglara yansımayacağı bildirilmektedir.

İşlemin sonucunda veritabanının bütünlüğünü kontrol etmek ve olası sorunları düzeltmek için aşağıdaki komutu kullanıyoruz.

isinteg –s kayro –test folder ( kayro = server ismi , folder ise test dosyasının ismi , -fix komutunu da kullanarak sorunları düzeltebilirsiniz )

bu komut hakkında daha fazla bilgi için http://support.microsoft.com/kb/182081/tr

Bu işlemin ardından sorunlu veritabanı sorunsuz bir şekilde mount olacaktır . ( not : bu işlemin %100 kurtarma ve onarma garantisi yoktur. )

Bu işlemlere rağmen veritabanı mount olmuyor ve sorunlar devam ediyor ise “/g” komutunu kullanabiliriz . Bu komut veritabanının bütünlüğünü kontrol eder ve eğer sorunlar var ise artık “/r” parametresini kullanabileceğimizi gösterir.

Komutun başarılı bir şekilde çalıştığını görebiliyoruz.

Eğer veri tabanı hala sorunlu ise “/r” parametresi ile “Soft Recovery” işlemi yapılabilir . Microsoft ; eğer Exchange Server ın veri dosyaları duruyor ancak mount işlemi gerçekleşmiyor ise bu işlemi öneriyor . Ancak veri dosyaları yok olmuş ve online olarak yedekten geri dönülmüş ise o zaman “Hard Recovery” yani “/c” parametresini önermektedir.

Eseutil Recovery faklı bir lokasyona taşınmış veritabanını kurtarabilir, bu özellik yalnızca Exchange 2003 le beraber kullanılabilir. Hard recovery "veritabanı back up alındıktan sonra bile" farklı lokasyona taşınmış olsa dahi geri kurtarma işlemini başarı ile tanımlar. Exchange 2003 öncesine kadar ise Veritabanını kurtarmak için Transaction Log files ın bulunduğu konumda olması gerekirdi. Exchange 2003 de /D switch’i kurtarma moduna eklenmiştir ve böylece transaction log files ın bulunduğu konuma da transaction logları tarafından yazılmış bilgilere rağmen geri yüklemeyi başarır. Bu yeni özellik çevrimdışı veritabanlarını " Recovery Storage Groups" a yazarken ve ya yukarıda ki senaryoda gibi bozulmuş veritabanlarını kurtarırken son derece kullanışlıdır.

Veritabanını ve transaction log dosya gruplarını istediğiniz klasöre kopyalayabilir ve başarılı bir şekilde normal geri kurtarma işlemi yapabilirsiniz. Veritabanı bir kez doğrulandığında ( Consistence ) daha sonra veritabanını istediğiniz lokasyona taşıyabilirsiniz ve farklı log larla ilişkilendirebilirsiniz.

eseutil /r e00 /i ( veritabanının olduğu dizinde çalıştırın )

Komutun çalıştırılmış şekli yukarıdaki gibidir . Bu uygulama ile beraber sorunlu olan veritabanı dosyaları düzelecektir. ( yine bu konuda da Microsoft bir garanti vermemektedir. )

ESEUTIL r için bazı özel durumlar vardır, örneğin yeni sistemlerde log ve DB farklı dizinlerde olabilir. Bu durumda tercihiniz her zaman komutu DB nin olduğu dizinde çalıştırmak olsun. Ancak log ve kontrol dosyası için aşağıdaki iki parametreyi kullanabilirsiniz

eseutil /r E03 /i /L "D:\LOGS\DB2\" /S "D:\LOGS\DB2\"

bu şekilde DB ve log dosyalarının ayrı olduğu veri tabanları içinde eseutil aracını kullanabilirsiniz. Eğer logların olduğu dizinde çalıştıracak veya farklı bir dizinde çalıştırıyorsanız bu durumda veri tabanının olduğu path gerekli olur ki bunuda /D parametresi ile yazabilirsiniz.

Buradan anlaşılacağı üzere "P" parametresi veri kaybı göz önüne alınsada sonuç itibari ile mount olmayan veri tabanının mount olmasını ve insanların tekrar online olmasını sağlayan bir komut seti. Ancak bazı durumlarda P parametresine rağmen veri tabanı mount olmayabilir. MH parametresi ile kontrol ettiğiniz zaman hala Dirty Shutdown görürsünüz.

Bu durumda veri tabanını mount etmeye çalıştığınız zaman aşağıdaki gibi bir hata alırsınız

MapiExceptionCallFailed: Unable to mount database. (hr=0×80004005, ec=-501)

501 kodunun açıklaması log dosyası bozulmuş demektir. Bu durumda ilk olarak edb hariç ( imkanınız yani terini var ise onuda ) tüm log ve chk dosyalarını yedekleyin. Ardından edb hariç tüm log, temp,chk dosyalarını silin. Ardından P parametresini çalıştırın. Exchange konsol üzerinden veri tabanını mount etmeyi denemeden önce veri tabanı özelliklerindeki "This database can be overwritten by a restore" kutucuğunu işaretleyin ve mount edin. Hepsi bu

Eğer ESEUTIL aracını Exchange üzerinde değil de bir başka makinede çalıştırmak istiyorsanız Exchange server dan aşağıdaki dosyaları kopyalamanız gerekmektedir

Eseutil.exe, Ese.dll, Jcb.dll, Exosal.dll, Exchmem.dll

“C:\Program Files\Exchsrvr\bin” dizininde bulunmaktadır .

ESEUTIL ile yapılacaklar bunlarında ötesindedir , ancak her bir komutu ve bu komutların switchleri ayrı bir makale konusu olduğundan en önemli ve en çok kullanılan komutlarını anlattım . Diğer detayları ile bir başka makalede buluşmak üzere.

Malum, Exchange Server kullanan sistem yöneticileri için kurulum sonrasın yapması gereken temel adımlardan bir tanesi de OWA için http gelen istekleri https olarak değiştirmektir. Bunu IIS konsolu üzerinden redirection özelliği ile yapabilirsiniz, ancak projelerimde gördüğüm kadarı ile çoğu yanlış yönlendirme nedeni ile diğer alt sanal dizinlerde bu yönlendirmeden etkilenmektedir. ( rpc, oab, activesync ve benzeri)
Bu nedenle ben sizlere farklı bir alternatif sunmak istiyorum. Malum iis kurulumu ile gelen varsayılan dosya olan iisstart dosyasının içeriğine aşağıdaki gibi bir kod yazmanız yeterli olacaktır.

<html>
<head>
<title>Redirect to Outlook Web Access to use HTTPS</title>
<META
http-equiv="refresh" content="0;URL=https://mail.cozumpark.com/owa">
</head>
</html>

Bu makalemde sizlere Lepide Software tarafından bizlere sunulan LepideAuditor Suite programı hakkında bilgi vereceğim.

Bundan yıllar önce sanallaştırmanın önemini anlatmaya çalışan makaleler yazarken yıllar içerisinde artık herkes sanallaştırmanın önemini anlamış ve artık her şirkette kullanıl olmuştur. Audit dediğimiz kavramda aslında şu anda bu durumda. Yani gerçekten çok büyük öneme sahip olan izleme, raporlama hele ki kritik verilerin olduğu şirketler için vazgeçilmez bir özellik olup şu dönemde de bu konunun üzerinde duruyoruz. Tabiki banka, Telekom veya GSM gibi şirketler için zaten Audit yani izleme, takip etme standart bir hizmet olup olmazsa olmaz ürünlerdendir.

Evet, bu alanda pek çok farklı yazılım ve donanım için ürün bulunmaktadır. Active Directory, Exchange veya 3 parti yazılımlar, dosya sunucuları başta olmak üzere herkes kendi sistemlerinde yöneticilerin neler yaptığını takip etmek ister. Veya bir değişikliğin kimin tarafından yapıldığını öğrenmek ister. Bu tür konular belki bizlerin kobi olarak isimlendirdiği şirketlerde maliyetler yüzünden önemsenmez ancak yılda bir kez dahi olsa bu bilgi gerektiğinde hayati önem taşır. Kobi deki sistem yöneticileri her ne kadar bunları biliyor olsa da izleme sistemleri kapsamları ile orantılı olarak çok ciddi lisans maliyetlerine sahiptir. Örneğin Active Directory hizmetini izlemek ile database yani veri tabanı hareketlerini izlemek son derece farklıdır.

Bu makalemde yer vereceğim program ise bizlerin temel anlamda en sık olarak kullandığı ve aslında en sık olarak bilgi talep ettiği servisleri izleyen, raporlayan bir ürün olan LepideAuditor Suite yazılımıdır.

Bu yazılım temelde AD, GPO ve Exchange sistemlerini izlemektedir.

Ürün temel olarak aşağıdaki sistemlere ile uyumlu çalışmakta olup sistem gereksinimleri de son derece temel seviyededir.

Sistem Gereksinimleri

•Dual Core Processor or higher Processor

•Minimum 4 GB RAM

•500 MB free space for the software installation

•Enough disk space to generate and save reports

Desteklenen Windows İşletim Sistemi Sürümleri

•Windows XP

•Windows Vista

•Windows 7

•Windows 8

•Windows Server 2003

•Windows Server 2008

•Windows server 2008 R2

•Windows Server 2012

•Windows Server 2012 R2

Desteklenen Exchange Server Sürümleri

•Exchange Server 2003

•Exchange Server 2007

•Exchange Server 2010

•Exchange Server 2013

Kurulum için ek gereksinimler

•NET Framework 4.0 or later

•Any of the following SQL Server versions. •SQL Server 2005

•SQL Server 2008

•SQL Server 2008 R2

•SQL Server 2012

•SQL Server 2014

•SQL Server 2005 Express Edition

•SQL Server 2008 Express

•SQL Server 2008 R2 Express

•SQL Server 2012 Express

•SQL Server 2014 Express

Kurulum kısmı son derece kolay olduğu için bu bölümü atlıyorum.

Tavsiyem bu ürün için ayrı bir sanal makine kullanmanız, yani mevcut DC veya Exchange server üzerine kurulum yapmayın.

Kurulum sonrasında ise ayarlara başlayalım.

Kurulum sonrasında programı çalıştırdığınız anda yukarıdaki menü otomatik olarak açılıyor. Domain i bulması için domain ismi ve yetkili bir kullanıcı bilgisi tanımlıyorum. Yine alt bölümde organizasyonunuz içerisinde eğer Exchange server var ise onunda otomatik olarak tanınmasını sağlayacak kutucuk işaretli gelmektedir.

Bu bölümde verilen domain için DC ve Exchange sunucularının listesi çıkıyor ve sizin izlemek istediğiniz sunucuları seçmeniz bekleniyor. Benim ortamımda tek bir DC olduğu için All veya bunu seçmem yeterli olacaktır.

Bu bölümde ise izlenmesini istediğiniz OU yapısını, tüm OU ları veya tüm OU ların izlenmesi durumunda izlenmesini istemediğiniz OU ları seçtğiniz bir ekran karşınıza çıkıyor. Ben tüm OU ların izlenmesini istiyorum.

Bu bölüm önemli olup aslında hangi obje class’ larını izlemek istediğinizi seçebilirsiniz, aksi halde çok fazla log okumak zorunda kalabilirsiniz. Tabiki programın güzel özelliklerinden bunları sınıflandırabilirsiniz ama baştan çok fazla log almak mantıklı olmayacaktır. Bunun için örneğin sadece user obje class ve computer obje class’ ı seçebilirsiniz ama bu durumda örneğin GPO üzerindeki değişikliklerin takip edilmeyeceğini unutmayın. Eğer yer sorununuz yok ve gözümden hiçbir şey kaçmasın diyorsanız bu şekilde devam edebilirsiniz.

Bu bölümde ise SQL server bilgilerini giriyor ve yeni oluşturulacak olan DB için bir isim giriyoruz.

Bu bölümü isterseniz atlayabilirsiniz. Mevcut veri tabanı çok şişerse diye arşivlemek istemeniz halinde arşiv veri tabanı için özellikleri buradan tanımlayabiliriz. Eğer bunun için mevcut veya ayrı bir sql server var ise bunun bilgilerini girip, arşiv veri tabanı ismini tanımlayıp hani günlerde arşivleme yapılacağını seçebilirsiniz. Ancak buradaki önemli nokta, eğer alt bölümdeki kutucuğu işaretlerseniz aldığınız raporlarda arşivlenen veriler prod ortamdan silineceği için göremeyeceksiniz. Bu durumda arşiv veri tabanından sorgulama yapmanız gereklidir. Yani eski kayıtlar için diyebiliriz.

Son ayarlardan sonra programı bir kapatıp açıyoruz ve konsol aşağıdaki gibi açılıyor.

Hemen lisansı yüklememiz gerekmektedir. Bunun için üst menülerden License information bölümünden mevcut yapınız için lisans talebinde bulunmanız yeterli.

Lisans yüklemesinden sonra ilk olarak hızlıca ayarları bir kontrol edelim.

Malum kurulumda yaptığımız gibi mevcut domain’ i silebilir veya yeni domainler ekleyebiliriz. Alt bölümde ise sırası ile rapor, email, alerts ve zamanlanmış raporlar hakkındaki ayarları değiştirebiliriz.

Çok karmaşık olmayan bir ara yüz ve ayarlar olduğu için detaylara girmiyorum. ( program bu konuda gerçekten çok başarılı, normalde benim makalelerimi takip edenler bilir her menüyü ayrı anlatmak gerektiği durumlar oluyordu )

Ancak önemli olan bölüm Backup ayarlarıdır. Raporların altında olmasına rağmen bu bölüm aslında 6 saatte bir AD yapısının bir görüntüsünü alıp kritik bir değişiklik sonrasında karşılaştırma için kullanılabilir. Yani bunu Active Directory Snapshot özelliğine benzetebilirsiniz. Geri dönmek için ise ana menüdeki Restore üzerinden aşağıdaki gibi istediğiniz backup setini seçip yetkili bir kullanıcı adı ve şifresi girmeniz yeterlidir.

Ancak tabiki mutlaka tavsiye edilen system state ve benzeri yedekleme sistemlerinizin çalıştığından emin olun. Yani bu özelliği tek başına bir AD yedekleme sistemi olarak kullanamazsınız.

Email ayarları malum çok önemli, çünkü program her ne kadar gerçek zamanlı izleme yapsa da siz bütün gün ekranı takip edemesiniz, bu nedenle mail sunucunuz üzerinden relay izni veya bu ürün için bir kullanıcı tanımı ile mail gönderimlerini sağlayabiliriz.

Alert bölümü de yine çok önemli bölümlerden biri. Örneğin DC üzerinde bir logon işlemi olduğunu alert olarak görmek isteyebilirsiniz veya size sunulan yüzlerce durumdan birini ( hazır raporlara bayıldım J )

Filtre bölümü sizin hayal gücünüze kalmış durumda, kimin hangi makinede ve nasıl logon olacağını belirleyip Alert’ in oluşmasını sağlayabilirsiniz.

Ve tabi ki bu durumun oluşması halinde kime nasıl bir mail gönderileceği.

Bir sonraki bölümde ise yukarıdaki gibi yüzlerce durum için gözünüzden kaçması durumuna karşılık veya rutin olarak raporlama yaptırabilirsiniz.

İstediğiniz durumlar için istediğiniz zamanlanmış raporu alabilirsiniz.

Tüm bu ayarlarını yaptığımız bölümler aslında gerçek zamanlı olarak yine sekmeler ile ulaşabileceğimiz özellikler.

Evet, bu bölümleri tanıttıktan sonra ve artık lisans dosyamızı da yüklediğimize göre ana ekranımıza geri dönebiliriz.

Ana ekranımızda gördüğünüz gibi bir takım hareketlenmeler var. Örneğin 2232 tane schema güncellemesi olduğunu göreceksiniz, aslında hemen çok ciddi bir directory değişikliği yapıldığı ortada, bunu ancak ya Exchange yada Lync gibi esaslı bir program yüklemesi ile olacağını bilirsiniz. Bende raporların ne kadar sağlıklı çalıştığını size göstermek için ürünü kurduktan sonra ortama bir Exchange kurulumu yaptım ve sonuç yukarıdaki gibi, sıfır tertemiz kurulan bir domain için sadece bir Exchange kurulumu ne kadar değişiklik yapıyor siz düşünün.

Hemen alt bölümde ise Default Domain Policy içerisinde 15 adet değişiklik olduğunu görüyoruz ve merak edip neymiş bu değişiklikler diye bakıyoruz.

Bunun için tek yapmamız gereken raporlar bölümüne gelmek ve aşağıdaki yolu izlemektedir.

Bu rapor sayesinde GPO üzerindeki değişiklikleri görebiliyoruz. Baktığımız zaman hep bir ayar ekleme olduğunu görüyoruz ve bunu da merak ediyoruz J Merak ettiğimiz ayar için üzerine tıklamamız yeterli.

Hemen sağ bölümde bu değişikliğin ne olduğunu görebiliyoruz.

GPO içerisinde Default Domain Controller Policy içerisinde, Computer Configuration altında bir ekleme yapılmış. Eğer tam detayını görmek isterseniz kayıdın üstüne çift tıklamanız yeterli.

Yani sizden habersiz kuş uçmuyor demek yerinde olur J

Yine AD tarafındaki değişiklikleri de kontrol edebilirsiniz. Zaten mantık son derece kolay, rapor sayfasına gelip kontrol etmek istediğiniz ana başlıkları seçip sağ bölümden detay görmeniz yeterli. Tabi istersen kişisel raporlarda almanız mümkün.

Gördüğünüz gibi yine çok sağlam bir rapor alıyoruz.

Exchange tarafını da hemen kontrol edelim. İki tane yeni mailbox açmıştım bakalım onları görebilecek miyiz?

Evet, yukarıdaki gibi bu detayı da yakaladık, peki kota değişikliği yapmıştım ona bakalım hemen.

Bunu da detaylı bir şekilde görebiliyorum.

Peki gelelim daha kritik bir konuya, özellikle sistem yöneticilerinin bir başkasının posta kutusuna erişmesini istemeyiz, tabi ki yöneticilerde bunu istemez, bu nedenle örneğin Manage Full Access Permission izni yani A kullanıcı posta kutusuna B kullanıcısının tam erişimi veya Send As yetkisi çok riskli bir durum olup bunu süreli kontrol etmek isteyebilirsiniz.

Bakalım;

Evet, bunu da yakalık, Exchange tarafındaki durumu da paylaşıyorum

Gördüğünüz gibi gerçekten Mesut kullanıcısının posta kutusu için Hakan kullanıcısının tam erişim hakkı vardır. Bu tür raporlar gözünüzden kaçmasın diye isterseniz alert oluşturabilirsiniz.

Bu bölümleri makalemin başında da gösterdiğim için tekrar detaylandırmıyorum.

Bu bölümde filtre tanımlayabilirsiniz yani kim veya kimin üzerinde ne yapıldığında gibi. Bu sayede tüm mailbox değişiklikleri değil sadece Manage Full Access Permission konularını alert olarak alabilirsiniz.

Ancak buna hiç gerek kalmayabilir J Nedeni ise yine ürün ile gelen Audit raporları. Diyelim ki yukarıdaki gibi bir konudan haberdar değilsiniz, hiç üzülmeyin hazır raporlarda yukarıdaki gibi bir işlem yapılmış olsa bile size erişim bilisi sunuluyor.

Gördüğünüz gibi Audit menüsü altında ihtiyaç duyacağınız tüm rapor modelleri sunulmaktadır.

Not: Bu özelliğin kullanılması için kurulum sonrasındaki “Audit Non-owner Access” özelliğinin açık olması gereklidir.

Eğer bu özellik açık değil ise sadece admin seviyesindeki değişiklikleri görebilirsiniz. Ancak unutmayın ki posta kutusu seviyesinde böyle bir takip posta kutuları için ortalama %10 büyüme demektir.

Ancak isterseniz her kullanıcı için değil örneğin müdürler, genel müdür yardımcıları gibi kritik posta kutularını seçebilirsiniz

Veya bu posta kutuları için örneğin silme hareketlerini.

Peki ben bu özelliği de açıyorum. Sonra Hakan kullanıcısı ile Mesut’un posta kutusuna erişiyorum.

Sağ üst köşeye bakarsanız logon olan kullanıcı hakan, ama posta kutusu Mesut’ un. Ardından Mesut’ a attığım maili sildim. Raporlara bakalım şimdi.

Evet, raporlarda hemen bu hareketleri yakalayabiliyoruz.

Ayrıntılardan da görebileceğimiz gibi inbox içerisindeki bir maili silmişiz.

Evet, gördüğünüz gibi AD, GPO ve Exchange Server için son derece kullanışlı ve kolay bir program olan LepideAuditor Suite  ile tüm hareketler kontrolünüz altında.

Benim şahsi görüşüm son çok kompleks olan izleme programlarına göre kurulum, yaygınlaştırma ve kullanımı çok kolay, özellikle hazır raporları son derece yeterli ki zaten istediğiniz gibi özel rapor oluşturabiliyorsunuz.

Ürün hakkında daha fazla bilgiye ulaşmak için aşağıdaki linki kullanabilirsiniz.

http://www.lepide.com/lepideauditor/

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

CloudMagic biz sistem yöneticileri tarafından çokta hoş karşılanmayan bir uygulama. Mobil telefonlarda ve tablerlerde mail istemcisi olarak çalışan ve doğal olarakta bizim Exchange Server tarafında mobil cihazlara uyguladığımız policyleri devre dışı bırakan, ancak kullanıcının hala mail almasını sağlayan bir uygulama olarak özetleneibilir.

Durum böyle olunca biz Exchange yöneticileri olarak bu uygulamanın Exchange Server üzerinden mail çekmsini yasaklamak için dertleniriz ve bu konuda bende bir çözüm paylaşmak istiyorum.

Bu programı kullanan bir kullanıcı özelliklerinden mobil telefonlarını açtığınız zaman cloudmagic için istemci göreceksiniz, aşağıdaki gibi bir kural ile bunu hızlı bir şekilde çözebilirsiniz

New-ActiveSyncDeviceAccessRule -AccessLevel Block -Characteristic DeviceType -QueryString CloudMagic

Exchange Server yöneticileri yönetmekte oldukları ortamlara göre kimi zaman outlook bağlantı özelliklerini değiştirmek, hatta bu değişikliği zorlamak mecburiyetinde kalabilirler. Bildiğiniz gibi outlook varsayılan olarak bir exchange mail profili oluşturduğunda bağlantı cache mode dediğimiz profil ayarı ile kurulur. Bu varsayılan ayar olup posta kutusunun bir kopyasını lokal bilgisayarda ost olarak saklar. Arama ve benzeri tüm disk işlemlerini lokal ost de yapar ve outlook bunu exchange server ile eşitler. Ancak bazı durumlarda cache mode tercih edilmez.

Örneğin çok şubeli bir yapıda 1000 tane kullanıcınız var ve bunlar 50 tane terminal server havuzuna load balance cihazı ile giriş yapıyor. Bu durumda her bir bilgisayarda oturum açan kullanıcılar sürekli olarak posta kutularını exchange üzerinden RDS sunucuların lokal disklerine indirecek ve tabiki RDS sunucularının diskleri hızlı bir şekilde dolacaktır. Böyle bir durum için Active Directory GPO yardımı ile ( office gpo template ) outlook programının cache mode kullanmasını yasaklayabilir, bu sayede outlook direkt olarak exchange server’ a bağlı olan yöntemi yani online mode’ ı kullanır. Tabiki benzer bir online mode bağlantıların yasaklanması içinde olabilir.

Bu sefer başka bir senaryo ile ilerleyelim. Malum online mode demek outlook istemcilerinin her türlü okuma, yazma yani bilgi isteklerinin doğrudan exchange server kaynakları tarafından karşılanması demektir ki bu da exchange server için ciddi bir iş yüküdür. Bu nedele eğer istemcilerinizin size online mode yöntemi ile bağlanmasını engellemek için aşağıdaki powershell komutunu kullanabilirsiniz

Set-CasMailbox MailboxName -MapiBlockOutlookNonCachedMode:$true

Bu komutu çalıştırdıktan kısa bir süre sonra artık bu kullanıcı için online mode bağlantısı gerçekleşmez.

Outlook Online Mode

http://sozluk.cozumpark.com/goster.aspx?id=2771&kelime=outlook-online-mode

Outlook Cache Mode

http://sozluk.cozumpark.com/goster.aspx?id=2770&kelime=outlook-cache-mode

(312)

Exchange Server DAG mimarisinde bir mailbox sunucusu üstündeki bir mailbox veri tabanı için DAG üyesi diğer bir mailbox sunucusu üzerinde pasif bir kopya tutmak isteyebilirsiniz. Böyle bir durumda ister EAC yada Exchange 2010 da kullandığımız Exchange Management Consoel, yada powershell kullanabilirsiniz. Ancak hangisini tercih ederseniz edin ortak kullanabileceğiniz bir parametre ( arayüz için seçenek ) vardır ve bu “SeedingPostponed” olarak adlandırılır.

Bu parametrenin amacı kopya eklendikten hemen sonra logların replikasyonunun başlamasının engellenmesi içindir. Aşağıdaki örnek bir komut paylaşıyorum;

Add-MailboxDatabaseCopy -Identity DB3 -MailboxServer MBX4 -ActivationPreference 5 –SeedingPostponed

Bu daha çok çoğrafi olarak bir birinden uzak ve düşük network bağlantısı olan mailbox sunucuları için yapılır. Pasif kopya bağanır ancak loglar başka bir yöntem ile oraya ulaştırıldıktan sonra replikasyon başlatılır.

(173)

Bu akşam sizlere sunacağımız webcast’ e katılmak için öncelikle aşağıdaki linkten kayıt olmanız gerekmektedir. Ardından mail adresinize kayılım linki gelecektir.

TIKLAYINIZ

(367)

Merhaba, malum herkesin şirket ihtiyacı farklıdır mutlaka ancak benim başımdan geçen bir senaryo için kullanılabilecek bir komut setini sizler ile paylaşmak istiyorum. Senaryo, şirket çalışanlarının mobil telefonları üzerine kayıtlı olduğu mail hesabı ve doğal olarak onlara ait olduğunu sandığı tüm kontakların aslında şirket’ ten ayrılmaları ve telefonlarının elinden alınması veya şahsi telefonu olsa bile mail hesabının kapatılması ile kontaklarının yok olduklarını görme senaryosu. Üzücü bir durum ama günün sonunda iş size patlıyor ( veya size bağlı olan ekibe).

Senaryo gereği üst düzey yetkili işten ayrılır ve bu gerçek ile tanışır, bu durumda silinmiş posta kutusunu getir kontakları götür derken gereksiz ek iş çıkar, bunun yerine otomasyona ek bir komut ile veya kullanıcı işten çıkarıldıktan sonra ama hala hesabı açık iken aşağıdaki komut yardımı ile kontaklarını export edip kendisine verirseniz hiç uğraşmadan sorunu çözmüş olursunuz.

Komut ÇözümPark ekibinden Ufuk Tatlıdil tarafından hazırlanmıştır

Öncelikle bu işi yapacak kişiye yetki vermemiz gerekli, varsayılan olarak Organizasyon yöneticilerin de de bu yetki olmadığı için bu adımı atlamayın lütfen. Ama bundan önce bu tür işler yaptıysanız bu yetkiyi almışsınız demektir, bu durumda tekrar yetki vermenize gerek yoktur.

New-ManagementRoleAssignment -Role “Mailbox Import Export” -User USERNAME

New-MailboxExportRequest -IncludeFolders “#Contacts#/*” -Mailbox USERNAME -FilePath \\Server_Name\export\ufuk_Contacts.pst

Get-MailboxExportRequest | Get-MailboxExportRequestStatistics

Get-MailboxStatistics -Identity USERNAME

(943)

Exchange Server 2010 ortamlarında Outlook bağlantıları MAPI/RPC üzerinden veya Outlook Anywhere (RPC over HTTPS) üzerinden CAS Server’ a yapılmaktadır. MAPI/RPC istemcileri CAS Array Object olarak ifade ettiğimiz FQDN adresine (RPC end point) bağlanarak posta kutusu erişmlerini gerçekleştirirler. HTTPS üzerinden gelen istekler ise (HTTPS based client) Outlook Anywhere FQDN ( hostname – RPC proxy endpoint) e bağlanır ( tüm posta kutusu ve public folder erişimleri için).

Buna ek olarak ihtiyaç duyulan EAS, ECP, OAB ve EWS için ise Outlook anywhere için kullanılan adres geçerli olabilir. Hatta bazı senaryolarda POP/IMAP için bile benzer FQDN adresi ( SMTP endpoint) kullanılır.

(303)

Exchange Online ve Kullanıcı Mailbox Özelliklerin anlattığımız videomuza erişmek için aşağıdaki link’ i kullanabilirsiniz

http://tv.cozumpark.com/video/784/Exchange-Online-ve-Kullanici-Mailbox-ozellikleri

(235)

Exchange Server üzerinde loglarda aşağıdaki gibi bir hata alıyorsanız eğer

Bunun temel sebebi aktif olarak kullanmaya çalıştığınız SSL Sertifikasının artık olmayışıdır. Genel olarak yeni sertifika yüklemelerinden sonra eski sertifikaları silince bu sorun görünüyor. Bu arada 0.0.0.0:444, 0.0.0.0:443 ve farklı değerler olabilir, zaten hata içeriğine göre bizde sertifikaları güncelleyebiliriz.

İlk olarak Exchange server üzerinde aşağıdaki komut ile mevcut sertifikaları listeleyelim

netsh http show sslcert

Örneğin benim hatam 0.0.0.0:444 ise öncelikle bu hata aldığım ve ip ve port için aşağıdaki değerleri not almalıyım

Certificate Hash ve Application ID, yukarıdaki resimde işaretledim.

Daha sonra bu port için tanımlı sertifika atamasını silelim

netsh http delete sslcert ipport=0.0.0.0:444

Şimdi ise yeniden atama yapalım

netsh http add sslcert ipport=0.0.0.0:444 certhash=158d0faecdcac3b771ff7ea43852b9e64f7e01d5 appid=”{4dc3e181-e14b-4a21-b022-59fc669b0914}”

Hepsi bu. Artık bu sorunu atlamış olacaksınız. Umarım faydalı bir ipucu olmuştur.

Kaynak

http://www.exchangedictionary.com/solutions/event-id-15021-error-occurred-while-using-ssl-configuration

(524)

Eğer şirketinizde artık aktif bir Exchange Server kullanımı olmayacak ve mevcut sunucuları da düzgün bir şekilde kaldırmamış iseniz aşağıdaki adımları gerçekleştirerek Active Directory veri tabanından tamamen Exchange organizasyon bilgilerini silebilirsiniz.

Bu işlem için ADSIEDIT arasını kullanıyoruz ve iki farklı AD veri tabanı bölümüne ( Domain ve Configuration) bağlanıyoruz.

Kırmızı ile işaretli olanlar AD veri tabanı bilgisi, sarı ile işaretli olanlar ise silinecek kayıtlar.

Removing Active Directory Objects:
1. Go to Primary Domain Controller
2. Open ADSIEDIT
3. Right Click on ADSIEdit and Click Connect to
4. Connect to “Default Naming Context”
5. Navigate to the following objects and Delete them.
DC=Domain,DC=Com -> OU=Microsoft Exchange Security Groups

DC=Domain,DC=Com -> CN=Microsoft Exchange System Objects

6. Right Click on ADSIEdit and Click Connect to
7. Connect to “Configuration”
8. Navigate to the following objects and Delete them.
CN=Configuration,DC=Domain,DC=Com -> CN=Services -> CN=Microsoft Exchange

CN=Configuration,DC=Domain,DC=Com -> CN=Services -> CN=Microsoft Exchange Autodiscover

9. Force the Active directory Replication.

Kaynak

http://forums.msexchange.org/m_1800543683/printable.htm

(701)

Aşağıdaki komutları kullanarak duplicate identity’e sahip kullanıcıların mailbox restore’unu yapabilirsiniz;

Aşağıdaki komutları kullanarak duplicate identity’e sahip kullanıcıların mailbox restore’unu yaptım. Kayıtlara geçsin lütfen

Mailbox GUID bulmak için öncelikle aşağıdaki komutu çalıştırın

Get-MailboxStatistics -Database “recoverydb” | list displayname, identity | more

Kurtarmak istediğiniz GUID yi not aldıktan sonra aşağıdaki komutu kullanın
        
New-MailboxRestoreRequest -SourceDatabase “recoverydb” -SourceStoreMailbox MAILBOX GUID -TargetMailbox   x.y@domain.com.tr   -AllowLegacyDNMismatch

Kaynak

Oktay Yılmaz

(70)

OWA Offline Mode Bilgisayarınızda internet bağlantınız olmadığında da OWA (Outlook Web Access) üzerinden maillerinize erişebilir, bunları yanıtlayabilir; kişilerinizi düzenleyebilir ya da takvim öğelerinizi görüntüleyip toplantı isteklerinizi yanıtlayabilirsiniz. Tarayıcıdan office 365 portalı üzerinde oturum açılmasının ardından outlook bölümüne gelerek ayarlar altında çevrimdışı ayarlar seçilir ve ardından offline mode için çevrimdışı erişim etkinleştirilir. Etkinleştirme sırasında gerekli bilgilendirmeler yapılır. Çevrimdışı erişimi için sık kullanılanları kullanmak kolaylık sağlayacaktır. Gelen kutusu ve taslaklar her zaman eşitlenecektir. Ayrıca bu klasörlerin dışında eşitlenmesi istenen 5 klasör de seçilebilir. Gerekli yapılandırma sonrası maillerinizi, takvimlerinizi ve kişilerinizi OWA üzerinde offline olarak yönetilebilmektesiniz.

Metin: Sevil Rodoplu

(183)

Outlook programı bizlere kullanım kolaylığı noktasında pek çok özellik sunmaktadır. Bunlarda bir tanesi ise Auto-Complete List dediğimiz daha öncesinde mail gönderdiğimiz kişilere bir kez daha mail göndermek istememiz halinde sadece adının birkaç harfini veya mail adresinin bir bölümünü yazmamız halinde bize açılan bir menüden seçme imkânı sunar.

Örneğin kardeşim Serkan’ a mail atmak istediğim zaman Serk yazıyorum ve bunun ile başlayan daha önce mail gönderdiğim adresler listeleniyor. Tabiki benim mail trafiğim çok yoğun olduğu için sadece Serkan bile yazınca gördüğünüz gibi pek çok Serkan çıkıyor J

Bu özelliği isterseniz kapatabilirsiniz veya yanlış bir adres eklenmiş ise onu yine yukarıdaki resimde görüldüğü gibi çarğı işaretinden veya üzerinde iken klavyenin delete tuşuna basarak silebilirsiniz. Ama ben şu anda bu konulara değinmeyeceğim.

Evet, bu güzel bir özellik ve özellikle Outlook 2010 – Exchange 2010 sürümlerinden sonra bu liste kullanıcı posta kutusunda tutulmaya başladı. Yani daha önceki sürümlerde ilgili bilgisayar için tutulan bir NK2 dosyasından artık kullanıcı posta kutusunun içine alındı.

Bunun en büyük avantajı artık bilgisayarının değiştiren veya aynı bilgisayar bile olsa profili resetlenen kullanıcıların bu listeyi almak için ek bir efor sarf etmesinin gerek olmaması. Eskiden eğer bir kullanıcı profili resetlenecek ise bu dosya alınır, Outlook kurulduktan sonra tekrar ilgili dizine atılırdı. Ancak terminal server gibi ortamlarda kullanıcı profillerinde bilgi olmaz, ortak alanlar ise MAP ile bağlanır ve bu nedenle sorun oluştukça ilgili kullanıcının roaming profili silinir. Bu silme sonucu kullanıcı verisi kesinlikle kaybolmaz. Neden?

Kullanıcı mailleri sunucuda duruyor, masa üstüne veri kaydetme yetkisi zaten yoktu, peki verileri nereye kayıt ediyor? Map drive yapılmış ortak dosya sunucularına, doğal olarak onlarda kaybolmuyor. Peki mailler tamam, dosyalar tamam, kısa yollar? Onlar ise GPO ile Terminal sunucuları için her kullanıcıya otomatik kopyalanıyor.

Tabiki burada bir takım kayıplar olur, örneğin browser için favoriler veya yaptığınız bazı görsel ayarlar. Anca bu konu çok sorun edilen bir konu değil. Ama mail listesi çok önemli. Yani siz bir kullanıcı profilini resetlediğiniz zaman yukarıdaki durumdan dolayı sizi üzmez, ama eğer Outlook tamamlama listesi kaybolur ise o zaman bir hayli can sıkıcı olabilir J

Peki yıl olmuş 2014, 2010 sürümlerinden beri bu özellikle artık posta kutusunda ise benim size anlatacağım konu ne olabilir ki? Konu şu ki, her ne kadar artık tamamlama listeleri posta kutusunda olmasına karşın 2007 sistemlerden 2010 sistemlere geçiş yapan şirketlerde bazı posta kutuları için bu otomatik tamamlama listelerinde sorunlar olur. Örneğin 5000 kullanıcınız var, kullanıcıların roaming profile dizini olan storage için bir değişiklik yapma kararı aldınız, diyelim ki SATA veya Fiber disklerden yeni SSD diskleri olan bir storage’ a geçiyorsunuz, ancak mevcut eski profilleri taşımak istemiyorsunuz. Günün sonunda yukarıdaki gibi bir senaryoda zaten bu profillerde kullanıcı verisi yok ( birkaç kişisel ayar ve browser için favoriler hariç ). Hop güzel güzel Active Directory üzerinde ADModify aracı ile toplu olarak 5000 veya test için 100 kullanıcının roaming profile path’ ini eski dizinden yenisine çektiniz, kullanıcılar logon oldu ve temiz bir profile yüklendi, Outlook açıldı ama hop otomatik tamamlama listesi yok. Bu sorun tüm kullanıcılarda olmaz, ancak olan kullanıcı sayısıda 5000 gibi bir rakamlardan bahsediyorsak sizi bezdirmeye yeter.

Peki bu sorun ile karşılaşan kullanıcılar için çözüm nedir?

İlk olarak aşağıdaki aracı indirmemiz gerekiyor.

http://mfcmapi.codeplex.com/

Outlook sürümüne uygun olanın indirmeniz gerekli.

Sorun yaşayan kullanıcı için bir bilgisayarda oturum açın ve online olarak Outlook programını açın.

Bir kere Outlook programını açalım sonra kapatalım. Ardından indirdiğimiz programı çalıştıralım.

Daha sonra Session – Logon kısmına tıklayalım.

Karşımıza hangi Outlook profili için bağlantı kuracağımızı belirten ekranda varsayılan profili seçebilir veya farklı bir kullanıcı profili var ise onu seçebilirsiniz.

Logon işlemi başarılı bir şekilde tamamlandıktan sonra aşağıdaki gibi kullanıcı posta kutusunu görebilirsiniz

Ardından yukarıdaki posta kutusuna çift tıklıyoruz ve yeni bir pencere açılıyor. Bu pencere posta kutusunun içeriğini bize göstermektedir.

Daha sonra IPM_SUBTREE altında inbox klasörünü bulup sağ tıklıyoruz ve “Open associated contents table” linkine tıklıyoruz.

Açılan pencerede aşağıdaki gibi IPM.Configuration.AutoComplete kaydını buluyoruz.

Sağ tıklıyoruz ve siliyoruz.

Artık Outlook programını yeniden başlatmamız halinde sıfırlanmış bir Auto-Complete listemiz var. Tabiki eski kayıtlar gidiyor, ancak artık bundan sonrası için bu kullanıcının herhangi bir şekilde profilinin resetlenmesi sonucu otomatik tamamlama listesi kaybolmayacaktır. Yani bu sorunu kalıcı olarak çözmüş olduk.

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

(115)

Queue – kuyruk, genel olarak pek çok teknoloji ürününde kullanılan bir kavramdır. Exchange Server mimarisinde de pek çok sistem yöneticisinin yakından bildiği ve zaman zaman sorun yaşadığı başlıklardan birisidir. Temel olarak bir mesajın hedefine ulaşmak için geçici olarak beklediği alan olarak ifade edebiliriz. Mesaj iletilmeden önce, iletilme sırasında ve iletildikten sonra kuyrukta saklanır ( detaylı olarak makalenin ilerleyen bölümlerinde açıklanacaktır). Her mailbox ve Edge rolünde ( Exchange 2010 için Hub transport ve Edge ) yer alan bir veri tabanıdır. Özetle transport sunucularında yer alan bir veri tabanıdır. Aynı maillerin saklandığı Exchange Server Mailbox Database gibi Queue Database de yer almaktadır. ( Her ikisi de Extensible Storage Engine (ESE) mimarisini kullanır)

Exchange Server 2013 için kuyruk tipleri aşağıdaki gibidir;

1. Persistent queues

• Submission queue
• Unreachable queue
• Poison message queue

1. Delivery queues
2. Shadow queues
3. Safety Net

Kalıcı kuyruk olarak geçen kuyruk tipleri aşağıdakilerdir

Submission Queue

Transport server üzerinde çalışan transport agentlar tarafından işlenen tüm maillerin kategorize edilmesi için kullanılan kuyruk tipidir. Transport sunucusuna gelen tüm mesajlar submission kuyruğunda işlenir. Mailbox server üzerinde mesaj receive connector üzerinden, pickup veya replay dizinlerinden veya Mailbox Transport Submission servisinden. Edge rolünde de mesajlar klasik olarak receive connector üzerinden ve yine pickup – replay dizinlerinden alınabilir.

Kategorize etmek temel anlamda kuyruktaki mesajların alıcısını ve bu alıcının nerede olduğunu bularak mesajı oraya iletmek olarak ifade edilebilir. Eğer alıcının yeri bulunmuş ise bu mesaj Delivery kuyruğuna, bulunamamış ise Unreachable kuyruğuna iletilir. Her transport servisi sadece bir tane submission kuyruğuna sahiptir. Bir mail submission kuyruğunda ise aynı anda diğer kuyruklarda işlenemez.

Unreachable Queue

Yönlendirilemeyen yani alıcısı bulunamayan mesajların saklandığı kuyruktur. Bu tür kuyruklar genellikle mail iletimindeki yapılandırma değişiklikleri nedeni ile görülür. Her transport servis bir adet unreachable kuyruğuna sahiptir. Bu kuyruk içerisindeki mesajlar iletim yapılandırılmasında bir değişiklik sezildiğinde tekrar delivery kuyruğuna gönderilir. Bu kuyruk genellikle boş olur ve bu durumlarda get-queue powershell komut çıktısında göremeyebilirsiniz.

Poison Message Queue

Transport sunucusu veya servisine zarar verdiği tespit edilen maillerin ortamdan izole edilmesi için kullanılan özel bir kuyruktur. Genellikle kötü içerikli kod içeren maillerin burada saklandığını görebiliriz. Bunun tespiti ise daha çok transport server üzerindeki transport agent’ ların bu maili işlerken hata alması veya işleyememesi durumlarında görülür.

Delivery Queue

SMTP protokolü tarafından yerel veya uzak bir hedefe iletilmek üzere olan maillerin saklandığı kuyruktur. Birden çok iletim kuyruğu görebilirsiniz ve aynı hedefe giden mailler genelde bir kuyruk altına toplanabilir. Örneğin şirket içerisinde 1000 çalışan ve x bir zamanda 13 kişi hotmail.com a 7 kişi gmail.com 5 kişi mayasoft.com.tr ye ve 50 kişi cozumpark.com a mail atar ise bu 4 domain için 4 iletim kuyruğu görebilirsiniz ve bu mailler bu kuyruk altında toplanır. Kuyruk otomatik oluşur ve yine otomatik olarak silinir. Silinme süresi varsayılan olarak 3 dakika olup Set-TransportService komut seti ile QueueMaxIdleTime parametresini kullanarak değiştirebilirsiniz.

Shadow Queue

Exchange Server’ ın mail iletiminde de yani transport seviyesinde de yüksek erişilebilirlik desteği sunabilmesi amacı ile kullanılan bir kuyruktur. Bir mail iletilirken bir kopyasının saklandığı bir kuyruk tipidir. Eğer mesajı alan bir sonraki nokta sağlıklı bir şekilde aldığını söyler ise bu kopya silinir, eğer sorun olduğu bildirilir ise bu kopya sayesinde mail tekrar iletilir. Maili alan bir sonraki sunucu ile bu bilgiyi XSHADOW sayesinde öğrenir. Ancak mail bir Exchange sunucusundan diğer bir Exchange sunucusuna yani XSHADOW destekleyen bir sunucuya değil de bu komuttan anlamayan ve doğal olarak Exchange Server’ ın beklediği cevabı veremeyen bir sunucuya gönderilmesi durumu içinde mevcut mail’ i silmek için bir delay yani bekleme ayarı vardır.

Safety NET

Transport sunucusu tarafından başarılı bir şekilde teslim edilmiş bir mailin kopyasının tutulduğu kuyruk tipidir. Temel amacı DAG mimarisinde bir transport sunucusu tarafından gönderilmiş ama henüz DAG ile replike edilmemiş olan mailleri bu transport sunucusuna bir şey olması durumunda kaybolmaması için saklandığı yerdir. Örneğin DAG nodelarından biri down oldu ve diğer MBX sunucusu ayağa kalkacak, ancak eski sunucunun kuyruğundaki mailler henüz DB seviyesinde kopyalanmadığı için Safety NET sayesinde bu yeni sunucu eksik olan mailleri otomatik olarak alır.

Kuyruk veri tabanı varsayılan olarak aşağıdaki dizinde yer alır

%ExchangeInstallPath%TransportRoles\data\Queue

Mail.que

Kuyruktaki mesajların saklandığı veri tabanı dosyasıdır.

Tmp.edb

Kuyruk veri tabanının ilk yüklenmesinde veri tabanı şemasının kontrol edilmesinde kullanılır

Trn*.log

Aktif olay günlüğüdür, yani veri tabanına yazılmadan önce gerçekleşen aktiviteler ram ve log dosyasında tutulur, daha sonra veri tabanına yazılır. Mevcut bir log dosyası maksimum boyutuna ulaşması durumunda Trn.log, Trnnnn.log şeklinde isim değiştirerek artar.

Trn.chk

Kontrol dosyası transaction log dosyalarının veri tabanına işlenmesini takip eder. Yani hangi log dosyası veri tabanına işlenmiş kontrol eder.

Trnres00001.jrs – Trnres00002.jrs

Bunlar placeholder olarak tanımlanır, yani yer kaplamak için kullanılır, diskte yer kalmadığında mevcut log dosyalarının kullanılabilmesi için sırası ile silinir.

Klasik ESE mimarisi kullanılır. Yani hızlı çalışması için gelen istekler önce RAM ve loglara sonra veri tabanına yazılır.

Checkpoint dosyası hangi log dosyasının içeriğinin veri tabanına düzgün bir şekilde yazılıp yazılmadığını kontrol eder. Log dosyaları için bir bakıma gerek yoktur çünkü bu veri tabanı için circular log açıktır.

Kuyruk veri tabanında saklama ve temizleme işlemi için “generation tables” ismini verdiğimiz tablolar kullanılır. Yani tek tek mail bazlı bir temizlik yerine saat bazlı bir tablonunun içeriğinin komple silinmesi gerçekleştirilir.

Temel çalışma mantığı, örneğin saat 1PM – 2PM arasında gelen mesajların hepsi 1p-2p_msgs tablosunda tutulur, 2PM olduktan sonra gelen mesajlar ise 2p-3p_msgs tablosun da. Bu şekilde 3p_4p_msgs tablosu şeklinde veri tabanında sürekli yeni tablolar oluşur. Mesaj silme işlemi ise örneğin 1p-2p_msgs tablosu için bu tablo içerisindeki tüm mailler başarılı bir şekilde işlenmiş ise bu tablo silinir, bu şekilde saat bazlı olarak işlenmiş ve artık kuyruk veri tabanında olmasına gerek olmayan mesajlar silinir.

Bu şekilde bireysel veya tüm mesajların silinmesinden doğacak disk I/O yükünü de düşürmektedir.

Peki, böyle bir mimari için kuyruk veri tabanı boyutları ne olmalı? Aslında bu konu çok net ifade edilebilecek bir konu değil çünkü mail sisteminizdeki en küçük anormallik kuyruk veri tabanının hızlıca büyümesine neden olabilir, ama ben yine de kağıt üzerinde olması gerekeni paylaşabilirim.

Örnek senaryoda saniyede 50KB olan 5 mail alan bir sistem için maksimum 24 saat ve 500.000 mail barındırması + %20 disk alanı için toplam gereksinim 58GB olmaktadır. Kuyruk boyutu ise 25GB olmaktadır.

Buraya kadar temel olarak Exchange Server kuyruk mimarisinden bahsettim, şimdi ise bu mimarinin en önemli oyuncusu olan kuyruk veri tabanından bahsedeceğim.

Genel olarak bu DB boyutu kontrolsüz bir şekilde büyüyebilir, bunun birkaç nedeni vardır. İlk olarak mevcut sunucularınızdaki kuyruk durumunu aşağıdaki powershell ile kontrol edebilirsiniz

Get-TransportService | Get-Queue | Measure-Object MessageCount

Eğer kuyrukta çok fazla mail var ise hali hazırda kuyruk veri tabanının büyük olması gayet normaldir. Yukarıdaki resimde 13 tane mail olduğunu görüyoruz ki bu çok küçük bir değerdir. Kuyrukta yapının büyüklüğüne göre mutlaka değişmek ile beraber 50, 100 tane mail olması olasıdır. Malum büyük şirketlerde örneğin 1000 kişi çalışan bir yerde hotmail yerine homail yazan, gmail yerine gail yazan 3 5 kişi çıksa bile onlardan 10 20 bilemediniz 30 40 tan yanlış yazılmış mail domain nedeni ile DNS çözümlemesi yapılamayan ve bu nedenle kuyrukta bekleyen mailler olur. Ama bu rakam 500, 1000 ve daha fazla ise bu durumda bir terslik var demektir.

Varsayılan olarak kuyruğunda çok mail olmamasına karşın kuyruk veri tabanı büyük olan yapılar için kontrol noktaları aşağıdaki gibidir.

Öncelikle kuyruk veri tabanının ayarlarını kontrol etmemiz gereklidir. Kuyruk veri tabanı ayarları için aşağıdaki dosyayı inceleyebiliriz

%ExchangeInstallPath%Bin\EdgeTransport.exe.config

Not: bu dosya üzerindeki değişikliklerin geçerli olması için lütfen Microsoft Exchange Transport service yeniden başlatın.

Burada kuyruk veri tabanı ile başlayan tüm ayarlar kuyruk veri tabanını ilgilendiren ayarladır.

Daha fazla ayar ve açıklama için Technet referans linkini kullanabilirsiniz

https://technet.microsoft.com/en-us/library/bb125022(v=exchg.150).aspx

Ben daha çok günlük hayatta özellikle kuyruk veri tabanı boyutunun etkileyecek olan ayarları detaylandıracağım.

QueueDatabaseMaxBackgroundCleanupTasks

Eğer kuyruk veri tabanı boyutu hızlı olarak büyüyor ise, ama bu nokta önemli hali hazırda zaten boyutu yüksek ise değil hızlı olarak büyüyor ise bu temizleme işleminin kuyruklama işleminden yavaş kaldığını gösterir ki o zaman bu değeri 32 den 64 e çıkarıp bir gün bekleyebilirsiniz, bunun sonucunda veri tabanındaki büyüme hızının düşmesi beklenir, ama küçülmez.

QueueDatabaseOnlineDefragSchedule

Varsayılan olarak açık gelen online birleştirme işlemi için gece 1:00:00 da başlaması için bir ayar vardır. Bu ayarı eğer veri tabanı boyutununz büyük ise 18:00:00 şeklinde değiştirebilirsiniz. Bu sayede mesai sonrasında defrag işlemi başlar.

QueueDatabaseOnlineDefragTimeToRun

Bu değer ise varsayılan olarak 3 olup online defrag işleminin başlamasından sonra kaç saat çalışacağını gösterir. Bunu da 12 yaparak sabah 06 ya kadar online defrag işlemi yaptırabilirsiniz.

Diğer kontrol noktaları ise aşağıdaki gibidir

Get-TransportServer “Postaci” |fl *pipe*

Eğer true ise bunu aşağıdaki komut ile kapatıyoruz

Set-TransportServer Postaci -PipelineTracingEnabled $False

Bu veri tabanının büyümesini tetikleyen bir izleme özelliğidir.

Sonra ise aşağıdaki komut ile Config dosyası incelenir

Get-TransportConfig

MaxDumpsterSizePerStorageGroup değerki MB olmalı, GB değil. Ek olarak

MaxDumpsterTime : 7.00:00:00

Değeri 7 değil ise bunu 7 gün yapmalı,

Get-TransportConfig | fl *dump*

Eğer farklı ise yukarıdaki varsayılan değerlere çekiniz

Set-TransportConfig -MaxDumpsterSizePerStorageGroup <size> -MaxDumpsterTime <timespan>

Not: bu değerler şirket ihtiyaçlarına göre değişir. Yani 7 gün pek çok kurum için yeterli bir süredir, ancak 18MB günümüz ihtiyaçlarında 50MB olabilir. Bunu belirlerken o kurumun mail almak veya göndermek için belirlediği en üst sınırı sizde referans alabilirsiniz. Yani bir seferde 50bm lık bir mail alabiliyor ve gönderebiliyor ise sistem lütfen bu değeri minimum 50MB + %30 yapın.

Kuyruk veri tabanının boyutlarının büyük olmasının bir nedeni de Transport Agent olabilir. Özellikle Exchange server üzerinde kurulu olan bir Anti Virus, Anti Spam ürünü var ise bunu transport seviyesinde kapatıp birkaç gün büyüme trendini izleyerek çözebilirsiniz.

Bir diğer önerim ise internal spam mailler olacaktır, muhtemel dışarıdan gelen spam maillere karşı önleminiz vardır, ama yok ise zaten sürekli olarak spam yiyen bir Exchange server kuyruk veri tabanı hızlı şişer bu normal bir durum, ancak büyük kurumlardaki anti spam çözümleri buna izin vermez. Ama yine bu büyük kurumlarda 500, 1000 ve üzeri kullanıcılar olduğu için içerideki spam konularına da dikkat etmeniz gereklidir. Bu nedenle önerim Promodag ve benzeri bir Reporter ürünü alıp haftalık olarak rapor çekmeniz ve internal spamcıları bulmanızdır.

Mail alma ve gönderme limitleriniz yine 50mb ve benzeri ise db boyutunun hızlı büyümesi normaldir. Tabiki bunları takip etmenin en iyi yolu öncelikle mevcut db yi bir sıfırlamak ve yukarıdaki adımları sağlıklı olarak takip etmek.

Kuyruk veri tabanının boyutunun büyümesindeki bir diğer faktör ise Safety NET özelliğidir. Bunu makalemin başında açıklamıştım. Mail kaybı olmaması için kullanılan bu özellikle gerek Primary Safety NET gerekse bunu yedeği olan sunucu da mailler 2 + 2 toplam 4 gün saklanır. Bunun en temel nedeni ise ulaştırılamayan bir mail zaten 2 günün sonunda kullanıcıya NDR mesajı olarak geri gönderilir. Ama bu gönderilen maillerin bir kopyasının iki gün sunucularda tutulması büyük yapılar için ciddi bir yük oluşturur, bu nedenle buradaki tavsiyem aşağıdaki iki komut ile bu süreyi bir güne düşürmeniz olacaktır.

Set-TransportConfig -SafetyNetHoldTime 1.00:00:00

Get-TransportService | Set-TransportService -MessageExpirationTimeout 1.00:00:00″

Not: SafetyNetHoldtime değeri, organizasyondaki ReplayLagTime değerine eşit veya büyük olmalıdır.

Eğer transport queue db boyutu tüm bunlara rağmen düşmüyor ise mevcut kuyruk veri tabanını sıfırlamanız en iyi yöntemlerden biri olacaktır. Tek sunuculu bir ortamda iseniz Microsoft Exchange Transport service önce pause yapın, sonra maillerin sıfır olmasını bekleyin ve servisini durdurun. Daha sonra eski veri tabanının ismini veya lokasyonunu değiştirin ve servisi tekrar başlatın, bu sayede yeni bir veri tabanı ile devam etmiş olursunuz. Birden çok sunucu ve DAG olan ortamlarda bu işlemi yapabilirsiniz ancak burada son bir günlük veya ayarı değiştirmediyseniz varsayılan olarak iki günlük safety NET içeriğini kaybetmiş olacaksınız. Bunu kaybetmeden bu işlemi yapmak için DAG node larını teker teker boşa çıkarın, yani bir node üzerindeki tüm kullanıcıları diğer node’ a taşıyın, daha sonra kuyruğu izleyin ve hiç mail alınmadığını kontrol edin ( HealthMailbox gönderimlerini önemsemeyin ). Ardından 1 gün bekledikten sonra bu işlemi gerçekleştirin. Daha sonra tüm posta kutularını bu sunucu üzerine alıp sırası ile diğer sunucularında kuyruk veri tabanlarını temizleyebilirsiniz.

Kaynaklar

https://technet.microsoft.com/en-us/library/bb125022%28v=exchg.150%29.aspx#QueueDBFiles

https://technet.microsoft.com/en-us/library/aa997263%28v=exchg.150%29.aspx

http://msexchangeguru.com/2011/06/02/mail-que/

http://jaapwesselius.com/2014/03/05/move-transport-database-in-exchange-2013/

https://technet.microsoft.com/en-us/library/bb738141(v=exchg.80).aspx

https://technet.microsoft.com/en-us/library/aa998047(v=exchg.150).aspx

(202)

Bildiğiniz gibi Exchange Server 2013 ve sonrasında outlook bağlantılarında artık sunucu ismi yerine bir ID kullanılmaktadır. bu ID aslında posta kutusu GUID, @harfi ve kullanıcının bulunduğu domain UPN son ekdir. Ancak bunu bir kullanıcı için hızlı bir şekilde bulmak biraz zaman alabilir, aşağıdaki powershell ile bunu kolaylıkla yapabilirsiniz

$username = “huzuner”
$guid = (Get-Mailbox $username).ExchangeGUID
$upn = (Get-User $username).UserPrincipalName
$upnsuffix = $upn.Split(“@”)[1]

$ServerName = “$guid@$upnsuffix”
write-host $ServerName

Çıktı olarak size ihtiyacınız olan Server FQDN bilgisini verecektir.

(94)

Exchange OWA ve ActiveSync Erişim IP Adreslerini Nasıl Tespit Ederim? Exchange Server’ a OWA ve Active Sync Üzerinden Kimler Bağlanmış?

Bazı kritik durumlarda günlük olarak ihtiyaç duymadığınız bu bilgiye acil olarak ihtiyaç duyabilirsiniz. Böyle anlarsa bu makale size çok yardımcı olacaktır. Amacım OWA yani IIS üzerinden sunulan web tabalı e-posta hizmeti için kimlerin erişim sağladığını tespit etmektedir.

Varsayılan olarak Exchange Server OWA için IIS kullanır ve yine IIS varsayılan olarak hizmet verdiği web siteleri için log tutar. Bu log dizini siz değiştirmediyseniz eğer aşağıdaki gibidir;

C:\inetpub\logs\LogFiles

Burada her bir web sitesi için ayrı klasörler görebilirsiniz. Hangi web sitesinin log klasörü hangisi olduğunu IIS manager üzerinden kontrol edebilirsiniz

Site ID ne ise klasörün de sonunda benzer bir numara göreceksiniz

İlk olarak amacımız burada incelemek istediğiniz logları c:\log gibi kolay bir dizine alalım

Daha sonra aşağıdaki link üzerinden ücretsiz ola log parser yazılımını indirelim ve kuralım

https://www.microsoft.com/en-us/download/details.aspx?id=24659

Kurulum sonrasındaki ilk komutumuz log dizinindeki logları birleştirmektir. Bunun için c:\log klasörü içerisine bir klasör daha açalım ve ismi “mergedlog” olsun

Daha sonra aşağıdaki komut ile birleştirme işlemini tamamlayalım

logparser.exe -i:iisw3c “select * into c:\log\mergedlog\merge.log from c:\log\*” -o:csv

Not: komutu log parser exe olan dizinde çalıştırın, ek olarak eğer hata alırsanız lütfen bu komutu not defterine yapıştırıp tırnak işaretlerini silip tekrar ekleyin

Dosyanın oluştuğunu kontrol edelim

1.5GB lık tek bir dosya oldu.

Şimdi ise artık sorgu zamanı, ister OWA, iste Active Sync veya farklı komut setleri ile sonuç alabiliriz

İlk olarak OWA ile başlayalım

LogParser -i:csv “SELECT cs-username, date, time, c-ip, cs-uri-stem, cs(User-Agent) FROM C:\log\mergedlog\merge.log TO C:\log\Output.csv WHERE cs-method LIKE ‘%post%’ and cs-uri-stem LIKE ‘%owa%'”

Çıktıyı kontrol edelim

Active Sync bağlantıları için komutumuz aşağıdaki gibidir;

LogParser -i:csv “SELECT cs-username, date, time, c-ip, cs-uri-stem, cs(User-Agent) FROM C:\log\mergedlog\merge.log TO C:\log\Output.csv WHERE cs-method LIKE ‘%post%’ and cs-uri-stem LIKE ‘%Microsoft-Server-ActiveSync%'”

Benzer şekilde bir dosya oluştuğunu görüyoruz. Dosya ismi aynı olduğu için eski dosyanın üzerine yazar, eğer siz ikisini ayrı ayrı tutmak istiyorsanız komutun TO bölümünden sonrasındaki dosya ismini activesync olarak değiştirebilirsiniz

Excel dosyasını açınca ise sonuç aşağıdaki gibidir;

Biraz küçükte olsa aslında her şey net, kimin hangi telefondan ne zaman hangi ip zerinden bağlandığını görebiliyoruz.

Aslında makalemde anlatmak istediklerim bu kadar, ancak son olarak bundan daha fazlası için sizlerin de komutları istediği gibi geliştirebileceğini hatırlatmak isterim. Örneğin sadece Mac client bağlantılarını mı görmek istiyorsunuz örnek aşağıdaki gibidir;

LogParser -i:csv “SELECT cs-username, date, time, c-ip, cs-uri-stem, cs(User-Agent) FROM C:\log\mergedlog\merge.log TO C:\log\Output.csv WHERE cs-method LIKE ‘%post%’ and cs(user-agent) LIKE ‘%Macoutlook%'”

Ya da bir kullanıcıyı mı arıyorsunuz?

LogParser “SELECT date, time, c-ip, cs-uri-stem, cs-username, cs(User-Agent), cs-uri-query FROM C:\log\mergedlog\merge.log TO c:\temp\Output.csv WHERE cs-username LIKE ‘%huzuner%'”

Gerisi size kalmış, kolay gelsin.

Kaynak

http://myriadofthings.com/outlook-web-access-owa-and-activesync-reporting-using-iis-logs/

http://www.msexchange.org/articles-tutorials/exchange-server-2003/tools/Using-Logparser-Utility-Analyze-ExchangeIIS-Logs.html

https://forums.iis.net/t/1145506.aspx

(517)