Exchange Server Sorun Çözümü için Kolay Log Toplama Yöntemi – Exchange Log Collector Script

Özellikle Exchange Server 2013 sonrasında loglama alt
yapısında pek çok değişiklik oldu. Özellikle kendi kendine yönetim ve
iyileştirme politikasının bir ürünü olan “Managed Availability” kavramını çok
ciddi manada sistemin log üretmesine neden oldu.

http://www.cozumpark.com/blogs/exchangeserver/archive/2015/03/01/exchange-server-2013-managed-availability.aspx

Öncelikle 2010 uzmanları bu loglar ile sık sık dolan C
disklerinden dolayı tanıştı, daha çok neden bu kadar çok log üretildiğini
araştırdılar, sonuca ulaşınca ise genelde otomatik temizleme komutlarını
zamanlanmış görev yapıp sorundan kurtuldular. Ancak gelin görün ki zaman
içerisinde sorun çözümlemek için bu logların hayati önemi olduğunu anladılar.
Durum böyle olunca logların silme sürelerini en azından son 7 günden 30 güne
yükselttiler. Buraya kadar hayat güzel gidiyordu ancak yine başka bir sorun ile
karşı karşıya kaldık. Çok büyük yapılarda özellikle bildiğiniz gibi sorunların
çözülmesi için yeniden kurmak, silmek tekrar oluşturmak gibi kobi çözümleri çok
kabul edilen çözümler değildir. Şimdi bir kobi çalışanı iseniz sakın alınmayın
bu sektörün bir gerçeği. Bende kobide çalıştım ve çok iyi biliyorum. Eğer sarf
edeceğiniz efor, alacağınız danışmanlığın ücreti karşılığını bulmayacak ise bu
kadar uzman bir personel veya danışmana gerek yoktur. Ancak bir mail kesintisi
ile milyonları kaybeden veya kaybedeceği prestijin telafisi olmayan kurumlar
için bu tarz iletişim alt yapılarındaki kesiniler kabul edilemez. Bir sorunun bu
nedenle kök neden araştırması çok önemlidir. Bir uzman olarak sizlerin de çok
iyi bildiği gibi sorun çözmek için öncelikle teşhisi iyi koymak lazım, bunun
için de iyi bir analiz yani log okumak lazım. Makalemin başında anlattığım
dağınık yapı itibari ile büyük bir exchange sunucu ortamı için bu kadar bilgiyi
toplamak son derece zor olacaktır.

Ama her türlü zorlukta imdadımıza yetişen powershell
burada da hayatımızı kurtarıyor. Aşağıdaki linkten edineceğiniz log collector
komut seti sayesinde tüm exchange loglarını merkezi olarak alabilir ve daha
sonra sorun çözümlemek için kullanabilirsiniz.

https://github.com/dpaulson45/ExchangeLogCollector

Peki nasıl kullanıyoruz. Öncelikle bildiğiniz gibi
exchange server çok fazla log üretiyor ve siz merkezi olarak birden çok sunucu
log dosyasını bir sunucu üzerine toplamak istiyorsanız öncelikle yeterli boş
alanınızın olduğunu kontrol edin. Benim tavsiye yanlış hesaplama durumuna
karşılık C diskinizin dolması = işletim sisteminizin her an mavi ekran vermesi
ve bir daha normal açılmamasına yol açabilir. Ondan en temizi bir yönetim
sunucusu gibi bir sunucuda komutu çalıştırmanız veya gerçekten yeterli
yerinizin olduğundan emin olduktan sonra çalıştırmanızı öneririm.

İlk komutumuz aşağıdaki gibidir;

.\ExchangeLogCollector.ps1 -AllPossibleLogs

Bu komutu çalıştırdıktan sonra komutu çalıştırdığınız
sunucu üzerindeki tüm varsayılan logları toplayıp aşağıdaki dizine
yerleştirecektir;

C:\MS_Logs_Collection

Not: Ortalama 1000 kullanıcı ve iki MBX sunucu olan bir
exchange server ortamında tek bir sunucu için bu komut ortalama 30GB log
topladı, tabiki bu sizin kullanıcı, mail alma gönderme sayısı, ekleri, DAG
yapısı vb pek çok değişkene göre değişir ancak fikir vermesi açısından
paylaşmak istiyorum ki olası bir disk boş yer sorunu yaşamayın.

clip_image002

Bir uyarı sonrası “y” tuşuna basarak toplama işlemi
için onay verebilirsiniz.

clip_image004

Not: remote toplama için exchange server minimum 2012
ve üstü bir OS de çalışmalı. 2008 ve 2008 R2 üzerinde ise bu log toplama
işlemini remote yapamazsınız.

clip_image006

Log toplama işlemi başladı.

Okumaya devam et

Azure Compute Hizmetleri için Karar Ağacı – Decision tree for Azure compute services

Bir uygulamanız var ve siz bunu azure üzerinde
konumlandırmak istiyorsunuz. Azure compute başlığı altında aslında size pek çok
hizmet sunmaktadır. Ancak kimi zaman bu hizmet çeşitliliği kafa karışıklığına
neden olabilmektedir. “Decision Tree” olarak isimlendirdiğimiz aşağıdaki akış
şeması işleri biraz daha sadeleştiriyor.

Bu akış şemasını başlangıç noktası olarak ele alın. Her
uygulamanın kendine özgü gereksinimleri vardır, bu nedenle öneriyi bir başlangıç
noktası olarak kullanın. Daha sonra, daha ayrıntılı bir değerlendirme yapın ve
aşağıdakilere bakın:

·         Feature set

·         Service limits

·         Cost

·         SLA

·         Regional availability

·         Developer ecosystem and team skills

·         Compute comparison tables

Bunlar aslında bir uygulamayı bulut üzerinde
çalıştırmak için bilmeniz gereken en temel parametrelerdir.

Eğer kompleks uygulamalarınız var ise yani uygulamanız
çoklu iş yüklerinden oluşuyorsa, her iş yükünü ayrı ayrı değerlendirin. Tam bir
çözüm belki iki veya daha fazla cumpute hizmeti ile sunulabilir.

clip_image002

Peki bu akış şeması bize ne anlatıyor? Öncelikle iki
temel tanımımız var bunları biliyor olmalıyız.

Greenfield

Greenfield yazılım veya dağıtım, daha önce hiç
bulunmayan bir kurulum ve / veya yapılandırmadır. Yani sıfırdan inşa etmeye
başladığınız projeler için kullanılır.

