locked
Hybrid Deployment - Online User can not access legacy on premises public folder RRS feed

  • Question

  • Good Day

    We are running an hybrid deployment with exchange 2010 (mailbox and public folder) and a new exchange 2016 (which we installed for migration purposes). AD Sync is in place, no AD FR

    Hybrid configuration is done also with public folder access configuration (seperate proxy mailbox) and everything is running fine except public folder access.

    If i migrate the mailbox from an existing user (mailbox on the exchange 2010 server) to O365, user can access legacy publicfolder after migration.

    If i create a new user with its mailbox directly in O365, the user is not able to access legacy public folder. if i check outlook connection status, there is no connection to the legacy exchange 2010. there is also a user present (remoteusermailbox) on the on prem infrastructure for the affected user. if i check autodiscovery xml file for the affected user, i can see that the correct information for public folder is present

          <PublicFolderInformation>
            <SmtpAddress>mailbox [at] domain.com</SmtpAddress>
          </PublicFolderInformation>

    Any idea what the problem could be?

    btw, we use outlook 2016, but same problem with outlook 2010

    Thanks

    Monday, February 26, 2018 3:36 PM

Answers

  • looks like we found the problem. the remote mailbox account on the on prem infrastructure didn't had the x500 address matching the legacy dn from the exchange online Account.

    How to fix:

    open exchange online powershell and get the attribute "legacyExchangeDN" with following command:

    get-mailbox user-at-domain.com | fl legacyexchangedn

    you'll get en output like this:

    LegacyExchangeDN : /o=ExchangeLabs/ou=Exchange Administrative Group (FYDIBOHF23SPDLT) .......

    This "ExchangeLabs" is important

    now go to your corresponding on premises ad account and open attribut editor. search for the "ProxyAddresses" Attribute and ad the x500 Address:

    x500:/o=ExchangeLabs/ou=Exchange Administrative Group (FYDIBOHF23SPDLT) .......

    Replicate those changes to all your Domain Controller.

    Done, the user should be able to browse on Prem Public folder

    (note, maybe this attribute is written back to on prem ad if you enable "Exchange Hybrid Setup" in your Azure AD Connect configuration)

    • Proposed as answer by Allen_WangJF Friday, March 2, 2018 2:07 AM
    • Marked as answer by andre_80 Friday, March 2, 2018 6:51 AM
    Thursday, March 1, 2018 2:03 PM

