Split User and Workstation migrations, please!

Active Directory Migrations require managing entropy and chaos until you are done, at which point, hopefully, you have essentially the same services you started with.  It is work that, at best, you can get through without anyone noticing.  Part of managing that entropy and chaos involves breaking things into smaller and more manageable parts.  To this end one of my favorite things to isolate in during the migration process is the workstation vs. user migration.  You do not have to move the user and workstation at the same time, nor should you!

The common and natural entropy affect during migrations is the pairing of user and workstation migrations.  This correlation is sometimes caused by Active Directory (AD) administrators, desktop support engineers, and even by developers of tools (hey, I’m looking at you Dell Software Group who updated their Cached Credentials migration utility to force the user/workstation to move together – but it is an awesome tool!).  We are all trained by Microsoft to think of “one user, one workstation”, and so that is how we approach the migration.  But we need to stop the madness!

Why split the workstation migration from the user migration?  From a risk management perspective they are two very different kinds of risks, and combining risk is a good way to get you “noticed” in a migration, and being noticed in migrations is rarely something you want to have happen.  From a process perspective they are unique processes, and don’t mix well together.  From a data management perspective the combination creates all kinds of opportunities for cumbersome reporting that is likely to be at best 80% accurate.  However, if you do have a company where one person has one workstation and your user to workstation management is truly 100% accurate at just a click away – feel free to stop reading (grin).

Workstation migrations, the act of joining the workstation from domain A to domain B, are a very low risk proposition, but is one of the more physically disruptive activities to be performed.  Moving a workstation is not likely to break an application, make someone unable to perform their job, or in general be anything other than an annoyance to the end user.  This makes this a low risk proposition.  The annoyance is that you have to reboot, of course.  That reboot is what is physically disruptive.  The end user has to watch their machine shutdown, restart, and they have to login again, something they prefer to do no more than once a day.

By contrast a User migration is high risk, but not really that disruptive.  All the user has to do is login to the “right” domain, which they can do as part of their daily routine, so no big deal.  However, the risk part is that things may not work right.  Did the desktop profile get setup?  Were permissions in SharePoint updated?  Did the application owner remember to change the authentication point?  Is their token bloated now and as a result SID History isn’t giving access to that file share that we forgot to dual ACL?  Lots can go wrong.

High risk item (user migrations) require good planning and coordination.  Low risk items take much less planning and coordination.  The result is that high risk items tend to move at a slower pace than low risk items.  This means you can complete your workstation migration much faster than you can complete your user migration, if the two are separated.

So please, keep these two items separate in your migration!  Combining them just means more work, more combined risk, and a longer period of time to complete your migration process.

Now I know the questions, as I hear them often.  So let me address them as best as I can.

 

Q:  But Michael, if I split them apart how do I get the last logged in domain updated so that the user can login to the right domain when they are migrated.

A:  Yes, many tools, like Migration Manager, put the “change last logged in domain” as part of the workstation move task, so it is convenient to do it there, but it doesn’t have it be done there.  First, it is a pretty simple function to script.  Second, it is a pretty simple change to communicate.  Third, doing that for your users seems nice, until you commit to it, but only later realize that your reporting is off by as much as 60% and you are now changing the last logged in domain on workstations that host users that are not even migrated yet.  So yes, you are creating as much of a problem as you are solving.

 

Q:  But Michael, my users can only have “one touch” during the migration, and splitting these apart would be two touches (meaning two points they are affected by the migration).

A:  (As I roll my eyes) So you are saying that once you deploy a workstation for an end user you never do anything to that workstation ever again for the life of its use?  If that is the case then the hackers of the world will love you.  But for all of us using Microsoft Windows, that isn’t a reality.  This whole “single touch” thing is somebodies crazy political idea, and has nothing to do with getting a project done.  But if you are insistent, then let me propose this idea for you:  What is the reason you are migrating in the first place?  Security?  Simplification of support?  Merger of business?  Whatever ever it is, call the workstation migration “that” and don’t call it part of the Active Directory migration.  Done.  Now your AD migration has only one touch, and the workstation migration was part of the DNS changes, or the Network consolidation, or whatever you want to call it.  It is just a name.

Tags:

Leave a Reply