Iş kritik sunucularımız için kullanabileceğimiz birçok veri depolama türü bulunmakta. SATA Disk veri depo türlerinden Serial Attached SCSI olarak bildiğimiz veri depolama türlerine-Fibre Channel veri depolama türlerinden SSD veri depolama türlerine kadar birçok veri depolama türü küçüklü-büyüklü bütün organizasyonlara hizmet etmek üzere hazır beklemekte.

Kullanabileceğimiz disk türleri bu kadar fazla olunca doğru veya yanlış birçok kurulumu yapmış olabilir ve hali hazırda kullanmaya devam ediyor olabilirsiniz. Veya mevcut yapılandırmanız T anında ihtiyaçlarınıza cevap veriyordu ama şimdi Y anındasınız ve mevcut yapılandırma isteklerinize cevap veremiyor. Kaçınılmaz bir yükseltme-iyileştirme projesi sizleri bekliyor olabilir.

Bu makale içinde karmaşık bir konuya değineceğim. Karmaşık olmasının nedeni paylaşacak olduğum Microsoft Exchange Server mimarisinin ilk girişte işaret etmiş olduğum bütün veri depolama türlerini destekliyor olmasından kaynaklı. İşler bu kadar karmaşık olmakla kalmıyor Exchange server mimarisi ve barınmış olduğu Windows işletim sistemi de bu karmaşanın içinde kendine yer buluyor. Ama bu karmaşık durumun içinden çıkacağız ve dünyayı kurtaracağız.

Bu makale içinde aşağıdaki konuları inceleyeceğiz. Bu makale kapsamında doğru, etkili ve en uygun çözümler ile maliyette ve performansa etki edecek olan yapılandırmaları paylaşacak ve Exchange Server için en iyi yapılandırmayı ve gereksinimlere ulaşmayı hedefleyeceğiz. Server seviyesinden Servis seviyesine ve servisler arasındaki performansa etki edecek parçalanmaları inceleyeceğiz.

• Exchange Servisleri Veri Depolama Tasarımı
• Exchange Servisleri Veri Depolama Yapılandırması
• Exchange Log Path Powershell Komut Seti

Exchange Servisleri Veri Depolama Tasarımı

Günümüz Exchange server mimarisi, ilk var olmuş olduğu günden beri birçok veri depolama havuzunu desteklemektedir. Desteklemiş olduğu havuz, bu kadar geniş olduğu için birçok yanlış yapılandırmaları beraberinde getirmektedir.

İlk girişte bahsetmiş olduğum Veri Depolama havuzları ile bu bölüme başlamak istiyorum. Exchange Server 2016 ve daha önceki sürümleri, sektörde bulunan bütün veri depolama birimlerini desteklemektedir.

Yukarıda görmüş olduğunuz ekran görüntüsü Exchange 2016 Storage Configuration Options makalesinden alınmış bir ekran görüntüsüdür. Ekran görüntüsü incelendiği zaman ve paylaşmış olduğum adreste detaylar incelendiği zaman, Exchange Server bu veri depolama birimlerinin her birisi üzerinde çalışabilmektedir.

Ekran görüntüsü detaylı bir şekil incelediğiniz zaman fark edeceksiniz. Veri depolama birimlerinin türlerini, veri depolama birimleri içinde bulunan disklerin RPM türünden yazma ve okuma hızlarını, ihtiyaç duymuş olduğumuz kapasitenin ve performansın hangi disk türleri ile karşılanacağını, performansa etki edecek olan I/O olarak bilinen veri değerlerini ve günün sonunda organizasyonumuza etki edecek olan toplam sahip olma maliyetlerini hesaplayabiliyoruz. Maliyet kalemleri ilk satın alma ile birmiyor, kullanmış olduğumuz zaman süresince kullanmış olduğu enerji sarfiyatı da bizleri bekliyor

Durum bu kadar karmaşık, en az daha önce paylaşmış olduğum Sunucu Sanallaştırma Platformlarında Bellek Yapılandırması kadar. O makalemizde hedefe ulaşanlara Nobel ödülü verildi mi bilmiyorum ama bir başka konu ile tekrar adayız…

Yukarıda ki resimde paylaşmış olduğum Veri depolama türlerini renklendirdim. Farklı disk türlerinden, farklı teknolojiler ile bir araya getirilmiş veri depolama türlerini sembolize eden renkleri kullandım.

