Wednesday, November 25, 2015

Configure Active Directory Replication with Windows 2008

I installed a second Active Directory Server by selecting the “Active Directory Domain Services” Role from the Server Manager Dialogue. Step by step instructions can be seen in Deploying a Test Windows Environment in a KVM Infrastucture. After that was installed I ran the following from the run dialogue:
dcpromo.exe
And I saw the following screen:
ad wizard Configure AD Replication with Windows 2008
Let’s choose to “Add a domain controller to an existing domain”:
existing forest Configure AD Replication with Windows 2008
Enter the name of the Domain and enter the admin password for that Domain:
enter domain name Configure AD Replication with Windows 2008
If the connection to the primary DC is successful, you will see the following:
existing DC Configure AD Replication with Windows 2008
We won’t be doing any inter-site setup, so selecting the default site name is okay here:
default site ad setup Configure AD Replication with Windows 2008
Next let’s setup a DNS server on the new DC and let’s NOT make it Read only (RODC):
additional dc options Configure AD Replication with Windows 2008
Next, let’s go ahead and replicate the AD configuration from the primary DC:
replicate data ad wizrd Configure AD Replication with Windows 2008
Click “Next” a couple of times and at the end, you will get to the summary page:
ad wizard summary Configure AD Replication with Windows 2008
After you click “Next”, the replication will start:
replicating data Configure AD Replication with Windows 2008
After it’s done, you will see the following:
ad wizard finished Configure AD Replication with Windows 2008
Click “Finish” and restart the machine.

Confirm the Replication Worked

After the machine is rebooted you will see that it’s part of the domain and it’s setup as a “Backup DC”:
C:\Users\Administrator.ELATOV>systeminfo | findstr "Domain"
OS Configuration:          Additional/Backup Domain Controller
Domain:                    elatov.local
Now let’s make sure the same users exist on the this machine as well:
C:\Users\Administrator.ELATOV>dsquery user
"CN=Administrator,CN=Users,DC=elatov,DC=local"
"CN=Guest,CN=Users,DC=elatov,DC=local"
"CN=krbtgt,CN=Users,DC=elatov,DC=local"
"CN=Karim Elatov,CN=Users,DC=elatov,DC=local"
Checking the DNS Records on the new machine, I saw the following:
C:\Users\Administrator.ELATOV>dnscmd /EnumRecords elatov.local @ /type A
Returned records:
@                [Aging:3614831] 600  A  192.168.250.54
                 [Aging:3614830] 600  A  192.168.250.47
CLIENT           [Aging:3613844] 1200 A  192.168.101.47
cluster                          3600 A  192.168.250.51
dc                               3600 A  192.168.250.47
dc2                              3600 A  192.168.250.54
haproxy                          3600 A  192.168.250.52
iis-2            [Aging:3613995] 1200 A  192.168.250.49

Command completed successfully.
We can see that our machine (dc2) was automatically added to DNS. Checking for that record on the primary DC, I saw the following:
C:\Users\Administrator>dnscmd /EnumRecords elatov.local dc2 /type A
Returned records:
@                    [Aging:3614831] 3600 A  192.168.250.54

Command completed successfully.
That looks good. Now to check the status of the replication:
C:\Users\Administrator.ELATOV>repadmin /replsummary
Replication Summary Start Time: 2013-05-18 16:43:23

Beginning data collection for replication summary, this may take awhile:
  .....


Source DSA          largest delta    fails/total %%   error
 DC                        12m:11s    0 /   5    0
 DC2                       11m:29s    0 /   5    0


Destination DSA     largest delta    fails/total %%   error
 DC                        11m:29s    0 /   5    0
 DC2                       12m:11s    0 /   5    0
No errors are seen. We can also see all the data that has been replicated:
C:\Users\Administrator>repadmin /showrepl

Repadmin: running command /showrepl against full DC localhost
Default-First-Site-Name\DC
DSA Options: IS_GC
Site Options: (none)
DSA object GUID: a68c69a8-b015-4254-b81c-dc65782bd1fa
DSA invocationID: a68c69a8-b015-4254-b81c-dc65782bd1fa

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

DC=elatov,DC=local
    Default-First-Site-Name\DC2 via RPC
        DSA object GUID: f3d68c86-ec97-42d0-8aef-f62e8c70f347
        Last attempt @ 2013-05-18 16:33:47 was successful.

CN=Configuration,DC=elatov,DC=local
    Default-First-Site-Name\DC2 via RPC
        DSA object GUID: f3d68c86-ec97-42d0-8aef-f62e8c70f347
        Last attempt @ 2013-05-18 16:35:57 was successful.

CN=Schema,CN=Configuration,DC=elatov,DC=local
    Default-First-Site-Name\DC2 via RPC
        DSA object GUID: f3d68c86-ec97-42d0-8aef-f62e8c70f347
        Last attempt @ 2013-05-18 16:31:54 was successful.

DC=DomainDnsZones,DC=elatov,DC=local
    Default-First-Site-Name\DC2 via RPC
        DSA object GUID: f3d68c86-ec97-42d0-8aef-f62e8c70f347
        Last attempt @ 2013-05-18 16:31:54 was successful.

DC=ForestDnsZones,DC=elatov,DC=local
    Default-First-Site-Name\DC2 via RPC
        DSA object GUID: f3d68c86-ec97-42d0-8aef-f62e8c70f347
        Last attempt @ 2013-05-18 16:31:54 was successful.
