This is part two of a three part series on installing Microsoft Exchange 2010RC.  Because of the Microsoft decision to implement direct RC to RTM upgrade of the Exchange 2010 RC code, you can now install the Exchange 2010RC code into your Exchange environment and begin to deploy and configure.

Part one of this series walked through the install of a consolidated server offering mailbox (MBX), hub transport (HT), client access (CAS), and of course, the management tools. In part two we will cover the basic configuration of the system, and part three will cover putting together a simple Database Availability Group.  Also, in part two, I will be assuming a nominal level of familiarity with Exchange administration including navigation in the console, common tasks (such as user creation and DNS record creation), and using MMC and the operating system in general.

Part One

Part Two

Part Three

Starting with Server 2008 SP2 as a base server, in part one we modified some system settings, installed all the prerequisites, and then stepped through the basic install of a consolidated Exchange server offering mailbox, client access, and hub transport services.  In part two, we will configure the core system to support internal clients, Outlook Web Access (OWA), and the basic in and out mail flow through the Hub Transport.  At the end of part two of this article, we will have the core system able to interoperate with internet mail and internal mail with both OWA and full Outlook 2007 clients.  It is important to consider the full client version - because we are using the Outlook 2007 client, we will not have public folders in operation.  If you need to support Outlook 2003 clients, you will need public folders; public folders are not covered in any part of this article.

Exchange, even in the 2010 variant, is a mature product.  As such, it comes out of the basic install pretty much ready to perform the core functions.  However, because we have a completely new structure for this article, there are some minor configurations that need to be completed.

After we take a quick look at the overall Exchange Management Console, we need to establish an SMTP domain,  create the send connector, modify the receive connector structure for internet email, ensure that DNS is ready to support autodiscover, and setup OWA.  We’ll also put in a new certificate to replace the self-signed Exchange certificate.  This new certificate will make things easier for OWA, autodiscover, Outlook Anywhere functionality, and if you use a publicly trusted certificate provider, lessen the impact of enabling Exchange ActiveSync.

Let’s get started.  Here is the Exchange 2010 Management Console: new, improved, contains new stuff!

On the left, we have the standard tree approach.  Notice that there is a top level “On Premise” category.  Presumably, you will be able to manage your offsite, hosted Exchange resources also; however, I have no direct knowledge of this.  Below that, you see the (now) standard Exchange organization.  Take some time to poke around in here.  Notably, with the demise of the storage group, the organization configuration node now holds Database Access Group data which we will cover in part three.

At the top, in the On-Premise node, there is a new “Organizational Health” tab.  Mine was full of errors to start with, but after I ran the “collect organizational health data” from the action pane, things looked a LOT better.

The “Organization Configuration” node does not list the Exchange administration roles; instead it shows Federation Trusts and Organizational Relationship.  I don’t have any of that in my environment, so mine are blank.

The last interesting tidbit in the Management Console is the “Organization Configuration|Mailbox” node.  Note that database management and availability groups are at this level. Previously, database management was at the “Server Configuration|Mailbox” level.  This change reflects the removal of the storage group from Exchange.  And it should start you thinking about the cost reductions associated with implementing a high-availability solution using Exchange 2010.

While there are some other differences, the balance of the tools in the Management Console will be familiar to anyone with Exchange 2007 experience.  In the interests of space conservation (not to mention my poor fingers that need to type all this) we will not explore every facet in this article.  I do encourage you to explore the entire management console before proceeding as things are somewhat different.

While we are in the organization node, click on the Hub Transport, and check the “Accepted Domains” tab.  The setup asked you for this information, but it does not hurt to double check.  Here you can see that my domain is listed, and that it is authoritative.

Also while we are here, let’s create our internet send connector.  I will use a PowerShell command to accomplish this task - just to prove it can be done, and how easy PowerShell makes things for us.  I also simply like using PowerShell as it exposes more of the management tasks.

To do this, open an Exchange Management Shell using the programs menu (you have created some desktop shortcuts for the EMC and the EMS, haven’t you?).

Once the EMS is open, enter this command:

New-SendConnector -Internet -Name ToInternet -AddressSpaces *

You should get this in return…

…and the EMC should reflect this change (remember to refresh to see changes).

Note that the new send-connector has the following defaults:  no protocol logging, a 10MB maximum message size, default FQDN for connections, not a scoped connector (not affiliated with a specific AD site), the connector will use DNS, it will send mail to any SMTP domain that your Exchange organization does not have as an authoritative domain, and lastly, the send connector is associated with our HT role on our server.  I like to change the FQDN to match my MX record.  To do so enter this command:

Set-SendConnector ToInternet -FQDN mail.tsoorad.net (change the FQDN to meet your requirements).

