Hi AD Expert,

I have AD Server running 2008 R2 in premise and another one AD running 2012 Standard on the cloud. Besides, I have also AD servers on the other countries that connected via VPN tunnel.

How do I know from where the AD in the cloud replicate from and how to configure the time to replicate? the AD on cloud is used for DRP. so the replication supposed coming from in premise AD and not running from CLoud AD to In premise AD.

Thanks.

Regards,

Hi Henry2050,

If you have a domain controller that is a member of your on-premise domain/forest then if everything's been set up correctly, it'll be connected via a VPN connection as well meaning it's no different to any other remote site or associated domain controller you have.

Assuming this is indeed the case then there's no real concept of it replicating only one way as again, the cloud-based domain controller isn't viewed any differently than any other domain controller located in a different site.

You can configure the site link cost (assuming it's been correctly set up as having its own site and IP range(s)) through the normal tools, such as the dssite.msc MMC or possibly even PowerShell depending on the version of Windows you're performing the administration from.

Additionally, you can use normal tools such as repadmin.exe and dcdiag.exe to troubleshoot issues and determine information such as the replication partners.

Finally, if the domain controller in the cloud is not able to directly communicate with the on-premise domain controllers then it's either not going to work once it passes the tombstone interval - unless all the FSMO roles have been seized and the other domain controllers evicted via a metadata cleanup, however, this will simply produce a domain controller working in an isolated environment which will be of no value from a DR perspective. Hopefully this isn't the case.

Cheers,
Lain

Hi Henry2050,

If you have a domain controller that is a member of your on-premise domain/forest then if everything's been set up correctly, it'll be connected via a VPN connection as well meaning it's no different to any other remote site or associated domain controller you have.

Assuming this is indeed the case then there's no real concept of it replicating only one way as again, the cloud-based domain controller isn't viewed any differently than any other domain controller located in a different site.

You can configure the site link cost (assuming it's been correctly set up as having its own site and IP range(s)) through the normal tools, such as the dssite.msc MMC or possibly even PowerShell depending on the version of Windows you're performing the administration from.

Additionally, you can use normal tools such as repadmin.exe and dcdiag.exe to troubleshoot issues and determine information such as the replication partners.

Finally, if the domain controller in the cloud is not able to directly communicate with the on-premise domain controllers then it's either not going to work once it passes the tombstone interval - unless all the FSMO roles have been seized and the other domain controllers evicted via a metadata cleanup, however, this will simply produce a domain controller working in an isolated environment which will be of no value from a DR perspective. Hopefully this isn't the case.

Cheers,
Lain

• Proposed as answer by Mary DongMicrosoft contingent staff, Moderator Wednesday, July 08, 2015 9:01 AM

You can use repadmin to check the replication status. You can also use dcdiag to check the DC health status. This is in case you would like to do regular manual checks.

Please also note that there are monitoring tools that are able to check the health status of your DCs and AD replication. Microsoft SCOM is one them but there are also some third party tools like Lepide Auditor - Active Directory: http://www.lepide.com/lepideauditor/active-directory.html You can ask them for an evaluation period.

As for the replication, you can create multiple AD sites, create subnets in use and assign them to the correct AD sites and also move the DCs to the correct AD sites using dssite.msc. The tool will allow you also to customize the replication frequency.

Hi Henry,

Thanks for your post.

You could use Repadmin /showrepl displays the replication partners.

https://technet.microsoft.com/en-us/library/cc811565(v=ws.10).aspx

For configuring the Replication Frequency between domain controllers, you could refer to:

https://technet.microsoft.com/en-us/library/cc730954.aspx

http://windowsitpro.com/high-availability/how-do-i-change-schedule-replication-between-two-domain-controllers-site  (Please Note: Since the web site is not hosted by Microsoft, the link may change without notice. Microsoft does not guarantee the accuracy of this information.)

Best Regards,

Mary Dong

use repadmin /showreps command to check the AD replication, check below links to know more

http://www.windowstricks.in/2009/10/how-to-check-active-directory-2.html

http://www.windowstricks.in/2010/03/how-to-check-active-directory.html

Regards,

Ganesh

www.windowstricks.in

Hi Henry,

Thanks for your post.

You could use Repadmin /showrepl displays the replication partners.

https://technet.microsoft.com/en-us/library/cc811565(v=ws.10).aspx

For configuring the Replication Frequency between domain controllers, you could refer to:

https://technet.microsoft.com/en-us/library/cc730954.aspx

http://windowsitpro.com/high-availability/how-do-i-change-schedule-replication-between-two-domain-controllers-site  (Please Note: Since the web site is not hosted by Microsoft, the link may change without notice. Microsoft does not guarantee the accuracy of this information.)

Best Regards,

Mary Dong

Hi Henry,

Please also check the event log, what's other detail message about the error?

For troubleshooting: "The RPC server is unavailable", you could refer to the article.

http://social.technet.microsoft.com/wiki/contents/articles/4494.windows-server-troubleshooting-the-rpc-server-is-unavailable.aspx

Best Regards,

Mary Dong

Hi Henry,

Please also check the event log, what's other detail message about the error?

For troubleshooting: "The RPC server is unavailable", you could refer to the article.

http://social.technet.microsoft.com/wiki/contents/articles/4494.windows-server-troubleshooting-the-rpc-server-is-unavailable.aspx

Best Regards,

Mar

Hi Henry,

It is not best practice to create manual connections and there's nothing about your scenario that requires you to do so. That being the case, remove the manual links you've created (in this case, both of the connection objects starting with "DC02").

The Sites and Services screenshot from above doesn't match what you're saying as if it's pointing to the NTDS Settings for CLOUD-DC01 then you wouldn't be seeing an <automatically generated> connection object pointing to itself. This image looks more like the view you would have from one of the HQSITE domain controllers (i.e. DC01 or DC02.)

This observation is backed up by the fact you have two connection objects pointing to "DC02". This has come about because someone has created one DC02 connection object on one domain controller and then another on a separate domain controller with the same name. You can tell because the second "DC02" has includes the standard Active Directory nomenclature of "CNF:" in its name. Active Directory automatically renames the losing conflicting object to include this label for easy identification.

You've mentioned that manual replication using Sites and Services fails with an error relating to DNS. Have you done any of the following yet?

1. Looked in the Event Viewer under "Directory Service" for any warnings that describe the DNS failure?
2. Run "dcdiag /test:dns /dnsbasic /e /v /s:dc02" to get an idea of which specific DNS record can't be found?

You could also run the dcdiag command from point 2 locally on CLOUD-DC01 to get an idea of what the reverse view looks like.

Because you're trying to fix a missing record issue, one change I'd recommend making until you've fixed the problem is configuring the primary DNS entry on CLOUD-DC01 to point to the IP address of DC02 (or DC01 - it doesn't really matter) and then either restarting CLOUD-DC01 or manually performing the following steps on CLOUD-DC01:

1. Run this command from an administrative command prompt: ipconfig /registerdns.
2. Stop and then start the Netlogon service.

This will direct CLOUD-DC01 to create its appropriate host and service location records on DC02 which will quite likely help resolve any DNS issues identified above. You can always switch the primary DNS value back once you've fixed all replication issues, though it's worth mentioning that you should never use the loopback address as a DNS entry (either 127.0.0.1 for IPv4 or ::1 for IPv6.) Also, it should be obvious, but make sure that DNS queries from CLOUD-DC01 can actually reach DC02.

Going back to the start, once you have resolved your DNS and subsequent replication problems, you can easily change the domain controller associated with an automatic connection object by editing the automatically created connection object under your CLOUDSITE\NTDS Settings container:

1. Right-click the <automatic connection> object and choose properties.
2. Click the Change button next to the Server value and choose DC02.

Focus on performing your configuration and administration from DC02 until both repadmin and dcdiag show no more errors. If you have broken replication and you're performing administrative tasks on both DC02 and CLOUD-DC01 then you're likely to make the situation worse than it already is.

I think that's enough for now as you've got a few things to do before looking for any other faults. Just to recap:

1. Delete the manually created Connection objects.
2. Configure the primary DNS entry on CLOUD-DC01 to point to DC02.
3. Either reboot CLOUD-DC01 or manually register the host and service location records.
4. Assuming this resolves your DNS and replication issues, change the desired replication server in the automatic connection's properties.

Cheers,
Lain

Hi Henry,

It is not best practice to create manual connections and there's nothing about your scenario that requires you to do so. That being the case, remove the manual links you've created (in this case, both of the connection objects starting with "DC02").

The Sites and Services screenshot from above doesn't match what you're saying as if it's pointing to the NTDS Settings for CLOUD-DC01 then you wouldn't be seeing an <automatically generated> connection object pointing to itself. This image looks more like the view you would have from one of the HQSITE domain controllers (i.e. DC01 or DC02.)

This observation is backed up by the fact you have two connection objects pointing to "DC02". This has come about because someone has created one DC02 connection object on one domain controller and then another on a separate domain controller with the same name. You can tell because the second "DC02" has includes the standard Active Directory nomenclature of "CNF:" in its name. Active Directory automatically renames the losing conflicting object to include this label for easy identification.

You've mentioned that manual replication using Sites and Services fails with an error relating to DNS. Have you done any of the following yet?

1. Looked in the Event Viewer under "Directory Service" for any warnings that describe the DNS failure?
2. Run "dcdiag /test:dns /dnsbasic /e /v /s:dc02" to get an idea of which specific DNS record can't be found?

You could also run the dcdiag command from point 2 locally on CLOUD-DC01 to get an idea of what the reverse view looks like.

Because you're trying to fix a missing record issue, one change I'd recommend making until you've fixed the problem is configuring the primary DNS entry on CLOUD-DC01 to point to the IP address of DC02 (or DC01 - it doesn't really matter) and then either restarting CLOUD-DC01 or manually performing the following steps on CLOUD-DC01:

