Rob has created a Powershell 3.0 workflow enabled script, which replaces the *Junk* System Center Unified Installer which was delivered as part of the 2012 suite. Now, I normally don’t take pleasure in basing the work for the great engineers within Microsoft, but in the case of the Unified Installer, there will have to be an exception.

If you have any requirement to deliver a lab for working in System Center, the only real option was to grab a coffee, and lock away a couple of hours to click trough the installers, figure out what will go where, and finally get some connectors into place, before you could finally say “Bingo”. At which point the Snapshot feature of Hyper-V becomes your very best mate.

The PowerShell Deployment Toolkit (PDT) changes this forever (or at least I hope it will), Rob has leveraged the power of PowerShell workflows (and if you have no idea what I’m speaking about – start researching and mark my words this is going to play a big part of our future). And leveraging just 2 XML files has a complete unattended solution for installing SC2012SP1.

These files will go out, download EVERYTHING you will need, and then with a little help, create all the VMs for the Lab, before finally getting to grips with the payload and deploying System Center. Rob covers this process in detail on the Building Clouds blog – so go read that, and check out his MMS 2013 presentation if you need to see this work (and you do)!

What I want to cover here, is just a simple trick – the 2 XML files I mentioned are pretty cool, but only one of these is really where we will spend our time, this is called Variable.xml and the other has all the logic for checking dependencies for the components, unpacking, installing, integrating, etc.; it’s a thought read, but if you like a challenge – then crack open Workflow.xml

Configuration Roles

One of the beauties of this solution is that I can use the PDT to customise how my lab should be deployed, all with a few simple lines of XML, and I do mean simple – this is an example extract from my current file

<!– Management Console –>

<Role
Name=“System Center 2012 SP1 Virtual Machine Manager Console“
Server=“PDC-Console.diginerve.lab“ ></Role>

<Role
Name=“System Center 2012 SP1 Orchestrator Runbook Designer“
Server=“PDC-Console.diginerve.lab“ ></Role>

<Role
Name=“System Center 2012 SP1 Operations Manager Console“
Server=“PDC-Console.diginerve.lab“ ></Role>

<Role
Name=“System Center 2012 SP1 Service Manager Console“
Server=“PDC-Console.diginerve.lab“ ></Role>

<Role
Name=“SQL Server 2012 Management Tools“
Server=“PDC-Console.diginerve.lab“ ></Role>

<Role
Name=“System Center 2012 SP1 Configuration Manager Console“
Server=“PDC-Console.diginerve.lab“ ></Role>

<!– Virtual Machine Manager –>

<Role
Name=“System Center 2012 SP1 Virtual Machine Manager Database Server“
Server=“PDC-SQL2012.diginerve.lab“
Instance=“SCVMM“></Role>

<Role
Name=“System Center 2012 SP1 Virtual Machine Manager Management Server“
Server=“PDC-SC-VMM.diginerve.lab“ ></Role>

Here, you can see that I am going to deploy 2 computers to my lab, one of which will be a Management console, onto which I will deploy all the different suite consoles, including the SQL management tools; and to the second server I will deploy SCVMM, but its database will be hosted on a shared SQL server with a dedicated Instance for SCVMM.

One of my first challenges was to figure out what roles I can actually deploy with PDT, and the answer to that is locked in the XML of Workflow.xml so for this post, I want, to show you a simple trick to gather out this list of options, so that you can also get started on creating an awesome Variables.xml for your personal labs.

PS> $workflowxml = [XML] (Get-Content .\Workflow.xml)

PS> $workflowxml.Installer.Roles.Role | Select Component, Name

This will then pump out to screen in the Name column all the Roles which you can define for your configuration

Now go play…

In association with Microsoft a number of MVPs from the Windows Server / System Center disciplines have organised to run weekly technical presentations, illustrating some of the awesome features of the products, and solutions which you can deliver from the software suites. The content is going to be Level 300 and better, which translates to Geek Fest J

Looking at the line-up of presenters and topics for the next 12 weeks, you are going to be in for treat, with some of the long established heavy hitters out in force, to swing open the lid and starting fiddling with the inner workings, just to make your life easier.

The only requirement is a copy of Lync 2013 client (Download), and an hour of your time, at 4pm GMT once a week.

And just for Bonus shots, we are adding an extra presentation this week on Thursday!

The first session is tonight (23^rd April 2013) at 4pm GMT

• Automating Hyper-V administration with PowerShell

   

  And on Thursday we have, at the same time of 4pm GTM

• Keeping your CIO Happy: Executive Score carding with SQL, SharePoint and Operations Manager!

I will also be joining in the fun a little later with a deep dive on Network Virtualisation ‘Under the Hood with PowerShell’, but you have to wait a few weeks J

So – CLICK HERE NOW and get the calendar appointments!

https://communities.cisco.com/community/technology/datacenter/nexus1000v

Delivering the first truly distributed switch for the Hyper-V platform, a lot of new concepts and possibilities are truly now a reality.

Join the Beta

I can only urge you to follow the steps in the slide below, and join the Beta program

Then within a few hours you will be greeted with a message similar to the following, directing you to the Beta site, and an active community

Online Lab

Alternatively, if you are resource locked, I can suggest you take a look at the online labs hosted publically. This is not specifically the newest Nexus 1000v, and you will not get to see the hypervisor or management consoles, but will give you access to see how the Nexus 1000v seamlessly integrates with other networking hardware and devices, from the network engineers perspective.

Check out this free resource (Contributions accepted / No affiliation) at http://www.sharontools.com/online-lab/

Cheers

Damian

In the odd scenario, when VMM just keeps getting in its own way, and simple jobs keep failing, due to jobs you cannot see, trapping you, sometimes need to call in the heavy guns and stop VMM from hurting itself. The Refresher model has being around since Day 1, and if you have used VMM for any amount of time, it will be nothing new to you, so when jobs need to just stop, you need to flick the switch, and turn them off for a little time, while you get some time to fix the root problems.

How?

Start with the registry and on your VMM server, navigate to the following location

HKLM\Software\Microsoft\Microsoft System Center Virtual Machine Manager Server\Settings

Under this location, you may or may not see the following Keys – these all affect the Refreshers in VMM, which you are going to turn off J. Note if you have these already defined, note the current values; as one you fix this problem, you do need to turn back on the refreshers, otherwise VMM will have no idea what is happening on the hosts – no a thing you would really want…

• VMUpdateInterval
  
  • VM Refresher, Defaults to 30 Minutes
    
• VMPerformanceUpdateInterval
  
• VMPropertiesUpdateInterval
  
  • VM light refresher (subset of properties from the VM Refreshers), Defaults to 2 Minutes
    
• SQMUpdateInterval
  
• HostUpdateInterval
  
  • Host and User Role Refresher, Defaults to 30 Minutes
    

If you set the value to any one of these to 0, this has the effect of switching off the refresher. Now, once you have these all turned off, you are going to need to restart the VMM Service, so that it reads its new rules, and effectively stands down.

At this time you should be able to move forward with no more locking jobs active.

Remember, to go back and remove these Keys again, or reset them to their original values once you are done, and then restart the VMM services to re-activate the service.

Good Luck, and remember that this is MVP Sharing, and not CSS supporting

Damian

Structure

The Nexus 1000v is composed of two components, mapping from the modular physical enterprise world, to the Virtual world.

• Virtual Supervisor Module (VSM)
  
  • The VSM are essentially implemented as a Virtual Machine running on your chose Hypervisor (Hyper-V of course), or a physical appliance such as the Nexus 1100
  • The VSM is analogous to the Supervisor which you find in normal enterprise class modular switches.
  • VSMs are normally deployed in pairs, similar to their physical counterparts and are responsible for all the switch’s logic actions – the CPU of the environment in an Active/Passive configuration, hosting the NX-OS environment.
• Virtual Ethernet Module (VEM)
  
  • The VEM is essentially an Extensible Switch Filter deployed to the extensible switch on each Hyper-V host
  • The VEM is analogues to the Line cards found in the modular switch, which host the Ethernet ports to which we connect our systems, in this case Virtual Network Interfaces of the VM.
  • A VSM supports up to 64 VEMs in a distributed logical switch model, with each VEM represented in NX-OS of the VSM as line cards (with the port description automatically representing the VM Name)

Deployment

Deploying the Nexus 1000v is completed tough to use of a simple installation wizard, which generates 2 Virtual Machines and attaches an installation ISO to deploy the Supervisor operating systems (NX-OS) and their heartbeat for High availability. The Extensible switch modules are then deployed to the relevant hosts, and create a tunnel back to the VSM for configuration; these modules can be manually deployed, or through the use of SCVMM 2012 SP1 can be automatically distributed and enabled.

Connecting the Nexus 1000V virtual network with the physical upstream network, is achieved by utilizing the host network adaptors connected to the extensible switch. These can be bonded to create large trunks of 6 active ports, and 6 passive ports per host. These ports can also be distributed across multiple physical switches for high availability.

The Nexus 1000v is an enterprise class, proof of concept ready solution, which strategically redefines the network for cloud.

Can you afford to miss out…

Regardless of your environments side, you need to consider the Nexus 1000v as core network component for Virtualization/Cloud project. Its proven enterprise history, Cisco’s dedication to NX-OS with over 2000 active engineers, and its unbeatable production costs.

The Nexus 1000v will be available in 2 Editions, the following table illustrates the cost and feature comparison

Investigate this platform now, learn about vPath and the Cisco virtual services vision; treat your Hypervisor, treat your business.

Learn more – https://communities.cisco.com/community/technology/datacenter/nexus1000v

Happy Networking

Damian

What is the Nexus 1000V?

Cisco Nexus® 1000V Series Switches provide a comprehensive and extensible architectural platform for virtual machine (VM) and cloud networking. The switches are designed to accelerate server virtualization and multitenant cloud deployments in a secure and operationally transparent manner. Integrated into the Windows Server 2012 Extensible Switch, and fully compatible with System Center Virtual Machine Manager 2012 SP1, the Cisco® Nexus 1000V Series provides:

