I would like to point you to a nice blog by Ronnie Pot in the Netherlands that provides an excellent set of instructions for resolving this error. The error your server does not have a name server record in DNS is puzzling because if you look for the NS records you will find them. Ronnie ran into this problem and discovered a Microsoft KB article that will guide you to the solution. http://blog.ronnypot.nl/?p=879

—
So who wrote this blog and what do they do for a living anyway?
We’re Third Tier. We provide advanced Third Tier support for IT Professionals.
Get Support Blog Twitter Facebook LinkedIN

In the process of two recent migrations, an issue has snuck up on me. The initial symptoms have all been different, but the end result has been the same. Replication errors. For one client it first appeared even when the Migration Wizard was not able to disable the DHCP service on the source servers, for another it did not appear until the mail box move was attempted.

If you are suffering from these issues you will see replication errors in your NTFRS event logs. “having Trouble enabling Replication from…”

When you run a dcdiag, you will get an error similar to the following:

Microsoft Windows [Version 5.2.3790] (C) Copyright 1985-2003 Microsoft Corp. C:\Documents and Settings\Contoso>dcdiag /s:ContosoSBS Domain Controller Diagnosis Performing initial setup: Done gathering initial info. Doing initial required tests Testing server: Default-First-Site-Name\ContosoSBS Starting test: Connectivity ……………………. ContosoSBS passed test Connectivity Doing primary tests Testing server: Default-First-Site-Name\ContosoSBS Starting test: Replications REPLICATION LATENCY WARNING ContosoSBS: This replication path was preempted by higher priority work. from Old-Server to ContosoSBS Reason: The replication operation failed because of a schema mismatch between the servers involved. The last success occurred at 2011-07-09 12:29:54. Replication of new changes along this path will be delayed. REPLICATION LATENCY WARNING ContosoSBS: This replication path was preempted by higher priority work. from Old-Server to ContosoSBS Reason: The replication operation failed because of a schema mismatch between the servers involved. The last success occurred at 2011-07-09 12:29:51. Replication of new changes along this path will be delayed. REPLICATION LATENCY WARNING ContosoSBS: This replication path was preempted by higher priority work. from Old-Server to ContosoSBS Reason: The replication operation failed because of a schema mismatch between the servers involved. The last success occurred at 2011-07-09 12:24:50. Replication of new changes along this path will be delayed. REPLICATION LATENCY WARNING ContosoSBS: This replication path was preempted by higher priority work. from Old-Server to ContosoSBS Reason: The replication operation failed because of a schema mismatch between the servers involved. The last success occurred at 2011-07-09 12:24:39. Replication of new changes along this path will be delayed.

If you open a command prompt, and on the new SBS 2011 Server and you do a repadmin /showrepl you will get a reply that also indicates DNS and Replica Link Errors.

C:\Documents and Settings\ContosoSupport>repadmin /showrepl repadmin running command /showrepl against server localhost Default-First-Site-Name\Old-Server DC Options: IS_GC Site Options: (none) DC object GUID: 899d2bae-5a7b-44fe-bb2e-1a3f65221d34 DC invocationID: 276bef04-f1fd-4cd3-93e0-75b686c542f4 Source: Default-First-Site-Name\ContosoSBS ******* 9 CONSECUTIVE FAILURES since 2011-07-09 12:16:16 Last error: 8524 (0x214c): The DSA operation is unable to proceed because of a DNS lookup failure. Naming Context: CN=Schema,CN=Configuration,ContosoSBS,DC=lan Source: Default-First-Site-Name\ContosoSBS ******* WARNING: KCC could not add this REPLICA LINK due to error. Naming Context: ContosoSBS,DC=lan Source: Default-First-Site-Name\ContosoSBS ******* WARNING: KCC could not add this REPLICA LINK due to error. Naming Context: CN=Configuration,ContosoSBS,DC=lan Source: Default-First-Site-Name\ContosoSBS ******* WARNING: KCC could not add this REPLICA LINK due to error.

All This sounds pretty nasty, and things are “just not right”. Never Fear. The fix is simple. Update your NIC drivers on your source server. Turn off RSS (Recive Side Scaling) and TOE (TCP Offload Engine)

	Receive-Side Scaling (RSS) resolves the single-processor bottleneck by allowing the receive side network load from a network adapter to be shared across multiple processors. RSS enables packet receive-processing to scale with the number of available processors. This allows the Windows Networking subsystem to take advantage of multi-core and many core processor architectures. http://technet.microsoft.com/en-us/network/dd277646
	TCP Offload Engine or TOE is a technology used in network interface cards (NIC) to offload processing of the entire TCP/IP stack to the network controller. It is primarily used with high-speed network interfaces, such as gigabit Ethernet and 10 Gigabit Ethernet, where processing overhead of the network stack becomes significant. http://en.wikipedia.org/wiki/TCP_Offload_Engine