1. Run this command from an administrative command prompt: ipconfig /registerdns.
2. Stop and then start the Netlogon service.

This will direct CLOUD-DC01 to create its appropriate host and service location records on DC02 which will quite likely help resolve any DNS issues identified above. You can always switch the primary DNS value back once you've fixed all replication issues, though it's worth mentioning that you should never use the loopback address as a DNS entry (either 127.0.0.1 for IPv4 or ::1 for IPv6.) Also, it should be obvious, but make sure that DNS queries from CLOUD-DC01 can actually reach DC02.

Going back to the start, once you have resolved your DNS and subsequent replication problems, you can easily change the domain controller associated with an automatic connection object by editing the automatically created connection object under your CLOUDSITE\NTDS Settings container:

1. Right-click the <automatic connection> object and choose properties.
2. Click the Change button next to the Server value and choose DC02.

Focus on performing your configuration and administration from DC02 until both repadmin and dcdiag show no more errors. If you have broken replication and you're performing administrative tasks on both DC02 and CLOUD-DC01 then you're likely to make the situation worse than it already is.

I think that's enough for now as you've got a few things to do before looking for any other faults. Just to recap:

1. Delete the manually created Connection objects.
2. Configure the primary DNS entry on CLOUD-DC01 to point to DC02.
3. Either reboot CLOUD-DC01 or manually register the host and service location records.
4. Assuming this resolves your DNS and replication issues, change the desired replication server in the automatic connection's properties.

