Schema version


Many times I saw on forums that people ask, how to check current schema version. They want to know if they need to extend it before adding new server OS as Domain Controller. I decided to write this short post about that (yes, I know that in the Internet is many other sites with this topic :)  but I wanted to show this my way)

Let’s start. We have few possibilities to check that

  • GUI console (ADSI Editor)
  • Microsoft DS Tools (dsquery command)
  • 3rd party tools (i.e. adfind from Joe Ware)

I will show you how you can check schema version using all of mentioned options

ADSI Editor

On Windows Server 2003 to be able to run this console (adsiedit.msc) you need to install first Windows Server 2003 Support Tools from the first server installation CD. You can find them in a location of your CD/DVD-ROM drive in \Support\Tools directory, install suptools.msi file.

Whereas on Windows Server 2008 you need to add “Active Directory Domain Services Tools” from Control Panel -> RSAT -> Role Administration Tools (on a DC these tools are available by default, when you pormote server as Domain Controller, they are installed automatically)

When you have done adding necessary tools to your system, you can start ADSI Editor. To do that in run box type adsiedit.msc and press enter

Running ADSI Editor

You should see ADSI Edit, now. To check schema version, select “Schema” well know Naming Context in left pane, expand it and select schema container

Selecting schema Naming Context

Click on it right mouse button and choose “Properties“. In “Attribute Editor” search for objectVersion attibute and check its value. That value is current schema version.

Schema version value (Windows Server 2003)

Schema version value (Windows Server 2008/2008R2)

Schema version of

  • 13 – Windows 2000 Server
  • 30 – Windows Server 2003 (realease 1)
  • 31 – Windows Server 2003 R2 (release 2)
  • 44 – Windows Server 2008 (release 1)
  • 47 – Windows Server 2008 R2 (release 2)
  • 51 – Windows Server 8 Developers Preview (new server edition; now only in Developer’s preview for MSDN subscribers)
  • 52 – Windows Server 8 Beta (publicly available)
  • 56 – Windows Server 2012 (release 1)
  • 69Windows Server 2012 R2 (release 2)

Microsoft DS Tools

Another short and also simple method for achiving that are Microsoft DS Tools and to be more specific – dsquery command.

DS Tools are available on each Domain Controller or workstation/server with Administrative/RSAT Tools installed.

To start checking schema version from command-line type

dsquery * “cn=schema,cn=configuration,dc=domain,dc=local” -scope base -attr objectVersion

DSQUERY syntax

An output of that command will show you schema version value

DSQUERY output

3rd party tool ADFIND

This tool is completely free and can be downloaded from http://www.joeware.net/freetools/tools/adfind/index.htm

This is very poweful tool which can be used for other Active Direcrory/LDAP queries, not only for schema version. I learnt using the tool on Experts-Exchange forum from Mike (mkline71) who really knows how to use that :]

When you downloaded ADFIND open command-line and go to folder where it is saved and run this syntax

adfind -sc schver

and that’s all, review its output. You will see everything what you want to know about schema version

ADFIND output

You can use registry too:

HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parame ters\SchemaVersion

Enjoy checking schema version.

It’s done.

Advertisements

Raising Forest Functional Level


Introduction

This article describes how to raise Forest Functional Level and how to do that. But at the first stage, we will focus on prerequisites for this action.

Forest Functional Level determines which features are available in a forest (each domain within a forest) and which operating systems may act as Domain Controllers. This is really important to understand it appropriately before you start raising FFL.

Important! The most important thing is that raising FFL into higher level is one time action and cannot be reverted using the same console to previous state or lower mode. You need to restore your forest from backup. So, before doing that, please consider it wisely.

Note! There is one scenario when you can go back with Forest Functional Level without using backup. This situation is when you have Windows Server 2008R2 FFL and you did not enable Active Directory Recycle Bin. Only then you can go back.

You can raise Forest Functional Level using this tool:

  • Active Directory Domains and Trusts

To be able to raise FFL, user account on which you want to do the action, must be a member of “Enterprise Administrators” group.

We have currently 5 Doman Functional Levels available(6 including Windows Server 8 Beta :)  but this article doesn’t count this OS as this is beta version):

  • Windows 2000 Native
  • Windows Server 2003 Interim
  • Windows Server 2003
  • Windows Server 2008
  • Windows Server 2008R2

and mentioned beta FFL Windows Server 8 Beta (which probably would be changed to Windows Server 2012 in final release) Each Forest Functional Level introduces new features in a forest. So, that’s why it is worth raising. This short brief shows what kind of features we have in each FFL:

Windows 2000 Native mode [1]

  • Domain Name change
  • Universal Distribution Groups
  • Group Nesting for Distribution Groups
  • Group Nesting for Domain Local Security Groups which can contain Global Security Groups as members

In this mode, you can only use these Operating Systems as Domain Controllers in whole forest (in each domain):

  • Windows 2000 Server
  • Windows Server 2003
  • Windows Server 2003R2
  • Windows Server 2008
  • Windows Server 2008R2