Veri depolama birimlerim arasında bulunan diskler Blue Array olarak göstermiş olduğum ilk disk havuzu en yavaş disklerden oluşan bir disk kümesi olarak düşünmenizi istiyorum. Green Array biraz daha hızlı ve Red array ise en hızlı disk kümesi durumunda. Orrange Array ise disk kümelerim arasında en ucuz ve en yavaş disk kümesi durumunda olan Just a Bunch of Disks olarak bilinen kullan-at disklerinden oluşturulmuş bir küme.

Exchange Server 2016 CU5 Kurulumu makalesi içinde kurulum yolunu varsayılan değerlerde bırakmış ve bu makaleye pası vermiştik. Yukarıda vermiş olduğum ilk resim bu türden oluşturulmuş bir veri depolama havuzu üzerine kurulumu gerçekleştirilmiş bir Exchange Server Mimarisini temsil etmektedir.

Tek bir veri depolama havuzumuz bulunmakta ve bu havuz içinde tek tip diskler bulunmakta. Doğru veya yanlış ihtiyaçlarımızı karşılamakta ve kullanmaktayız.

Her ne kadar yukarıda göstermiş olduğum türdeki kurulum, ihtiyaçlarımızı karşılamış olsa bile bu türden bir kurulum Toplam Sahip olma maliyet olarak adlandırdığımız kurala aykırıdır. Resimde göstermiş olduğum kurulum yöntemi performans ve Exchange server için gereksinim duyulan alanı karşılıyor olsa bile maliyet tarafında yanlış bir tasarıma imza atmış durumdayız.

Resimde göstermiş olduğum üç mavi kutu içinde ki veriler incelendiği zaman farklı performans gereksinimi duyan Exchange server verileridir.

İlk kutu içinde Exchange Server için ihtiyaç duyulan işletim sisteminin barınmış olduğu kutuyu Windows Installed Path gözükmektedir ve biz bu dizini C sürücü ismi olarak bilmekteyiz. Bu kutu içinde Windows Server bileşenleri, Exchange server için ihtiyaç duyulan üçüncü firmaların yazılımları, ajanları (yedekleme, izleme) bulunmaktadır. Bizim Exchange server kurulumunu gerçekleştirmemiz için böyle bir alana ihtiyacımız bulunmakta ve ihtiyaç duymuş olduğumuz alan gereksinimi Windows Server’ in çalışabilecek olduğu alan ve performans gereksinimi kadardır. Bu alanın ihtiyaç duymuş olduğu gereksinim belirli aralıklar ile çalışacak (yedekleme zamanında, izleme zamanında, güncelleştirme zamanında gibi) ve sürekli aynı performans değerlerini kullanmayacaktır. Bu bölüme çok hızlı veri depolama ürünleri ile beslememiz ihtiyaç dışı yapılmış bir yatırım olarak gözükmektedir.

İkinci kutuda ise Exchange server bileşenleri bulunmakta ki resim içinde Exchange Installed Path olarak görebilmektesiniz. Makalemizin ilerleyen bölümlerinden detaylandıracağız. Bu bölüm Exchange server hizmet etmiş olduğu zaman dilimi içerisinde yani her zaman hizmet edecek olan bölümdür.

Bahsetmiş olduğum kullanım değerleri yukarıda paylaşmış olduğum resim içinde gösterilmekte. Her bir bileşen farklı değerlere hizmet etmektedir ve farklı performans ölçülerine sahiptir. Windows bileşenleri ile Exchange Server bileşenlerinin kullanmış olduğu kaynaklar aynı değildir.

Bu türden bir kurulumu yaptığımız zaman ihtiyaçlarımız karşılanmış olsa bile daha önce belirttiğim gibi yanlış bir tasarım sonrasında yanlış bir yatırım yapmış olacağız. Ayrıca şöyle bir riskimizde bulunmakta, Windows bileşenlerinin zaman-zaman kullanmış olduğu yüksek kaynak tüketimi, aynı havuz içinde çalışan Exchange Server etkileyecek ve Exchange server üzerinde oluşan belirli süreli performans problemlerini yaşayacağız.

Çözüm olarak ilk kurulum işlemi anında Windows işletim sistemini kurmuş olduğumuz veri havuzu ile Exchange Server kurulum havuzunu Installation Space and location bölümünde değiştirebiliriz veya bu makale içinde anlatacağım yöntemler ile kurulum sonrasında veya ihtiyaç durumunda değiştire bilirisiniz.

