When utlizing Outlook 2007 the autodiscover service is heavily tied into Outlook anywhere functionality, I am going to reference a previous posting that explains those functions in detail.
http://exchange-genie.blogspot.com/2007/07/autodiscover-ad-attribute.html

With Exchange 2007 in order to allow clients remote access to the mail system you will need to install an Exchange 2007 CAS server which will allow clients to access thier mail via Imap,Pop,OWA,Active Sync, and Rpc/https (outlook anywhere).

For this article I am going to skip the installation of each server role and just work with the configuration. The lab consists of 1 DC, 1 CAS/Hub and 1 MBX server running Windows 2003 and Exchange 2007 SP1.

Rpc/http was first introduced with Exchange 2003 and has been renamed with Exchange 2007 to Outlook Anywhere. In order to use this functionality with Exchange we must install the RPC over HTTP Proxy networking component on a server (recommened on your Exchange server).

What does this network componet do for us?
RpcProxy.dll is an Internet Server API (ISAPI) that runs in Internet Information Services (IIS). RpcProxy.dll listens for activity on the RPC virtual directory

The rpcproxy.dll requires authentication and will not pass anonymous request even if IIS is configured for anonymous authentication.

When an Outlook clients typicaly communicates with an Exchange server the client attempts to connect via Mapi Rpc, with Rpc/http Outlook makes a http connection to the rpc proxy server which strips the http and send the rpc request to tha appropriate Exchange server.

Installing Rpc/http networking componet:
1. From the Add/Remove programs select Windows components
2. Select Networking Services then details

3. Select Rpc over http proxy -> OK

4. Click Next to start the installation
5. Click Finish to complete the installation

How do we verify the installation?
1. Validate you have 2 virtual directories installed called RPC and RPC with Cert
The 2 new virtual directories points to C:\WINDOWS\System32\RpcProxy which is the location of the rpcproxy.dll

2. Verify the RPC Proxy server extension is allowed in IIS (this will be enabled after you install the component)

Later we will look at a tool called rpc dump that can be used to troubleshoot connectivity problems.

After we have installed our CAS server we need to enable Outlook Anywhere which can be done in 1 of two ways, 1. EMS (command line) or 2. EMC (gui)

1. EMS
To work with Outlook anywhere via EMS we would use the the following set of commands Get-OutlookAnywhere,Set-OutlookAnywhere,Enable-OutlookAnywhere.

A. Open EMS
B. Now we will use the Enable-OutlookAnywhere command to enable this feature
–The following switches are available for the command
** Pre SP1
Enable-OutlookAnywhere -DefaultAuthenticationMethod -ExternalHostname -SSLOffloading <$true $false> [-Confirm []] [-DomainController ] [-Server ] [-TemplateInstance ] [-WhatIf []]
** Post SP1
Enable-OutlookAnywhere -ClientAuthenticationMethod -ExternalHostname -SSLOffloading <$true $false> [-Confirm []] [-DomainController ] [-IISAuthenticationMethods ] [-Server ] [-TemplateInstance ] [-WhatIf []]

For this demo I used the following command
[PS] C:\>Enable-OutlookAnywhere -Server vmcashub -SSLOffloading:$false -ExternalHostname vmcashub.vn.local -ClientAuthenticationMethod basic -IISAuthenticationMethods basic

*Note if you use the defaultauthenticationmethod is will override the clientauth and IISAuth **
*Setting the ClientAuthMethod is what autodiscover will user to configure the client*

Enable-OutlookAnywhere
http://technet.microsoft.com/en-us/library/bb124993%28EXCHG.80%29.aspx

We can ouse the Get-OutlookAnywhere command to view our configuration
Get-OutlookAnywhere
http://technet.microsoft.com/en-us/library/bb124263%28EXCHG.80%29.aspx