• Advanced virtual machine networking based on Cisco NX-OS operating system and IEEE 802.1Q switching technology
• Cisco vPath technology for efficient and optimized integration of virtual network services
• Tight integration with System Center Virtual Machine Manager 2012 SP1
• Layer 2 Switching with Transmit side Rate Limiting
• Security Policy Mobility, inbuilt support for Private VLANs with local PVLAN Enforcement
• Provisioning Port Profiles with deep Integration with SCVMM
• Traffic Visibility, including VM Migration Tracking, NetFlow v.9 with NDE, Cisco Discovery Protocol v.2
• And so much more

These capabilities help ensure that the virtual machine is a basic building block of the data center, with full switching capabilities and a variety of Layer 4 through 7 services in both dedicated and multitenant cloud environments.

Learn More

Join Cisco Gunnar Anderson (Cisco), Appaji Malla (Cisco) and myself (Damian Flynn) on Wednesday March 6^th at 9am PST as we present the Nexus 1000V, Overview some of the amazing features which this solution enables, and most importantly share the details on how you can start working with the Beta Release right away.

Follow this link to register for the launch, and we will look forward to a great online event, and an opportunity to show you the future, and answer your questions.

Share.

Please click the buttons below, to tweet, share and re-blog what is clearly one of the most important events in the Microsoft Private Cloud strategy so far in 2013.

See you Wednesday

Damian

Learn more @ https://communities.cisco.com/community/technology/datacenter/nexus1000v/

I have not being slacking, that I promise; the last 2 months have being a complete nightmare which oh so much happening. But it is all good.

The year started off on a high again as I was renewed for the 3^rd year in a row as a MVP – so first and foremost, thank you to all that have helped make this real again both online and offline. Once again the focus of choice is Cloud and Datacenter Management, which translates to Windows Server / System Center, or the Cool Stuff…

The beginning of January was swallowed up with the final edits for the second book, which from the drafts I had the opportunity to read from my fellow authors, namely Aidan, Patrick and Michel, this will be a bible you are going to want to have on your desk at all times; some of the details and reference trapped inside the 550 page is amazing; I even found myself looking up some details from Michel’s chapter yesterday when debating with my colleague whether he should not leave the Hyper-V host reserve alone – Awesome (And no – I don’t have copies yet either, just the private drafts). This one is on the shelves in March, so be sure to check it out.

While all this work was happening, we also kicked off the year we the amazing VIRTy Alley event, digging deep into the depths of VMWare and Hyper-V. If you missed this event, don’t panic – it is still available online, so you can grab the slides and watch the presentations – and please no laughing. The information is at this URL: http://www.vkernel.com/virtu-alley/presentations. My topic for the event is the new Software Defined Networks feature in Windows 2012; which I also cover in even more detail in the book!

