Kurumunuzun birden fazla lokasyonu varsa ya da Active Directory hizmetlerinizin işleyişinin devamlılığını garanti etmek istiyorsanız, mutlaka birden fazla domain controllerınız vardır. Birden fazla Domain Controller ise Active Directory replication anlamına gelir. Bu yazımızda Active Directory replication sorunları, nedenleri ve çözümleri üzerine yoğunlaşacağız.

Microsoft’un Windows 2000 ile Bilgi İşlem dünyasına en büyük armağanı, hiç kuşkusuz Active Directory’dir.  Bu muhteşem network yönetim sistemiyle, en basitinden, en devasa networklere  kadar her ölçekteki networkü   yönetmek oldukça kolaydır. Active Directory bu olanakları bizlere kolaylıkla sağlayan güçlü bir sistemdir ama kendiside bir o kadar hassas bir mekanizmaya sahiptir.

Replication Nedir?

Replication yani Türkçe ifade edersek çoğaltma, “aynı yada benzer tür verilerin birden fazla server  arasında  transfer edilerek herzaman güncel veriyle çalışmak” anlamına gelir, diyebiliriz. Söz konusu Active Directory olduğunda 2 tür replicationdan bahsedebiliriz;

1-      Intrasite replication

2-      Intersite replication

Intrasite replication aynı site içindeki Domain Controllerlar  arasında gerçekleşir. Intrasite topology ve replicationdan  NTFRS ( NT File Replication Service) adlı servislerin sorumlu olduğunu unutmayın

Intersite ise farklı sitelar arasındaki belirlenen Domain Controlerlar  arasında gerçekleşir. Intersite topology ve replicationdan KCC (Knowledge Consistency Checker) sorumludur.

Düzgün işlemeyen veya işlemeyen replication büyük sorundur; Ana yada yardımcı sunucularda oluşturduğunuz nesneler, diğer sunuculara çoğaltılamaz, doğrulanamaz, Active Directory veritabanındaki objelerin  süresinin  dolup dolmadığı belirlenemez, forest ve domain prep çalışmaz, Exchange veya schemayı genişleten uygulama ve processleri çalıştıramaz, kuramazsınız, domain controller promoto/demote işlevleri çalışmaz. Yani düşünmek bile istemeyeceğiniz bir sürü problemi karşınızda bulabilirsiniz.

Neden Replication sorunu olur?

Replication sorunlarının başında, düzgün ayarlanmamış site linkler, site subnet objeleri, transfer metodları ( intersite replication sorunları için) , dns problemleri, ağ iletişim problemleri ve uzun süre offline olup sonradan online olan, arızalı  dizin sunucuları başı çekerler.

Bunun dışında birde yapılandırma sorunları vardır. Buna bir örnek verirsek, Multi Domain yapılarında, aynı DC üzerinde Infrastructure Master FSMO rolü  ve Global Catalog serverın tutulması, sık görülen hatalardan birisidir…

Örnek Replication Sorunları

Event loglarınızı düzenli bir şekilde kontrol etmezseniz, bir süre replication sorunu olup olmadığını anlamayabilirsiniz. Yeni bir DC i ağa katmaya çalıştığınızda, Forestprep, Domainprep, Exchange server kurulumu gibi yüksek sayıda objenin ağda transfer edildiği durumlarda hatayla karşılaştığınızda sorunla yüzleşirsiniz. Event Loglara baktığınızda ise genellikle NTDS ve Netlogon hataları görürsünüz.

Event 1388 – 1988 hataları:

Bu hata, hedef domain controllerda “strict replication consistency” adı verilen registry değerinin var olmaması veya yanlış değere sahip olmasından kaynaklanır. Strict Replication Consistency (SRC) değeri, süresi dolmuş (outdated) objelerin çoğaltılmasını engelleyen bir registry değeridir.

SRC değeri 1 olarak ayarlandığında (etkin) DCnin local Active Directory database i ile replike edilen objeleri kıyaslar. Eğer dizin sunucusu uzun süre offline olmuş veya zaman/tarih hatası var ise, SRC değeri yok veya aktif değilse outdated olarak bahsettiğimiz bu çöpe atılacak objeler, tekrar ve tekrar replicate edilir. Aşağıda örnek bir “NTDS Replication” event error kaydı görmektesiniz.

Event Type:Error

Event Source:NTDS Replication

Event Category:Replication

Event ID:1388

