www.sbsmigrationtips.com

Just like with the 2003 to 2008 migration there are keys to success

The purpose of this post is to showcase how the migrations from SBS 2003 to SBS 2008 is similar to SBS 2003 to SBS 2011.

If you are already experiencing a setup failure, please check the following post first:
http://blogs.technet.com/b/sbs/archive/2010/08/03/the-ultimate-guide-to-sbs-2008-setup-failures.aspx

A. Read through the migration guide before starting.

Understand what setup will do for you and what you need to do manually.

B. Watch the migration video demos and online training.

SBS 2011 migration video

C. Join an SBS 2008 forum or user group 

Find resources at www.sbsforum.info or www.sbspartnerforum.info or www.sbsgroups.com  

You might find an answer to a question you have, seek advice on your migration plan, or simply see what others have encountered that you might not have considered.

D. Practice a migration yourself in a test environment.

This way you know what to expect. This also allows you to test the hardware and verify you have the necessary BIOS updates and drivers.  Use Storagecraft or Sysinternals Disk2vhd tool and make an image.  Stand up in a virtual server (HyperV, VMware whatever) and do a dry run migration practice.

KNOWN ISSUES – SBS 2003 migrations to SBS 2011

E. On the Source server, run the SBS 2003 BPA.

  • SBS 2003 BPA
  • Resolve any issues reported in the source environment ahead of time.
  • Know that SBS 2003 SP 1 is not the same as Windows 2003 SP 1 or SP 2. See item #4 for an explanation.
F. On the Source server, make sure the Active Directory is healthy.

If there is only one DC, make sure the SYSVOL and NETLOGON shares are present. Also, check the File Replication Service event log to see if it is in Journal Wrap. The event below is an example of what to look for.

Event Type: Error
Event Source: NtFrs
Event ID: 13568
Description:
The File Replication Service has detected that the replica set “DOMAIN SYSTEM
VOLUME (SYSVOL SHARE)” is in JRNL_WRAP_ERROR.

If there are multiple domain controllers in the source environment, force an Active Directory replication between them in Active Directory Sites and Services and verify it is successful.

You can also run the Microsoft IT Environment Health Scanner in the source environment to uncover any AD health issues.  Please note that with the new source tool process you will be blocked from migration if these key issues are not resolved.

Microsoft IT Environment Health Scanner

An unhealthy Active Directory can result in the following setup errors:

  • Windows Small Business Server group policies cannot be configured.
  • Windows Server Update Services cannot be configured.

To fix this, you will need to restore the source server, resolve the AD Health issue(s) and start the migration all over again.

G. On the Source server, check the Primary group of the account you will use to install the SBS 2008 server into the domain.

Make sure the Primary group is set to something besides Domain Admins, Enterprise Admins, or Schema Admins. Otherwise, you may receive the following pop-up error during the migration:

The user account does not have the permission that it needs to join the domain. The user account must be a member of the Domain Admins, Enterprise Admins and Schema Admins groups.

  1. In the properties of the user account, click the Member Of tab, and at the bottom look for the Primary group.
  2. Make sure the Primary group IS NOT : Domain Admins or Enterprise Admins or Schema Admins.
  3. To change it, select Domain Users and click the Set Primary Group button.
H. On the Source server, run the SBS 2011 Migration Preparation Tool.  (it’s on the SBS 2011 media)

This tool performs the following actions:

  1. Installs update 943494 on the SBS 2003 server to extend the migration grace period from 7 to 21 days.
  2. Runs ADPREP to update the forest, domain, and group policy object access control entries.
  3. Changes Exchange 2003 from Mixed mode to Native mode.
  4. Adds the Authenticated Users group to the Pre-Windows 2000 security group.

If Exchange 2003 is not running in Native mode, Exchange Server 2010 will not be installed and you will have to start all over. The error message is Exchange Server 2010 cannot be installed.

If the Authenticated Users group is not a member of the Pre-Windows 2000 security group, then standard users will not be able to access the Remote Web Workplace. The error message they will see is: Cannot connect to the Remote Web Workplace site. To continue, contact your network administrator.

I. In the source domain, check for the existence of an account named Postmaster.

SBS setup tries to create a Distribution List with the SAM account name of Postmaster. If it already exists, you will receive the following errors at the end of setup.

Setup errors due to an existing Postmaster account:

  • The e-mail distribution groups cannot be created.
  • Incoming and outgoing e-mail for Windows SharePoint Services are not configured.
  • Incoming and outgoing e-mail for Windows SharePoint Services are not configured.

