Thursday, March 29, 2012

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.

Monday, March 26, 2012

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:

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

Make a note of all the folder names under the c:\ClusterStorage namespace and how they map to your CSV’s

Evict one of your nodes from the existing cluster

Remove the Failover clustering role from the evicted node and join it to the new domain.

Add the Failover Cluster role back once the node is added to the new domain

Create a new cluster on the node in the new domain

Shut down all the VM’s on the CSV that will be moved to the new cluster

Delete the VM from Failover Cluster Manager (FCM). Do *NOT* delete the VM from Hyper-V Manager

Take the CSV offline and remove it

Take the storage volume hosting the CSV offline and delete the disk from FCM

Ensure that the LUN is not presented to nodes in the old cluster anymore

Present the LUN to the host in the new cluster

Open up Computer Management on a node in the new cluster, go to Storage and re-scan for new storage

Bring the new disk online, taking care to not initialise it

In FCM, go to Storage – Add Disk – Select the disk you brought on previously

Tuesday, March 13, 2012

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)

I had to revoke my existing certificate via GoDaddy’s Control Panel

Open the EMC and select the Server Configuration node

Click on a free space in the Exchange Certificates tab and select New Exchange Certificate

Monday, March 12, 2012

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:

Open DNS Management on a DNS server in olddomain.local

Expand Forward Lookup Zones under DNS

Right-click Forward Lookup Zones and select New Zone

The New Zone Wizard will appear. Click Next

Select Stub Zone and click Next

Select the option to store the Zone in AD

Choose to replicate the zone to all domain controllers in olddomain.local

Name the zone newdomain.local and click Next

Add the IP of an DNS server authoritative for the newdomain.local domain. Select the option to “Use the above servers to create…”

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.

Open Active Directory Domains and Trusts in olddomain.local

Right-click – Properties on the domain name for the forest root domain for which you want to create a trust

On the Trusts tab, click New Trust, then click Next

Type the DNS name (newdomain.local) of the forest root domain of the other domain. Click Next

Select Forest on the Trust Type screen. Click Next

Select Two-Way when prompted for the Direction of Trust

Select “Both this domain and the specified domain” when prompted for the Sides of Trust. Click Next

Enter the credentials for the newdomain.local domain. Click Next

Select Forest-wide authentication. Click Next

Confirm the trust (specify credentials when prompted)

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

Friday, March 9, 2012

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.

Use Prepare-MoveRequest.ps1 to create Mail Enabled Users (MEU’s) in the target domain

Configure Exchange servers in the source and target domains to operate within a shared address space

Use ADMT to migrate user accounts to the target domain

Use ADMT to re-ACL resources

Use ADMT to migrate computer accounts to the target domain

Move mailboxes to the Exchange server in the target domain

Decommission source Exchange server

Use ADMT to remove old ACL’s from resources

Use ADMT to migrate servers to the target domain

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.

About Me

About This Blog

This blog serves 2 purposes. Firstly, I want to share information with other IT pros about the technologies we work with and how to solve problems we often face. I work with technologies from the desktop to the data center, Active Directory, System Center, Exchange, Hyper-V, VMware, Networking and Storage.

Less altruistically, I use my blog as a reference. There's so much to learn and remember in our field that it's impossible to keep up. By blogging, I have a notebook that I can access from anywhere. It has made me look much smarter than I probably am on many occasions.