Migrating Domain Controller to Azure

Please clarify.
Site to site VPN ?
What DNS servers does your system query?
Without an Internet feed, how are you expecting to hit an azure server?
The only way to have functionality is to have a local DC, short of that your logins will take some time (timeout period) unless your credential caching was restricted....

Yes, I have a site to site VPN currently. My goal is not to have the on-prem Domain controller anymore therefore I would not need to have the internet on-prem. We have moved from working in the office to working from home. The VM's in Azure uses the Domain controller I have in Azure for the DNS.

Let me explain further:

I have two Azure VMs one is a replica domain controller and the other is our ADFS server. When disconnecting the connection to the on-prem (Site to Site VPN), ADFS can't authenticate our passwords. Then when I try to log into the Domain controller in Azure it continuously says the username and password is incorrect. I don't understand why. If I made it the primary domain controller by moving all the FSMO roles, why does it need that connection to on-prem DC to authenticate? Thank you for your help. I am pretty new to Azure so if you need further clarification, please let me know.

Check the azure vm dc ntds within sites and services to make sure it is a global catalog (gc)

The tie in and DNS servers used on the systems
nslookup -q=srv _ldap._tcp.dc._msdcs.youraddomain.com

See what is returned?

Run
Dcdiag

It is listed as a global catalog in Sites and Services. Below are the results from the command you gave me. I have attached the log file from the dcdiag run. I notice it says the GC has not finished being promoted to GC, but it says it's a GC in Sites and Services.

C:\windows\system32>nslookup -q=srv _ldap._tcp.dc._msdcs.docauto.com
Server:  localhost
Address:  ::1

_ldap._tcp.dc._msdcs.docauto.com        SRV service location:
          priority       = 0
          weight         = 100
          port           = 389
          svr hostname   = sys-dc2.docauto.com
_ldap._tcp.dc._msdcs.docauto.com        SRV service location:
          priority       = 0
          weight         = 100
          port           = 389
          svr hostname   = sys-dc.docauto.com
_ldap._tcp.dc._msdcs.docauto.com        SRV service location:
          priority       = 0
          weight         = 100
          port           = 389
          svr hostname   = sys-dc1.docauto.com
sys-dc2.docauto.com     internet address = 10.1.0.4
sys-dc.docauto.com      internet address = 192.168.1.2
sys-dc1.docauto.com     internet address = 192.168.1.3

C:\windows\system32>
logfile.txt

Just a little more clarity. SYS-DC2 is the domain controller in Azure that is having the problem. SYS-DC is the on prem domain controller. SYS-DC1 is offline.

The 10.1.0.4 is a private ip space, without a VPN connection to the azure server,.
What about dcdiag status?

The 10.1.0.4 is the private ip for the sys-dc2 Azure DC. It does has a public ip as well. Currently, it still has the VPN connection because without it, I can't log in. The sys-dc is 192.168.1.2. I attached the log file for the dcdiag run in my previous reply. I will attach it to this one.
logfile.txt

You have many errors, also seems like you have long deprecated Dcs in the replication backlog....
Is what you have installed on the azure a writeable DC or a RODC?

Yes, it is a writable domain. I see that from the long we do have domains that are no longer in use. I am trying to remove the deprecated domains but it keeps failing. I was trying to do a metadata cleanup using ntdsutil but it continues to fail. When I manually try to remove them, it fails. Is there a way to stop the replication with the dead domain controllers? If so, would that fix the global catalog issue?

Where are you trying to clearup on which system?
from your error it seems you transferred roles prematurely.
Make sure the replication between your on premises dc is accessible from the azure DC.

Repadm ..

I was trying on the Azure DC. The on-prem dc and the azure dc can talk to one another. Would I need to go back to the on-prem DC to do the metadata cleanup since I transferred roles before replication was finished?

You shoukd try metadata cleanup on the on-premise DC.
You could look at ntds on the azure side to see whether it reflects the old objects.

I was able to clean up some of the metadata and now it is passing the advertising test. I don't get the error about it not completing the GC promotion anymore.
dcdiaglog.txt

Arnold was a big help with this time sensitive issue. The domain controller was not advertising as the Global Catalog which was the issue. This was my first experience on Experts Exchange and I am definitely satisfied with the results. Thanks again Arnold for your help!