Exchange Migration Walk-Thru

Reader has Exchange upgrade problems; plus, update on Exchange memory optimization problem.

Before getting to the Q&A this week, let me do a little bit of clarification on my column on Optimizing Exchange Memory Usage from April 27.

If you recall, the question centered on high memory utilization on the part of Exchange 2000. In the last part of my answer, in a suggestion entirely peripheral to the actual question itself, I suggested that the reader add the /3GB switch to Boot.ini because he had more than 1GB of RAM in his server.

What I did not do—and should have done—was to verify that the reader was running Windows 2000 Advanced Server. The /3GB switch is not supported on Windows 2000 Standard Server. Using it can cause memory fragmentation issues that could possibly result in a server outage. This is documented in Microsoft Knowledge Base Article 314736, "XADM: Event Viewer Log Entries Cite Virtual-Memory Fragmentation on an Exchange 2000 Server."

You should only use the /3GB switch on Windows 2000 Advanced Server or Windows 2000 Datacenter Server, and only if you have 1GB or more of RAM.

If you added the /3GB switch to a Windows 2000 Standard Server based on my column, remove the entry and restart the server. You have my sincerest apologies.

Thanks to Tony, Dan, Bob, Mark, and Rogerio for bringing this mistake to my attention. Rogerio also suggested that the reader take a look at the memory tuning hints in the Exchange 2000 Deployment Guide, available on Microsoft TechNet at

With all that being said, the rules change if you run Exchange 2003 on Windows Server 2003, which supports the /3GB switch on Standard Edition. With Windows Server 2003 Standard Edition, you should use the /3GB switch if the server runs Exchange 2003 and has 1GB of RAM or more.

Get Help from Bill

Got a Windows or Exchange question or need troubleshooting help? Or maybe you want a better explanation than provided in the manuals? Describe your dilemma in an e-mail to Bill at mailto:[email protected]; the best questions get answered in this column.

When you send your questions, please include your full first and last name, location, certifications (if any) with your message. (If you prefer to remain anonymous, specify this in your message but submit the requested information for verification purposes.)

In addition, you should add /USERVA=3030 to the same ARC path in Boot.ini that you use for the /3GB switch. This gives a little memory back to the operating system to use for Page Table Entries (PTEs). This is documented in KB 823440, "You Must Use the /3GB Switch When You Install Exchange Server 2003 on a Windows Server 2003-Based System."

And now, on with the Q&A...

Bill: We did an in-place upgrade of our Windows NT domain to Windows Server 2003 a while back and everything went well. Over the weekend, I started the Exchange 2003 migration.

I was able to install the ADC (Active Directory Connector) but during the installation of the Exchange 2003 server, setup failed with an error involving the POP3 service. I corrected the problem but setup kept failing with the same error.

I decided to try a disaster recovery installation (setup /disasterrecovery) and that was successful. Setup completed and I was able to create mailboxes on the new Exchange server.

Now I have a couple of problems. All of my mailboxes are still on the Exchange 5.5 server. A few of my users (not all of them) can't view the Global Address List. Also, e-mail seems to be piling up in the queue between the Exchange 2003 server and the Exchange 5.5 server. My users have Outlook 2000. They can still send and receive e-mail if they specify the full SMTP address.

I can ping between all the servers. There aren't any other Exchange servers in my organization. The ADC is running on the same server as Exchange 2003. I have a domain controller and a Global Catalog server for the domain in the same office as the Exchange servers.

How do I proceed now?

Readers: I gave Shehzad a call to get more information and we worked together to get this problem resolved. Here's the result of our work.

We started by making sure that the DNS and WINS configuration was correct for both Exchange servers. The Exchange 2003 server was configured correctly but the Exchange 5.5 server was configured with a DNS suffix that pointed at the company's external DNS domain, not the internal domain, and WINS had several invalid resource records. We fixed those glitches and restarted the Exchange 5.5 server but the symptoms persisted.

We verified that the Recipient Connection Agreement was properly configured with the Active Directory side terminated in an OU called ADC Staging Area. This OU contained the expected number of Universal Distribution Groups and a handful of disabled user accounts representing mailboxes with users who were no longer in Active Directory. Every existing mailbox-enabled user had the proper e-mail information displayed in Active Directory Users and Computers.

We also verified that the Configuration CA had been installed correctly so that the end-point of the Exchange side was pointed at port 379 on the Exchange 2003 server. This is the port used by the Site Replication Service (SRS). We forced replication over the Configuration CA and did not get any errors in the Event Log.

When following up after the ADC replication, we noticed that the Exchange 2003 server didn't appear in the server list when viewed with Admin at the Exchange 5.5 server. The Exchange 5.5 server appeared in ESM (Exchange System Manager). We verified that we could use the mailbox icons listed under the private information store to move mailboxes to the Exchange 2003 server. However, because the Exchange 5.5 server did not know of the existence of the Exchange 2003 server, we were unable to replicate public folders to the new server.

We then pointed Admin at the Exchange 2003 server to get a look at the directory contents in the SRS database. Sure enough, the SRS database contained both servers in the directory service. This confirmed that the problem was with the directory service replication between the SRS server and the Exchange 5.5 server.

We verified that the Exchange system account was correctly entered at the Exchange 2003 server and we verified that the account had Service Account permissions on the Organization, Site, and Configuration containers in the legacy directory service.

We then used the directory service replication feature in Admin to force replication between the two Exchange servers (Exchange 5.5 and SRS). This succeeded with no errors on the console or in the Event Log, but the Exchange 2003 server still did not appear in the site. This was the reason for mail piling up at the Exchange 2003 server, because the Exchange 5.5 MTA did not know of the existence of another server in the same site.

At this point, I suggested that Shehzad either tear down the Exchange 2003 server and start over or call Microsoft product support. Instead, he suggested the following idea:

Since the problem was apparently due to a configuration error due to the failure of the original Exchange Server 2003 installation, Shehzad suggested that we install another Exchange 2003 server in the same site and move the SRS over to the new server (assuming that it installed with no errors.) We then wait for the Exchange 5.5 server to replicate with the SRS on the new server, which should result in transferring information about both Exchange 2003 servers in the site.

Well, friends, I'm happy to tell you that the idea worked perfectly. Shehzad installed the third server then we walked through transferring the SRS to the new server. Within minutes, we saw all three servers in Admin at the Exchange 5.5 server and shortly after that, mail began moving between the MTAs.

We moved the SRS back to the original Exchange 2003 server without incident. We were then able to move all mailboxes to the Exchange 2003 server. We moved the SMTP connector to the new server and verify inbound and outbound message transfers. We then replicated all public folders to the new server in preparation for taking down the Exchange 5.5 server.

Shehzad is going to keep an eye on the event logs over the next couple of weeks to make sure that the initial failed setup did not cause any other strange problems then put the new server in full production.

If you have any feedback on the actions we took, or suggestions for other potential fixes, please let me know. I'll print the best feedback in an upcoming column.

Hope this helps.

About the Author

Contributing Editor Bill Boswell, MCSE, is the principal of Bill Boswell Consulting, Inc. He's the author of Inside Windows Server 2003 and Learning Exchange Server 2003 both from Addison Wesley. Bill is also Redmond magazine's "Windows Insider" columnist and a speaker at MCP Magazine's TechMentor Conferences.


comments powered by Disqus

Subscribe on YouTube