To be able to set up Windows 2000 Native FFL, all domains in a forest must be operating at Domain Functional Level Windows 2000 Native mode (more about DFL in my previous article)

Windows Server 2003 mode [1] All Windows 2000 Native mode features plus:

  • Forest trust
  • Domain rename
  • Linked-value replication
  • The ability to deploy a read-only domain controller (RODC)
  • Improved Knowledge Consistency Checker (KCC) algorithms and scalability
  • The ability to convert an inetOrgPerson object instance into a User object instance
  • Deactivation and redefinition of attributes and classes in the schema
  • Domain-based DFS namespaces running in Windows Server 2008 Mode

In this mode, you can only use these Operating Systems as Domain Controllers in whole forest (in each domain):

  • Windows Server 2003
  • Windows Server 2003R2
  • Windows Server 2008
  • Windows Server 2008R2

To be able to set up Windows Server 2003 FFL, all domains in a forest must be operating at Domain Functional Level Windows Server 2003 mode (more about DFL in my previous article)

Windows Server 2008 mode [1] All Windows Server 2003 mode features. There is no new features introduced.

In this mode, you can only use these Operating Systems as Domain Controllers in whole forest (in each domain):

  • Windows Server 2008
  • Windows Server 2008R2

To be able to set up Windows Server 2008 FFL, all domains in a forest must be operating at Domain Functional Level Windows Server 2008 mode (more about DFL in my previous article)

Windows Server 2008R2 mode [1] All Windows Server 2008 mode features plus:

  • Active Directory Recycle Bin

In this mode, you can only use Windows Server 2008R2 as Domain Controllers in whole forest. There is no possibility to run the older operating systems as Domain Controllers in this mode.

To be able to set up Windows Server 2008R2 FFL, all domains in a forest must be operating at Domain Functional Level Windows Server 2008R2 mode.

Note! Simply saying, the lowest Domain Functional Level within a forest, the highest possible Forest Functional Level

That’s all about theory, now we will see, how to do that.

We know everything what we should know about FFLs and we can start raising it.

Scenario

This is a single forest, multiple domain environment where testenv.local is forest root domain. There are also two other child domains: child.testenv.local and child2.testenv.local.

Domain Functional Level each of them is: testenv.local              – Windows Server 2008R2 mode child.testenv.local    – Windows 2000 Native mode child2.testenv.local  – Windows 2000 Mixed mode

as in my forest there is no more Windows NT4, Windows 2000 Server and I do not plan to use them anymore, I would raise my forest Functional Level into Windows Server 2003 mode. But first of all, my child domain’s DFL must be raised up.

For child.testenv.local I will raise DFL into Windows Server 2008R2 (as there are only Windows Server 2008R2 Domain Controllers) For child2.testenv.local I will raise DFL into Windows Server 2003 (as there are no older Domain Controllers that 2003, and I cannot raise it higher because server 2003 is still used for DCs)

After that, the lowest DFL in my forest will be child2.testenv.local which is Windows Server 2003. So, the highest possible Forest Functional Level is Windows Server 2003.

I will only show you, how to raise Forest Functional Level. For information about raising DFL, please read my previous article about that.

Raising Forest Functional Level using Active Directory Domains and Trusts console

Open Active Directory Domains and Trusts console from “Administrative Tools” and select root node

Active Directory Domains and Trusts console

Click right mouse button on it and choose “Raise Forest Functional Level…” option from the list

Choosing an option to raise FFL

From the drop down list choose suitable Forest Functional Level (in this case it is Windows Server 2003) and click on “Raise” button

Available FFL options

FFL selected

confirm that you are sure what you are doing

Confirmation

Congratulations! Your Forest Functional Level has been raised up!

FFL has been raised up

Current FFL mode

That’s all!

Raising Domain Functional Level


Introduction

This article describes how to raise Domain Functional Level and how to do that. But at the first stage, we will focus on prerequisites for this action.

Domain Functional Level determines which features are available in a domain and which operating systems may act as Domain Controllers. This is really important to understand it appropriately before you start raising DFL.

Important! The most important thing is that, raising DFL into higher level is one time action and cannot be reverted using the same console to previous state or lower mode. You need to restore your forest from backup. So, before doing that, please consider it wisely.

You can raise Domain Functional Level using these tools:

  • Active Directory Users and Computers
  • Active Directory Domains and Trusts

both consoles allow for DFL change and they show the current Domain Functional Level.

To be able to raise DFL, user account on which you want to do the action, must be a member of “Domain Admins” or “Enterprise Administrators” group.

We have currently 6 Doman Functional Levels available(7 including Windows Server 8 Beta :)  but this article doesn’t count this OS as this is beta version):

  • Windows 2000 Mixed mode
  • Windows 2000 Native mode
  • Windows Server 2003 Interim mode
  • Windows Server 2003 mode
  • Windows Server 2008 mode
  • Windows Server 2008R2 mode