Date:2/21/2005

Time:9:19:48 AM

User:NT AUTHORITYANONYMOUS LOGON

Computer:DC3

Description:

Another domain controller (DC) has attempted to replicate into this DC an

object which is not present in the local Active Directory database.  The

object may have been deleted and already garbage collected (a tombstone

lifetime or more has past since the object was deleted) on this DC. The

attribute set included in the update request is not sufficient to create

the object. The object will be re-requested with a full attribute set

and re-created on this DC.

Source DC (Transport-specific network address):

4a8717eb-8e58-456c-995a-c92e4add7e8e._msdcs.sistemuzmani.local

Object:

CN=InternalApps,CN=Users,DC=sistemuzmani,DC=local

Object GUID:

a21aa6d9-7e8a-4a8f-bebf-c3e38d0b733a

Directory partition:

DC=contoso,DC=local

Destination highest property USN:

20510

User Action:

Verify the continued desire for the existence of this object. To

discontinue re-creation of future similar objects, the following

registry key should be created.

Registry Key:

HKLMSystemCurrentControlSetServicesNTDSParametersStrict Replication Consistency

Event Type:Error

Event Source:NTDS Replication

Event Category:Replication

Event ID:1988

Date:2/21/2005

Time:9:13:44 AM

User:NT AUTHORITYANONYMOUS LOGON

Computer:DC3

Description:

Active Directory Replication encountered the existence of objects

in the following partition that have been deleted from the local

domain controllers (DCs) Active Directory database. Not all direct

or transitive replication partners replicated in the deletion

before the tombstone lifetime number of days passed. Objects that

have been deleted and garbage collected from an Active Directory

partition but still exist in the writable partitions of other DCs

in the same domain, or read-only partitions of global catalog servers

in other domains in the forest are known as “lingering objects”.

This event is being logged because the source DC contains a lingering

object which does not exist on the local DCs Active Directory database.

This replication attempt has been blocked.

The best solution to this problem is to identify and remove all

lingering objects in the forest.

Source DC (Transport-specific network address):

4a8717eb-8e58-456c-995a-c92e4add7e8e._msdcs.sistemuzmani.local

Object:

CN=InternalApps,CN=Users,DC=sistemuzmani,DC=local

Object GUID:

a21aa6d9-7e8a-4a8f-bebf-c3e38d0b733a

Not:
Strict Replication Consistency kayıt anahtarı Windows 2003 SP1 ve sonrasında mevcut ve aktifdir. Windows 2000, SP4 ve 2003 Serverda sonradan girmeniz gerekebilir.

Strict Replication Consistency’i aktifleştirin :

Daha öncede bahsettiğim gibi Strict Replication Consistency (SRC), tombstoned,  yani süresi dolmuş ve silinmek üzere işaretlenmiş nesnelerin, replicationda tekrar tekrar çoğaltılmasını engeller. Bu değere registry’de :

HKLM\System\CurrentControlSet\Services\NTDS\Parameters\Strict Replication Consistency

yoluyla erişebilirsiniz. Eğer bu değer mevcut değilse yeni bir “Dword” değeri oluşturun, adına “Strict Replication Consistency” (tırnaklar olmadan) yazın ve 16lı hexadecimal değerine 1 yazın.

Bu işlemi yaptıktan sonra bilgisayarı yeniden başlatınız.

Repadmin ile Garbage collected objeleri silmek :

Windows 2003 Resource kit ile beraber gelen araçlardan biriside “Repadmin” dir. Repadmin, replikasyon konusunda ihtiyaç duyacağınız hemen her türlü imkanı sağlar. Tek dezavantajı, komut satırından çalışmayı sevmeyen kişiler için  ilk başta biraz karışık gelmesi sayılabilir.

Repadmin’i yukarıda belirttiğimiz amaçta çalıştırmak için aşağıdaki komutu verin :

repadmin /removelingeringobjects Destination_domain_controller Source_domain_controller_GUID Directory_partition /advisory_mode

         advisoy_mode anahtarını, repadmin komutunu çalıştıracağınız ilk seferde mutlaka giriniz. advisory_mode, komut çalıştırmadan önce sonuçlarını simüle eder. Eğer bir sorun  yoksa “succesfull” ibaresini görürsünüz.

Komut advisory_mode anahtarıyla düzgün çalışmışsa, şimdi asıl komutu girebilirsiniz. Tam açılımlı bir örnek verirsek :