To fix this, you will need to restore the source server, rename the Postmaster account and start the migration all over again.  Alternatively you can complete the steps listed in http://technet.microsoft.com/en-us/library/cc626214(WS.10).aspx and http://technet.microsoft.com/en-us/library/cc626120(WS.10).aspx   I think this is now checked by the source server tool, I’ll check on this one and report back.

J. Check Exchange 2003 policies:
  • Existing Mailbox Management policies
  • Duplicate SMTP addresses in recipient policies
  • Invalid SMTP addresses in recipient policies

If any of these are present during the migration to SBS 2008, the setup will finish with the following errors:

Setup errors due to mailbox management policies or duplicate/invalid SMTP addresses in recipient policies:

  • The Exchange E-mail address policy cannot be configured.
  • Incoming and outgoing e-mail for Windows SharePoint Services are not configured.
  • Incoming and outgoing e-mail for Windows SharePoint Services are not configured.

How to check for Mailbox Management policies:

If you have Exchange 2003 or Exchange 2000 recipient policies that are ONLY Mailbox Manager policies and do not define e-mail addresses (they do not have an E-mail Addresses (Policy) tab), perform the following steps to delete the policies:

  1. In Exchange System Manager, expand Recipients, and then select Recipient Policies.
  2. To verify that a policy is only a Mailbox Manager policy, right-click the policy, and then select Properties. The Properties page must not have an E-Mail Addresses (Policy) tab.
  3. To delete the policy, right-click the policy, and then select Delete. Click OK and then click Yes.

If you have Exchange 2003 or Exchange 2000 policies that are BOTH E-mail Addresses and Mailbox Manager policies (they have both the Mailbox Manager Settings (Policy) tab and the E-mail Addresses (Policy) tab), perform the following steps to remove the mailbox manager portion of the policy:

  1. In Exchange System Manager, expand Recipients, and then select Recipient Policies.
  2. Right-click the policy, and then select Change property pages.
  3. Clear the Mailbox Manager Settings check box, and then click OK.

How to check for duplicate/invalid SMTP addresses in recipient policies:

  1. In Exchange System Manager, expand Recipients, and then select Recipient Policies.
  2. Right-click the policy, and then select E-Mail Addresses (Policy) tab.
  3. Inspect the SMTP Addresses for any that are unchecked. If you find any, place a check in the box or remove that address.
  4. Inspect the SMTP Addresses for any that have an IP address. For instance, @192.168.1.1. If you find any, remove those addresses that contain an IP address.
  5. Click OK.

Again, I think that this is auto checked by the source server tool, I’ll double check and report back.

Recovery option 1:

Restore the source domain to before the migration, take corrective actions for any of the known causes, and start the migration over.

Recovery option 2:

Take corrective actions for any of the known causes. Complete the lengthy manual repair steps for each of the received errors as provided in the SBS 2008 Tech Library.

K. When you create the answer file for the migration, leave the Certificate authority name blank.

At the very least, do not use remote.domain.com or any periods in the name. For more information, see this.

L. On the SBS 2011 server, after setup is done, run the SBS 2011 BPA.

www.sbsbpa.com

M. Disabling IPv6 is not necessary in SBS 2011.

If you think you want to disable IPv6 in SBS 2011 or any Vista/Windows 2008/R2 product for that matter, you must do so in the registry. Unchecking IPv6 in the properties of the nic will cause you grief. For more information on how to do this, read here.

N. Remove the Last Legacy Exchange Server from an Organization

Before you are ready to demote and remove the source SBS 2003 server from the network, make sure you follow the steps to Remove the Last Legacy Exchange Server from an Organization BEFORE you uninstall Exchange 2003 from the SBS 2003 server. The steps are located here.

O. Disable WSUS on Source domain prior to migration

If you have a deadline set for a Windows 2008 or R2 update in WSUS that is past-due, your SBS 2011 setup can fail when the update is automatically installed and the SBS 2011 server is rebooted.  Deadlines are not automatically set in SBS 2003 but can be set by the Admin through the native WSUS console.  We recommend disabling WSUS for the duration of the migration.

P. On the Source Server run the Exchange 2007 Readiness Check in the Exchange BPA

Q. Make sure the Admin account you are using for the migration has a STRONG password

