Update Calendar folder permission

Most admins have one time or another come across the need for changing permission on individual folders in mailboxes.
Most common cases I have seen this is for calendar folder in resource mailboxes.
This is an easy task but some challenges exist. To start with you use the MailboxFolderPermission cmdlet to set/add/remove permissions.

To read the existing permission on the calendar folder, run.

Get-MailboxFolderPermission -Identity LasseP

And you will see the following output.

FolderName : Top of Information Store
User : Default
AccessRights : {None}
Identity : Default
IsValid : True

FolderName : Top of Information Store
User : Anonymous
AccessRights : {None}
Identity : Anonymous
IsValid : True

You see the usual Anonymous and Default permission group. Interesting here is that you see the permission for “Top of Information Store” which is the root folder in the mailbox.


To get permission for a specific folder you have to specify this as a parameter and here we must know the exact folder name. This gives us some interesting challenges for Multilanguage organization because the calendar folder can have different names.
So if I specify the calendar folder name in Swedish

Get-MailboxFolderPermission -Identity LasseP:\Kalender

I get an error because the folder name is not “Kalender”, but when specifying the English name I get what I want.

Get-MailboxFolderPermission -Identity LasseP:\Calendar

FolderName : Calendar
User : Default
AccessRights : {AvailabilityOnly}
Identity : Default
IsValid : True

FolderName : Calendar
User : Anonymous
AccessRights : {None}
Identity : Anonymous
IsValid : True

Folder name must also be correct when using Set/Add-MailboxFolderPermission.
So how do we know the calendar folder name for a mailbox?
Here is neat trick we can use to get the name with Get- MailboxFolderStatistics cmdlet.

Get-MailboxFolderStatistics -Identity LasseP -FolderScope Calendar | Select-Object -First 1).Name

The output will be a text string with the calendar folder name, in our example it is “Calendar”.
Selecting only the first object is needed because users can have more than a single calendar folder and we want only the default calendar folder in the mailbox which is returned first.
Next step is to update the ACL with new permission, and here we have one more challenge. We need to figure out if we want to add permission or change existing reason for this is that we have two cmdlet to use, Add-MailboxFodlerPermission and Set- MailboxFodlerPermission. Each one of them will give an error if used in the wrong context.

To add a new user (or a group) to the ACL, run.

Add-MailboxFolderPermission -Identity LasseP:\Calendar -User Eva -AccessRights Reviewer

This will grant user Eva the reviewer permission on LasseP’s calendar folder.
Running the same cmdlet again will give you an error with “Add-MailboxFolderPermission : An existing permission entry was found for user: Eva”.

To change the permission you must use Set-MailboxFolderPermission

Set-MailboxFolderPermission -Identity LasseP:\Calendar -User Eva -AccessRights Owner

The vice versa is true if you run Set-MailboxFolderPermission and the user being granted permission is not in the ACL you will get an error saying “Set-MailboxFolderPermission : There is no existing permission entry found for user: Axel”
So before we can update the folder permission you must know if the user/group is already member of the ACL. This is accomplished by using Get-MailboxFolderPermission, this we already tried earlier.
To make things easier without issuing multiple commands I created a script.

Update-CalendarFolderPermission.ps1

########################################
# Update-CalendarPermission.ps1 -Identify <mailbox> -User <xxx> -Permission <permission>

param
(
    [Parameter(Mandatory = $true, HelpMessage="Enter a mailbox where you apply permission to")]
    [ValidateNotNullOrEmpty()]
    [string]$Identity ,

    [Parameter(Mandatory = $true, HelpMessage="Enter a user/group who will be granted the permission  syntax domain\xxx might be needed")]
    [ValidateNotNullOrEmpty()]
    [string]$User = "",
    
    [parameter(Mandatory = $true, HelpMessage="Enter a valid permission set")]
    [ValidateSet("ReadItems","CreateItems","EditOwnedItems","DeleteOwnedItems","EditAllItems","DeleteAllItems","CreateSubfolders","FolderOwner","FolderContact","FolderVisible","None","Owner","PublishingEditor","Editor","PublishingAuthor","Author","NonEditingAuthor","Reviewer","Contributor","AvailabilityOnly","LimitedDetails","Remove")]
    [string]$Permission = ""
)

