Active Directory Migrations: New Hire Process

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

$warningpreference='silentlycontinue'

## Function to look in the source directory for all CSV files. Sort by most recent date and return the last 10.
## This way we can manipulate that file and use it for the rest of the script

function SourceFileMenu()

{
$sourceFiles = Get-ChildItem $sourcefolder\*.csv | Sort LastWriteTime -Descending | select name, lastwritetime -first 10
Write-Host ("=" * 80)
Write-Host "Available migration source files"
Write-Host ("-" * 80)

[int]$optionPrefix = 1

# Create menu list
foreach ($option in $sourceFiles)
{
if ($displayProperty -eq $null)
{
Write-Host ("{0,3}: {1,-40} {2}" -f $optionPrefix,$option.Name,$option.lastWriteTime)
}
else
{
Write-Host ("{0,3}: {1}" -f $optionPrefix,$option.$displayProperty)
}
$optionPrefix++
}

$maxOptions = $optionPrefix - 1

Write-Host ("-" * 80)
$response = 0
while($response -lt 1 -or $response -gt $sourcefiles.count)
{
[int]$response = Read-Host "Select a source file [1 - $maxOptions]"
}

$val = $null

if ($response -gt 0 -and $response -le $sourceFiles.Count)
{
$val = $sourceFiles[$response-1]
}

$pattern = [regex] "(.*)\.csv"

##save our selection into a variable and return it to the caller
$sourcename = $pattern.matches($val.Name) | foreach {$_.groups[1].value}

return $sourcename
}

##Pause function. Mainly so that the script will still work if you're using the ISE
Function Pause ($Message = "Press any key to continue . . . ") {
If ($psISE) {
# The "ReadKey" functionality is not supported in Windows PowerShell ISE.

$Shell = New-Object -ComObject "WScript.Shell"
$Button = $Shell.Popup("Click OK to continue.", 0, "Script Paused", 0)

Return
}
##ISE related stuff
Write-Host -NoNewline $Message

$Ignore =
16, # Shift (left or right)
17, # Ctrl (left or right)
18, # Alt (left or right)
20, # Caps lock
91, # Windows key (left)
92, # Windows key (right)
93, # Menu key
144, # Num lock
145, # Scroll lock
166, # Back
167, # Forward
168, # Refresh
169, # Stop
170, # Search
171, # Favorites
172, # Start/Home
173, # Mute
174, # Volume Down
175, # Volume Up
176, # Next Track
177, # Previous Track
178, # Stop Media
179, # Play
180, # Mail
181, # Select Media
182, # Application 1
183 # Application 2

While ($KeyInfo.VirtualKeyCode -Eq $Null -Or $Ignore -Contains $KeyInfo.VirtualKeyCode) {
$KeyInfo = $Host.UI.RawUI.ReadKey("NoEcho, IncludeKeyDown")
}

Write-Host
}

##Function for moving the objects to the correct OU
function CheckSite ($Site){
## Base OU where you have your users. This assumes you separate everything by region.
$BaseUserOU="domain.com/Users OU/"
switch ($Site){
"Site1 {
$OU="/CO"
$UserOU=$BaseUserOU + $OU
}
"Site2" {
$OU="/NC"
$UserOU=$BaseUserOU + $OU
}
"Site3 {
$ou="/MA"
$UserOU=$BaseUserOU + $OU
}

}

## Return the OU to the caller
return $userOU
}

## MainMenu builder
function mainMenu() {

Clear-Host;
#… Present the Menu Options
Write-Host “`n`New Hire Migration Process `n” -ForegroundColor Magenta
Write-Host “`t`tThese steps are in the order they need to be run.” -Fore Cyan
Write-Host “`t`tPlease run them sequentially and ensure each step finishes successfully” -Fore Cyan
Write-Host “`t`tbefore continuing on.`n” -Fore Cyan
Write-Host “`t`t`t1. Generate Include Files” -Fore Cyan
Write-Host “`t`t`t2. Enter Passwords” -Fore Cyan
write-host "`t`t`t3. Check for MEU" -fore cyan
Write-Host “`t`t`t4. ADMT” -Fore Cyan
Write-Host “`t`t`t5. Mailbox Move” -Fore Cyan
Write-Host "`t`t`t6. Set migrated attribute" -ForegroundColor Cyan
write-host "`t`t`t7. Set UPN and Displayname" -ForegroundColor Cyan
Write-Host "`t`t`t8. Disable Lync in source" -ForegroundColor Cyan
Write-Host "`t`t`t9. Enable Lync in target" -ForegroundColor Cyan
Write-Host "`t`t`t10. Set SIP in source -ForegroundColor Cyan
Write-Host "`t`t`t11. Move User to correct OU" -ForegroundColor Cyan
write-host "`t`t`t12. Clean up Files" -fore cyan
Write-Host “`t`t`tQ. for Quit`n” -Fore Cyan

}

##Variables. Add our snapin, decare paths, etc.
Add-PSSnapin Quest.ActiveRoles.ADManagement -erroraction SilentlyContinue
$Path="D:\newhire\includes"
$currfolder = Split-Path -parent $MyInvocation.MyCommand.Definition
$sourceFolder = $currfolder + "/Includes"

##Present the menu as a do/while, thus ensuring we only exit when we want
do {
## Call menu and store the keystroke into a var
mainMenu;
write-host "You last chose number " $input

$input = Read-Host "Enter a number for an option"

##Perform necessary option based on input
switch ($input) {
"1" { ## GEnerate include files for various scripts. renames the include file chosen to userincludes.csv and prepares the admt include
$IncludeFile=SourceFileMenu
$IFile=$includeFile + ".csv"
copy-item $sourcefolder\$IFile -destination $sourcefolder"\UserIncludes.csv"
$output=@()
import-csv $path\Userincludes.csv| ForEach-Object {
$obj = New-Object PSObject | Select-Object SourceName, TargetRDN, TargetUPN
$obj.SourceName = $_.sourceName
$obj.TargetRDN = $_.TargetRDN
$obj.TargetUPN = $_.TargetUPN
$output += $obj
}
write-host "...Generating Files..." -foregroundcolor red

$output|export-csv $path\"ADMTUserInclude.csv" -notypeinformation
Pause
}
"2" { ## Loads the parameter input. Prompts for credentials
write-host "Input target Creds" -backgroundcolor red -foregroundcolor white
$LocalCredentials=get-credential

write-host "Input source creds" -backgroundcolor red -foregroundcolor white
$RemoteCredentials=get-credential

$ImportFile="D:\newhire\includes\UserIncludes.csv"
$SourceDc="sourcedc1.sourcedomain.com"
$TargetDC="targetdc1.targetdomain.com"
$TargetDeliveryDomain="targetdomain.com"

$ExchURI="http://targetex1.targetdomain.com/powershell"
$LyncURI="https://registrarpool.targetdomain.com/ocspowershell"
$LyncFEURI="https://targetfe.targetdomain.com/ocspowershell"
$LyncFESourceURI="https://sourcefe.sourcedomain.com/ocspowershell"
$LyncURISource="https://sourcelyncdir.sourcedomain.com/ocspowershell"
$SourceDomain="sourcedomain.com"
$TargetDomain="targetdomain.com"
$RegistrarPool="registrarpool.targetdomain.com"
$TargetOU="Target/OU"
$import=import-csv $ImportFile

##Create Lync sessions for source and target
$LyncSessionSource=New-PSSession -connectionuri $LyncURISource -credential $RemoteCredentials
$LyncSession=New-PSSession -connectionuri $LyncURI -credential $LocalCredentials

write-host "Variables Loaded"
Pause
}
"3" { ##Check for existence of MEU. We can't do a migration if meu doesn't exist
foreach ($item in $Import){
write-host "Checking if user is enabled for UM in source " $item.smtp -foregroundcolor yellow

##check user attributes to see if they're enabled for UM. They shouldn't be, but just in case
$CheckUM=get-qaduser -service $SourceDC -identity $item.sourcename -includedProperties msExchUMRecipientDialPlanLink
$CheckDial=$checkUM.msExchUMRecipientDialPlanLink
if ($CheckDial){
write-host $item.smtp "is enabled for Unified Messaging. Please go disable and come back and rerun script" -fore yellow
$input="Q"
}
}
##Create Sessions
## Exchange sessions throw an error if it takes too long to get back to them, so we have to create and delete them as we go
$ExchSession=New-PSSession -ConfigurationName Microsoft.Exchange -connectionuri $ExchURI -credential $LocalCredentials

import-pssession $ExchSession|out-null

## Check if there's an MEU in target domain. If not, exit
foreach ($item in $import){
$aUser=get-mailuser $item.smtp
if (!$aUser){write-host "No MEU exists for " $item.smtp "please exit and run the Prepare script manually" -fore yellow
$input="Q"
}
if ($aUser){
##We've had some weird issues where the email address policy isn't applying immediately, so just in case let's go ahead and turn it off and back on for the users.
## We wait 30 seconds because otherwise the script goes too fast.
write-host "MEU Exists for " $item.smtp
write-host "Disabling EaP"
start-sleep -s 30
set-mailuser -identity $item.smtp -emailAddressPolicyenabled $false
write-host "enabling EAP"
start-sleep -s 30
set-mailuser -identity $item.smtp -emailaddresspolicyenabled $true
}
}
remove-pssession $Exchsession
pause
}
"4" { ## ADMT
## Can't be done via script because ADMT won't migrate the sid unless we have it installed on a DC or launch the GUI. Since that's the whole point we launch the GUI to do the ADMT
& C:\Windows\ADMT\migrator.msc
Pause
}
"5" { ## Mailbox Move
##Create Sessions
$ExchSession=New-PSSession -ConfigurationName Microsoft.Exchange -connectionuri $ExchURI -credential $LocalCredentials

import-pssession $ExchSession|out-null

foreach ($User in $import){
New-MoveRequest -Identity $user.smtp -domaincontroller $TargetDC -RemoteLegacy -RemoteGlobalCatalog $SourceDC -RemoteCredential $RemoteCredentials -TargetDeliveryDomain $TargetDeliveryDomain -baditemlimit 50 -warningaction silentlycontinue
}

## Rather than go check manually in exchange for move status, let's just do it all here. Wait 30 seconds between tries.
## Even with no data in the mailbox it still takes about 5 minutes to do the process
foreach ($User in $import){

do {
start-sleep -s 30
$a=get-moverequeststatistics -identity $user.smtp
clear-host
write-host "Getting move request statistics for " $user.smtp -fore yellow
write-host "`t`t`t " $a.status -fore cyan
}
until ($a.status -eq "Completed")
}
remove-pssession $ExchSession

Pause
}
"6" { ## Set attribute for reporting
foreach ($item in $Import){
write-host "Attribute being set for " $item.sourcename -foregroundcolor yellow
set-qaduser -service $SourceDC -identity $item.sourcename -objectAttributes @{"extensionattribute4"="MigratedToCorp"}
}
Pause
}
"7" { ## Set UPN and displayname, enable AS
$ExchSession=New-PSSession -ConfigurationName Microsoft.Exchange -connectionuri $ExchURI -credential $LocalCredentials

import-pssession $ExchSession|out-null
foreach ($item in $Import){
$UPN=$item.newupn+"@csgicorp.com"
$AS=$item.ActiveSync.ToUpper()
write-host "Setting UPN and AS for " $item.displayname -foregroundcolor yellow
set-user -identity $item.displayname -displayname $item.displayname -userprincipalname $UPN
if ($AS -eq "YES"){set-casmailbox -identity $item.smtp -activesyncenabled $true}
}
remove-pssession $ExchSession
Pause
}
"8" { ## Disable Lync in source
import-pssession $LyncSessionSource
foreach ($item in $import){
write-host "Disabling Lync for " $item.olddisplayname -foregroundcolor yellow
disable-csuser -identity $item.olddisplayname
}

remove-pssession $LyncSessionSource
## We add a delay otherwise it goes too fast
start-sleep 60
Pause
}
"9" { ## enable lync in target
import-pssession $LyncSession

foreach ($item in $import){
enable-csuser -identity $item.displayname -registrarpool $registrarpool -sipaddresstype EmailAddress
write-host "Enabling Lync for: " $item.displayname -foregroundcolor yellow
}
remove-pssession $LyncSession
pause
}
"10" { ##Set sip attribute in source
ForEach ($item in $import){
write-host "Adding source SIP for " $item.sourcename -foregroundcolor yellow
$NewSIP="sip:" + $item.smtp
set-qaduser -service $SourceDC -identity $item.sourcename -objectAttributes @{"msRTCSIP-PrimaryUserAddress"=$newsip}
}
pause
}
"11" { ##Move to OU
$date=get-date -format "yyyyMMdd"
foreach ($item in $import){
$return=CheckSite $item.sitecode
get-qaduser -service $targetDC -identity $item.displayname|move-qadobject -service $targetDC -identity {$_} -newparentcontainer $return
}
pause
}
"12" { ##Cleanup created files and move them to a completed dir
$date=get-date -format "yyyyMMdd"
move-item "$sourcefolder\ADMTUserInclude.csv" "$sourcefolder\Completed" -force
move-item "$sourcefolder\UserIncludes.csv" "$sourcefolder\Completed" -force
$ANewName=$date+"ADMTUserInclude.csv"
$UNewName=$date+"UserIncludes.csv"

if (!($(test-path "$sourcefolder\completed\$anewname"))){
rename-item "$sourcefolder\Completed\ADMTUserInclude.csv" $ANewName -force
rename-item "$sourcefolder\Completed\UserIncludes.csv" $UNewName -force
}
else {
remove-item "$sourcefolder\completed\$anewname"
remove-item "$sourcefolder\completed\$Unewname"
rename-item "$sourceFolder\Completed\ADMTUserInclude.csv" $ANewName -force
rename-item "$sourcefolder\Completed\UserIncludes.csv" $UNewName -force

}

pause
}

"Q" { ## quit and clean up our sessions if we missed any
get-pssession|remove-pssession
}
default {
Clear-Host;
Write-Host "Invalid input. Please enter a valid option. Press any key to continue.";
Pause
}
}

} until ($input.ToUpper() -eq "Q");
get-pssession|remove-pssession
Clear-Host;
Advertisements

Active Directory Migrations: Final Thoughts

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.)

Hopefully I’ve been of some help to you.

Active Directory Migrations: Assorted Lync Stuff

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.


##call include file
. .\params.ps1

##Create Sessions
$LyncSession=New-PSSession -connectionuri $LyncURI -credential $LocalCredentials
$import=import-csv $importfile

##Target side enable cs-user
import-pssession $LyncSession

foreach ($item in $import){
 if ($item.LineURI){
 set-csuser -identity $item.displayname -EnterpriseVoiceEnabled $true -LineURI $item.LineURI
 write-host "Setting EV and LineURI for: " $item.displayname -foregroundcolor yellow
 }
}
## let's clean up, shall we?
remove-pssession $LyncSession

This last one grants the voice policy and the mobility policy, if applicable. This is using the Lync powershell modules on the ADMT server


$Importfile="\\omacsgiadmt01\d$\Migration\admtincludes\UserIncludes.csv"
$import=import-csv $importfile

import-module Lync

foreach ($item in $import){
 grant-csvoicepolicy -identity $item.displayname -policyname $item.CSVoicePolicy
 write-host "Granting CSVoice: " $item.displayname -foregroundcolor yellow
 $LM=$item.LyncMobility.ToUpper()
 if ($LM -eq "YES"){
 Grant-CsMobilityPolicy -identity $item.DisplayName -Policyname "CSGI Mobility"
 write-host "Granting CSMobility: " $item.displayname -foregroundcolor yellow
 }
}

That’s it for Lync!

Active Directory Migrations: Setting user attributes

In the ongoing series of AD Migrations….

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.

AttribMig.ps1:


##filename attribmig.ps1
## Set transcript output
$Tranoutput="d:\migration\Outputs\" + $date + "SourceSIP.txt"
start-transcript -path $Tranoutput -append

##call include file
. .\params.ps1

## import our import file
$import=import-csv $importfile

##Set migrated attribute in source
## We're just setting an extended attribute using QAD and piping that out to the screen.

ForEach ($item in $import){
 write-host "Attribute being set for " $item.sourcename -foregroundcolor yellow
 set-qaduser -service $SourceDC -identity $item.sourcename -objectAttributes @{"extensionattribute4"="MigratedToCorp"}
}
stop-transcript

DisplayName.ps1


## Set our transcript and output file
$Tranoutput="d:\migration\Outputs\" + $date + "UPN.txt"
start-transcript -path $Tranoutput -append

##call include file
. .\params.ps1

##Create Sessions to Exchange 2010 in Target
$ExchSession=New-PSSession -ConfigurationName Microsoft.Exchange -connectionuri $ExchURI -credential $LocalCredentials

## Import our file and session

$import=import-csv $importfile
import-pssession $ExchSession|out-null

##Perform set user to fix displayname and upn
## Set the displayname and UPN based off of input file

foreach ($item in $Import){
 $UPN=$item.newupn+"@csgicorp.com"
 $AS=$item.ActiveSync.ToUpper()
 write-host "Setting UPN and AS for " $item.smtp -foregroundcolor yellow
 set-user -identity $item.smtp -displayname $item.displayname -userprincipalname $UPN

## Check if user is supposed to have ActiveSync Enabled and turn it on if they do

if ($AS -eq "YES"){set-casmailbox -identity $item.smtp -activesyncenabled $true}

}

## Clean up after ourselves and stop transcript
remove-pssession $ExchSession
stop-transcript

Active Directory Migrations: User ADMT and Mailbox Move

I’m not going to go thru the screenshots of how to ADMT a user over. That’s documented well enough elsewhere (i.e. HERE).

All I’ll really say about that is that you NEVER want to migrate Exchange attributes of a user. Never, ever, ever. The process for migrating a user and a mailbox is simple enough:

  • Run prepare-moverequest.ps1 for each mailbox that needs to be created. It creates an MEU (mail enabled user) on the target side with all the exchange attributes you need. Essentially a fancy contact
  • ADMT the user (see above). Exclude: homeMDB, homeMTA, mailnickname, all the msExch*, all the msRTCSIP, proxyaddresses, targetaddress
  • 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.

Moving KMS servers

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.

New Microsoft Certification Tracks

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??

Here’s a good article on the changes: http://www.microsoft.com/en-us/news/features/2012/04-11CloudCertifications.aspx

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??