Once we have enable Outlook Anywhere any future modification will be done with the Set-OutlookAnywhere command (i.e. changing authentication)
Set-OutlookAnywhere http://technet.microsoft.com/en-us/library/bb123545%28EXCHG.80%29.aspx

2. EMC
a. Open EMC –> Server configuration –> client Access Server
b. Select the CAS server you want to enable
c. Click the button to Enable Outlook Anywhere

d. Enter the External name that clients will use to connect to your Exchange Server, note this name should match the name on your certificate. Select the authentication method of choice

e. On the Completion Wizard Click finish

As you saw there is very little configuration when enabling Outlook Anywhere we have 3 options
1. Url 2. authentication and 3. Enable SSL offloading

Once we have Enabled Outlook Anywhere we can validate the registry key has configured correct ports for communication to our mailbox servers. Note only the name listed in the key can be used by clients to connect and you will notice there is no IP address listed so testing via IP will fail through the rpc proxy.

1. Click start Run
2. Regedit – this will open the registry editor
3. HKEY_LOCAL_MACHINE\Software\Microsoft\Rpc\RpcProxy
4. Notice the Dword called Enabled set to 1
5. There is a String value called “ValidPorts”
VMMBX1:6001-6002;VMMBX1:6004;vmmbx1.vm.local:6001-6002;vmmbx1.vm.local:

**Note if the port are not listed it could take up to 15 minutes to update or you can restart the Microsoft Exchange Service Host **
we can see that the rpc proxy connects to our mailbox server on the following port 6001-6002 and 6004. Each port is defined below

Microsoft Exchange Information Store service: 6001
referral service of DSProxy: 6002
proxy service of DSProxy: 6004
Active Directory (if the global catalog server and Exchange Server are on the same server): 6004

In our client testing we can validate the proxy making connections to our mailbox server with these ports.

Configure a client:
Manually
1. Create a New profile
2. check the manually configure box at the bottom

3. Select Microsoft Exchange

4. Input your mailbox server name (this could be FQDN or Netbios Name)

5. Click the “More settings” button

6. Select the connections tab

7. Check the box “Connect to Microsoft Exchange using HTTP” -> Exchange Proxy Settings

8. Input the url of your Outlook Anywhere server, check the appropriate authentication

9. Click OK and finish the profile

2. Autodiscover
** if autodiscover is not working please refer to my blog on autodiscover **
http://exchange-genie.blogspot.com/2007/07/autodiscover-ad-attribute.html

1. Click Add

2. Give a name for the profile

3. Input the display name and users email address and password
**Note a domain logged on user will auto populate the information**

5. Logon to your mailbox

6. Click Finish

Validation:
That we have installed all the components we need to do some testing to validate we have access to our mail.

Check Outlook connection status:
1. Log onto Outlook
2. in the System tray hold the CTRL key and right click the Outlook icon
3. select connection status

You can see our connection shows https, which validates we are going through the CAS server and proxying our connection.

Netstat:
We can use netstat to show our connection for each hop Client-> CAS -> Mbx -> DC

Open a command windows on the CAS server and type netstat -na

You can see from the screen shot above that our client 192.168.1.5 is making connections are port 443 to our CAS server 192.168.1.101

As noted in the connections window from Outlook you can see that the Outlook client makes multiple connections to the CAS server on port 443 and this is validated in the netstat

CAS -> MBX
On the mailbox server open a command window and type Netstat -na

The first item to note is our mailbox server listening on ports 6001,6002, and 6004 which is the ports used by rpc/http to make connections

Below you can see our mbx server 192.168.1.102 receiving connections on port 6001 and 6004 from our CAS server 192.168.1.101

MBX -> DC
On our domain controller we can see Ldap 389 and GC 3268 ports with connections from both our CAS server and MBX server.

Packet Captures:
We can use a tool like NetMon or WireShark to perform network captures on each hop as well to validate our traffic between each node. We must note this is encrypted traffic so we will only see sessions between the nodes

This capture is run on the XP client and we can see TLS communication between our client 192.168.1.5 and our CAS 192.168.1.101

