Windows Server 2016'da Active Directory Database ve Log Dosyalarının Farklı Bir Dizine Taşınması

Active Directory Database ve Log dosyalarının varsayılan konumdan farklı bir dizine taşınması çoğu zaman göz ardı edilse de, uzun vadeli sürdürülebilirlik ve denetim açısından oldukça anlamlı bir ihtiyaçtır. Özellikle C:\ Disk'i üzerine yapılan varsayılan kurulumlar, zamanla hem kapasite hem de performans yönünden yetersiz kalabilir. Üstelik aynı Disk üzerinde çalışan işletim sistemi ve Active Directory servisleri, olası bir Disk arızasında tüm yapının aynı anda etkilenmesine neden olur. Bu da geri dönüş süresini uzatır ve müdahale alanını ciddi şekilde daraltır.

Database ve Log dosyalarının ayrı Disk'lerde veya RAID yapılandırma işlemiyle korunmuş farklı dizinlerde tutulması, sadece performans değil, güvenlik ve yönetilebilirlik açısından da avantaj sağlar. Çünkü yoğun kullanıcı ve nesne etkileşiminin yaşandığı ortamlarda bu dosyaların erişim hızı doğrudan Active Directory Replication, Authentication (kimlik doğrulama) süreleri ve genel sistem yanıt süresine etki eder. Yapının büyümesiyle birlikte yaşanacak performans problemleri genellikle bu tür temel yapılandırma tercihleriyle doğrudan ilişkilidir.

Bu taşıma işlemi tek başına performans artışı sağlamaz; aynı zamanda Log dosyalarının tutulduğu alanda detaylı izleme yapılmasına, ayrı Disk kotalarıyla denetim uygulanmasına ve Backup stratejilerinin daha esnek tanımlanmasına da zemin hazırlar. Ancak tüm bu faydalara rağmen, bu işlem plansız yapıldığında oldukça risklidir. Çünkü Active Directory servisleri doğrudan bu dosyalarla entegre çalışır ve yapılacak en küçük bir hata, Directory Services’in başlatılamaması gibi ciddi sonuçlara yol açabilir.

İyi planlanmış bir taşıma süreci, yalnızca bugünü değil, yapının gelecekteki ihtiyaçlarını da gözeten bir iyileştirme anlamına gelir. Bu işlem sadece yapılabiliyor diye değil, gerçekten ihtiyaç varsa ve sistemin geleceği düşünülerek gerekçelendiriliyorsa yapılmalıdır. Aksi takdirde, stabil çalışan bir yapının gereksiz yere riske atılması söz konusu olabilir. Bu yüzden karar vermeden önce, ortamın mevcut Disk kullanımı, büyüme tahminleri, yedekleme stratejileri ve olası felaket senaryoları birlikte değerlendirilmelidir.

Active Directory Database ve Log dosyalarının neden farklı bir dizine taşınması gerektiğini anlamak, sadece bir yapılandırma değişikliğinden ibaret değildir. Bu süreç, AD'nin arka planda nasıl çalıştığını, veri bütünlüğünü nasıl sağladığını ve sistem performansına nasıl doğrudan etki ettiğini daha net görmeye imkan tanır. Dosyaların yerinin değiştirilmesiyle birlikte aslında sadece fiziksel bir taşıma değil, aynı zamanda veri erişim sürelerinin, Disk I/O performansının ve hata senaryolarına karşı alınan önlemlerin de yeniden yapılandırılması söz konusu olur. Bu yüzden konunun tüm boyutlarıyla ele alınması, alınacak kararın ne kadar isabetli olacağını belirleyen temel faktörlerden biridir.

Disk I/O İşlemlerinin Optimizasyonu

AD Database'i NTDS.dit ve Log dosyaları, sistem sürücüsünde tutulduğunda, bu dosyalar aynı Disk üzerindeki diğer işletim sistemi dosyaları, uygulama verileri ve geçici dosyalarla aynı Input/Output - I/O kanallarını paylaşır. Modern sunucu ortamlarında, Disk I/O performansı sistemin genel performansında kritik bir rol oynar. Disk I/O, verilerin Disk'ten okunması ve Disk'e yazılması işlemlerini kapsar. AD'nin yoğun şekilde kullanıldığı ortamlarda, bu işlemler oldukça sık ve yoğun bir şekilde gerçekleşir.