This has happened with on Broadcom and Intel Network card drivers. Once RSS and TOE are disabled, reboot the source server. Replication begins instantly, and you can carry on with your migration. Here is an Intel NIC with these options disabled:

—
So who wrote this blog and what do they do for a living anyway?
We’re Third Tier. We provide advanced Third Tier support for IT Professionals.
Get Support Blog Twitter Facebook LinkedIN

So you have a migration planned, and you want to change MX records and cut over, but it looks like it’s going to take 5 days to migrate those 59gb of email down from the hosted provider! What do you do?

First, you think differently. No, I’m not talking about provisioning mac.com accounts, I’m asking us to stop thinking about the mail as a big chunk of data to be moved in one unit. Don’t even think of a single mailbox in that way. Start thinking about what part of the user’s mailbox they couldn’t live without for a day or two. The last two weeks of mail? The last two months? Once you’ve identified that interval that we’ll call “staple data”, make your plan: first cut over the MX record and immediately migrate that staple data. The reduced footprint of that data will turn your multi-day mailbox move effort into a several-hour effort. As soon as the staple data is in place on the new server, then begin the import of the rest of the data. I usually call that data the “historical backfill.”

Now how do you accomplish this date-delimited dissection of the mailbox? Pretty easily. All the basic tools we use or have used have all had date-specific parameters we can use during exports and imports. Exmerge had them, the PowerShell Export\Import-Mailbox commandlets have them. What are the other tools we can use? There’s one main other one that people aren’t usually familiar with. It’s called the Exchange Transporter Suite. It was built primarily to assist people in migrating from non-Microsoft mail platforms. In addition to tools to assist with Lotus migrations, it also has a very nice IMAP and POP migration tool. The IMAP tool is especially helpful for bringing client mail off of Google Apps and onto an Exchange server without having to do it from the Outlook client. Wouldn’t it be nice to do it in one place, all the mailboxes at once? Yep. It is. I’ll introduce you more formally to that tool in a future post.

How Come ExMerge Won’t Run?

One thing I’ve realized is that many SMB consultants aren’t sure how to move mail around in a world in which ExMerge isn’t easily accessible. That’s right, you can’t run ExMerge on an SBS 2008 or Exchange 2007 server to export\import mail. Ah, you might say, I’ve heard that you have to use PowerShell instead. Partly true, but you still can’t run the PowerShell import\export scripts on the server. You have to set up a separate management workstation to run them from. In fact, you can actually run ExMerge from a separate management workstation. The same change in functionality that will not let you run the PowerShell cmdlets on the server also “broke” ExMerge on the server.

The need for a separate management workstation to handle mail import\export procedures gets complicated for those who are trying to host their SBS 2008 box at a colo. In those situations, we’ve temporarily installed VMWare on the server and installed an XP Pro VM to use as a management workstation. Trying to handle the migration via a workstation connected to the colo via VPN is NOT a good idea.

So what’s involved in setting up a management workstation to run ExMerge or use the Import\Export scripts? I would suggest that you focus on running the PowerShell scripts rather than using ExMerge, but I’ll give you the details for both:

Installing ExMerge on a 32-bit Management Workstation

For ExMerge, you are going to follow the normal rules for running Exmerge on a workstation.

1. If on XP, install the IIS Snap-In component from the Add Components Add/Remove applet.
2. If on XP, install the Windows Server AdminPack tools.
3. Install the Exchange 2003 (yes, 2003) management tools on the workstation from the Exchange 2003 media. Ignore the schema error.
4. Download and install ExMerge on the workstation.
5. Pick or create a user who is not a member of the Domain Admins group to use for the import process.
6. Create an “ExMerge” group to assign Exchange permissions to and add the target user to the group.
7. Use the Exchange Management Console to delegate “Exchange View Only Administrator” control to the ExMerge group.

8. Give the ExMerge group Send-As and Receive-As rights. The easiest way to do this is in Exchange Powershell, like this:

Get-MailboxDatabase -identity “SERVER\First Storage Group\Mailbox Database” | Add-ADPermission         -user “DOMAIN\ExMergeGroup” -ExtendedRights Receive-As, Send-As

