Initial Domain Integration Discovery…

2017-11-16T03:12:56+00:00 November 16th, 2017|blog, Domain Integration, PowerShell, Scripting|

If you are intending to be involved in an Active Directory Domain integration with Quest Migration Manager for AD, there are some simple AD attribute discovery checks you should do long before you get serious about such things as user counts and remediation and so forth.  And especially if you’re going to perform an Enterprise multi-Domain integration (many-to-one), its even more critical that you map out your attributes that you will be using for merging & matching the user objects across each domain relationship.

Attribute Analysis

Here at Coretek, we do a lot of Organizational and Enterprise Active Directory integrations, and many of them involve Quest Migration Manager for AD (MMAD).  Just today I was working with a customer to gather some of this early info, so I thought I’d post a note on some of these simple tests so you, too, can run them and see if your AD is in good shape to take on such a project.

The Quest Migration Manager for AD requires that you use a pair of Unicode String attributes for each domain relationship.  The default attributes used in a simple non-Exchange migration are “adminDescription” and “adminDisplayName”.  However, the more common scenarios I see involve Exchange and also multiple domains, requiring the use of other attributes such as “extensionAttribute14” & 15 and others.

The most common scenario I get involved with is where the users have already been created in the destination domain (due to an HR automation or other project), and the user objects from the source domain(s) will be merged, rather than created fresh.  In these cases I typically try to get the customer to check for these following critical things at a pre-project state — or as early as can be done — for the set of user objects that are to be part of the migration/integration:

  • Existing sidHistory — In most cases, existing sidHistory attributes on a user object are just a part of an old migration and may not matter.  However, if something like a previous Exchange migration was left un-complete, the sidHistory might be a critical part of the mailbox access for those users… and removing it without planning would be bad!  Tread carefully!
  • Existing extensionAttribute14, 15, etc. — These are the attributes that are commonly used in Enterprise AD migrations, and you’ll often find them still left-over from previous projects.  Those old project-based values don’t matter on their own; however I’ve also seen these attributes quite commonly used for other semi-hidden administrative items.  Why?  Because in Exchange environments, there’s a nifty GUI capability for editing these attributes, putting them at the fingertips of people that would otherwise leave them alone.  Again, make sure they are free and won’t be overwritten by anyone!

PowerShell Queries

So let’s check for these attributes, and below are some simple ways to see if anything is populated for those critical attributes.

To return a simple list of all user distinguishedNames with “sidHistory” populated with something (command is all-one-line):

(Get-ADUser -Filter {sidHistory -like "*"} -SearchBase "ou=MyOweYou,dc=doemane,dc=lowcull").distinguishedName

…then of course, you can swap out extensionAttribute14 for others… and replace the “.distinguishedName” with others, and we could format the output differently, dump to a CSV, etc.  Here is a similar search, but now we’re formatting the output to a table for easier quick reading (command is all-one-line):

Get-ADUser -Filter {extensionAttribute14 -like "*"} -SearchBase "ou=MyOweYou,dc=doemane,dc=lowcull" -Properties sidHistory,extensionAttribute14 |ft -Property name,sidhistory,extensionattribute14

…or, to pull it all together into one command and search for all three of the attributes I mentioned, do this (command is all-one-line):

Get-ADUser -Filter {(extensionAttribute14 -like "*") -or (extensionAttribute15 -like "*") -or (sidHistory -like "*")} -SearchBase "dc=doemane,dc=lowcull" -Properties sidHistory,extensionAttribute14,extensionAttribute15 |ft -Property name,sidhistory,extensionattribute14,extensionattribute15

Of course, you’ll want to change out the specifics in the commands above to match your domain info and attribute discovery needs, but you get the idea.

I hope that helps get you closer to your domain integration…  And I hope you let us help you out!

 

DFS Replication Validation Script…

2017-07-27T00:01:04+00:00 December 12th, 2012|Uncategorized|

The other day, while at the enterprise-level customer with whom I’m currently working, I ran into a situation where I needed to validate that certain parts of a DFS hierarchy were properly being replicated across the customer’s AD domain controllers.  As the administrators applied normal, routine DFS changes, the changes sometimes didn’t replicate properly across the enterprise — causing some segments of the DFS structure to not be visible or available. 

Apparently, the DFS problem was a result of using VMware guests as AD DCs.  I understand (from the customer) that a Microsoft hotfix is in the last stages of testing (at the time of this writing) and will be available for release “soon.”   It seemed that even though the DCs in question did not synchronize time with the ESX host upon which they reside, there is a default behavior in VMware Tools that assigns the host time value to the guest — at least up until the “do not sync” routine is processed during startup; after which the guest is then allowed to find its own time.  During this brief time window, the DFS Namespace service sometimes completes assembling its DFS target list and can find itself behind in time, relative to links it has been given by PDCE; which makes no sense to it, and it removes them from its listing.  And as a result, people can’t find their mapped drives or browse some of the DFS Tree.  (Note: I cannot take credit for this timing behavior investigation and results; and while I’d love to credit the folks who are due, I’m not permitted to.)  The customer remedied the situation with a temporary fix, but the real fix is the up-coming aforementioned patch.

Anyway, while the symptoms were being analyzed, I was working on other things and needed to work around the issue as much as possible while the solution was being chased.  So, I whipped up a simple little DOS script to go out and validate the top-levels of the DFS hierarchy across all domain controllers that carry them, in order to find out what would or wouldn’t be properly resolved.

For what it’s worth, I thought I’d pass the script along to you.  Here it is:

 

@SETLOCAL ENABLEDELAYEDEXPANSION
@set AdDomain=MyAdDomain.local
@set DirQuantity=17
@set DestPath=h:DcList.txt
@REM This requires elevated credentials, otherwise will fail...
@ipconfig /flushdns
@REM First we build the input file...
@nslookup %AdDomain% |findstr 
[0-9].*.[0-9].*|findstr /V /C:"Address: " > %DestPath% @ECHO As of 20121212, there should be %DirQuantity% DFS dirs on each server (actual, plus the "." and ".." items). @REM Now loop through the input file and check the DFS at the destination... @For /F "tokens=*" %%Q in (%DestPath%) Do @( @set MYDC=%%Q @set MYDC=!MYDC:Addresses: =! for /f "tokens=* delims=" %%A in ('dir /A:D \!MYDC!Corp ^|findstr /C:"Dir(s)"') do @set MYDIR=%%A for /f "tokens=* delims= " %%G in ("!MYDIR!") do @set MYDIR=%%G @REM Options A: Use this line if you wish to see all DFS sources: @ECHO For: !MYDC! !MYDIR:~0,9! @REM Option B: Use this line if you wish to see only those in violation @REM (note: there's a space and tab separator for spacing alignment): @REM @ECHO For: !MYDC! !MYDIR:~0,9! |findstr /V /C:"%DirQuantity% Dir(s)" )

What it does:

The script builds a domain controller list in a static, external file, then iterates through the list, attempting to quantify the available DFS path branches against a numeric count that you supply in another variable.  I provided two different “ends” to the script (one of them commented out), in order to give you a couple different ways to present the results.  Make sure to “set” the variables in the first few lines, to your locally-relevant information; especially the number of *expected* DFS hierarchies.

Of course, I wanted to write it to do more, but I pretty much ran up against the limits of what I *should* do in a DOS script.  I’ll make another version in PowerShell some day that iterates down the hierarchy and validates the entire structure, instead of just the top level… 

…Unless you beat me to it…  😉

There you go; enjoy!

🙂