Christmas Project: Getting Exchange Server 2007 Installed

Introduction

One of my many holiday projects was to get Microsoft Exchange Server 2007 installed and running over the weekend at home to replace my Exchange 2003 installation.  The most logical (and possibly the easiest, but who knows) thing to do is upgrade but that would be too simple.  It took me just over six total hours to get a brand new working installation of Exchange 2007 on my Yuppie Redneck domain at home - not bad considering the pretty massive changes made to Exchange.

This blog entry is just to outline what a fairly novice Exchange person ran into through the process, along with some other interesting tidbits I came across during the process.  They might be useful, while they also might not be...

Goals

1. Install Exchange Server 2007 on Windows Server 2003 (no, Longhorn isn't supported yet)
2. Configure Exchange Organization for Receiving\Sending mail for my Public (yuppieredneck.com) & Private domains
3. Learn some new things...

Installation Gotchas

The first thing to do in any "new" situation is to do what - install CD and see what happens.  A "fire first, aim second" approach is the only way for this geek to go - ain't no different here.  The nice thing though is that Exchange Server 2007 gives you some pretty nice pre-reqs list before letting you chase your tail.  Thus, the first two things I had to do being the novice is to install the following:

1. Microsoft Management Console (MMC) 3.0 (from the web)
2. Windows PowerShell (codename: Monad)

There might be a few of you who ask - wait, my install asked to first install the .NET Framework 2.0 - why not yours?  It did, though being a web guy, I don't usually ever install a new server without dropping the framework bits on the server.  Thus, it was already installed.

Getting SMTP flowing in\out of the Building

The first major thing is to get email back up & running since my wife will let me know pretty quickly if email is down.  This took a little bit of time but not a great deal considering that most of the work I could do with just a few hints from the Exchange help.  Yes, I admit it, I read some of the manual.  However, it wasn't all that easy and did require one email to our internal alias for help to solve the problem.  I will share more details...

It was easy to configure the Client Access role for the organization and\or server at first because my org consisted of exactly one server.  This isn't the Exchange Server 2007 best practice blog so please don't think that I am suggesting this setup.  In fact, I *highly* recommend that you don't install Exchange in this configuration if your budget can afford it.

The whole point though is that in single configuration environments you install several roles on the single server.  This includes the Client Access Role, Hub Transport Role, and a few other various roles.  For my installation purposes, I didn't get involved with Unified Messaging Role (Telephony) or even the Edge Server Role.  The Edge Server Role is a interesting principle that is put forth by the Exchange team whereby you place the server with this role in the DMZ and ask the world to talk with just this server.  It didn't suit me just right because I don't use the concept of a DMZ at home because I just can't trust throwing a full server out there, instead, I use my firewall (SonicWall TZ-170 Wireless) Access Rules to define what traffic gets through and where it goes.  For many, this is nothing more than Port Forwarding.

Thus, this put forth my first interesting issue:

Issue 1:  By default, the Hub Transport Role is locked down by default to only allow communication from the Internet using Client Authentication. This is obviously isn't my goal since I want to have all MX traffic for my domain pointing to this server and it translate & deliver as appropriate.  My first error message was pretty straight forward:

530 5.7.1 Client was not authenticated (from the NDR sent to me as the sender)

I then went on to find out this "locked down" problem and went off seeking to solve it.  I quickly stumbled upon a few examples of how to resolve the problem using the Exchange Management Shell though what the "documentation" told me to do didn't work.  I would have liked to have been able to do this using the Exchange Management Console though I was running on Beta 2 build (for fun) and a nice little note was found below this image:

Thus, I found the Exchange Management (Monad) command to use via a blog on the MS Exchange Team Blog -

Set-ReceiveConnector "[Your Receive Connector Name (i.e. Default {ServerName})]" -PermissionGroups:"AnonymousUsers,ExchangeLegacy,ExchangeServers,ExchangeUsers"

If you struggle, this is the RTM documentation for Exchange Server 2007 for the Exchange Management Shell for connectors -

Management Shell Command-lets Options

At this point, the command worked and all of sudden mail started flying into my domain and my inbox.  It was mostly spam, but that is another day and another piece (ForeFront).

The last thing I needed to do is ensure to setup a New Send connector and I did so by using the same documentation and using this command:

New-SendConnector -Name "Friendly Name" -AddressSpaces {your domain name}

Management Shell Command-lets Options

Crazy as it may sound, it all just worked from this point on.  I enjoyed the experience and boy have "da boys" in Exchange come a long way since 5.5 & 2000!

Resources for SMTP Flow:

1. Configuring Exchange 2007 Hub Transport role to receive Internet Email
2. How to smoothly survive the transition from linkstate to E2K7 Routing
3. Exchange 2007 Step-by-Step Walkthrough - Beta 2
4. Understanding Exchange Server 2007 Roles

Wait, a better way to do it...Client Access Role on Web Server

Issue 2:  I ran into my second dilemma as I realized that I would need to open ports for two servers inside my network if my current environment stayed the same.  Basically, my primary access method for clients (i.e. Chris's Outlook, Mom's OWA, etc.) is via port 80 (RPC over HTTP & HTTP) and I don't have but one web server (by choice).  Thus, I was faced with an interesting dilemma - setup redirects to get clients to the mail server's OWA installation or change my network. 

It dawned on me at this point that this is where the brilliance came in from the Exchange team.  Just like the brains in IIS came up with the modular IIS server for IIS7, the Exchange team was able to divorce "Mailbox" roles & "Client Access" role.  The lightbulb went off (instead of me reading it which I am sure I could have done) and I realized - wait...Install the Client Access Role on the Web Server and it will take care of finding the mailbox storage server.  It was then that Issue #2 was solved by doing the following:

1. On Web Server, install Exchange 2007 Client Access Role ONLY
2. Removed Client Access Role from the Mailbox Role Server (i.e. Mail Server)

Thus, today we have a single port open for HTTP access to email - Yuppie's E2K7 Mail Server and a single, internal mailbox & transport server.

In a perfect world, all things would have just worked but this just wasn't the case.  Instead, the first problem I had was that on my IIS server I had done my typical practice of deleting the "Default Web Site".  Thus, during the "Client Access Role" pre-requirsites check it barked, scream, in fact just cored that it didn't have that "Default Web Site."  I even, though knowing already what the issue was, clicked on their link that was to help *solve* resolve the problem and get Client Access to install on this system.  It was then that I dropped my chips, my Diet Coke spilled over, and my chair flipped back ...you want to know why?

The *recommended* steps to resolve this problem was to "Un-install & Re-install IIS 6.0"

In particular, I am referring to the following Error in the picture:

Error:

Unable to access the 'Default Web Site' on this server

If you click that little "Recommended Action" you will get this awesome, though totally not logical, suggestion to resolve your problem.  If anything in this blog might be helpful, let me just say it is this one piece of knowledge.  My day job is spent in the Web (i.e. IIS) world and the first thing I know is that they are looking for one thing:

W3SVC/1

If you don't have your 'Default Web Site' because you are like me and just can't fathom having something that you aren't going to use then you will quickly be in a "pickle."  Though, my friend, they great thing is that you can easily fix this problem *WITHOUT* un-installing IIS.  If you are like me, I can imagine my world isn't too far off.  I often run more than one Web site on my Web servers and things don't come out very pretty when you remove IIS 6.0.  Especially, and more noteworthy, if you don't have a stable and good backup.

Resolution:

I need to install Client Access Role on my Web server (IIS) and I need to do it without uninstalling and re-installing IIS 6.0.  I need Exchange's setup to detect that I have now returned the Default Web Site to its glory as the first, and most important, website on this server installation.  What may I do...?

The options are several, the one I pick is easy.  I forewarn, though, that I didn't say the *easiest* so your way might be easier (um, like turn on Edit-While-Running and do Find\Replace) but I like being careful.

Steps:

1. I installed the IIS 6.0 Resource Kit Tools to get the Metabase Explorer (MBExplorer) tool on the Server (or just copy it over or connect remotely)
2. I opened up the Metabase, and located the Default Web Site:
3. The problem is fairly easy to locate - after re-creating the Default Web Site, it doesn't get installed to W3SVC/1 so the install is failing
4. Right-click on the W3SVC/998577302 and choose Rename
5. Rename to 1

At this point, the install will succeed.  However, you should note that you are not finished.  After the install is completed, you will need to use this tool one more time to change a few other locations where the wrong path is put in during the install. 

1. Locate the AppRoot property  for /Exchange VDir and you will see a path like "W3SVC/998577302/Root" and this is invalid
2. Change the # from 998577302 to 1
3. Do the same for /owa, /exchweb, /public, and the other various virtual directories.

Conclusion

In the end, I have learned a lot over the holiday about Exchange Server 2007 and I like a lot of what has been done.  It is clear to me that the Exchange team takes customer's voices very serious and it shows in 2007.  I was able, as a past Exchange Administrator, and a fairly novice skill-level get mail up and running on my new domain pretty quickly. 

The one major disappointment I had was with the Recommended Action for Issue #2.  This is a dangerous act and I know there are better ways to accomplish this without possibly leading to downed Web servers.  However, all in all, it has been a fun and enjoying time spent -

Happy New Year folks...

-Chris