Cheers,
Lain

Hi Mr. Lain,

Thanks so much for your patient of answering my question. That's true that my cropped image has some mistakes. the correct one should be the one below:

Actually, the automatically generated one is pointing to Cloud-DC02, which is because we previously has another AD called "Cloud-DC02" and has been disjoined from domain. To save time, we just shutted down the "Cloud-DC02" AD and create a new VM and built another AD called "Cloud-DC01".

You have your point that because i have manually add the DC02 connection, so to avoid the confusion, the AD is automatically generated a new one plus the nomenclature behind. My reason to add that in because previously after doing the DCPROMO, i don't see the DC02 inside, that's why i added in manually. In this case, is it safe to remove the DC02i have added previously (I think the one without nomenclature is the one added manually) and rename the one with nomenclature to DC02? will it cause replication issue?

Yes, for the DNS issue i will try to perform the steps that you given and let you know the result. Currently, i can see that the replication is only from DC02 to Cloud-DC01. because, when i create users or objects in DC02, it will automatically replicated to CLoud-DC01 but not vice versa. do you think it is issue with DNS?

However, when i try to do nslookup and reverse lookup from both DC02 and CLoud-DC01, both are able to resolve FQDN or IP addresses of both DC. by right when they are able to resolve hostnames, the DNS should not be causing problem right?