This capture show communication from the CAS 192.168.101 to the mailbox server on port 6001/6004

See the highlighted section showing a destination port 6001 from the CAS to the MBX server

See the highlighted section showing a destination port 6004 from the CAS to the MBX server

Mailbox Server -> DC/GC
Below we can see our mailbox server making connections to the DC Ldap port 389

RPCPing:

RpcPing is a utility that we can use to troubleshoot or validate that our rpc proxy is working properly.
Rpc ping is a command line tool that can be found in the Windows 2003 resource kit http://www.microsoft.com/downloads/details.aspx?FamilyID=9d467a69-57ff-4ae7-96ee-b18c4790cffd&DisplayLang=en We can use this tool to test rpc connectivity through an rpc proxy server which is used for Outlook Anywhere.

You can use this MS article to assist with this utility http://support.microsoft.com/kb/831051

1. Open a command line to the resource kit directory

2. Lets connect to port 6001 =store

rpcping -t ncacn_http -s vmmbx1.vm.local -o RpcProxy=mail.vm.local -P “brian.tirch,vm.local,*” -I “brian.tirch,vm.local,*” -H 1 -F 3 -v 3 -B msstd:mail.vm.local -e 6001 -u 10 -a connect

You can see we make a successful connection

3. Lets connect to port 6004 =DsProxy

rpcping -t ncacn_http -s vmmbx1.vm.local -o RpcProxy=mail.vm.local -P “brian.tirch,vm.local,*” -I “brian.tirch,vm.local,*” -H 1 -F 3 -v 3 -B msstd:mail.vm.local -e 6004 -u 10 -a connect

You can see we make a successful connection

These tests show us that we are properly connecting through the rpc proxy server to the correct ports associated with Outlook Anywhere.

reference the above MS article for a break down of the switches.

PerfMon:
Windows 2008 has added some additional perf counters that we can use with Rpc/Proxy that can assist in identifying connectivity and user load.

common issues:
1. Certificates – If the client machine does not trust the certificate that is being presented it will fail to connect. So if you are using self signed or self issued certificates you will need to deploy them to each client machine

http://technet.microsoft.com/en-us/library/bb124149%28EXCHG.80%29.aspx

 

For this blog I used a simple setup with 1 CAS/Hub and 1 MBX server, this blog does not cover all the configurations and thier options but goes into detail about Exchange 2007 Autodiscover service.

There are 4 ways to get autodiscover to function:
1. Set the SCP to the url of the autodiscover server (this will work for domain joined machines)
2. DNS/HTTP
3. Deploy an Xml file to the users machine which also requires registry changes on the client
4. DNS SRV records (requires Outlook 2007 SP1)

There are a number of setting when it comes to configuring autodiscover and its associated components:

By default Exchange creates the 2 virtual directories on the CAS server that are needed for the autodiscover and availability service, however there is no gui interface to manage these services and all management must be done from EMS (exchange management shell)

- EWS – Exchange Web Services and Autodiscover — for autodiscover service

Lets start from the begining:

SERVICE CONNECTION POINT – SCP

———————————————–
The SCP informtion can be found using LDP or Adsieidt, for this blog I will use Adsiedit in my examples:
Open the Configuration container to the following path:
CN=Services, CN=Microsoft Exchange,CN=First Organization (your org name),CN=Administrative Groups,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Servers,CN=YourServer,CN=Protocols,CN=Autodiscover,

By default the SCP will be set to Https://yourserverfqdn/autodiscover/autodiscover.xml

How can the SCP be manged?

Currently there is no gui interface to manage the SCP setting however we can use the new EMS.
1. Open EMS
2. Get-clientAccessServer ¦ fl Name,AutoDiscoverServiceInternalUri

The get command will allow us to view the current SCP for a given server or all servers.