Then we have Orchestrator, this is my System Centre Blood at the moment for my Day Job, as we get close to wrapping up a new SaaS solution, and a major project to move ID Management to SAP. Both of these projects are leveraging the Microsoft Forefront Identity Management 2010 R2, Synchronisation service to keep our AD and Line of Business applications in sync; and with the power of Orchestrator we manage, control and log all the steps hundreds of times a day. Cool stuff! I did need to go under the hood and published a new Integration Management Pack for FIM out on Codeplex (http://scointegrationpacks.codeplex.com/releases ) just in case you might need to do the same someday (there is an update in my local repository ready for publishing – ill sort that out on Monday, Promise! Which has 1 new activity).

I also had the opportunity to contribute the feature article on the just release TechNet UK February 2013 newsletter, with some pointers on Orchestrator SP1, and the community Integration packs…

Then it was off to Boston for a week, before heading on to the as always brilliant MVP Summit; getting the opportunity to meet so many Guru’s and heckle the Microsoft Product groups. Before finally returning back to the currently “Smelly” Irish countryside.

If you are by now tiered reading this, then I’ll just sneak in a plug to the blog postings which I have being co-authoring with Nigel Cain from Microsoft, and the VMM team, covering all that is new and confusing in the world of Network Virtualization; these are LONG and detailed posts, with many more to come, but Highly recommended reading if you are considering deploying VMM 2012 SP1 to production. This will link you to the latest post we published – http://blogs.technet.com/b/scvmm/archive/2013/02/14/networking-in-vmm-2012-sp1-logical-networks-part-i.aspx

What’s next?

Next week, Cisco will present to the world the new Nexus 1000v Virtual Switch for Windows 2012, and VMM; I am joining the Launch party guess presenters list on March 6^th so some slides to wrap up for that.

Then its MMS, together with Nigel, we will take to the podium to chat about our SP1 experiences, and try to share some tricks, trips and traps!

I have a surprise poster to share with you also, but it’s not ready just yet, it is still a work in progress, but as a tease, here is a sneak peek…

See you soon

Damian

Announcing the Initial Public Release of the Orchestrator Integration Pack for FIM Sync Services 2010 and 2010 R2

You can grab the code and IP on CodePlex at https://scointegrationpacks.codeplex.com/

Activities

Currently the Pack is exposing 4 activities, which are as follows

• Get Management Agents
  

  Return a list of all the registered Management Agents on the connected FIM Sync Server

• Start Management Agent Run Profile
  

  Supply the name of the Management Agent, and the Run Profile which we would like to start

• Clear Run History
  

  Remote all the Profile Run History prior to the supplied date

• Clear Password History
  

  Remote all the Password Sync History information prior to the supplied date

VIRTu Alley will take place on Tuesday, January 15th from 10:00 – 1:00 EST and Wednesday, January 16th from 10:00-1:30 EST.

I will be speaking on day 2, doing a Dive on Network Virtualization. Fellow MVP/co-author/friend Aidan Finn (@Joe_Elway) is going first with an overview of “What’s in Windows Server 2012 Hyper-V”, followed by fellow MVP Didier Van Hoye (@WorkinghardinIT) talking about “Cluster Aware Updating”, before I finally get to share some tricks.

There’s no cost – all you have to do is register for one or both days (each day requires registration):

Click here to register for VIRTu Alley Day 1

Click here to register for VIRTu Alley Day 2

The event is jam packed full of really impressive speakers, so do not waste the opportunity to get a great seminar for free.

Schedule of Events

Click here to register for VIRTu Alley Day 1

Click here to register for VIRTu Alley Day 2

VIRTu Alley will take place on Tuesday, January 15th from 10:00 – 1:00 EST and Wednesday, January 16th from 10:00-1:30 EST.

I will be speaking on day 2, doing a Dive on Network Virtualization. Fellow MVP/co-author/friend Aidan Finn (@Joe_Elway) is going first with an overview of “What’s in Windows Server 2012 Hyper-V”, followed by fellow MVP Didier Van Hoye (@WorkinghardinIT) talking about “Cluster Aware Updating”, before I finally get to share some tricks.

There’s no cost – all you have to do is register for one or both days (each day requires registration):

Click here to register for VIRTu Alley Day 1

Click here to register for VIRTu Alley Day 2

The event is jam packed full of really impressive speakers, so do not waste the opportunity to get a great seminar for free.

Schedule of Events

Click here to register for VIRTu Alley Day 1

Click here to register for VIRTu Alley Day 2

1. Source forest
   1. Create Test Users and Exchange Mailboxes
   2. Use Virtual Machines (Windows XP / 7 – Office 2007 / Office 2010) as Pseudo Clients for the Test Users
2. Target
   
   1. Address the issues related to scenarios where the target accounts might already be pre-populated
      
   2. Prepare a Mapping CSV to link the Source accounts with the Target accounts
      
   3. Use ADMT to migrate both the Password and SID, for the Test account
      
   4. Use the Exchange script Prepare-MoveRequest.ps1 to link the Source Test Accounts to target Accounts
      
   5. Migrate the Content of the Mailbox Move-MailboxRequest
      

There is more to cover, but that’s for another day… we have lots to do and cover, so head down and dig in.

Validation Pass Configuration

For this validation pass, I have created the following environment

• Two test accounts in the source forest called taccount1 and taccount2, both of which are mailbox enabled
• Two virtual machines (Windows 7 as this is still the OS which most organisations are utilizing) configured as desktops with Outlook 2010 in the source forest.
• taccount1 is using the computer TestDesktop1 as its workstation, and tccount2 is using the computer TestDesktop2 as its workstation
• To simulate both account scenarios, I have also created an account in the target forest called Test.Account2 which I plan to merge taccount2 with.
• Three security groups on the source forest configured with the following membership
  • TestGroup1 ß taccount1
  • TestGroup2 ß taccount2
  • TestGroup3 ß taccount1,taccount2

Account Locations

Before we proceed, there are two migration scenarios which must consider

1. The user has a unique account in both forests (this can be common situation to enable employees access to target resources while the integration is being organised.)
2. The user has a unique account only in the source forest.

Account in Both Forests

In this scenario, we need to address the merger of attributes and mailbox resources from the source forest to the destination forest. We also need to play extra consideration in the situation where the user account in the target forest has also being enabled with a mailbox; which is going to complicate matter somewhat more.

Rule of Thumb

If at all possible, use the following guideline when considering the creation of secondary accounts for users in the target forest while preparing for consolidation, as these will keep things a lot simpler at the time of migration.

1. Create the accounts in an OU where you can clearly identify they
2. Keep the amount of data attributes which are populated to a minimum, as these will need to be considered again at merge time.
3. Do not Mailbox enable the accounts!
   1. Really, you do not want to have the accounts mailbox enabled, It complicated communication with the users, and makes a nightmare of the migration by adding extra steps which we can do without.
   2. You should however, Mail enable the account. And be 100% sure that the email address you define when mail enabling the account is an email address which is listed on the users account in the source forest (proxy address list). This will ensure that the migration tool can use the mail address as a unique identifier for matching up the source and target accounts when merging. Additionally, the User will now also be included in the Exchange GAL, but pointing back to the source mailbox.

Planning Account Merges

In the painful circumstance where the users account has already being pre-created for you in the target forest, you can prepare from some manual work. Initially, you will want to verify if target forest accounts are either Mail or Mailbox enabled.

If the account is Mailbox enabled, find out if there is truly a business requirement, generally the answer is NO, as the user already has a mailbox in the source environment, and this situation is simple complicating the migration, and the user. If at all possible, export the content of the target mailbox to a PST file which you can provide to the user, and remove the mailbox from the target forest.

If the account has not been mail enabled, which is quite likely going to be the case, as the accounts would have being provisioned quickly to address the business requirements of granting access to resources such as Lync and SharePoint, then you must go ahead and Mail enable the account. We will consider what steps we need to take to address this typical scenario next.

Accounts Only in Source Forest

The will be the normal scenario for the vast bulk of your accounts in a normal situation, (but what is normal anymore?). In this configuration we will have the migration tool create for us the account in the target forest, and therefore not need to be concerned with pre-enabling the accounts for mail, or cleaning up any prior efforts.

Merging Accounts

This job should not be underestimated, as it is going to be quite manual, and might require the input of additional users to ensure the preparation work is completed correctly prior to applying any additional changes to the accounts.

Essentially, we will require a method of associating or mapping the account in the source forest with the account in the target forest. In the scenario where the account names match in either forest; or even better the target account is Mail User enabled, then these is process is going to be trivial. However, the typical scenario will be that naming conventions are totally different in both environments, and will need some patients to manually create the mapping.

To facility a migration where accounts must be merged, we are going to need some specific information from both forests, which we can then combine to create a single unique record per account to be processed; The details which we will require are as follows:

• SourceName – The objects “SAM Account Name” as defined in the Source Forest
• SourceMail – The objects “Primary eMail address” as defined in the Source Forest
• TargetSAM – The objects “SAM Account Name” as defined in the Target Forest
• TargetUPN – The objects “User Principal Name” as defined in the Target Forest

Exporting Data

To export the data from the Source Forest, we can use the Active Directory PowerShell Module. The following command syntax will dump all User Accounts from the source domain, specifically there SAM (SourceName) and Primary Mail address (SourceMail) information

Get-ADUser -Filter * -Properties mail | select @{Expression={$_.samaccountname};Label="SourceName"}, @{Expression={$_.mail};Label="SourceMail"} 

Similar to the process for exporting from the Source Forest, we can again use the Active Directory PowerShell modules to dump the Target Accounts SAM (TargetSAM) and UPN (TargetUPN) information. If housekeeping is good, we can use the -SearchBase parameter to reference a specific OU which may be hosting the target accounts, in my example I called this OU “ADMT”

Get-ADUser -SearchBase "OU=ADMT,DC=DigiNerve,DC=net" -Filter * -Properties mail | select @{Expression={$_.samaccountname};Label="TargetName"}, @{Expression={$_.UserPrincipalName};Label="TargetUPN"} 

Sample Exports

As an example let’s consider our test accounts, which we created for the validation pass as a typical mapping challenge

Quickly glancing at the above lists, we can see clearly that there are more accounts in the Source Forest, that those in the target forest. Additionally, we can quickly see that although the naming conventions in both forests are different, we can create a consolidated list, as below for example.

However, creating this list is based on knowledge and some amount of guess work, as we manually build the list based on the associations we can visually see. You can extend the list to include additional data from both forests such as FirstName, Surname and Display Name, which might make this process simpler, and maybe even permit you to write a function or macro in excel to create a mapping for you.

Pre-Migration CSV Files

Prior to starting the User Account Migration, ensure that you have created the list as above. Then from this list we will create two different CSV files which can then be utilised for the rest of the migration. The following is an example of the CSV files created from the table

ADMT-Mapping.csv

SourceName, TargetName 

taccount2, Test.account2 

MAIL-Mapping.csv

TargetName, SourceMail 

Test.account2, Taccount2@decommission.local 

Final Pre-Flight Checks

Prior to commencing any work with the actual migration we must ensure that the accounts in our target environment which we plan to migrate are ready.

• Accounts which have Mailboxes should really be mailbox disabled and any content exported to a PST. (This can be imported after the migration or just passed to the user)
  

Once this work is complete, we can proceed.

User Account Migration

With the environment now prepared, and our accounts understood, we will begin the operation in batches of accounts. The size of the batches is totally up to you, however initially for validation and piloting these should be keep quite small.

Once you have selected the user’s batch to utilize, for example test accounts, we will follow this process

1. Any Mail Contacts in the target forest should be removed for the accounts about to be processed.
2. Using the ADMT tool we will migrate/merge accounts from the source forest to the target forest based on our CSV file
3. Mail enable the new accounts in the target forest
4. Using the Prepare-MoveRequest.PS1 utility we will prepare the target accounts for mailbox migration.

ADMT User Account Migration Wizard

Drum roll time, as we are finally going to take advantage of the preparation work which we have being diligently addressing over the past number of posts. Using the ADMT tool which we deployed in our target forest, along with the password export server which we implemented in the source forest we will now begin process our first batch of accounts.

With the Trust, ADMT and Password tools in place, along with our CSV File for mappings we can now start a migration exercise.

Note: We can also use this CSV for creating the accounts in the target forest, if they do not already exist. The benefit here is that the account name created in the target forest can be formatted in a different convention from that of the source forest, keeping things nice and tidy. As an example this is a sample of my updated ADMT-Mapping.csv file with a new entry for my taccount1, which I would like created for me on the target forest as Test.Account1

ADMT-Mapping.csv

SourceName, TargetName 

taccount2, Test.account2 

taccount1, Test.account1 

1. From the designated Management Station, logon and launch the ADMT tool.
2. From the Action menu, or by Right clicking the top most node in the tree, select the option User Account Migration Wizard

   

3. After a few moments the User Account Migration Wizard will be presented, on the welcome screen, after reading the introduction Click Next
4. The First page we will work on is the Domain Selection page, providing details of the source and target domains
   1. In the Source Domain Text Field, we can type the fully qualified domain name of the source forest domain
   2. In the Source Domain Controller Text Field, we can type the fully qualified name of the source domain controller we are going to use
   3. In the Target Domain Text Field, we can type the fully qualified domain name of the target forest domain
   4. In the Target Domain Controller Text Field, we can type the fully qualified name of the target domain controller we are going to use

   

5. The next page User Selection Options permits us to determine which accounts we plan to process

   I am going to select the option to Read objects from an include file which essentially is my CSV file

   

   On the Include File Selection page, click on Browse… and select the CSV file which contains the mapped accounts that you plan to migrate.

   

6. On the Organizational Unit Selection page, click the Browse… button to select the OU on the Target forest we will create any new objects in. I have pre-created an OU called ADMT for my environment.

   

7. The Password Options page, offers some choices on how to handle the passwords for accounts in the target domain. If you choose to deploy the Password Migration tool, then you will likely want to use the Migrate Passwords option, but alternatively you can use the Generate complex passwords option just as easily.

   

8. On the Account Transition Options page, we will determine how the accounts should be treated on the source and target forests. Set these to suit your requirements, for example, have the new accounts in the target forest flagged as enabled or disabled based on their current state in the source forest; and set the original source account to expire in 60 days’ time (by which time we should be well and truly done).
   1. Sneaking at the bottom of this page is the option to Migrate user SIDs to target domain, this one you are going to want to enable, to that you can ensure that the users retain access to the file and print resources in the source forest until you have time to re-assign the Access Control Lists on these servers.

   

9. As this is the first time running the wizard, and selecting the option to Migrate user SIDs to the target domain, the wizard will request that It is permitted to enable auditing on the source domain, this must be agreed with by clicking Yes if the wizard is to be able to migrate the SID history. Depending on the configuration in the target domain, you may be prompted further to enable auditing there also.

   

10. The User Account page of the wizard, will then request an account with privileges on the source forest, so that it can read the SID details for migration.

    

11. The User Options page will allow us to determine the action to take on the associated groups which our test accounts are members of. The options here will depend on the details you need to migrate, for example if you are using roaming profiles these will need to be addressed. Many file shares might be restricted by Groups, so migrating this information to the target forest will migrate extra data which will need to be cleaned up again later.

    

12. On the Object Property Exclusion page, if there are properties on the source accounts which we do not want migrated, you can select these here, for example this might be important if the account was pre-staged and configured with an office for example which you do not wish to overwrite.

    

13. On the Conflict Management page, as we have two scenarios to address, I am going to select the option to Migrate and merge conflicting object. In addition these target objects were created for a reason, so unless you need to clean up, I will not turn on any of these switches.

    

14. And finally the Summary page, review the task description and then when ready click on Finish to start the process.

    

15. The Migration Process Page will then be displayed, which will present the progress of the migration, along with statistics of the actions taken/completed. Note that there is a View Log button which you can click to provide deep insight into what has being happening in the background.

    

16. Finally, we can click on Close to complete this part of the exercise.

Mail Enable Accounts

At this point, our users account should be copied to the target domain, with both SID history and passwords! However, the accounts we just migrated are still not Mail enabled, therefore we will utilise the second of our CSV files which we prepared a little earlier and use it to batch enable each of the newly migrated accounts. The command to enable an account as a mail user is simply Enable-MailUser -Identity <target.account> -ExternalEmailAddress email@source.exchange

Taking both the PowerShell command and the CSV file for the mail-mapping, we can use the pipeline and looping functions in PowerShell to do the job for us

Import-Csv .\mail-mapping.csv | foreach { Enable-MailUser –Identity $_.TargetName -ExternalEmailAddress $_.SourceMail } 

Once this script has being completed, we can take a look at one of the accounts which we affected on the target domain to verify everything is as we expect.

We should be able to observe the New SID on the account, the SID History, and the mail attributes which have being migrated and assigned during the course of the past few exercises.

Note: Similarly to utilizing our AMDT-Mapping.csv file for creating new accounts in the target forest, we can utilize our Mail-Mapping.csv file to ensure that these new accounts are also configured as mail users in our target environment, ensuring that they are prepared for mailbox migration steps. As an example this is a sample of my updated MAIL-Mapping.csv file with a new entry for my Test.account1, which I would like to reference the address in the source forest of TAccount1@decommission.local

MAIL-Mapping.csv

TargetName, SourceMail 

Test.account2, Taccount2@decommission.local 

Test.account1, Taccount1@decommission.local 

Mailbox Migration

With our accounts now on both forests, and the glue in place to reference each other, we are quickly approaching the final stages to get the migrations sorted. In this section we are going to cover two stages

• Prepare the Target account for Mailbox Move
• Move the Mailbox from the Source Exchange to the Target Exchange

Prepare Mail Moves

Microsoft has helped out, by providing a script to help with the migration of Mailboxes from a remote forest to the target forest. This script is located in the Exchange 2010 Scripts Folder, located at c:\Program Files\Microsoft\Exchange\V14\Scripts and is named Prepare-MoveRequest.ps1. The following sample syntax defines the command we will issue.

 .\Prepare-MoveRequest.Ps1 -Identity "EmailAddress" -RemoteForestDomainController "FQDN of Source DC" -RemoteForestCredential $sourceCredentials -LocalForestDomainController "FQDN of Target Forest DC" -LocalForestCredential $targetCredentials –UseLocalObject –OverwriteLocalObject -Verbose 

Using Credential Variables

To facility the migration of our source mailboxes and accounts to the target forest, we will again need to provide some credentials. Instead of repeat typing these, I will use powershell variables to collect and store for use in our commands. To do this, I am going to work from a server in the Target Exchange environment and use an Exchange Shell, so that I will also have access to the necessary exchange commands for the next stages.

Let’s start by creating a variable for our target environment, and storing our credentials in this variable. Note, when we are prompted for these credentials provide them as either a UPN or Domain\User format.

$targetCredentials = Get-Credential 

And again, we will repeat, this time providing credentials with privileges to the source domain. If you followed all the steps so far, then our target administrator credentials should also work as we granted the administrator account full access.

$sourceCredentials = Get-Credential 

Prepare Mailbox Move

On our target domain, we can launch an Exchange Management shell, and navigate to the host folder of the script

CD 'C:\Program Files\Microsoft\Exchange\V14\Scripts' 

Utilizing the credential objects which we created in the previous step, we should be able to prepare our recently migrated accounts for mailbox migrations. In the following example, we will use our Mail-Merge.CSV file again to prepare all the recently migrated and mail user enabled accounts.

Import-Csv c:\mail-mapping.csv | foreach { .\Prepare-MoveRequest.Ps1 -Identity $_.SourceMail -RemoteForestDomainController "Decom-DC01.decommission.local" -RemoteForestCredential $sourceCredentials -LocalForestDomainController "DC01.diginerve.net" -LocalForestCredential $targetCredentials -TargetMailUserOU "Distinguished name of OU in TargetForest" –UseLocalObject –OverwriteLocalObject –Verbose} 

After a successful run, the verbose output of the script should indicate that the target account was matched up and merged.

Migrate Mailboxes

And the Final Hurl, to move the actual mailbox.

New-MoveRequest –Identity test.accoun1 –RemoteLegacy –RemoteCredential $SourceCredentials –RemoteGlobalCatalog decom-dc01.decommission.local –TargetDeliveryDomain decommission.local –Verbose 

Executing this command in verbose mode, will deliver quite a lot of information, to help us understand how the process is executing, before finally queuing the mailbox for its movement.

As with the previous steps, we are likely going to want to move a number of mailboxes from the source to the target forest, so using the same CSV files to manage our batch, we can again get PowerShell to queue up all the moves for us:

Import-Csv c:\mail-mapping.csv | foreach { New-MoveRequest –Identity $_.TargetName –RemoteLegacy –RemoteCredential $SourceCredentials –RemoteGlobalCatalog decom-dc01.decommission.local –TargetDeliveryDomain decommission.local –Verbose } 

Just as with local move requests, we can query, suspend and resume these from the exchange shell.

If you are curious, on the Source Forest, the mailbox we migrated will have been removed, just as you would expect with a local move. And the account should not be listed as a Mail User, with its references updated to point at the target forest exchange environment.

Outlook User Experience

This will not be of any shock, when we check the users outlook experience; the user will be unaware of anything happening while the migration itself is happening, however the moment the migration is complete; if the user was connected to the mailbox using Outlook a banner will be presented

And just for geek value, we can also look at the connectivity dialog

Now, being a good end user, we can Close out Outlook, and then re-launch again. Assuming all the changes have completed their replication cycles, Outlook will update its profile, and point to our new mailbox. However the old account will not have access to the new mailbox, so the user will need to use their new account from the target OS.

After providing the new account, Outlook will complete its connection, and mail will once again flow

Note – that until the user starts natively logging into the new Target Domain, they will be challenged with the new User name every time they launch outlook.

The topics we are going to cover are as follows

1. Source Forest
   
   1. Enable the Exchange Server Mail Replication Service Proxy
      
2. Cross Certify Exchange in each forest (Only necessary when using Self Signed Certs)
   
3. Target Forest
   
   1. Add Source Domains to Authorised Domain List
      
   2. Configure Relay to Source Domain (For Mailboxes not hosted on Target)
      
   3. Configure Address Book Synchronisation Services
      

Exchange Server Mail Replication Service Proxy (MRSProxy)

On every Exchange 2010 CAS server this MRSProxy is installed, which is utilized to facilitate cross forest mailbox move requests, which are initiated from the exchange server in the trusted environment, generally the target forest. However, by default the feature is disabled, so we need to change that default and enable it on each exchange server hosting the CAS role in the source forest.

Exchange 2010 SP2 and Newer

This task is quite easy to accomplish when run from the Exchange Management Shell , on one of the exchange servers in the source forest. Assuming the EWS web site is installed with default names, the following command will apply the change needed.

PS> Get-WebServicesVirtualDirectory –Identity "EWS (Default Site)" | Set-WebServicesVirtualDirectory –MRSProxyEnabled $True 

Exchange 2010 Pre – SP2

We don’t have the luxury of PowerShell if we are pre-SP2, in which case, we will be changing the setting in the configuration file. The setting in question is located in the following file C:\Program Files\Microsoft\Exchange\V14\ClientAccess\exchweb\ews\web.config.

Open the file for exiting, for example Notepad, and search the file for the string <MRSProxyConfiguration which you should locate very close to the bottom

Change the IsEnabled field from “false” to “true”

You are going to have to repeat this on each CAS server manually.

Latency and Timeouts

Before, we wrap up this configuration change, there is one additional consideration which we should take into account, the network infrastructure between the source and target exchange servers. Transferring mailboxes over an internet connection will introduce latency into the path, and we need to take this into consideration. The default Timeout value used by the MRSProxy is 1 minute, which is likely not going to be enough, certainly as I am moving data from a slow field office exchange environment to a centralised Datacenter infrastructure.

In this case, we should consider changing the timeout to a larger value, for example 15 Minutes. Again, this needs to be changed on each CAS server in the source environment, and unfortunately we need to do this one the old fashioned way. The setting in question is going to be located in the following file C:\Program Files\Microsoft\Exchange\V14\ClientAccess\exchweb\ews\web.config.

Search the file, and locate the entry <MRSProxyConfiguration and change the DataImportTimeout from its default value of “00:01:00″ (1 minute) to our larger value (15 minutes) “00:15:00″. Then save the file.

For either or both of these changes to take effect, on each CAS server you now will need to restart the Web Server

IISReset 

Add Source Domains to Authorised Domain List

Mail flow is a very important part of a migration effort, as we need to ensure that the messages continue to be delivered for our users in the source environment, during the life of the process.

Prior to conducting any work on the consolidation, the mail flow between environments will be typical out via the public internet scenario, with users in each environment effectively having mails addressed to their respective domains. This configuration will not work once we start integrating as users from the source domain will be migrated to the target exchange environment, and if we do not address mail flow, these users will be unable to receive mails for their original source domain address.

To deal with this scenario, we need to apply a change to the mail flow; in such a way that all inbound email for both the source and target domains are delivered now to the target exchange environment. We also need to ensure that the target exchange environment accepts the new domain as permitted (authorised), while also forwarding mails for addresses in the source domain to the source exchange server assuming that the user addressed in the email message is not already located in the target exchange environment.

The changes which need to be applied can be implemented in a reverse configuration,

• Starting with creating a traffic flow from the target exchange environment to the source exchange environment.
• Authorizing the source domain addresses on the target exchange server
• Testing the target exchange server will deliver emails to the source address without issues
• Assigning an alias to a user on the target exchange environment with a source address, and testing exchange delivers to this alias also

Address Book Synchronisation Services

One final consideration in this setup is address books; in large migrations and consolidations, it is quite normal for the integration of the mail environments to be active for a long period of time. When this is the case we would normally want to extend the Exchange Address books on each environment with the list of users from the respective members list. To accomplish this, we would generally create contact objects in the respective environments for each user and using yet another tool keep these in synchronisation.

Synchronisation is important, as users in the source environment will over time be migrated out, and there address for deliver will change, but not in the normal sense. Although these users will continue to have their original SMTP address associated to them in the target environment, they will assume a new X.400 address. This address will be the cause of many support requests, as it is still the default address which Outlook will utilize when routing mails to exchange, and is also the preferred address for outlook to store in its cache.

Therefore, if Damian.flynn@source.com is moved to the target exchange environment, users on the internet will have no issues delivering mails, however other colleagues of Damian.Flynn from the source.com environment will likely see bounced mail messages in outlook, as it will try and now fail to deliver messages using the systems X.400 address.

There are 2 ways to address this

• Make the users aware of the issue, and have them delete the cached address from their colleague, then resent the message after typing the full SMTP address out again (preferably the new target.com address, but not required), which outlook will then cache and use in the future.
• Use an Address book Synchronisation Service, which will address this issue each day by updating any address changes and distributing this back to exchange, and thus the clients

In my scenario, I am going to migrate around 150 users and aim to complete within a week, so the effort involved in setting up the Address Book Synchronisation service is not sustainable for such a small and short project; and therefore I am going to skip this process. However, if you are working on a larger / longer project, you will want to take a look at Microsoft FIM, and its Exchange GAL functions to address this objective.

If I have a requirement in the future, I will document the steps involved also.

Configure Relay to Source Domain

The first configuration we will look at establishing is the Send Connector between the target and source environments. This can be completed in PowerShell or from the User Interface on the target exchange. For illustrative purposes I will use the UI to create the link to our source exchange environment (decommission.local).

Working on the Exchange Management console, from the Target forest, expand the navigation tree to Microsoft Exchange à Microsoft Exchange On-Premises à Organization Configuration àHub Transport. Select the Send Connectors tab in the view pane

• From the Actions list under Hub Transport, located and click New Send Connector…
  

  
  

• The New Send Connector wizard should now appear
  
  • In the Name field provide a name for the connector we are about to create, for example Decommision.Local Send Connector.
    
  • In the drop down list to Select the intended use for this Send connector we can stick with the default option Custom
    
• On the Address Space page of the wizard, we will click on the Add… button to present the SMTP Address Space Dialog

  
  

  • In the Address space text box, provide the name of the Source SMTP email domain we will be routing traffic for, eg decommission.local
  • If the email domain is split into subdomains, you might want to enable to check item Include all subdomains
  • The default Cost will ensure that this connector is 1^st choice for the mail flow.
• After adding all SMTP domains hosted on the source exchange environment to the list, we can click on Next
  
• On the Network Settings page of the wizard, we will click on the Add… button to present the Add smart host dialog

  

  • Selecting either the IP Address or Fully qualified domain name radio options, we can supply either the IP address of FQDN of the Source Exchange environment Hub, or Edge transport services. This will be the new hand-off point for transferring emails from the sending environment to the source (destination) environment
• Repeating the previous step for each additional host you wish to add for the source, once complete, click on Next
• The Configure smart host authentication settings will next be offered, I am going to keep this set to None. I am choosing this option, as mail I transfer from the Target Environment will be presented at the Source Environment to the same drop point which normal internet email is currently delivered to, which is also not authenticated. This keeps everything simple and clean for our migration effort

  environment

• The next page in the wizard is the Source Server in our target environment which will be delivering email on to the source domain over this connector. Essentially this page lists all the servers in the target environment which are enabled with Hub or Edge services, and capable of transferring email over the connector, we simply scope this list back to define the servers we wish to permit to use the connector.

  

• Finally, the wizard will present the summary of our selections, before finally proceeding to create the new connector

  

• Once the wizard is complete, it will confirm its changes were successfully applied, and show us the PowerShell command which was created based on our selections.

  

Testing Outlook/OWA mail flow

Before we proceed to the next step, we should complete some test mail flows to ensure that the connector is working, by sending emails to users with the source SMTP domains which we enabled in this connector, and verifying that these are delivered correctly. We should also check that these mails have indeed traversed the connector, by either using message tracking, or simply checking the email header of the received email message.

If there is a backlog, with mails traversing this connector we can use the Queue Viewer, or the PowerShell command Get-Queue referencing the sending target environment exchange server, to see if there are many messages queued, or if there is a problem handing over the messages to the source environment destination servers.

Testing SMTP mail flow

With successful test results from the mail clients, passing messages between the two environments using the connector, we should take a look at how the Hub Transport behaves. This is the module of exchange which is responsible for handling email from other systems, and the internet.

We can use the shell to test this functionality out. From the shell, launch telnet command ”

telnet <server> <port>"

providing the address of the SMTP gateway for the Target Domain, along with the SMTP listener port number with by default is 25

Telnet 172.16.1.31 25 

The server will then acknowledge the connection by offering its banner

220 smtp.diginerve.com Microsoft ESMTP MAIL Service ready at Fri, 14 Dec 2012 10:51:36 -0000 

Next, we will introduce ourselves with a Hello message, and the name of the domain we represent, as you can see, I just make this up J

helo mytestsession.telnet 

The server should then greet us back

250 exchange2010.diginerve.net Hello [172.16.1.181] 

Now, we tell the server that we are sending a mail from our address; again I am making it up as I expect no one will reply to me J

mail from: damian@telnet.cmd 

The server now checks to see if my address is ok, since the server is not doing any spam type checks, it is happy to let me proceed

250 2.1.0 Sender OK 

Next, we will provide the email address I am sending to, the recipient

rcpt to: damian@decommission.local 

Now, the server will check this address, and due to the fact that the domain is not known to it, refuse to let me go any further!

550 5.7.1 Unable to relay 

Ok, not sure we were expecting that? Or were we? Well, to be honest we were.

The process we completed earlier to ensure that the connector has being established works fine, due to the fact that email created within our exchange system were ultimately sourced from the CAS module of exchange, which manages the MAPI\RPC connections from Outlook and OWA, etc.

The connector is SMTP based, and is hosted by the Hub Transport, but simply tells the server that if somehow emails destined for the source domain appear in the transfer queue, use this connection.

The test we just tried, however asks the transport server to accept the mail into the queue for us, so that it can be processed for delivery or routing. This failed as Exchange rightly thinks that we are trying to Relay mails, which is a NO NO, and kindly tells us get lost.

Authorised Domains

With the connector validated, and mail flow working, we can move our focus up one more step in the chain, this time adding the source domains SMTP addresses as authorised addresses on our target environment. Doing this will permit us to keep the original email aliases for the source domain on the users we migrate over to our target environment, and if we set it up correctly, ensure that if the alias is not located on the target environment, that exchange will take the message and forward it over our new connector to the source environment, without creating any Non-Delivery notifications.

The second objective is to fix the test we just failed on, and allow the Hub transport to accept the message for the source domain, so to place it into the queues for processing. Let’s get started.

Working on the Exchange Management console, from the Target forest, expand the navigation tree to Microsoft Exchange à Microsoft Exchange On-Premises à Organization Configuration àHub Transport. Select the Accepted Domains tab in the view pane

• From the Actions list under Hub Transport, located and click New Accepted Domain …

  

• The New Accepted Domain wizard should now appear
  
  • In the Name field provide a name for the SMTP domain which we are about to create, for example Decommision.Local.
    
  • In the Accepted Domain text filed, we will enter the qualified SMTP domain we are accepting, e.g. decommission.local.
    
  • The Radio options we are going to select the choice Internal Relay Domain. E-mail is delivered to recipients in this Exchange Organisation or relayed to an email server outside this Exchange organization. User this setting if the domain is shared by this Exchange organization and another messaging system
    
• That’s all there is to it, the wizard will complete its process, and as before show us the PowerShell command which was created based on our selections.

  

From an outside looking in, nothing really will have appeared to have changed after this exercise, but behind the scenes some real cool stuff has occurred. As the transport layer is generally not of concern to the end users the magic of this setting can only be appreciated when we start to actually test the Hub services. In the previous section, we verified from outlook that we had no issues sending mails to the users in the source environment, but as mail flow administrators this is only part of the story, as the last section basically created a new bridge to throw messages off from, which were destined to the source environment, just as if they were been transferred in from the internet.

However – this section has permitted us to connect directly to the Hub SMTP servers, and send emails to users with addresses in the Source environments SMTP domain, without risk of relay, or bounce back. In addition since we choose to go with the option Internal Relay when we created the configuration, exchange will first check to see if a user in this exchange organisation matches the SMTP alias just mailed to, and if no match is found, then instead of sending back a Non-Delivery Report, instead relays the mail on to the original Source Exchange environment, for it to process as if it was the only system to ever see the email.

Therefore, since we made no changes in the source exchange environment, if the address is not matched there, that exchange environment will go ahead and generate its NDR messages! COOL!

Testing the Exchange Configuration

You can make the test as elaborate as you can imagine, however to prove the concept, we will try a simpler test pass

• Append a new @sourcedomain alias to an existing account in the target exchange environment
• Select an existing mail enabled account from the source domain
• Using Telnet, connect to the SMTP server on the Target domain
  • Craft and send a mail addressed to the @sourcedomain aliased account on the target domain
  • Craft and send a mail addressed to the selected account on the source domain

Using SMTP, just as we tried earlier, we are expecting a much better experience

Telnet 172.16.1.31 25 

The server will then acknowledge the connection by offering its banner

220 smtp.diginerve.com Microsoft ESMTP MAIL Service ready at Fri, 14 Dec 2012 10:51:36 -0000 

helo mytestsession.telnet 

250 exchange2010.diginerve.net Hello [172.16.1.181] 

mail from: damian@telnet.cmd 

250 2.1.0 Sender OK 

rcpt to: damian@decommission.local 

Again, the server will check this address, however exchange will now accept the message as we have added the domain decommission.local as authorised

550 2.1.5 Recipient OK 

Great, exchange is happy, now enter data mode so we can compose a message to send

data 

Exchange Acknowledges with instructions

354 Start mail input; end with <CRLF>.<CRLF> 

OK, let’s craft a message and end it with “Enter” “.” “Enter” as suggested by the instructions

Hi this is my super cool first test message 

. 

And, then Exchange Acknowledges with the message ID and that it has being placed in the queue

250 2.6.0 <131be144-98e3-46ba-b005-71ad12cfbfcc@exchange2010.diginerve.net> [InternalId=9438736] Queued mail for delivery 

Success… Well almost, all you now need to do is check that the mail was delivered to the tested alias, and if you can see your new message, you are ready to repeat for all the other test scenarios you have though out.

Comments

So, we now have a working understanding of how mail will flow, and the challenges which we might encounter, but the basics are in place for us to progress to the next stage of configuration, which is Validation end to end!

As I noted in the context of this post, we are not covering address book sync, which might be a problem for example when we move users from the source to the target domain, and a person from the source domain uses a cached address, or if the users reply to an existing thread, where one or more of the recipients are no longer hosted on the source exchange environment.

Make sure you test the configuration well before starting on the next post, and see you soon!!!

In the post we will walk through the steps required to deploy the free Active Directory Migration Toolkit 3.2 which we will utilize for a bulk of the physical work in consolidating the forests. I have assigned a dedicated machine joined to the target forest for the task at hand, so that any colleagues whom wish to assist in the exercise can do so.

As a recap this is the plan for today

1. Target Forest
   
   1. Install the Free Microsoft Active Directory Migration Tools (ADMT) to a Management Station
      
2. Source Forest
   
   1. Optional – Install the ADMT Password Export utility
      

Active Directory Migration Toolkit

Prior to actually installing the toolkit on our designated server, we must first download a copy of the utility to our server from the Microsoft Download Centre. At the time of writing version 3.2 is the current release and can be obtained from the location – http://www.microsoft.com/en-us/download/details.aspx?id=8377

With the tools installer now available, we can begin the exercise. The installation of the ADMT is straight forward

1. Double click the installation file for the ADMT tool, and after a few moments we should be presented with its splash screen

   

2. After reviewing the information, click on Next.
3. The Licence Agreement will be next, sell your soul and select I Agree then click on Next again

   

4. Next up is the Community Experience Improvement Program agreement, we are offered the choice to Join the Customer Experience Improvement Program

   

5. Next the Database Selection page is presented, where we have the option to name a remote SQL Server, SQL instance, or use a local SQL installation. In a lab test I would run with a SQL Server Express installation, but in production I am going to use a SQL Standard or Enterprise server for the database.

   

6. After selecting the Database, the wizard will proceed with checking the Database selection is valid
7. Assuming now additional issues, the Configuring Components page will be presented and the installation will progress

   

8. After a few moments the installer will complete, and the wizard will present a summary of the changes just applied.

   

9. Clicking Finish will terminate the wizard

Once the installation is complete, we can launch the tool from the start menu. The Action menu will offer a list of different migration exercises which we can execute, we will investigate these in due course.

Password Export Server

The next step in the preparation is pretty much optional. The Password Export Server, gets deploy to a system in the Source Forest, and permits us to securely transfer over the current user passwords with their accounts. This can be of a great benefit in making the transition for users quite pain free, however it becomes less important if there are Password Policy mismatches between the environments, or if for some other business reason, some of the employees in the source forest already have an account in the target forest to gain access to resources, prior to us getting this whole process online.

In a company merger this last statement can be quite often true for some senior executives, whom require secure access to services on the target forest well before the migration kicks into action. I will address some of these style accounts as we proceed, as this happens to be the case in my scenario also.

Prior to starting with installing the export server on the source forest, we will first create a token on the target forest, which we will use to sign/trust the passwords which the export server will send over to use, just to prevent any potential unwanted smart guys messing us up.

Export Key File

Launch a shell on our ADMT machine and enter the following command, replacing the <SoruceDomain> with the FQDN name of the domain you are exporting from and <KeyFilePath> with the name of the file we will create.

admt key /option:create /sourcedomain:<SourceDomain> /keyfile:<KeyFilePath> 

This is what the command looks like in my environment and its output

PS> admt key /option:create /sourcedomain:decommission.local /keyfile:passwordexport.key 

The password export server encryption key for domain 'decomission.local' was successfully created and saved to 'C:\Users\dpfadmin\passwordexport.key.pes' 

With this token now created, Transfer it to the designated server in the source forest which will be utilized for installing the Password Exporter.

Install the Password Exporter

On a node in the source forest, we will first download a copy of the Password Exporter from the Microsoft Download Centre. At the time of writing version 3.1 is the current release and can be obtained from the location – http://www.microsoft.com/en-us/download/details.aspx?id=1838

With the installer on the server, we can start the installation

1. Double click the installation file for the Password Migration setup, and after a few moments we should be presented with its splash screen

   

2. The Licence Agreement is next up, again donate your soul and click Next

   

3. The Encryption File page is next to been displayed. On this page use the Browse button to locate the token file we transferred in the last exercise, so that the installer recognises the file will be used to protect the communications with the Migration tool.

   

4. The Start Installation page, verifies we are now ready to install the function

   

5. Installation will begin, and the Updating System page, will present the progress of the operation

   

6. After a few moments, a new dialog will be presented, asking for a service account for the Password Migration utility service. In my environment I am hosting this tool on a Domain Controller in the Source forest, and the default Local System account should be suitable for the service, alternatively we can provide a set of credentials.

   

7. And we are done!

   

8. The installer will ask for a reboot after clicking Finish. Be sure that you plan the reboot at a suitable time, but before you plan to use this feature

    

Summary

And that takes us one more step closer to ready. At this stage we now have the AD migration tools in place, and can now prepare to focus on the steps needed to get the Exchange systems ready.

In the next posting Exchange will be the focus of our endeavour for consolidation.

The concept of article still stands very true in VMM 2012 and 2012 SP1, however there are some additional export features now embedded in the product also which one could leverage. However, as things happen I recently had a requirement of backing out a cluster of nodes from my VMM server with all the VMs intact, to address an issue, before reading the cluster and all its VMs back under VMMs management scope again.

The price of such a move was that I would no longer have any metadata on these VMs once SCVMM re-enrolled them the environment including roles, quotas, clouds, etc. This as you can imagine in a private cloud is not going to cut any mustard, and I was under a very small outage window.

Hence, I took the opportunity to rev the code from “Michael Michael”, and make it VMM 2012 aware.

Now before you start spamming that this code is not sexy PowerShell, I remind you that I was under the gun, and did not have time to refactor into functions etc, and figured that sharing this would save you some time in the case of an emergency also. It might not be pretty, but it works.

Export Metadata

Right, enough waffle, lets dump the data to an XML File, which I am placing in the current folder and calling exportedproperties.xml. In addition I am filtering the hosts which I am exporting from, as I have a LOT of them, and really only need to care about the nodes which need attention. You can remove this filter or update to match your environment by editing the match clause in this section of the command “? {$_.HostName -like
“hyperv*”}”, Replacing
hyperv* with your own wildcard string

#Code to export the metadata of the Virtual Machines on the cluster

get-vm | ? {$_.HostName -like
“hyperv*”} | select hostname, name, vmID, ID, @{Name=‘Custom1′;Expression={$_.CustomProperties[0]}}, @{Name=‘Custom2′;Expression={$_.CustomProperties[1]}},@{Name=‘Custom3′;Expression={$_.CustomProperties[2]}},@{Name=‘Custom4′;Expression={$_.CustomProperties[3]}},@{Name=‘Custom5′;Expression={$_.CustomProperties[4]}},@{Name=‘Custom6′;Expression={$_.CustomProperties[5]}},@{Name=‘Custom7′;Expression={$_.CustomProperties[6]}},@{Name=‘Custom8′;Expression={$_.CustomProperties[7]}},@{Name=‘Custom9′;Expression={$_.CustomProperties[8]}},@{Name=‘Custom10′;Expression={$_.CustomProperties[9]}}, OwnerSid, Tag, CostCenter, SelfServiceUserRole, OperatingSystem, QuotaPoint, UserRole, UserRoleID, Owner, Description, cloud| export-clixml
“exportedproperties.xml”

Import the Metadata

After you have removed and reimported the nodes back into VMM, we need to look at the restore code, you can paste as is, or place it in a file for example RestoreMetadata.PS1. Again, the data file is in my current folder and called exportedproperties.xml

# Import Time

# First import the metadata in question from the exported xml file

$exportedquery
=
Import-Clixml
“exportedproperties.xml”

# Now we have the same query as set above during export time in our hands in a variable called exportedquery

# let’s do some setting of values

# first, get all the VMs that currently exist in the system

$currentVMs
= get-vm | ? {$_.HostName -like
“bil-vm-opsc1*”} | sort-object
Name
-descending

foreach ($curVM
in
$currentVMs)

{

foreach ($oldVM
in
$exportedquery)

{

if ($curVM.Name -eq
$oldVM.Name)

{

if ($curVM.Hostname -eq
$oldVM.Hostname)

{

# we matched the VM based on name and host. we can’t do anything else from here on

$vmname
=
$oldVM.Name

$hostname
=
$oldVM.Hostname

$oldvmid
=
$oldVM.VMID

$curvmid
=
$curVM.VMID

$oldID
=
$oldVM.ID

$curID
=
$curVM.ID

“Matched VM $vmname on $hostname.”

# now set the properties

# User Role Reference for later

$vmmuserrole
= get-vmmuserrole | where {$_.ID -eq
$oldVM.UserRoleID}

# Cost Center Format

if ($oldVM.CostCenter -eq
$null)

{

$costcenter
=
“”

}

Else

{

$costcenter
=
$oldVM.CostCenter

}

# Description Format

if ($oldVM.Description -eq
$null)

{

$description
=
“”

}

else

{

$description
=
$oldVM.Description

}

# Now, the work – Check and set the Cloud First, as any Owner will be wiped in this operation

if ($oldVM.Cloud -eq
$null)

{

$cloud
=
“”

}

else

{

$cloud
= Get-SCCloud -id $oldVM.Cloud.ID

$resultVM
= set-vm -VM $curVM -Cloud $cloud

}

# Now, assuming we have a Cloud dealt with, we can move on with the rest of the metadata

if ($curVM.Owner -eq
“”)

{

if ($oldVM.OwnerSid -eq
“”)

{

$resultVM
= set-vm -VM $curVM -Custom1 $oldVM.Custom1 -Custom2 $oldVM.Custom2 -Custom3 $oldVM.Custom3 -Custom4 $oldVM.Custom4 -Custom5 $oldVM.Custom5 -Custom6 $oldVM.Custom6 -Custom7 $oldVM.Custom7 -Custom8 $oldVM.Custom8 -Custom9 $oldVM.Custom9 -Custom10 $oldVM.Custom10 -CostCenter $costcenter -Tag $oldVM.Tag -Description $description -UserRole $vmmuserrole -QuotaPoint $oldVM.QuotaPoint

}

else

{

$ownersid
=
$oldVM.Owner

“Changing Onwer of VM $vmname to $ownersid”

$resultVM
= set-vm -VM $curVM -Custom1 $oldVM.Custom1 -Custom2 $oldVM.Custom2 -Custom3 $oldVM.Custom3 -Custom4 $oldVM.Custom4 -Custom5 $oldVM.Custom5 -Custom6 $oldVM.Custom6 -Custom7 $oldVM.Custom7 -Custom8 $oldVM.Custom8 -Custom9 $oldVM.Custom9 -Custom10 $oldVM.Custom10 -CostCenter $costcenter -Tag $oldVM.Tag -Owner $ownersid -Description $description -UserRole $vmmuserrole -QuotaPoint $oldVM.QuotaPoint

}

}

}                        

}

}

}

}

