Collection:Exchange 2007 Client Access Server Role(2)

Uncovering the New Outlook 2007 AutoConnect feature

Introduction

Microsoft Outlook 2007 AutoConnect (formerly known as AutoDiscovery) is a new Exchange Server 2007 feature, or more specifically Web Service, which makes it so much simpler as well as easier to configure the Outlook 2007 profiles in your organization. In order to automatically configure and connect previous versions of Outlook to Exchange 2000 and 2003 Servers, you needed to do so using the Custom Installation Wizard from the Office Resource Kit or a similar tool. But now the users can configure their Outlook profile themselves, as they only need to click next a few times and specify their e-mail address and password, depending on whether they're using a client machine member of the respective Active Directory domain or not.
The AutoConnect feature is provided by the Client Access Server (CAS) role, which is the server role that replaces the front-end server we know from Exchange 2000 and 2003. So in order to make use of the new AutoConnect feature, it’s a requirement that you have at least one Exchange 2007 Server, with the CAS role installed, and deployed in your organization.

How Does The AutoConnect Feature Work?

When the CAS role is installed on an Exchange 2007 Server, a new virtual directory called AutoDiscover is created in the IIS Manager.

                                            Figure 1: AutoDiscover virtual directory

When Outlook 2007 is launched from a client machine it immediately starts searching your DNS server(s) for a host record. If an IP address is found the client will try to access the Web Site to which the XML file refers, which by default is the Default Web Site (more specifically the AutoDiscover virtual directory). The record should point to an Exchange 2007 Server with the CAS role installed, and that is accessible either via the intranet or the Internet. As soon as the CAS receives a request from a client, it generates a XML document with information found about the user in Active Directory. This XML file is then posted back to the client and used as a configuration template for Outlook. The template file contains information such as display name of the user, server name, alias, availability server URL (free/busy info), OOF URL, OAB URL, auth package etc.

Note:
Although we focus on the Outlook 2007 client in this article, the AutoConnect feature also works with Outlook Express (POP3 and IMAP4) and Exchange ActiveSync clients. It’s also worth mentioning the AutoConnect feature works with RPC over HTTP as well.

Creating the necessary record in DNS

In order to make use of the AutoConnect feature when configuring the Outlook 2007 clients in your organization, a necessary step is to create a special host (A) record in DNS. In order to do so log on to one of the DNS servers in your Active Directory, then open the DNS Management MMC snap-in by clicking Start -> Run then type dnsmgmt.msc. Now expand Forward Lookup Zones then right-click the respective domain in the left pane and select New Host (A) in the context menu (Figure 2).

                         Figure 2: Creating a record in DNS Management MMC snap-in

Type Autodiscover in the Name text field, then specify the IP address of the Exchange 2007 Server with the CAS role installed as shown in Figure 3 below.

                                             Figure 3: Specifying the host record details

When you’ve done so click Add Host then OK in the appearing dialog box. You can now close the DNS Management MMC snap-in again.

Configuring AutoConnect on the Client Access Server

Before we’re ready to move on and configure our Outlook 2007 clients using the AutoConnect feature, we also need to specify which CAS server is to be used by the msExchOutlookProvider attribute on the msExchDiscoverConfig object in Active Directory. Because the Exchange Server 2007 build I use in this article doesn’t have an option for configuring the Outlook Provider Configuration settings in the Exchange Management Console, we need to do so using the OutlookProviderConfig CMDlet via the Exchange Management Shell instead. So let’s fire up the Exchange Management Shell then type the below command and hit Enter:

Set-OutlookProviderConfig –id exch –server: ehvms06

My CAS server is called ehvms06 so you should of course replace this name with the NetBIOS name of the Exchange 2007 server that holds the CAS role in your environment.

Note:
The Set-OutlookProviderConfig command is, among other things, used to set specific global settings by using the msExchOutlookProvider attribute on the msExchAutoDiscoverConfig object in Active Directory. To get more information about the available parameters that can be used with this CMDlet, type get-help set-outlookproviderconfig in the Exchange Management Shell.

If you want to test the AutoConnect feature without using SSL, you can disable the requirement for SSL with Set-OutlookProviderConfig –id exch –ssl:$false. Just keep in mind that you always should be using SSL in a production environment, but since the current versions of Exchange Server 2007 aren’t meant for deployment in a production environment, there shouldn’t be anything to worry about.