To set the SCP we use the commandlet: Set-ClientAccessServer -Identity vmcashub -AutoDiscoverServiceInternalUri “https://mail.vm.local/autodiscover/autodiscover.xml”
** Note: You can leave this as the internal servername unless you have an NLB that you want to take advantage of**

and we can validate our change with the get command:
Get-clientAccessServer ¦ fl Name,AutoDiscoverServiceInternalUri

Now that the SCP is set domain joined clients could use the autodiscover service however there are some additional components are tied to the autodiscover serivce like Offline address book, UM, availability.

Lets use the Test-OutlookWebServices commandlet and see what happens
Test-OutlookWebServices -identity Brian.Tirch
**Note if you don’t specify an identity the system will choose a user

Id : 1003Type : InformationMessage : About to test AutoDiscover with the e-mail address Brian.Tirch@vm.local.
Id : 1018Type : InformationMessage : The SSL certificate on mail.vm.local is self-signed.
Id: 1006Type : InformationMessage : Contacted AutoDiscover at https://mail.vm.local/autodiscover/autodiscover.xml.
Id: 1018Type : InformationMessage : The SSL certificate on vmcashub.vm.local is self-signed.
Id : 1016Type : SuccessMessage : [EXCH]-Successfully contacted the AS service at https://vmcashub.vm.local/EWS/Exchange.asmx.
Id : 1015Type : SuccessMessage : [EXCH]-Successfully contacted the OAB service at https://vmcashub.vm.local/EWS/Exchange.asmx.
Id : 1014Type : SuccessMessage : [EXCH]-Successfully contacted the UM service at https://vmcashub.vm.local/UnifiedMessaging/Service.asmx.
Id : 1006Type : SuccessMessage : Successfully tested AutoDiscover.

Let take a look at the Output:
1. The first return shows the user that is being used to test autodiscover
InformationMessage : About to test AutoDiscover with the e-mail address Brian.Tirch@vm.local.
2. Exchange creates self signed certificates during installation (from here on out I will skip this message)
Id : 1018Type : InformationMessage : The SSL certificate on mail.vm.local is self-signed.
3. The system connects to the SCP to find the autodiscover service
Id: 1006Type : InformationMessage : Contacted AutoDiscover at https://mail.vm.local/autodiscover/autodiscover.xml.
4. The availability service is contacted
Id : 1016Type : SuccessMessage : [EXCH]-Successfully contacted the AS service at https://vmcashub.vm.local/EWS/Exchange.asmx.
** note the url- this is the fqdn of the server and we have not modified this yet

5. The OAB url is checked
Id : 1015Type : SuccessMessage : [EXCH]-Successfully contacted the OAB service at https://vmcashub.vm.local/EWS/Exchange.asmx.
** note the url- this is the fqdn of the server and we have not modified this yet and would cause problems for external users
6. The UM serverurl is checked
Id : 1014Type : SuccessMessage : [EXCH]-Successfully contacted the UM service at https://vmcashub.vm.local/UnifiedMessaging/Service.asmx.
** note the url- this is the fqdn of the server and we have not modified this yet and would cause problems for external users
7. The process completes succuess
Id : 1006Type : SuccessMessage : Successfully tested AutoDiscover.

The test looks good and users will be able to use autodiscover service (AS).

The following services can be set from the gui or from EMS in this example I will use EMS:
OAB
UM
—-EMS Only
EWS

We need to set the internal and external urls, by default the internal url is set to the fqdn of the server.

Lets start with EWS (Exchange web services) which controls the availability service
EWS
Get-WebServicesVirtualDirectory ¦ fl name,internalurl,externalurl
Name : EWS (Default Web Site)InternalUrl : https://vmcashub.vm.local/EWS/Exchange.asmx
ExternalUrl :
from the output we see the external url is not set and the internal is set to the server fqdn which will work for internal clients however we want to use our external name of mail.vm.local for our configuration.