Bu çözüm sonrasında kazanımlarımız performansa ve maliyete ve sağlıklı çalışmaya etki edecektir. Performansa etki etmiş olduğu konular, Exchange Server bileşenleri ihtiyaç duymuş olduğu değerleri kendi disk havuzu içinde kullanacak, Windows Server bileşenleri ihtiyaç duymuş olduğu değerleri kendi disk havuzu içinde kullanmış olacak.

Bu değişiklik sonrasında Windows bileşenlerinin zaman-zaman kullanmış olduğu yüksek kaynak tüketimi Exchange server çalışmasına etki etmeyecek, Exchange Sunucumuz sağlıklı bir şekilde hizmet edecektir.

Maliyete etkisi ise bambaşka bir konu. Makale içinde kullanmış olduğum veri havuzlarını renklere göre ayırmıştım. Windows bileşenleri 1 birim hıza sahip Blue olarak işaret ettiğimiz disk ünitesi üzerinde hizmet etmekte Exchange Server bileşenleri ise 3 birim hıza sahip Red olarak işaret ettiğim disk ünitesi üzerinde hizmet etmekte. Maliyete etkisi Technet üzerinden almış olduğum ilk resim içinde açıklanıyor. Seçimini yapacak olduğunuz her bir disk biriminin ilk satın alma maliyeti ile kullanmış olduğunuz sürece içinde ki Power Utilization değerleri farklılık göstermektedir.

Tasarımımız biraz daha değişti. Veri depolama havuzumuz içine Green olarak işaret ettiğimiz 2 birim hıza sahip Green diskler eklendi. Exchange server bileşenleri incelendiği zaman Exchange Server servisleri farklı kullanım değerlerine sahiptir. Exchange Server 2016 ile birlikte Exchange server bileşenleri tek bir sunucu üzerinde hizmet ediyor olsa bile kendi içinde servis olarak ayrılmış durumdadır. Daha önceki Exchange Server sürümlerinde bu değerleri Rol/sunucu olarak ayırabiliyorduk ama şimdi bütün roller iç-içe geçtiği için servis olarak bu ayrımı yapmamız gerekmektedir.

Exchange server bileşenlerini oluşturan HUB Transport Servisleri, Front-End Servisleri, Edge Servisler, Client Access Servisleri ve Mailbox Servisleri farklı kaynaklara ihtiyaç duymaktadır. Bu son paylaşmış olduğum topoloji içinde veri tabanını barındıran disk havuzu iki birim hıza sahip Green olarak göstermiş olduğum disk havuzu üzerinde barınmaktadır.

Son topolojide paylaşmış olduğum ekran görüntüsünde işleri biraz daha karmaşık duruma getirdim galiba. Exchange Server bileşenleri kendi içinde farklı değerlerde çalışabildiği gibi Windows Server bileşenleri de kendi içinde farklı değerlerde çalışmaktadır.

Windows Server performans Tunning makalesi incelendiği zaman performans ve maliyet çözümleri için ip uçları verilmekte. Windows Server üzerinde yüklü bulunan her bir rol için farklı yapılandırmalar yapılmaktadır. Konumuz bu değil zaten Exchange serverda bir Windows rolu değil ama barınmış olduğu Windows üzerinde ufak dokunuşlar yapmamızı isteyecektir.

Exchange Serverin barınmış olduğu Windows Server üzerinde bulunan Page File yapılandırmasını Windows kurulumunun yapılmış olduğu Blue olarak göstermiş olduğumuz 1 birim hıza sahip veri depolama biriminden 3 birim hıza sahip RED olarak göstermiş olduğumuz veri depolama havuzuna almamız gerekmektedir. Çünkü bu Page file verisi Windows bileşenleri gibi sabit değerlerde kaynak kullanmamaktadır ve kullanım oranına bağlı olarak çok değişken veriler kullanmaktadır. Bu sebepten ötürü Read/Write hızı daha hızlı olan Red veri depolama havuzuna taşımanız Exchange server performansına etki edecektir. Nasıl yapılacağını Smart Paging File ve Page File Farkı Nedir? makalesi içinde paylaşmıştım ve yapılandırma için sizleri bu tarafa davet ediyorum.

Exchange server bileşenleri her bir bileşen seviyesinde farklı değerler kullandığı gibi her bir rolde kendi içinde yapmış olduğu hizmetler çerçevesinde farklı değerler kullanmaktadır. Parçalanmalar hizmet seviyesinde de bulunmakta.