All replies

  • Thank you for your reply Udara

    I already know those links and configured all those settings already. except for the second link. step 2 there is not possible because the affected users are on O365, there you can't set mailboxdatabase settings.

    The problem does only affect users which are created with a O365 mailbox directly. If i create a user on the on prem server and move it to O365, this user does not have the problem.

    More ideas? Thanks

    Tuesday, February 27, 2018 6:49 AM

  • we also do same thing as a workaround when mail is not worked with cloud only users. Most of issues happened with cloud only users.. Still we have faced mail flow issue only. not Shared folder access issue.

    but we can use soft match method for match user in AD with same account in O365.

    As I think your approach is correct. 

    After creating new user in onprem Exchange, then proceed as usual...

    Tuesday, February 27, 2018 7:04 AM
  • Thanks, but we need to have this working when we create the mailbox directly in O365. We dont want to create all new MBX on prem and the migrate it.

    If someone has another Idea how to fix this please let me know.

    Tuesday, February 27, 2018 7:11 AM
  • Hi,

    I suppose that it's a known issue, this mailbox is created in Office 365 directly, thus there's no associated On-premise object for authentication to public folder. Thus, we need to manually create remote mailbox in On-premise Exchange, and associate it with same email address.
    Note: This object must have the same name, alias, and user principal name (UPN) as the cloud mailbox.

    Then, use ExchangeGuid to associate those objects in Exchange Online and On-premise.

    More information, for your reference:
    Exchange Online users can't access legacy on-premises public folders
    Users in a hybrid deployment can't access a shared mailbox that was created in Exchange Online

    Best Regards,
    Allen Wang


    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.


    Click here to learn more. Visit the dedicated forum to share, explore and talk to experts about Microsoft Teams.

    Tuesday, February 27, 2018 4:01 PM
  • Thank you for your answer Allen.

    Maybe i was not clear enough, we have ad sync in place which synchronice all our user to the azure ad. so the user object is already present and also the remote mailbox is configured. but i'll check the exchangeguid property

    Wednesday, February 28, 2018 12:17 PM
  • Well, I mean the account which created in Office 365 directly will experience this issue.

    Best Regards,
    Allen Wang


    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.


    Click here to learn more. Visit the dedicated forum to share, explore and talk to experts about Microsoft Teams.

    Thursday, March 1, 2018 2:22 AM
  • Well we have Exchange 2016 on prem. I open the EAC from this on prem server. then i go to recipients -> mailbox and there i select "office 365 mailbox" then it creates an user account in on prem ad and as soon as this account is synchronised with ad sync to o365 it creates the o365 mailbox. this accout is not able to access on prem public folder
    Thursday, March 1, 2018 6:00 AM
  • looks like we found the problem. the remote mailbox account on the on prem infrastructure didn't had the x500 address matching the legacy dn from the exchange online Account.

    How to fix:

    open exchange online powershell and get the attribute "legacyExchangeDN" with following command:

    get-mailbox user-at-domain.com | fl legacyexchangedn

    you'll get en output like this:

    LegacyExchangeDN : /o=ExchangeLabs/ou=Exchange Administrative Group (FYDIBOHF23SPDLT) .......

    This "ExchangeLabs" is important

    now go to your corresponding on premises ad account and open attribut editor. search for the "ProxyAddresses" Attribute and ad the x500 Address:

    x500:/o=ExchangeLabs/ou=Exchange Administrative Group (FYDIBOHF23SPDLT) .......

    Replicate those changes to all your Domain Controller.

    Done, the user should be able to browse on Prem Public folder

    (note, maybe this attribute is written back to on prem ad if you enable "Exchange Hybrid Setup" in your Azure AD Connect configuration)

    • Proposed as answer by Allen_WangJF Friday, March 2, 2018 2:07 AM
    • Marked as answer by andre_80 Friday, March 2, 2018 6:51 AM
    Thursday, March 1, 2018 2:03 PM
  • Great, glad it solved after adding x500 address.
    Please mark your reply as answer, it'll highlight the solution for other community.

    Best Regards,
    Allen Wang


    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.


    Click here to learn more. Visit the dedicated forum to share, explore and talk to experts about Microsoft Teams.

    Friday, March 2, 2018 1:29 AM
  • We are having the same issue as andre_80.  I tried his fix but it didn't work for us, user is still unable to browse on-premises Public Folders.  If someone has any ideas about what else we can try it will be appreciated.  Thank you.
    Monday, April 30, 2018 10:41 PM
  • how did you create the user and its mailbox? did you open eac and then create a new mailbox with thipe "office 365"? do you have AD Sync in place? if yes and everything else is configured correctly, you should be able to fix the issue with the described x500 setting in the proxy addresses.

    could you post the proxy addresses attribute from the affeced local ad user?

    does all user have the issue or do you have user which can successfully access the on prem publicfolder?

    Tuesday, May 1, 2018 5:39 AM
  • I created the user using our on-premises Exchange 2013 EAC.  I used the 'Office 365 mailbox' option.  We have AD sync in place and I manually initiated a sync after creating the user.  I used the powershell command you specified previously to get the 'Exchange Labs' x500 proxy address for this user and then added it to his AD object.

    Only users created this way are having the problem.  A user who was created on-premises and then migrated to Office 365 can access the Public Folders without any issues.

    Here is the proxy address:

    /o=ExchangeLabs/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=70b62d1562c344a28fa81b5a8deba662-Frank Castl


    Tuesday, May 1, 2018 6:59 PM
  • Just wanted to post a follow up that Public Folder access is working now.  I enabled the 'Exchange Hybrid Deployment' option in the Azure AD Connect sync client which also started a full import.  I checked to see what changes, if any, were being made and it added the 'Exchange Labs' x500 address to the accounts in AD.  We tested a few accounts that were not working and they can now access the Public Folders.  I don't know why manually adding the x500 entry didn't work or why we didn't enable this option previously.  Thank you for your help andre_80.
    Tuesday, May 1, 2018 10:47 PM
  • thanks for your post with your solution.

    what would be interessting, how did you add the x500 address to the on prem AD user. did you ad the prefix x500: ?

    /o=ExchangeLabs/ou=.....

    or

    x500:/o=ExchangeLabs/ou=....

    Wednesday, May 2, 2018 4:37 AM
  • I added it the second way, x500:/o=ExchangeLabs/ou=.  I checked the account after turning on the 'Exchange Hybrid Deployment' option in AD sync and the x500 entry it added was the same as what I had manually entered.  No clue as to why it didn't work when I did it.  Interesting side note, our 'delta' sync process now takes about 40 minutes.  Before enabling the 'Exchange Hybrid Deployment' option it would only take around 1 minute.
    Wednesday, May 2, 2018 2:15 PM
  • this is indeed strange. i also thought about enabling the exchange hybrid option but as we have migrated alread all of our several 100 users i'm a bit worried to do this in production environment... (as wit works with manually update the proxy addresses even if it is a bit more work to do)

    But great that it fixed your problem

    Thursday, May 3, 2018 5:13 AM
  • So, another follow up.  It took a few days but our sync process is back to normal.  It takes about a minute now instead of 40 minutes or more it was taking after I turned the hybrid option on.  If anyone needs to turn this feature on after having sync in place for a while I would suggest increasing the time between syncs, at least temporarily.  We set ours to 2 hours and that seemed to help.  You can do that from Powershell on the sync server.

    Set-ADSyncScheduler -CustomizedSyncCycleInterval 02:00:00 

    Monday, May 7, 2018 2:23 PM