Announcing new options for SQL Server 2008 and Windows Server 2008 End of Support

2019-02-28T12:26:21-04:00February 28th, 2019|Azure, Desktop Management, Desktop OS, Domain Integration, End of Service, Exchange, Microsoft, Microsoft Infrastructure, Micrsoft Cloud Solution Provider, Office 365|

We get it. Change is scary. If you’ve been running the same operating system for many years, a large-scale overhaul is understandably intimidating. But it’s time. To continue their focus on progress and innovation, Microsoft is ending support for some popular 2008 products, including SQL Server 2008 and 2008 R2 and Windows Server 2008 and 2008 R2. If you are still running either of these, don’t panic! Microsoft has put options in place to give you the time you need, and we at Coretek Services, are here to assist you with a smooth transition. Check out this article and contact us for more information.

Initial Domain Integration Discovery…

2017-11-16T03:12:56-04:00November 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!