Musings of Jason Jones

Tag Archives: Microsoft

In our scenario we had to keep creating new hires in the legacy domain so that we could get sidHistory, until we can say that we’re done and all things have been migrated.

I did it all in one script, but it’s a little big. I like it cause I did some new (to me) stuff like menus and consolidation. It’s what I wanted to do with the rest of the migration scripts, but just didn’t quite work right. If you’re migrating 100 people at once, you want to verify that everything in step 1 has worked correctly before going on to step 2.

Below is the script. I’ll try to explain as we go, but most of it is just re-doing of things we’ve done before.

This script also assumes that you still have your daily sync scripts going from source to target domain and that you’re waiting at least a day between new hire creation in legacy and migration to target. If not, you’ll need to run the prepare-mailboxmove script manually to create the MEU

I’ve now given you all my scripts I used for my AD migrations. They represent a huge amount of work on my part for writing, testing, compiling and refining them. Please use them wisely and if they help you out feel free to write a comment and let me know. I like to know I’m not just writing for myself.

Also keep in mind that you are not done. Not remotely. Now you have to go back and fix everything else you didn’t touch: DNS zones, DHCP, file share permissions, file servers, applications servers, applications, GPO’s, contacts, Sharepoint, etc, etc. Try to think of everything a user does on a daily basis and figure out if and how it needs to be migrated. You probably band-aided everything to get it working in the interim, but you still need to go back and FIX it.

To that end, what about your new hires? Hopefully you enfolded them in the migration process or at the end you’ll find out you have another 20-100 people who still need to be migrated. All because you didn’t define that process in the beginning. I know, because we ran out of time to do it on ours and had to do them all over again.

What about your remote users? Are you making them come into the office, mail their equipment in and be offline for days, or what? We did some hodge-podge process of creating a new local user account on remote PC’s and handholding them thru logging in with that, VPN in, and then migrate their computer and have them do it all over again so we could get the IP and finish the process. By the end it worked great, but 1 person could really only handle a couple of these remote users at a time.

And what are you going to do until all of the above is done? Do new hires need to be onboarded into their legacy domain or can they go directly into the new domain? Likely you’ve still got applications tied to the old domain that require sidHistory, group access or whatever, so your new users will need to come into the old and then be migrated into the new before they even start. Hopefully your onboarding process has that flexibility. (I’ll cover that powershell script in another post.)

Wow, so it’s been a whole 3 months since I’ve posted. Can you tell I got deep into actually doing migrations rather than talking about it? It took a little longer than I’d hoped – mainly due to scheduling – but we managed to finish the migrations. I personally migrated a little over 2,000 people. Due to our migration windows I never did more than 150 people at a time, but I was surely itching to.

These next couple of scripts are Lync related. Not too much involved in them, mainly creating the remote session and then running a quick command. Note that we installed the Lync module on our ADMT server, but for some reason some of the commands don’t work natively so we had to do some thru remote pssessions and some thru the module

##call include file.
## this is just in case we forgot to call it before
. .\params.ps1
##Create Sessions
##The usual pssession, just pointing to the Lync server in the source domain and using our source credentials
$LyncSessionSource=New-PSSession -connectionuri $LyncURISource -credential $RemoteCredentials
## Import our include file
$import=import-csv $importfile
##Source side disable-csuser
##Import the session, and then for each item in the include file, disable them for Lync in the source domain.
##Lync uses display name so we have to make sure that's in our include file
import-pssession $LyncSessionSource
foreach ($item in $import){
write-host "Disabling Lync for " $item.olddisplayname -foregroundcolor yellow
disable-csuser -identity $item.olddisplayname
}
## Let's clean up our session
remove-pssession $LyncSessionSource

Our next script is basically the same, but opposite. Let’s enable them for Lync in the target domain

##call include file
. .\params.ps1
##Create Sessions
$LyncSession=New-PSSession -connectionuri $LyncURI -credential $LocalCredentials
##Import
$import=import-csv $importfile
##Target side enable cs-user
##Import the session, then go thru the input file
##Since we changed the displayname of users as part of the process we had to account for that in the include file
## The rest of the commands are Lync specific. When you enable you have to specify registrar pool and address type
import-pssession $LyncSession
foreach ($item in $import){
if ($item.smtp){
enable-csuser -identity $item.displayname -registrarpool $registrarpool -sipaddresstype EmailAddress
write-host "Enabling Lync for: " $item.displayname -foregroundcolor yellow
}
}
##Let's clean up after ourselves
remove-pssession $LyncSession

This one is basically the same as the previous, but we have to set options for the users that can’t be set in the enable command. We’re setting the LineURI (i.e. telephone number) and turning on Enterprise Voice.

These next couple are very specific to our environment but I’m putting them out here for posterity. Both use the Quest AD Powershell tools, which are very powerful tools when it comes to object manipulation in AD. I suggest you go download and install them immediately – Quest

This first one sets an extended attribute on the user in the source domain so that we know they’ve been migrated. It’s more for a key for reports and stuff, but can be good info to have.

The second combines a couple of things. The first thing it does is set the displayname and UPN for the migrated user to go with our new standards (oh, did I mention we’re changing the UPN but leaving the SAM alone and changing the displayname?)

It also turns on ActiveSync for the users if they need it. Made the most sense for our scripts to put it here.

Perform a move mailbox (see below). The move mailbox converts the source account into a MEU on the source domain. This is needed for mailflow.

## Get date, set our transcript file, etc.
$date=get-date -format "yyyyMMdd"
$Tranoutput="d:\migration\Outputs\" + $date + "Mailboxmove.txt"
start-transcript -path $Tranoutput -append
##call include file
## This ensures that the variables are loaded, altho if you followed the previous article they already should be
. .\params.ps1
## Create Remote Powershell session to the Exchange 2010 server
## Greate for making sure all your command can be run from one place
$ExchSession=New-PSSession -ConfigurationName Microsoft.Exchange -connectionuri $ExchURI -credential $LocalCredentials
import-pssession $ExchSession|out-null
## Import the include file
$import=import-csv $ImportFile
## Do a move request for each mailbox using all of our variables
## Targetdeliverydomain is important to ensure mailflow. It should be set to a 3rd SMTP domain that is only being used by the 2010 environment
## This then gets set on the MEU in the source side
foreach ($item in $import){
New-MoveRequest -Identity $item.smtp -domaincontroller $TargetDC -RemoteLegacy -RemoteGlobalCatalog $SourceDC -RemoteCredential $RemoteCredentials -TargetDeliveryDomain $TargetDeliveryDomain -baditemlimit 50
}
## clean up after yourself and close your remote powershell session
remove-pssession $ExchSession
stop-transcript

The move mailbox ends up being the easiest part of this whole process. You can run powershell commands to check the status of the move request or just go into the Exchange console and check it there.

I was recently working with a client who was in the process of building a new AD forest and the slow and painful process of migrating all objects and collapsing old ones. That’s a pain for a different time.

When the new forest was first built out they weren’t sure how quickly they’d be migrating to the new domain or how quickly they’d be building out servers. The first part of the process was to build out a few DC’s and then go from there. Since KMS requires a minimum of 5 servers to activate any of them it seemed prudent to point them to the old KMS server in the old forest so that the Windows servers wouldn’t expire.

This was easily done by creating a SRV record in DNS in the new domain pointing to the old server. That’s not the point of this article, but as a down and dirty all you need to do is create a SRV record in the domain of a _VLMCS type as a _tcp record, pointing to port 1688. i.e. _VLMCS._tcp._domain.com. The data in the record is just the FQDN or IP of your KMS server.

All that being said, fast forward to the day that more than 5 servers existed in the new domain and they wanted to create a new KMS in the new domain and point the existing AD servers at it.

Creating the new KMS is easy. Just go to an elevated command prompt and type:

slmgr.vbs /ipk KEY

where KEY is your purchased KMS key from Microsoft.

Then you’ll want to activate the KMS against Microsoft:

slmgr.vbs /ato

You should get a nifty popup box that says Activation is successful.

And finally you’ll want to go into DNS and delete the manually created SRV record pointing back to your old KMS host. You should also see one in there for your new KMS.

Now that you have a brand new KMS host, you need to go back and re-point your new AD serves at it. Should be as simple as doing a /ato again, right? Wrong!

Since the old KMS server is still up and accessible over the network your AD servers will automatically use it to renew their license, and will continue to do so every 180 days that they renew. You need to teach them how to forget that it exists.

Type the following commands in sequence. Wait for a popup after each one telling you that it was successful:

slmgr.vbs /ckhc <== disables caching of the KMS host
slmgr.vbs /ckms <== clears the KMS host name cache
ipconfig /flushdns <== reloads the IP cache
net stop sppsvc && net start sppsvc <== restarts the Software Protection Service, which is necessary for any of these changes to take effect
slmgr.vbs /ato <== attempt to activate the KMS client
Note that until you've hit 5 servers you should get an activation error to that effect. Once you hit 5 it'll go away.
slmgr.vbs /skhc <== re-enable KMS host caching and take us back to default settings
slmgr.vbs /dlv <== give us a verbose list of all the KMS licensing settings. Should show that we're activated and who we're activating against

Annoyingly, you won’t get a successful activation until you’ve hit your 6th server, but all the activations you’ve attempted will automatically work once you get there. If you want to force it you can go back and do an slmgr.vbs /ato again.

All these commands are possibly overkill, but it was the only way I was consistently able to get all the servers to activate against the new KMS.

So I, like most of us, got an email from Microsoft in the last week or so telling me that I’d attained a new certification by doing absolutely nothing. I’ve been an MCSE since 1998 on Windows NT, then Windows 2000, then Windows 2003. When they came out with the MCITP certification back in 2009/2010, I was a little annoyed since all of the products and technologies I like to show expertise on now each required their own certification. So I got the MCITP on EA, SQL and Exchange. It was a lot of tests and some extra tests I wouldn’t have normally taken, except I wanted the cert.

But back to my original point: I got an email that I’ve attained the new cert “Microsoft Certified Solutions Associate” on Windows 2008. Being always suspicious of “free” stuff I immediately put 2 and 2 together and saw that my new cert was MCSA, which has always been the lesser of Microsoft certs. I’d seen all the articles lately saying that they were completely changing the program again for Windows 8 (now 2012) so I assumed that when the new software got released that I’d have to change over. Who knew that you needed to re-up before the new one even came out??

So now to get your MCSE (Microsoft Certified Solutions Expert) you have to decide which track you want (Cloud, SQL, etc.) and take yet another couple of exams. (And then of course take more tests when Windows 2012 comes out). Who’s ready to take more tests? Annoying!

Regardless of my complaints, here I am studying up on Systems Center, which seems like a heck of a lot of bloated software (my test environment has 8 servers, with 7 different pieces of software running) to do some very cool stuff. But who wants to go back to being an MCSA??