Bir AD sunucusu, kullanıcı oturum açma taleplerini, grup politikası uygulamalarını, replikasyon süreçlerini ve diğer birçok işlemi yönetirken sürekli olarak NTDS.dit dosyasına erişir. Aynı zamanda, her değişiklik ve güncelleme bir Log dosyasına yazılır. Bu I/O taleplerinin tümü, işletim sisteminin kendisi tarafından yapılan I/O talepleriyle yarışır.

Sonuç olarak, aynı Disk üzerindeki I/O talepleri arasında bir darboğaz oluşabilir, bu da AD performansını doğrudan etkiler. AD Database'i ve Log dosyalarını ayrı bir fiziksel Disk'e taşıyarak, bu I/O işlemleri Diskler arasında bölünür ve her bir Disk'in yükü hafifletilmiş olur. Bu, AD'nin işlem hızını ve sunucunun genel performansını artırır.

Veritabanı Tutarlılığı ve Veri Bütünlüğü

AD Database'i ve Log dosyalarının farklı dizinlere veya fiziksel Disk'lere taşınması, veritabanı tutarlılığı ve veri bütünlüğü açısından da önemlidir. Active Directory, veritabanı değişikliklerini önce Log dosyalarına yazar, ardından bu değişiklikleri veritabanına (NTDS.dit) uygular. Bu iki aşamalı yazma süreci, sistemin çökmesi veya beklenmedik bir güç kaybı durumunda veri bütünlüğünü korumak için tasarlanmıştır.

Ancak, hem veritabanı dosyası hem de Log dosyaları aynı Disk üzerindeyse, Disk arızası durumunda her iki veri seti de zarar görebilir. Bu, veritabanının ciddi şekilde bozulmasına ve hatta geri döndürülemez veri kaybına yol açabilir. Veritabanı dosyasını ve Log dosyalarını ayrı fiziksel Disk'lere taşıyarak, bir Disk arızasında verilerin sadece bir kısmının zarar görmesi sağlanabilir, bu da veri kurtarma ve yeniden yapılandırma sürecini büyük ölçüde kolaylaştırır.

Replikasyon Performansı ve Tutarlılık

AD'nin dağıtılmış bir yapıya sahip olduğunu ve verilerin birden fazla Domain Controller (DC) arasında replikasyonla yayıldığını göz önünde bulundurmalıyız. Replikasyon süreci sırasında, AD veritabanı sık sık güncellenir ve bu güncellemeler Log dosyalarına yazılır. Log dosyalarının hızlı bir şekilde yazılabilmesi ve işlenmesi, replikasyon sürecinin sağlıklı bir şekilde ilerlemesi için kritik öneme sahiptir. Eğer Log dosyaları, işletim sistemi veya diğer yoğun I/O işlemleriyle aynı Disk üzerinde bulunuyorsa, bu, replikasyon performansını olumsuz etkileyebilir ve DC'ler arasındaki veri tutarlılığını tehlikeye atabilir.

Log dosyalarının ayrı bir yüksek performanslı Disk'e taşınması, replikasyon işlemleri sırasında Log yazma hızını artırır ve böylece replikasyon sürecinin hızlanmasını sağlar. Bu durum, AD verilerinin diğer DC'ler arasında daha hızlı ve tutarlı bir şekilde yayılmasına olanak tanır.

Disk Arızalarına Karşı Koruma

Tek bir Disk üzerinde hem AD Database'i hem de Log dosyalarını tutmak, Disk arızalarına karşı sistemin savunmasız hale gelmesine neden olabilir. Eğer bu Disk arızalanırsa, hem veri hem de işlem geçmişi kaybedilebilir. Ayrı Disk'lere sahip olmak, bu riski dağıtarak, en kötü senaryoda bile veri kurtarma şansını artırır. Örneğin, eğer sadece Log dosyalarını barındıran Disk arızalanırsa, en son tam yedeklemeden itibaren olan işlemleri kaybedebilirsiniz, ancak veritabanı dosyası sağlam kalırsa, geri yükleme işlemi daha kolay ve hızlı olur.

Disk Alanı ve Büyüme Yönetimi