and mentioned beta DFL Windows Server 8 Beta (which probably would be changed to Windows Server 2012 in final release)

Each Domain Functional Level introduces new features in a domain. So, that’s why it is worth raising. This short brief shows what kind of features we have in each DFL:

Windows 2000 Mixed mode [1]

  • Domain Name change
  • Universal Distribution Groups
  • Group Nesting for Distribution Groups
  • Group Nesting for Domain Local Security Groups which can contain Global Security Groups as members

In this mode, you can use these Operating Systems as Domain Controllers:

  • Windows NT4
  • Windows 2000 Server
  • Windows Server 2003
  • Windows Server 2003R2

higher OSes are unavailable because Windows Server 2008 and above doesn’t support Windows NT DCs. If you want to use Windows Server 2008 then you need to migrate all of your NT4 DCs at least to Windows 2000 Server and raise Domain Functional Level to Windows 2000 native mode.

Windows 2000 Native mode [1]

  • Universal Groups for all types (Security, Distribution)
  • Group Nesting allowed for all groups (Global, Universal, Domain Local)
  • Group type conversion
  • SID History enabled

In this mode, you can use these Operating Systems as Domain Controllers:

  • Windows 2000 Server
  • Windows Server 2003
  • Windows Server 2003R2
  • Windows Server 2008
  • Windows Server 2008R2

Look, this is no possibility to run Windows NT4 Domain Controllers in this mode. So, if you have not any Win NT DCs in a domain and yo do not plan use any of them in the future, you can simply raise Domain Functional Level into Windows 2000 Native mode.

Windows Server 2003 mode [1] All Windows 2000 Native mode features plus:

  • Domain Controller name change
  • Domain name change
  • Possibility to change default location of newly created user/computer objects
  • logonTimestamp and lastLogonTimestamp attributes update
  • InetOrgPerson password set up on userPassword attribute
  • Selective authentication for users/groups/computers from trusted domains

In this mode, you can use these Operating Systems as Domain Controllers:

  • Windows Server 2003
  • Windows Server 2003R2
  • Windows Server 2008
  • Windows Server 2008R2

Look, this is no possibility to run Windows NT4 and Windows 2000 Server Domain Controllers in this mode. So, if you have not any Win NT and 2000 DCs in a domain and you do not plan to use any of them in the future, you can simply raise Domain Functional Level into Windows Server 2003 mode.

Important! When you raise your Domain Functional Level into Windows Server 2003 Interim mode then you can only use Windows NT4, Windows Server 2003 and Windows Server 2003R2 Domain Controllers! This DFL mode cannot be directly set up using the same consoles as for other modes. For that you need to use ADSIEdit tool and raise Forest Functional Level to Windows Server 2003 Interim mode.

For more information about that, please visit Microsoft Technet and read this article

Windows Server 2008 mode [1] All Windows Server 2003 mode features plus:

  • DFS replication support for Windows 2003 SYSVOL
  • Domain-based DFS namespaces running in Windows Server 2008 Mode
  • AES 128 and AES 256 support for the Kerberos protocol
  • Last Interactive Logon information
  • Fine-grained password policies
  • Personal Virtual Desktops

In this mode, you can use these Operating Systems as Domain Controllers:

  • Windows Server 2008
  • Windows Server 2008R2

Look, this is no possibility to run Windows NT4, Windows 2000 Server, Windows Server 2003 and Windows Server 2003R2 Domain Controllers in this mode. So, if you have not any of these DCs in a domain and you do not plan to use them in the future, you can simply raise Domain Functional Level into Windows Server 2008 mode.

Windows Server 2008R2 mode [1] All Windows Server 2008 mode features plus:

  • Authentication mechanism assurance
  • Automatic SPN management

In this mode, you can only use Windows Server 2008R2 as Domain Controllers. There is no possibility to run the older operating systems as Domain Controllers in this mode. So, if you have not any of them and you do not plan to use them in the future, you can simply raise Domain Functional Level into Windows Server 2008R2 mode.

That’s all about theory, now we will see, how to do that.

We know everything what we should know about DFLs and we can start raising it.

Scenario

This is a single forest, multiple domain environment where testenv.local is forest root domain. There were Windows 2000 Server Domain Controllers which were replaced by the new ones with Windows Server 2008R2 OS. All the old DCs are decommissioned but the Domain Functional Level is set up as Windows 2000 Native mode. Now, I know that I have no any 2000,2003 and 2008 DCs and I do not plan to use them in the future, I can raise DFL to Windows Server 2008R2 mode.

Raising Domain Functional Level using Active Directory Users and Computers console

Open ADUC console from “Administrative Tools”

ADUC console

Select DNS domain name at the top of console and click on it right mouse button. Choose “Raise domain functional level…” option from the list.

Choosing option to raise DFL

DFL available options

From the drop down list, select appropriate Domain Functional Level. In my case, it is Windows Server 2008R2

