Glen's Exchange and Office 365 Dev Blog

In Exchange 2010 SP1 throttling is enabled by default and while for the best part this is a good thing there are a few things you may need to be careful of if you have written code that retrieves a large number of items from a mailbox folder. While you can disable or set custom throttling polices for your application or scripts its generally a better idea to build your code to work within these throttling thresholds. With EWS the throttling policies affect a number of different areas from the number of concurrent connections one user can establish to a server, limits on the number of subscriptions and also the CPU time one particular user can consume when executing particular operations. For the most part if your using simple single threaded scripts where your not executing requests concurrently most of the settings wont have any bearing. The one policy setting that will have a direct affect on existing scripts or code is the EWSFindCountLimit which by default is limited to 1000. Thi...

One of the new cmdlets in Exchange 2010 SP1 is the Set-MailboxFolderPermission cmdlet which was an addition to the other Exchange 2010 RTM folder permission cmdlets get-MailboxFolderPermission and add-MailboxFolderPermission. What this cmdlet gives you the ability to do is update the permissions of any folder within a mailbox as long as you are a member of the RBAC roles that allows you set them as specified in http://technet.microsoft.com/en-us/library/dd638132.aspx . Another thing this cmdlet does is give me the ability to revisit the default calendar folder permission GUI from this post (which used EWS and will still work okay on 2010) and rewrite this to be able to be used in Remote powershell so it will work against any 2010 SP1 server as well as anything else that supports these cmdlets such as live@edu or Office365. If you don't really want a GUI and would rather just export the permissions to CSV modify them and then reimport them that's easy to do for example to expo...

Normally if you want to work out the size of a mailbox or the size of a mailbox folder as an administrator you would use get-mailboxstatistics and get-mailboxfolderstatistics the Exchange Management Shelll cmdlets which are the fastest and easiest way of retrieving this information on 2007 and 2010. However if you want to get the Mailbox size using normal user rights or the EMS cmdlets aren't an option then EWS can be used. There is no one property inside a mailbox that can be used to get the total size of a mailbox so like you needed to do in 2003 and earlier to calculate the size of a mailbox you need to get the size of each mailbox folder then sum these together. To get the Size of the Mailbox Folder and Deleted Items within a folder requires the use of the following extended Mapi properties PR_MESSAGE_SIZE_EXTENDED and PR_DELETED_MESSAGE_SIZE_EXTENDED To get the properties on all of the folders in a Mailbox a Deep Traversal findfolders operations from the Root ...

A big leap forward on Office365 compared with the current BPOS offering is the ability to use remote powershell and a subset of the Exchange cmdlets that are available in Exchange 2010. This makes it pretty easy to migrate your current onpremise scripts that use make use of EMS and EWS into something that uses remote powershell and EWS. To demonstrate this I've converted on my old scripts the FreeBusy board to use Remote powershell, Office365 and the EWS Managed API 1.1. I've put a download of the script here the code looks like $UserName = "admin@domain.com" $Password = "password1" $secpassword = ConvertTo-SecureString $Password -AsPlainText -Force $adminCredential = New-Object -TypeName System.Management.Automation.PSCredential -argumentlist $UserName,$secpassword If(Get-PSSession | where-object {$_.ConfigurationName -eq "Microsoft.Exchange"}){ write-host "Session Exists" } else{ $rpRemotePowershell = New-PSSession -Configura...

This has taken me a little longer then expected to update but I've finally created a version 2 of my simple powershell client script i posted here . Firstly if you missed it the new version the EWS Managed API 1.1 has been released which allows you to access all the new 2010 SP1 functionality like archive mailboxes, dumpster v2 etc you can download this from here the new script requires this library. The new features I've added to the script is firstly there is a Entry Point box that allows you to select what entry point you want. The Non IPM Root is usefull if you want to look at the dumpster folders or other things in the Non_IPM_Root, Archive root takes you into the Archive mailbox if its exists for that user. Another new edition is the ItemType box which allows you the select between being able to view the Normal Mailbox Items, FAI (Folder Associated Items) or Deleted Items (not really applicable for Dumpster v2). Lastly because the new script is built for use with Window...

Great strides have been made since Exchange 2007 SP2 with the introduction of more advanced audit levels into Exchange which have again improved in Exchange 2010 and again with 2010 SP1. Auditing however relies on a few things that after the fact of an event you may have wished to audit (or more likely a Superior wanting to know what mailboxes where accessed) . But like footprints in the sand when you walk along the beach many of the actions we do in Outlook do leave marks that the majority of people may not realize. One such mark in the sand that happens in your mailbox when using Outlook 2010 or OWA 2010 is when you access another users folder eg calendar, contacts etc is a wunderbar link gets added to the Common Views Root folder. What you can do with this little bit of information is deduce what other mailboxes a particular user has been access by enumerating the wunderbar links in the users common view folder. These wunderbar links are FAI (folder associated Items) so live in th...

In Exchange 2007 SP3 Microsoft implemented canaries in OWA to help prevent man in the middle/cross scripting attacks in OWA http://msdn.microsoft.com/en-us/magazine/dd458793.aspx#id0080023 gives a good explanation around why you would want to use a canary and what it is. But put basically a canary is a secret between the client and server in OWA this gets stored in cookie collection of your browser and then it gets submitted with the various requests that your browser sends. If your request doesn't have the canary then the server pretty much says "no OWA for you!". Because in the scripting world it can be useful as a workaround to instrument OWA to automate particular things such as enabling the extended junk-Email rule in OWA and Outlook in the past I've posted scripts that use OWA automation that have now pretty much been broken by the canary's. So to fix this you need to add some code that will deal with the canary my favorite object to use for these type of...