Thanks.

Hi Henry,

Okay, knowing about CLOUD-DC02 and the problems that relate to it makes a difference to the steps you need to perform, as you need to remove all traces of CLOUD-DC02. There is a proper process to follow for achieving this.

First of all, follow points 1 to 3 from my previous post as they're still very relevant. Once you've done that, you can focus on removing CLOUD-DC02 properly by using either of the following steps:

1. Basic process: This will perform the minimum steps required to remove CLOUD-DC02.
2. Advanced process: Use the 2003 SP1 or later section, making sure to skip step 19.

If you have any questions about this process, come back here and ask about it as it's important to pay attention to what you're doing with this tool. If this is your first time using ntdsutil then follow just the basic process.

Once you have removed CLOUD-DC02 and allowed some time for the domain controllers to recognise this, I'd suggest using repadmin and dcdiag to check the health of DC02 and CLOUD-DC01. The dcdiag command is in the previous post and a useful one for repadmin is:

repadmin /showrepl /all dc02

You could also run the same command on or against cloud-dc01 to see whether it believes everything's fine yet.

If they both come back with no errors then go ahead with step 4 from the previous post and configure the automatic connection.

Cheers,
Lain

Hi Henry,

Okay, knowing about CLOUD-DC02 and the problems that relate to it makes a difference to the steps you need to perform, as you need to remove all traces of CLOUD-DC02. There is a proper process to follow for achieving this.

First of all, follow points 1 to 3 from my previous post as they're still very relevant. Once you've done that, you can focus on removing CLOUD-DC02 properly by using either of the following steps:

1. Basic process: This will perform the minimum steps required to remove CLOUD-DC02.
2. Advanced process: Use the 2003 SP1 or later section, making sure to skip step 19.

If you have any questions about this process, come back here and ask about it as it's important to pay attention to what you're doing with this tool. If this is your first time using ntdsutil then follow just the basic process.

Once you have removed CLOUD-DC02 and allowed some time for the domain controllers to recognise this, I'd suggest using repadmin and dcdiag to check the health of DC02 and CLOUD-DC01. The dcdiag command is in the previous post and a useful one for repadmin is:

repadmin /showrepl /all dc02

You could also run the same command on or against cloud-dc01 to see whether it believes everything's fine yet.

If they both come back with no errors then go ahead with step 4 from the previous post and configure the automatic connection.

Cheers,
Lain

Hi Lain,

You mentioned to remove the manually created connection objects. is it safe to delete as i worry the replication is on going and if i delete it it will goes haywire. The one i added manually should be the one without the nomenclature. So, should i just keep the nomenclature one and rename to DC02 and then delete the manually created DC02? because of them are vallid right?

Thanks

Hi Henry,

