Sembee Blog of Exchange MVP Simon Butler

An interesting little issue with a client's configuration caused a problem recently.

The problem only affected users off site using Outlook Anywhere. While they could get their email correctly, the availability service didn't. This stopped Out of the Office from working correctly unless OWA was used, or the end user was in the office.  

This particularly configuration uses a Client Access Server in a data centre, which proxies over a site to site VPN in to the main office where another CAS, plus the mailboxes are actually located. Therefore the issue had to be around a configuration difference between the two servers. 

Running 

get-clientaccesserver servername |fl 

on the server in the data centre and comparing it to the server in the main office, showed that the value for AutodiscoverSiteScope was populated with the AD site for the main office. This was because the server in the data centre had been built in that location initially and then moved. 

Removing that entry so it was blank resolved the issue:

Set-clientaccessserver servername -AutodiscoverSiteScope $null 

A five minute fix resolved an annoying problem for the end users. 

The default behaviour of Outlook with regards to sent items continues to come up on forums as an issue.

By default, when you send an email using the From field via your Send As permissions, the item you have sent goes in to your own Sent Items folder. This is because you sent it, not the person whose mailbox it was sent from. This can be useful from a tracking point of view (who sent the email).

However it may also be useful for the item to be stored in the Sent Items folder of the Shared Mailbox so that other users or even the mailbox owner can see what was sent.

How you achieve this depends on the version of Outlook that you are running. The version of Exchange doesn't matter.

For Outlook 2003 and 2007, a registry change is required, following the installation of an update. If you are keeping the machines up to date, then further updates should not be required.
These registry changes are outlined in the following articles:

Outlook 2007
http://support.microsoft.com/kb/972148
Requires Outlook 2007 Hotfix: 970944
http://support.microsoft.com/kb/970944/

Outlook 2003
http://support.microsoft.com/kb/953804/
Requires Outlook 2003 Hotfix: 953803
http://support.microsoft.com/kb/953803/

For older versions of Outlook, you will need to look at third party tools. The only one that I am aware of are the tools from Ivasoft: http://www.ivasoft.biz/

For OWA, you will need to use a server side tool, again the third party tools from the above site are the only ones that I am aware of - and support for latest version of Exchange isn't available.

For Outlook 2010, no registry change is required, you just need to add the mailbox in a different way.
Instead of adding the mailbox as an additional mailbox through the Properties of the primary mailbox, add the additional mailbox as an additional Account. That means going through the new Account wizard again. This feature also allows you to have connections to another mailbox in another Exchange forest at the same time - I have used this to migrate public folders (see http://blog.sembee.co.uk/post/Cross-Forest-Public-Folder-Migration.aspx)

However if you are using Outlook 2010, you should also be aware of the issues  in this KB article: http://support.microsoft.com/kb/2297543 (Performance problems when you try to access folders in a secondary mailbox in Outlook 2010).

(Late posting because I forgot to press publish).

Anyone who has done a cross forest public folder migration will almost certainly be reliving their nightmares about it simply from reading the title.
I was just the same.

Extract the content to a PST file, either manually (selecting about 1000 items at a go) or by using a rule, move the PST file to a machine in the new forest, then import.

Slow, mind-numbing dull and therefore not the most fun part of a migration and always the bit that I don't look forward to. 

However a recent migration was done almost completely hands free. I moved almost 9gb of data in an afternoon, while I went to the cinema.

To do this, I took advantage of the new feature of Outlook 2010 that allows it to connect to two different Exchange organisations at the same time.

This allowed me to create a rule to move the content between the two public folders. Once the rule was set, I left it to get on with it. The speed wasn't great, but compared to moving it manually, it was a considerable time saver. After returning from cinema I was able to do more of the migration work, while I waited for the rule to finish.
Furthermore, by using multiple machines, I could move lots of large public folders at once. Once the process was completed, the rule was discarded.
Even before moving the data, when creating the new folders it was easy to setup the permissions as I could compare them side by side.

Where an item was corrupt and couldn't be moved, or the few items that didn't match the rule, I simply moved those items manually or deleted them. In most folders this was only a few hundred items at most.

You still can't copy and paste large numbers of items, as the problem with trying to copy/cut and paste more than about 1500 items is still in Outlook, but a rule effectively moves each item individually, so that isn't a problem.
For the folders with small number of items, a straight copy and paste works well.

I used the same procedure to move a stubborn mailbox which wouldn't move on the regular cross forest move mailbox procedure. Much faster than exporting the mailboxes out to PST file and then importing them. It also allowed me to identify the corrupt items and deal with them.

Even if you aren't deploying Outlook 2010 for your migration, it is worth downloading the trial for this feature alone. Then once the migration is complete, discard the trial software.

A common complaint in forums for some time has been SSL certificate prompts from Outlook 2007, when running Exchange 2003.
The error is usually along the lines of

"The name on the security certificate is invalid or doesn't match the name of the site."

Often the first response will be connected to RPC over HTTPS, as this is the only part of Exchange 2003 that can use SSL certificates for Outlook connectivity.

However the real cause of this is because of the changes made to Outlook 2007 to accommodate the changes to Exchange 2007 and its move to web services. Web services are used to reduce the dependency on Public Folders.

The specific cause of this is a process known as autodiscover. Anyone who has managed Exchange 2007 will be very familiar with Autodiscover, as it can be a key pain point.

Outlook 2007 will attempt to connect to autodiscover.example.com - where example.com is the part of your email address after the @ sign. It will also attempt to connect to a number  of other URLs if that one fails.
 
If your domain does not have an entry for autodiscover, but does have a wildcard entry in its DNS (which is common) then you may get this issue.

Therefore from a client where you have the problem, attempt to ping 

autodiscover.example.com

Where example.com is your email domain, then repeat with your internal Windows domain.

If it resolves, pinging either autodiscover.example.com, example.com or similar, even if it fails, then you may well be on to the cause. The final test is to bring up a web browser and type in autodiscover.example.com and see what happens.
It is likely that you will get the same SSL certificate prompt that Outlook receives and then it will load another web site completely.

The reason for this is quite simple.
Web hosts will often share the IP address of their server with a number of web sites, could be 100s. However to use SSL, a web site must have a dedicated IP address. Therefore a single web site with that IP address will have SSL support.
By using a wildcard in your DNS (so anythingyoulike.example.com resolves) means that all hosts will resolve to the same IP address.
As SSL cannot share an IP address, and does not see the host name being used, it will connect, and generate the SSL certificate mismatch.

How to resolve? Either remove the wildcard entry on the external DNS or have an entry for autodiscover.example.com put in to your domain with a dummy IP address - 127.0.0.2 for example. This will cause the host name to resolve, but fail to connect. See the single host replacement method on this page for instructions on how to do it: http://www.amset.info/netadmin/split-dns.asp

However if you ever deploy Exchange 2007 or higher then remember to remove it!