Here I am piping the get command to the set command which will set all my Web services virtual directories at once instead of one by one:
Get-WebServicesVirtualDirectory set-WebservicesVirtualDirectory -intrnalurl https://mail.vm.local/EWS/Exchange.asmx -externalurl https://mail.vm.local/EWS/Exchange.asmx
**Note if you are not using an NLB then you can leave the internal settings to the default.

Lets verify this by running the get again:
Get-WebServicesVirtualDirectory ¦ fl name,internalurl,externalurl
Name : EWS (Default Web Site)
InternalUrl : https://mail.vm.local/EWS/Exchange.asmx
ExternalUrl : https://mail.vm.local/EWS/Exchange.asmx
**You do not need to set external urls on non internet facing CAS servers

Repeat the steps with the commands below:

Offline Address Book
Get-OabVirtualDirectory ¦ fl Server,Name,internalurl,externalurl
Server : VMCASHUB
Name : OAB (Default Web Site)
InternalUrl : http://vmcashub.vm.local/OAB
ExternalUrl :

Set-OabVirtualDirectory -Identity “vmcashub\oab (default web site)” -InternalUrl https://mail.vm.local/oab -ExternalUrl https://mail.vm.local/oab

Get-OabVirtualDirectory ¦ fl Server,Name,internalurl,externalurl
Server : VMCASHUB
Name : OAB (Default Web Site)InternalUrl : https://mail.vm.local/oab
ExternalUrl : https://mail.vm.local/oab

Unified Messaging:
Get-UMVirtualDirectory ¦ fl Name,Server,Internalurl,externalurl
Name : UnifiedMessaging (Default Web Site)
Server : VMCASHUBInternalUrl : https://vmcashub.vm.local/UnifiedMessaging/Service.asmx
ExternalUrl :

set-UMVirtualDirectory -Identity “vmcashub\UnifiedMessaging (Default Web Site)” -InternalUrl https://mail.vm.local/UnifiedMessaging/Service.asmx -ExternalUrl https://mail.vm.local/UnifiedMessaging/Service.asmx

[PS] C:\>Get-UMVirtualDirectory ¦ fl Name,Server,Internalurl,externalurl
Name : UnifiedMessaging (Default Web Site)
Server : VMCASHUBInternalUrl : https://mail.vm.local/UnifiedMessaging/Service.asmx
ExternalUrl : https://mail.vm.local/UnifiedMessaging/Service.asmx

Now that we have set all the directories lets rerun our TEST-OutlookWebService

C:\>Test-OutlookWebServices -Identity brian.tirch fl
Id : 1003Type : InformationMessage : About to test AutoDiscover with the e-mail address Brian.Tirch@vm.local https://mail.vm.local/autodiscover/autodiscover.xml
.
Id : 1016Type : SuccessMessage : [EXCH]-Successfully contacted the AS service at https://mail.vm.local/EWS/Exchange.asmx

id : 1015Type : SuccessMessage : [EXCH]-Successfully contacted the OAB service at https://mail.vm.local/EWS/Exchange.asmx
.
Id : 1014Type : SuccessMessage : [EXCH]-Successfully contacted the UM service at https://mail.vm.local/UnifiedMessaging/Service.asmx.

Id : 1006Type : SuccessMessage : Successfully tested AutoDiscover.
An alternate way for clients to find the autodiscover service is to create an entry in DNS. Outlook 2007 looks at two urls by default to attempt to locate the autodiscover service.
The client locates the Autodiscover service on the Internet by using the primary SMTP domain address from the user’s e-mail address. The Autodiscover service will query DNS for either https://primarysmtpdomain/autodiscover/autodiscover.xml or https://autodiscover.primarysmtpdomain/autodiscover/autodiscover.xml.

Configure Autodiscover via DNS
————————————–

When an Exchange 2007 CAS server is installed a virtual directory for autodiscover is created. We must use EMS to configure the urls for the autodiscover vdirs

*** we already set the information for the OAB, UM, and availability so those steps will not be repeated but all steps done under the SCP section would need to be done as well

