How to use Permissions Browser to verify permissions on Public Folders

Within the Vault Administration Console (VAC) permissions can be seen that are set on an archive that is inherited from the Root Target Folder, however it will ONLY show the Root folder levels, and will not show permissions in sub folders.

 

Top Right - Auto and Manual
This is to show Automatic permissions, those set through Outlook or Exchange System Manager (ESM), the Manual are permissions set through EV and the VAC and not through the Exchange Environment.

Top Left - Archive List
This is a list of all the archives hosted in the Enterprise Vault environment, once an archive is selected the bottom left section will then be populated with folders.

Bottom Left - Folder List
This is a list of all the folders contained within the archive selected above, so for instance the following is seen \Support\EV.
Each folder that is selected will then populate the main area to the right.

Main Area - Effective Permissions List.
Based on the Archive selected and the folder within that archive, the Main Area should now show a list of all of the users that have access or do not have access to this folder.
In this example the Administrator is an owner of the folder, being able to Add, Read, Delete Items and folders, also above this it shows that this is an ALLOWED type.
If this was DISALLOWED then this would be a deny so the user could NOT Add, Read or Delete Items and folders.
Permissions browser will list both in distinct sections, so it will have the ALLOWED types first and then in another section it would have the DISALLOWED types.

Important notes and caveats regarding Permissions..
Read access to a folder means that folder can be searched.
Allows override Denies - contrary to Microsoft's "Denies Override the Allows"
Enterprise Vault uses a "Least Restrictive" Policy.
For example, Jane Doe is part of the Secretary group, which has a deny on a particular folder, but is added to the folder with the ability to read, write and edit etc.
Outlook would prevent Jane Doe from viewing or editing items, even though that account has explicit permissions because the Deny from the group overrules this, however within EV.
The fact that Jane Doe has Allows will override what the group denies that account.

The other side of this is Jane Doe is part of the PF Admin group and has Owner rights on the folder, but someone adds her to have explicit Deny permissions on the folder, the fact that EV uses "Least Restrictive" policies, her membership of the PF Admin will mean she can perform actions on the folders.

Another thing to also note is that Enterprise Vault determines permissions to Public Folders through "Client Permissions" and "Admin Permissions".
Client Permissions are taken across by default and are what the majority of Public Folder users will use to administer rights for EV and Outlook to make sure they are in sync.

Admin Permissions are not taken over unless "Inherited Permissions" are enabled within the Public Folder Archiving Policy, and are typically set en masse through PFDavAdmin or singularly through the ESM.
This is usually not recommended because it can slow down archiving considerably as it will spend a high majority of its time synchronizing permissions instead of archiving.
In addition, it may give users such as Backup Users the ability to add, read and delete items they would never have the ability to through Outlook.

If someone has determined that they do not have access to a folder, it is first recommended to find that folder within the Permissions Browser, look to see what permissions if any that user has.
If determined the user does not have the desired permissions, add them through either Outlook or ESM and then do either a Run Now or in Report mode to have those permissions synchronized.
After this, do a Refresh of Permissions Browser and make sure the user has been added and then have them retest.

If it has not transferred to Enterprise Vault then it is recommended to DTrace the PublicFolderTask only and then run a report mode against that folder task, this way it can be determined what it is doing when it comes across that folder and that particular user.

Most often causes for permissions not taking correctly is either the Global Catalog is offline or replication between Exchange Servers and Global Catalogs has not occurred and the server that is queried just simply does not have the information available yet. Permissions will also be copied on scheduled archiving runs, so the permissions can be set and be assured that definitely by the following morning those permissions will be affective.