Exchange 2007 Availability Services

The Exchange Server 2007 Availability service improves free/busy data access for information workers by providing secure, consistent, and up-to-date free/busy data to clients that are using Availability Web Service (like Microsoft Office Outlook 2007 or Exchange 2007 Outlook Web Access). Outlook 2007 uses the Autodiscover service to obtain the URL of the Availability service.

But what is the Availability Service?

Unlike previous versions of Exchange, free/busy data does not have to be stored in public folders; thus we no longer have to deal with replication or latency. Instead we will access the target mailbox’s free/busy data directly from the calendar (via the Availability service).

If you couple that with the new Calendar Assistant functionality in Exchange 2007 (namely the ability for Exchange to place meeting requests in a tentative state for mailboxes without the need for the end user to triage the meeting request, and the ability to update meeting requests when certain information changes (location, attendees, meeting notes)), the Availability service provides a methodology by which end users will be able to see free/busy data in real-time that is always up to date.

The Availability Service is a web service that is deployed on the Client Access Server role. Outlook 2007 clients discover the Availability service via Autodiscover. The Availability Service is used by the Outlook 2007 and Outlook Web Access Scheduling Assistant to

• Retrieve live Free/Busy information for E2K7 mailboxes
• Retrieve live Free/Busy from other E2K7 forests
• Retrieve published Free/Busy from Public Folders (for legacy mailboxes or for mailboxes using legacy Outlook clients)
• View attendee working hours
• Show meeting time suggestions

As mentioned above, in order for the Availability Service to provide a seamless end user experience, it must be able to interact with legacy systems. To that end, the Availability Service can retrieve data from free/busy public folder stores. Now you may ask why would there be public folder free/busy data? Well, remember that only Outlook 2007 utilizes the Availability service. Outlook 2003 clients and earlier clients still use Public Folders. In addition, mailboxes stored on legacy Exchange servers will also still publish free/busy data to a public store. During server and client coexistence, we need to ensure that all parties can obtain free/busy data regardless of server version or client version.

Note: In order to maintain backwards compatibility, Exchange 2007 mailboxes using Outlook 2007 clients will utilize the Availability service for retrieving data, but also publish to a free/busy public store, since legacy clients also need to retrieve free/busy data.

This table explains what method is used for free/busy in the different topologies:

Client	Logged in Mailbox	Target Mailbox	Free/Busy Retrieval
Outlook 2007	Exchange 2007	Exchange 2007	The availability service reads free/busy information from the target mailbox.
Outlook 2007	Exchange 2007	Exchange 2003	The availability service makes HTTP connections to /public virtual directory of Exchange 2003 mailbox.
Outlook 2003	Exchange 2007	Exchange 2007	Free/busy information will be published in local public folders.
Outlook 2003	Exchange 2007	Exchange 2003	Free/busy information will be published in local public folders.
Outlook Web Access 2007	Exchange 2007	Exchange 2007	OWA 2007 calls the availability service API which reads free/busy information from the target mailbox.
Outlook Web Access 2007	Exchange 2007	Exchange 2003	OWA 2007 calls the availability service API which makes an HTTP connection to the /public virtual directory of Exchange 2003 mailbox.
Any	Exchange 2003	Exchange 2007	Free/busy information will be published in local public folders.

So how does this work? 

1. Well the client will make a connection to the CAS server (if Outlook 2007, this will be determined via the Auto Discover configuration) using the Availability URL. 

2. If the target mailbox is in another AD site:

a. Then the CAS server will make an HTTPS connection to the target CAS server.

b. The target CAS server will obtain the F/B information by communicating over MAPI to the mailbox server and then send it back to the source CAS server.  

3. If the target mailbox is in the same AD site:

a. Then the CAS server will communicate to the mailbox server (via MAPI) and obtain the F/B information. 

4. The source CAS server will then provide the data back to the Outlook 2007 / Outlook Web Access 2007 client.

In addition, the Availability Web Service enables the user to share their calendar information in more granular ways. For each target person/group, the user can choose one of four levels of sharing:

1. Share nothing
2. Share their Free-Busy information
3. Share a little more detail including subject, location and timing
4. Full calendar details.

