I never upgraded to the newer versions of it though - because one of the most important features for me - the ability to use the server as a gateway - was dropped from subsequent releases (because Server 2008 no longer supported NAT). I liked the programmability of the routing built into Server 2003, and I've built a number of security monitors and integrations with the home security system myself.
Eventually though all good things must come to an end, and so it was the time to upgrade to newer software. I wanted the programmability of Exchange Web Services that were not available in 2003, newer anti-spam products, and closing of the support window for 2003 software is just around the corner.
I decided to go for plain Jane installation of Server 2008 and Exchange 2010 - one generation behind, yes, but detailed instructions for upgrade from SBS 2003 were available for that software, and also once SBS is out of the picture, migration to the newer versions of separate components is easier.
Clear instructions were quite hard to discover, so I decided to put together this list of pointers for people who would attempt to do it after me.
First, this is THE guide: http://demazter.wordpress.com/2010/04/29/migrate-small-business-server-2003-to-exchange-2010-and-windows-2008-r2/
It is detailed, ALMOST error-free, and it is awesome in every regard. Big - HUGE - thanks for Glen Demazter for putting it together!
There are a few quirks that need to be pointed out in addition.
First, use Administrator account for installation, not just a user who is a member of Domain Admins group. This is because Administrator has rights to AD schema, which Domain Admins group does not. If you don't, the Step 3 will fail.
Second, domain controller and mail server should both have static IP addresses. In Step 5 (DHCP) allocate at least 16 addresses at the lower end of the space to static IP range, select IPs from that range, and configure them to be static in the network adapters of the respective servers.
Then after Server 2008 was DCPROMO'ed, go to DNS control panel (Admin Tools) and create entries for them in forward and reverse lookup zones of your local domain.
In Step 6, the write-up assumes that you use a router. I don't, I use SBS 2003 as a gateway. So instead of redirecting the ports on the gateway, you would use Administrative Tools -> Routing and Remote Access -> SERVERNAME -> IP Routing -> NAT/Basic Firewall -> double-click on Network Connection (or whatever your public network interface is called) -> Services and Ports.
You will need to redirect ports 25 and 443 at a minimum to your mail server. Most likely you would want to have it double as your web site, so you might as well redirect port 80 as well.
When this is done, you need to go to your EXTERNAL DNS server (typically this would be at your domain's registrar) and make DNS record for the external names - mail.YOURDOMAIN.com (or owa.YOURDOMAIN.com) and autodiscover.YOURDOMAIN.com to point to the server.
You COULD create an SRV record, but regular record is fine, too. As it happens, if you already have a wildcard domain entry, it should work as well, as anything going over HTTPS (autodiscover traffic does!) will end up on your server, and that's what you need.
In Step 7, there are two companies that make reasonably priced certificates - GoDaddy ($90 per year) and StartSSL ($60/2 years of Class 2 cert).
I chose StartSSL because their package includes unlimited number of certificate - under their business model they charge you $60 for verifying your personal information (you email them photos of your passport, the driver's license, and phone bill), and then you can issue yourself any number of certificates - wildcard, UCC, whatever you want - against the domains that you own.
Once a certificate is imported, Step 7 misses a very important step - the services need to be transferred to the newly imported certificate from Exchange's self-created cert. This can be done in Exchange Management Console -> Server Configuration -> Select certificate, then click Assign Services To Certificate from the left Action pane.
Once this is done, go to https://www.testexchangeconnectivity.com/ and test your connection. This appears to be Microsoft's web site, but I would nevertheless use a specially created, low-power user account to test this out, and then delete the account.
StartSSL certs, albeit being very cheap, have a quirk which in the end took me a lot of pain to resolve. They allow putting ONLY the domain and its derivatives into the certificate. For instance, you can have solyanik.com, autodiscover.solyanik.com, and mail.solyanik.com all be in one certificate. However - and this is very, VERY annoying - the computers inside the network do not use public computers to connect, they connect by their local name, which is something like MYMAILSERVER.solyanik.local, rather than mail.solyanik.com.
Since MYMAILSERVER.solyanik.local cannot be put into startssl cert, the internal outlook clients complain twice on every restart (reconnection to server, really) about server (MYMAILSERVER) having wrong cert (mail.solyanik.com).
This is fixable.
To do so, you need to first create an internal authoritative domain for solyanik.com in your DNS server (on your domain controller, Administrative Tools -> DNS -> Forward Lookup Zones -> New Zone -> Primary Zone), and then create entries for autodiscover, www, mail, etc in this zone. Use the local IP addresses for these entries. This will become authoritative for inside of your network (and, obviously, ONLY for your internal network, as this DNS zone would not synchronize upstream).
Then follow the instructions in this KB to fix the internal pointers to the mailserver and the autodiscover: http://support.microsoft.com/kb/940726
This makes the certificate warnings from internal Outlook clients disappear.
Step 8 - data migration from older Exchange - does not work as described. You will get an exception error when you try to migrate the mailboxes.
To fix this, on SBS 2003 go to Exchange System Manager -> Administrative Groups -> First Administrative Group -> Servers -> SBS2003SERVERNAME -> First Storage Group -> Mailbox Store (double click) -> Security and grant full access to the machine account of the new Exchange 2010 server (you will need to select the option that includes computer account in the account picker, by default it only includes users and groups and will balk when you ask it to resolve machine account). Machine account has the same name as the computer.
Second, when you migrate the public folders, it won't work either. The fix is described here: http://mlbtech.wordpress.com/2008/03/29/exchange-2003-and-the-token-supplied-to-the-function-is-invalid-id-80090308/
In my case the AD object did not have 443 in it, so the only thing that I needed to do was to remove the SSL requirement as described in the first part of the post above:
1. In the properties of the virtual root Exadmin in IIS, go to the “Directory Security” tab.
2. In the “Secure Communications” section select “Edit”.
3. Make sure to deselect “Require secure channel (SSL)” and “Require 128-bit encryption.”
4. If the “Require 128-bit encryption.” is selected and greyed out, make sure to select “Require secure channel (SSL)” and deselect “Require 128-bit encryption.” then deselect “Require secure channel (SSL)” again.
I do not use either Sharepoint or SBS's user shares at home, so I have not tried instructions in Steps 8 and 10.
I did, however, get Windows Phone 7 to connect to the new instance of Exchange. This was highly non-trivial, and this was what needed to be done.
First, go to https://cert.startcom.org/ and clicking on "import our CA certificate" and install the certificate on the phone.
Second, for Administrator accounts, on domain controller, go to Active Directory Users and Computers -> DOMAINNAME.local -> MyBusiness -> Users -> SBSUsers, and, immediately before connecting the user, open user's properties -> security -> advanced -> click "Include inheritable permissions from this object's parent", then OK out of the dialog.
Now delete the existing account on your phone (yes, this is painful, I know), and re-create it. Your people tiles for Exchange contacts will of course be gone...
At the very end, when the SBS server is demoted and removed from the network, Exchange Management Console will start complaining about not being able to access Active Directory. Close it, remove this file: "c:\users
Finally, the send connector that was created as part of Exchange Migration worked erratically for me. Some emails would sit in the queue forever, then get rejected. The exchange queue viewer would show messages sitting in outgoing queue with the error "A matching connector cannot be found to route the external recipient".
To fix this, do the following:
- Open Exchange Management Console
- Go to Organization configuration -> Hub Transport -> Send connectors.
- There will be SBS connector; delete it.
- Right click -> New Send Connector
- Name it something (SMTP) and pick Custom (default) for intended use, then Next
- On the Address space tab, click Add, set address to *, everything else leave as default. Next.
- On the Network Settings tab, click Use external DNS checkbox.
- Then click through to the end of the dialog which will create a new Send connector
You are now done. Thank you for using Microsoft software!
No comments:
Post a Comment