Archive | July 2012

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!

Author: Krzysztof Pytko

lastLogon vs lastLogonTimestamp


As I can see frequently in questions on forums, people ask about possibility to check the last date when user logged on into a domain. They very often try to get that information basing on lastLogon attribute. When other person tells that this should be checked using lastLogonTimestamp instead of lastLogon attribute, they are surprised and ask why this atribute is not the proper one.

I will try to explain in this short article difference between these 2 LDAP attributes.

If you want to determine when user was logged on within domain for the last time, you need to run appropriate query to get that information. You can use one of two attributes to see the time of last successful logon:

  • lastLogon
  • lastLogonTimeStamp

the most simple difference between them is that lastLogon attribute stores information about last successful user logon only on that particular Domain Controller and it is NOT replicated to other Domain Controllers.

To get more information about other Active Directory attributes which are not replicated to Domain Controllers, you may read really good article on Mike’s blog where you can also see examples how to check them. Article is titled Find Non Replicated Attributes in Active Directory

So, if you want to simply know when user was authenticated for the last time by this particular DC, you can use this attribute.

In other case when you are interested in the date of the last successful logon in a domain for a user, you need to use lastLogonTimestamp attribute. The small inconvenience of using the attribute is that this is accurate between 9-14 days. However, it is far enough to determine when user was logged on to the domain the last time.

Now, you can see how to search that information in a domain. I have prepared test domain environment with 3 Domain Controllers on which I have logged on using iSiek user (except DC03). I will show you what kind of tools you can use to simplify that process.

As there are many tools available, I’ve decided to use:

  • Microsoft DS Tools
  • Quest PowerShell module for Active Directory
  • Windows PowerShell module for Active Directory (required Windows Server 2008R2 Domain Controller)

Microsoft DS Tools

This method is the least convenient but it is available on any Domain Controller without requirement of any additional software to install. When you query AD for that attribute using DSQUERY command in LDAP query mode, its output is returned in int64 format which is unreadable to human and it is really difficult to determine a date when user logged on to domain. However, you can get that attribute and convert to human readable mode using i.e. w32tm command with /ntte switch.

Let’s try to get that information with DSQUERY and w32tm commands.

Note! Remember that this test environment has only 3 Domain Controllers and it is much more easy to run these commands on each of them separately to show you how this looks like. In real word, you may encounter many Domain Controllers per domain and it would be very difficult to run the query on each DC to get information about lastLogon attribute. If you want to get the date and time for particular Domain Controller then this attribute is accurate for you in other case you should use lastLogonTimestamp to determine the date of the last successful logon in a domain.

On each of my Domain Controllers in test lab I will run in command-line

dsquery * -filter “(&(objectClass=User)(objectCategory=Person)(sAMAccountName=iSiek))” -attr sAMAccountName lastLogon lastLogonTimestamp

results can be seen below.

Output from DC01

as you can see, lastLogon and lastLogonTimestamp are returned in int64 format and we cannot tell the exact date and time. Now, I will convert them into human readable format using w32tm command

for lastLogon
w32tm /ntte 129875005360000000

lastLogon attribute converted from int64 to human readable format

for lastLogonTimestamp
w32tm /ntte 129870095844687500

lastLogonTimestamp attribute converted from int64 to human readable format

On DC02 you can see the same lastLogonTimestamp attribute’s value as this was replicated between Domain Controllers but lastLogon attribute has different value as my user was authenticated by DC02 another day.

Output from DC02

to see that difference I will convert lastLogon int64 value

lastLogon attribute converted from int64 to human readable format

now, as you can see there is different date than on DC01

Difference between DC01 and DC02 lastLogon attribute

however, lastLogonTimestamp is the same on DC02

lastLogonTimestamp converted from int64 to human readable format

Now, on DC03 you can see that there is no value for lastLogon attribute as Domain Controller never authenticated the user

Output from DC03

and the last screen from DC03 for lastLogonTimestamp attribute. It is the same as on the other Domain Controllers

lastLogonTimestamp converted from int64 to human readable format

Quest PowerShell module for Active Directory

This is a 3rd party tool which needs to be downloaded from Quest web site and installed on any machine. When you do that, please see output of this query within a Quest console

Get-QADUser iSiek | Select SamAccountName,lastLogon,lastLogonTimestamp

Output from Quest Tool on DC01

as you can see, this tool is much more convenient in use than MS DS Tools. It automatically converts int64 value and displays only human readable date and time format. The same syntax was run on DC02 and DC03, so you can see results below

Output from Quest tool on DC02

Output from Quest tool on DC03

Windows PowerShell module for Active Directory

This tool is available when you have Windows Server 2008R2 Domain Controller. You can use it then from DC or from Remote Server Administrative Tools (RSAT) on Windows 7 client machine. This command differs a little bit from Quest syntax but it does the same.

Below you can find appropriate syntax for Microsoft PowerShell

Get-ADUser iSiek -Properties * | Select SamAccountName,lastLogon,lastLogonTimestamp,lastLogonDate

Output from Windows PowerShell on DC01

you can see different output as lastLogon and lastLogonTimestamp attributes were not converted automatically from int64 value. To get date and time in human readable mode, you need to use another attribute in syntax. This is lastLogonDate

as in previous examples, you can see another Domain Controllers and their output in Microsoft PowerShell module for Active Directory

Output from Windows PowerShell on DC02

Output from Windows PowerShell on DC03

Author: Krzysztof Pytko