If the problem doesn't follow to another workstation, then delete the profile on that machine and start again.
However you need to be very sure it isn't a client side issue, as that is normally a server or auto discover issue.

-M

the client is trying to get to http://serverFQDN/OAB

tried to browse there?

Remi

Check that you are using the latest SP
http://www.microsoft.com/downloads/details.aspx?familyid=9EC51594-992C-4165-A997-25DA01F388F5&displaylang=en

The following help from Slipstick may help on Sync Issues in Outlook

http://www.slipstick.com/outlook/sync-web.asp
http://www.slipstick.com/outlook/sync.asp


Also, check to see if this one workstation/profile is setup to use cached exchange mode.
If it is, turn it off and try again.

Jeff, I respect your opinion with regards to SBS considerably, and I know we have had disagreements in the past, but a hosts file.
Seriously are you mad?

Hosts file are not a solution to anything. When you consider the admin overhead if you change anything about the internet connection, it also means that the autodiscover external URL will not resolve correctly inside.

All that admin overhead to save US$40!

While that solution may work, it isn't something I am going to recommend.

-M

Admin Overhead:
There is no admin overhead if you deploy the file via group policy.  This can easily be done in Server 2008's Computer Configuration Preferences which will copy the edited HOSTS file to the designated clients.

The cost for multiple domain (UCC) ssl certificates is about $90, or $60 more per year.  While this is not a lot of money, it isn't really a necessary expense.

Autodiscover External URL will not resolve correctly inside:
Why not?

If you read my blog post it is for a specific scenario.  I believe in the scenario I describe, modifying the HOSTS file is a great solution.

Jeff
TechSoEasy

If you are paying $90 for a certificate you are paying too much.
A SAN/UC certificate is $60/year from a GoDaddy reseller. That is less than GoDaddy sell them directly.

Now I don't know what your hourly rate is like, but if you change ISP or IP address, that means every client needs to be touched to have the hosts file updated. Group policy only applies if the machine is on site and logging in live - it doesn't apply if the user is remote and coming in via cached mode.
If the users are remote that means talking someone through the process of updating the file.

If the site goes to a different support company they may not know that you have set the hosts file and then wonder why it doesn't work.

If the client is using the same domain name inside as outside, which does happen as the wizard no longer tries to force .local variant on you then autodiscover internally will not resolve correctly because hosts file overrides DNS and most routers will not allow traffic to go out and come back in on the same interface.

Hosts files are never a solution for anything other than testing.

You stated in your blog posting that if you add an autodiscover.example.com entries that you get a certificate warning - you should get a warning if you are using a host file as well. It is all about name resolution, that is all, whether the name resolution is done by DNS or a hosts file.

I also think that you posted this "solution" where the question was in relation to the full product. It might be something that would work in a small environment, but it certainly not a solution for anything of any size. Ensuring that all remote users have an updated hosts file is a major headache.

I have been there when it comes to hosts files headache. Undocumented, on every machine that was remote, needing to update 85 machines one morning after an ISP change all remotely. Couldn't email out instructions because the hosts file was blocking access to the Exchange server. I don't want another admin to go through that kind of headache.

Finally I have to say that I haven't seen this problem.
I was the first to post on the single server solution back when Exchange 2007 was first released. That initial solution no longer applies when Exchange 2007 is used on Windows 2008, like with SBS 2008. I have subsequently posted an updated solution for the single domain SSL certificate : http://www.amset.info/exchange/singlenamessl.asp 

-M

Simon,

I don't really mean to get into an argument over this.  I found a simple way to resolve a problem in a simple environment.  

I will ask you this though... why would you need a multiple domain UCC certificate when using a SRV record?  Why doesn't the OAB sync work the way it's supposed to?  Because the real solution is to have the OAB sync without error the same way the rest of the mailbox syncs without error through the SRV record.

Jeff
TechSoEasy

I've been real busy so I am just getting back to this issue. I created a public DNS record autodiscover.domain.com that points to the same IP address as mail.domain.com.

I have a multi domain certificate

They are now getting a security alert.
Information you exchange with this site cannot be viewed or changed by others. However, there is a problem with the sites security certificate
There is a red X next to "The name on the security certificate is invalid or does not match the name of the site"

Do I need to configure their Internet domain on the local DNS server and have mail and autodiscover point to the internal IP address?

Technically, internally you should need to.

However I have been putting the entries in.
What names did you put in the certificate?

Oh and I didn't respond to Jeff's point.
When you suggest something that is so off the scale, you will generate debate. It is unfortunate that you didn't allow comments on your blog, otherwise I and a few others would probably have raised the subject that as to why it is wrong.
Hosts files should not be required, never required in a correctly functioning environment. I would still have to disagree that it is a simple way to resolve a problem. It introduces a "fix" that is hidden away from someone else coming along.

-M

Some idiot (me) had autodiscover in the certificate, not autodiscover.domain.com