(You’d swap SERVER and DOMAIN\ExMergeGroup with the appropriate server name and domain and group names in your environment.)

You should now be able to log on to that workstation as a member of the ExMerge group and run ExMerge to pull data out of Exchange 2007 or migrate data into Exchange 2007. I will show you how to do date-delimited extraction later in this article.

If you are interested in knowing whether ExMerge will work in the same way with Exchange 2010, the answer is no, but you can read more about that in this helpful article by Alexander Zammit.

Getting Ready to use Import-Mailbox on a 32-bit Management Workstation

If you are going to use PowerShell to pull the mail into the new Exchange 2007 server (which I recommend), then you are going to need to get a workstation ready to run the import process on. This is mainly written with an XP system in mind.

1. Install these prerequisites: .Net Framework 2.0 and its update, MMC 3.0 (if on XP), and Powershell 1.0. Ah yes, and Outlook 2007 or 2010.
2. Download, extract and install the Exchange 2007 32-bit Management Tools. Make sure you download the version that matches the service pack level of your Exchange 2007 installation, otherwise you will have problems.
3. Pick or create an account that is NOT a member of the Domain Admins or any other privileged group in the domain. Add that user to the local Administrators group on the Exchange 2007 server.
4. In the Exchange 2007 Management Console on the server (click on Organization), use the Add Exchange Administrator action to grant that user account the Exchange Server Administrator role.
5. To import and export mail, you need to grant import user account Receive-As and Send-As permission on any mailbox databases on the Exchange 2007 server. To do that, run this command at an “escalated” Exchange PowerShell prompt:

Get-MailboxDatabase | Add-ADPermission –User Importer –ExtendedRights Receive-As,Send-As
(replace Importer with the name of the user that you created\picked.)

To import all the .pst files in a specific directory into appropriate mailboxes, just make sure that each .pst file is named to match the user’s mailbox alias (jsmith’s .pst would be called jsmith.pst), and then execute something like this:

Dir D:\PSTDump\*.pst | Import-Mailbox

This will look at each .pst, match it to it’s mailbox on the server and import the contents of the .pst.

To import a single .pst file that doesn’t match the mailbox name, you can do this:

import-mailbox jsmith@domain.com -pstfolderpath d:\PSTDump\johnnyboy.pst

You can also do date-delimited imports, but that’s primarily something you’d want to do as an export process in ExMerge. I’ll go over that now.

Date-Delimited Mail Exports using ExMerge

Using date-delimited exports is commonly used when mailboxes are very large and need to be exported in chunks in order to avoid the 2gb limit on ANSI .pst files. It is also useful when there are many mailboxes to be moved in a short time and it is not practical to move all the data at once.

Let’s create a scenario: It’s March 13th, 2010 and tonight we need to migrate 115 users from an Exchange 2003 server in one domain to an Exchange 2007 server in another domain. We’ve already migrated the user accounts to the new domain using LDIFDE, but now it’s time to migrate the mail. We changed the firewall’s configuration an hour ago so that new email is being delivered to the mailboxes on the new server. We’ve set up our export\import account and are ready to use ExMerge.

Because the total amount of mail on the server is equal to 79gb (yes, this is an urgent project!) and a dozen of the mailboxes are larger than 3gb, it would take quite a bit of time to export all the mail out this evening. What we will do is export the “staple data” first: all the mail from January 1st 2010 up till today. Because that is only 73 days of mail, the .pst file for each mailbox will will be relatively small, and the entire export process will probably take 35 minutes or so. Since ExMerge will automatically name the .pst file after the user alias, the exported files are ready to be imported into Exchange 2007 immediately.

Once the initial run of .pst files has been exported and then imported successfully, it’s time to start working on historical backfill. We will go back to ExMerge and begin running another date-delimited export covering all of 2009, choosing a separate directory as the destination. When that export finishes, we will use import-mailbox again (pointing it at the new directory) to bring that mail into the mailboxes on the new server. We can go backwards, year by year, until all the mail has been brought in. Since the most critical data has already been imported, the migration should seem smooth to the users even if data is continuing to be imported over the next 24 hours. It is the rare user that refers to 36-month old emails on a daily basis.

What if you have just set up Exchange 2010? Can the management workstation you set up for importing into Exchange 2007 still be used? Nope, while the strategies I’ve outlined here are still valid, you can only use a system set up with Exchange 2007 management tools to import data into an Exchange 2007 mailbox server. If you have SP1 loaded on Exchange 2010, you can run the new-mailboximportrequest and new-mailboxexportrequest commands to export or import to\from .pst files. See this article for more details: http://msexchangeteam.com/archive/2010/04/26/454733.aspx

