Here in The Exchange Café I will be posting on the new developments from the world of Exchange and I can’t think of anything newer than the Preview release of Exchange 2013.  In this series I will cover the configuration of the Exchange 2013 preview.  This will be broken into 2 sections.  The first two posts will be on “Configuration of the Client Access Server in the Exchange 2013 Preview”, and the second two posts will deal with “Configuration of the Mailbox Servers in the Exchange 2013 Preview”

You can access the official documentation and download the Preview here.  My good friend “The Exchange Guy” has recently posted on how to install the Client Access Server role for the Exchange 2013 Preview.  We will now configure the CAS role for the following topics:

1.        The Exchange Administration Center

2.       Send and Receive connectors

3.       Accepted domains and default email address policies

4.       Configure SSL certs

5.       Configure external URL’s

6.       Configuration of Outlook Anywhere

In this post we will take a look at the new Exchange Administration Center, cover the creation of a Send Connector, and finish by showing how to configure the default accepted domain, and email address policies.

A quick look at the new Exchange Administration Center

From an administration point of view one of the biggest changes in Exchange 2013 Preview is that the Exchange Management Console is gone. The Exchange Administration Center is the evolution of the Exchange Control Panel and it provides a single unified management console for management of on-premise, online, or hybrid deployments.  You can access it via a web browser and going to the ECP virtual directory.  You can find the ECP virtual directory by running the following command in the Exchange Management Shell:

Get-ECPVirtualDirectory | Format-List InternalURL,ExternalURL

After you login you should see a page similar to the below.

As you can see in the above image via the EAC we have eleven management categories on the left hand side, and when you click on each one you will see the sub categories for each listed at the top of the main page.

Exchange Administration Center note

You can configure the EAC to not allow users internet access form outside the corporate environment.  To do this you would run the following Exchange Management Shell command.

Set-ECPVirtualDirectory  -Identity “CAS_Server_Name\ecp (default web site) –AdminEnabled $False”

If you want the changes to take effect immediately you will need to restart IIS.  To verify this access your Exteranl URL for the ECP and you will get a 404 website not found error.

Create a Send Connector

As with previous versions of Exchange to successfully send email to the internet we first have to configure a send connector. These are the steps that need to be followed to successfully set up the Send Connector.

1.       Go to Mail Flow > Send Connectors. On the Send Connectors page, click the”+” symbol.

2.       In the new send connector wizard, specify a name for the Send connector and then select Internet. Click next.

3.       Verify that MX record associated with recipient domain is selected. Click next.

4.       Under “Address space”, click +. In the add domain window, make sure SMTP is selected in the Type field. In the Fully Qualified Domain Name (FQDN) field, enter *. Click save.

5.  Make sure “Scoped send connector” isn't selected and then click next.

6.  Under Source server, click +. In the Select a server window, select a Mailbox server that will be used to send mail to the Internet via the Client Access server. After you've selected the server, click “add” and then click ok.

7.  Click finish

You can now send email outside of your internal Exchange organization!

Receive Connectors

By default an inbound Receive connector is created when the Exchange 2013 Preview is installed.  This Receive connector accepts anonymous SMTP connections from external servers, so you do not need to do any additional configuration if this is the functionality you desire.  If you want to restrict inbound connections from external servers, modify the Default Frontend <Client Access Server> Receive Connector on the Client Access server.

Add Additional Accepted Domains

When you deploy the Exchange 2013 Preview Exchange uses the domain name of the Active Directory domain where Setup /PrepareAD was run.  If additional domains are needed for recipients to send and receive from you must add the domain as an accepted domain.  A public DNS MX record is required for each SMTP domain from which you accept email from the internet.  To add an accepted domain:

1.       Open the EAC as discussed above.

2.       As you can see in my example below, I have the default jwc2v.com that was created when I installed Exchange. To add another domain go to “Mail Flow” -> “Accepted Domains”, and click on the “+” symbol.

3.       In the ”new accepted domain” wizard enter the name for the accepted domain and in the “Accepted domain” field, specify the SMTP recipient domain you wish to add.

4.       Select “Authoritative domain” and click “Save”

