As an Exchange Administrator, I have been asked numerous times "grant this person access to my folder and all of its subfolders". Prior to Exchange 2010 there was no simple way to assign MAPI permissions to all of these Outlook folders. Exchange 2010 has added the Add-MailboxFolderPermission cmdlet which allows an administrator to now complete this task from the Exchange Management Shell.
You may also notice that Exchange 2010 provided another cmdlet, Get-MailboxFolder. When I saw this I thought "Wow! I can run the Get-MailboxFolder and pipe the Add-MailboxFolderPermission and I'm done." Did you really think it would be that easy? The Get-MailboxFolder cmdlet only runs against the currently logged in user. Yes, you can't run this cmdlet against another mailbox. Take a look at the management role where this cmdlet is available.
Get-ManagementRole -Cmdlet Get-MailboxFolder
Okay. Then how can we use the Add-MailboxFolderPermission to run against a root folder and all of its subfolders? Looking at all the parameters available for the cmdlet there is no recurse (wouldn't that be nice). I was able to accomplish this task in two steps:
1. Get a list of folders from the mailbox
2. Add the permission to the folder
Get-MailboxFolderStatistics
The first thing we need to obtain is the list of folders that we will apply permissions. We can utilize the Get-MailboxFolderStatistics cmdlet for this purpose. The result we want is the FolderPath value that is returned in the format "/Folderpath".
Get-MailboxFolderStatistics owner | Where { $_.FolderPath.Contains("FolderName") -eq $true }
Add-MailboxFolderPermission
Then we can use the Add-MailboxFolderPermission cmdlet to assign the permissions. The format for the folder name is "Mailbox:FolderPath" so we will need to modify the result from earlier to accomodate the expected value. The following example illustrates the example where Jane's manager John wants her to access his Clients folder and all of its subfolders.
ForEach($f in (Get-MailboxFolderStatistics John | Where { $_.FolderPath.Contains("/Clients") -eq $True } ) ) {
$fname = "John:" + $f.FolderPath.Replace("/","\");
Add-MailboxFolderPermission $fname -User Jane -AccessRights Reviewer
}
Conclusion
This is only an example of how you can accomplish this task. Use this with caution and always test prior to running against a production mailbox. The one known issue is the possible results when using the Get-MailboxFolderStatistics cmdlet. You need to adjust your where clause appropriately so that you don't get unwanted results.
Please send me any questions, comments, and/or suggestions to jim at endital dot com. Thanks.
Showing posts with label Exchange Server. Show all posts
Showing posts with label Exchange Server. Show all posts
Tuesday, September 7, 2010
Friday, July 2, 2010
Exchange 2010 Public Folders and the NT User Permission
I am currently working on a transition from Exchange 2007 to 2010. I like to use these types of projects to work on cleaning up the current environment before performing the upgrade. In this post I am going to talk about something every Exchange administrator loves... public folders. Why does everyone cringe when this topic comes up? We should be happy that Microsoft didn't build their replication technology for mailbox databases off of public folder replication. That would have been the end of Exchange. Back to the point. Everyone who has ever checked permissions on a public folder has seen this:

Well, now the question becomes: how can I easily remove these zombie accounts (terminology from back in the Exchange 5.5 days)? You could manually use either Outlook or PFDavAdmin to remove these permissions. But what if you had thousands of folders to process? I doubt any of us have that kind of time or patience. Exchange 2007 introduced Powershell, so let's look there. Here I have an example folder with its current folder permissions:

Well, now the question becomes: how can I easily remove these zombie accounts (terminology from back in the Exchange 5.5 days)? You could manually use either Outlook or PFDavAdmin to remove these permissions. But what if you had thousands of folders to process? I doubt any of us have that kind of time or patience. Exchange 2007 introduced Powershell, so let's look there. Here I have an example folder with its current folder permissions:
Thanks to PowerShell this task is going to be really simple. You just need to run the following command against this folder to remove the zombie account permissions from the parent and all subfolders:
Get-PublicFolder "\Folder1" -Recurse Get-PublicFolderClientPermission Where { $_.User.ToString().Contains("NT User:") -eq $true } Remove-PublicFolderClientPermission -Confirm:$False
Then when you check your folder permission it should look like the following:
Just a word of caution is the amount public folder replication traffic that this process may cause is dependent on the number of public folders and the number of permissions that were removed. The sample script above will also remove accounts that had their mailboxes removed. These accounts would appear as "NT User:DOMAIN\Username".
Friday, June 25, 2010
Exchange 2010 Recovery Database and Backup Exec 2010
Tonight I finally got around to testing the restore of an Exchange 2010 database. The server has only been online two weeks. The process was so simple I thought I would share it with everyone.
- The first thing I did was create the restore database using the New-MailboxDatabase cmdlet: New-MailboxDatabase -Recovery -Name RDB -Server Ex2010
- Then I selected New job under the Restore Tasks in Backup Exec 2010
- Selected the database to restore under Selections
- Selected to Redirect Exchange sets, Redirect using Volume Shadow Copy Service snapshot provider, and entered the server name under Restore to Database or Recovery Database
- Selected Commit after restore completes and Mount database after restore under Settings/Microsoft Exchange
That was it. The restore took about 15 minutes to complete and when it was finished the database appeared in the console as mounted. I can now sleep peacefully knowing this database is protected.
D9Z9A3XVCWF5
Subscribe to:
Posts (Atom)