I meant to blog this yesterday but I was busy with my MiniCooper group last night.  This morning I’m eating a bagel and creme cheese with tea on an Amtrak heading towards Sacramento and the next stop on the SMBMVPtour (see www.smbmvptour.com ) . 

By now hopefully you’ve already read these two blog posts on the SBSblog (http://blogs.technet.com/sbs ) I’m about to blog about, but if you haven’t, go do so now….

Read them?  Okay now I’ll flesh them out a bit more.  This first one is about how there’s now an update for the migration tool.  You know how I jump up and down and tell you guys never ever ever ever say yes to updates during the install because not only does it add time to your migration, but it adds potential for change and patches and this is the time you want to limit change and patching?  Okay so there’s one time of the migration process I DO want you to install updates and it’s right here at this point of the migration tool.  When you install the tool on your sbs 2003 there’s a box there to say yes to go check for updates.  PLEASE PLEASE PLEASE get updates on this ONE spot.  Because they’ve added new rules to ensure that Exchange won’t barf as much. 


Why does Exchange barf? 

Rule 2

This update adds the following rule to check whether the Allow inheritable permissions option is enabled for the mailbox store and for the public folder in Active Directory:

Rule: Access control list (ACL) inheritance is blocked
Severity: Error
Description: Exchange setup requires that Access Control List (ACL) inheritance be enabled. Go to http://technet.microsoft.com/en-us/library/bb643112(EXCHG.80).aspx for more details.

I’ve seen quite a few Exchange barfages due to this one issue. 

When Exchange barfs while one can manually install, end up with an eval version of Exchange and then find the kb to make it not eval, I’m still more comfy in telling folks to do a system state restore on the sbs 2003 and start the migration process over. 

Also be aware of a known issue you might hit Sub Rule 5 from the update (KB 2578426) if your _MSDCS zone is not a forward lookup zone delegated from your primary domain zone as documented in the blog:


Bottom line, you want updates right here at this one spot.

Spotted this in the partner forum….

Got Public Folder replication issues?  Check this post out:

To troubleshoot the issue, I suggest you perform the following steps:

1. On Exchange 2003 server, open Exchange System Manager->expand “Administrative Group”->”Servers”->”ServerName”->”storage group name”->right click the mailbox store and click “Properties”->go to “Diagnostics logging” tab->in the left panel, expand “MSExchangeIS” and click “Public Folder”->in the right panel, select the following items and make sure the logging level is set to “Maximum”:

 Replication Incoming message, Replication Outgoing message, Replciation AD Updates, Non-Delivery reports, Replication Backfill, Replication General.

 2. On Exchange 2010 server, open Exchange Management Shell and run the following commands to set the event log level:

 Set-EventLogLevel Identity “MSExchangeIS\9001 Public\Replication Incoming Messages” -Level Expert

Set-EventLogLevel Identity “MSExchangeIS\9001 Public\Replication Outgoing Messages” -Level Expert

Set-EventLogLevel Identity “MSExchangeIS\9001 Public\Replication DS Updates” -Level Expert

Set-EventLogLevel Identity “MSExchangeIS\9001 Public\Replication Backfill” -Level Expert

Set-EventLogLevel Identity “MSExchangeIS\9001 Public\Replication NDRs” -Level Expert

Set-EventLogLevel Identity “MSExchangeIS\9001 Public\Replication Genera” -Level Expert


3. In SBS 2011 Exchange Management Shell, navigate to “C:\Program Files\Microsoft\Exchange Server\V14\Scripts” and run the following two commands: 

.\AddReplicaToPFRecursive.ps1 -TopPublicFolder “\” -ServerToAdd Exchange2010ServerName

.\AddReplicaToPFRecursive.ps1 -TopPublicFolder “\NON_IPM_SUBTREE” -ServerToAdd Exchange2010ServerName 

Please wait and monitor the issue. If the issues persists, please collect application log on both Exchange 2003 and Exchange 2010:

If even Public Folder hierarchy doesn’t replicate to SBS 2011, it is probably the mail flow has some problems or the SMTP address of SBS 2011 public folder database is not correct. Please perform the following steps to further troubleshoot the issue: 

1. Log on Exchange 2010 server, click “Start”->click “Run” and type “adsiedit.msc”

2. Expand the “CN=Configuration,DC=[Domain_Name],DC=com”-> ” CN=Services”->”CN=Microsoft Exchange”->”CN=<organization name>”->”CN=Administrative Groups”->”CN=Exchange Administrative Group (FYDIBOHF23SPDLT)”->”CN=Databases”

3. Right click the Public Folder database object and click “Properties”->Make sure the following attribute is set correctly:

ProxyAddresses: “SMTP:PFDatabaseName@domain.com”  (For example: the database name is PFDB1, the SMTP address is “SMTP:PFDB1@domain.com“)

Mail: “PFDatabaseName@domain.com

mailNichName: “PFDatabaseName” 

4. Please try to send an e-mail from a user whose mailbox is on SBS 2003 to SBS 2011 user and check whether the recipient is able to receive the e-mail.

 P.S. also ! Remove AV for Exchange on the source. !

Check the following for other known issues:


So you go to do a SBS 2003 to 2011 migration and you can’t get the MBCA to run?


Uninstall it and reinstall it.  Seriously.  I’ve seen situations where the MBCA doesn’t do it’s thing for whatever reason and uninstalling and reinstalling does the trick.

Strange but true. 

https://skydrive.live.com/#!/view.aspx?cid=C756C44362CD94AD&resid=C756C44362CD94AD%21808  Other weird tips in that document.

SBS 2003 to SBS 2011 – Run the Migration Preparation Tool on the Source Server Failed (X) on Schema Update:

So during the migration from SBS 2003 to SBS 2011 the migration tool failed on the schema update…

Suggested actions include:

Based on the research, we found this issue maybe caused by the factors below:

1. The value for the SYSVOL setting under the NETLOGON\Parameters section of the registry is not populated or refers to an invalid location.

2. The reparse point between %windir%\sysvol\sysvol\domain and %windir%\sysvol\sysvol\<FQDN> is invalid.

3. The Default Domain or Default Domain Controller policies are missing from the SYSVOL folder or were not defined with the default GUID number.

I would like to provide some suggestions below to narrow down this issue:

Suggestion 1: Verify the SYSVOL registry key exists and points to the current sysvol path


1. Press the Windows + R keys.

2. Type REGEDIT in the RUN field and click OK.

3. Locate the following registry value:


Value Name: SYSVOL

Value Type: REG_SZ

Value Data: <path to current sysvol location>

4. A typical registry value for a SYSVOL folder located in the default path is C:\Windows\SYSVOL\sysvol.

5. If the SYSVOL registry setting or its value is missing, manually add or correct it in REGEDIT or run:

reg add HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters /V SysVol /T REG_SZ /D “<valid drive letter:>\<valid parent folder>\sysvol\sysvol” /F

Suggestion 2: Verify the file system junction is correct


There are two reparse points in the SYSVOL tree which must be correctly defined.

A DIR command against the path “<drive>:\windows\sysvol\sysvol\domain” (where “domain” is the literal word “domain”) is not sufficient to validate the reparse path. Instead the LINKD command-line tool must be used. LINKD is available as part of the Windows Server 2003 Resource Kit Tools.

Windows Server 2003 Resource Kit Tools


The LINKD syntax to validate the reparse points for a SYSVOL located at C:\Windows\SYSVOL in the CONTOSO.COM domain is:

linkd %systemroot%\sysvol\sysvol\contoso.com


linkd %systemroot%\sysvol\Staging Areas\contoso.com

If those commands fail to return a valid reparse point (i.e. return a blank value or invalid path), the reparse point must be redefined. The LINKD syntax to define the reparse points for a SYVOL located at C:\Windows\SYSVOL in the CONTOSO.COM domain would be:

linkd c:\windows\sysvol\sysvol\contoso.com c:\windows\sysvol\domain


linkd c:\windows\\sysvol\Staging Areas\contoso.com c:\windows\sysvol\staging\domain

Suggestion 3: Verify the Default Domain and Domain Controllers policies exist in the SYSVOL folder and have the correct GUID


From the console of the infrastructure master where you are running ADPREP /DOMAINPREP verify that:

· The SYSVOL contains two subdirectories, POLICIES and SCRIPTS.

· Default Domain and Default Domain Controllers policies exist under the POLICIES folder.

· The Default Domain policy has been defined with the GUID “{31B2F340-016D-11D2-945F-00C04FB984F9}”.

· The Default Domain Controllers policy has been defined with the GUID “{6AC1786C-016F-11D2-945F-00C04fB984F9}”.

If the SYSVOL folder is empty, or the POLICIES and SCRIPTS folders are missing, resolve that condition.

If the Default Domain or Domain Controller policies exist but lack the default 31B.. and 6AC… GUIDs, recreate them with DCGPOFIX.

As I’m blogging some of these migration errors and resolutions from the partner forum I don’t want people to get the idea that every migration hits a brick wall.

No one runs into the partner forum and yells “I can print!”  or “I had no issues today!”.  It is after all THE break fix partner forum you know.

And if anyone pings me and says “I can’t access that link — dudes and dudettes if you sell your services to clients and perform IT services you SHOULD have access to that link.  Go to the Microsoft partner page, sign up and go to the support tab.  From there follow the instructions to sign up for the partner forum where you get support from a Microsoft Engineer.

Thread Title SBS2003 to SBS2011 fails DCPROMO exit code 19 name change pending reboot required
Started by: DriveSlayer


Thanks all for your inputs. I’m glad to hear that the issue has been solved. We really appreciate all your efforts on this issue. I believe partners who may visit this thread in the future will benefit from your sharing.

SBS 2003 migrate to SBS 2011 failed with an DCPromo error.

Run C:\rendom\redom /end on the server.

Error message when you use the Active Directory Installation Wizard to add a member server in a Windows Server 2003 SP1 domain: “The Directory Service cannot perform the requested operation because a domain rename operation is in progress”


Thank you for using Microsoft Partner Online Tech Community.

You may get an error “Verify that the Source Server Name Is Correct” while trying to install SBS into an existing domain:

The KB that related to:

You May Get an Error “Verify that the Source Server Name is Correct” While Trying to Install SBS into an Existing Domain – The Official SBS Blog – Site Home – TechNet Blogs:

Mark Minasi’s Reader Forum – SBS 2003 to SBS 2011:

I had to laugh but not laugh a little bit reading this.  I don’t get why people think that any deviation from the Microsoft migration documents is somehow ‘unsupported’.  Karl advocates clean installs… that’s a supported migration path.  Jeff Middleton’s www.sbsmigration.com methodology of “swing” migration is a normal and supported active directory joining of the domain … it just happens to be with a twist of seizing the FSMO roles due to SBS being SBS. 

All of these things we do with clean/swing is the hoops we are jumping through due to active directory. 

Bottom line this idea that you’ll get no support if you choose path A or path B, that’s not how this works.  Anytime you call Karl, Jeff or Microsoft CSS, they will do their business best to support you.  Sometimes that means rolling back and starting over.  Sometimes that means trying another way.  But they aren’t going to stop you at the door and say “sorry dude, we won’t help you at all”.

I’m reading the migration doc tonight (do I know how to party on a Friday night or what?) and it’s Soapbox time at the Bradley Blog.

Item 13. Page 26 of the whitepaper on how to migrate from SBS 2003 to SBS 2011 says this:

On the Get important updates page, if the Destination Server is connected to the Internet, click Go online and get the most recent installation updates (recommended). If the Destination Server is not connected to the Internet, click Do not get the most recent installation updates. After the installation finishes and you configure Internet access, you can connect to the Internet to get the most recent updates

And I will once again state for the record that the LAST thing you should be doing during the install of an operating system beginning a migration process bringing change to a network is to introduce MORE change when you install the operating system and say “yes” to updates.  Currently there are no needed updates to fix the install process.  You build any pc behind a firewall these days.  The server has a nic firewall to protect it as it is being installed.  The update process does not just bring down install patches but ANY patches, security, .net etc.  So please, do me and yourself a favor and say NO to getting updates during the install process.