Brownfield

Bir brownfield dağıtımı, var olan bir altyapıya
yükseltme veya ekleme anlamına gelir. Yani yeni bir proje değil var olan bir
proje veya var olan bir proje için güncelleme, değişiklik anlamına
gelir.

Örnek yeni bir proje yapıyor olun, bu durumda ilk
sorunun cevabı YES olacaktır yani sağ bölüm ile devam ediyoruz;

clip_image003

İlk soru çok basit aslında, bu yazılım, dağıtım, proje
için tüm kontrolün sizde olması mı gerekiyor. Yani kuracağınız OS’ den tutun,
IIS veya .net bileşenleri vb? Eğer bu sorunun cevabı YES ise bu durumda sizin
için en iyi çözüm Azure üzerinde IaaS bir hizmet almanızdır. Yani sanal makine
hizmeti almanız yeterlidir.

Peki böyle bir gereksinim yok ise No diyerek bir alt
bölüme inebilirsiniz.

High performance computing workloads, yani yüksek
performans gerektiren iş yükleriniz olacak mı?

Azure, bulutta büyük paralel ve toplu hesaplama
işlerini çalıştırmanızı sağlayan ve isteğe bağlı kolay bir şekilde
genişleyebilen bilgi işlem kaynaklarını sağlamaktadır.  Eğer böyle bir ihtiyaç var ise bu durumda Azure Batch kullanımı olacak
demektir.

Azure batch sayesinde büyük ölçekli paralel ve yüksek
performanslı bilgi işlem (HPC) işlerini verimli bir şekilde yönetebilirsiniz.
Temel olarak azure batch sanal makinelerden oluşan bir compute pool oluşturur ve
yönetir, istediğiniz uygulamaları yükler veya yine istediğiniz işleri zamanlar
ve çalıştırır. Bu sayede cluster veya zamanlanmış görevler için ayrı
uygulamalara ihtiyaç duymazsınız. Sadece Azure batch için yayınlana API’ leri
veya araçları kullanmanız yeterlidir.

clip_image005

Peki HPC ihtiyacı yok ise bu durumda yine No diyerek
bir alt bölüme inebilirsiniz.

clip_image006

Aslında konuyu adım adım ve uzun uzadıya anlatmaya
gerek yok sanırım. Son bu örnek ile konuyu bağlamak istiyorum. Bir sonraki
sorumuz bir mikroservis kullanacak mısınız?

Eğer yeni nesil bir yöntem olan yazılım geliştirmede
son dönemde sıklıkla gördüğümüz mikro servis kullanımı olacak ise yine işler
değişiyor. Eğer bir yazılımcı iseniz zaten Monolithic ve MicroService farklarını
burada anlatmamın bir anlamı olmaz. Ama özetle bir birinden daha bağımsız ve
esnek parçalardan oluşan bir proje istiyorsanız mutlaka Micro Service
kullanılmaktadır. Bu sayede yazılım ekipleri bir birinden daha bağımsız kod
geliştirmekte ve hatta deployment yapabilmektedir. Genişletilmesi daha kolay ve
bağımsız olur. Eğer sizin uygulamanızda da micro servis olacak ise bu durumda
App Service kullanıyor olmanız gerekmektedir.

Evet, uzun lafın kısası alında Microsoft bence çok
güzel bir akış diyagramı ile aslında bizlere ne tür uygulamalar için azure
üzerinde ne tür hizmetleri kullanabileceğimizi veya kullanmamız gerektiğiniz
bize özetliyor. Bu sayede aslında azure üzerinde koşacak uygulamalar içinde
daha doğru bir maliyet hesabı yapılmış olur.

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

Kaynak

http://www.cozumpark.com/blogs/cloud_computing/archive/2018/06/04/azure-compute-hizmetleri-icin-karar-agaci-decision-tree-for-azure-compute-services.aspx

 

 

Windows 10 Makinelerde Scaling Level Ayarlarının GPO ile Yapılması

Her geçen gün teknolojik yenilikler ile beraber
hayatımıza yeni nesil ürünlerin girdiği bir dönemde özellikle görüntüleme
teknolojilerinde de ne popüler konulardan birisi 4K. Malum ilk HD, Full HD gibi
teknolojiler çıkınca bir hayli popüler olmuş sonrasında ise artık hepimizin bir
şekilde kullandığı televizyon, monitör veya laptop’ ın bu teknolojileri
desteklediğini gördük. Şu anda 4K görüntüleme teknolojisi de özellikle yurt
dışında çok popüler olmak ile beraber Türkiye de ihtiyaçları doğrultusunda
personeline bu yönde monitör veya bilgisayar alan şirketler bulunuyor. Buradan
yola çıkarak özellikle 4K monitör veya laptop kullanıcıların ilk deneyimleri çok
önemli.

Bundan önce 4K çözünürlükte bir monitör veya bilgisayar
kullanmayanlar için ilk sorun alışkın oldukları ikonların ve yazıların farklı
boyutta olmasıdır.

Aslında Windows 10 ile beraber bu konuda çok güzel bir
çözüm sunulmuştu, DPI (İnç Başına Nokta);

Metin ve pencerelerin boyutundan DPI (İnç Başına Nokta)
ayarı sorumludur. Kullanıcılar metin ve pencerelerin, nesnelerin daha küçük veya
daha büyük görünmesini sağlamak için bu ayarları kendileri değiştirebilirler.
Buna ek olarak Windows 8.1 ile hayatımıza giren ve son derece pratik olarak
çözünürlük işini kolaylaştıran “Scaling Level” kavramı ile tanıştık.

clip_image001

Scaling Level yukarıdaki gibi basit bir şekilde
ayarlanabilmektedir.

Aşağıdaki tablo ise çözünürlük ve scaling level
arasındaki ilişkiyi göstermektedir.

clip_image003

Örneğin 4K çözünürlük olan QFHD (4K) için Microsoft
scale level olarak %200 öneriyor, çünkü genelde 1920×1080 pek çok kişi için
kabul edilen ideal orandır. Tabiki bu tercih size kalmış.

Okumaya devam et

Exchange Server 2019 Yenilikleri

