Migrating CIFS Shares to a new NetApp Filer

What better way to kick off the festive season than a with a storage migration (only being slightly ironic!).  A customer uses their existing NetApp kit to provide block storage to vSphere hosts and CIFS shares to Windows clients and they wanted me to do a swap out upgrade.  Migrating the vSphere data is a cinch nowadays, what with Storage vMotion and all, so I’ll just document the CIFS stuff.

1. First you’ll need to setup a SnapMirror relationship of the CIFS volume between the source and destination filers (no faffing around with robocopy and the like)
2. Make a backup copy of the /etc/cifsconfig_shares.cfg file
3. Execute cifs terminate on the source filer (downtime starts here)
4. Update (quiesce if necessary) and break the SnapMirror relationship
5. Take the source filer offline
6. Assign the source filer’s IP to the new filer
7. Reset the source filer’s account in Active Directory (if applicable)
8. Execute cifs setup on the new filer
1. It goes without saying that you will assign the source filer’s hostname to the destination filer, as well as join it to the AD (assuming the source filer was joined)
9. Execute cifs terminate on the destination filer and replace the cifsconfig_shares.cfg with the backup copy you made in step 2
10. Execute cifs restart on the destination filer
11. Test client access

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.

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.