Choosing DFL mode

and click on “Raise” button. Confirm that you are sure to do that

Confirmation

Congratulations! Your Domain Functional Level has been raised!

Information about raised DFL

Information about current DFL

Raising Domain Functional Level using Active Directory Domains and Trusts console

Open Active Directory Domains and Trusts console from “Administraive Tools”

Active Directory Domains and Trusts console

From available domains list select that one on which you want to raise DFL. Click on it right mouse button and choose “Raise domain functional level…” option from the list.

Option to raise DFL

From the drop down list, select appropriate Domain Functional Level. In my case, it is Windows Server 2008R2

Available DFLs

and click on “Raise” button

Raising DFL

Congratulations! Your Domain Functional Level has been raised

DFL has been raised

Current DFL mode

That’s all!

Redirecting default computers location in Active Directory


You may wish to apply some group policies to newly joined computer in a domain. By default the only one takes affect, it is “Default Domain” policy. What if you have some GPOs which are installing software on your new computers? Do you need to manually move computer account into that OU to trigger software installation?

NO! You can change default computer accounts location after joining to the domain. You need to use redircmp command and specify new location. After that, all newly joined machines will be redirected into that OU.

Note! Redicmp is by default available on any Windows Server 2008/2008R2 Domain Controller. If you want to use that on Windows Server 2003, you need to first install Support Tools from the first CD.

Command’s syntax is very easy to understand. You need to only know Distinguished Name of an OU to which you want to redirect joined computers. In Active Directory domain, default location for new joined computers is “Computers” container.

Default computer accounts location in AD

If you are not sure what Distinguished Name of an OU is, you can simply use DSQUERY command to determine it.

dsquery ou -name

i.e: dsquery ou -name “newcomps”

Getting distinguished name of an OU

When you know that name, you can run redircmp command

redircmp DistinguishedName

i.e. redircmp “ou=newcomps,ou=installation,dc=testenv,dc=local”

Redirecting computers location

From now, all newly joined computers will be added with that location.

New computer accounts location

In case that you delegated task of joining computers to domain also to other users than domain administrators, you need to ensure if they have “Write computer objects” permission within that location.

Checking delegated permissions

if not, you need to grant access to that group of users by delegating proper permissions over “Delegate control” wizard. Add appropriate group and follow below steps

Delegating rights

Delegating rights

in case that you also with to allow them removing computers from domain, grant them “Delete selected objects in this folder”

Delegating rights

Delegating rights

and that’s all!

How to migrate OU structure from one domain to another


Sometimes you may face an “issue” when you are migrating domain, using ADMT or another tool which does not support OU migration, to the new domain within the same forest or to completely new one.

Do you need then to rebuild everything manually or resign from existing OU scheme? No, you can very simply extract OU structure from one domain and import it to another. To achieve that you need to only use LDIFDE command which is available on any Domain Controller.

In this example, I will show you how to export OUs from one domain to flat text file, modify appropriate part of that file and import it to the new domain.

As you can see below on a screen, in my test environment some Organizational Units already exist. I would like to keep them in my new forest but I do not want to recreate whole structure manually. LDIFDE will help me to get everything to text file in really short time.

OUs structure in the old domain

There are many Organizational Units which I want to create in the new domain in another forest. To export all necessary information about OU objects, I need to run below syntax

ldifde -f c:\OUs.ldf -r “(objectClass=organizationalUnit)” -l objectClass,description

Exporting OU structure

on C-Drive in OUs.ldf file I will have all exported structure almost ready to import in another domain. There were 39 OUs exported which I can simply view in notepad

LDIFDE exported data

Now, I need to make some simple changes in LDF file to be able to import it in another domain. The most important part to change is distinguished name of the old domain. The old domain name is testenv.local and the new one is testcorp.local

So, I need to replace all dc=testenv,dc=local entries with the new domain’s DN dc=testcorp,dc=local

Old DN of domain

To do that, LDF file needs to be opened in notepad. When file is opened, CTRL+H key combination for text pattern replacement can be used

Old DN replacing by the new one

and LDF file is preapred with distinguished name of the new domain

New domain DN in LDF file

The last step before LDF file can be imported in the new domain, is “Domain Controllers” OU deletion from input file. As this OU exists by default in each domain, there is no need to create it. Just search Domain Controllers OU in LDF file and delete its entries as they are not required

Deleting Domain Controllers OU from LDF file

Now, file is ready to be copied to the new domain for import. On a Domain Controller from the new domain in command-line this syntax should be executed to import OU structure

ldifde -i -f c:\OUs.ldf

OU structer import in the new domain

You can see that 39 entries were exported and 38 were imported (minus one as Domain Controllers OU was deleted from input file). So, whole operation has been finished successfully. I have all OUs in the new domain now.

OU structure in the new domain after OUs import

and that’s all! OU structure is the same in the new domain!

Determine DFL and FFL using PowerShell