Hope this saves you a little time (and hair)

As illustrated in the previous post, I am breaking the job into smaller chunks so that we can take bites from the apple, and measure progress. This post will focus on the preparation of our Active Directory environments.

1. Promote the new DCs into the Target Domain
   
2. Define the Field Offices as Site in the Target AD
   
3. Configure DNS on the Target and Source AD environments to self-resolve
   
4. Update Source DHCP scopes with Target environment DNS suffix search lists
   
5. Optional – Define any special DNS Records in Source Domain
   
   1. KMS SVR Records
      
6. Establish the Forest Transitive Trust between Source and Target environments
   
   1. Repeat Per Source Forest
      
7. Assign Target Forest Admins, as Administrators to the Source Forest
   
   1. Repeat Per Source Forest
      

Promote the new DCs

In my environment I mentioned that I deploy in a hub and spoke configuration, with each field office considered a spoke. My rule of thumb for the deployments is to physically host a domain controller for the target domain in the field office if we have 20 or more users; otherwise the field office will authenticate remotely.

As the final objective in consolidation is to ultimately remove any trace of the original forest and its domains, deploying our target forest domain controllers is a great place to start. This will ensure that the users on these sites have a good login experience, and having a domain controller from the target forest is advised when we need to focus on mailbox migrations, etc. The hardware we will use should meet the minimum specification your organisation has agreed on, and may be an existing server, or a new purchase.