24-28 Eylül tarihlerinde Orlando da düzenlenen
Microsoft Ignite etkinliği ile beraber pek çok yeniliği de gün yüzüne çıkan
Exchange Server 2019 artık yavaş yavaş şirketlerin yeni proje listelerine
girmeye başladı. Etkinliğe katılma ve bu özellikleri özellikle ürün
yöneticilerinden duymak büyük heyecan vericiydi. Aslında o kadar çok yenilik
var ki bunların hepsini gerçekten öğrenmek ve yazmak açıkçası biraz zaman aldı.
Özellikle ignite sırasında yapılan sunumlardaki bazı bilgileri gerçekten henüz
Microsoft kaynaklarında bulmak mümkün değildir, bu nedenle de özellikle bazı
konularda ürün yöneticileri ile mailleşmem gerekti. Tabiki mevcut sunumları
izleyerek aslında temel yenilikleri aşağıdaki gibi herkes
özetleyebilir;

clip_image002

Ama malum ben ürünleri gerçekten çok iyi derecede
anlamadan, kurmadan ve özellikle canlı ortamda tecrübe etmeden çok yazmak
istemiyorum. Tabiki bazen malum Google bizi daha çok sevsin diye bazı bilgileri
çok erken vermek adına paylaşımlarımız olsa da en azından Exchange Server 2019
için gerçekten kaputun altında ne var dedirtecek sorulara sahip yenilikler için
yazma zamanı gelmişti.

Peki Exchange Server’ da neler yeni? Aslında yukarıdaki
paylaştığım görsel tüm konuyu özetliyor ama bu makaledeki amacım biraz daha
sunumdan öte şeyleri paylamak olacaktır.

Yeni özelliklere geçmeden önce bence en büyük yenilik
Exchange Server 2019 ürününün sadece Volume Lisanslama hakkına sahip olan
müşteriler tarafından kullanılabileceğidir. Burada aslında Microsoft vizyonunu
ortaya koyuyor. Herkes buluta geçerken on-prem de devam eden müşterilerin VL
hakkı olmalı yoksa Kobi ve benzeri neden Exchange Server gibi bir yükün altına
girsin ki diye düşünüyor? Bence de haklı aslında. Yani sunucu lisansı, istemci
lisansı, OS lisansı, yedekleme yazılımı, arşivleme, disk, server, anti spam
gateway lisansı, bakım maliyetleri derken bu işi zaten büyük kurumlar götürür.
Bu da aslında bir sonraki sürümün belki çıkmayacağı, çıksa bile bu kullanım
şartlarının daha da sınırlanacağının bir işareti bence.

Yeni özellikleri aşağıdaki başlıklar halinde
inceleyebiliriz;

Security

Windows Server Core support

Block external access to Exchange admin center (EAC)
and the Exchange Management Shell

Performance

Improved search infrastructure

Faster, more reliable failovers

Metacache database

Modern hardware support

Dynamic database cache

Clients

Calendar-Do Not Forward

Calendar-Better Out of Office

Calendar-Remove-CalendarEvents cmdlet:

Assign delegate permission via PowerShell

Email address internationalization (EAI)

İlk olarak güvenlik özelliklerini
detaylandıralım.

Güvenlik Yenilikleri

Okumaya devam et

Active Directory Güvenliği için 10 Temel Öneri


Günümüzde güvenlik her şirket için önemli bir başlık
olmasına karşın güvenlik konseptinde derinlik ne yazık ki temel anlamda
firewall, anti virüs, son dönemde DLP gibi ana başlıklardan daha derine
inemiyor. Özellikle çok fazla bütçe ve uzman ile kurulan banka ortamlarında
bilen yaşanan büyük zafiyetlerin aslında uygulama temelli zafiyetler olduğunu
gördükçe güvenlik algısının sadece yüzeysel ürün temelli değil uygulama bazlı
yapılması gerektiğini bir kez daha görmüş oluyoruz.

Peki her uygulama için güvenlik sıkılaştırma çalışması
yapılabilir mi? Pek çok global üretici için uygulamalarının en iyi güvenlik
çözümleri, yapılandırmaları veya birlikte çalışma senaryoları bulunmaktadır,
ancak özellikle büyük şirketler için bunları tek tek hayata geçirmek var olan
karmaşık yapıyı daha içinden çıkılmaz bir hale sokabileceği gibi bütçe ve zaman
açısından yönetimi zordur. Bundan dolayı özellikle zafiyet testleri sonucunda
kritik uygulamalar hedef alınır. Ancak küçük şirketler için ne yazık ki zafiyet
taramalarının bütçesinin bile bulunması sorun olabiliyor. Madem öyle daha
minimal yapılar için neler önerebiliriz?

Tabiki bu işin doğrusu öncelikle bir veya bir den çok
uzman ile mevcut yapı için zafiyet testlerinin uygulanması, sonuçlarının
değerlendirilmesi, uygulanması ve bu zafiyetlerin kapatıldıktan sonra tekrar bir
test yapılmasıdır. Hatta buna ek olarak “security hardening” olarak bilinen ve
yine büyük kurumlar tarafından özellikle OS seviyesinde yaptırılan sıkılaştırma
çalışması sayesinde testlerde çıkmayan ancak üreticilerin önerdiği en iyi
yapılandırmaları gerçekleştirerek güvenlik seviyenizi daha yukarılara
çekebilirsiniz.

Bende pek çok müşterime aslında bu noktada herhangi bir
ürün almadan yardımcı olmak için sağlık taraması adı altında hizmet sunmaktayım.
Bu makaledeki amacım da bu sağlık taraması kapsamında yaptığım çalışmaların bir
bölümü olan Active Directory için güvenlik anlamında neleri kontrol etmeniz ve
nasıl yapılandırmanız gerektiğini paylaşmaktır. Günün sonunda sağlık taraması
sadece 27001, KVKK, güvenlik gibi başlıkları değil aynı zamanda sisteminizin ne
kadar sağlıklı çalışıp çalışmadığını ve kritik bulguların olup olmadığını
görmeniz için alabileceğiniz bir servis.

Bunu yapan ya da aslında yaptığını iddia eden pek çok
araç görebilirsiniz. Ancak birkaç temel rapor ve pasta dilimi görseller ile
kritik alt yapılarınız için yorum yapmanız doğru olmayacaktır. Nasıl zafiyet
tarama ürünlerinin olmasına karşın Pentest adı altında uzman danışmanlara ücret
ödeyip gerçek hayat senaryolarının sisteminiz üzerinde denenmesini sağlıyorsanız
yine bir uzmanın sizin yaşayan bu sisteminiz için yorum yapması çok
kıymetlidir.