For Domain Functional Level you need to query Default naming context (domain partition) and read msDS-Behavior-Version attribute. Its value tells you what kind of DFL is present in your domain. However, today, there is no need to check if domain is working in 2000 mixed mode but I decided also to put that information into script to have full overview of DFL. In this case (mixed mode) you have to check ntMixedDomain attribute.

If ntMixedDomain attribute is set to that means Domain Functional Level is not in 2000 mixed mode. In case that this attribute is set to 1 then DFL is Windows 2000 Mixed mode.

For msDS-Behavior-Version attribute value and its corresponding DFL check below list

  • 0 – Windows 2000 Native mode
  • 1 – Windows Server 2003 Interim mode
  • 2 – Windows Server 2003 mode
  • 3 – Windows Server 2008 mode
  • 4 – Windows Server 2008 R2 mode
  • 5 – Windows Server 2012 mode
  • 6 – Windows Server 2012 R2 mode

To get Forest Functional Level mode, you need to check the same msDS-Behavior-Version attribute but in different AD object. This object is

cn=partitions,cn=configuration,dc=testenv,dc=local

on Configuration partition

Note! Remember that Forest Functional Level mode cannot be higher than Domain Functional Level. Its value may be equal or less but never HIGHER!

For msDS-Behavior-Version attribute value and its corresponding FFL check below list

  • 0 – Windows 2000 mode
  • 1 – Windows Server 2003 Interim mode
  • 2 – Windows Server 2003 mode
  • 3 – Windows Server 2008 mode
  • 4 – Windows Server 2008 R2 mode
  • 5 – Windows Server 2012 mode
  • 6 – Windows Server 2012 R2 mode

that’s all available option at this moment, so now it is possible to prepare PowerShell script checking that attribute and comparing it to above lists

Windows PowerShell module for Active Directory

Open Windows PowerShell or Windows PowerShell module for AD and use below syntax to get Domain Functional Level mode (in case that you are using module for AD, you don’t need to use Import-Module cmd-let!)

Import-Module ActiveDirectory
Get-ADObject -Identity "dc=testenv,dc=local" -Properties * | Select msDS-Behavior-Version,ntMixedDomain

Windows PowerShell syntax for DFL

Get-ADObject -Identity "cn=partitions,cn=configuration,dc=testenv,dc=local" -Properties * | Select msDS-Behavior-Version

Windows PowerShell syntax for FFL

Remember to change domain distinguished name from dc=testenv,dc=local to yours

Now, it’s time to see complete script which displays more friendly output for user

Import-Module ActiveDirectory
Clear-Host
Write-Host ""
Write-Host "Domain Functional Level is " -ForegroundColor Green -NoNewLine
$domain=Get-ADObject -Identity "dc=testenv,dc=local" -Properties * | Select msDS-Behavior-Version,ntMixedDomain
if ($domain.ntMixedDomain -eq 1){
Write-Host "Windows 2000 Mixed mode" -ForegroundColor Yellow
}
else {
switch ($domain."msDS-Behavior-Version")
{
0 { Write-Host "Windows 2000 Native mode" -ForegroundColor Yellow }
1 { Write-Host "Windows Server 2003 Interim mode" -ForegroundColor Yellow }
2 { Write-Host "Windows Server 2003 mode" -ForegroundColor Yellow }
3 { Write-Host "Windows Server 2008 mode" -ForegroundColor Yellow }
4 { Write-Host "Windows Server 2008 R2 mode" -ForegroundColor Yellow }
5 { Write-Host "Windows Server 2012 mode" -ForegroundColor Yellow }
6 { Write-Host "Windows Server 2012 R2 mode" -ForegroundColor Yellow }
default { Write-Host "unknown" -ForegroundColor Red }
}
}
Write-Host ""
Write-Host "Forest Functional Level is " -ForegroundColor Green -NoNewLine
$forest=Get-ADObject -Identity "cn=partitions,cn=configuration,dc=testenv,dc=local" -Properties * | Select msDS-Behavior-Version
switch ($forest."msDS-Behavior-Version")
{
0 { Write-Host "Windows 2000 mode" -ForegroundColor Yellow }
1 { Write-Host "Windows Server 2003 Interim mode" -ForegroundColor Yellow }
2 { Write-Host "Windows Server 2003 mode" -ForegroundColor Yellow }
3 { Write-Host "Windows Server 2008 mode" -ForegroundColor Yellow }
4 { Write-Host "Windows Server 2008 R2 mode" -ForegroundColor Yellow }
5 { Write-Host "Windows Server 2012 mode" -ForegroundColor Yellow }
6 { Write-Host "Windows Server 2012 R2 mode" -ForegroundColor Yellow }
default { Write-Host "unknown" -ForegroundColor Red }
}
Write-Host ""

Copy above code and put it into notepad, save it as ps1 file and execute in Windows PowerShell environment

Script output

Quest PowerShell module for Active Directory