You should remove any and all connections that aren't named "<automatically generated>". If you have disabled automatic site bridging then this will create a problem until you've defined the appropriate site link bridges, but based on your two site configuration, this is irrelevant (either that or someone's made a monumental mistake in turning it off.)

There's no need to worry as even if there's no connection objects left at all, this will only be a problem up to the point where the KCC runs again (runs every 15 minutes.) At that point, the domain controller that holds the ISTG role in the site with no defined inbound connections will go about restoring a connection - as long as it can communicate with a domain controller in a next hop site (which is why DNS is so important and why pointing the domain controller(s) with errors to a working domain controller - as in Step 2 two posts back, so often helps resolve issues.)

Cheers,
Lain

Hi Henry,

You should remove any and all connections that aren't named "<automatically generated>". If you have disabled automatic site bridging then this will create a problem until you've defined the appropriate site link bridges, but based on your two site configuration, this is irrelevant (either that or someone's made a monumental mistake in turning it off.)

There's no need to worry as even if there's no connection objects left at all, this will only be a problem up to the point where the KCC runs again (runs every 15 minutes.) At that point, the domain controller that holds the ISTG role in the site with no defined inbound connections will go about restoring a connection - as long as it can communicate with a domain controller in a next hop site (which is why DNS is so important and why pointing the domain controller(s) with errors to a working domain controller - as in Step 2 two posts back, so often helps resolve issues.)

Cheers,
Lain

Hi Lain,

If i remove all the connections except the one automatically generated, i think the replication will goes down. Currently, the replication is still working if i make changes on DC02 and it is replicated to CloudDC-01. but not vice versa. So assume that i deleted all of the items except the one automatically generated, will the one side replication from DC02 to CloudDC-01 still happen?

Another thing that you mention about the "Configure the primary DNS entry on CLOUD-DC01 to point to DC02". how should i do that? should i add the A records for CLOUD-DC01 on DC02 dns manager and add DC02 A records on the CLOUD-DC01 dns ?

Thanks

Hi Henry,

The four steps I listed above are all very straight forward. I think you're just worrying that removing a connection is going to break things permanently when it won't. As I said, you can actually delete all the connection objects if you wanted to and so long as the domain controllers can actually still resolve each other's records and still have IP connectivity with one another then they will rebuild their connections.

If you follow the steps I included two posts back, you're probably looking at an entire process of no more than ten minutes - depending on how comfortable you are with the metadata cleanup process (though if you don't force the KCC to run you could be waiting a tad longer.)

With respect to the DNS change on CLOUD-DC01, it's basic stuff. All you're doing is changing the Primary DNS Server address in the IPv4 configuration on CLOUD-DC01 to point to the IPv4 address DC02 (as per my second post from the top of the thread). That's all.

Cheers,
Lain

Hi Henry,

The four steps I listed above are all very straight forward. I think you're just worrying that removing a connection is going to break things permanently when it won't. As I said, you can actually delete all the connection objects if you wanted to and so long as the domain controllers can actually still resolve each other's records and still have IP connectivity with one another then they will rebuild their connections.

If you follow the steps I included two posts back, you're probably looking at an entire process of no more than ten minutes - depending on how comfortable you are with the metadata cleanup process (though if you don't force the KCC to run you could be waiting a tad longer.)

With respect to the DNS change on CLOUD-DC01, it's basic stuff. All you're doing is changing the Primary DNS Server address in the IPv4 configuration on CLOUD-DC01 to point to the IPv4 address DC02 (as per my second post from the top of the thread). That's all.

Cheers,
Lain

Hi Lain,

Thanks for your patience. As i am newbie, that's why i need to ask more before performing any steps.

I have followed your 3 out of 4 steps in the previous previous email.

1. In CLOUD-DC01 AD, i have deleted the manual connection site i created and left only one Automatically Generated that actually point to the CLOUD-DC02 that have problem and i have shutted down permanently and wait for the tombstone to expire before demotion.

2. I change the DNS IP address pointing to the DC02 for the Preferred DNS server and the Alternate DNS Server is to CLOUD-DC01 IP itself as it is also a DNS server.

3. I rebooted the CLOUD-DC01 and now it is already up. However, i still didn't find any changes. by right, under the Active Directory Site and Services, the CLOUD-DC01 (under NTDS Settings), it should automatically add in a new Connection Name with the "Automatically Generated" pointing to DC02 right?

4. I still didn't perform step 4 as step 3 is still not sure.

THanks.

Hi Henry,

Based on your screenshot above, you still need to remove CLOUD-DC02 as per the instructions I linked in the third last post (using either the "basic process" or "advanced process".) CLOUD-DC02 needs to be removed by you, you can't wait for a tombstone period to expire as even then the objects won't remove themselves.

Once you have removed the metadata belonging to CLOUD-DC02, you can force the ISTG to check the topology at both sites by logging onto CLOUD-DC01 and either DC01 or DC02 and running the following commands from an elevated command prompt:

• Run on DC01 or DC02: repadmin /kcc site:hqsite
• Run on CLOUD-DC01: repadmin /kcc site:cloudsite

This will force the KCC on each domain controller in each site to start the process of creating the new links.

Once you've run these commands, you want to check the Event Log\Directory Service log for any updates in status. You can also use repadmin to check and force replication as described earlier on.

If you're really struggling with this diagnostic then it might be a lot faster to simply demote CLOUD-DC01 and re-promote it.

Cheers,
Lain

• Edited by Lain Robertson 19 hours 56 minutes ago Removed misinformation.

Hi Henry,

Based on your screenshot above, you still need to remove CLOUD-DC02 as per the instructions I linked in the third last post (using either the "basic process" or "advanced process".) CLOUD-DC02 needs to be removed by you, you can't wait for a tombstone period to expire as even then the objects won't remove themselves.

