Users cannot set OOF after AD migration (somewhat related to MSKB 2963483) RRS feed

  • Question

  • Hi all,

    I'm involved in a project to migrate users from a Windows 2003 functional domain to a new Windows 2012 domain.  For various reasons, at this time, their email has to remain on the old domain, on an Exchange 2007 based system.  When the users are migrated, they take their SID history with them, allowing them to access resources on the old domain with their new login.  The majority of the client environment is Windows 7 running Office 2010.

    After their accounts have been migrated, our test users find they can't set an Out of Office status in Outlook.  When they try, they get the error "Your automatic reply settings cannot be displayed because the server is currently unavailable".  When I have Outlook logging enabled, I see OOF logs created, with a HTTP status code 500 and an error referring to "User is not mailbox owner".

    I have tried the hotfix and registry settings in MS Knowledge Base article 2963483 but it doesn't seem to resolve the problems.  When reviewing the oWinHTTP log file, I see entries where it will always try to negotiate with Desktop Credentials and failing with an error 500.

    I've found another of other suggestions in trying to find a solution but they refer to changing settings on the Exchange servers, which is unlikely to be approved in the environment I'm in.

    Is there any other fix I can try to get this resolved?  Currently we've only migrated about a dozen users as part of UAT, so it'snot that big a problem now, but will be when the rest are moved.  Thanks.

    Monday, November 7, 2016 5:43 AM

All replies

  • Hi Astatine,

    Please also refer to the following article, it provides more details troubleshooting steps and may give your some hints:

    Your Out of Office settings cannot be displayed

    Moreover, if all methods for client cannot resolve the issue, I strongly recommend you involve your Exchange administrator to help troubleshoot the issue .

    Best Regards,

    Niko Cheng
    TechNet Community Support

    Please remember to mark the replies as answers.
    If you have feedback for TechNet Subscriber Support, contact

    Tuesday, November 8, 2016 9:41 AM
  • Hi Niko,

    The article you linked was actually one of the pages I found earlier in relation to the problem and I've tried all the items listed except for the ones relating to such as disabling Windows Authentication on the autodiscover directory.  I doubt such a change would be approved, and there isn't really an Exchange administrator at the moment.

    Tuesday, November 8, 2016 10:36 PM
  • Did you find a resolution to this?  I'm experiencing the same issue.
    Tuesday, February 28, 2017 8:40 PM
  • Hi there,

    I did manage to find a few options to resolve it.

    The initial workaround was to have users set OOF via webmail, which still worked.

    When looking at the logs again from Outlook, I noticed in the error that it was saying that "user <newSID> wasn't owner of mailbox <oldSID>" where newSID was the SID of the user in the new domain and oldSID was their SID in the old domain.  One of the options tested was to simply grant full rights to the new domain account on the mailbox (via Powershell).  Following this, OOF worked.  While this option was the least invasive of what was considered, there's some discussion going on about whether it's the "best" option because it still requires the user to manage passwords for both accounts.

    I didn't mention it in my original post because I hadn't run into the issue yet, but there is a second old domain in the scenario, running slightly more recent versions of Windows and Exchange (Windows 2008, Exchange 2010).  This second old domain is a legacy of an acquisition/merger that was never finalised on a technology level.  When migrating test users from that domain to the new 2012 one, there were similar issues with OOF but different error messages in Outlook logs.  The permission fix described above was attempted but it didn't work.  In this case, the option that did work was to turn the mailbox into a linked mailbox - disconnecting it from the user's old domain account and reconnecting it to their new domain account.

    The fix that worked for the 2nd old domain means an end result very much like a resource forest model, which was an idea that was discussed much earlier on but not taken up.  I think out of the 2 options, it's probably the better solution as it at least conforms with a known model that Microsoft (apparently) support, and by performing it, the source AD account is disabled, meaning the user only has to manage the password on their new account and can't logon with the old one anymore (which is an ongoing issue we've had).

    Lastly, both of the Exchange systems in the old domains haven't been tended to very well.  Neither have autodiscover configured to an acceptable level which I think may have contributed to this issue and others that came up.  Unfortunately in this scenario I wasn't in a position to do anything about it.

    Wednesday, March 1, 2017 9:44 AM