Thursday, March 29, 2012

Increasing the amount of concurrent mailbox moves in Exchange 2010

Exchange 2010, by default, allows you to do 2 concurrent mailbox moves.  This is a rather conservative approach, in this age of 10Gb Ethernet and super-fast SAN storage.  Fortunately Microsoft has provided a mechanism whereby we can increase the amount of concurrent moves allowed.

Said mechanism involves editing the MSExchangeMailboReplication.exe.config file, which resides under the C:\Program Files\Microsoft\Exchange Server\V14\Bin\ foler.

These are the changes you need to make if you’d want to allow 20 concurrent moves:

  • MaxActiveMovesPerSourceMDB = “20"
  • MaxActiveMovesPerTargetMDB = “20"
  • MaxActiveMovesPerTargetServer = “20"

Once you’ve made the changes you will also need to restart the Microsoft Exchange Replication service.  Lastly – all the above needs to be done on the target server.

Quick and easy, just the way I like it!

Monday, March 26, 2012

Moving a Hyper-V cluster to a new AD Domain

I recently had to move a production Hyper-V cluster to a new AD domain, as part of a forest migration project I am busy with.  Microsoft has a KB Article on the procedure, but it only applies to Windows Server 2003 and below, and then only in a non-production environment.  So a migration is out, I had to find a way to move all the nodes into a new cluster, with minimal disruption to the VM’s uptime.  This process assumes the new cluster will run on your existing hardware.  Here is what I did:

  1. Make a list of your VM’s per Cluster Shared Volume (CSV).  We won’t be able to share our CSV’s across clusters so our move process will be CSV driven
  2. Make a note of all the folder names under the c:\ClusterStorage namespace and how they map to your CSV’s
  3. Evict one of your nodes from the existing cluster
  4. Remove the Failover clustering role from the evicted node and join it to the new domain.
  5. Add the Failover Cluster role back once the node is added to the new domain
  6. Create a new cluster on the node in the new domain
  7. Shut down all the VM’s on the CSV that will be moved to the new cluster
  8. Delete the VM from Failover Cluster Manager (FCM).  Do *NOT* delete the VM from Hyper-V Manager
  9. Take the CSV offline and remove it
  10. Take the storage volume hosting the CSV offline and delete the disk from FCM
  11. Ensure that the LUN is not presented to nodes in the old cluster anymore
  12. Present the LUN to the host in the new cluster
  13. Open up Computer Management on a node in the new cluster, go to Storage and re-scan for new storage
  14. Bring the new disk online, taking care to not initialise it
  15. In FCM, go to Storage – Add Disk – Select the disk you brought on previously
  16. Go to Cluster Shared Volumes – Add Storage – select the storage added previously
  17. Rename the new folder under the c:\ClusterStorage namespace back to what it was previously called
  18. Open Hyper-V Manager, the VM status should change from Critical to Normal
  19. Make the VM’s highly available using FCM
  20. Start the VM’s
  21. Rinse and repeat for your other CSV’s

You should also evict nodes and join them to the new cluster as soon as your usage requirements allows you to do so.

Tuesday, March 13, 2012

Changing the OWA / ActiveSync / Outlook Anywhere certificate on TMG 2010 when migrating to a new Exchange Server

I find myself in the middle of an AD and Exchange Forest migration, and one of the tasks that came up is moving the certificates from the old/source Exchange 2010 server to the new destination Exchange 2010 server.  Here is how I went about moving the certificate

Request a new Certificate from your Certificate Authority (CA)

  1. I had to revoke my existing certificate via GoDaddy’s Control Panel
  2. Open the EMC and select the Server Configuration node
  3. Click on a free space in the Exchange Certificates tab and select New Exchange Certificate
  4. Enter a friendly name for your certificate , i.e. GoDaddy Exchange Cert, click Next
  5. Select the appropriate options here, in my case it’s the following:
    • Client Access Server (Outlook Web Access)
    • Client Access Server (Exchange ActiveSync)
    • Client Access Server (Web Services, Outlook Anywhere, Autodiscover)
  6. Click Next,taking care to follow the SAN / UCC Certificate guidelines I mentioned in a previous article
  7. Enter your Organization info and click Browse to select a location to save your certificate request.  Click Next
  8. Review the summary screen and click New and Finish
  9. Submit your Certificate request to your CA and download your certificates