repadmin /removelingeringobjects domain_controller sistemuzmani.local A0AE6093-15F5-4DB8-836B-4495E3A15396 DC=sistemuzmani,DC=local

Not: GUID, Globally Unique IDentifier A0AE6093-15F5-4DB8-836B-4495E3A15396_msdcs.forest_root_domain_name.com  benzeri bir tanımlayıcıdır. Repadmin için sadece ilk bölümünün alınması yeterlidir , yani A0AE6093-15F5-4DB8-836B-4495E3A15396 kısmından sonrasını yazmayın.

GUID’inizi bilmiyorsanız  :

repadmin /showrepl /v dc.sistemuzmani.local komutunu verdiğinizde çıkan sonuçtan GUIDinizi görebilirsiniz. Örnek çıktı aşağıdaki gibidir :

AnkaraBranchSite\DC

DC Options: IS_GC

Site Options: (none)

DC object GUID: d0281ebb-4a3a-4851-9ddd-0006a4c1be08

DC invocationID: d0281ebb-4a3a-4851-9ddd-0006a4c1be08

==== INBOUND NEIGHBORS ======================================

DC=sistemuzmani,DC=local

AnkaraBranchSite\DC2 via RPC

DC object GUID: 6dd95a70-86a4-4c9a-8ae9-1467b872d885

Address: 6dd95a70-86a4-4c9a-8ae9-1467b872d885._msdcs.sistemuzmani.local

DC invocationID: c0f0e7a2-cb59-4861-b8b2-68b59da2a75a

SYNC_ON_STARTUP DO_SCHEDULED_SYNCS WRITEABLE

USNs: 42563/OU, 42563/PU

Last attempt @ 2007-06-02  17:07:52 was successful.

CN=Configuration,DC=sistemuzmani,DC=local

KocaeliBranchSite\dc3 via RPC

DC object GUID: 7bb27be0-fdcf-410c-9d4e-31270064f302

Address: 7bb27be0-fdcf-410c-9d4e-31270064f302._msdcs.sistemuzmani.local

DC invocationID: 7ec73b22-27a9-4e89-8d80-b322a474bc7d

SYNC_ON_STARTUP DO_SCHEDULED_SYNCS WRITEABLE COMPRESS_CHANGES NO_CHANGE_

NOTIFICATIONS

USNs: 167362/OU, 167362/PU

Last attempt @ 2007-06-02 14:59:38 was successful.

AnkaraBranchSite\DC2 via RPC

DC object GUID: 6dd95a70-86a4-4c9a-8ae9-1467b872d885

Address: 6dd95a70-86a4-4c9a-8ae9-1467b872d885._msdcs.sistemuzmani.local

DC invocationID: c0f0e7a2-cb59-4861-b8b2-68b59da2a75a

SYNC_ON_STARTUP DO_SCHEDULED_SYNCS WRITEABLE

USNs: 42563/OU, 42563/PU

Last attempt @ 2007-06-0217:06:54 was successful.

CN=Schema,CN=Configuration,DC=sistemuzmani,DC=local

KocaeliBranchSite\dc3 via RPC

DC object GUID: 7bb27be0-fdcf-410c-9d4e-31270064f302

Address: 7bb27be0-fdcf-410c-9d4e-31270064f302._msdcs.sistemuzmani.local

DC invocationID: 7ec73b22-27a9-4e89-8d80-b322a474bc7d

SYNC_ON_STARTUP DO_SCHEDULED_SYNCS WRITEABLE COMPRESS_CHANGES NO_CHANGE_

NOTIFICATIONS

USNs: 167217/OU, 167217/PU

Last attempt @ 2007-06-02 14:59:39 was successful.

AnkaraBranchSite\DC2 via RPC

DC object GUID: 6dd95a70-86a4-4c9a-8ae9-1467b872d885

Address: 6dd95a70-86a4-4c9a-8ae9-1467b872d885._msdcs.sistemuzmani.local

DC invocationID: c0f0e7a2-cb59-4861-b8b2-68b59da2a75a

SYNC_ON_STARTUP DO_SCHEDULED_SYNCS WRITEABLE

USNs: 42502/OU, 42502/PU

Last attempt @ 2007-06-02 16:59:38 was successful.

DC=ankara,DC=sistemuzmani,DC=local

KocaeliBranchSite\dc3 via RPC

DC object GUID: 7bb27be0-fdcf-410c-9d4e-31270064f302

