I am working on a checklist for a migration from standard server or sbs 2003/2000. Look for it soon.

Some sites will tell you to simply log in to IIS and set a redirect on the default site to /owa. Problem is, that setting will be pushed down to all the virtual directories, which will then have to be un-set manually. If you don’t do this, you can expect the sub-sites to fail, including activesync. If you have ever worked as an admin on an Exchange or IIS server, you know that, if you are running a Microsoft web-based application, you change as little as you can get away with and you do it in the simplest manner possible. The best way to do this is to set up a redirect on the iisstart.htm file.

To do this,

1. Select the default website in IIS (this assumes Server 2008 and Exchange 2007, btw).
2. Select the content view at the bottom to see the documents in the root of the directory.
3. Highlight the iisstart.htm file and hit the “switch to features view” Now we are looking at the features for just this one file.
4. Now select the HTTP Redirect button and check the box for “Redirect request to this destination” and put in “/owa” (no quotes).
5. Hit apply and test. This should not require a bounce of IIS.

To ensure that users get directed to the correct site even if they forget to type in https, you can force the error they get to redirect them to the correct site.

1. In the IIS manager, click on the default site and choose “Error Pages.”
2. Select the 403 error and choose to edit it.
3. Choose to “Respond with a 302 redirect” and put in the full path (including https and /owa) of your owa login page. Hit OK. No restart of IIS should be necessary.
4. Test.

Old Server: Windows 2003 Std/Exchange 2003 Std, all patches (pretty basic)

New environment: 2 Windows 2008 Enterprise Mailbox servers running the Exchange 2007 Enterprise mailbox role in CCR with a Windows 2008 Standard machine running the CAS/HT roles and serving as the File Share Witness host. Each of the mailbox servers have three volumes (CCR likes both machines to be as nearly identical as possible): a 40GB C:, a 20GB D: for log files (on a RAID10) and a 300GB E: (on a RAID6). These volumes were set up by a co-worker a few weeks ago and he did a great job with it. The servers are fast and they have great I/O on disk writes. All three machines are hosted in a ESX/Blade server environment with a SAN backend connected via Fibre Channel. This is becoming a pretty popular arrangement. The RAID10 logfile volume is considered best practice for performance reasons. The mailbox store lives on the big RAID6 volume for fault tolerance.

Anyway, all machines were updated and I had tested failing over the CCR cluster nodes successfully, so at about midnight last night, I started moving mailboxes. At around 2am, the old mail server went offline. It responded to ping, but I could not RDP to it or get to and SMB shares. Couldn’t get to the services either. It was, for my purposes, dead. The big issue here is that the mailbox move process was still trying to work, for all 225 mailboxes. The lack of old server caused all kinds of issues to take place that had the effect of hammering the log files. And since log shipping is pretty much how CCR works, both servers started choking. In two hours, we generated 19.8GB of log files, which then knocked the mailstore offline. I could not remount it, since there was no room for more logfiles.

Panic mode.

I temporarily stopped the replication, created new log file folders on both of the cluster nodes, moved the location of the log files in AD, moved the files themselves over to the big data volume, and restarted replication. These steps were originally from EXPTA.com, but it appears that that site is down, so I am linking to the google cache. These should all be done in the Exchange Management Shell (launched as administrator), and only performed after the new log directories have been created on both cluster nodes in the exact same location. Obviously, you will need to also change the paths to match your environment.

Step 1:  Suspend-StorageGroupCopy -Identity “First Storage Group” -SuspendComment “Moving transaction logs” -Confirm:$False

Step 2:  Move-StorageGroupPath -Identity ‘First Storage Group’ -LogFolderPath ‘E:\ExchangeLogs’ -SystemFolderPath ‘E:\ExchangeLogs’ -ConfigurationOnly

Step 3: move [oldpath]\*.* [newpath]

Step 4: Resume-StorageGroupCopy -Identity “exchange1\First Storage Group”

After this was completed (step 3 took a while, since I had 20GB of logfiles) I was able to remount the store and test via OWA. Then it was time to figure out why the Ex2003 box went down. After the moves are complete, I will run a backup to commit those log files to the DB and then move them back to the correct drive, as 20GB should be enough in any  normal case.

MX ToolBox – Great for all-in-one checking of reverse pointers, blacklists, open relays and general diagnostics. If I was stuck on a desert island, this would be the troubleshooting website I would take.

TestExchangeConnectivity.com – Runs a test connection to your Exchange server the same way your Wi-Mo phone or iPhone would. Great for testing an environment when you are not really sure the phone should work (unsupported OS or patch level)

Hexillion.com – Good for looking up public records for DNS and such. The have a lot of options for how much data you want to see.

Telnet client – The fact that this has to be manually installed on Vista is a crime

Steps to send email via telnet – If you need to interact on the most basic level, without fear of spamfiltering or email clients muddying the water, this is a good place to start.

Since Exchange 2007 is much more modular than previous versions, it assumes that you are going to have basically every role on one or more individual servers. You can put them all on one, but you will have to turn some things on to make sure that everything works. If you are trying to turn of NDR’s and it isn’t working,  you need to do it here too.