Speed Limit

Exchange 2010 – Handling different Internal and External Domain Names

One of the issues I ran into with a recent migration from Exchange 2003 to Exchange 2010 was dealing with DNS Namespaces.

The company domain was not the same as the external domain name. Example:

Internal: mail.domain.local
External: mail.domain.com

When you purchase your exchange SSL certificate this may not be a problem. Just make sure you add your local url and server name into the pool with your certificate and all will be fine.

The problem comes when your internal domain name matches someone else’s external domain. The issuing certificate company will not be able to authenticate a certificate for you based on another domain that is not owned by you.

This in itself can cause some nightmares with the internal url structure for Exchange 2010.

Exchange 2010 uses a plethora of url’s to determine where everything is. This all wraps up into what is called Autodiscover.

To find these url’s in your exchange install use these commands in the ESM:

get-AutodiscoverVirtualDirectory

get-ClientAccessServer

get-webservicesvirtualdirectory

get-oabvirtualdirectory

get-owavirtualdirectory

get-ecpvirtualdirectory

get-ActiveSyncVirtualDirectory

each listing can have a specific setting for internal and external url.

What kind of problems can I run into?

First and foremost the problem I ran into was you could not access Automatic Replies via outlook.

“The automatic reply settings cannot display because the server is currently unavailable. Try again later”

To troubleshoot this the first thing you want to do is test your email auto-configuration via outlook. Hold the Ctrl button down and right-click the Outlook icon in the desktop tray to access the option.

This nifty little feature can definitely point you in the right direction. Once you run this be sure to uncheck GuessSmart and Secure GuessSmart Authentication. Enter your account password and let her rip. When the process is done running you will be presented with some output.

This output will list your internal and external urls along with any directories that have been setup.
The key here is the AutoDiscoverService.

In my case it pointed externally to https://mail.domain.com/, a lot of my urls were pointing there. From inside our organization there was no way to access this url because our internal domain name was different then our external one.

So how do we fix this?

“Split-Brain” DNS.

Split-brain DNS is a Domain Name System (DNS) configuration method that enables proper name resolution of local resources from both inside and outside of your local network.

The idea is to resolve and external dns records internally and trick Exchange autodiscover services into  thinking that the domain you listed on your SSL Certificate resolves.

How to Create a Forward Lookup Zone

To create a new forward lookup zone:

1. Start the DNS snap-in. To do this, click Start, point to Administrative Tools, and then click DNS.

 

• Click the DNS Server object for your server in the left pane of the console, and then expand the server object to expand the tree.

 

 

• Right-click Forward Lookup Zones, and then click New Zone. The New Zone Wizard starts. Click Next to continue.

 

 

• Click Primary zone to create a master copy of the new zone. Click Next.

 

 