Address: 7bb27be0-fdcf-410c-9d4e-31270064f302._msdcs.sistemuzmani.local

DC invocationID: 7ec73b22-27a9-4e89-8d80-b322a474bc7d

DO_SCHEDULED_SYNCS COMPRESS_CHANGES NO_CHANGE_NOTIFICATIONS

USNs: 167327/OU, 167327/PU

Last attempt @ 2007-06-0214:59:39 was successful.

Bu komutla sadece GUID’inizi değil Inbound Neighbours bağlantıları , siteler hakkında bilgiler ve son replicationların düzgün olup olmadığı, varsa da hatalar listelenir.

Not:  Windows 2000 serverlarda repadmin i çalıştıramazsınız. Bunun yerine Strict Replication Consistency kayıt anahtarını aktifleştiriniz.

Yapılandırma Hataları

Active Directory yapılandırma hatalarının başında, Global Catalog server ile Infrastructure Master FSMO rolünün aynı serverda olduğu durumlarda yaşanabilir.  Domain’de birden fazla DC olduğu durumlarda, asla infrastructure master ve global catalog  aynı server üzerinde olmamalıdır.

IM (Infrastructure Master) GC (Global Catalog) ile aynı serverda olduğunda, objelerin tarih statüsünü(time stamp) bilemez(outdated mı?, tombstoned mı? Yoksa güncelmi?). Bu yüzden IM FSMO rolü çalışmaz ve replication gerçekleşmez.. Bu yüzden her zaman bu FSMO rolünü GC olmayan bir başka DC de tutunuz..

Nasıl?

Öncelikle Active Directory Users And Computers’ı açın. Sunucunuzu seçin, sağ tıklayın ve “Connect to Domain Controller” seçeneğini seçin.Burada FSMO rolünü devredeceğimiz DC’ye bağlanacağız. Connect to… seçeneğini verdikten sonra, karşımıza dizinde kayıtlı Dclerin bir listesi gelecektir (şekil 1).

Şekil1- Dizinde kayıtlı Domain Controllerların listesi.

Listeden rolü devredeceğiniz  DCyi seçin ve OK’i tıklayın.

Bu işlemide tamamladıktan sonra karşımıza bağlandığımız DC’nin Active Directory Users And Computers snap-in i gelir. Yine buradan server a sağ tıklıyoruz, Operation Masters seçeneğini seçiyoruz.

Şekil 2- Operations Masters.. seçeneğiyle rolleri görüntüleyin

Şekil 3 – FSMO rolümüzü buradan değiştiriyoruz.

Burada “Operations Masters” altında, rolün o andaki geçerli sahibi olan serverın adı görülür. Aşağıda ise FSMO rolünü  transfer edebileceğimiz serverın ismi görüntülenir. Rolü devretmek için “Change” butonuna tıklarız. FSMO rolü başarıyla devredilirse :

Şekil 4- Başarıyla devredilmiş bir FSMO rolü.

FSMO rolünün geçerlilik kazanması biraz zaman alabilir. Bu süreyi kısaltmak için Rolü devrettiğimiz sunucuda “File Replication Service” servisini yeniden başlatın. Daha sonra Directory Service loglarından rolün doğrulandığına dair bilgilendirme Event kayıtlarını kontrol edebilirsiniz..Bu information logu, Directory Services altında olacaktır :

Şekil 5- DC’nin infrastructure master rolünü aldığına dair information logu.

Infrastructure Master’ı taşımayıp GC serverı taşımanız gerekiyorsa;

1-Active Directory Sites And Services Snapin i açın: Start All Programs Administrative Tools Active Directory Sites And Services

Şekil 6 – Active Directory Sites And Services Snap-in i

Mevcut Site ınızı açın, Servers Container’ı altındaki GC serverınızı seçin.

2-Serverınızın altındaki NTDS settings’e sağ tıklayın, ve properties’e tıklayın.

Şekil 7 – NTDS Settings altında GC server seçeneğini buradan değiştiriyoruz.

3-      General tabında  ”Global Catalog” altındaki check box ı kaldırın.

4-      OK tıklayıp çıkın.

Bir süre sonra Event Viewer’da Directory Services kayıtlarına aşağıdaki gibi bir event düşecektir

Şekil 8 – Artık yeni bir Global Catalogumuz var!

