Public Folder Permissions in Exchange 2007

i've only rarely used the shell.  when i type "add-publicfolderclientpermission" what directory am i changing permissions on?  all of them?

when i get to the promt "AccessRights[0]" i hit enter and it keeps giving me an Identity prompt.

Yeah, that's what i was referring to by hitting enter twice. It does that in case you want to add more than one permission. You can just leave it blank, then hit enter again, and it will take you to the next prompt.

To answer the first question, it will prompt for which folder to do it on. "Identity"

Kevala,
the good news is it works! so i know the issue is a permissions problem and can be solved with the "FolderVisible" permission.  the bad news is the command only works on the immediate parent level.  for example, I ran the command on "\Andrew\Customers\A - F", and users can now see this folder.  however, there are hundreds of customer folders beneath that.  is there a way to propagate the permissions?

Hmm... i wonder if the permissions are missing on the parent hierarchy folder...

Are you familiar with ADSIEdit from the windows support tools?
If so, launch this, browse down to the CN=Folders\CN=Public Folders containers. Check this container and sub containers to see if permissions are inheriting down the tree.

I'm sure there is a way to assign it at the root level, i just honestly don't have time at the moment to find the command.
If you can't find the command, or don't feel comfortable with ADSIEdit and checking these perms, post back and i'll get back to this a little later today.

well, i'm not too familiar with adsiedit.  i'd *rather* find a solution within Exchange somewhere, as i have a feeling i'm going to need to perform variations of this solution for quite a few upcoming issues.  i'd rather not embark into adsi if i don't have to.  so, if you have a chance, i'd much appreciate any further help you have :)

Actually, by using ADSIEdit you are simply checking the permissions on the root Exchange Public Folders container. You would do this in the console, except it's not there anymore. :)

1. Launch ADSIEdit.msc from the Windows 2003 Support Tools
2. Expand CN=Configuration\Services\Microsoft Exchange\Orgname\Administrative Groups\AdminGroupName\

3. Right-click "CN=Folder Hierarchies" and choose properties
4. Click Security, then the advanced tab
5. Ensure that inheritance is enabled
If it is
6. With CN=Folder Hierarchies highlighted, in the right pane, go to the properties of CN=Public Folders
7. Ensure inheritance is enabled here as well.

If there are permissions missing here, they will trickle down to the actual folders. Let's say for example, someone removed the "everyone" group that has a default of folder visible from here, you would have this problem.

If inheritance is enabled on both of these objects, then, as a test, add a user to the security tab of CN=Public Folders with "Read" rights and see if they can see all of the folders.

These two tests will tell us where to go next.

OK, I can confirm that Properties > Security > Advanced > Allow inheritable permissions... IS ticked for both CN=Folder Hierarchies and CN=Public Folders.  I noticed that the Everyone group does not have read access, and under Advanced > Permissions > Edit... the Everyone group only contains permission to "create top level folder."  

Before changing that, however, I gave a test user full access to CN=Folder Hierarchies and CN=Public Folders.  The test user can NOT view the newly created Public Folders in Outlook.  This makes me leery of changing permissions to the larger groups.  Should I be worried?  

The thing to consider with changing permissions in the information store is that the store.exe process can cache permissions for up to 2 hours. The only way to force the update quicker is to restart the mailbox store the user resides in, or the information store service itself.
If you can't do this, then wait a few hours or try again in the morning to make sure is definitely isn't working.
If it still doesn't work, then i'll try to find the permission to assign to mass folders, or the top level folder in the morning...

Thanks kevala,
My test user is still unable to access newly created public folders, despite full permissions in adsiedit.  I am wondering, should i give the Everyone group Read permissions on CN=Folder Hierarchies and CN=Public Folders?  my only concern is that if this wasn't set up by default, i could be screwing something up, although that doesn't seem likely.  

I just built a lab today, and have not touched anything... This is the default permissions for everyone on the CN=Public Folders object.

Do you at least show this?
(ATTACHED)

i can confirm that I show that, yes.  and--under Folder Hierarchies--i have found that user Everyone has inherited List and Read permissions as well.

This is weird, the users should be able to see the PFs by default...
I wonder if someone set a deny on the PFs for everyone, or anonymous???

Run the following in the management shell:

get-publicfolderclientpermission  (hit enter)