Install the Certificate on your new Exchange 2010 Server

  1. Open the EMC and select the Server Configuration node
  2. Right-click your Certificate’s friendly name and select Complete Pending Request
  3. Browse to your downloaded certificate and click the Complete button
  4. Still in the EMC, right-click your certificate’s friendly name and choose to Assign Services to Certificate
  5. Keep to the defaults, acknowledging any prompt to overwrite an existing SMTP certificate
  6. Click Finish to complete the process

Import your new Certificate on the TMG 2010 Server

  1. Open the EMC and select the Server Configuration node
  2. Right-click your Certificate’s friendly name and select Export Exchange Certificate
  3. Select a location to save it and click Export
  4. Copy the exported certificate to your TMG server
  5. Go Start – Run – MMC
    • Click File – Add/Remove Snap-in – Certificates
    • Click Add, select Computer Account and click Next
    • Select Local Computer – Finish – and click OK
  6. Right-click the  Personal – Certificates node and click Import
  7. Click Next and browse to your saved certificate, enter your password.
  8. Click Next and Finish to exit the import wizard

Add the Certificate to your TMG listener

  1. Open up TMG Management
  2. Navigate to the Firewall Policy node
  3. Go to the Toolbox pane on the right-hand side and select Network Objects – Web Listeners – your Exchange listener
  4. Go to the Certificates tab – click Select Certificate – Select your imported certificate and apply your changes
  5. Click Start – Run - notepad %systemroot%\system32\drivers\etc\hosts
  6. Replace the old Exchange server’s IP with the new server’s internal IP, ensuring you have entries for your certificate’s common name and Autodiscover hostname

Monday, March 12, 2012

AD and Exchange Forest Migration (Part II)

Part 2 of this series of posts will deal with the basics, like making sure name resolution works, setting up the necessary trusts and configuring SID History and SID Filtering.

Name Resolution

First things first. We’ll need to resolve names across our two forests, and that means setting up DNS.  In my case we set up Stub Zones pointing to the separate domains, i.e. the DNS server in the olddomain.local domain had a stub zone pointing to the newdomain.local domain, and vice versa.  We set it up like so:

  1. Open DNS Management on a DNS server in olddomain.local
  2. Expand Forward Lookup Zones under DNS
  3. Right-click Forward Lookup Zones and select New Zone
  4. The New Zone Wizard will appear.  Click Next
  5. Select Stub Zone and click Next
  6. Select the option to store the Zone in AD
  7. Choose to replicate the zone to all domain controllers in olddomain.local
  8. Name the zone newdomain.local and click Next
  9. Add the IP of an DNS server authoritative for the newdomain.local domain.  Select the option to “Use the above servers to create…”
  10. Verify your settings and click Finish to exit the wizard

In order to create a trust we will need to do the opposite on a DNS server in newdomain.local.  Once done name resolution will be working across both forests.

Setting up a Forest Trust

Now we’re getting somewhere – time to set up the trust.  Ensure you have administrative credentials in both domains.

  1. Open Active Directory Domains and Trusts in olddomain.local
  2. Right-click – Properties on the domain name for the forest root domain for which you want to create a trust
  3. On the Trusts tab, click New Trust, then click Next
  4. Type the DNS name (newdomain.local) of the forest root domain of the other domain.  Click Next
  5. Select Forest on the Trust Type screen.  Click Next
  6. Select Two-Way when prompted for the Direction of Trust
  7. Select “Both this domain and the specified domain” when prompted for the Sides of Trust.  Click Next
  8. Enter the credentials for the newdomain.local domain.  Click Next
  9. Select Forest-wide authentication.  Click Next
  10. Confirm the trust (specify credentials when prompted)
  11. Click Finish to exit the Wizard