Peki gelelim konumuza, güvenli bir Active Directory
için nelere dikkat etmemiz gerekiyor?

1 – Varsayılan Hesapların Kapatılması veya
Değiştirilmesi

Öncelikle ne yazık ki hala pek çok sistem yöneticisi
Active Directory ile beraber gelen Administrator olarak isimlendirilen
varsayılan hesap ile sistemlerini yönetmektedir. Bu pek çok ransomware başta
olmak üzere uzak erişim ve sonrasında verilerin şifrelenmesi ile sonuçlanan
atakları kolaylaştırmaktadır. Çünkü hala pek çok şirket dış dünyaya RDP açık
sistemler barındırmakta ve hele varsayılan kullanıcı ile bu sistemleri yönetiyor
ise zaman içerisinde şifre deneme yanılma yolu ile kolaylıkla bu sistemlere
sızmak mümkündür. Sadece ransomware değil pek çok hak yükseltme, içeriden gelen
ataklarda da varsayılan admin hesapların kullanılması büyük zafiyetlere neden
olmaktadır. Bu nedenle ilk olarak varsayılan Administrator hesabının
kopyalanarak yeni bir yönetici hesabı oluşturulması ve mevcut yönetici hesabının
tüm yetkilerinin alınması gereklidir. Bu sayede örneğin “Hakan” isminde standart
bir user olarak görünen ama oysaki “Administrator” hesabının yerine geçen yeni
bir yönetici hesabınız olacaktır. Mevcut hesabı bu şekilde kopyalayacak
uzmanlığınız yok ise en kötü “rename” yani Administrator yerine “hakan”
kullanarak” en azından varsayılan brüte force şifre bulma atakları için öne
geçebilirsiniz.

clip_image002

2 – Yönetici Hesapları Ayrıştırılması

Bir diğer sık yaptığımız hata ise tek bir kullanıcı
hesabı ile hem kişisel bilgisayarımızı hem Forest/Domain ortamını yönetiyor
olmamız. Burada her şirket için farklı çözüm oluşturabileceğimiz gibi en iyi
senaryo olarak kendi bilgisayarımız için “hakan”, uzak son kullanıcı
bilgisayarlarını yönetmek için “wrk_hakan”, domain ortamındaki sunucuları
yönetmek için “srv_hakan” ve Active Directory, Exchange, CA Server gibi kritik
alt yapı sunucuları için “ent_hakan” kullanıcı hesaplarını oluşturmanız ve en
önemlisi de örneğin srv_hakan kullanıcısının veya buna bağlı grubun üyelerinin
herhangi bir son kullanıcı bilgisayarına giriş yapmasına izin vermemeniz
gereklidir. Benzer şekilde ent_hakan da DC, Exchange gibi sunucuların dışında
herhangi bir sunucuya login olmamalıdır. Ayrıca varsayılan olarak gelen domain
admins grubu tüm bilgisayarlarda local admin olduğu için onu da kaldırmanız ve
son kullanıcı makineleri, sunucular için ayrı lokal admin grupları oluşturmanız
şarttır.

3 – Kritik Grup Üyeliklerinin Kontrolünün
Sağlanması

Güvenlik emek ister tabiki gönül ister ki hiç ürün
satın almayalım ancak bazı noktalarda temel Audit veya siem ürünleri güvenlik
için şart. SIEM belki bu madde için çok lük kalabilir ancak lepide gibi uygun
maliyetli bir Audit ürünü ile AD kritik grupların üyelik güncellemelerini
mutlaka takip etmeniz gereklidir. Bu sayede olası bir hak yükseltme veya 2.
Maddedeki senaryoyu bozan bir yönetici olması halinde bundan mutlaka haberdar
olmanız gereklidir.

clip_image004

4 – Lockout Policy

Çok temel bir policy olmasına karşın hala çok büyük
yapılarda bile Lockout policy olmadığına sağlık taraması çalışmalarım sırasında
karşılaştım. Bunun tabiki yönetimi bir hayli zor olduğu için her müşterinin
farklı bir yorumu bulunur ancak tartışmasız en temel Active Directory güvenlik
önlemi lockout policy uygulanmasıdır.

clip_image006

 

5 – Password Policy

Çok temel bir bilgi olduğu ve artık bu konuda çok ciddi
farkındalık olduğu için üzerinde çok durmayacağım, ancak burada önemli olan
nokta eğer yetkili hesap segmentasyon yapmışsanız tek sorun yöneticinizin sahip
olduğu tüm hesaplara aynı şifreyi vermesi olacaktır ki bunu engellemezseniz
aslında sizin herhangi bir ürün almadan sağladığınız hak yükseltme koruma
özelliğiniz bir anda çöp olabilir.

clip_image008

6 – Eski Kullanıcı ve Makine Hesaplarının
Temizlenmesi

Ne yazık ki pek çok sağlık taramasında bu noktanın
düzenli olarak yapılmadığını görüyoruz. Banka, Telekom veya global firmalar gibi
düzenli denetlenen firmaların dışında ne yazık ki işten ayrılmış kullanıcı
hesaplarının hala aktif olarak kaldığını görebiliyoruz. Burada gerek makine
gerekse kullanıcı hesaplarının düzenli kontrol edilmesi ve gereksiz olan
hesapların önce disable, daha sonra şirket politikasına göre silinmesi
güvenliğinizi arttıracak adımlardan birisi olacaktır.

clip_image010

7 – Düzenli Yama Yüklenmesi

Çok geleneksel olacak ama OS seviyesinde çıkan kritik
yamalar Active Directory ortamınız için çok büyük risk doğurabilir. Sadece OS
seviyesinde değil özellikle son dönemde gördüğümüz CPU zafiyetleri de ne yazık
ki çok ciddi güvenlik zafiyetlerine neden olduğu için aslında AD ortamınızı
üzerinde barındırdığınız donanımların firmware yüklemelerinden OS yamalarına
kadar güncel bir sistem kullanıyor olmanız gerekli. Şimdi yama yüzünden kesinti
yaşan müşterilerin “aman hocam bana yama deme” dediğini duyar gibiyim ama yine
hep dediğim gibi pilot dağıtım, test yapmadan yapılan her yama hangi sisteme
olur ise olsun büyük bir zarar verme potansiyeli taşır. Bu üreticilere göre
farklılık göstermek ile beraber bu kötü tecrübeler ne yazık ki sistemlerimizi
bilinen zafiyetlere karşı korumasız bırakmamız için bir bahane olamaz. Yama
yönetimi aslında başlı başına ayrı bir konu olduğu için bunu da geçiyorum
şimdilik.