The Availability Service & Cross-Forest Topologies 

In previous generations of Exchange, allowing free/busy access between Exchange organizations was an arduous process involving a directory synchronization process and the use of an Exchange Support Tool, Inter-organization Replication Tool (IORepl). IORepl is a MAPI-based application that allows for the replication of public folder data between two organizations. 

With Exchange 2007, organizations can use the Availability Service to provide access to free/busy data without the need of data synchronization tool (however, you still need to have directory synchronization for address list related lookups).

Cross-forest availability can be used across trusted or untrusted forests. The granularity of free/busy information is determined by whether cross-forest free/busy has been configured as per-user or organization wide service.  Per-user free/busy is possible only in a trusted cross-forest topology and makes it possible for the availability service to make cross-forest requests on behalf of a particular user. This makes it possible for a user in a remote forest to grant detailed free/busy information to a cross-forest user.

However, with organization wide free/busy, the availability service can make cross-forest requests only on behalf of a particular organization.  With organization wide free/busy, a user’s default free/busy information is returned and it is not possible to control the granularity of free/busy information returned to users in the other forest.

So does this mean I can have multiple forests, not implement trusts, and not use IORepl and still get free/busy data? To answer that, let’s look at two scenarios:

1. Source and Target forests are using Exchange 2007
2. Source Forest is Exchange 2007 and Target forest is Exchange 2003

For #1, you could do this either via a trust or no trust.  When you have a trust you can do per-user lookups which can restrict the type of data returned (e.g. if target mailbox restricted F/B access for source mailbox, then restricted data is returned).  If there isn’t a trust, you define an account that can retrieve the data; the data returned is the default F/B data and doesn’t provide any granularity in terms of permission access).

For #2, you need to configure IORepl to replicate the data to the Exchange 2007 forest public folder hierarchy.  You then configure the availability service to retrieve the target organization’s data from the public store.

All of this really assumes the clients are utilizing Outlook 2007 or OWA 2007 as they are the only clients that can utilize the Availability service.  If the users are not going to be using Outlook 2007 then you’d be better off using IORepl. 

. 

Problems with Exchange Server 2007 Availability Service

After you have configured your Client Access Servers, and installed your organizations SSL certificate on IIS, you realize that users are not able to see the Free/Busy information for other users from Outlook 2003 or Outlook 2007.

Here are some of the symptoms:

When you try to create a new meeting request in Outlook using the scheduling assistant, you find that you are able to see free/busy information only for your own and not other users. Other users appear as ‘No information’. Under ‘suggested times’, in Outlook 2007, you find that it perpetually shows "loading". You may also receive a certificate error, concerning a name mismatch.

However, you are able to see the Free/Busy information for other users if you use Outlook Web Access (OWA).

The problem here is because of a certificate name mismatch. You have installed the certificate for your company’s webmail URL (webmail.company.com) on your Client Access server but your Outlook client is accessing it using the host’s FQDN, which results in the mismatch. If you have configured your internal DNS servers to resolve webmail.company.com directly to the CAS server (or the CAS NLB virtual IP), you can modify the InternalURL value by using the Set-WebServicesVirtualDirectory cmdlet. In the following command I am making the internalURL same as the externalURL.

Set-WebServicesVirtualDirectory -id:"EWS*" -ExternalUrl "https://webmail.company.com/ews/exchange.asmx" -InternalUrl "https://webmail.company.com/ews/exchange.asmx"

 

Before you do this, make sure your internal DNS servers are setup correctly to resolve webmail.company.com directly to the Client Access server(s). If you have multiple CAS servers in an NLB configuration, you will need to repeat the above command on all CAS servers.

Come back to Outlook and create a new meeting request with the Scheduling Assistant. Everything should be honky dory!

Backing up the Client Access Server

The data that needs protecting by backup for the Client Access server is located in several places:

• Exchange server configuration stored in Active Directory
• Configuration files stored in the file system (C:Program FilesMicrosoftExchangeClientAccess)
• IIS customizations stored in the IIS metabase

Similar to the Hub Transport server the Exchange server configuration can be recovered from Active Directory using the setup /m:RecoverServer command.  Assuming the Active Directory is already backed up by your Domain Controller backup strategy the Client Access server backups only need to take into account the configuration files in the file system and the IIS metabase.

