Tony Brown's Exchange Server Blog

Just thought I’d share a couple gotchas that I stumbled across on a recent Exchange 2003 to Exchange 2010 migration.

1. Blackberry Enterprise Server needs to be at least 5.0 SP1 – Once this is updated and so long as everything else is  configured correctly (besadmin permissions etc) the BES should be able to access both servers mid migration.

2. Forms based authentication MUST be enabled on the existing 2003 server to enable the OWA url to redirect correctly. Out of the box – Exchange 2010 likes you to setup legacy.<domain name>.com published to the Internet as it is a redirect – not a proxy. This means both the existing and new exchange servers must be accessible from the internet during the migration to ensure all users (both migrated and ‘to be migrated’ users have access to to webmail).

3. I saw the issue where the move procedure returns an error and a stub mailbox is left on the old Exchange Server – although the deleted mailbox retention should remove this at the next interval – having to change the retention time to enable you to remove the existing server isn’t really an option so if you see this on test mailbox migrations (ensure you test a mailbox for a user that has elevated permissions) install KB940012 on the existing Exchange 2003 server to alleviate the issue.

4. If your user account is a member of any of the protected Windows 2008 R2 security groups (Domain admins, Schema Admins etc…) then active sync won’t work. Seems harsh but Microsoft say that your day to day user account shouldn’t have elevated permissions and you should use ‘Run As’ to perform administrative tasks. So you have 2 options if you’re having this problem;

1. Remove yourself from the protected groups

2. Select the ‘allow inheritable permissions’ on the advanced page of the security tab of your AD user account and then follow this guide to stop sdprop removing permissions.

Just a couple of things to think about if you’re planning an Exchange 2003 to 2010 (or 2007) migration.

Just a high level overview of a procedure I used a couple of weeks ago to overcome database corruption at a business that had a single server and didn’t want a huge amount of downtime.

They were running Exchange 2007 on windows 2003 x64 and their mailbox store was touching 75Gb so we had them archive and delete a large amount of data from their mailboxes. This meant there was 30Gb of white space in the database which was great, but there were latency issues which meant we had to defrag the database.

When we kicked the defrag off – it bombed out after about 30 seconds reporting database corruption.

In this situation – an intrusive database fix using eseutil could be a bit of a nightmare as;

1. You never know how long it’s going to take
2. The possible corruption may be huge
3. You should run it twice to ensure the corruption has been fixed
4. The impact on the end users is hard to determine and could be massive

We called it a night and decided to come back the following day with a spare server. We installed the server into the existing organization as you would with any migration and confirmed mail flow and all services were working on the new server.

After we had enabled circular logging (temporarily and for obvious reasons) and when the time suited the client – we gracefully moved all mailboxes to the new server – there was a little downtime, but only while the users mailboxes were being moved – client access services were unaffected as they were running Exchange 2007 so any client access server can access any mailbox store (Exchange 2003 would need a little more attention).

Once the user mailboxes were moved we removed the corrupt mailbox store and created a new one.

Once we knew the database was healthy we moved all the mailboxes back and bingo – we had fixed the corruption, removed the white space and defragmented the database without running a database fix which should always be avoided wherever possible.

We chose this method primarliy because the downtime was quantifiable – we could communicate with the users how long they’d be down which we couldn’t do with an database fix.

This was just a heads up of the way we completed the procedure… not a technical article you’ll need to do more research into exactly how to complete the procedure – post in the exchange forum if you have any questions or would like to know more…

Here’s a list of the current major SAN (Subject Alternative Name) providers and some basic information on costs and configuration. SAN certificates have been part of the x509 standard since 1999 but only since the advent of Exchange 2007 have they been widely used.

In previous versions of Exchange, you only really needed one – for OWA, the same domain name could be used for pop3 and pretty much anything else as they were using different IP services / ports.

With Exchange 2007 however there are multiple FQDN’s that need to be accessed internally and externally that need to point to the same exchange server on the same SSL port (which of course has domain name validation), hence the need for SAN certificates.

There are a number of different ways to configure the autodiscover service the majority of which are outlined here http://technet.microsoft.com/en-us/library/bb332063%28EXCHG.80%29.aspx.

The minimum you can get away with (in the real world) is 4 names and they’ll usually take the following structure;

autodiscover.<SMTP address name>.com       |    For external autodiscover connections
mail.<SMTP DNS name>.com                           |    For external OWA, TLS, & POP3S
CASservername.<internal DNS name>.local    |    For internal FQDN resolution
CASservername                                               |    For internal ’server name only’ resolution

Prices have been coming down steadily in the recent months for SAN certificates (it’s a good job as when Exchange 2007 first arrived they costed $1000+). Microsoft currently only recommend 3 SAN suppliers (Globalsign, Entrust & Comodo) – makes you wonder why more haven’t asked to be on that page….

Below is an overview of what’s currently (easily) available,  if I’ve missed you off the list – then please contact me and I’ll get you added….

DigiCert (www.digicert.com) – $328 per year for 4 names
Verisign (www.verisign.co.uk) – $1,200 per year  for 4 names
GlobalSign (www.globalsign.co.uk) – $195 per year for 4 names
Entrust (www.entrust.net) - $449 – 10 names
Comodo (www.comodo.com) – $284 per year – 4 names
RapidSSL (www.rapidssl.com) – $199 – unlimited names
Certificates for Exchange (www.certificatesforexchange.com) $59 per year – 5 names (can be full domain names)

Historically you had to be careful to ensure the chosen public certificate authority supported the application it was securing, but all the above provides report 99% browser compatibility and all will work with Exchange 2007+.

On the face of it – certificates for exchange appear to be offering an astonishing deal, but once you check the site out and realize is a godaddy account inside a wrapper – might make you think twice.

Which SAN certificate should you choose?
I guess it’s down to budget and technical ability – the godaddy cert is very cheap, but if something unforseen happens during its creation or installation then it’ll be quite painful to sort out (It’s happend to me!). The providers that charge more for their certificates usually have better support structures in place that’ll expediate the resolution of any problems that may arise.

Please comment with any experiences that you think may benefit other users and please keep them rant free

My name is Tony Brown and I’ve put myself forward to Nathan (the godfather of the MMMUG) with a view to help out in any way I can.

I’ve been using and installing Exchange Server since v5.0  and have a good grasp of all related technologies – I’ve got a truck load of MCP’s under my belt along with the experience you need to put that knowledge into practice.

I’m going to be the lead on the website’s development so if anyone has any idea’s – then please head over to the Exchange forum and let us know what you’re thinking.

I’m going to be blogging about all aspects of Exchange setup and configuration, from desgin to implementation so check back soon for information that you (hopefully) won’t find anywhere else!