clip_image012

8 – Çoklu Kimlik Doğrulama

Active Directory gibi sistemlere erişimlerin
sınırlanması ve hatta bu tür sistemlere giriş yapabilecek makinelere ise smart
card gibi ek güvenlik önlemleri ile girebiliyor olmanız ayarlanmış olması
gereklidir. Örneğin bizim en değerli varlıklarımızdan birisi olan mali
varlığımıza erişirken nasıl kimse sms veya benzeri ikinci doğrulama
mekanizmalarından vazgeçmiyor ise bir şirket için verilerde en değerli varlıklar
olduğundan suyun başındaki konumu nedeni ile AD erişimleri mutlaka MFA – 2FA
cihazları ile desteklenmelidir.

Bu basit bir örnek

http://www.cozumpark.com/blogs/donanm/archive/2018/08/05/yubikey-for-windows-hello-ile-guvenliginizi-arttirin.aspx

clip_image014

9 – İzleme

Aslında grup değişiklikleri izlenmesi başlığında izleme
noktasının öneminden bahsetmiştim, ancak bu çok özel bir izleme örneği olup her
şirketin bunu yapması bazen mümkün olmuyor, ancak bu maddeyi gerçekleştiremiyor
olsanız dahi genel olarak AD üzerindeki GPO, DNS, AD değişikliklerinden mutlaka
haberdar olmanız gerekli, aksi halde bu maddeye kadar yapmış olduğunu pek çok
değişiklik kötü amaçlı olarak geriye doğru değiştirilebilir ve bundan haberiniz
olmayabilir. Bu konuda Lepide, Netwrix, Manage Engine, Change Auditor gibi pek
çok Audit yazılımı kullanabilirsiniz. Tabiki sahip olduğunuz SIEM’ i eğiterek
kritik durumlar için yine log üretmesini sağlayarak bu ihtiyacı
karşılayabilirsiniz ama benim her zaman tercihim AD, Exchange gibi kritik
servisler için özelleşmiş Audit yazılımları almak olacaktır. SIEM olsun bana bir
zararı yok hatta tüm logları topluyor süper ama T anında o SIEM den istediğim
bilgiyi almak bazen zor bazen imkânsız olabiliyor.

10 – Yedekleme ve Felaket Senaryosu

Evet en iyi güvenlik önlemlerinden biriside tabiki çok
sağlam bir yedeğinizin olması. Veya olası bir saldırı, şifre ele geçirme ya da
servis kesintisi gibi ataklar için geri dönüş planınızın olmasıdır. Buna sahip
iseniz pek çok beklenmedik saldırı için kurtarma senaryonuz hazır
olacaktır.

Evet, elimden geldiği kadar basit olarak bir
farkındalık makalesi hazırlamaya çalıştım. Tabiki benden 27001 özelinde, KVKK
veya temel sağlık taraması alan müşterilerimin sadece Active Directory için 184
noktaya baktığımı biliyorlar, yani bu işin hepsini burada makaleye dökmek ne
yazık ki çok ciddi bir zaman alacağı için ben en azından böyle hizmetler veya
ürünler alamayan pek çok kobi çapındaki firmalar için yardımcı olmak amacı ile
bu bilgilerimi paylaştım. Ancak daha ciddi iş ihtiyaçlarınız ve bütçeniz var
ise tabiki benim gibi bir uzmandan böyle profesyonel bir tarama hizmeti ile
durum rapor edinmeniz ve sonrasında da ister mevcut ekipleriniz ile, iste
danışmanlarınız ile iyileştirme çalışmasını Active Directory gibi kritik tüm
sistemler için yapmanızı öneririm.

 

Kaynak

http://www.cozumpark.com/blogs/windows_server/archive/2018/10/07/active-directory-guvenligi-icin-10-temel-oneri.aspx

 

 

Exchange 2019 Client Access Rules

Exchange Server 2019 duyurulması ile beraber bizlerde
hızlı bir şekilde yeni özelliklerini sizler ile paylaşmaya başladık. Aslında
geçen hafta yeni özelliklerinin nerede ise tamamına yakınını aşağıdaki makalede
sizler ile paylaştım

http://www.cozumpark.com/blogs/exchangeserver/archive/2018/10/14/exchange-server-2019-yenilikleri.aspx

Ancak burada özellikle bazı teknolojiler için ayrı
makaleler yazacağımı da belirtmiştim. Client Access Rule özelliği de bu
teknolojilerden birisi.

Peki daha önce kullanmadığımız ve Exchange 2019 ile
beraber gelen bu yeni özellik nedir?

Client Access Rule, temel olarak Exchange 2019
organizasyonunuzu yönetmek için kullandığınız Exchange admin center (EAC) ve
remote PowerShell erişimlerini sınırlandırmak için kullanılır. Hub transport
kurallarına benzeyen bu kurallar sayesinde EAC ve remote PowerShell için IP
temelli, kimlik doğrulama türüne ve kullanıcı özelliklerine bağlı olarak
Exchange ‘e kimlerin bağlanacağına siz karar verebilirsiniz.

Peki bu ihtiyaç nereden doğdu? Aslında Exchange 2013
ile beraber web ve powershell temelli yönetim alışkanlıkları arttıkça bu uzak
erişim protokolleri için özellikle şirket dışından veya şirket içerisinden
sıklıkla erişim talepleri arttı. Ancak şirket içerisinden olsun şirket dışında
olsun bu tarz erişimler son derece büyük riskleri beraberinde getirmekteydi.
Exchange sunucusuna RDP yapamayan kötü niyetli bir kişi şirket içerisinden veya
dışından bu tarz uzak yönetim araçları sayesinde tüm mail sistemini ele geçire
bilmekteydi. Tabiki banka, Telekom, gsm gibi büyük kurumlar Exchange Server
önünde konumlandırdıkları WAF veya benzeri güvelik cihazları ile aslında (bazen
de IIS ile) bu tarz istekler için IP bazlı temel bir sınırlandırma getirerek
koruma sağlayabiliyordu.

Ancak müşterilerden gelen yoğun istek üzerine bu tarz
ek bir koruma veya önlem olmadan Exchange server’ ın kendi kendini koruması için
tasarlanmış olan Client Access Rule ortaya çıkmıştır.

