Announcing Support for Controlled Connections to Public Folders in Outlook

Up to now, Administrators did not have control over which users would see public folders in their Outlook clients. If public folders were created within the organization or if an Exchange Online organization is configured to access on-premises public folders, all clients would make a connection to and show the “Public folders” object in Outlook. From there, one could control access to individual public folders (controlled through folder permissions). However, it was difficult to have only some of Outlook clients connect to public folders.

We are now introducing the ability to show the public folder object in Outlook to only a set of users who might need them. To get started, this will be available for Outlook for Windows users only.

To do this, administrators can use two parameters:

  • PublicFolderClientAccess is an optional parameter on the user object. By default, its value is set to ‘false’. Setting this to ‘true’ on a specific user designates this user as one of users who will see public folders in Outlook.
  • PublicFolderShowClientControl parameter on the organization config. By default, the value of this parameter is also ‘false’ and once it is set to ‘true’, the controlled access of public folders is enabled.

Here is an example of how to use these parameters; to enable access to only the user “Administrator” and turn the feature on for the organization:

Set-CASMailbox “Administrator" -PublicFolderClientAccess $true
Set-OrganizationConfig -PublicFolderShowClientControl $true

Important note: setting the organization parameter to true without setting user attributes to true first will make it so no users will see the public folder object in Outlook for Windows. In other words – if you want to implement this, we suggest that you plan ahead and populate user attributes first (PublicFolderClientAccess on users that need access set to true) and then set the organization level parameter (PublicFolderShowClientControl set to true). That way, users who need to have access will not lose access unexpectedly.

Why would you want to do this?

Tenant admins will now have more flexibility over which users connect to public folders in Outlook. This will benefit very large organizations who might have issues with connection limits to public folders and will reduce the load to that infrastructure.

This will also be helpful to organizations during mergers and acquisitions if moving to EXO. Imagine one organization having existing public folders, but after the companies merge – without this feature all of the users would unnecessarily connect to the public folder hierarchy.

Note: This feature is not intended to be replacement for public folder permissions, it is merely providing means to have more control over which clients connect to the public folder tree.

A few more questions answered that you might be interested in:

Will this work for only Outlook on Windows?

At this time, yes. We are working to bring this to additional clients (like Outlook for Mac or Outlook on the web) in the future and will talk about this later.

What about on-premises servers?

We are considering support for on-premises in a future CUs and we will provide details at the later time.

Is there a specific version of Outlook that I need to see changed behavior?

No. The feature works by removing the public folder information from the Autodiscover response to Outlook for Windows clients. Therefore, if the user is not enabled for public folder access they will simply not connect to the public folder tree no matter the version of Outlook for Windows they use.

In case of any questions, please do reach out to us via the comments section below. We are updating official documentation to add those parameters.

Public folder team

Comments (8)
  1. Looking forward to seeing this on-premises as merger and acquisitions situations/requirements are not limited to cloud environments.

  2. Farshad says:

    Would ti make more sense to make the PublicFolderClientAccess as $true by default. That way when PublicFolderShowClientControl is set to $true, then still all users can access the public folders and customers can set only PublicFolderClientAccess to $false for only those users they want to disable this for? The other way around we have to write scripts to set this to $true for all users, imagine customer with large number of mailboxes. Also we always have to set this to true for users who are moved to cloud, adding more tasks.

    1. Ashish Gupta says:

      As this feature is build keeping in mind to hide the public folders for some users so the default value is false. Also, there are organizations with both types like some of which prefer the false as default value as they want to hide Public folders for most users (cases of M&A) and on another side, there are organizations which like true as default value as they want to provide access to PF’s for most users. So right now we went with the feature theme. but later on, if we would find more tenants are liking the true as default value then we could change the default value of PublicFolderClientAccess to true.

  3. Joe Sutherland says:

    1. Can we get the PublicFolderClientAccess in a mailbox plan so that we can default newly created mailboxes to have access to public folders if we want?

    2. I know you said this isn’t available for on-premises Exchange yet, but what about Hybrid Public Folders where the mailbox is in Exchange Online and the Public Folders only are on-premises? If this will work to hide the Public Folder AutoDiscover referral in that scenario, it would be a great workaround for this miserable bug: . The “workaround” of moving the shared mailbox back on-premises is not acceptable.

    Thanks for this feature! This will be great for so many of my M&A projects just as you’ve mentioned!

    1. Ashish Gupta says:

      for #1 we will check if this would be feasible and then try to add this param in cas-mailboxplan with default vaue true.

  4. @Joe Sutherland, for #2, the control is available in Exchange Online for all possible PF deployments, that covers the EXO users accessing PFs On-Premises as well.

  5. NinoV says:


    when i try to run Set-CASMailbox “user” -PublicFolderClientAccess $true there is error thrown “A parameter cannot be found that matches parameter name ‘PublicFolderClientAccess'” is it possible that this is not yet available in our tenant? When i list properties with get-casmailbox i can see property there with default value.

    same goes when i try to run command on organizational level

    A parameter cannot be found that matches parameter name ‘PublicFolderShowClientControl’

    1. NinoV says:


      update on issue with missing PublicFolderClientAccess and PublicFolderShowClientControl cmdlets from tenant. After investigation and consultation with MS internal resources bottom line was that root cause of issue was with not correctly applied RBAC on our tenant. It was some internam MS procedure which was not completed on tenant side when feature was rolled out. Up on acknowledging what is missing MS has fixed issue and now everything is working as expected. Thank you.

Comments are closed.

Skip to main content