Son topolojimiz içinde 3 birim hıza sahip durumdaki veri depolama havuzumuza Exchange Server Transaction Log larını RED olarak adlandırdığımız 3 birim hıza sahip veri depolama havuzuna taşıdık. Exchange Server veri tabanı üzerinde Circular Logging özelliğini aktif duruma getirmediysek Exchange Server veri tabanı *.edb olmak üzere bir veri tabanı dosyası ve bu veri tabanını besleyen *.log isminde Transaction Log’ lar dan oluşacaktır. Veri tabanımız üzerinde circular logging özelliğini kapatmadıysak veri tabanının sahip olduğu Log’ ları veri tabanının barınmış olduğu veri depolama biriminden daha hızlı bir veri depolama havuzuna taşımamız gerekmektedir.

Topolojimiz içinde yapmış olduğumuz son değişiklik ile veri tabanımızın *.edb sabit verisi 2 birim hızına sahip Green veri depolama havuzu üzerinde çalışırken veri tabanımızın sürekli değişen *.log verisi Red olarak sembolize ettiğimiz veri depolama havuzu üzerinde çalışmakta.

Bu değişiklik veri tabanımızın performansına bire-bir etki etmektedir ve yapacak olduğumuz dizayn ile performansın ötesinde veri tabanımızın sağlıklı çalışması, bakım görevleri ve yedekleme görevlerine etki edecek derin-kapsamlı konuları kapsamaktadır. Bu bölüm için ayrı bir çalışmayı planlamaktayım. Zaten bu makale içinde fark ettiyseniz Orange olarak renklendirdiğim Just a Bunch of Disks lerden oluşan veri depolama havuzundan hiç bahsetmedim.

Exchange Servisleri Veri Depolama Yapılandırması

Exchange 2016 ile birlikte değişen son kullanıcı erişim mimarisi aşağıda paylaşmış olduğum şema içinde gösterilmektedir.

Bu yeni mimariyi iki farklı bölüm altında incelememiz gerekmekte. İlk bölüm daha önceki Exchange server sürümlerinde Client Access Rol olarak bildiğimiz servisler. Bu servisler şemada görüldüğü üzere Http/Https protokolü üzerinden erişim kabul etmektedirler ve arka tarafta kullanmış oldukları Windows bileşeni Web Server (IIS) Rolüdür.

Client Access Servislerinin barınmış olduğu Log dizini varsayılan değerlerde %SystemDrive%\inetpub\logs\LogFiles yolu altında barınmaktadır ve değiştirilebilmektedir.

Şema içinde Client Access Services olarak görmüş olduğunuz Http Proxy ve IIS protokollerinin log dosyaları Default Web Site, Şema içinde Backend Services olarak görmüş olduğunuz IIS, Remote Powershell, Rpc Proxy, RPC CA, EAS, EAC, EWS, OAB ve Outlook protokollerinin log dosyaları Exchange Back End Site’ ları altında bulunmaktadır.

Bu dizin altında kayıt altına alınan verileri W3C Logging Fields bölümünde değiştirebilir ihtiyaç duymuş olduğunuz özel değerleri bu bölümde ekleyebilir-çıkartabilirsiniz. Yapılandıracak olduğunuz her bir tanımlama oluşan olayların kayıt altına alınmasına, kaydedilmesine ve doğal olarak Exchange 2016 mail sisteminin çalışmasına etki edecektir. Exchange sistemini yönetenler zaten bu alanın zaman içinde büyüdüğünü ve temizleme işlemine ihtiyaç duyduğunu bilmektedirler.

Exchange 2016 için değişiklik yapacak olduğumuz ikinci bölüm Transport Services olarak bildiğimiz log dosyalarının barınmış olduğu dizindir. Bu bölümde yapacak olduğumuz değişiklikler Windows bileşenleri olmayıp Exchange Management Shell üzerinden değişiklikleri yapmamız gerekmektedir.

Değişiklikleri yapacak olduğumuz servisler Exchange Trasnport Services, FrontEnd Transport Services, Imap Settings, Mailbox Services Mailbox Transport Services ve Pop Settings dizinleridir.

Not: Mailbox Transport services dosyaları *.edb ve *.log olarak bildiğimiz veri tabanı dosyaları değil SMTP protokolünün sahip olduğu dosyalardır. Exchange veri tabanı dosyaları şema içinde gri renkte bulunan dosyalardır ve bu dosyaların değişikliğini veri tabanı seviyesinde bir başka makale içinde inceleyeceğiz.