Peki örnek kurallara ve nasıl kural yazılacağına
geçmeden önce Client Access Rule için temel bileşenler nelerdir onları
görelim

Conditions- Koşullar

Kuralların en temel bileşeni olup Kimlik doğrulama
tipi, IP adresi, kullanılan protokol, kapsam, kullanıcı ismi, kullanıcı filtresi
gibi hangi koşulda kuralın çalışacağını tanımladığımız bölümdür.

Exceptions – Harici Durumlar

Tanımlanmış bir koşul için harici bırakılacak veya
başka bir deyişle bu kuraldan etkilenmeyecek durumları tanımladığımız
bölümdür.

Action – Aksiyon – Karar

En basit bölüm olup koşullara veya harici durumlara
gelen bir isteği uyup uymamasına göre izin veya yasaklamaların yapılacağına
karar verdiğimiz bölümdür.

Priority – Öncelik

Her kural dizesinde olduğu gibi burada da
önceliklendirme söz konusu olup en düşük numaralı kural en baskın – öncelikli
kuraldır.

Bu kısım önemli çünkü çakışma durumlarında kuralların
nasıl çalışacağını iyi bilmemiz gerekiyor.

Örneğin birden çok kuralda aynı koşul sağlanır ise ilk
kural uygulanır, diğer kurallar görmezden gelinir. Örneğin en yüksek öncelikli
bir PS yasak kuralı olsun ve buna karşın siz bir de daha düşük öncelikli bir
remote powershell izin kuralını belirli bir ip ye veren bir kural yazmış olun,
bu durumda ikinci yazdığınız kuralın hiçbir etkisi olmaz, yani ilgili ip den
gelse bile istek ilk kuraldan dolayı bloklanır. Çözüm ise ilk kurala ek bir
kural yazmaktansa ilk kurala ilgili ip için exception yani bir istisna eklemeniz
doğru çözüm olacaktır.

Ya da başka bir senaryo düşünelim, bir kural içerisinde
birden çok durum söz konusu olsun, yani EAC yasaklanacak ancak finans
departmanındaki bir kullanıcı için. Böyle bir kuralın çalışması için gelen
isteğin kural içerisindeki “tüm” durumları sağlaması şarttır. Bir nevi OR değil
AND olarak çalışır.

Bir kural içerisindeki bir durum için birden çok değer
atanması durumunda OR yani hangisi uyuyor ise kural etkili olur. Örneğin ilgili
kuralda bir ip için EAC veya Remote PowerShell demeniz halinde ikisinden biri
için action davranışı geçerli olacaktır.

Son olarak bir kural içerisinde bir den çok exception
tanımlanmış ise yine firewall mantığındaki OR şeklinde çalışır, yani ip adres
veya protocol olarak basic authentication seçmeniz halinde ikisinden hangisi
eşleşir ise action bu istek için uygulanmaz (exception olduğu için)

Yukarıdaki durumlar biraz gözünüzü korkutmuş olabilir
ama emin olun kural yazmaya başlayınca son derece kolay olduğunu göreceksiniz.
Hele ki Microsoft bize burada test için çok güzel bir komut seti hediye
etmişken;

Test-ClientAccessRule -User< MailboxIdentity>
-AuthenticationType <AuthenticationType> -Protocol <Protocol>
-RemoteAddress <ClientIPAddress> -RemotePort
< TCPPortNumber>

Örnek komut aşağıdaki gibidir;

Test-ClientAccessRule -User hakan@cozumpark.com
-AuthenticationType BasicAuthentication -Protocol ExchangeAdminCenter
-RemoteAddress 192.16.16.16. -RemotePort 443

Aslında son derece basit bir mantık ile çalışıyor, pek
çok firewall, smtp gateway veya benzeri cihazlardaki en temel kural mantığı ile
durumu ve istisnaları seçiyorsunuz, bu durumun gerçekleşmesi durumunda ise ne
yapacağınızı seçiyorsunuz, hepsi bu!

Peki Client Access Rule yönetimini nasıl
yapıyoruz?

Power Shell üzerinden yönetildiği için öncelikle
mutlaka sunucu local erişiminizin olduğuna emin olun, çünkü olası bir hatalı
kural tanımlamasından sonra uzak sunucu erişiminiz kesileceği için bu hatayı
düzeltme şansınız olmayacaktır.

Bu nedenle önerim sunucu üzerinde çalışmanız yönünde
olacaktır. Ancak bu önerim core sürümleri için geçerli değildir, çünkü core
sürümü bir Windows OS üzerine Exchange server kurmuş iseniz ki bunu tavsiye
ediyorum bu senaryo için ise ilk önerim aşağıdaki gibi en temel uzak erişim
kuralını yazmanız olacaktır.

New-ClientAccessRule -Name “Always Allow Remote
PowerShell” -Action Allow -AnyOfProtocols RemotePowerShell -Priority
1

Unutmayın öncelik çok önemli ve bunun çakışma
durumlarını da sizlerle paylaşıyor olacağım.

Peki gelelim kullanım senaryolarına.

Öncelikle mevcut durumda herhangi bir CAR var mı
kontrol edelim;

Get-ClientAccessRule

clip_image001

Okumaya devam et

Exchange Server 2016 DAG Activation Preference Değişimi – PreferenceMoveFrequency

Exchange Server 2010 sürümünden beri son derece
başarılı bir şekilde çalışan DAG mimarisi sayesinde kesintisiz bir mail sistemi
deneyimi sunmaktadır. Aslen 2007 sürümünde temelleri atılan ancak 2010 sürümü
ile ideal yapıya kavuşan DAG yani temelde log replikasyonu sayesinde mailbox
sunucuları arasındaki eşitleme özelliği sayesinde olası bir sorunda posta kutusu
seviyesinde herhangi bir kesinti olmadan kullanıcılarımız mailerine ulaşmaya
devam edebilmektedir.

clip_image001

 

Ancak her yeni sürüm hatta CU güncellemesi ile DAG
üzerinde birtakım iyileştirmelerin yapıldığını da görüyoruz. Aslında bunlar
küçük iyileştirmeler olsa bile son derece önemli sonuçlar doğurabiliyor. Bende
bu makalemde aslında Exchange Server 2019’ un çıktığı şu dönemde Exchange
Server 2012 CU2 ile gelen yeni bir özelliği yazmak istedim. Peki nedir bu yeni
özellik ve neden şimdi yazma ihtiyacı duydum?