To be able to run below code, you need to have installed free Quest PowerShell module for Active Directory

If you have this available then you can run below syntax

Get-QADObject -Identity "dc=testenv,dc=local" -IncludeAllProperties | Select msDS-Behavior-Version,ntMixedDomain

Quest PowerShell syntax for DFL

Get-QADObject -Identity "cn=partitions,cn=configuration,dc=testenv,dc=local" -IncludeAllProperties | Select msDS-Behavior-Version

Quest PowerShell syntax for FFL

Remember to change domain distinguished name from dc=testenv,dc=local to yours

Now, it’s time to see complete script which displays more friendly output for user

Clear-Host
Write-Host ""
Write-Host "Domain Functional Level is " -ForegroundColor Green -NoNewLine
$domain=Get-QADObject -Identity "dc=testenv,dc=local" -IncludeAllProperties | Select msDS-Behavior-Version,ntMixedDomain
if ($domain.ntMixedDomain -eq 1){
Write-Host "Windows 2000 Mixed mode" -ForegroundColor Yellow
}
else {
switch ($domain."msDS-Behavior-Version")
{
0 { Write-Host "Windows 2000 Native mode" -ForegroundColor Yellow }
1 { Write-Host "Windows Server 2003 Interim mode" -ForegroundColor Yellow }
2 { Write-Host "Windows Server 2003 mode" -ForegroundColor Yellow }
3 { Write-Host "Windows Server 2008 mode" -ForegroundColor Yellow }
4 { Write-Host "Windows Server 2008 R2 mode" -ForegroundColor Yellow }
5 { Write-Host "Windows Server 2012 mode" -ForegroundColor Yellow }
6 { Write-Host "Windows Server 2012 R2 mode" -ForegroundColor Yellow }
default { Write-Host "unknown" -ForegroundColor Red }
}
}
Write-Host ""
Write-Host "Forest Functional Level is " -ForegroundColor Green -NoNewLine
$forest=Get-QADObject -Identity "cn=partitions,cn=configuration,dc=testenv,dc=local" -IncludeAllProperties | Select msDS-Behavior-Version
switch ($forest."msDS-Behavior-Version")
{
0 { Write-Host "Windows 2000 mode" -ForegroundColor Yellow }
1 { Write-Host "Windows Server 2003 Interim mode" -ForegroundColor Yellow }
2 { Write-Host "Windows Server 2003 mode" -ForegroundColor Yellow }
3 { Write-Host "Windows Server 2008 mode" -ForegroundColor Yellow }
4 { Write-Host "Windows Server 2008 R2 mode" -ForegroundColor Yellow }
5 { Write-Host "Windows Server 2012 mode" -ForegroundColor Yellow }
6 { Write-Host "Windows Server 2012 R2 mode" -ForegroundColor Yellow }
default { Write-Host "unknown" -ForegroundColor Red }
}
Write-Host ""

Script output

Now, we have two scripts, one to check schema version and one to check DFL and FFL. If you wish, you may combine them into one and get all necessary information in one output

Active Directory troubleshooting tools


Maybe that’s funny but I would strongly recommend using basic Windows tools first, to see if there is no issue with networking on a server itself.

  • ipcofnig
ipconfig /all

to see network settings on a server. Just simply review IP address, network mask, default gateway and DNS servers list to be sure that nothing has changed there. This is really useful in case that you are using DHCP with reservation for a server. When you see in IP address section 169.254.x.y with network mask 255.255.0.0 (APIPA address) you may be sure that there is no connection to DHCP server from your machine. In other case when settings are ok, you should check another command

  • ping

another step checks if network card is not broken and if network communication is working on a server. For the first check, you should ping loopback interface (127.0.0.1) address to see if it replies. If so, then you can be sure that NIC is not broken, in other case that means you have a network card issue

ping 127.0.0.1

When you have done the step above you need to check if server works properly on layer 3 and try to ping its real IP address or another machine in the same subnet

ping <ServerIPAddress>

after that check if there is communication with default gateway to be sure that another subnets are reachable

ping <DefaultGateway=Router>

the last check should be performed to remote host in another subnet. You will see if there is no problem with routing between current network and if communication goes out from the subnet.

ping <RemoteHostIPAddress>

at this stage that’s all you can check using ping command.

  • tracert

this tool allows you to see how network communication is transmitted to another subnet. You can see how many routers (hops) are in the path and you can evaluate if transmission goes over proper path. Tracert shows you also time delay on each hop which allows for detecting lags for connection. When specified point is not reachable, you will see at which step it is not working or where the communication has the longest delay.

tracert 
or
tracert -d <DestinationIPAddress>

as you can see there are 2 variants of this command. I would suggest to use the second option with -d switch. When your run tracert with -d then reverse DNS resolution is skipped and command is executed a little bit faster.

  • pathping

this command is a summary of ping and tracert. Its output shows you response time of each hop in the routing path.

pathping <RemoteHostIPAddress>
  • netstat