Next you'll get the "Identity prompt", type in the name of a ROOT public folder that people cannot see. But type it in with this format:  \PFname
(Make sure to put the "\" before the name.
It will dump out the permissions for that folder.
What does it look like?
Try this on a few folders to see if there is a trend...

It doesn't look too surprising... It looks like it reflects accurately what i've seen in Outlook permissions (via folder properties) and in Adsiedit.  The deeper into the parent folders i delve, I don't see higher level permissions propagating down.  I remember in Exchange 2003 I could manually propagate permissions.  This seems like it would be the solution; why has MS taken away this feature!?

So, in this case, can users see the "Andrew" and "Customers" folders? But not the folders beneath the "Customers" folders? That is what i would expect to see based on what i'm seeing there...

I'm not sure why we took the propagate away... It was a big win to get the PF management console back with SP1...

yes that's correct.

i concur, when sp1 came out and i had a console finally for public folders, i was excited.

any other ideas on propagating permissions through the Shell?  in the meantime, half of my users can't see newly created public folders.  

Sorry, didn't bail on ya, i was off today and going non-stop... started at 6am and  i've just now gotten a chance to turn my computer on (4:23am the following day)

OK... so, since the permissions look like the defaults on the main containers, the root folder, and it's sub folders, but not at the 4rd level, it doesn't sound like there is an actual problem, other than having to set the appropriate permissions on each of these folders.
I'm also assuming that based on the information provided, a new public folder created at the top level, and any of it's subfolders are visible by everyone.

I honestly have not had a chance to look into any propagation options with the management shell.
Just a 4 in the morning thought off the top of my head, i'm wondering if we could use PFDAVADMIN to modify these permissions in bulk?
I would download it and check it out.

http://www.microsoft.com/downloads/details.aspx?familyid=635be792-d8ad-49e3-ada4-e2422c0ab424&displaylang=en

"The tool checks the permissions status of each public and mailbox folder and corrects any problems found. The ability to bulk export/import the permissions and replica lists make this tool invaluable in achieving greater productivity in managing public folders"

Another option might be some powershell scripting (if we can't find a propagation option), but this could turn into a journey...

Let me know what you think of the pfdavadmin tool for now.
I don't go back to work til Sunday, so my resources and time are limited for now, but i'll keep monitoring.

This looks like the avenue for modifying PFs in bulk if PFDAVADMIN doesn't do the trick:

http://technet.microsoft.com/en-us/library/aa997966.aspx

ugh.  I just tried to use pfdavadmin.exe, which--from the description--looks great.  unfortunately, i get an error when trying to run it.  not sure what this error means...

per your 2nd suggestion, the scripts, it looks like the ReplaceUserPermissionOnPFRecursive.ps1 would be the one to try, no?

Yeah, ReplaceUserPermissionOnPFRecursive.ps1 looks like the one. Again, i don't have access to my resources right now, but if i did i would be playing with that particular script, and a set of "pilot" folders..

I tried running ReplaceUserPermissionOnPFRecursive.ps1 script with specified -TopPublic Folder, -User, and -Permission.  After finally getting the syntax right, I got a corruption error.  I thought it looked familiar, so I went back to my Public Folder Management Console, navigated to a random public folder, and noticed a very similar error:

Microsoft Exchange Warning
-----------------------------------------------------------------------------------------
Warnings

get-publicfolder
Completed

Warning:
Object \Andrew\Customers\M - R\M\MicroNova Technology  has been corrupted and it is in an inconsistent state. The following validation errors have occurred:

Warning:
The Name property contains leading or trailing whitespace, which must be removed.

Warning:
Object \Andrew\Customers\M - R\M\Miramar Designs Ltd.  has been corrupted and it is in an inconsistent state. The following validation errors have occurred:
----------------------------------------------------------------------------------------------------

Any ideas?  I get this error on almost all my public folders.  The folders and files were created normally, and can still be accessed successfully by their creator, just not by any other user.

Sorry, not sure how i missed this update.

I have a question for ya... I've seen in the past also where "linked" mailboxes had problems accessing public folders.
If you go into the EMC, and check the Recipients container, do any of the mailboxes show as Linked Mailboxes?

-------------------------------------

On another note, i was able to reproduce your problem. I resolved it by removing the spaces from "A - F", and rerunning the command.
So, can you try this?  
- Go into the public folder management console
- Highlight the "customers" folder on the left side
- On the right-side, right-click "A - F" and choose properties
- Change the name to "A-F"
- Try again...

i don't see any linked mailboxes in my Recipients containter in EMC; i see only Legacy and User mailboxes.

concerning the "trailing whitespace" issue, i think you correctly diagnosed the error.  if i delete spaces from public folder names, the error goes away.  this, however, would be a laborious solution, as we have thousands of public folders with names like "CUI Inc." (see attached pic of Outlook)

i deleted the space in \Andrew\Customers\A-F and re-ran ReplaceUserPermissionOnPFRecursive.ps1.  i received more trailing whitespace warnings for folders futher down the hierarchy (See attached pic). despite this, it looks like the permissions did NOT propagate down to folders that did NOT contain spaces in their title.  

i am able to successfully change permissions of these folders through Outlook so other users can successfully view them.  the problem seems purely a propagation issue.  i'm about ready to bite the bullet and spend $200 to call microsoft! :)

I've also found that putting the path in quotes (as opposed to removing the spaces) works too. I'm just not sure that this would help the lower level folders...

Let me see what else i can find... If the quotes don't work then you'd almost have to write a script to remove the spaces!  There's got to be something better for this...

Researching...

(If you call MS let me know, i'll talk with the tech you get to try to help)

Can you post the exact command you are running?? I haven't been able to see that in the screenshots...

I think i found a way to remove all of the spaces:

get-publicfolder -identity "\" -Recurse -ResultSize Unlimited | Foreach { Set-publicfolder -Identity $_.Identity -Name $_.Name.Trim() }

Let me test this in my lab to see the affects...