I am not going to cover the process of promoting a server to a domain controller, as if this is not something you are comfortable with then the rest of this project is going to be a real challenge.

Define the AD Sites in the Target Forest

To ensure the AD replication and login experience is optimal for the systems in our field offices, we should ensure that the AD Sites are defined correctly in the target forest. To accomplish this we just need to know what the production IP subnet will be in each of the field offices, the table should act as a guide. If you are unsure of the network details for your field offices, then you will need to co-ordinate with your network engineers, or the IT Team responsible for the source environment.

Define a new AD Site

In the Active Directory Sites and Services snap-in we will proceed to create an entry for every field office that will be hosting a domain controller for the target forest in the final consolidated configuration.

If you have field offices which will not be hosting a local domain controller, then just complete Step 2 in this process and simply assign the IP subnet for that field office, with a field office which will be hosting a domain controller and that is network close (low latency – good bandwidth), as this will direct the clients in that field office to prefer to use the domain controller in the assigned site.

1. Right click on the Sites node, and from the context menu select the option New Site…

   

   1. The New Object – Site dialog will be presented
      1. In the Name text box, supply the name of the new AD Site (Field Office)
      2. In the Site Link list, select the site link you will use (Note, you can change this later, but you must select one now to proceed)

      

   2. After clicking Ok you will be presented with a confirmation dialog

      