• In the Name box, type the name of the zone (for example,external.com, and then click Next.

 

NOTE: This name is typically the same as the DNS suffix of the host computers for which you want to create the zone.

 

• On the Zone File page, accept the default file name for the new zone file, and then click Next.

 

 

• Click Next.

 

 

• Click Finish.

 

 

The new zone is listed under Forward Lookup Zones in the DNS tree.

Next we add a record for a DNS (A) Record for webmail and point it internally to our Exchange 2010 Server. This will allow the Autodiscover services to work the way they were intended. This fixes the Out of Office and the Auto Configuration.

How to Create a Host Record

To create a host or “A” record:

1. Start the DNS snap-in.

 

• Click the DNS Server object for your server in the left pane of the console, and then expand the server object to expand the tree.

 

 

• Expand Forward Lookup Zones.

 

 

• Under Forward Lookup Zones, right-click the zone that you want (for example, example.com), and then click New Host (A).

 

 

• In the Name (uses parent domain name if blank) box, type the name of the host that you want to add. For example, if you want to add a host record for a Web server, type www.

 

 

• In the IP address box, type the IP address of the host that you want to add. For example, type 192.168.0.100.

 

 

• Select the Create associated pointer (PTR) record check box, and then click Add Host. You receive a message similar to the following:
  The host record www.example.com was successfully created.

  Click OK.

 

 

• When you are finished adding hosts, click Done.

 

 

Note: If you have websites externally that also use the same domain name, Example: http://www.external.com. You will also need to create a blank (A) record, and a www (A) record to point to the external address for those sites. Otherwise you will no longer be able to access your external website internally.

By doing this all of your configurable urls for Exchange 2010 can be the same. This reduces the risk that one or more of your Outlook options stop working.

Did this article help you? Let me know!!

Questions? Drop me a line!

Exchange 2003 to Exchange 2010: The “Swing” Migration – Part 5

In the last part we had corrected some errors in the event log and our server was now humming along in complete unison with our Exchange 2003 Server.

The scenario:

Exchange 2003 still hosting email from internal and external sources. Exchange 2010 in place and able to pass email back and forth to the legacy Exchange Server. Public folder replication has been verified and we are ready to move mailboxes.

I had initially scheduled time a couple of weeks ago to start perform mailbox moves to test everything out. My plan was to move the three IS mailboxes and test connectivity and mail flow for a week before moving other mailboxes. The plan was slightly flawed as I later found out.

How was I going to do it? The easiest method without having to change external MX/DNS Records was this:

1. Change the address of the Exchange 2003 Server to a unique IP that I had setup with a DNS record earlier to go to legacy.exchange2003.com.
2. Change the Exchange 2010 Server IP to match that of the old Exchange 2003 Server.
3. Thus the new server becomes the front end and the old server passes email to any accounts that have not been moved.

The Flaw:

The big change in OWA would cause some ripples in our association cellphone use. Since we use ActiveSync this would break all the Cellphones. Why? Our Exchange 2003 did not use an SSL certificate. The new Exchange 2010 required one.

Thus ended my first attempt when I made all the changes only to find out that our firewall service had not opened port 443 to the OWA Address.

Tip: Make sure port 25 and 443 are open to your OWA Address BEFORE you switch server IP’s. Once this port is verified open you can move forward.

The process:

1. Change the IP on the Exchange Server 2003 to an unused IP that has a DNS record setup for legacy.mail.com (insert your domain here)
2. Delete the DNS record for your Exchange 2003 Server in your local DNS.
3. Create a new record for the new IP address for Exchange 2003.
   • This WILL break mail flow for the moment.
4. On the Exchange 2010 Server change the IP to the one your old Exchange 2003 Server had.
   • The reason for this is that the DNS/MX records are already in place for webmail.mail.com so we will not need to wait for any external records to propagate before we can start operating.
5. Delete the old record in DNS for Exchange 2010 and create a new record with the correct address.
6. Test your original webmail. It should go to the Exchange 2010 Server now.
   • Don’t forget that the webmail now uses https and ends with /OWA instead of /Exchange.
7. Test the url you setup for legacy.webmail.com/exchange and make sure you can access any mailboxes still on the old server.

You have now successfully swapped your mail servers! Now the fun part.

Test mail inbound and outbound to internal and external accounts. I used a Hotmail and a Gmail account for testing. **Important: Test more then one exchange account. In my scenario I thought it wasn’t working but it ended up being a permissions glitch on a single account. All other accounts worked fine.

Once testing has been completed I bit the bullet and moved all mailboxes attached to cellphone accounts.

Prior to moving servers I had done some preliminary research and sent out instructions on changing email settings on Windows Phone 7 to allow email to flow again. The only configuration difference was that SSL needed to be checkmarked to work.

Some isolated incidents where an Error presented itself after making this change required the Email, Contacts, Tasks, and Calendar to be un-synced. Once un-synced you could resync only email and then the rest and everything would work fine.

Important steps to take upon moving mailboxes:

• Watch your mail flow like a hawk. Make sure the queues aren’t backing up on either server.
• Prepare for fallout. Have instructions and documentation ready for the next business day.
• Familiarize yourself with Exchange System Manager 2010 (ESM).
• If you have copiers/scanners or other devices that utilize email prepare to reconfigure them if need be.
  • Technically this shouldn’t be a problem if mail is flowing correctly.

In the next post I will go through some of the problems I ran into after the switch and how to fix them.

Let me know how your installs went!

References:

• Exchange 2003 to Exchange 2010: The “Swing” Migration – Part 4
• Exchange 2003 to Exchange 2010: The “Swing” Migration – Part 3
• Exchange 2003 to Exchange 2010: The “Swing” Migration – Part 2
• Exchange 2003 to Exchange 2010: The “Swing” Migration – Part 1

Upgrading from Sharepoint Foundation to Sharepoint Server 2010: Part 2

What they don’t tell you…

After surviving a relatively painless upgrade from SharePoint Foundation 2010 to SharePoint Server 2010 I found myself racing to setup the Active Directory Profile sync using the User Profile Synchronization features.

Upon entering my Central Administration I found that the services had already been setup and all I need do is change some configuration and off I go!

Wrong…

Selecting my User Profile Service and clicking manage sent me to a generic error screen:

WTF!!!!! My dreams of connecting to Active Directory and farming data were dashed!

After an hour of searching I was sent to the logs files which can be found here:

\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\LOGS

If you have ever had to deal with SharePoint logs, they are heinous! I found a nifty little tool called ULSViewer that helps take away some of the pain that comes with log files. GET IT!

The logs revealed one line:

UserProfileServiceImportStatisticsWebPart:LoadControl failed, Exception: System.MissingMethodException: Method not found: ‘Boolean Microsoft.Office.Server.UserProfiles.UserProfileImportJob.get_IsSynchronizationRunning()’.
atMicrosoft.SharePoint.Portal.WebControls.UserProfileServiceImportStatisticsWebPart._LoadStatusAndSettings()at Microsoft.SharePoint.Portal.WebControls.UserProfileServiceStatisticsWebPartBase.LoadControl(Object sender, EventArgs e)
What does this mean? Nothing if your not a SharePoint coder!

I did what any good IS Professional would do…hit Google and start sifting through information. To summarize the information I found the problem was related to SharePoint Server 2010 SP1. Which was the version I had installed. In order to fix this I needed to install the latest Cumulative Updates.

To verify this I was sent to my C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\ISAPI folder to check the file version on 3 dll files.

Microsoft.SharePoint.dll
Microsoft.SharePoint.Portal.dll
OWSSVR.dll

I found the version number was different on one of the files which initially was causing my woes.

Microsoft.SharePoint.dll – 14.0.6029.1000
Microsoft.SharePoint.Portal.dll – 14.0.6106.5001
OWSSVR.dll – 14.0.6029.1000

Installing all the latest updated and rebooting the server fixed the issue and now my User Profile Service and Synchronization is working like a charm.

A couple of Pain points to keep in mind.

• When I updated using the June Cumulative updates I would get a OWSTIMER.exe debug after each patch installed.
  • I was able to cancel each error and after reboot the server had no apparent problems. I believe this is because I did not stop the FIM Services before installing.
  • If Visual Studio is installed on the same server it will cause the debug message to appear on error.
• Don’t panic, the patch took me about 45 minutes to install which seemed like an eternity.

Where are all my new features?????

At first this wasn’t readily apparent to me either. I logged into my site and saw absolutely nothing different.

You need to be logged in as the Site Collection Administrator in order to see the features. I did this from the server.

Go to your SharePoint Server > Browse to your SharePoint Site > Click Site Actions > Site Settings. 

You now should see a ton of new options. One will be Site Collection Features. Under Site Collection Features you will be able to turn on some of the new features for your Site. This will need to be performed on all separate Site Collections.

I hope this helps someone out of a bind. It was an insane issue and I found little to no direct help from the internet.

Let me know if you have come across similar issues!