AD veritabanı ve Log dosyaları, zamanla büyür. Bu büyüme, sistem Disk'i üzerinde ciddi alan sorunlarına yol açabilir. Özellikle yoğun kullanılan bir AD ortamında, Log dosyaları hızlı bir şekilde dolabilir ve bu durum işletim sistemi için ayrılan Disk alanını tehdit edebilir. Ayrı bir Disk'e veya depolama birimine taşınan veritabanı ve Log dosyaları, bu büyümenin sistem performansını etkilemesini engeller. Bu adım, Disk alanının daha iyi yönetilmesini sağlar ve sistem sürücüsünün gereksiz şekilde dolmasını önler.

1- CMD (Command Promt) üzerinde net stop ntds komutu çalıştırarak NTDS servisini durduruyorum.



1.1- Bu komutu çalıştırdıktan sonra; Kerberos Key Distribution Center (KDC), Intersite Messaging, DNS Server, DFS Replication şeklinde 4 tane ilişkili servisin durdurulacağı bilgisi geliyor.

1. Kerberos Key Distribution Center (KDC)

Kerberos Key Distribution Center (KDC), Active Directory ortamında kimlik doğrulama için kullanılan merkezi bir bileşendir. Kerberos protokolü, güvenli bir şekilde kullanıcıların ve servislerin kimliklerini doğrulamak için tasarlanmıştır. KDC, Authentication Service (AS) ve Ticket Granting Service (TGS) olmak üzere iki ana bileşenden oluşur.

Authentication Service (AS)

Bir kullanıcı Domain'e giriş yapmak istediğinde karşılaştığı ilk yapı, Authentication Service (AS) olur. Bu servis, kullanıcıdan gelen kimlik doğrulama isteğini işlerken aslında yalnızca parola kontrolü yapmaz. Kullanıcının User Principal Name (UPN) bilgisiyle birlikte sistem saatiyle olan uyumu, hesap durumu ve şifre politikaları da işin içine girer. Eğer her şey tutarlıysa, AS kullanıcının hesabı adına bir Ticket Granting Ticket (TGT) üretir ve bu bileti yalnızca kullanıcıya özel olacak şekilde şifreleyerek geri gönderir. Buradaki şifreleme işlemi, kullanıcının şifresinden türetilmiş olan simetrik anahtarla yapılır. Bu yüzden kullanıcı, sadece kendi parolasını biliyorsa bu bileti açabilir ve kullanabilir.

Üretilen TGT, kullanıcı adına Key Distribution Center (KDC) tarafından dijital bir kimlik gibi işlev görür. Bu bilet, geçerlilik süresi boyunca kullanıcının tekrar parola göndermeden diğer servislerle iletişime geçebilmesini sağlar. Ama bu bilet tek başına işe yaramaz; çünkü içinde sadece kim olduğunu kanıtlayan bilgiler vardır, nereye erişmek istediğiyle ilgili bir şey yoktur. Sistem bu bileti geçici ama güvenilir bir kimlik doğrulama aracı olarak görür. Genellikle 10 saat geçerlidir, ancak bu süre ortamın yapılandırmasına göre değiştirilebilir.

TGT'nin çalışma mantığı sayesinde kullanıcı, sabit aralıklarla yeniden parola girmek zorunda kalmaz ve kimliğini her seferinde sıfırdan kanıtlamak yerine bir anlamda dijital imzasını kullanır. Bu, hem kullanıcı deneyimi açısından akıcı bir yapı sunar hem de oturumlar arası kimlik tutarlılığını sağlamış olur. Tüm bunlar, Kerberos mimarisinin kimlik doğrulama sürecini hem hızlı hem de güvenli bir şekilde sürdürebilmesine imkan tanır.

Ticket Granting Service (TGS)

Bir kullanıcı belirli bir servise erişmek istediğinde, daha önce Authentication Service tarafından kendisine verilmiş olan Ticket Granting Ticket (TGT)'yi Ticket Granting Service (TGS)'ye iletir. TGS bu bileti açar, kimlik bilgilerini doğrular ve ardından kullanıcının erişmek istediği servise özel olarak tasarlanmış bir Service Ticket üretir. Bu biletin içinde hem kullanıcının kimlik bilgileri hem de hedef servise özgü oturum anahtarları yer alır. Böylece kullanıcı, doğrudan servise gidip bu bileti sunduğunda, parola girmeden doğrulanmış bir kimlik gibi kabul edilir.