Both forests now trusts each other.  Strictly speaking this is more permissive than what is required.  I always do it this way to prevent chasing down possible issues and because I try and keep the co-existence phases as short as possible.

Enabling SID History / Disabling SID Filtering

This is the final part of laying the groundwork.  Security principals in Active Directory have an attribute, called SID history, to which domain administrators can add users’ old security identifiers (SIDs). This is useful in our case because we then do not need to modify access control lists (ACLs) on large numbers of resources and users can use their old SIDs to access resources.  We do it like so (all commands to be entered on one line from a DC in either domain):

  1. netdom trust newdomain.local /domain:olddomain.local /twoway /enablesidhistory:Yes /usero: olddomain\administrator /passwordo:*******
  2. netdom trust olddomain.local /domain:newdomain.local /twoway /enablesidhistory:Yes /usero: newdomain\administrator /passwordo:*******

This enabled SID history.  Now we disable SID Filtering

  1. netdom trust olddomain.local /domain:newdomain.local /twoway /quarantine:no /usero:olddomain\administrator /passwordo:*******
  2. netdom trust newdomain.local /domain:olddomain.local /twoway /quarantine:no /usero:newdomain\administrator /passwordo:********

We have now laid the foundation for our migration.  In the next post we will have a look at  a couple of things, including installing ADMT and configuring the Password Export Server.

Friday, March 9, 2012

AD and Exchange Forest Migration (Part I)

I’m currently in the middle of a big and relatively complex forest migration.  I’ve found that while there’s a ton of documentation on the subject, a lot of it is way too complex for 90% of engagements and the rest is very spotty.  Thus I’ve set out to document my processes in a simple and to the point way, keeping in mind that this is what works for me, in this specific client’s environment.  Caveat Emptor.

Current Environment

Source:

The source domain is a standalone forest, with a two-way forest trust to the target domain.

Source Domain Name:  olddomain.local
Domain Functional Level: Windows Server 2008 R2 domain level
Mode: Native
Forest Level: Windows Server 2008 R2 domain level
SMTP Address Space: company.com

Target:

The target domain is a child domain contained in a existing forest.

Target Domain Name: newdomain.local
Domain Functional Level: Windows Server 2008 R2 domain level
Mode: Native
Forest Level: Windows Server 2008 R2 domain level
SMTP Address Space: company.com

High-Level Overview

  1. Clean up source domain by deleting unused accounts, mailboxes etc.
  2. Setting up Name Resolution (DNS) to allow us to create a trust
  3. Create a Two-Way Forest Trust between the source and target domains
  4. Enable SID History and disable SID Filtering
  5. Install the Active Directory Migration Tool (ADMT)
  6. Install the ADMT Password Export Server (PES)
  7. Use Prepare-MoveRequest.ps1 to create Mail Enabled Users (MEU’s) in the target domain
  8. Configure Exchange servers in the source and target domains to operate within a shared address space
  9. Use ADMT to migrate user accounts to the target domain
  10. Use ADMT to re-ACL resources
  11. Use ADMT to migrate computer accounts to the target domain
  12. Move mailboxes to the Exchange server in the target domain
  13. Decommission source Exchange server
  14. Use ADMT to remove old ACL’s from resources
  15. Use ADMT to migrate servers to the target domain
  16. Decommission old servers, domain and forest

I will use the next series of blog posts to document all the above steps in detail.  As I said, I have been unable to find a single authoritative source for the process, so I aim to make my life easier the next time I’m faced with this challenge.  Hopefully I also save someone else some time and effort.

I want to conclude by saying that even though my documentation might suit your environment to a T, it is imperative that you lab the living daylights out of your processes.  Also, make sure you understand what each step does, and have a rollback procedure in place.