Once you have removed the metadata belonging to CLOUD-DC02, you can force the ISTG to check the topology at both sites by logging onto CLOUD-DC01 and either DC01 or DC02 and running the following commands from an elevated command prompt:

• Run on DC01 or DC02: repadmin /kcc site:hqsite
• Run on CLOUD-DC01: repadmin /kcc site:cloudsite

This will force the KCC on each domain controller in each site to start the process of creating the new links.

Once you've run these commands, you want to check the Event Log\Directory Service log for any updates in status. You can also use repadmin to check and force replication as described earlier on.

If you're really struggling with this diagnostic then it might be a lot faster to simply demote CLOUD-DC01 and re-promote it.

Cheers,
Lain

• Edited by Lain Robertson Monday, July 13, 2015 11:04 AM Removed misinformation.

Hi Henry,

Based on your screenshot above, you still need to remove CLOUD-DC02 as per the instructions I linked in the third last post (using either the "basic process" or "advanced process".) CLOUD-DC02 needs to be removed by you, you can't wait for a tombstone period to expire as even then the objects won't remove themselves.

Once you have removed the metadata belonging to CLOUD-DC02, you can force the ISTG to check the topology at both sites by logging onto CLOUD-DC01 and either DC01 or DC02 and running the following commands from an elevated command prompt:

• Run on DC01 or DC02: repadmin /kcc site:hqsite
• Run on CLOUD-DC01: repadmin /kcc site:cloudsite

This will force the KCC on each domain controller in each site to start the process of creating the new links.

Once you've run these commands, you want to check the Event Log\Directory Service log for any updates in status. You can also use repadmin to check and force replication as described earlier on.

If you're really struggling with this diagnostic then it might be a lot faster to simply demote CLOUD-DC01 and re-promote it.

Cheers,
Lain

Hi Lain,

Thanks for your patient.

This morning, I found that the new connection has already been created by AD automatically. Look at the attached picture below:

So, i think i don't need to do the fourth step right? Because i checked inside the NTDS Container of CLOUD-DC01, the value is already DC02 However, when i right click and click "Replicate Now" From DC02, there is still DNS error below:

Can we just keep the CLOUD-DC02 there first as we have shutted the DC down. The Cloud-DC01 is completely new DC that i have just built in the cloud last Thursday. The reason i am doing it because i don't want to mess around with the CLOUD-DC02 which has been disjoined from domain. To save time, i just bult a new DC, CLOUD-DC01.

Currently, after check, when i create new objects on DC02, it is still replicated to CLOUD-DC01 but not vice versa.

FYI, currently every screenshot i taken was only from CLOUD-DC01 AD Server and I didn't make any changes or deletion of Active Directory and Site Services on DC02 yet. When i login to DC02 AD Server,  i found under the AD Site and Services, there is one connection that is not automatically generated under CLOUD-DC01 NTDS Container. I thought the list should be the same with the CLOUD-DC01? why am i seeing different list here? Should i also delete the one not automatically generated on my DC02 AD Server and wait till it generate by itself like the one one CLOUD-DC01?

Thanks for your attention.

Best Regards,

H

Hi Henry,

The fourth point isn't all that important and we should forget about it entirely at the moment until your replication problems are resolved.

To answer your question about removing CLOUD-DC02, yes, you really do need to remove it. It might not seem a big deal to you but underneath the surface that invalid metadata is going to negatively affect your Active Directory topology.

With respect to the error produced when you attempt manual replication, can you please run the following commands on DC02 and CLOUD-DC01 respectively and paste the output from both servers either back here in this thread or upload it to something like OneDrive as a text file. Feel free to change things like domain names and so on, but really, it's not what we'd consider sensitive information so it's up to you.

Commands to run on DC02 as well as CLOUD-DC01:

dcdiag /test:dns /dnsbasic /v

ipconfig /all

Cheers,
Lain

Hi Henry,

The fourth point isn't all that important and we should forget about it entirely at the moment until your replication problems are resolved.

To answer your question about removing CLOUD-DC02, yes, you really do need to remove it. It might not seem a big deal to you but underneath the surface that invalid metadata is going to negatively affect your Active Directory topology.