However there is a downside to this.  When setup /m:RecoverServer is used to restore a Client Access server, and then the IIS metabase is restored afterwards, the Client Access server will experience errors.  Because of this, Microsoft recommends keeping a manual change log of all customizations made to the Client Access server, such as changes to the default virtual directories, or any new virtual directories created.

A workaround for this is to perform a full backup of the file system and System State for Client Access servers.  This allows you to restore the entire server without causing problems after the IIS metabase is recovered.

Recovering the Client Access Server

Since there are two approaches to backing up the Client Access server role there are also two approaches to recovery.

The first is to use setup /m:RecoverServer to reinstall Exchange on the replacement server.  Then, restore the C:Program FilesMicrosoftExchangeClientAccess files from the most recent backup.  Finally, manually apply all customizations that have been recorded in a change log.

The above method will work provided your change log is up to date and accurate.  Any discrepancies will potentially lead the recovery effort astray.  This method is also quite tedious and error prone in complex environments.

The second approach is to use a complete server backup for the restore.  In this scenario the new server is installed with the operating system only.  There is no need to join it to the domain or even to give it a static IP address provided a DHCP server is available.  Next, restore the last full server backup onto the server.  It is likely that the server will then require a restart.

This second approach is less effort and will tend to be more accurate but requires that more data be backed up each night than for the first method.

Publishing Exchange 2007 OWA with ISA Server 2006

We must start our configuration on the Exchange Server site. Start the Exchange Management Console (EMC), navigate to the Server configuration container, select the Client Access role and select the new OWA directory. The OWA directory is new in Exchange Server 2007 and will be used by OWA clients when they access Exchange Server 2007. You must enable Basic Authentication in the Authentication tab if it is not already configured.

                                             Figure 1: Enable Basic Authentication

On IIS site

Next we must issue a certificate from an internal CA or a commercial CA for the Default Web Site. After issuing the certificate, navigate to the OWA directory – go to the Directory Security tab and enable SSL and 128-bit encryption as you can see in the following figure.

                                           Figure 2: Enable SSL and 128-Bit encryption

On ISA site