Tabii ki, siz NTDS ayarlarında varolan varolan bir GC’yi kaldırırsanız, bunun tam tersi bir uyarı alırsınız.

Şekil 9- Global Catolagu kaldırdığınızda alacağınız event log kaydı.

Not: Değişikliklerin gerçekleşmesi yarım saat kadar zaman alabileceğini unutmayınız.

Bazen FSMO rolleri başarıyla taşınamaz, rol hatalıdır (ERROR state) veya her iki sunucunuzda çakışmalardan dolayı, domainde veya forestta tek bir serverda olması gereken rolü her iki server birden üstlenmeye çalışabilir. Böyle durumlarda rolü “seize” etmeniz gerekebilir.  Bu konu ile  ilgili  bir makale, daha önce sevgili hocamız Alper Çanak tarafından, Sistem Uzmanı.Com da detaylı bir şekilde yazıldığı için yazma gereği duymadım. Böyle bir durumla karşılaşmışsanız http://www.sistemuzmani.com/Articles/Details.aspx?aId=1000000129 adresine tıklayarak bu makaleyi okuyabilirisiniz.

USN JOURNAL WRAP HATALARI

Bir diğer sık görülen replication sorunuda NTFS USN Journal Wrap hatalarıdır. NTFS USN Journal, NTFS 5.0 ile formatlanmış partitionlarda gerçekleşen tüm değişiklikleri tutan bir logdur. Journal loglarda iki tür kayıt tutulur: dosyanın açık olduğu durum ve kapalı olduğu durumu bilgisi.. NTFRS, replike  ettiği dosyaların kapalı olduğuna emin olduktan sonra dosya ya da veriyi replike eder. USN Journalda oluşabilecek hatalardan dolayı NTFRS, Active Directory veritabanının durumun bilgisini alamayacak, dolayısıyla replikasyonuda gerçekleştiremeyecektir. Bu tür hatalara, USN Journal Wrap hataları denir. Journal Wrap hatalarının nedeni, journal log dosyasının belirlenmiş boyutundan daha büyük olması veya, elektrik kesintisi, uygunsuz shutdown vb. “nedenlerden dolayı log dosyasında hata oluşması sıralanabilir.

A- Journal log boyutuyla ilgili sorunlar:

Journal boyutunu hesaplamak için şöyle bir formül vardır :

journal boyutu/((60 byte + (dosya adı uzunluğu)) * 2)

Bir örnek verecek olursak:

8+3 dosya isim formatına sahip 200.000 dosya/dizin için journal log boyutu 32 MB ı bulur. Windows 2000 SP2 e kadar, varsayılan journal log boyutu 32MB, verilebilecek en büyük log boyutu ise 128 MB’dı. Windows 2000 SP3 ile bu değer varsayılan 512 MB, maksimum 10.000 MB’a çıkarılmıştır. Bu ayarı bir registry ayarında değişiklik yaparak konfigüre edeblirsiniz :

HKLM\System\CCS\Services\NTFRS\Parameters\”Ntfs Journal size in MB” (REG_DWORD)

“NTFS Journal Size in MB” değerini varolan değerden daha yüksek bir değere ayarlayınız.

B- Inconsistent Journal log hataları ile ilgili sorunlar:

Windows 2000 SP3 ve sonrası için, “Enable journal wrap automatic restore” adlı bir registry değeri gelmiştir. Bu değer aktif hale getirildiğinde, Ntfrs.exe log dosyası üzerinde *non-authoritative restore işlemi gerçekleştirerek log dosyasını kurtarmaya çalışır. İlgili registry anahtarına :

HKLM\System\Ccs\Services\Ntfrs\Parameters

altından ulaşablir ve Enable journal wrap automatic restore adlı kayıt anahtarına  “1″ değerini vererek aktif hale getirebilirsiniz (varsayılan olarak kapalıdır)

*
Ntfrs.exe’nin gerçekleştirdiği non-authoritative restore işleminin, Active directory’de gerçekleştirilen non-authoritative restore işlemi ile bir ilgisi yoktur.

         İlgili registry değerlerini konfigüre ettikten sonra, bilgisayarı yeniden başlatınız.

Sonuç

Active Directory replication problemleri elbette sadece bunlarla sınırlı değildir. Fakat bu yazımda, Sistem Yöneticilerinin en sık karşılaştığı bazı temel  replikasyon sorunların üzerinden geçmiş olduk ve bu sorunlarla nasıl başedebileceğimizi gördük.