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 dump 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.
Source: FTB Threads