1. Open EMS
2. use Get-autodiscovervirtualdirectory ¦ fl
This will return all autodiscover vdirs and their information, in a large organization you may want to specify the -Server switch to return only the server of interest

[PS] C:\>Get-AutodiscoverVirtualDirectory ¦ fl Name,internalurl,externalurl
Name : Autodiscover (Default Web Site)
InternalUrl :
ExternalUrl :
** Note this am current bug that the urls are exposed. The autodiscover information is pulled form the SCP or the 2 deafult urls.

Depending of the url of your choice the appropriate record must be created in DNS for either
https://primarysmtpdomain/autodiscover/autodiscover.xml or https://autodiscover.primarysmtpdomain/autodiscover/autodiscover.xml.

I typically use https://autodiscover.primarysmtpdomain/autodiscover/autodiscover.xml

Create an (A) record called Autodiscover
Verify internal and external users resolve this to the appropriate Server

Now that we have created the DNS record and set the Autodiscover urls we need to test a remote client.

I have configured a Windows XP Pro client running Outlook 2007 that is not domain joined to test Autodiscover.

1. Lauch Outlook 2007
2. Input the client information

3. Select Next

4. We are prompted for a certificate message

** This was a lab envrionment and self signed certs should not be used in with production systems.

** Note the url is looking for https://autodiscover.vm.local however by default the autodiscover website is underneath the default web site that is tied to mail.vm.local for OWA, OOF , etc… to resolve this we need to remove the autodiscover site from the default website and create an additional website and associate a certificate for autodiscover.vm.local to that site or utilize a wildcard certificate or SAN cert

http://technet.microsoft.com/en-us/library/aa995942.aspx

5. We are prompted to Logon to MBX server

6. Process completes successful

Now that we have tested Autodiscover lets validate that our client can contact the other services tied to Autodiscover: Availability, UM, OAB

1. Open Outlook 2007

2. Hold the Control Key and Right click the Outlook Icon in the system tray

3. Select Test Email AutoConfiguration

4. Input the users email address and credentials ( I like to remove the guess smart and Secure Guess smart authentication to narrow the search scope for my needs)

 
Lets look over the output

Select the Log tab

We can see that autodiscover attempts the 2 urls first https://vm.local/autodiscover/autodiscover.xml and https://autodiscover.vm.local/autodiscover/autodicover.xml

Since we Created an A record in DNS for Autodiscover.vm.local we in the log a succeeded when contacting the url.

Next let’s select the results tab

From this we get lots of good output and can see that all the urls are set and everything appears to be working properly. We can perform some additional tests to check OOF, OAB, and Availability but will leave those for the last section.
Deploying an XML file:
————————-

There are a number of scenarios that can come into play that would cause issues with the first two methods that I have described above. A common scenario relates to mergers between companies. Lets say Company A has a namespace of CompanyA.com and purchases Company B with a namespace of CompanyB.com. Since these are now all assets of Company A, their primary STMP address will be CompanyA.com for both entities. Company A is running Exchange 2003 and Company B has Exchange 2007.

What is the problem you say…… Outlook 2007 will always attempt to use the primary SMTP address of the user when attempting to locate autodiscover information. Since all primary addresses are now CompanyA.com Outlook will attempt to find the information at that address.

What can be done?

Outlook 2007 allows an XML file to be deployed to the users machine and can be configured to check the local file first. This XML file can specify the url of the appropriate autodiscover server.

Sample XML

What steps need to be take to use the local XML file?

1. Modify the follow Registry information on each client machine
***Note be careful when making changes to the registry****

A. Hkey_current_user –> Software –> Microsoft –> Office –> 12.0 –> Outlook -> autodisover

** you will find a number of built in xml file installed with Outlook
** You can also add the following registry key to force Outlook to prefer the xml file
HKCU\Software\Microsoft\Office\12.0\Outlook\AutodiscoverDWORD: PreferLocalXML = 1