Using strategies like these can reduce the stress of having to migrate a lot of mailbox data in a short time-frame, and make large-mailboxes less formidable seeming. I hope you find this helpful. Of course, if you’re in the middle of it and short on patience, go ahead and open a ticket, and I’ll help you out!

—–

So who wrote this blog and what do they do for a living anyway?
We’re Third Tier. We provide advanced Third Tier support for IT Professionals.
Get Support Blog Twitter Facebook LinkedIN

We fully patched it. We defragmented the Exchange database. We ran the BPA. We updated the NIC drivers. We fixed up a journal wrap problem. We ran dcdiag to test DNS-AD integration. We ran gpupdate. We ran repadmin to test AD sync. We ran the BPA again and it told us that the server held none of the FSMO roles. !***!&*($&#*(&$*!!!!! Yikes. We verified all of them in the GUI. We verified all them using command prompt tools and it came back as holding all of the FSMO roles. Still the BPA persisted in claiming that it did not, so we postponed the migration while we gathered our thoughts. After consulting with everyone we could think of that was an expert in AD, it was concluded that if the AD itself knew that the server held the roles and all of the usual tests came back good that the BPA must be on drugs. The migration was scheduled.

We took a backup. We took an image. We mounted the image onto our virtual server. We started and finished the migration. We migrated the mailboxes, moved the data and generally progressed through the to do list smoothly. Then we noticed the event log in the SBS 2003 server. It said that a recent DC Promo was unable to complete and AD replication was halted until it finished. Sure enough when we tried to add a user as a test, the user did not sync between the servers. AD was not replicating. Testing AD pointed to a problem with the objects in the Computer OU and DNS-AD integration tests said that it was unable to find the PDC. It claimed records were missing that were not missing. Rather than turn back to an SBS 2003 server that no one was able to determine why the BPA said didn’t hold the FSMO roles, we decided our options were to press forward to try to fix the AD or create a new domain. Since everything was working, from the user perspective, we decided we had a bit of time to work on fixing AD before our 21 day migration period was up. Work began.

Moving forward with the migration we got to the point were we decided to uninstall Exchange 2003 and attempt a demotion of the SBS 2003 server. The uninstall of Exchange 2003 went along fine. However when we tried to demote the SBS 2003 server it informed us it thought it was the last replication of DNS in active directory. Hard stop.

To troubleshoot Active Directory we checked schema version on both the server and found it was set to 44. Good but we needed them to replicate with each other. So, we deleted the connection objects on both of the servers. Went into DSSITE on both servers and told it to check replication topology.  Waited for some time and we got the connection object back. We forced replication and it was successful! Problem solved.

We thought, problem solved. Shortly thereafter we got a call from the client, Outlook was reporting Disconnected. A look at Exchange 2007 showed that all of the mailboxes were gone! But the good news was that the mailbox store was still the right size so we knew that they were in there. We just needed to connect to them. Exchange Command shell: get-mailboxdatabase |clean-mailboxdatabase  to have all disconnect mailboxes show up in the Console then in the console, go to disconnectted mailbox, right click each mailbox and choose connect.  Do this for each users mailbox and another problem solved.

Are we done yet? No, yet another issue reared it’s ugly head. Users with large mailboxes were getting a message that their mailbox was too big and they were blocked from sending or receiving email. <sigh> Look at the Mailbox size limitation in the SBS Console and it still held our settings to allows for larger mailboxes for the Standard User Role. Reapply the role. No change. Back into the Exchange Management Console we go. Here we set the mailbox size for the users directly.

No further problems have presented themselves so we believe that we have successfully migrated an SBS 2003 with AD problems over to SBS 2008. Overall it was a good learning experience for the technician involved and now we know that the BPA is never on drugs. Apparently it knows things about AD that AD doesn’t even know about itself.

—
So who wrote this blog and what do they do for a living anyway?
We’re Third Tier. We provide advanced Third Tier support for IT Professionals.
Get Support Blog Twitter Facebook LinkedIN

Meet Karl in Seattle on Tuesday, November 3rd

6:30 PM – 9:00 PM
Introduction to Project Management and Zero Downtime Migration Strategies

$10 discount available instantly. Just use discount code SEA200911 at checkout.

For more info, see http://www.smbbooks.com/categories/seminars.htm

Register Now