Introduction I have been wanting to do an Active Directory Tips and Tricks post for troubleshooting and proper setup for some time no...
Introduction
I have been wanting to do an Active Directory Tips and Tricks post for troubleshooting and proper setup for some time now and so after a nice relaxing weekend I decided to work this up for the community.
Steps (11 total)
Many times I have come across AD setups with bad choices for the domain name. Most of you will be aware that as of a few years ago you can no longer issue 3rd party SSL certs with the *.local domain name in the Subject Alternative Names. Further I have found many times the root domain is chosen as the AD domain name. This is also not viable for a long term AD domain choice as the AD wants to be Authorative for the Domain name you choose. So with both those things in mind, to choose properly we need to choose a subdomain of our root DNS domain name.
Most deployments I have found have one site and this is usually the corporate office. So I would usually choose
office.domainname.com or corp.domainname.com
This would allow me to put up an A Record in the Root DNS servers pointing at the WAN address of the corporate office firewall. That way we can have everything routable and we can issue 3rd party SSL certs for the subdomains or just get a *.domainname.com wildcard SSL for the whole organization.
office.domainname.com or corp.domainname.com
This would allow me to put up an A Record in the Root DNS servers pointing at the WAN address of the corporate office firewall. That way we can have everything routable and we can issue 3rd party SSL certs for the subdomains or just get a *.domainname.com wildcard SSL for the whole organization.
Choose right from the beginning and it will keep your event logs clear and keep everything looking for AD services pointed in the right direction.
Setting up AD DNS is basically handled for you when you create a brand new Forest and Domain using Server Manager and the Active Directory Wizard.
Choosing the right domain name is critical for this step in your AD infrastructure build out so get it right the first time...
Choosing the right domain name is critical for this step in your AD infrastructure build out so get it right the first time...
If you find yourself like I often do encountering AD that is already setup and not functioning correctly then you need to clean up the DNS entries as a first step.
Start by finding and logging into the PDC so you can do a top down cleanup of any DNS issues.
*Tip - To find the PDC, open a CMD prompt and type:
NetDom Query FSMO
*Tip - To find the PDC, open a CMD prompt and type:
NetDom Query FSMO
Once you locate the PDC, then remote in and open DNS Manager from Administrative Tools. The next few steps is what I do to clean up DNS.
I have a quick check of the time stamps to get an idea of what is going on with the DC's.
Once in DNS we need to check the following items:
1- Check the _MSDCS forward lookup zone and be sure we have good information listed for the AD servers.
Once in _MSDCS you will see all the DC's listed that are supposed to be online and active. I usually check the Time Stamp of the DC's and check to be sure the date showing is within 7 days of today. If you have old servers listed with Time Stamps outside this 7 day range, that is a problem as they are not updating the DNS records and most likely are not replicating as well. This is my very first indicator of any Domain Controller DNS or replication issues.
Once in DNS we need to check the following items:
1- Check the _MSDCS forward lookup zone and be sure we have good information listed for the AD servers.
Once in _MSDCS you will see all the DC's listed that are supposed to be online and active. I usually check the Time Stamp of the DC's and check to be sure the date showing is within 7 days of today. If you have old servers listed with Time Stamps outside this 7 day range, that is a problem as they are not updating the DNS records and most likely are not replicating as well. This is my very first indicator of any Domain Controller DNS or replication issues.
Start by looking over _MSDCS DNS Zone and checking the time stamp to see if you can spot the problem DC's. Usually it is an old DC that was decommissioned but not gracefully DCPROMO'd from the environment. These extra entries will cause confusion about where your servers and workstations look for LDAP services from Active Directory. This can at its least cause delays in finding resources, and at worst can cause AD to stop responding altogether.
If the server listed is one that is Orphaned or is no longer in play you need to delete that bad data out of DNS, and that means checking EVERY SINGLE DNS ZONE under _MSDCS. Look for that orphaned server or IP and delete it.
NameServers on the Zone files also need to be looked over so right click on the zone and choose properties then NameServers tab. Verify top to bottom that the name servers listed are the ones that are operational DC's and remove any old entries. I also like to verify the existing ones by clicking them one at a time, and then choose edit and then resolve, to force the server to be sure it gets the green check. That way you really know all is tip top...
Now that DNS is clean and all the settings for DNS have been checked and verified, one further step I do after I clean DNS is to setup the DNS console with all the DNS servers in the environment.
This accomplishes two things:
1)it confirms that you have the correct IP's for those servers listed in the PDC DNS, and
2) it gives you a single pane to work your DNS checks from.
1)it confirms that you have the correct IP's for those servers listed in the PDC DNS, and
2) it gives you a single pane to work your DNS checks from.
Now that we have a clean DNS we need to verify that all the AD Replication connects between the servers are set properly and we do this from AD Sites and Services.
Open Server Manager and then Tools and Active Directory Sites and Services.
Once in the console drill down to the Default-First-Site-Name and then expand the Servers node.
You will see a list of all the DC's in that Default site. What you now need to do is be sure all of the Domain Controllers showing are actually in play. If you find some that have been decommissioned / offline but not gracefully DCPRMO'd from AD then you need to first delete the NTDS connections under that orphaned server and then delete the NTDS subtree and then finally the server reference. This will allow REPADMIN to run correctly and find good servers so that we can move on.
You will see a list of all the DC's in that Default site. What you now need to do is be sure all of the Domain Controllers showing are actually in play. If you find some that have been decommissioned / offline but not gracefully DCPRMO'd from AD then you need to first delete the NTDS connections under that orphaned server and then delete the NTDS subtree and then finally the server reference. This will allow REPADMIN to run correctly and find good servers so that we can move on.
Once all the orphaned NTDS AD Replication Connections have been deleted and the server references as well you can then move on to assigning the proper subnets to the respective sites.
Create the smallest number of sites possible to keep replication performance acceptable. Go ahead and right click Sites and choose New Site if you have more than one site with domain controllers located in it. You really only want to create sites that have DC's located on premise.
Create the smallest number of sites possible to keep replication performance acceptable. Go ahead and right click Sites and choose New Site if you have more than one site with domain controllers located in it. You really only want to create sites that have DC's located on premise.
One thing that is often overlooked is setting the IP Subnet assignments for your sites. Most of you will have a few DC's in the same Site and subnet assignment can be overlooked. Once you expand your AD into another site and subnet over VPN or MPLS then you would want to first define all the various subnets and then assign those subnets to the sites. You can have more than one subnet per site so just create all them and think of the site as a group. When various workstations attached to the domain pop up with a IP in that subnet then that DC is assumed local and the workstation will look to the local site first for LDAP services.
Subnets will be entered like
192.168.1.0/24
Just right click the Subnets Folder and choose New Subnet. Drop down to choose the sites
Subnets will be entered like
192.168.1.0/24
Just right click the Subnets Folder and choose New Subnet. Drop down to choose the sites
Replication between domain controllers happens every 180 min or 2 min if you reset a password. Once you have a clean Sites and Services replication links (*usually setup automatically by the replication engine) you can then go about testing replication using the following commands.
The first command is a quick sync and does all the connects at once and reports success or error. The command with the /ADEP is a step by step through each connect stopping for you to hit continue and does a full sync with extended attributes synced.
The first command is a quick sync and does all the connects at once and reports success or error. The command with the /ADEP is a step by step through each connect stopping for you to hit continue and does a full sync with extended attributes synced.
RepAdmin /SyncAll
RepAdmin /SyncAll /ADEP
RepAdmin for Experts
https://technet.microsoft.com/en-us/library/cc811549
https://technet.microsoft.com/en-us/library/cc811549
Now open a CMD prompt run as Administrator so we can run DCDIAG to check AD health.
This will give a quick high level overview of your AD health so we can narrow down any issues with accessing LDAP resources.
This will give a quick high level overview of your AD health so we can narrow down any issues with accessing LDAP resources.
What I like to do after I clean up DNS is to save and clear the event logs and reboot the PDC. This will have the PDC go through the AD motions during boot and then you will get a good solid picture of your current issues when running DCDIAG.
Now open CMD RunAs Administrator and Type
DCDIAG
This will verify the DC health so you should make note of any errors and then researching those specific issues and event ID's on the internet.
Run the DCDiag DNS Health Checks
DCDIAG /DnsAll
DCDIAG /DnsAll
Dump DCDiag results to a text file
DCDIAG /f:C:\DCDIAGReport.txt
DCDIAG /f:C:\DCDIAGReport.txt
The last step is to run a Best Practices Scan from the Server Manager Console for AD DS and remedy any errors and warnings. This final step will confirm that all with AD is operating correctly. Just research the errors if they are displayed and follow the necessary resolution steps. To many to mention here but one that will show for most is the check to see if this DC is running as a Virtual Machine and makes reference to best practices needing to be followed. This one is common and can be ignored in most cases.
Protect all OU's in this organization from accidental deletion command to protect all unprotected OU's.
Open PowerShell on the PDC RunAs Administrator
Get-ADOrganizationalUnit -filter * -Properties ProtectedFromAccidentalDeletion | where {$_.ProtectedFromAccidentalDeletion -eq $false} | Set-ADOrganizationalUnit -ProtectedFromAccidentalDeletion $true
Open PowerShell on the PDC RunAs Administrator
Get-ADOrganizationalUnit -filter * -Properties ProtectedFromAccidentalDeletion | where {$_.ProtectedFromAccidentalDeletion -eq $false} | Set-ADOrganizationalUnit -ProtectedFromAccidentalDeletion $true
The next evolution of AD is Azure Active Directory. This is easy to connect to your local AD using the Azure AD connect tool which you can download here.
http://www.microsoft.com/en-us/download/details.aspx?id=47594
Once you connect your on-premise AD to Azure you can then leverage the new features in Windows 10 that will allow you to connect remote users to your internal AD without the need for VPN. This cloud ready AD is the future and I would encourage all of you to give it a try.
http://www.microsoft.com/en-us/download/details.aspx?id=47594
Once you connect your on-premise AD to Azure you can then leverage the new features in Windows 10 that will allow you to connect remote users to your internal AD without the need for VPN. This cloud ready AD is the future and I would encourage all of you to give it a try.
Conclusion
Active Directory can be tricky if it is not setup correctly and I hope this how-to helps you with your AD adventures!
Good Luck and Happy Computing!
No comments
Post a Comment