2. Back on the Active Directory Sites and Services tree, Right click on the Subnets node, and from the context menu select the option New Subnet…

   

   1. The New Object – Subnet dialog will be presented
      1. In the Prefix text box, supply the network subnet for the new AD Site (Field Office)
      2. In the Site Name list, select the site which this new Subnet will be associated to.

      

      1. Click OK to complete the configuration
3. Back on the Active Directory Sites and Services tree, Right click on the IP node, and from the context menu select the option New Site-Link…

   

   1. The New Object – Site Link dialog will be presented
      1. In the Name text box, supply the Name of the Link (Field Office to Hub)
      2. In the Sites in the Site Link list, select the name of the spoke and hub which will be managed in this link.

      

      1. Click OK to complete the configuration
4. Again on the Active Directory Sites and Services tree, Right click on the newly created site link (eg Miami and Datacenter) node, and from the context menu select the option Properties…

   

   1. The New Object – Site Link dialog will be presented
      1. In the Description text box, supply a description for this site links purpose, e.g. Replication between Spoke and Hub
      2. In the Sites in the Site Link list, ensure the correct sites are listed for this link, and remove or add as required.
      3. In the Cost field, set a replication cost as per your environments configuration. I am using a flat hub and spoke so the default 100 is fine
      4. In the Replicate every field, set the time in minutes between replications. This will depend on your environment conditions. I am setting this for 15 Minutes

      

      1. Click OK to complete the configuration