Next, we need to address the receive connector issue.  As you can see, in the “Server Configuration” node the Hub Transport already has two receive connectors.  The “client” connector is for POP/IMAP SSL connections, and the “Default” connector is for server connections.  However, the “default” connector does not accept anonymous connections and we sort of need that if we expect to connect this Hub Transport right through a firewall into the internet.  Microsoft would like to see you deploy an Edge Transport role for security reasons, so this connector is only for internal or highly trusted connections.  This is part of the “secure by design and secure by deployment” routine, but not everyone wants yet another server deployed.  Therefore, we can change things a bit and use the Hub Transport to send and receive without an Edge Transport role server.  Let’s do that.  Before we can, though, we need to look at the existing “default” connector and change it a bit so it will not create a conflict with our new internet receive connector.

Here are the properties of the default connector.  On the “network tab,” notice that the default connector is setup to handle all IP addresses and that on the “Permission Groups” tab the allowed connections are all secured in some fashion.  What I prefer to do is to change this connector to only handle the internal network server subnet.  Then we can create a new connector that works for the entire world.  When traffic comes to our server, the source IP address is evaluated, and if there is a connector that matches the source IP, Exchange will use that connector.  Because we have one receive connector with a specific IP subnet listed, the conflict of having multiple connectors for the same IP subnet is averted. You can use single IP address, or ranges of IP addresses.  Slick. To change the existing IP range, left click the range, then click edit; make your changes and click apply.  You may wish to remove the IPv6 settings as well.  I know that I do - none of my clients use IPv6 internally - although that may change in the next few years.

After your edits, you should have something like this:

OK, now let’s put an internet-specific receive connector in place.  Because of the pre-designed nature of this connector, the connector will only receive inbound mail for Exchange-authoritative or relay domains as specified in the “organization configuration” and is therefore unable to relay.  Very nice.

Again, I will use PowerShell to do this task.  This is the information you need before you begin:

Server IP, Server port (25 - of course!), and the range or single IP that you will receive SMTP traffic FROM.  So, for my environment, the server address is 1.1.1.25, the port is 25, and I want to receive from 0.0.0.0-255.255.255.255.  Clear as mud? Here is the command string for my EMS command line: 

New-ReceiveConnector -Name FromInternet -Usage Internet -Bindings 1.1.1.25:25 -RemoteIPRanges 0.0.0.0-255.255.255.255

You should get this in return…

 

…and the EMC should reflect this change (remember you may need to refresh to see changes).  You should poke around at the properties of the new FromInternet receive connector and admire your handiwork and review the other options.  However, I would leave this connector in the state it is in, and setup other connectors to handle your more esoteric needs. See this blog entry for a review of how to setup receive connectors to receive email from internal application servers.

Before you go much farther, open up DNS and ensure that the FQDN for the server is associated with an “A” record, and then create a new host for Autodiscover.domain.com so that clients can find the server.  Here is a snippet of my DNS so that you get the idea.

Now is a good time to enable Outlook Anywhere.  This is a simple process.  Go to the “Server Configuration|Client Access” node, select your server, and click on the “Enable Outlook Anywhere” wizard in the Action Pane.

I choose the basic authentication - after all, we are encrypting this entire process with SSL; your organization may prefer to use NTLM.  Likewise, my server loading does not dictate using SSL offloading.  YMMV.  Click on Enable to move on.

You may get a notice that there is a short delay.  This is normal.  The balance of this article will take more than this delay to complete, so things will be ready by the time you need the OA to be functional.

At this point, you should be able to create a few users and access the mail box from Outlook Web Access (OWA).  But first, let’s twiddle a few settings for OWA to make things easier on the user.  Note that the title of the tab for OWA is now “Outlook Web App.”  On the “Authentication tab, let’s select “User name only” and get your domain name in there so users only have to user their user name with a password and not the entire UPN. They will love you for it.

We need to restart IIS to get this change enforced, so open PowerShell and do IISRESET /noforce to accomplish the reset.  Now let’s avoid those nasty certificate error messages and replace the self-signed certificate with one from either a publicly-trusted issuer, or in my case, from my Enterprise CA from my domain.  Either way, the process is the same. 

Create the certificate request, obtain the certificate, import the certificate, enable the certificate with services and we’re done.  So simple.  So simple that this little piece trips up many administrators.  Ergo, one of the new features of Exchange 2010 is a handy certificate wizard process.  Let’s step through that right now.  By the way, this new certificate wizard ROCKS!

Open the certificate process from the EMC.  That’s right, we can do this in the GUI!

In the first screen, enter a friendly name… notice that I used Domain Wildcard.  Yes, this is going to make a wildcard certificate!  Woo hoo!  Click next to move on.

I selected “wildcard” and entered my domain.  Wildcarding is so nice.  Keep in mind this will pick up *.tsoorad.net which is great; however, remember that older devices (read smartphones) don’t like wildcard certificates.  Click on next to move on.

On this next screen fill in the data as appropriate to your environment, click on next to move on.

The next screen allows you to review your data before committing yourself.  You do review these screens don’t you?  Click on next when you are ready to move on.