With respect to the error produced when you attempt manual replication, can you please run the following commands on DC02 and CLOUD-DC01 respectively and paste the output from both servers either back here in this thread or upload it to something like OneDrive as a text file. Feel free to change things like domain names and so on, but really, it's not what we'd consider sensitive information so it's up to you.

Commands to run on DC02 as well as CLOUD-DC01:

dcdiag /test:dns /dnsbasic /v

ipconfig /all

Cheers,
Lain

Hi Lain,

Thanks again for the advise.

May i know what is the different between Basic and Advanced that you advised earlier in the previous post? is clearing metadata is the same as demotion of AD? I think removing CLOUD-DC02 is not actually affecting the replication with the CLOUD-DC01 right? Now, whenever i try to make changes, i will always need to go to DC02 in premise AD and the changes to the objects that i made will be replicated to CLOUD-DC01 and vice versa.

However, when login to the DC02 AD, i found that the connection under CLOUDSITE CLOUD-DC01 container has only one DC02, whereby the cloud one has more. and this one is not automatically generated too. You may find the different between these two AD below:

DC02 (IN PREMISE AD)

CLOUD-DC01 (CLOUD AD)

What could be the issue causing this? i thought both DC02 and CLOUD-DC01 under CLOUDSITE should have the same list right?

Thanks.

Hi Henry,

I think you're misunderstanding the nature of connection objects. Connection objects only relate to inbound replication, not inbound and outbound. It's quite possible - and quite common where there's more than one domain controller at a site, that the servers selected for replication in one direction are different from those selected to perform replication in the opposite direction.

So to answer your final question, no, it's not correct to state that the connection list should be the same in both sites.

Based on your screenshots, I can still see two of the original issues:

1. You still have manual connections defined as shown in your first screenshot, where the connection object named DC02 is manual.
2. You still haven't cleaned out (or perhaps just finished the process) the metadata for CLOUD-DC02 as it's still showing up as an automatically generated link in the second screenshot when it should not be there at all. This is going to continue to create replication problems for you.

The difference between the "simple" and "advanced" processes I listed much earlier is that the advanced process goes beyond the basic "ntdsutil metadata cleanup" process and discusses the removal of DNS records and so on. As I mentioned before, I believe you would be better off following the "Clean up server metadata using GUI tools" section of the "basic" guide until you're more familiar with how Active Directory topology is generated as well as the command line tools that support it.

Again, to summarise - and I can't stress this enough, you need to remove all manual connections as well as cleaning CLOUD-DC02 out of your topology before you can make real headway in fixing replication.

If you're able to provide the output from the commands listed above, I can helped you in more detail, but for now, until you've taken care of the above two points there's nothing more I can do.

Cheers,
Lain

Just as a follow-up to my previous post, first of all I need to make a correction. Yes, the list should look the same when viewing the same site from different domain controllers. You're absolutely right about that; I just lost sight of what you were asking as I wasn't paying enough attention. I though you were asking me if both inbound connectors needed to be referring to the same servers in both directions, which they do not. Hence my mistake.

Even so, I've knocked up a quick-and-nasty Visio diagram to explain what I mean about the connection objects being one way and how they can point to any domain controller combination between the two sites.

The first diagram shows a very simple example where both of the connection objects point to the same domain controllers. Here, the result is guaranteed to look the "same" in both site views within Sites and Services.

The second diagram shows how when you have more than one domain controller at either or both sites, the domain controllers being referred to don't necessarily "line up".

Hopefully this helps you understand what I meant about connectors being inbound only.

Just the same, the same two points above relating to cleaning things up is still what you need to be focusing on in order to move forward.

Cheers,
Lain

Just as a follow-up to my previous post, first of all I need to make a correction. Yes, the list should look the same when viewing the same site from different domain controllers. You're absolutely right about that; I just lost sight of what you were asking as I wasn't paying enough attention. I though you were asking me if both inbound connectors needed to be referring to the same servers in both directions, which they do not. Hence my mistake.

Even so, I've knocked up a quick-and-nasty Visio diagram to explain what I mean about the connection objects being one way and how they can point to any domain controller combination between the two sites.

The first diagram shows a very simple example where both of the connection objects point to the same domain controllers. Here, the result is guaranteed to look the "same" in both site views within Sites and Services.