5.       You can see the new Accepted domain above.

Configure Email Address Policies

The last topic for this post is the configuration of Email Address Policies.  If you want the accepted domain that we configured to be added to every recipient in the organization you will need to modify the default email address policy.

1.       In the EAC go to “Mail Flow”->”Email Address Policies” and select the “Default Policy” and click the edit icon.

2.       Under “Email address format” select  the SMTP address you want to change and then the edit icon.

3.       On the “email address format” page, edit the “Email address parameters” field to specify the SMTP recipient domain you want to apply to all recipients in the Exchange organization. Click “Save”.

4.       Click “Save”

5.       In the “Default Policy” details pane, click “Apply”.

6.        If you go to the "Recipients" page you can see these changes.

     That is a wrap for this session of The Exchange Café.  In summary we took a peek at the new Exchange Administration Center and how to login to it.  We reviewed creating a Send connector and we finished with adding an additional accepted domain and modifying the default email address policies.  I invite you stay tuned for the next installment of “Configuration of the Client Access Server in the Exchange 2013 Preview Part 2”.   If you have any questions about this topic please feel free to ask.

Jay W. Cotton

My cohort “The Exchange Guy” recently posted this.

Enjoy!

Jay W. Cotton

                I recently posted this article in the Mr. Proactive and Miss T. Proactive blog site.  In their own words, “Mr. Proactive and Miss T. Proactive are Premier Field Engineers. Mr. Proactive is constantly looking for proactive items that he can share with Microsoft customers. Miss T. Proactive is always looking for Tips and Tricks to share.”  You can visit them here.  I wanted to share this in The Exchange Café as well, as this particular topic has been coming up more often with my customers.  Enjoy!

Jay W. Cotton

While onsite one day with a customer we received a report that a calendar item was not on one of the attendee’s Outlook calendar.  After some investigation we found that the user had deleted the item on accident.  Immediately I began to wonder why the Calendar Repair Assistant had not found and repaired the inconsistency. 

                Not familiar with the Calendar Repair Assistant you say?  A good place to start is here.  In a nutshell, the Calendar Repair Assistant (CRA for short) runs within the Microsoft Exchange Mailbox Assistant service and is designed to repair calendar inconsistencies between organizers and attendees.  As of Exchange 2010 SP1 the CRA is throttle based and performs the following four step process:

1.  Detects inconsistencies The CRA uses the organizer's copy of the calendar item as a master copy for all meeting items. The assistant compares the attendee's calendar item with the organizer's calendar item for inconsistencies. The only exception to this rule is when the assistant compares the attendee's and organizer's response status. The assistant assumes that the attendee's response status is the correct one, and, if necessary, updates the organizer's tracking information.

2.  Determines if inconsistencies were intentional If an inconsistency is detected, the CRA determines whether the attendee intentionally introduced the inconsistency. For example, an attendee can introduce an inconsistency by deleting the meeting request and not notifying the organizer. If the assistant determines that the attendee didn't introduce the inconsistency, it corrects the problem. If the assistant can't determine if the inconsistency was intentional, it performs no further action.

3. Corrects inconsistencies The CRA corrects inconsistencies on the Mailbox server on which it runs. However, if the organizer's mailbox is on a different server than the attendee's mailbox, the assistant reads from other Exchange 2010 Mailbox servers to compare the calendar items. The assistant doesn't overwrite the recipient's calendar information. Instead, it merges the information so data isn't lost. In addition, the repair update messages are moved to the recipient's Deleted Items folder.

4. Sends a calendar repair update message if a correction was made Calendar repair update messages are sent to users whose calendar items were updated by the CRA. Instead of sending the message to the user's Inbox, the assistant sends the message to the user's Deleted Items folder. By doing so, a record of the repair is kept in the mailbox without causing user confusion. If the user is experiencing calendar inconsistencies, you can advise the user to look in the Deleted Items folder for troubleshooting purposes. The assistant only sends repair update messages if the issue is fixed.

                Now let’s return to the customer in question.  In theory the CRA should have compared the attendees calendar, found that there was an inconsistency, determined that it was not intentional, and then placed the item on the attendee’s calendar and then sent an email into the attendee’s deleted items folder with a notification that the change has been made.

                Our first troubleshooting step was to look in the deleted items folder for the notification that an item was repaired.  Nothing was there.  Following that we ran the following Exchange Management Shell command to verify that the CRA had not been disabled for that user Get-mailbox username | fl CalendarRepairDisabled the output from that command is below.