Öncelikle değiştirecek olduğum servisler için barınmış olduğu dizini öğrenebilmek için Get-TransportServer | FL Powershell komutu ile servisin sahip olduğu niteliği öğreniyorum. TransportServer komutunu referans olması adına kullandım, diğer servisler içinde log dizininin barınmış olduğu yol *LogPath olarak görülmektedir.

Exchange management Shell komutunu yukarıdaki gibi hazırladıktan sonra organizasyonum içinde bulunan bütün Exchange sunucularına bağlantı gerçekleştiriliyor ve bütün Exchange 2016 sunucuları üzerinde ki Transport Services nin sahip olduğu Log dosyalarını bana getiriyor.

Komutu bu sefer diğer bütün Transport servisleri için düzenledim. Organizasyonum içinde bulunan bütün Exchange 2016 sunucuları üzerinde Transport servis seviyesinde log ların nerede barındığını bilmekteyim.

Artık bütün servislerin barınmış olduğu log yolunu bilmekteyim ve değişiklik yapmak için bunları dışarıya çıkartmam gerekmekte.

Hazırlamış olduğumuz Powershell komutunun özeti, Organizasyonum içinde bulunan bütün Exchange sunucuları üzerinde Transport servislerinin Logpath nitelikleri Komutu çalıştırmış olduğum sunucu üzerinde c:\path.csv altında okunabilir-düzenlenebilir duruma gelecek.

Powershell komutlarının düzenlemesini gerçekleştiren Yusuf Öztürk ve Ümit Seyhan’a teşekkür ederim.

Komut başarılı bir şekilde çalıştı. Ekranda gördüğünüz gibi organizasyonum içinde bulunan bütün Exchange sunucuları (Exchange01 ve Exchange02) Transport Services Log pathleri listelendi.

