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
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 http://snipurl.com/6a2y.
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.
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:firstname.lastname@example.org;
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
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
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
Hope this helps.