NewAccount = left(oMessage.body,instr(oMessage.body,vbcrlf)-1)Įventlog.write("*** ROBOT SCRIPT *** else case achieved")įunction CreateNewPublicFolder(NameOfFolder)
You will need to test and research the permissions, but 1887 gives everything except delete mailbox.Ĭode: Select all Function RobotScript(oMessage)Ĭase "Your Special EXACT text that must be used as a subject"
PUBLIC FOLDERS PERMISSIONS EXCHANGE 2010 HOW TO
This has been cut from a much larger script - so check it, but it shows how to add public subfolder, and how to set permissions via script, either with account ID, or with user email address. You send an email to my server with specific text in the subject to trigger this robot script, which is triggered from an account level rule (ie the message must be sent to a specific account, and contain the exact text for subject.) I have a robot script that creates a sub folder and sets permissions.
Users can't make subfolders either, if they don't have 'Create mailbox' permissions.Ĭreating a script to propagate permissions isn't very hard though. I've been searching through the forum for the answer, but all I found thus far seems to suggest that permissions on any subfolders in Public Folders structure need to be manually set, for each subfolder. 16:45I would need some help with Public Folders hierarchy and permissions propagation. Guys, I am really sorry for the long post.Īny assistance would be truly, truly appreciated.
That Public Folders structure has been abused for so long, there is just no easy way out of it. However, these guys keep adding new subfolders on a daily basis, so an automated permission propagation system would really be needed. Not even that - if it was a fixed number of subfolders, adjusting permissions manually would be possible. Is there a way to propagate permissions from the root folder, and have the inheritance enabled for every new folder that gets created? With 5000+ subfolders, you can only imagine how cumbersome would it be to adjust the permissions manually. However, I am now having a problem with permissions setup/propagation on folders/subfolders. PST files, provision a mailbox in HMailServer, import the PSTs to it, and copy the folder structure to HMailServer - all from Outlook. The plan was to export Office 365 PF data to multiple. Reverting back and possibly trying with a hybrid environment is not an option.įor that reason, we wanted to move the PF data from Office 365 to a local, on-prem server and try with a different tool, in hope we would restore the proper performance levels.Īfter a handful of third-party tools failed to provide the functionality this customer would need (Public Folders directly accessible via Outlook, and having the "drag-and-drop" feature), we found the awesome HMailServer. Of course, all this is causing a lot of frustration at this customer's side. However - all this was working perfectly fine on Exchange 2010 On-prem, but once it got migrated to Office 365, everything just got really, really slow.
I know, this is not at all what Microsoft Public Folders were intended for. They've been using it this way for years - kind of their own "Team collaboration tool". They use Public Folders to create "Case" subfolders, and "drag-and-drop" any related emails they receive to the corresponding "Case" subfolder in Public Folders. Their Public Folders structure is ~ 200 GB in size (and growing), and contains 5000+ subfolders. I've been searching through the forum for the answer, but all I found thus far seems to suggest that permissions on any subfolders in Public Folders structure need to be manually set, for each subfolder.Ī little bit of the background story - we recently obtained a client who we migrated from Exchange 2010 On-Prem to Office 365 (Mailboxes + Public Folders). I would need some help with Public Folders hierarchy and permissions propagation.