#Add Exchange 2010 Management Shell if needed
if (! (Get-PSSnapin Microsoft.Exchange.Management.PowerShell.E2010 -ErrorAction:SilentlyContinue) )    {
    Add-PSSnapin Microsoft.Exchange.Management.PowerShell.E2010 -ErrorAction:Stop
}

$MBX = Get-Mailbox $identity

$CalendarName = (Get-MailboxFolderStatistics -Identity $MBX.alias -FolderScope Calendar | Select-Object -First 1).Name
$folderID = $MBX.alias + ':\' + $CalendarName

if ($Permission -eq 'remove') {
    # special case, remove permission from user
    Remove-MailboxFolderPermission -Identity $folderID -User $User -Confirm:$False
}
else {
    $i = @(Get-MailboxFolderPermission -Identity $folderID -User $User -ErrorAction SilentlyContinue).count
    if ($i -eq 0) {
        # not in ACL, add permission
        Add-MailboxFolderPermission -Identity $folderID -User $User -AccessRights $Permission > $Null
    }
    else {
        # user is already in ACL, change permission
        Set-MailboxFolderPermission -Identity $folderID -User $User -AccessRights $Permission
    }

    # display new permission for $user
    Get-MailboxFolderPermission -Identity $folderID -User $User
}

Script isn't that hard to follow, there is some required input parameters needed. When this is handled, script continue with figuring out the calendar folder name then add or set permission depending on if user is already on ACL.

I also built in a special case where you could set permission to "remove" to remove the user from ACL on the calendar folder.


An example would be.

Update-Calendarpermission -identity Eva -User Lassep -Permission ReadItems

This will grant Lassep Read permission on Eva's calendar folder.


Script don't accept pipelining from other commands so if you want to update permission on multiple mailboxes you need to do this with two lines of code instead.

$mbx = Get-Mailbox conf*
foreach($mb in $mbx) { .\update-calendarpermission.ps1 -Identity $mb.Alias -User Lassep -Permission ReadItems}

First line is save mailboxes you want to change permission on into the $mbx variable.

Second line calls the Update-CalendarPermission script once for each mailbox in the $mbx variable.

The two line script will grant LasseP Read Permission on all 'conf*' mailboxes


now, go and play with this is a lab before running it on every mailbox in your production environment.

Some thoughts about applications sending SMTP messages to Exchange

Most organizations have applications that need to send mail, either to internal recipients or to have a SMTP server to relay there mail destined for external recipients.

Common configuration is that they figure out the server IP address where the application runs on and then enter the IP on the allow relay list on Exchange 2003 virtual server, if then run Exchange 2007 they often are a little bit puzzled until someone shows them MSExchangeteam 'Allowing application servers to relay off Exchange Server 2007'.

Why do I think this is bad?
First, most applications don't need the relay permission, admins often think so but the truth is that they don't need it.
Servers are not static, IP changes, name changes both on the application side and the Exchange side. If the server get infected with something bad, it is not just the application running on the server that are allowed to relay but everything running on the server since its the IP that are allowed to relay.
Remember this: IP restrictions are not authentication.
Have seen applications that are hardcoded to connect to a specific IP or names meaning that either IP or name can be changed on the Exchange server.
Resolution is of course to have applications easy to reconfigure with destination SMTP server’s name.