We can see that DNS is included as well. This is expected since we have AD-intergrated DNS. From “Active Directory-Integrated DNS Zones”:
Domain Name System (DNS) servers running on domain controllers can store their zones in Active Directory Domain Services (AD DS). In this way, it is not necessary to configure a separate DNS replication topology that uses ordinary DNS zone transfers because all zone data is replicated automatically by means of Active Directory replication.
I thought that was pretty convenient. We can also make sure the two server are in the same site. From the run dialogue execute the following:
dssite.msc
Expand “Sites” -> “Default Site” -> “Servers” and make sure you see both servers:
dssite msc Configure AD Replication with Windows 2008
If we were doing inter-site replication, we would have to create different site and replication schedules here.

Test Our Replication

To test out replication we can create a snapshot of the data by running the following from the command prompt:
C:\Users\Administrator.ELATOV>repadmin /showchanges . dc=elatov,dc=local /cookie:config.txt
...
...
DC2,CN=Domain System Volume (SYSVOL share),CN=File Replication Service,CN=System
,DC=elatov,DC=local
New cookie written to file config.txt (132 bytes)
That will create a “cookie” file with the data inside of it, in my case the file is called config.txt. Then let’s go ahead and add a new User to the primary DC, and see if that user gets replicated. From the run dialogue execute:
dsa.msc
And select “New” -> “User”:
dsa msc new user Configure AD Replication with Windows 2008
Let’s call our user “test”:
test user dsa msc Configure AD Replication with Windows 2008
After the user is created run the above command again:
C:\Users\Administrator.ELATOV>repadmin /showchanges . dc=elatov,dc=local /cookie:config.txt

Repadmin: running command /showchanges against full DC localhost
Using cookie from file config.txt (132 bytes)
==== SOURCE DSA: localhost ====
Objects returned: 1
(0) add CN=test,CN=Users,DC=elatov,DC=local
    1> parentGUID: 8793942d-d052-4a2f-9eaa-c44f45715be0
    1> objectGUID: a94935e4-ca0a-4699-b01b-b4e84e9f4b12
    4> objectClass: top; person; organizationalPerson; user
    1> givenName: tes
    1> instanceType: 0x4 = ( WRITE )
    1> whenCreated: 5/18/2013 6:22:49 PM Pacific Daylight Time
    1> displayName: tes
    1> nTSecurityDescriptor: O:DAGddfdfgdfgdfg
    1> name: tes
    1> userAccountControl: 0x10200 = ( NORMAL_ACCOUNT | DONT_EXPIRE_PASSWD )
    1> codePage: 0
    1> countryCode: 0
    0> dBCSPwd:
    0> logonHours:
    0> unicodePwd:
    0> ntPwdHistory:
    1> pwdLastSet: 5/18/2013 6:22:49 PM Pacific Daylight Time
    1> primaryGroupID: 513 = ( GROUP_RID_USERS )
    0> supplementalCredentials:
    1> objectSid: S-1-5-21-3787252690-2443488306-3332615697-1109
    1> accountExpires: (never)
    0> lmPwdHistory:
    1> sAMAccountName: test
    1> sAMAccountType: 805306368 = ( NORMAL_USER_ACCOUNT )
    1> userPrincipalName: test@elatov.local
    1> objectCategory: guid =278ebe8ed9bd3f469b97d822790af4fc;CN=Person,CN=Schema,CN=Configuration,DC=elatov,DC=local
New cookie written to file config.txt (132 bytes)
We can see that the difference in the cookie file since it was last run is the newly added test user. Also checking to make sure the user exists:
C:\Users\Administrator.ELATOV>dsquery user
"CN=Guest,CN=Users,DC=elatov,DC=local"
"CN=krbtgt,CN=Users,DC=elatov,DC=local"
"CN=Administrator,CN=Users,DC=elatov,DC=local"
"CN=Karim Elatov,CN=Users,DC=elatov,DC=local"
"CN=test,CN=Users,DC=elatov,DC=local"
I added a new user called ‘test2’ and made sure it was replicated. I then removed the user, ran the same command, and here is what I saw:
C:\Users\Administrator.ELATOV>repadmin /showchanges . dc=elatov,dc=local /cookie:config.txt

Repadmin: running command /showchanges against full DC localhost
Using cookie from file config.txt (132 bytes)
==== SOURCE DSA: localhost ====
Objects returned: 1
(0) delete CN=test2\0ADEL:a94935e4-ca0a-4699-b01b-b4e84e9f4b12,CN=Deleted Objects,DC=elatov,DC=local
    1> parentGUID: 5a9f62a2-0205-4100-8eac-4ccb60a75f7a
    1> objectGUID: a94935e4-ca0a-4699-b01b-b4e84e9f4b12
    0> givenName:
    1> instanceType: 0x4 = ( WRITE )
    0> displayName:
    1> isDeleted: TRUE
    1> name: test2
DEL:a94935e4-ca0a-4699-b01b-b4e84e9f4b12
    0> codePage:
    0> countryCode:
    0> unicodePwd:
    0> ntPwdHistory:
    0> pwdLastSet:
    0> primaryGroupID:
    0> supplementalCredentials:
    0> accountExpires:
    0> lmPwdHistory:
    0> sAMAccountType:
    0> userPrincipalName:
    1> lastKnownParent: guid =2d94938752d02f4a9eaac44f45715be0;CN=Users,DC=elatov,DC=local
    0> objectCategory:
    1> isRecycled: TRUE
New cookie written to file config.txt (132 bytes)

No comments:

Post a Comment