You will repeat this process or site definitions and IP subnet associations for all your field offices which will be migrated to the new Target environment.

Configure DNS Lookups between Source and Target Forest

An essential element of migration and consolidation is ensuring that resources from both the source and target environments are easily resolvable. This will enable users to start accessing services, while also permitting us to progress to the next stage, the establishment of trusts.

The exercise of actually configuring the DNS servers is quite straightforward, but as per the previous example we should first create a little inventory so that we know what domains we will want to define in each of the respective forests.

Define a new DNS Zone

For each of the domains in our list we will need to repeat the following process. If the domain is listed as being hosted on the target domain, then we will be creating a pointer in the source forest; and vice versa, If the domain is listed on the source forest we will be defining a lookup on the target domain.

Login to a server in the forest you are about to create the point in, using a server which is hosting the DNS services. Typically this will be a Domain Controller, and you will use an Administrative account. To keep processes simple we will make these changes AD integrated, so that all domain controllers, (and thus hopefully indirectly All DNS servers) will be updated with the new pointers. Note that you will need to check the environment to be sure that AD Integrated is enough, and also working!, alternatively you might need to repeat this process on every DNS server in the respective forest.

Start by launching the DNS Server snap in.

1. Expand the tree, until you can see the Forward Lookup Zones branch. Then Right click the node, and select the option New Zone…

   

   1. The New Zone Wizard dialog will be presented, read the welcome, and then click Next
   2. On the Zone Type page, select the option Stub zone and also ensure the option Store the zone in Active Directory is checked, then click on Next

      

   3. On the Active Directory Zone Replication Scope page, select the option replicate data To all DNS servers running on the domain controllers in this forest, then click Next

      

   4. On the Zone Name page, in the Zone name text field, provide the name of the DNS Zone you are defining the pointer for. In my example I am running the wizard on the Target Forest, and setting up the pointer to my source domain which is called decommission.local
      

      

   5. On the Master DNS Servers page, in the Master Servers list type the IP address of a DNS server hosting the domain name entered in the previous page. In my example, the domain was called decommission.local which is hosted on the source domain controller, with an address of 172.16.1.121. You can provide additional hosting DNS server IPs in this list if you desire.

      

   6. The wizard will then present the summary page, before creating the Stub configuration when you click on Finish
   7. 
2. Expanding the Forward Lookup Zones list on the DNS server, we should now see the new Stub with its glue pointing to the source DNS servers.

   

As outlined at the beginning of this section, we will need to repeat this exercise for each domain name hosted on our respective source and target forests

Forest Transitive Trust

An essential element of migration and consolidation is ensuring that resources from both the source and target environments are easily resolvable. This will enable users to start accessing services, while also permitting us to progress to the next stage, the establishment of trusts.

Start by launching the Active Directory Domains and Trusts snap in.

1. Expand the tree, until you can see the domain name, e.g. Diginerve.net node. Then Right click the node, and select the option Properties

   

   1. The domain Properties dialog will be presented, select the Trusts tab, the click on the New Trust… button

      

   2. The New Trust Wizard will then be presented. On the welcome page, just click on Next
   3. The Trust Name page will be presented. In the Name field, type the name of the forest you are creating the trust with. In my example I am working on the Target forest (DigiNerve.net) and will be creating the trust with the Source forest (decommission.local).

      

   4. On the Trust Type we will be creating a Forest trust.
      

      
      

   5. The Direction of Trust page is next to be presented, on this page we will be defining that the new trust to be created will be a Two-Way trust.
      

      
      

   6. Next, the wizard will show the Sides of trust page. This time we will select to create the trust on Both this domain and the specified domain.
      

      
      

   7. On the User Name and Password page, we are requested to provide an administrative account detail for the source domain, as the wizard will use these to create and later validate the trust on source side of the configuration also.

      
      

   8. On the Outgoing Trust Authentication – Local Forest page, we are going to allow the Target Forest user accounts Forest-Wide authentication access to the Source Forest for authentication. This might not be desired or required, so selecting the option Selective authentication will allow you to restrict the accounts which have access on to the source forest.

      

   9. On the Outgoing Trust Authentication – Specified Forest page, we are going to allow the Source Forest user accounts Forest-Wide authentication access to the Target Forest for authentication. Again you might not want this, as the final goal is to have the source users utilize their new Target Forest accounts, however depending on the size of the migration this might be useful for delegating access to the current source accounts access to resources on the target forest.

      

   10. Finally, the Trust Selections Complete page will be presented, with a summary of the selections we have made so far. We can take this opportunity to review the choices prior to creating the trusts.

       

   11. The next page should be Trust Creation Complete assuming everything so far has worked to plan. At this stage we will have trusts established in both forests. Nice work!

       

   12. Before the wizard completes, we have the option to Confirm Outgoing Trust to validate that the trust has being created successfully, this is well worth agreeing to

       

   13. Similarly, we are next offered the option to Confirm Incoming Trust to validate the reverse direction of the trust has also be created without issue

       

   14. After a few moments, the Wizard will run a number of tests on the trusts which were created earlier, to validate that these have being successfully established and working in both directions, to and from the source and target forests.

       