TGS, bu işlem sırasında hem kullanıcının hem de hedef servisin ilişkili olduğu Service Principal Name (SPN)'i baz alarak güvenli bir bağlantının kurulabilmesi için gerekli şifreleme anahtarlarını da bilete gömer. Kullanıcı, bu Service Ticket ile yalnızca hedef servise erişebilir; başka bir serviste bu bilet geçersiz sayılır. Bu sayede her erişim isteği için özel ve sınırlı bir yetki tanımlanmış olur. Sistem, böylece hem merkezi hem de bölümlenmiş bir kimlik doğrulama süreciyle güvenliği dağıtarak sürdürür. Bu yapının sunduğu avantaj, kullanıcı ile servis arasındaki kimlik doğrulamanın KDC üzerinden dolaylı ve şifreli bir yapıyla gerçekleşmesidir.

KDC, AD Domain Controller üzerinde çalışır ve Kerberos protokolü aracılığıyla tüm Domain kullanıcılarının kimlik doğrulama işlemlerini yürütür. Bu servis durduğunda, Domain kullanıcıları Kerberos kimlik doğrulaması gerektiren servislere erişemezler ve oturum açma işlemleri başarısız olabilir. KDC'nin düzgün çalışması, AD ortamında güvenli kimlik doğrulama işlemleri için kritiktir.

2. Intersite Messaging (ISM)