Strong passwords must meet the following minimum requirements:

  • Passwords cannot contain the user’s account name or parts of the user’s full name that exceed two consecutive characters.
  • Passwords must be at least six characters in length.
  • Passwords must contain characters from three of the following four categories:
    • English uppercase characters (A through Z).
    • English lowercase characters (a through z).
    • Base 10 digits (0 through 9).
    • Non-alphabetic characters (for example, !, $, #, %).

R. SBS 2003 must be on a class C subnet (subnet mask of 255.255.255.0).

Since SBS 2008 only supports a Class C Subnet if your SBS 2003 server is not in a Class C subnet it can cause communication problems during setup.  Please see the following post for supported network topologies in SBS 2008: http://blogs.technet.com/sbs/archive/2008/09/16/sbs-2008-supported-networking-topology.aspx

S. Authoritative Restores of Active Directory

There has been a few cases where migrations fail on domains where customers have previously performed an authoritative restore of their 2003 domain environment.  Authoritative restores can cause the SBS migration to fail by invalidating Kerberos tickets which will cause the Exchange install to fail.  If you have performed an authoritative restore or you are not sure if an authoritative restore has ever been done please apply the following hotfix on all 2003 domain controllers in your environment before starting the migration.  This will be flagged by the SBS 2003 BPA.

939820  Events 1925, 1006, 1645, 1055, 40961 on a Windows Server 2008-based domain controller or error message: “No authority could be contacted for authentication” when you use Remote Desktop Connection

 

13 Responses to SBS 2011 migration keys to success

  1. Lyle Epstein says:

    Anyone have a link to the offical migration guide in Word format?

  2. bradley says:

    Haven’t seen it in Word.

  3. Luisa Padill says:

    thanks for sharing the information.
    is there any web migration guide tool in PHP 5.2?

  4. Mike says:

    Is there a difference migrating from Server 2003 (non-SBS) with exchange 2003 to SBS2011?

  5. Greg says:

    Any best guesses on typical time it takes to complete this migration?

  6. Greg says:

    Any best guesses on typical time it takes to complete this migration?

  7. bradley says:

    Depends on how much data and how much data in mailboxes.

    Some of the tasks you can start and leave for overnight.

    Mine at the office took about 2 to 2.5 days for the SBS 2008 migration but that’s not 24 hours, but about 10 hours-ish per day.

  8. trevor says:

    any advice for the error “active directory replication is taking longer than expected”? getting this error over and over and the only stuff I see is for 2008 migration

  9. bradley says:

    Are you migrating from SBS 2003? The guidance is the same. Run the sbs 2003 and do that hotfix on the SBS 2003 server that’s flagged there for non authoritative restores.

  10. Don says:

    Can you revert to a class B network after the migration? We use different 172.16 segments for e.g. phone & communications servers and application & desktop computer equipment. Devices on different segments may rely on time or DNS services from the SBS server.

  11. Henri says:

    I missed this step:

    N. Remove the Last Legacy Exchange Server from an Organization

    and I’ve already demoted the SBS2003 server.
    Now what do I do?

  12. bradley says:

    Ping Jeff Middleton at ycst-at-sbsmigration.com You need to manually pick out the Exchange 2003 stuff from the SBS 2008 or SBS 2011.

  13. amillis says:

    In our test run we are getting the 2 errors in section ‘I’ listed above:

    The e-mail distribution groups cannot be created.
    Incoming and outgoing e-mail for Windows SharePoint Services are not configured.
    (only one of the second message, there are 2 listed in section I).

    We did not have a postmaster account, but did have the email address ‘postmaster@ourdomains.tld’ aliased on another account. The pre-migration scan didn’t pick this up and happily continued. I re-created the test environment for another pass through, this time removing the postmaster email aliases off the account ahead of time. I verified on the sbs2k3 system with ldifde that there’s no hint of ‘postmaster’ left.
    The installation completes with the same two warnings still. I found this in the SBSSetup log:

    [4232] 110308.003134.2885: Messaging: MessagingTaskException: The proxy address “smtp:abuse@ourdomain.LOCAL” is already being used by “ourdomain.local/MyBusiness/Distribution Groups/abuse”. Please choose another proxy address. – Error# (80006)
    [4232] 110308.003134.3188: Task: CreateMailDisributionGroups: failed with exception Microsoft.WindowsServerSolutions.Messaging.Management.MessagingTaskException: The proxy address “smtp:abuse@OURDOMAIN.LOCAL” is already being used by “ourdomain.local/MyBusiness/Distribution Groups/abuse”. Please choose another proxy address.

    It appears as if having ‘abuse@’ pre-existing in the sbs2k3 environment will break some of the setup like ‘postmaster@’.

    Sure would have been nice for it to check for it during the premigration scan. I’m about to reset the environment for another pass to be sure this clears the error.