none
Outlook 2010 hanging when trying to download the Offline Address Book from Exchange 2010 RRS feed

  • Question

  • Hi,

    I realise that this has been queried before, but I am getting a slightly different outcome for the issue.  Domain users cannot download the OAB.  The Connection Test applet in Outlook shows that it's hanging on connection to the OAB.  When I do a manual send/receive and select Download Address Book, nothing happens, just sits and sits and sits.  No progress being shown on the progress bar.  I've left this for about 30 mins, still nothing.  No errors, no failures, no sync errors in Outlook, nothing to indicate there is a problem.

    Now here's the difference.  Domain Admins (my admin account) can successfully download.  Both on opening Outlook and manually downloading at a later point in time.  Takes approximately 1 min for the connection, download and completion of the full address book.  About 15 seconds for changes.

    Basically, domain users cannot download the OAB from Exchange (2010) using the Outlook 2010 client.  I have checked permissions on the OAB directories on all the CAS' and the permissions are set with Authenticated Users having Read access.  There are no issues in the Event Viewer for the rebuilding of the OAB suggesting there is a problem.  I've restarted all services relating to the OAB and it's distribution.  I've tried different domain user accounts with the same symptoms.

    I did have this issue before and it involved a lengthy call to MS, as well as me rebuilding the OAB virtual directory, a new OAB and reseting all permissions and authentication for the users.  However, this was because all users, including the DA's couldn't download the OAB.

    Any help or suggestions would be greatly appreciated.

    Cheers!

    Andy
    Thursday, October 27, 2011 8:32 AM

Answers

  • My instinct would still be to recreate the OAB virtual directory to begin with. Ensure that there isn't a *.config file in the physical OAB directory on the server/s as that can cause problems as well.

    Simon.


    Simon Butler, Exchange MVP
    Blog | Exchange Resources | In the UK? Hire Me.
    • Marked as answer by yeoo_andy_ni Tuesday, November 1, 2011 8:57 AM
    Thursday, October 27, 2011 10:28 PM

All replies

  • My instinct would still be to recreate the OAB virtual directory to begin with. Ensure that there isn't a *.config file in the physical OAB directory on the server/s as that can cause problems as well.

    Simon.


    Simon Butler, Exchange MVP
    Blog | Exchange Resources | In the UK? Hire Me.
    • Marked as answer by yeoo_andy_ni Tuesday, November 1, 2011 8:57 AM
    Thursday, October 27, 2011 10:28 PM
  • Hi,

    Do you have any update?

    Thanks


    Sophia Xu
    Tuesday, November 1, 2011 7:42 AM
  • Hi guys.

    Thanks for the replies.  I did step through everything yesterday, recreating the OAB's Virtual directory.  Took a couple of hours in total, making sure that all types of user were able to download the address book.  I've now advised the IT guys on site what they can check if this happens again, so they have a bit of a heads up and exposure to what I've done for them.

    @Sembee - Thanks for the reply.  I did check the web.config file and modified the permissions on that too.  For some reason I wasn't seeing it before I removed the OAB vdir and recreated it, but once I noticed that the file was there I gave the same level of permissions as the OAB directory itself to the Authenticated Users.  To be honest, I don't 100% know if that was the step that resolved my issue(s), but it does help in future troubleshooting.  Thanks.

    @Sophia Xu - Yeah, see above.  I checked the permissions on the OAB vdir in ClientAccess\OAB for all the CAS' and modified them accordingly.  As stated above, I also modified the permissions to the web.config in the OAB folder.  This file only appeared after I removed the OAB vdir!  Weird.  The I also checked the authentication on the OAB vdir in IIS.  Made sure that Windows Authentication was enabled with the provider set to NTLM.  The final check was the permissions on the OAB vdir in IIS itself (right click > Edit Permissions).  I gave the authenticated users the same level of access as the actual folder location on the hard disk.  Once I did all of the above steps, everything started to work again.

    I hope that this post will help users with some of the troubleshooting steps that baffled me for long enough!

    Cheers!

    Andy

    Tuesday, November 1, 2011 9:08 AM