The second diagram shows how when you have more than one domain controller at either or both sites, the domain controllers being referred to don't necessarily "line up".

Hopefully this helps you understand what I meant about connectors being inbound only.

Just the same, the same two points above relating to cleaning things up is still what you need to be focusing on in order to move forward.

Cheers,
Lain

Hi Lain,

Thanks for the detail picture about the connection object. to be clearer, my scenario is actually the one below. Actually, Cloud-DC02 should not be connected to Cloud-DC01 since it is already shutted down, but it is automatically added and i think it is because belong to the same member inside the CLOUDSITE. am i right here?

About the Metadata cleanup, I am still not doing it as i am quite worry that i will make mistake and it will affect my primary domain controller which is DC01. From the article below about how to remove metadata after unsuccessful DC Demotion.

https://support.microsoft.com/en-us/kb/216498

My question are:

1. since i have not performed any demotion to the CLOUD-DC02 yet, is it best if i do the demotion first (i also don't know how to do demotion)? or is it because the CLOUD-DC02 has been forced to be disjoin from the domains and it means that it had been demoted?

2. From your expertise, should i login to DC02 DC and remove the the manually added DC02 under the CLOUDSITE->CLOUD-DC01->NTDS and wait for it to automatically generate the same list as CLOUD-DC01?

3. Lastly, since i have chosen DC02 to be the server where the CLOUD-DC01 should replicate from, does it also mean that DC02 will also automatically receive the replication from CLOUD-DC01 such as when i make changes to the objects inside AD using CLOUD-DC01?

Thanks.

Regards,

Hi Henry,

Looking at your questions in order:

1. From what you described earlier in the thread, it sounds like CLOUD-DC02 is no longer functional meaning you cannot perform a graceful demotion. That is why you need to use the metadata cleanup process I linked earlier.
2. Yes, log into DC02 and remove all manual connections from all sites. You don't need or want to be using manual connections.
3. You're not up to this stage yet as you have to fix all the above problems. But to answer your question, when you get this far, yes, anything changed on any of the domain controllers - which includes DC01, will replicate to all of the other domain controllers.

I honestly think if you're still worried about performing the metadata cleanup that you're better off engaging a professional services company to do this for you as it has to be done. They can also fix your derived issues in the space of minutes whereas this thread has been going on for days now.

Cheers,
Lain

Hi Henry,

Looking at your questions in order:

1. From what you described earlier in the thread, it sounds like CLOUD-DC02 is no longer functional meaning you cannot perform a graceful demotion. That is why you need to use the metadata cleanup process I linked earlier.
2. Yes, log into DC02 and remove all manual connections from all sites. You don't need or want to be using manual connections.
3. You're not up to this stage yet as you have to fix all the above problems. But to answer your question, when you get this far, yes, anything changed on any of the domain controllers - which includes DC01, will replicate to all of the other domain controllers.

I honestly think if you're still worried about performing the metadata cleanup that you're better off engaging a professional services company to do this for you as it has to be done. They can also fix your derived issues in the space of minutes whereas this thread has been going on for days now.

Cheers,
Lain

Hi Mr Lain,

Good Day. I am attached the screenshot when i am trying to check the replication issue by using dcdiag /test:replications from my cloud DC (CLOUD-DC01). from the result, is there any info that specify what is the cause of the replication issue? I have turn off both firewall services on both DC02 and CLOUD-DC01, thus it could not be port problem. Beside, i am able to telnet to port 53 for both of the servers too. Do you think it is issue with security between HQSITE DC (DC-02) with CLOUDSITE DC (CLOUD-DC01)?

Thanks.

Have a good day ahead

Regards,

H

Hi Henry,

The error shown is a DNS error.

Take a look in the Sites and Services MMC on CLOUD-DC01, navigate to CLOUDSITE/Servers/CLOUD-DC01, right-click on NTDS Settings, choose Properties and check if the DNS Alias value matches the DNS record shown above. If it does match, restart the NETLOGON service on CLOUD-DC01 to force the re-publication of the above record.

Is CLOUD-DC01 still pointing to DC02 for DNS?

Cheers,
Lain

• Edited by Lain Robertson 13 hours 10 minutes ago Changed formatting.