Another problem is when there is some kind of anti spam software running on Exchange. This will often make the applications mail end up being classified as spam and make Exchange admins trying to configure the anti spam software to white list some mail. Sometimes this cant be done and sometimes it can making admin workload bigger than before.
Resolution here is to educate developers in SMTP. They often doa good job of building applications but are very often bad at SMTP. They find a free SMTP engine on Internet and they stick it in there applications and in the end they manage to send a SMTP mail but it is often bad formatted in various way making the anti spam software react and classify it as spam.
Resolution here is of course knowledge about SMTP.

Back to the relaying part of sending mail. One very good solution here is to have the submitting application to authenticate SMTP session. By sending authenticated SMTP mail to Exchange, it will get the permission to relay, it will most likely bypass antispam software depending of software of course. It will also make the application easier to move to another server without reconfigure Exchange. Another thing with authentication and SMTP is that if I authenticate as ‘application 1’ I am only allowed to use ‘application 1’ email address, I cannot use another SMTP sender address..

My recommendations to developers, building applications sending SMTP mail.
* Use a good SMTP engine that do work. Have encountered one that didn’t like the tarpit time you can configure in Exchange 2003 and are default activated on Exchange 2007. This engine simply could not work with tarpit.
* Use authentication when submitting mail. NTLM is of course better than Basic, but if using basic authentication, use it over TLS.
* Ability to easy change SMTP configurations such as server name, sender and receiver SMTP address, TCP port etc.
* Have redundant SMTP server configuration. The SMTP server that you’re using may not be up and running. If mail are critical, consider having some queue functionality in the application that can try to resend mail. One queue functionality would be to use the local windows SMTP service, but this will only work if application run on Windows boxes and the local SMTP service is working.
* Use only valid sender and destination SMTP addresses. If there is NDRs, they should go back to an existing mailbox that someone can monitor and act upon.

There are of course recommendations to Administrators as well.
* Clearly communicate to developers what the rules are for submitting SMTP mail to Exchange. No hardcoded configuration, no anonymous submission etc.
* Add a good name for your SMTP servers, such as ‘smtp.ADdomainname’ for developers to use instead of giving them the real servername or IP. With a standardized name across all applications you can make them use another server when there is need. If you internal Active Directory name is company.local your smtp server name would be SMTP.company.local
* Set up internal MX records for the AD name space. Same advantage as above.
* If you have multiple HUB server, Load balance TCP port 587 across those servers and make applications use SMTP submission port 587 (this is the client receive connector that are default created on Exchange 2007)  instead of the default 25. Don’t load balance port 25 since it will break functionality in Exchange such as authentication.
* Be very careful of what mail you let through to internet, maybe you should block applications to send to Internet on connectors to maintain your good name on Internet. Companies have ended up on various blacklists because developers have built bad SMTP mail or have a buggy application that spray mail across Internet.

There are probably many more options/alternative/thoughts around this, but these are just some that regularly pops up.

Grant permission to change permission on mailboxes

To change mailbox permission on an Exchange 2003 mailboxes you must have the Exchange Full Administrator right. In many organizations there is just a few people that have this right, but the need to change mailbox permission is quite big, often the need is to give Full mailbox access to a user on a mailbox that is unmonitored.

And there we have a conflict, do we trust helpdesk or a novice Exchange administrator to have the Full Exchange Administrator permission? probably not. So what can be done?

Luckily there is a way to grant the permission to change permission on mailboxes without being the big Exchange administrator, sort of.

Use Exchange Management Console, drill down to a mailbox database, right click and click properties and select the security tab, add the helpdesk group and select Allow only Change Permission and Administer Information Store.
Change Permission will inherit down to mailboxes. The helpdesk group must also have Active Directory permission to manage user account. This is done with normal AD delegation.
Unfortunately helpdesk group must also have Administer Information Store permission to get what we want. With this right they can also dismount and mount that database.

Two links that help you understand things better.
http://support.microsoft.com/kb/329236
http://technet.microsoft.com/en-us/library/bb124053.aspx

This is not the ideal solution, but if there is a need for setting mailbox permission without being Full Exchange Administrator, this solution can help.