Hi,

This post is consolidating a lot of information I’ve found over the last day. It’s one of those things I’ve done a few times over the last several years, so each time I get to it I need a refresh!

For a user running Outlook connected to an Exchange server, and wanting to give someone else access to a large amount of existing folders, they really only have two options. Painstakingly go through every single folder’s permissions and add the other person, or set the permissions on a top level folder, then create new folders under that, and finally move the emails in. Permissions don’t inherit like normal file folders when you move one, only newly created folders inherit their parent’s permission.

Rather painful for the end user, but from the administration side of things, there are few options.

1. Give the second user full access to the first user’s mailbox. This option is far from ideal, because it’s an all or nothing permission, and it isn’t visible by the end user. They can’t tell who has access to their stuff. It also requires someone with appropriate Exchange privileges to manage and make these changes every time. It’s good for a generic mailbox, or someone who’s left the company etc where there is no particular user to manage the permissions.

Exchange 2003 instructions: http://technet.microsoft.com/en-us/library/aa998707%28v=exchg.65%29.aspx

Exchange 2007 insutrctions: http://technet.microsoft.com/en-us/library/aa996343%28v=exchg.80%29.aspx

Exchange 2010 instructions: http://technet.microsoft.com/en-us/library/aa996343%28v=exchg.141%29.aspx

Exchange 2013 instructions: http://technet.microsoft.com/en-us/library/bb124097.aspx

2. Using either PFDAVAdmin or ExFolders, an administration can use a GUI to connect to a user’s mailbox and apply permissions to a folder, then force propagation of those settings to all child folders. This gives the user visibility and control of the current permissions and future changes, but also will save someone a lot of time from manually doing this.

For Exchange 2000 (sorry if you’re still on this!), Exchange 2003 and 2007, the PFDAVAdmin tool is used, available here: http://www.microsoft.com/en-us/download/details.aspx?id=22427. Keep in mind if you’re on Vista or above you’ll need to manually install Microsoft .Net 1.1. There are some great instructions here on how to do so: http://saranspot.blogspot.com.au/2009/02/installing-dotnet-framework-11-on.html

How to apply the permissions and propegate? This blog post contains great detail, although you can just choose the option of all mailboxes and drill down to the one you’re after rather than worrying about long URLs: http://www.nigelboulton.co.uk/2010/12/delegating-and-propagating-exchange-folder-permissions-using-pfdavadmin/

For Exchange 2010, they change the utility to ExFolders, available here: http://gallery.technet.microsoft.com/office/Exchange-2010-SP1-ExFolders-e6bfd405 . This one can only be run on your Exchange server, read the notes below the download.

Hope that helps anyone looking for a refresh on how to give mailbox permissions or propagate folder permissions!

Hi,

Following on from my post here http://www.adamfowlerit.com/2013/01/02/recovery-storage-groups-in-exchange-2007/, once you’re finished with your Recovery Storage Group, you should clean it up. A rather simple process, you start with this Exchange Powershell command:

Remove-MailboxDatabase -identity <Server_Name>\<RSG_Name>\<Database_Name>

This will do the obvious thing of removing the mailbox database. If you can’t remember what you called your Recovery Storage Group, just use the command ‘Get-MailboxDatabase’ and you’ll see all your databases, and if you’ve named the RSG sensibly, you’ll be fine. One thing I ran into was trying this command from a Windows Server 2008 R2 box, while Exchange 2007 was running on Windows Server 2003. It brought up an error saying that I couldn’t remotely do commands from 2008 to 2003, but when I got onto the 2003 box, the database was gone! If you didn’t have this problem, you should get a message stating that you need to manually remove the database file.

The second step is to remove the Storage Group with the following command

Remove-Storagegroup -identity "<Server_Name>\<RSG_Name>"

Again, run ‘get-storagegroup’ to remind yourself of the name. After this, you’ll get a message telling you to remove the log file:

WARNING: The specified storage group has been removed. You must remove the log file located in h:\path\logs from your computer manually if it exists. Specified storage group: exchange\rsg.

Pretty straight forward. If you don’t clean up your RSG, you may have issues with backup software detecting the extra database.

Source: http://technet.microsoft.com/en-us/library/bb125197(v=exchg.80).aspx