[ad_1]
Sometimes we hear of issues where specific Exchange Online users are not able to viewaccess specific Exchange Online public folders using OWA or Outlook. The reason behind these issues is often related to the public folder mailbox that specific user is connected to, or permissions on public folders.
How do clients (Outlook or OWA) connect to public folders?
When users try to expand public folder information, the client connects to the assigned public folder mailbox for the signed-in user to access the required public folder information through a series of steps.
Outlook desktop client (Windows or MacOS):
- The client contacts the Autodiscover (AutoD) service to determine connection settings for the user’s primary mailbox that shall include an XML element named <PublicFolderInformation>.
- The Autodiscover service is responsible for populating PublicFolderInformation property with any healthy public folder mailbox SMTP address “e.g., public folder mailbox with a full hierarchy”. If DefaultPublicFolderMailbox is populated for the signed-in user mailbox settings, the service shall use DefaultPublicFolderMailbox value for filling PublicFolderInformation value over AutoD response.
- PublicFolderInformation will contain the SMTP address of a public folder mailbox the signed-in user is connected to retrieve public folder information.
- An additional Autodiscover request will be made to request connection settings for the SMTP address of the public folder mailbox obtained previously.
- If PublicFolderInformation property in AutoD for the signed-in user was empty or was containing unhealthy public folder mailbox, the user might have issues with accessing/viewing public folders.
- In this case, the public folder node itself will not appear for the user.
Outlook on the web (OWA) client (and the new Outlook for Windows client):
- OWA service connects to assigned public folder mailbox specified in the parameter EffectivePublicFolderMailbox/DefaultPublicFolderMailbox, stamped on the signed in user to retrieve public folder information. If this value contained unhealthy public folder mailbox, the user would have issues with accessing/viewing public folders.
Public folder access using OWA will work only if PublicFolderEnabled is set to Local and public folder deployment is active in Exchange Online.
For more information about the selection process logic for the public folder mailbox using Autodiscover service please check this article.
How does the service assign public folder mailboxes to users?
Depending on the value of PublicFoldersEnabled parameter on the Exchange Online organization configuration we can determine where public folders environment is located (on-premises or in the service). The following table describes possible values of PublicFoldersEnabled and what it means for clients accessing public folders.
|
PublicFoldersEnabled |
Description |
|
Local |
This is the default state, indicating the clients will access public folders in Exchange Online. |
|
Remote |
This state indicates that public folders are deployed on-premises or are in the process of migration. Only Outlook desktop clients can access public folders in this state, provided the public folders are configured for access in hybrid configuration. Check this article for more details. |
|
None |
No clients can access public folders in this state. |
Here are more details about each scenario:
Scenario 1: public folders are hosted in Exchange online (PublicFoldersEnabled: Local)
End-users using Outlook or OWA connect to cloud public folder mailboxes to accessview public folder information. There are two user mailbox properties that control the assignment of public folder mailboxes to users:
- EffectivePublicFolderMailbox: Exchange Online populates this parameter automatically to assign public folder mailboxes on users based on the hierarchy load as illustrated below.
- DefaultPublicFolderMailbox: Tenant admins can override Exchange Online assigned EffectivePublicFolderMailbox PF mailbox using Set-Mailbox -PublicFolder command. In such scenarios, DefaultPublicFolderMailbox will be populated with the public folder mailbox specified by the admin. For example:
Tenant admins should be careful when overriding system assigned PF mailbox and should not overload a single PF mailbox with too many user sessions. The recommendation is to have up to 500-600 users configured with a single PF mailbox. Additionally, ensure that the public folder mailbox is healthy.
How are public folder mailboxes assigned to users?
Exchange Online uses fully synchronized public folder mailboxes that are not excluded from serving hierarchy, then starts to load balance and assign these mailboxes to users using the EffectivePublicFolderMailbox parameter to ensure that users are always retrieving consistent public folder information.
Scenario 2: Public folders are hosted on-premises (PublicFoldersEnabled: Remote)
When admin configured public folders for co-existence, following the article either for Legacy or Modern public folders, on-premises public folder/proxy mailboxes are synced to Exchange Online using Azure ADConnect tool as mail enabled users. These synced mail-enabled objects are stamped in RemotePublicFolderMailboxes parameter in the Exchange Online organization configuration. The service uses these mail-enabled objects on RemotePublicFolderMailboxes parameter to load balance and assign them to users using EffectivePublicFolderMailbox. Admins can bypass that service assignment by stamping requested mail-enabled object on user mailbox using DefaultPublicFolderMailbox parameter. Only Outlook desktop (Mac and Windows) client can connect to the remote public folder mailbox to retrieve public folder hierarchy. That is illustrated via the PublicFolderInformation field on the Autodiscover service initiated by Outlook to retrieve connection settings for the on-premises public folder mailbox.
How to quickly mitigate a problem of some users that are not able to accessview specific public folder?
Admin could retrieve the EffectivePublicFolderMailbox/DefaultPublicFolderMailbox stamped on a working user and override the same value stamped on the affected user. This can be achieved using the following commands:
Get-Mailbox “replace with working user email address” |fl DefaultPublicFolderMailbox, EffectivePublicFolderMailbox
Set-Mailbox “replace with affected user email address” -DefaultPublicFolderMailbox “replace with retrieved public folder mailbox”
Consider the following: it’s not recommended to use root/primary public folder mailbox to serve hierarchy or assign specific secondary public folder mailbox to many users. Avoid causing exhaustion for the assigned specific public folder mailbox. Read more about public folder deployment best practices here.
To troubleshoot and mitigate the problem over the affected public folder mailbox please check this article. Once you managed to solve the sync problem with that affected public folder mailbox, revert back the change done affected users to let the service control the assigning of public folder mailboxes again. The stamped value of DefaultPublicFolderMailbox parameter on previously affected users should be set to null and the system will start to assign a fully synchronized public folder mailbox that is not excluded from serving hierarchy using EffectivePublicFolderMailbox parameter on that specific mailbox. This can be achieved using the following command:
Set-Mailbox “replace with user email address” -DefaultPublicFolderMailbox $null
How to go about troubleshooting any public folder connectivity scenario?
Admins can leverage cannot access public folders diagnostic tool in Microsoft 365 admin center to assist them diagnose the issue properly for any public folder connectivity scenario.
Let’s clarify some troubleshooting steps to follow if a user can’t connect to public folders using Outlook:
Consider the following scenario: Exchange Online user is not able to accessview remote on-premises public folders using Outlook and is getting something like the generic “Cannot expand the folder” error.
- Depending on the remote public folders Exchange server version verify that prerequisites mentioned in articles either for Legacy or Modern public folders are covered. Ensure that public folder/proxy mailbox objects are synchronized to Exchange Online and that they have auto-discoverable primary SMTP addresses.
- Validate that in online organization configuration PublicFoldersEnabled value is set to Remote and RemotePublicFolderMailboxes contains a list of the on-premises public folder proxy mailboxes. For more information depending on the Exchange on-premises version please check the following articles for either Legacy or Modern public folders.
<PublicFolderInformation><SmtpAddress>pf@domain.com</SmtpAddress></PublicFolderInformation>
- Validate that public folder/proxy mailbox object has auto-discoverable primary SMTP addresses using Test Email Auto Configuration tool:
- Enter Emailaddress of the public folder/proxy mailbox object
- Uncheck Use Guessmart & Secure Guessmart Authentication
- Click Test
- Sign in with the affected user. If no AutoDiscover response was received, please check log tab on Test Email Auto Configuration tool to troubleshoot the issue, if the issue seems ambiguous you can run the exact test on EXRCA else please contact Microsoft support.
- Validate that Office 365 user is represented by a MailUser object in the Exchange on-premises environment. If the object is not represented on-premises, please check the following article to address that.
- Validate that X500 address stamped on the user on-premises is matching LegacyExchangeDN for the cloud object value. If the X500 address was missing on-premises, please use the below command on the on-premises shell to add it.
Set-RemoteMailbox -identity User -EmailAddresses @{add=”X500:replace with cloud LegacyExchangeDN”}
Special thanks to Bhalchandra Atre and Nino Bilic who reviewed and contributed to this post.
Hazem Embaby
Support Escalation Engineer
[ad_2]
Source link