So we could see here that the CRA was enabled for the user in question.

Next we decided to look at the CRA logs to see if it logged the event at all.  By default you can find the CRA log files <Exchange installation path>\v14\Logging\Calendar Repair Assistant.  In our case there were no log files at all in this location!

At this point I asked the customer if they had made any changes to the CRA.  They said they had not, so we ran the following command via the Exchange Management Shell Get-mailboxserver  severname | FL *calendar*.  The output is below.

You can see above the default settings for the CRA. The CalendarRepairMissingItemFixDisabled was set to False so they had not disabled the CRA, and the default logging location had not been changed so it appeared that they had not made any changes.  I then noticed the top three entries.  I expected the CalendarRepairSchedule to be {} since the CRA now is throttle based and does not run on a schedule, however the first two entries CalendarRepairWorkCycle, and CalendarRepairWorkingCycleCheckpoint should not be empty if the CRA is running as expected. 

The CalendarRepairWorkCycle parameter specifies the time span in which all mailboxes on the specified server will be scanned by the CRA. For example, if you specify seven days for this parameter, the CRA will process all mailboxes on this server every seven days.

Calendars that have inconsistencies will be flagged and repaired according to the interval specified by the CalendarRepairWorkCycleCheckpoint parameter. For example, if you specify one day for this parameter, the CRA will query every day for new mailboxes that require processing.

As an example if the WorkCycle is set to seven days, and the WorkCycleCheckpoint is set to one day, the CRA will process all mailboxes on the server every seven days, and every day it will repair any calendar items it has flagged in its current queue as needing repair.

In this customer’s example both values were blank meaning that the CRA was not running at all.  After further investigation, we found that even though the CRA is enabled by default for all mailboxes on a particular mailbox server, it is NOT running by default.  So in this case we ran the following Exchange Management Shell command on EACH mailbox server Set-MailboxServer –Identity servername –CalendarRepairWorkCycle 7.00:00:00 –CalendarRepairWorkCycleCheckpoint 1.00:00:00.

When the CRA is working properly and an item is repaired, you will see entries like this in the CRA logs.

In the above example you can see the steps that the CRA takes in validating the calendar item, comparing the items on the attendee’s calendar to the organizer’s calendar, and then deciding whether it should be fixed or not, and then the confirmation that it has sent the fix to the attendee’s calendar.

From the attendee’s point of view, they will receive a message similar to the below example in their Deleted Items folder.  It also places the item back on the attendee’s calendar as “tentative”.

If you would like more information regarding Exchange 2010, Calendaring best practices, and other topics related to Exchange 2010 PFE offers many workshops, chalk talks, and other services that can address your needs.  Talk to your technical account manager for more details.  In the meantime, go back to your Exchange organization, double check your Exchange Calendar Repair Assistant, and make sure you are getting the functionality you expect from it.

                My name is Jay Cotton and I will be your host here in The Exchange Café.  I am a Microsoft Premier Field Engineer (PFE) based in the NY/NJ metro region.  I am lucky enough to have the best of both worlds within the PFE organization.  I have dedicated customers that I work with over a long term basis providing guidance and best practices that involve their Exchange deployments and migrations.   In addition to my dedicated customers, I also provide assistance on an as needed basis to other customers to support their Exchange needs, be that onsite troubleshooting, Exchange health checks (R.A.P’s), or best practice guidance covering a wide range of topics.

This flexibility gives me the advantage of seeing a large number of Exchange deployments and a wide range of issues involving Exchange 2003/2007/2010.  Here in The Exchange Café I intend to share this field experience with you, as well as keeping you up to date on the latest developments from the world of Exchange.   So pull up a chair, make yourself comfortable, and let’s talk about Exchange.

Jay W. Cotton