Dışarıya çıkartılan bütün log dizinlerini Notepad aracı ile görebilmekteyim. Artık Yusuf ve Ümit’e ihtiyacım yok galiba (:

Dışarıya çıkartılmış olan log dizinlerini varsayılan yoldan taşımak istediğim dizin olacak şekilde dizin yolunun ismini değiştirmekteyim.

Get komutları ile dışarıya çıkartmış olduğum log dizinlerinin bulunmuş olduğu CSV içindeki log dizinleri rename edildi ve bir başka yeni komut ile bunlar Exchange Management Shell üzerinden değişiklik yapılmak üzere çalıştırıldı.

Yukarıda görmüş olduğunuz bütün transport services log dizin yolları tek bir power Shell komutu ile değiştirilmiş oldu.

Hazırlanan Powershell komutu içinde Get-Exchangeserver parametresi var ve bu şu anlama geliyor. Bu komut çalışmadan önce organizasyon içinde bulunan bütün Exchange 2016 sunucularını öğreniyor ve değişikliği organizasyon içinde bulunan bütün sunucular için tek bir seferde yapıyor. Bu sebepten ötürü powershell komut dosyasını çalıştırmadan önce organizasyon içinde bulunan bütün Exchange 2016 sunucularının erişilebilir ve değiştirmek istediğiniz Log path dizininin yapılandırmış olduğundan emin olmanız gerekmektedir.

Değiştirmiş olduğumuz yeni log dizinini ve log ların yeni dizinde oluşturulduğundan emin oluyoruz. Yeni loğların yeni dizinde çalışabilmesi için servislerin yeniden başlatılmış olması gerekmektedir.

Hazırlanan powershell aracı problemsiz çalışmakta ve kontrollerini gerçekleştirdikten sonra yeni log dizini üzerinden hizmet ettiğini görebilmektesiniz. Fakat komutlar çalıştırıldıktan sonra Powershell çıktısında birtakım hataları göreceksiniz. Görecek olduğunuz bu hatalar nelerdir, şimdi onları açıklayalım.

Powershell aracının çıktılarında hataları gördüğüm zaman tekrar | FL komutu ile kontrollerini gerçekleştiriyorum. *logpath olarak görülen nesnelerde değişikliğin yapılmadığını gördüğüm nesnelerin özelliklerine bakıyorum.

Hazırlamış olduğumuz Powershell komutlarının değiştiremediği ve işlem sonrasında hata çıktısı ile sonuçlanan dizinlerin değiştirilemeyeceğini ve Microsoft tarafından değiştirilebilecek dizinlerin olduğunu Technet üzerindeki açıklamalarda görebilmekteyiz.

Exchange Log Path Powershell Komut Seti

Makale için kullanmış olduğum Exchange Management Shell Komut setlerine aşağıdan ulaşabilirsiniz.

İlk PS seti, mevcut log dizinleri export edilebilmesi için kullanılacaktır.

$ExportPath = “c:\Path.csv”
$ExchangeServers = Get-ExchangeServer
foreach ( $ExchangeServer in $ExchangeServers)
{

##Transport Service

Get-TransportService -Identity $ExchangeServer.Name | get-member | where Name -like “*LogPath*” |%{
$pathobj = New-Object -TypeName psobject
$values = Get-TransportService -Identity $ExchangeServer.Name | select -ExpandProperty $_.Name
if ($values -ne $null)
{
$pathobj | Add-Member -Name ServerName -Value $ExchangeServer.Name -MemberType NoteProperty
$pathobj | Add-Member -Name Type -Value “TransportService” -MemberType NoteProperty
$pathobj | Add-Member -Name PathName -Value $_.Name -MemberType NoteProperty
$pathobj | Add-Member -Name PathValue -Value $values -MemberType NoteProperty
write-output -InputObject $pathobj
Export-Csv -InputObject $pathobj -Path $ExportPath -NoTypeInformation -Encoding UTF8 -Delimiter “;” -Append
}
}

##FrontendTransportService

Get-FrontendTransportService -Identity $ExchangeServer.Name | get-member | where Name -like “*LogPath*” |%{
$pathobj = New-Object -TypeName psobject
$values = Get-FrontendTransportService -Identity $ExchangeServer.Name | select -ExpandProperty $_.Name
if ($values -ne $null)
{
$pathobj | Add-Member -Name ServerName -Value $ExchangeServer.Name -MemberType NoteProperty
$pathobj | Add-Member -Name Type -Value “FrontendTransportService” -MemberType NoteProperty
$pathobj | Add-Member -Name PathName -Value $_.Name -MemberType NoteProperty
$pathobj | Add-Member -Name PathValue -Value $values -MemberType NoteProperty
write-output -InputObject $pathobj
Export-Csv -InputObject $pathobj -Path $ExportPath -NoTypeInformation -Encoding UTF8 -Delimiter “;” -Append
}
}

##MailboxServer

Get-MailboxServer -Identity $ExchangeServer.Name | get-member | where Name -like “*LogPath*” |%{
$pathobj = New-Object -TypeName psobject
$values = Get-MailboxServer -Identity $ExchangeServer.Name | select -ExpandProperty $_.Name
if ($values -ne $null)
{
$pathobj | Add-Member -Name ServerName -Value $ExchangeServer.Name -MemberType NoteProperty
$pathobj | Add-Member -Name Type -Value “MailboxServer” -MemberType NoteProperty
$pathobj | Add-Member -Name PathName -Value $_.Name -MemberType NoteProperty
$pathobj | Add-Member -Name PathValue -Value $values -MemberType NoteProperty
write-output -InputObject $pathobj
Export-Csv -InputObject $pathobj -Path $ExportPath -NoTypeInformation -Encoding UTF8 -Delimiter “;” -Append
}
}

##MailboxTransportService

Get-MailboxTransportService -Identity $ExchangeServer.Name | get-member | where Name -like “*LogPath*” |%{
$pathobj = New-Object -TypeName psobject
$values = Get-MailboxTransportService -Identity $ExchangeServer.Name | select -ExpandProperty $_.Name
if ($values -ne $null)
{
$pathobj | Add-Member -Name ServerName -Value $ExchangeServer.Name -MemberType NoteProperty
$pathobj | Add-Member -Name Type -Value “MailboxTransportService” -MemberType NoteProperty
$pathobj | Add-Member -Name PathName -Value $_.Name -MemberType NoteProperty
$pathobj | Add-Member -Name PathValue -Value $values -MemberType NoteProperty
write-output -InputObject $pathobj
Export-Csv -InputObject $pathobj -Path $ExportPath -NoTypeInformation -Encoding UTF8 -Delimiter “;” -Append
}
}

##IMAP Settings

Get-ImapSettings -Server $ExchangeServer.Name | get-member | where Name -like “*LogFileLocation*” |%{
$pathobj = New-Object -TypeName psobject
$values = Get-ImapSettings -Server $ExchangeServer.Name | select -ExpandProperty $_.Name
if ($values -ne $null)
{
$pathobj | Add-Member -Name ServerName -Value $ExchangeServer.Name -MemberType NoteProperty
$pathobj | Add-Member -Name Type -Value “ImapSettings” -MemberType NoteProperty
$pathobj | Add-Member -Name PathName -Value $_.Name -MemberType NoteProperty
$pathobj | Add-Member -Name PathValue -Value $values -MemberType NoteProperty
write-output -InputObject $pathobj
Export-Csv -InputObject $pathobj -Path $ExportPath -NoTypeInformation -Encoding UTF8 -Delimiter “;” -Append
}
}

##POP Settings

Get-PopSettings -Server $ExchangeServer.Name | get-member | where Name -like “*LogFileLocation*” |%{
$pathobj = New-Object -TypeName psobject
$values = Get-PopSettings -Server $ExchangeServer.Name | select -ExpandProperty $_.Name
if ($values -ne $null)
{
$pathobj | Add-Member -Name ServerName -Value $ExchangeServer.Name -MemberType NoteProperty
$pathobj | Add-Member -Name Type -Value “PopSettings ” -MemberType NoteProperty
$pathobj | Add-Member -Name PathName -Value $_.Name -MemberType NoteProperty
$pathobj | Add-Member -Name PathValue -Value $values -MemberType NoteProperty
write-output -InputObject $pathobj
Export-Csv -InputObject $pathobj -Path $ExportPath -NoTypeInformation -Encoding UTF8 -Delimiter “;” -Append
}
}

}

Aşağıdaki paylaşmış olduğum ikinci Exchange Management shell komut seti ise dışarıya export etmiş olduğunuz CSV dosyasını değiştirdikten sonra CSV dosyası içinde yapmış olduğunuz değişiklikleri okuyup sistem üzerinde değişiklik yapacak olan komut setidir.

$Path = “C:\Path.csv”
$FilePath = “C:\”
$FileName = “Script.ps1”
$CreateScriptPath = $FilePath + $FileName
$PS = Import-Csv -Delimiter “;” -Path $Path
foreach ( $P in $PS )
{
if ($P.Type -eq “TransportService”)
{
[String]$Value = $P.PathValue
$Script = “Set-TransportService” + ” -Identity ” + $P.ServerName + ” -” + $P.PathName + ” ” + “‘$Value'”
Write-Output $Script
$Script | Out-File -FilePath $CreateScriptPath -Append
}
If ( $P.Type -eq “FrontendTransportService” )
{
[String]$Value = $P.PathValue
$Script = “Set-FrontendTransportService ” + ” -Identity ” + $P.ServerName + ” -” + $P.PathName + ” ” + “‘$Value'”
Write-Output $Script
$Script | Out-File -FilePath $CreateScriptPath -Append
}
If ( $P.Type -eq “MailboxServer” )
{
[String]$Value = $P.PathValue
$Script = “Set-MailboxServer” + ” -Identity ” + $P.ServerName + ” -” + $P.PathName + ” ” + “‘$Value'”
Write-Output $Script
$Script | Out-File -FilePath $CreateScriptPath -Append
}
If ( $P.Type -eq “MailboxTransportService” )
{
[String]$Value = $P.PathValue
$Script = “Set-MailboxTransportService” + ” -Identity ” + $P.ServerName + ” -” + $P.PathName + ” ” + “‘$Value'”
Write-Output $Script
$Script | Out-File -FilePath $CreateScriptPath -Append
}
If ( $P.Type -eq “ImapSettings” )
{
[String]$Value = $P.PathValue
$Script = “Set-ImapSettings” + ” -Server ” + $P.ServerName + ” -” + $P.PathName + ” ” + “‘$Value'”
Write-Output $Script
$Script | Out-File -FilePath $CreateScriptPath -Append
}
If ( $P.Type -eq “PopSettings” )
{
[String]$Value = $P.PathValue
$Script = “Set-PopSettings” + ” -Server ” + $P.ServerName + ” -” + $P.PathName + ” ” + “‘$Value'”
Write-Output $Script
$Script | Out-File -FilePath $CreateScriptPath -Append
}
}
$word = “‘”
$replacement = ‘”‘
$text = get-content $CreateScriptPath
$newText = $text -replace $word,$replacement
$newText > $CreateScriptPath
cd\
cd “$FilePath”
.\Script.ps1