A friend and former co-worker of mine (Sean Deuby) has some excellent Active Directory Troubleshooting guides available online for free. These aren’t going to solve every problem for you but are great to ensure you have covered your basis when trying to troubleshoot Active Directory. Take a look at the link to see all the great help he has.
You know…is the Internet great? I mean really think about all the great things that are available at our finger tips, things like these great troubleshooting guides. The Internet hasn’t always been great but I’d say over the last 5 years it has really blossomed well. I know there is bad and harmful things out there but I really do believe that there is more good than bad…OK, time for me to stop thinking out loud again.
Last week I was a speaker at Tech Immersion 2011 here in Phoenix Arizona. I gave four talks on a range of topics that covered Active Directory, PowerShell and Server Core. Hopefully I have some new followers since the conference and if so make sure to say hi in the comments.
The highlight for myself was meeting Jeffrey Snover. If you don’t know who he is then you better Bing or Google him now. This is the father of PowerShell and now the Lead Architect for the Windows Server Division. He was really great to talk, in fact there were a lot of great presenters there including, PowerShell gurus Don Jones & James Brundage, Microsoft Certified Master’s Miguel Wood & Mike Pfeiffer, MVPs and MCTs such as Simon Allardice, Scott Cate, Jeff Jones, Spike Xavier as well as Microsoft employees Michael Palermo, Harold Wong, Tony Harris & Kathrine Lord and ITIL/COBIT Master Mark Thomas. I left one person out and that was on purpose. Jason Helmick…what can I say. He along with the rest of Interface Technical Training put on an excellent conference that will only grow more and more as time goes on. Great job Jason and Lynn from Interface as well as everyone else that supported this event.
Here is a pic of Jeffrey and I after the event hanging out at Dick’s Hideaway.
I can’t wait for Interface to host another great event like this.
Some of you may have used Acctinfo.dll in to get the additional Account Info tab when managing Active Directory from 2003 or Windows XP. It was a great add on that should you additional info about Users such as their GUID and SID amongst many other things.
I’ve heard rumors that some people have seen Acctinfo2.dll out in the wild…aka the Internet and that it works on Server 2008 R2. Please don’t download anything called Acctinfo2.dll from the Internet unless it is officially from Microsoft. I’m not saying that Acctinfo2.dll doesn’t exist…to be honest I have no idea because I’ve never tried to install it. But like you I’m not a fan on downloading something that could potentially do harm to my environment.
For those looking to get those “Additional Account” attributes you can still do it. The first way is to just use the Attributes tab in Active Directory Users and Computers, but there is a an even better way. All you really need to do is use the Active Directory Administration Center. Let me show you.
Once you open the Active Directory Administration Center up you can do a search for the user you want additional info on:
Now either double-click on that account or click the Properties from the Tasks on the right side.
These are the standard account properties…but…did you notice the area called Modified on the bottom? That is where the magic really happens.
Here you can see all sorts of goodies including an account’s SID. Just take a look at all that goodness.
Good stuff indeed. Now stop trying to download something that doesn’t exist except in Area 51.
I love PowerShell. The more I learn the better it becomes.
There are several versions of the Active Directory Schema available. You must know what version you are running to fully understand the capabilities it allows for. Below shows the different versions of the Active Directory Schema. The following link from MSDN should also update later versions.
Windows 2000 RTM = Schema version 13
Windows Server 2003 RTM = Schema version 30
Windows Server 2003 R2 RTM = Schema version 31
Windows Server 2008 RTM = Schema version 44
Windows Server 2008 R2 RTM = Schema version 47
Windows Server 2012 RTM = Schema version 56
Windows Server 2012 R2 RTM = Schema version 69
Windows Server 2016 RTM = Schema version 87
Now to see what version you are running just open up PowerShell (make sure you’ve loaded the native AD Cmdlets) and type the following:
Get-ADObject “cn=schema,cn=configuration,dc=domain_name,dc=local” -properties objectversion
Just check the objectversion results for the corresponding number above to check your schema version.
Here is a few one-liner commands to help get info on your Active Directory environment. I don’t think there is any mind blowing commands here but they’ve helped me out. There are literally hundreds of these around the web as well as PowerShell ones but these are the ones that I’ve been using lately.
How to view the Domains you trust and see what those Domain SIDs are:
nltest /domain_trusts /v
A quick listing of your AD Sites:
dsquery * "CN=Sites,CN=Configuration,DC=forestRootDomain" -attr cn description location -filter (objectClass=site)
A quick listing of your AD sites and their Site Links and Costs (sure would be nice if you could spit this out to Visio or something):
dsquery * "CN=Sites,CN=Configuration,DC=forestRootDomain" -attr cn costdescription replInterval siteList -filter (objectClass=siteLink)
Compare time against your forest root PDCe:
w32tm /monitor /computers:ForestRootPDC
Find out which DC for a site is the ISTG:
dsquery * "CN=NTDS Site Settings,CN=siteName,CN=Sites,CN=Configuration,DC=forestRootDomain" -attr interSiteTopologyGenerator
Time and time again I run into an issue that presents me with a SID which I need to resolve. I’ve used a number of tools and scripts over the years to address this issue. I think I have the best and easiest method for me to solve this issue that always seems to pop up.
If you’re new to PowerShell you will want to make sure you have it installed if you want to use this script…and yes it is a script not a command. I do this by opening a text file and renaming it from a .txt file to a .ps1 file. When you try to open a .ps1 file it may open in your text editor but for this you will want to Right Click it and select Edit which will open up whatever you have as your PowerShell editor. Copy the following code into the Script Pane:
$objSID = New-Object System.Security.Principal.SecurityIdentifier
$objUser = $objSID.Translate( [System.Security.Principal.NTAccount])
Now just save this file and you can run it to return the results of the SID that you place in there. The one thing that will change is the actual SID. In this example i’m using S-1-5-21-768745588-123456789-987654321-500 which is the Well Known SID for the domain Administrator. My results should show me the friendly name. Anytime you change the SID you will have to resave the file but then just Run the script and it will show you the results.
I’m sure there is a way I could make this into an application but I”ll leave that fun for those looking to take this to the next step.
I was thinking about writing a post about Active Directory replication but thankfully soon realized that by doing so I could be severely depriving my kids and wife of a happy life. Its not that Active Directory replication is bad or harmful, its just that there is so much about it. I don’t care who you are you probably don’t know it all…I certainly don’t and have never claimed too.
While I was doing my research for this post I found what I”d like to call the bible to Active Directory replication. I’m also thankful this was one of the first resources I picked up on and didn’t have to much time invested. Without further ado – How the Active Directory Replication Model Works. I think if you printed this out it would be about 100 pages or so (not confirmed but it is long).
This article goes over every little detail needed to fully understand the Active Directory replication model. I’d love to know the person/team that wrote this and give them my gratitude. I wish stuff like existed for new products. I still remember trying to learn Active Directory when it was in beta back in 1999 and not fully understanding USNs, Up-to-Dateness Vectors and Watermarks.
If you have any good resources on Active Directory replication please feel free to share so others can learn as well.
I’ve blogged several times about the AD Recycle Bin (ADRB). It has been a popular subject here at the Life of Brian and I can see why. It is a feature all AD admins have been screaming about for years. I wanted to spend 5 mins of your life going over two attributes that confuse everyone…even me from time to time.
There are over a dozen attributes that deal with ADRB but I want to focus on two of them, isDeleted and isRecycled. The first time I read through the documentation on these attributes I thought it was pretty straight forward, isDeleted is when an object is deleted and isRecycled is when an attribute is recycled. Well it is NOT that simple. Let me explain these attributes a bit further for your understanding.
The isDeleted attribute has been around since Windows 2000 and exists on every AD object. It describes if an object is deleted (makes sense) but also if it is restorable. After the ADRB is enabled you have the ability to restore deleted objects (that were deleted after it was enabled).
The isRecycled attribute is new to Windows Server 2008 R2 and only exists on an object after it has been recycled. By default, a deleted object will become a recycled object after the msDS-deltedObjectLifetime (another new attribute in Server 2008 R2) expires. Now that object is what I like to call dead dead. This means that you can’t restore it with all its pretty properties. Its kind of like the old way of restoring an object just to get its SID back.
I think you can see where the confusion comes into play. When I hear or read the term isDeleted my gut reaction is to think that it is deleted (dead dead) and when it says isRecycled I think it can be restored fully…well the sad truth is that it is the opposite.
You may be familiar with the traditional ways to transfer FSMO roles but how about by using PowerShell? By now you should just know that PowerShell can do everything the GUI can do…well at least that is the way it feels to me.
If you want to use PowerShell to transfer any of your five FSMO roles (PDC Emulater, RID Master, Infrastructure Master, Domain Naming Master and Schema Master) then you will first need to import the Active Directory Module into PowerShell.
Now that you have the AD module loaded the cmdlet you will use for this is quite large – Move-ADDirectoryServerOperationMasterRole. Thankfully we have the Get-help cmdlet to help us remember that. All I need to do is remember move-ad and then I press tab to complete the rest. There is only one other cmdlet that is similar to it and you just have to remember you are trying to move the FSMO role and not the sever.
When entering the cmdlet you need to specify the operation master roles to move. the syntax for the five roles are as follows – PDCEmulator, RIDMaster, InfrastructureMaster, SchemaMaster, or DomainNamingMaster. To specify more than one role just separate each role with a comma.
An example of me moving the RID Master and PDC Emulater to DC2 is as follows:
Move-ADDirectoryServerOperationMasterRole -Identity "DC2" -OperationMasterRole RIDMaster,PDCEmulator
A feature that I just love in PowerShell is the –WhatIf parameter. By adding this to your code it will do a dry run and let you know what is going to change if you did the command without that parameter.
One key thing to note here is that I am NOT seizing the FSMO role. For that you will need to use NTDSUtil as defined here.
Stale user accounts can be a big problem…even more so when they are not disabled. I’m a firm believer that if you have an account that is not being used it should be disabled. However depending on the size of your Active Directory that can be a daunting challenge. Below you will find a snippet of code that will identify where user accounts are not being used for 10 weeks and then it has the ability to disable them.
dsquery user -inactive 10 -limit 0
The 10 value is for the number of weeks an account has been inactive. If you think you are going to have a lot of these then you may want to change your limit from 0 to something like 50 or so.
Now if you would like to disable them as well you simply add on another portion of code. For safety reasons I prefer to run the code above first to see who is inactive and then once I’ve validated those accounts can be inactive I run the following code to disable them.
dsquery user -inactive 10 -limit 0 | dsmod user -disabled yes
Obviously the account needs to have the appropriate permissions for dsmod to work so watch out for that. Good luck and happy hunting!