And we are done generating the request file.  Note that the underlying PowerShell command string is there.  Also note that there are changes to the New-ExchangeCertificate command, which negates any previous routine you may have had with Exchange 2007. There are guidance steps to help you out with next steps. Very nice. Click finish to proceed.

Take that hashed file - you do remember where you put it don’t you? - and get a certificate from your favorite source.  I will be using my Enterprise CA hosted by my domain.  Keep in mind that we generated a wildcard certificate request.  Typically, the public vendors want to charge you more for those.  When you have your new cert in hand, copy it to a file location that your Exchange 2010 server can access, and then open the “Import Exchange Certificate Wizard (right below the New Exchange Certificate Wizard from before).

On the first screen of the import wizard, choose your certificate file (either issued to you from a public source, or from your internal CA), and enter a password.  This password is the authority to import the certificate.  In my case, my user account that I was doing all this work with was a domain admin equivalent - so I put in that account’s password - simple?  Click on next to move on.

You have the ability to put this certificate onto multiple servers.  I chose to just put this certificate on one server for now.  Click on next when you are ready to move on.

Review the resulting data set and click on IMPORT to finish.

After the import is successful, review the last screen, especially the underlying PowerShell commands, and click on Finish to complete this task.

Our final step in the certificate process is to assign our new certificate to the Exchange services.  To do this, go back to the “Server Configuration” node, and click on our new certificate. The action pane will blink over to the pertinent actions - one of them is “Assign Services to Certificate.”  Let’s do that now.

Select the server(s) and click next to move on.  Select the appropriate services - note that I did not select “Unified Messaging” as my setup does not have the UM server role. Also note that IMAP and POP are not selected.  Given a choice, I don’t allow my users to have those protocols active, and the IMAP won’t work with a wildcard, IMAP requires a FQDN on the certificate. Click on Next to move on.

Review the summary, and click on Assign to make it happen.

Choose the YES option on this overwrite question.  Yes, we want to replace the certificate!  We don’t want that nasty self-signed thing!

Next, remove the existing self-signed certificate.  We do not need it.  Simply right click on the self-signed certificate and choose “remove” from the resulting context menu.

Now we’ll create a few users and our basic configuration is done.  Before we create the users, we are going to modify the recipient policy so that we control the creation of the mailboxes.  I like to have a bit of granularity in my email policies, so I have created my test accounts in their own container.  This allows me to control account creation by container.  When you work through the email policy wizard, look at the available options.  You can now apply email policies based on different criteria which allows you to have different email addresses per container, company, or other attribute.  You get to choose!  I do not modify the default policy.

Start the new policy wizard from the “Organization Configuration|Hub Transport” node.

Here we name the policy, and choose a container.  It is possible to choose the entire AD at the top level.  I choose a bit more segregation.  There are additional choices for applying the policy to different recipient types that exist in the container.

For this article, we are leaving the next selection set blank.  Here is where you could choose to further filter by any of the choices.

On the next step, we choose how we want the email address to appear.  I like firstname.lastname format. If you want to get fancier than this, you will need to edit the string based on the following variables.  Look here for more detail.

• %G First name
• %I Middle initial
• %S Last name
• %D Display name
• %M Exchange alias
• %<x>S The first X letters of the user's last name. For example %2S would represent the first two letters of the user's last name.
• %<x>G  The first X letters of the user's first name. For example, %3G would represent the first three letters of the user's first name.

On the next screen, I am choosing to implement this new policy immediately.  You can schedule this action for later, but you will not defer it forever - this is a carry-over from decisions made in the post-E2k3 environment where administrators were losing policy changes.

Now, create a few user accounts. In the EMC, go to the “Recipient Configuration” node, and select "New Mailbox” from the action pane.

Work your way through the wizard.  I have two AD accounts all ready for this purpose.  You could, of course, create the user accounts with the Wizard.  You can also create users in bulk, but that task is beyond the scope of this article.  Here are my two new accounts ready to go.

In my environment, I had to reset my exchangeAB SPN’s using these instructions. For a variety of undiscovered reasons, I suggest you reboot your Exchange 2010 server at this point.

Access your new accounts using OWA and the full Outlook client to ensure Exchange is configured properly.  Send a few test emails, set a few appointments and meetings just to make sure.  When you get done, sit back and enjoy a job well done.  Here are my two test users, one on OWA, and one on the full Outlook 2007 client.

It has been a somewhat lengthy journey, but we have configured Exchange 2010 to perform the basic email functions, allowing access to both OWA and the full Outlook client.  Remember that we did not configure support for OL2003 - we did not provision for public folders.  We have a new certificate, Outlook Anywhere is functional, and our email policy is configured to create our desired email addresses layout.  In part three, we will configure another Exchange 2010 server and setup a simple Database Access Group so that we can achieve basic high availability without the need for cluster services.