B. create a String Value called yournamespace i.e madeup.com

C. Set the path to Drive\autodiscover\autodiscover.xml ( or whatever path you choose)

D.create the autodiscover folder in the path listed above

E Deploy the XML file to the clients machine

For this test I have changed the primary smtp address of my user to Brian.tirch@madeup.com this address is not resolvable by my client.

Lets test autodiscover now:

We can see Outlook attempted to contact the 2 urls for madeup.com but fails.

The highlighted sections show the redirect from our local file which directs the client to https://autodiscover.vm.local/autodscover/autodiscover.xml and is successful
** Note we can make an additional registry change so that the local file is checked first **

Now select the Results tab:

From the highlighted section we can see the url was found via redirect and all associated urls are configured correctly

Lets test some features to verify functionality.

1. Send a meeting request and check attendees availability

We can see that the availability service is working since Jim Mcbee is showing busy.

2. Check OOF

If OOF is not functioning properly it will not bring up the away message information after selecting tools –> Out of Office assistant

SRV Record
Outlook 2007 has been recently updated (http://support.microsoft.com/kb/940881 ) to allow the user of SRV records as well, this can elminate the need to additional certificates.

Create an SRV record
Service: _autodiscoverProtocol: _tcpPort Number: 443Host: mail.YourPrimarnySMTP

Outlook client will not perform the following lookup

1. Autodiscover posts to https://YourPrimarySmtp/Autodiscover/Autodiscover.xml. This fails.

2.Autodiscover posts to https://autodiscover.YourPrimarySmtp/Autodiscover/Autodiscover.xml . This fails.

3.Autodiscover performs the following redirect check:
GET http://autodiscover.YourPrimarySmtp/Autodiscover/Autodiscover.xml This fails.

4.Autodiscover uses DNS SRV lookup for _autodiscover._tcp.YourPrimarySmtp, and then “mail.YourPrimarySmtp” is returned. (or whatever url you choose)

5. Outlook asks permission from the user to continue with Autodiscover to post to https://mail.YourPrimarySmtp/autodiscover/autodiscover.xml.

6.Autodiscover’s POST request is successfully posted to https://mail.YourPrimarySmtp/autodiscover/autodiscover.xml

Can you force clients to a particular server?

Yes, you can use the following commands to forces server information for autodiscover however
The following information describes a function that can be done, but is not recommended.

The Set-OutlookProvider commandlet will override any automatic values that the client would receive and can force configuration of a number of items.

these attributes can be viewed in Adsiedit with the following steps
1. Open Adsiedit
2. Expand configuration
3. Services
4. Microsoft Exchange
5. Organization name
6. Client Access
7. Autodiscover
8. Outlook
9. On the properties of EXCH,WEB,EXPR
- msExchAutoDiscoverServer which specifies the server name.
- msExchAutoDiscoverCertPrincipalName
and a variety of attributes can be set….

Set-OutlookProvider –id -Server myValueHere

If this value is set (and you never should), it will always override the automatically computed value for the provider. If it’s EXCH, it will override the Exchange server that’s populated in your profile. If it’s EXPR, it will override the RPCProxy server pushed out by Autodiscover.

To fix it, unset it:

Set-OutlookProvider EXCH –Server $null
Set-OutlookProvider EXPR –Server $null

How to Test configuration:
There are a few ways to test autodiscover after all the configuration is completed:
http://msexchangeteam.com/archive/2007/04/30/438249.aspx
http://www.exchangeninjas.com/AvailabilityServiceFAQ
http://technet.microsoft.com/en-us/library/b03c0f21-cbc2-4be8-ad03-73a7dac16ffc.aspx

1. From EMS run the following command
— Test-OutlookWebServices -ClientAccessServer “CASServer01″

2. From Outlook 2007

a. Open Outlook 2007

b. hold the control button and right click the icon in the system tray, select test email autodiscover

additional links