Exchange 2010 Offline Address Book Not Working

Exchange 2010 Offline Address Book Not Working - 500 Internal Server Error?

We know from past experiences that the 500 Internal Server Error is a very general HTTP status code that means something has gone wrong on the web site's server but the server could not be more specific on what the exact problem is.  That's really not a lot of information to go on.

This error in Exchange has come up a few times recently.  Best place to start troubleshooting is to find out if it's internal and/or external clients.  Also, is it effecting one user, multiple users, or all users?

One thing a lot of engineers like to do is create 403 redirect pages with Exchange 2010 to simplify access for end uers.  It's a great tool to be able to tell your clients to go to "https://mail.yourdomain.com" rather than https://mail.yourdomain.com/owa.  Unfortunately, what this does is it creates a web.config file in the directory of where your OAB virtual directory points.  Even more unfortunate, this breaks OAB.  But - don't worry - there's an easy fix for this.  Simply go to the security properties of the web.config file, assign Read and Read & Execute permission to Autheticated Users group then restart IIS using iisreset /noforce.

After this, you can download the address book for your users through Outlook.  Still not working?  If it's still not working on a few individual users, try this trick below.

Individual Users - Outlook 2007 or 2010 error (0x8004010F) operation failed. An object cannot be found.

Since Outlook 2007, the Offline Address book is downloaded via BITS and the sometimes the BITS job queue can get full.  (Especially if it has a queue of erros)
Simply run BITSADMIN.EXE /RESET to fis the issue.

If you cannot find/run BITSADMIN, it's technically a depreciated command, here's a PowerShell equivilent.  Note, you may need to run this multiple times:  get-BitsTransfer -allusers | Remove-BitsTransfer

Slow DFS Sharing - Several Seconds Before Root Directory Access

I recently installed a new DFS setup for a client.  With this DFS setup, everything was working great.  That is until end users started accessing everything.  Immediately we noticed that any access to any share would take up to 10 seconds to access the initial root folder.  From then on it worked great.  Turned out to be this little problem.  When you have a DNS only space, Windows tries accessing servers and folders NOT by using DNS first.

http://support.microsoft.com/kb/244380

Special thanks to this article for finding it:

http://serverfault.com/questions/50789/long-pause-when-accessing-dfs-namespace