What are you doing with ADMT?

So some astute reader asked what I was doing with ADMT, wondering whether there were some domain migrations happening.

No, no domain migrations happening just yet, but there’s a lot of background material here which is likely useful to hear about.

So each time an existing campus Exchange deployment has chosen to merge with the UW Exchange service, we’ve helped migrate those existing Exchange mailboxes into the UW Exchange service. The general process required to migrate involves having a sidHistory stamped on the destination user. So you might notice that some UWWI user accounts have sidHistory on them. And that’s because we’ve used ADMT as part of these Exchange migrations to allow the mailbox migration to happen.

However, these one-time migrations have not been smooth, nor have they been especially well designed. In one case, a department incorrectly asserted the wrong source user be mapped to a UWWI user, and we had to subsequently remove the sidHistory. Mapping the source users to the destination users has been a very time-consuming process.

And the ADMT implementation was to a box that has many other functions, and used a local sql express instance. When you use a local sql express instance with ADMT, it means that you can have only a single ADMT console doing migrations of any type.

So the work behind the prior blog post was to clean up this state of affairs while retaining the migration information associated with the migrations we’ve done in association with Exchange.

That work also serves another purpose which is to get us a bit closer to being ready to allow for migrations into UWWI. We some vision in terms of how migrations might work, and this is probably as good a time as any to share that vision. 🙂

So we envision this sort of workflow:

  1. You go to a webpage which explains the process, and which tells you what information you need to gather to start.This will involve a tool or directions on how to use ldifde to generate a list of your users and separately your groups.

    You’d then need to manually remove any users/groups you don’t want to migrate.

    And you’d want to pre-screen this list to make sure that the usernames are valid uw netids. And if not, you’d drop or rename those users.

    This webpage would also tell you that you need a trust to UWWI, to set a couple configuration settings on your domain/domain controllers to allow sidHistory migration. And there’d be some other details noted that would need to be ironed out, things like making sure specific users are authorized to go to the webapp and to the ADMT database.

  2. You’d then go to a web application/service of some sort where you’d submit the edited output of the tool/ldifde.
  3. The web app/service would check your submitted list for problems, like no uw netid, and give you back a webpage where you’d see details about the source/destination accounts so you could vet the user migration action. This would allow you to say no cop\barkills, displayName=Bart Kills is not the same person as netid\barkills, displayName=Brian Arkills, so drop cop\barkills until we can figure out what’s going on with that user.
  4. The web app/service would then carry out the migrations. Behind the scenes ClonePrincipal would be used to add the sidHistory, and we’d insert the right stuff into the ADMT database to make it look like ADMT had done the migration. We wouldn’t use ADMT itself because … well … ADMT has this bug. If a given destination user already has a sidHistory, then ADMT overwrites it. And that’s not good.
  5. Now, this is the step where things are really cool. You’d then download a copy of ADMT 3.1 and install it wherever you like. During installation, you’d point it at our ADMT database. Then you’d use the various ADMT wizards to migrate your own resources, in whatever timeframe meets your needs. No need to coordinate with UW Technology (and the best thing of all from my perspective is that I don’t have to be involved).You’d use the computer migration wizard to send out agents to your computers (on your schedule) that would automatically reACL them using all the migrated users/groups, would join them to the NETID domain, and reboot them.

There are a ton of details not fleshed out here, but as I said this is a vision. And the prior blog post was about getting things moving toward this vision.

Leave a Reply

Your email address will not be published. Required fields are marked *

Required
Required