Intersite Messaging (ISM), Active Directory ortamında site-to-site (site'lar arası) iletişimi yönetmek için kullanılan bir servistir. AD içinde, farklı fiziksel konumlarda bulunan Domain Controller'lar arasında replikasyon yapılırken, ISM protokolü kullanılır. Bu servis, farklı AD siteleri arasındaki replikasyon trafiğini ve verilerin güvenli bir şekilde taşınmasını sağlar.

ISM, özellikle düşük bant genişliği olan bağlantılarda verimli bir şekilde çalışmak üzere optimize edilmiştir. Site'lar arasındaki replikasyon trafiği, planlanan bir zamanlama çerçevesinde gerçekleşir ve ISM, bu trafiği yöneterek veri tutarlılığını korur. Eğer ISM servisi durursa, AD site'ları arasındaki replikasyon işlemleri durabilir veya kesintiye uğrayabilir, bu da veri tutarsızlıklarına yol açabilir.

3. DNS Server

DNS Server servisi, Active Directory ortamının bel kemiğini oluşturan bileşenlerden biridir. AD, tam anlamıyla işlevsellik kazanabilmesi için DNS'e bağımlıdır. DNS, isim çözümleme servisi olarak, Domain içindeki bilgisayarların ve servislerin IP adreslerini DNS adlarıyla eşleştirir.

AD ortamında, DNS özellikle Domain Controller'ların, istemcilerin ve diğer network bileşenlerinin birbirlerini bulabilmesi için kritik öneme sahiptir. Örneğin, bir client, Domain Controller üzerinde oturum açmak istediğinde önce DNS üzerinden Domain Controller'ın IP adresini çözümlemelidir. Ayrıca, AD'nin replikasyon işlemleri ve Global Catalog gibi diğer AD hizmetleri de DNS'e dayanır.

DNS Server servisi durdurulduğunda, AD ortamında isim çözümleme işlemleri başarısız olur. Bu durum, istemcilerin Domain Controller'lara bağlanamaması, AD replikasyonlarının başarısız olması ve genel olarak network iletişiminin ciddi şekilde etkilenmesiyle sonuçlanabilir.

4. DFS Replication (DFSR)

DFS Replication (DFSR), Distributed File System (DFS) içinde dosya verilerini replikasyon yapmak için kullanılan bir servistir. DFSR, özellikle farklı konumlardaki sunucular arasında dosya ve klasörlerin eşzamanlı olarak güncellenmesi ve senkronize edilmesi için kullanılır.

AD ortamında DFSR, özellikle SYSVOL paylaşımlarının Domain Controller'lar arasında replikasyonu için kritik öneme sahiptir. SYSVOL, AD içindeki politikaların ve script'lerin saklandığı yerdir ve bu verilerin tüm Domain Controller'lar arasında tutarlı olması gerekir. DFSR, bu verilerin tutarlı bir şekilde replikasyonunu sağlar ve böylece tüm Domain Controller'ların güncel politika ve script'lere sahip olmasını garanti eder.

DFSR servisi durdurulduğunda, SYSVOL ve diğer DFS replikasyonları kesintiye uğrar. Bu da, kullanıcıların doğru Group Policy yapısındaki politikalara erişememesi, oturum açma script'lerinin çalışmaması ve genel olarak AD yapısındaki tutarsızlıklarla sonuçlanabilir.

Bu uyarı alanında Y ile onaylayıp devam ediyorum.

2- Bir sonraki çalıştıracağım komut ise Ntdsutil komutudur. Komutu çalıştırdıktan sonra sırası ile aşağıdaki komutları tek tek çalıştırıyorum.

✅ ntdsutil
✅ Activate instance ntds
✅ Files
✅ info



3- Veri tabanının o anki durumunu sorgulamak için file maintenance adımında info komutu çalıştırırıyorum. 



👉 Disk Durumu ve Alan Kullanımı

C:\ sürücüsü NTFS formatında yapılandırılmış ve toplam 59.4 GB'lık bir kapasiteye sahip. Bunun 47.6 GB’lık kısmı boş. Bu boş alan, Active Directory bileşenlerinin log üretimi, veritabanı büyümesi ve sistem snapshot'ları gibi işlemler için oldukça rahat bir çalışma alanı bırakıyor. Eğer bu alan çok düşük olsaydı, ntds.dit dosyasının genişleyememesi ya da Log dosyalarının yeni kayıt yazamaması gibi ciddi problemler yaşanabilirdi.

👉 Veritabanı Yolu ve ntds.dit Dosyası

Database satırında belirtilen Ntds.dit, C:\Windows\NTDS\ntds.dit konumunda tutuluyor ve 20.0 MB boyutunda. Bu dosya, Active Directory'nin tüm organizasyonel yapısını, kullanıcı nesnelerini, grup üyeliklerini, GPO referanslarını, şifre hash’lerini ve daha fazlasını barındırıyor. Dosya boyutunun küçük olması, ortamın yeni kurulduğunu veya henüz çok fazla nesne barındırmadığını gösterir. Ancak veritabanının sıkıştırılmış bir yapıda çalıştığını unutmamak gerekiyor. Bu nedenle kapasite kullanımına sadece dosya boyutundan bakmak her zaman doğru yorum vermez.

👉 Yedekleme Dosyası (dsadata.bak) Backup dir satırında görülen C:\Windows\NTDS\dsadata.bak dosyası, Ntds.dit dosyasının otomatik bir yedeğidir. Sistem tarafından belirli aralıklarla oluşturulur ve veri kurtarma senaryolarında önemli rol oynar. Bu dosya olmadan, örneğin bir Authoritative Restore süreci başlatmak mümkün olmaz. Bu yedekleme dosyasının orada bulunması, Active Directory servisinin backup rutinlerinin düzgün çalıştığını gösteren olumlu bir işarettir.

👉 Log dosyaları ve Yazma Sıralamaları

Log dir altında dört önemli dosya yer alıyor ve toplamda 40 MB’lık bir alan kaplıyor:

✔ edbtmp.log: Geçici log dosyası. Genellikle işlem yapılırken aktif olarak kullanılır ve tamamlanmamış işlemleri içerir.

✔edbres00001.jrs ve edbres00002.jrs: Bunlar rezerv Log dosyalarıdır. Ana Log dosyalarında sorun yaşanması durumunda veri kaybını önlemek için devreye girerler.

✔ edb.log: Bu dosya, Active Directory üzerinde yapılan tüm işlemlerin ilk yazıldığı yerdir. Herhangi bir işlem önce bu Log'a kaydedilir, daha sonra veritabanına işlenir. Yani sistem Write-Ahead Logging mantığına göre çalışır.

Bu Log dosyalarının her biri 10 MB boyutunda. Bu sabit boyutlandırma, circular logging mekanizması çalışıyorsa sistemin otomatik olarak eski Log'ları temizlediğini gösterir. Ancak sistemde bu mekanizma devrede değilse ve Log dosyaları hızlıca büyüyorsa, bu durum replikasyon sorunları, yedekleme eksikliği ya da aşırı işlem yükü gibi durumların habercisi olabilir.

👉 Veri Tutarlılığına Etkisi

Buradaki log yapısı ve veritabanı yerleşimi, sistemin ani elektrik kesintileri, donma veya servis çakışmaları gibi olaylara karşı nasıl dayanıklı kalabildiğinin temel kanıtı. Her işlem önce log dosyasına yazıldığı için sistem beklenmedik biçimde kapanmış olsa bile, yeniden başlatıldığında Log'lardan eksik işlem tamamlanır veya rollback uygulanır. Bu yapı, veri bütünlüğünü sürekli koruyan bir mekanizma oluşturur.

👉 Sistemin Genel Sağlığına Dair Yorum

Bu ekran çıktısından yola çıkarak sistemin şu anda sağlıklı bir durumda olduğunu söylemek mümkün. ntds.dit dosyası erişilebilir, Log dosyaları stabil görünüyor, yedekleme dosyası mevcut ve disk alanı yeterli. Herhangi bir anormallik veya kapasite sıkışması gözlemlenmiyor. Ancak uzun vadede Log dosyalarının büyüme hızı, disk doluluk oranı ve veritabanı boyutundaki artış düzenli aralıklarla kontrol edilmeli. Aksi takdirde, bu yapı ileride gecikmeli replikasyon, yavaş sorgular veya servis yanıt sürelerinde artış gibi sorunlara zemin hazırlayabilir.

Bu yapının yüzeyine bakıp geçmek mümkün ama detaylara indiğinde çok daha fazlasını söylüyor. Active Directory'nin kalbindeki nabzı dinlemek istiyorsan, ntdsutil çıktısı bunu sana net şekilde anlatıyor. Yeter ki nasıl okuyacağını bil.

Active Directory Database ve Log dosyalarının Taşınması

4- Bu bilgiyi elde ettikten sonra artık Active Directory Database'i (veri tabanı) taşımak için aşağıdaki komutu çalıştırıyorum.

Görüldüğü gibi Active Directory Database (veri tabanı) Path'i (dizini) değişti. E:\ActiveDirectory\NTDS2, dizinindeki Active Directory ve NTDS2 klasörleri, benim belirttiğim bir klasörlerdir.



5- Active Directory Database (veri tabanı) taşıma işlemini gerçekleştirdikten sonra sıra, Active Directory Database Log dosyalarını taşıma işlemine geldi. Bunun için aşağıdaki komutu çalıştırıyorum.

Görüldüğü gibi Active Directory Log dosyalarının Path'i değişti. Yukarıda da belirttiğim gibi E:\ActiveDirectory\NTDS2 dizinindeki ActiveDirectory ve NTDS klasörleri, benim belirttiğim bir klasördür.



6- Active Directory Veri tabanı ve Log dosyalarının taşınma işlemini gerçekleştirdikten sonra, ntdsutil aracından file maintenance adımında q (quit) ve ntdsutil adımında da q (Quit) komutları ile çıkış yapıyorum.

7- Yönetim aracından çıktıktan sonra unutmamamız gereken şey; durdurduğumuz NTDS Servisini tekrar çalıştırmak olacaktır. Bunun için net start ntds komutu ile mutlaka tekrar çalıştırılmalıdır.



8- Görüldüğü gibi E:\ActiveDirectory\NTDS2 dinizini kontrol ettiğimde, Active Directory Database (veri tabanı) ve Log dosyaları taşıma işleminin başarılı bir şekilde gerçekleştiğini görebiliyorum.



9- Active Directory Users and Computers konsolunu çalıştırıp, gerekli kontrollerimi sağlıyor, her şeyin olması gerektiği çalıştığından emin oluyourm.



Active Directory veritabanı ve Log dosyalarının taşınması, Windows Server 2016 üzerinde dikkatle gerçekleştirilmesi gereken hassas bir işlemdir. Bu makalede, taşınma sürecinin adımları detaylı bir şekilde ele alındı. Ntds.dit veritabanı ve Log dosyalarının doğru hedef dizine aktarılması, sistemin kararlılığını sürdürmek için kritik öneme sahiptir.

Doğru bir taşınma işlemi, hem performans artışı sağlar hem de Disk alanı yönetimini optimize eder. Özellikle PowerShell ve GUI kullanılarak bu sürecin nasıl gerçekleştirileceği net bir şekilde açıklandı. Ayrıca, işlemin öncesinde alınması gereken yedekler ve olası hatalardan kaçınmak için yapılması gereken kontroller vurgulandı.

Bu makale, Active Directory Database ve Log dosyalarını taşımayı planlayanlar için pratik bir rehber sunuyor. Doğru adımları izleyerek, sistem performansını artırabilir ve güvenli bir veri yönetimi sağlayabilirsiniz.

Faydalı olması dileğiyle...