Öncelikle değişim aslında DAG mimarisi içerisindeki
Activation Preference olarak isimlendirdiğimiz pasif kopyalar için öncelik
sırası olarak da özetleyebileceğimiz bir mekanizmanın “
PreferenceMoveFrequency” olarak isimlendirilen yeni bir
özellikle güçlendirilmesidir. DAG mimarisini bilen ve kullanan sistem
yöneticilerinin tecrübe ettiği gibi aslında Activation Preference çok kritik bir
değer olup hangi veri tabanının öncelikle hangi sunucu üzerinde aktif olacağını
seçebiliyoruz, bu sayede olası bir yama yükleme, sunucu kapatma açma veya
felaket sonrasında sistem planladığımız tasarıma göre yük dağılımını
gerçekleştirebilecektir. Ancak genel sorun Türkiye başta olmak üzere pek çok
yapıda Exchange Server DAG mimarisi aynı site içerisinde 2 sunucu ile
kurulmaktadır. Yani 1000 üstü kullanıcı bile olsa daha güçlü iki makine ile tüm
posta kutularına hizmet verebilmekteyiz. Tabiki banka, Telekom, gsm veya büyük
şirketlerde kullanıcı sayıları 5000, 10.000, 30.000 şeklinde arttıkça mimari
büyüyor. Ancak zaten o boyuttaki şirketlere genelde bizim gibi üst seviye
yapılarda danışmanlık yapmış insanlar destek verdiği için makalenin konusu olan
özelliği biz bu CU güncellemesine kadar zamanlanmış görevler ile elle
yapıyorduk. Yani bir nevi büyük yapılar zaten başının çaresine
bakıyordu.

Sorun neydi peki?

Okumaya devam et

Azure FileSync – Bölüm 2

Makalemin ilk bölümünde daha çok alt yapı olarak Azure
File Sync servisini anlatmaya çalıştım. Bu bölümde ise servisin gerçek hayatta
nasıl kullanılacağını sizlerle paylaşacağım. Kurulum aşamasından önce bu servis
için bilmemiz gereken kavramları ve ön gereksinimleri sizler ile paylaşıyor
olacağım. Ayrıca bu servisi mevcut ortamlarınızda hangi şartlarda hangi
özellikleri ile kullanabileceğinizi anlatacağım.

Öncelikle bu servis ile Çözümpark’ ın Radore veri
merkezindeki sunucu ve storage sistemlerindeki tüm yedeklerini Azure dosya
sistemine taşıdığımı söylemek istiyorum. Yani bu servis ile Türkiye de (belki
de Dünya da)şu ana kadar en çok veri taşımış bir uzman tecrübesi ile bu
makaleyi kaleme alıyorum. Toplam 15TB üstü 10 yıllık bir veriyi buluta
çıkardım. Bu sürede bana destek olan Radore veri merkezindeki arkadaşlara çok
teşekkür ediyorum.

Aslında benim için yıllandırılmış bu dosyaları
saklamak, sunucu’ dan sunucuya, storage’ dan storage’ a hatta malum 10 yıl
içerisinde 3 veri merkezi değiştirmiş birisi olarak bir veri merkezinden
diğerine taşıma bir maliyetli ve yorucu oluyordu. Artık eski yedeklerimiz bulut
ortamındaki bu bana büyük bir esneklik kazandırdı. Aslında bizim gibi
teknolojiyi yakından takip edenler için Azure File Sync servisi çok yeni değil
ondan bende henüz ilk duyduğumdan beri böyle bir proje için kullanmak
istiyordum ve kullandım. Her zaman olduğu gibi beğendiğim bir teknoloji veya
ürün var ise mutlaka makalesini yazmak isterim. Benim bu makaleye başlama
hikayemde böyle oldu anlayacağınız.

Peki bu kadar hikâye yeter biraz iş yapalım.

Azure File Sync servisini kullanmak istiyorsanız
öncelikle aşağıdaki kavramları bilmeniz gerekli;

·        Storage Sync Service

·        Sync
group

·        Registered server

·        Azure
File Sync agent

·        Server endpoint

·        Cloud
endpoint

·        Cloud
tiering

 

Storage Sync Service

Azure File Sync servisinin en üst seviye kaynağıdır.
Bildiğiniz gibi azure portalında kaynaklar yani resource bilinen bir kavram olup
aslında ilk olarak en üst seviyede Azure depolama senkronizasyon hizmetini
tanımlıyoruz.

Storage sync servisi, Azure File Sync servisi için bir
kaynaktır (ilk olarak tanımlanan bir kaynak olduğu için top-level resource
olarak da bilinir). Bu kaynak aynı zamanda storage hesaplarının kaynakları ile
çifttir. Azure resource group içerisine tanımlanabilir. Bir abonelik içerisinde
birden çok storage sync service olabilir. Çünkü temel olarak Storage sync
servisi birden çok sync group ile birden çok storage hesabını
eşitleyebilir.

Sync Group

Bir sync grup, bir dosya kümesinin senkronizasyon
topolojisini tanımlar. Örneğin iki endpoint (dosya sunucusu veya klasör gibi
düşünebilirsiniz) eğer aynı sync group içerisinde ise birbirini eşitleyecek
şekilde dosyaları iletir. Sync group mutlaka bir storage account’ a bağlı
olmalıdır. Çünkü dosya eşitleme işlemini azure storage üzerinde
gerçekleştirecektir.

Registered server

Storage sync servis ile güven ilişkisi kuran sunucu
veya cluster ortamlarını temsil eder. Bir sunucu aynı anda sadece bir tane
storage sync servis’ e kayıt olabilir.

Azure File Sync agent

Azure File Sync aracı, Windows Server’ ın bir Azure
dosya paylaşımı ile senkronize edilmesini sağlayan indirilebilir bir pakettir.
Azure Dosya Senkronizasyonu aracısının üç ana bileşeni vardır:

FileSyncSvc.exe: Sunucu uç noktalarındaki
değişikliklerin izlenmesinden ve Azure’ a eşitleme oturumlarının
başlatılmasından sorumlu arka plan Windows hizmeti.

StorageSync.sys: Azure File Sync file system filter
olarak geçer ve eğer cloud tiering özelliği açık ise dosyaların hot veya cool
olarak filtrelenmesi işleminden sorumludur.

PowerShell management
cmdlets
: Son
bileşeni ise Microsoft.StorageSync kaynak sağlayıcıyla etkileşimde bulunmak için
kullandığınız PowerShell cmdlet’leridir ki bunları aşağıdaki (varsayılan)
konumlarda bulabilirsiniz:

C:\Program
Files\Azure\StorageSyncAgent\StorageSync.Management.PowerShell.Cmdlets.dll

C:\Program
Files\Azure\StorageSyncAgent\StorageSync.Management.ServerCmdlets.dll

Okumaya devam et

Azure File Sync – Bölüm1


Bilişim sektörünün her zaman öncelikli iş yükleri
vardır. Bunların en başında güvenlik gelmesine karşın bunun ile ilişkili olarak
yedekleme başlığı da belki güvenlik işe eş değer bir konudur. Bunun en temel
nedeni ise her ne kadar en yeni nesil güvenlik ürünlerini veya teknolojilerini
kullanıyorsanız dahi olsa günün sonunda zero day başta olmak üzere bir şekilde
zafiyete uğrama ihtimaliniz vardır. Böyle bir durumda mutlaka bir prosedürünüz
ve bu prosedürü işletecek bilgili personeliniz olmalıdır. Bu prosedürün
içerisinde ise yedekleme başlığını göreceksiniz. Daha basit bir örnek vermek
gerekir ise ransomware gibi zararlıların şirket bilgisayarlarına bulaması ve tüm
verileri şifrelemesi gibi bir zafiyet durumunda eğer elinizde bir yedeğiniz var
ise aslında durumu ucuz atlatmış oluyorsunuz. Tabiki bilgi güvenliği balı başına
bir konu, ne yazık ki Dünya üzerinde o kadar değerli veriler var ki kötü niyetli
kişiler şirket sistemlerine sızdığı zaman ransomware gibi kendini belli eden bir
aksiyon yerine veri hırsızlığını da tercih edebiliyorlar.

Peki bu girişi konuya nasıl bağlayacaksın diye merak
edenler olabilir? Aslında anlatacağım Azure File Sync teknolojisi de yedekleme
teknolojilerine benzer dosya replikasyon ürünüdür.

Ürünü anlatmadan önce sizlere hızlıca Azure File nedir
sorusunun cevabını vermek istiyorum.

Azure File, bir endüstri standarttı olan “Server
Message Block SMB” protokolü ile ulaşabileceğimiz ve aynı on-prem sistemlerdeki
gibi klasik bir dosya paylaşımı imkanını bulut üzerinden sunan bir özelliktir.
Daha kısa bir ifade ile bulut üzerinde kullanılan dosya paylaşım platformu
diyebiliriz.

On-prem üzerindeki bir sunucu üzerinde nasıl bir dosya
paylaştırıyorsak azure üzerinde de benzer bir şekilde dosya paylaştırıp buraya
SMB protokolü ile on prem veya bulut üzerindeki sistemlerden
erişebiliyoruz.

Windows, macOS ve Linux gibi işletim sistemleri de
sorunsuz bir şekilde erişim sağlayabilirler.

clip_image002

Buradaki en önemli özelliklerden biriside böyle bir
dosya sistemi için ama Windows ortamında ana NAS üzerinde mutlaka bir yönetim
eforu sarf etmeniz gerekmesiydi. Yani yerleşik sistemlerdeki bir Windows dosya
sunucusu için yedekleme, ulaşılabilirlik veya yama yönetimi gibi bakım işlemleri
varken Azure File için bu tür bir derdiniz olmuyor. Hem HA yani sürekli olarak
ulaşılabilir olması hem de bakım maliyetlerinin olmaması Azure File’ ı bir hayli
üstün bir dosya sunucusu haline getiriyor. Tabiki en büyük sorun network bant
genişliklerinin sınırlı olması. Ama konumuz da zaten bu. Yani Azure File Sync
ile bunu nasıl aşacağımız.

Peki neden hala dosya sunucularına ihtiyaç duyuyoruz?
Onedrive, dropbox, sharepoint online veya aklınıza gelebilecek pek çok bulut
dosya sistemi olmasına karşın? Temelde alışkanlıklar gelse de özellikle büyük
dosyalar için gecikmeler çok ciddi can sıkıcı olabilmektedir.

Okumaya devam et

Exchange 2019 preferred Architecture – Tercih Edilen Mimari

Exchange Server 2019 çıkışı ile beraber ignite öncesi,
ignite ve sonrasındaki tecrübelerimi sizler ile paylaşmaya devam ediyorum. Pek
çok konuda olduğu gibi bu konuda da makale, Webcast ve benzeri paylaşımlarımı
ÇözümPark Bilişim Portalı veya kendi kişisel blog sayfam üzerinden takip
edebilirsiniz.

Bu yeni makalemde ise Exchange Server 2019 projelerimde
de kullandığım ve Microsoft tarafından önerilen mimari hakkında bilgi
vereceğim.

PA olarak kısaltacağımız tercih edilen, tavsiye edilen
mimari Microsoft mühendisleri tarafından bizim gibi kurulum yapacak sistem
mühendislerine nelere dikkat etmemiz gerektiğini ve başarılı yaygınlaştırma,
kurma işlemleri için dikkat edeceğimiz balıkları paylaştıkları bir
dokümandır.

Burada herşeyi Türkçe ye çevirmeyeceğim bunun temel
sebebi ise örneğin “autodiscover” veya “MAPI over http” gibi aslında bu konunun
özünde olan ve temel olarak üretici, danışman, müşteri üçlüsü arasındaki ortak
dili koruyan terimleri olduğu gibi işleyeceğim.

Peki bu doküman hangi başlıklarda önerilerde
bulunuyor?

·        Namespace design

·        Site
resilient datacenter pair design

·        Server design

·        Database availability group design

Eğer Exchange Server 2016 ile çok yakından
ilgileniyorsanız burada size güzel bir haber verebilirim. Mevcut 4 başlığın 3
için neredeyse tavsiye edilen yapılandırma aynı. Zaten temel olarak mimari aynı
olduğu için çok ciddi değişiklikler yok.

Exchange Server 2019 da neler yeni yi merak ediyorsanız
aşağıdaki makalemi inceleyebilirsiniz;

http://www.cozumpark.com/blogs/exchangeserver/archive/2018/10/14/exchange-server-2019-yenilikleri.aspx

Özetle namespace, data center design ve DAG için ciddi
değişiklikler olmamasına karşın asıl değişiklikler Server tasarımında kendini
göstermektedir.

Öncelikle namespace kavramı değişiklikleri ile
başlayalım;

Okumaya devam et