after verification if there is network communication, you should also check if all required ports are opened and your server is listening on them

netstat -an -p tcp

and you will get all ports on which server is listening.

The whole list with required ports to be opened for Active Directory communication over firewall, you can find on Microsoft Technet site.

  • portqry

this tool is similar to netstat but the main difference is that portqry checks specified port or ports range if they are opened. Netstat shows only ports which are already opened and server listens on them.To use that, you need to download it from Microsoft: Portqry Download

OK, now you have an overview about networking part. If there are no errors, you should investigate somewhere else. The next place to check if something is going wrong is Microsoft Event Viewer

  • Event Viewer

please review logs regularly to avoid any server issue. I know that is a lot of work but it would prevent your server to crash suddenly, if you detect error earlier. The most important logs are:

  1. System log
  2. Application log
  3. Security log (if you are investigating user account lockout or unauthorized access to domain machine)

This is the only one place where you can get information about lingering objects in your Active Directory environment. That’s why this is important to review event logs on regular basis.

To replace standard Event Viewer you can download Event Log Admin which is 3rd party tool but it’s free and much more convenient in logs management

  • dcdiag

this is one of the most important commands to troubleshoot Active Directory: Directory Services. Thanks to it, you can get quick overview of your domain/forest condition and start resolving issue, if any exists.

dcdiag /e /c /v /f:c:\dcdiag.log

will scan all Domain Controllers in entire forest to check for potential issues with them.

Note! In large environments where is big amount of Domain Controllers, I would suggest to skip using /e switch to avoid generating huge output file and shorten reporting time

dcdiag /fix

does some fixes with DNS in the environment (this command superseded netdiag from Windows Server 2003)

  • repadmin

another very important command for enterprise/domain administrator. This allows you for:

  1. Checking replication status
  2. Forcing replication
  3. Removing lingering objects
  4. Checking status for system state backup of Domain Controllers
  5. Identifying issue with USN rollback

Checking replication status

to display information about replication status, you should use below syntax

repadmin /showrepl /intersite /all /verbose >c:\repadmin.log

and check if there are any error statuses for replication. If you want to get summarized report about replication and its state, please use

repadmin /replsummary

that’s all about replication status possibilities.

Forcing replication

One option of repadmin is forcing replication with other DCs. If you wish to push standard Active Directory update in your domain only, try this way

repadmin /syncall /APd

to force replication to all Domain Controllers in entire forest, you need to use additionally /e switch

repadmin /syncall /APed

but to be able to run above command, you need to be a member of Enterprise Administrators group in forest root domain

Removing lingering objects

This happens not very often in environment but if it appears, you need to clean up AD database. Repadmin is really helpful for this activity. Below syntax is only an overview of its usage, if you’re interested how to really clean up database from lingering objects, please read Microsoft article “Use Repadmin to remove lingering objects

repadmin /removelingeringobjects DomainControllerName DomainControllerGUID DirectoryPartition

if you wish to only enumerate lingering objects on particular directory partition, use at the end /advisory_mode switch. It does not remove these objects, just only reports them.

repadmin /removelingeringobjects DomainControllerName DomainControllerGUID DirectoryPartition /advisory_mode

Checking status for system state backup of Domain Controllers

As you know, really important part of regular Domain Controller management is to have up-to-date System State backup. Mostly this is done by 3rd party backup tool or using Windows default command used as scheduled task. How often do you verify if this kind of backup has been finished successfully? :)

Believe me, you should do that to be sure that you have available the most actual System State backup for at least one Domain Controller. In case of DC failure, you would be able to restore it. However, you should take care about backing up:

  1. Domain Controller with forest-wide FSMO roles
  2. Domain Controller with domain-wide FSMO roles in each domain

In case of any domain failure you are able to restore the most important DC in a short time.

To verify if System State backup is performed properly by your Domain Controllers run below query

repadmin /showbackup *

and this will give you an output with last successful System State backup. One more important command to execute is vssadmin which allows to see if all necessary writers are running properly. When their status is stable you can be sure that System State backup would be performed without any issue. Vssadmin command needs to be run on each Domain Controller separately.

vssadmin list writers

and check status of these writers:

  1. System writer
  2. NTDS
  3. FRS writer
  4. Registry writer
  5. COM+ REGDB writer

if all of them have stable in status it’s good

Identifying issue with USN rollback

Normally, you should not worry about that but virtualization is used almost in every company now. Administrators try to use virtual machines snapshots to revert them to the previous state if they found any error. This may be a good option for domain member servers, however it is not the proper way to restore Domain Controllers. You cannot use virtual Domain Controller snapshot to revert it back as a DC restoration. This is not supported by Microsoft and may lead to USN Rollback

Information! Please do not use Domain Controller snapshots to restore it. Always use the latest available System State backup to avoid any issues

To start identifying USN rollback issue run below syntax

repadmin /showutdvec "dc=domain,dc=local"

where “dc=domain,dc=local” is distinguished name of your domain