Before we start the Exchange Webclient Access Publishing rule wizard we must request a certificate for the ISA Server Web Listener because we are using HTTPS-Bridging. ISA Server terminates the SSL connection from the OWA client, inspects the traffic and encrypts the connection to the Exchange Server again. The common name (CN) of the requested certificate must match the Name of the Server that OWA clients specify in their browsers. In this example the Public FQDN is OWA.IT-TRAINING-GROTE.DE so the CN of the certificate must be OWA.IT-TRAINING-GROTE.DE. You can request certificates via the CA servers webconsole (http://caservername/certsrv). You must request a Webserver certificate as shown in the following figure.

Please note:Depending on your ISA Server Firewall rules, you must create a Firewall rule that allows HTTP or HTPS access from your ISA Server to the CA Server.

                                               Figure 3: Advanced certificate request

Split DNS or HOSTS file?

The Public Name OWA.IT-TRAININGR-GROTE.DE in the OWA Web Listener must be resolvable to the internal Exchange Server IP adderss, so you have two options:

• Split-DNS or
• HOSTS file

If you are using Split DNS you must create a new Forward Lookup zone in DNS named IT-TRAINING-GROTE.DE. You must then create a new A-record named OWA in the new Forward Lookup zone with the IP Address of the internal Exchange Server.

If you are using the HOSTS file you only need to extend the file with an entry like this:

IP address of the Exchange Server   OWA.IT-TRAINING-GROTE.DE 

                                                      Figure 4: HOSTS file

Now it is time to create the Exchange Webclient Access Publishing rule.

Start the ISA MMC click - New  - Exchange Webclient Access Publishing Rule. Name the rule and select the Exchange Version and that you want to publish Outlook Web Acess.

                                               Figure 5: New OWA Publishing rule

Select Publish a Single Website or load balancer

In the next window of the Wizard select the option Use SSL to connect to the published Web server or server farm.

Enter the Name of the Internal Site Name. You can specify a NetBIOS servername or DNS FQDN.

Next you must enter the Public Name that Outlook Web Access users must use when they want to access the Outlook Web Access Server from the Internet. You can see the configuration in the next figure.

Figure 6: Enter the Public Name that OWA Clients use

New Web Listener

The next step in the wizard is to create a Web Listener. ISA Server uses Web Listeners to listen for incoming requests that match the Listener settings. A Web Listener is the combination of an IP address, a Port and, when using SSL, a certificate. You must give the Web Listener a unique name.

In the next window of the Wizard select Require SSL secured connections with clients.

You must specify the Web Listener IP Address. If the request comes from the Internet you must select the External Network. If your ISA Server has more than one IP Address bound to the External Network Interface you can select the IP Address used for Outlook Web Access.

                                            Figure 7: Specify the Web Listener network

Select the Certificate that you had requested from the internal CA server and click Next.

                                           Figure 8: Select the Certificate for the Listener

Because we are using forms based Authentication with Outlook Web Access, you must select HTML Form Authentication and Windows (Active Directory) for Authentication validation.

                                             Figure 9: Select HTML Form Authentication

Single Sign On (SSO) is one of the new features in ISA Server 2006 that allows clients to access different Published sites without the requirement of reauthentication. We don’t need SSO in this example so you can disable it.

Select Basic Authentication because ISA Server will use this Authentication type to authenticate the Outlook Web Access clients to the published Exchange Server.

                                             Figure 10: Authentication Delegation

The last step in the Wizard is to specify the user group for which the Firewall rule applies to. The default setting is “All Authenticated Users”.

Finish the Wizard and Click Apply to save the settings.

After creating the OWA rule you should change some settings:

• Change “Requests appears to come from the original Client” in the “To” Tab
• Enable “Require 128 Bit encryption for HTTPS Traffic” in the “Traffic” Tab

Navigate to the Listener Properties and select the Forms tab. Under Password Management enable Allow users to change their Passwords.

Test the Client Connection

After successfully configuring Exchange Server 2007 and the Exchange Webclient Publishing rule you can test the connection from one of your clients. For this article the client is a Windows XP Service Pack 2 machine.

Figure 11: OWA FBA from a XP client

How to Test Outlook 2007 Autodiscover Connectivity

• Run the following command:

Test-OutlookWebServices -ClientAccessServer "CASServer01"

Services Used by a Client Access Server

W3SVC

World Wide Web Publishing Service

This service is required and must be started.

MSExchangeADTopology

Microsoft Exchange Active Directory Topology Service

This service provides Active Directory topology information to several Exchange Server components. This service does not have any dependencies.

POP3Svc

Microsoft Exchange POP3

By default, this service is stopped. For clients to use POP3 to connect to Microsoft Exchange, this service must be started. This service depends on the Microsoft Exchange Active Directory Topology service.

IMAP4Svc

Microsoft Exchange IMAP4

By default, this service is stopped. For clients to use IMAP4 to connect to Microsoft Exchange, this service must be started. This service depends on the Microsoft Exchange Active Directory Topology service.

IISAdmin

Internet Information Services Admin Service

This service manages the Internet Information Services (IIS) metabase and provides support for the World Wide Web Publishing Service (W3SVC) service, the POP3 service, and the IMAP4 service, which are required by the Client Access server. IIS Admin also supports other applications, such as the metabase update service, which is an internal component of the system attendant.

MSExchangeServiceHost

Microsoft Exchange Service Host

This service configures the RPC virtual directory in IIS and registry data for Outlook Anywhere. This service depends on the Microsoft Exchange Active Directory Topology service.

MSExchangeFDS

Microsoft Exchange File Distribution Service

This service is used to distribute offline address book and custom Unified Messaging prompts. This service depends on the Microsoft Exchange Active Directory Topology service and the Workstation service.

How to Enable the Auto-Processing of Meeting Messages

To use the Exchange Management Shell to enable the auto-processing of meeting messages

• Run the following command:

Set-MailboxCalendarSettings -Identity "Ellen Adams" -AutomateProcessing:AutoUpdate

How to Remove Out-of-Date Meeting Requests and Responses

To use the Exchange Management Shell to remove out-of-date meeting requests and responses

• Run the following command:

Set-MailboxCalendarSettings -Identity "Ellen Adams" - RemoveOldMeetingMessages:$true

Troubleshooting the Free/Busy State

The calendar information which is provided to your users is produced by the Availability service. This information is also known as the free/busy information. Outlook clients use the availability service to get their Free/Busy information and the availability service gets its information from the Autodiscover service. External and internal URL information is located by the Autodiscover service and then passed to the Outlook clients. When there is a problem with the Autodiscover service or the Availability service then your end users will not be able to see the calendar information of other Outlook users in the Exchange server environment.

Administrators can use Outlook 2007 to determine whether the Autodiscover service is unable to provide information to clients. To see if there is a problem with the Autodiscover service an administrator can log on to the user’s mailbox that is having the connection problem and then run the steps outlined below:

1. From Outlook 2007 open the Tools menu.
2. Click Options, then click the Other tab, and then click Advanced Options.
3. From the Advanced Options page, select Enable logging, and then click OK.
4. Restart Outlook 2007.
5. Try to view the free/busy state for another user.
6. From the Microsoft Windows desktop, click Start, Run, and then type %temp% into the text field.
7. From Windows Explorer, open the olkdisc.log file and locate the files in the olkas directory.
8. Here you will usually find information about the service that is most likely not functioning properly.

If Outlook 2003 users are unable to publish their free/busy state in Exchange Server 2010, or in Exchange Server 2007, and hash marks are appearing in the free/busy state for these users then administrators may see the following event in the Application log:

Event ID : 8207
Category : General
Source : MSExchangeFBPublish
Type : Error
Message : Error updating public folder with free/busy information on virtual machine <Exchange2007ServerName> . The error number is 0×80004005

Administrators can try to clear the free/busy state information by running the following command:  “Outlook /cleanfreebusy”.

If they receive another error message such as “Unable to clean your freebusy information” then it is most likely the result of having migrated from a previous version of Exchange. It is also possible that a new Exchange Server 2010 or Exchange Server 2007 organization was installed. The reason why this happens is because the Exchange Server 2010 or the Exchange Server 2007 organization contains no replicas of at least one free/busy folder.

An administrator can fix this problem by following the steps outlined below:

1. Bring up the Exchange Management Shell and run the following command: get-publicfolder -Identity “NON_IPM_SUBTREESCHEDULE+ FREE BUSY” -Recurse | fl name,Replicas                                                                (Note that an Exchange 2010 server or an Exchange 2007 server in not listed as a replica for at least one of the SCHEDUE+ FREE BUSY folders. An example of a missing SCHEDUE+ FREE BUSY folder may be displayed such as: Name : EX:/o=contoso/ou=Exchange Administrative Group (FYDIBOHF23SPDLT) Replicas : {}
2. Bring up the Exchange Management Shell and run the following command: set-publicfolder -Identity “NON_IPM_SUBTREESCHEDULE+ FREE BUSY<Name of Folder>” -replicas “<Target PF Database>”              Example                                                                                                                                                                                                       ———–                                                                                                                                                                                     Set-publicfolder –identity “NON_IPM_SUBTREESCHEDULE+ FREE BUSYEX:/o=contoso/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)” –Replicas “ServerStorage GroupPublic Folder Database”
3. Using the command from step 1 above verify that the public folder group now has a replica. If the public folder group has a replica object you will see something similar to the following:                                                        Name : EX:/o=contoso/ou=Exchange Administrative Group (FYDIBOHF23SPDLT) Replicas : {Public Folder Database}

All users must accept or decline a meeting request to populate the free/busy data if their free/busy data is not populated.

Another possible situation that can adversely affect the free/busy state is in a Microsoft Exchange Server 2003 and Exchange Server 2007 coexisting environment. Some free/busy messages are not successfully replicated from Exchange 2007 servers to Exchange 2003 servers after some mailboxes have been migrated from an Exchange 2003 server to an Exchange 2007 server. Administrators will notice that the updated free/busy messages of the migrated users are not available on the Exchange 2003 server.

Administrators will see the following error logged in the application event log of the Exchange 2003 server:

Event Type: Error Event Source: MSExchangeFBPublish Event Category: General Event ID: 8207 Description: Error updating public folder with free-busy information on virtual machine <server name>. The error number is 0×80070057.

Administrators can correct this problem by installing the Update Rollup 6 for Exchange 2007 Service Pack 1.