2. Back in the Domain Properties dialog we will now see that the source domain is listed as trusting and trusted with the target domain.

   

3. For sanity, on the Source Forest launching the Domains and Trusts Console, we should also see that the wizard created the second side to the trust also, presenting that the target domain is trusting and trusted.

   

That should have us now configured with inter forest trusting, ready to permit us to delegate permissions to our existing accounts in the target forest, so that we can fully manage the source environment. In addition we did not restrict the accounts allowed to be used over the trust, we can grant access to resources in each respective forest to accounts in the respective forests; this you likely will not want to use, but it is an option if required.

Assign Target Forest

The last step in this batch is to delegate access to accounts in the Target Forest, permissions in the Source Forest. This permits us to simplify the process of migrating Source accounts into the target environment, along with general management techniques.

Grant Administrative Permissions to the Source Forest

Add the Administrator account from the target domain to the Source Forests administrator’s security group

Start by launching the Active Directory Users and Computers snap in.

1. Expand the tree, until you can see the organisation units, e.g. decomission.local node. Then click the node, to list all the objects within the container
   
2. Locate the Administrators group, and right click the object and select the Properties option on the context menu.

   

   1. The Administrators
      Properties dialog will be presented, which will present the list of accounts and groups which are offered this security access. We will add our Target accounts to this group, therefore granting administrative permissions to the source forest domain. Click on the Add… button

      

      1. The Select Users, Contacts, Computers, Service Accounts, or Groups dialog
         will then be presented.

         

      2. In the Enter the object name to select field, type the name of the accounts from the Target Forests domain we will be delegating the access to
      3. Click on the Locations… button, to present the Locations dialog, from which we can select the Target Forest (Diginerve.net) and click OK to accept

         

      4. On the Select Users, Contacts, Computers, Service Accounts, or Groups dialog, click on the button Check Names to have the previously typed name validated, and marked with and underscore.

         

      5. Click on OK to add the new user to members list for the group
   2. The Administrators Properties page will be updated, and the new member will be listed in the dialog. If additional users should be delegated to, then we can repeat this process.
   3. Once you are happy with the list, click to Apply the setting change and click OK to dismiss the dialogue.

      

Final Checks

At this point the two forests are not trusting, and users can be granted privileges to resources in each forest. This effectively we will not really focus on communicating to the users, but use it as a foundation to flow objects between the environments as we conduct the migration. Spending a little time to test was you have completed at this state is a good thing, that will help ensure you are comfortable with basic environments.

In the next posting we will take a look at the free Microsoft Active Directory Migration tool and get it installed to the environment.

While not on stage, with Aidan and Thomas we co-hosted the MVP desk with Claire Smyth.

At the event I also had an opportunity to speak with The Register, and IT Pro \ Cloud Pro regarding my experience to date with this fantastic new operating system.

If you are curious on how these went, or just want to giggle to yourself at my expense, then hit up the links:

IT PRO –

• Windows Server 2012 – Making Your Job Easier

The Register –

• Windows Server 2012 – Under the Bonnet

Enjoy!

Damian

During the last two months hundreds of Hyper-V users have taken the time and effort to participate in The Great Big Hyper-V Survey of 2012 which closed last week. We cannot share any details about the results just yet as we are still counting and analysing the results. We’ll let you know as soon as we can. Promise!

As a stimulus for you we offered a couple of Microsoft Private Cloud Computing books. Because Aidan Finn said he would select a winner for the book based on the responses he got on his own blog and on Twitter, I still have two books to give away. One is offered by co-author Hans Vredevoort and the other by me.

Quoting Hans:

“After checking the retweets (100+) and who had blogged (15) about the survey, I created a list of about 100 people and assigned them a number. I then asked my two youngest sons Laurens and Steven to just pick a random number between 1 and 100. So based on this method I can congratulate Daniel Neumann @neumanndaniel and Dennis Schut @dennisschut with winning a copy of our Microsoft Private Cloud Computing book! I will approach the winners over the course of next week.”

Hans will be signing and sending a copy of the Microsoft Private Cloud Computing to Dennis; while Daniel your copy is making its way from Ireland to you, Congratulations to the both of you. You can look forward to some real light reading for the Christmas break!

Thank you, everyone else for taking the few minutes out of your time to participate in the survey for 2012.

Extra Special request:

I you have already read the book, might we encourage you to write a review and post it on Amazon. We would be very honored!

• Decommission non-required systems and hardware
• Migrate all users to the main Active Directory and Exchange Environments
• Be sure not to cause issues for the users
• Clean up the artefacts left over, once Integrated

As it has been a number of years since I have needed to execute this process, I am going to take the opportunity to get my notes in order, and reflect the environments which are currently in fashion, which in most of my recent experience are typically Windows 2008 servers with Exchange 2010. With a little tuning the process will adopt to addressing both newer and older environments, but until I have the pleasure of needing to go back to the archives, I am going to keep them closed as they should be for now.

My target environment is a Mixed mode Windows 2008R2 / Windows 2012 setup, with the messaging system currently Exchange 2010. I am running a Hub/Spoke setup, so all my attention in the target environment will be on the Hub, as we make adjustments so that we can consolidate and migrate the new source in.

We have a lot to consider, so I am going to break the process into blocks, some of which will need to be completed by my colleagues in different areas; mainly the Networking team responsible to integrating the environment, along with the IT Support representatives who maintain the source environment. The high level list below will serve as a guide to the steps we will address during the course of this exercise.

Setup and Test Cycle

Prerequisites

1. Router tunnels up to the Site with the exchange server
   
2. Clients Minimum requirement
   
   1. Windows XP SP3
      
   2. Office 2007 SP2
      
3. Physically Deploy new Target Domain Controller (DC) to the new Location Field Offices (Site’s)
   
4. List of Users/Computers/Software.
   

Prepare

1. Promote the new DCs into the Target Domain
   
2. Define the Field Offices as Site in the Target AD
   
3. Configure DNS on the Target and Source AD environments to self-resolve
   
4. Update Source DHCP scopes with Target environment DNS suffix search lists
   
5. Optional – Define any special DNS Records in Source Domain
   
   1. KMS SVR Records
      
6. Establish the Forest Transitive Trust between Source and Target environments
   
   1. Repeat Per Source Forest
      
7. Assign Target Forest Admins, as Administrators to the Source Forest
   
   1. Repeat Per Source Forest
      

Active Directory Migration Framework

1. Target Forest
   
   1. Install the Free Microsoft Active Directory Migration Tools (ADMT) to a Management Station
      
2. Source Forest
   
   1. Optional – Install the ADMT Password Export utility
      

Exchange Migration Framework

1. Source Forest
   
   1. Enable the Exchange Server Mail Replication Service Proxy
      
2. Cross Certify Exchange in each forest (Only necessary when using Self Signed Certs)
   
3. Target Forest
   
   1. Add Source Domains to Authorised Domain List
      
   2. Configure Relay to Source Domain (For Mailboxes not hosted on Target)
      

Validation

1. Source forest
   1. Create Test Users and Exchange Mailboxes
   2. Use Virtual Machines (Windows XP / 7 – Office 2007 / Office 2010) as Pseudo Clients for the Test Users
2. Target
   
   1. Use the Exchange script Prepare-MoveRequest.ps1 to move Source Test Accounts to target
      
   2. Use ADMT to migrate both the Password and SID, for the Test account, optionally Enable account
      
   3. (Pending 2.A) Clear User Must Change Password at next logon setting
      
   4. Migrate the Content of the Mailbox Move-MailboxRequest
      
3. Source (VM)
   
   1. Set PRI login scripts for Profile migrations (PRI indicated this might not be required)
      
   2. Outlook Profile Path – Manual / Automatic
      
4. Source (Physical with Dummy Accounts)
   
   1. Set PRI login scripts for Profile migrations (PRI indicated this might not be required)
      
   2. Outlook Profile Path – Manual / Automatic
      

Before we commence with the preparation for our task ahead, we will work with the respective teams to ensure that they have all the pre-requisites addresses, or an action plan in place so that our job will run as smooth as possible.

In the next post, we will being with our preparation work

If you are interested in Windows 2012, check out the articles:

• Private cloud deployment in Windows Server 2012
• How to use IP address management in Windows Server 2012

Fellow MVP and Good friend, Aidan Finn has also contributed

• Hyper-V: plotting a new path to virtualisation

Essentially, the Orchestrator Runbook server forgets that it was indeed a licenced version, and fails back to evaluation mode. Checking the log in Orchestrator a Warning message, is displayed with the message “License Expired” – similar to the sample below.

This is a known issue. When connection to SQL Server is lost and then restored (e.g. SQL Server was restarted) then the Runbook Servers do not fully restore connectivity. One of the connections that may fail is the thread that validates the licensing. Since it cannot retrieve the license from the database, it assumes the product was in evaluation and that the license has expired.

If you experience this issue please make sure you contract Microsoft Product Support by opening a Service Request against this issue; Additional information is available in KB 2768366 – Orchestrator does not reconnect when the SQL server is restarted