That was only short introduction to repadmin command. If you’re more interested in its full possibilities, I would recommend reading Microsoft whitepaper.

  • ADRepl Status

that separately downloaded tool from Microsoft is really helpful when you want to see Active Directory replication status. It is available at this location.

  • dnslint

Another helpful command for domain administrator. Thanks to this command, you can see if all required DNS records exist for specified Domain Controller

dnslint /ad /s "DomainController-IP-Address"

if some records are missing, you can try to re-add them using below steps. On that DC in command-line run

ipconfig /flushdns
dcdiag /fix
nltest /dsregdns
ipconfig /registerdns

and check once again if they appeared.

  • nltest

This command has many useful switches. It allows to see:

  1. All Domain Controller for specified domain
  2. Check and verify secure channel for domain
  3. Reset secure channel for domain
  4. Site to which DC belongs to
  5. Sites covered by particular Domain Controller
  6. Query domain/forest trust information

and many others. If you want to see all of its possibilities run command with /? switch in command-line to get full help.

To get all Domain Controllers and compare it to your list (mostly administrators are sure that this machine is no longer DC but it shows up in query results)

nltest /dclist:DNSDomainName

To query and verify secure channel use

nltest /server:DomainController /sc_query:DNSDomainName
nltest /server:DomainController /sc_verify:DNSDomainName

if you want to troubleshoot issue related with Sites, you may list all of them firts

nltest /dsgetsite

and to see which Sites are covered by particular Domain Controller

nltest /dsgetsitecov

If you organization has established forest trust with another company, you can simply check information about that

nltest /dsgetfti:DNSDomainName

and the same can be done to get domain trust information

nltest /domain_trusts
  • NTDSUtil

command which is forgotten by admins but it is really helpful. You can use it for:

  1. Active Directory authoritative restoration of any object
  2. Change DSRM password (how many of you changes this password due to company password policy? ;)  )
  3. Transfer/Seize FSMO roles
  4. Do metadata cleanup
  5. Create Install from Media (IFM)
  6. Create application partitions
  7. Compress AD database
  8. Duplicate SID cleanup

and much more I did not mention here.

  • LDP

You can use this command to modify schema and AD objects attributes. In Windows Server 2008R2 you can also use this tool for deleted object restoration. Similar tool for almost the same tasks (except object restoration) is ADSIEdit which allows operating in GUI.

  • dsacls, dsrevoke and LIZA

these 2 commands and one GUI tool are really needed when you troubleshoot Active Directory Delegated rights. You can verify any Organizational Unit to see if user/group of user are allowed to do required tasks on that OU. For these commands you need to know distinguished name on an OU. To get that in short way, you need run dsquery command

dsquery ou -name "OUName"

and copy its output to dsacls command

dsacls "OUDistinguishedName" >c:\dsacls.log

dsrevoke works a little bit different and needs to be downloaded first. It reports/removes specified user or group permissions from all objects where user/group is premitted

dsrevoke /report "DomainName\userNameorGroup" >c:\dsrevoke.log
dsrevoke /remove "DomainName\userNameorGroup"

Note! Be aware of using /remove switch as this will remove user or group from object ACL

and finally LIZA. This is really good and free tool to see delegated permissions and it works as GUI tool. To be able to run it, you need to have .NET 2.0 installed on machine. Download LIZA

  • Account Lockout and Management Tools

this is really helpful when you troubleshoot user/computer account lockout issue. Just download it from Microsoft: AL Tools

and use

  1. LockoutStatus.exe to see on which Domain Controller an account is locked out
  2. eventCombMT.exe to review security log on all Domain Controllers or only on specified

I think, that’s all regarding direct tools for AD database troubleshooting. I probably did not mentioned all of available tools as I could not remember them. If you found that something important is missing here, please let me know, I will update this article.

SYSVOL replication tools (GPO, logon scripts)

Another part which needs to be checked separately is SYSVOL replication as it is not checked in details by mentioned tools above. First tool which allows you to see SYSVOL FRS replication is

  • FRS Diag

this is old tool and Microsoft does not recommend using it anymore, however it may be still helpful in the old environments. This is not a part of operating system and needs to be downloaded separately from Micrsoft: FRSDiag download

  • Ultrasound

newer and more appropriate tool for FRS diagnosis is Utrasound which is also free and needs to be downloaded from Microsoft: Ultrasound download

  • GPO Tool

this may be helpful to you when you are troubleshooting Group Policies. It is a part of Microsoft Windows 2003 Resource Kit but still can be used on Windows Server 2008/2008R2. To be able to use GPO Tool, you need to download it from Microsoft.

  • GPO Log View

this tool allows you in much more convenient way to review GPO logs. It is free and can be downloaded from Microsoft: GPO Log View

I think that’s all. If I forgot something, please let me know and I will update this article as it might be helpful to us during Active Directory troubleshooting process. Thank you in advance

%d bloggers like this: