Jump to content
Sign in to follow this  

Active Directory re-design in production

Recommended Posts

The topic hook here, is redesigning the Active Directory Object Units of an existing network. Really, OUs are like Subfolders of a Windows User and Computer tree / list. I am working with a live domain structure, so more important before making any changes, is knowing and documenting how it was / currently is. This being in case you move something and it breaks.
Especially 3rd party applications linked into Active Directory, and the OU path is like a network or folder path, if the lookup is where it assigns user permissions via the AD / LDAP (Lightweight Directory Access Protocol) / Windows Challenge/Response (NTLM) mechanisms. Point here being, if you assign permissions to a user as below, moving them to a new OU and not updating that lookup in an app can break it, unless it verifies the current path of that user account in its NTLM-esc lookup.


Point being, if I move the Object_UserAccount into a different OU or a deeper subfolder / OU on that domain, that lookup may very well be broken for the 3rd party app, using AD for it's lookup.

That is kind of long in the teeth, but in Windows land, especially when changing domain structure around, you can get some nasty snags. Documenting is as it was, lets you see if the old path is defined in whatever 3rd party app or device you are working with. Also applicable, are Group Policies and where they apply. Group Policy Editor on a domain controller will let you see what ones are applied and what OU they are nested under. Group Policies are a step of this, but I am not focusing on these for this thread. Knowing the old policies they apply to, will be helpful on your rollout, as in my case, some departments have printers autoinstall, based on their location. I note this to troubleshoot or recreate that behavior on the new side of domain OUs.

csvde.exe: This C(ommand L(ine) I(nterface) tool will let you connect to your domain.local, while picking a root OU, to then export all those details to a CSV file. Along with some screenshots of the tree structure, this is a great method to know what OU path a user was in, before you redesigned the trees and moved users around. This in especially the case, of someone's windows or other app, stopping to work, upon you moving their account or machine around in the domain tree.

Excel or Libre based office spreadsheet program: I use these especially in migrating a live domain to a new server. You have to clean the AD export up to 8 relevant columns, as the rest of the data is made by the new domain controller, thus importing the old stuff will just fail. Rambling point here, is that when you import a new domain controller to an existing domain, it will inherit the security level of the prior domain. Server 2012 running on a Windows 2003 Domain Forrest level? No thank you, please don't even.
You can and likely will use the spreadsheet program for reference in the future, either to make sure you moved the user from old to new, correct path, or to debug why an app may have stopped working, and trend a fix for anyone else who may have the same issue.

Great. We have a d
ump of users with their original path (in my case, over 100 sub-OUs for maybe 20 different business units.). Sometimes, people over-design systems. It can be intentionally confusing to dissuade others from making changes, or simply be over-designed for some fantasy scope projection of future growth, instead of something that works with their current, yet is still scaleable for later add-ons. In my opinion, empty folders are a BAD design call, especially in OUs. Sometimes the path is limited to a certain amount of characters, so 50 of them characters being empty sub-folder paths, is just a shitty design call.

Share this post

Link to post

By the way, I throw some swearing into the conversation. Living the Sys Admin life, I find swearing to help describe a scenario, add criticality to issues, but try to avoid swearing at people. Inanimate things or bad design choices? That's a 'cussin.

As I covered concepts and personal opinions and observations, this post will cover some examples of using CSVDE, and demonstrate the clunky OU folder paths, to a more managed, what I consider to be sensible, replacement OU path. As covered above, when changing core settings such as the domain structure, make SURE you know how it was before you made a change. Ideally, you can fix an issue as fast or faster than you may have broke it. Even more ideally, you would not be doing this in production, but on a test domain. Seriously though, stuff like this tends to run rampantly broken for so long, that trying to do it in a test environment is impractical, because most places don't really believe in or respect what a testing environment even is.
Wrapping that up, if you are experimenting, setup a test domain at home or off your work network and try this stuff out 1st. VMs are awesome for this if you don't have extra dedicated test equipment around. Just be sure it does not bleed into your production network.

Now that I have added plenty of cautionary details, Csvde usage is as such:

csvde -d "ou=Targeted_Root_OUName,dc=YourDomainName,dc=suffixDotName" -f C:\LogPath\FileNameOfThis_Query.csv

Breakdown of this Command:


  • ou = This is the folder in your domain tree you want to export. Defaults are like, Builtin; Computers; Domain Controllers; System; Users. Also you may see a site-specific one or multiple in this root list / main directory tree.
  • dc = These 2 dc items are for the FQDN (Fully Qualified Domain Name) of your personal or office domain. If you domain is called work.local, then your string is dc=work,dc=local.
  • As for wrapping the ou=..dc=.. in double-quotes, this is solid practice when dealing with spaces. As you tinker with various tools, single quote or double quote will also be helpful in defining what criteria options are applicable to a tool, especially if you get some piping or output commands added to the syntax string.

Rad, so now we have a working test command:





csvde -d "ou=Users,dc=work,dc=local" -f c:\exports\ADUsers_PreChanges.csv

If I had spaces in the file path after -f for the file export, I would also wrap that in double quotes. You could always do that too, and it should not cause any faults in processing the command. In this case though, the export would fail, if I did not already have a c:\exports folder created. So that is a factor in writing your output files.

At this point, you have a spreadsheet with the original path of everything under the Users tree / OU in your domain, so you can move those to a new container, and if anyone has unforseen issues, then see how it used to be, then search the tools they are having a problem with, to see if it is pathed to the old Object location of: work.local\Users\UserName in it's active directory lookup. This depends on your platform or application, but starting with the as-it-was document, gives you leverage to roll it back quickly, and I feel it also saves you from jumping into black holes for issues, where no real error may be given.

Measure twice, cut once. Or something like that. Hopefully this was a help and happy reprovisioning. :yar:

Share this post

Link to post
Sign in to follow this