Glen's Exchange and Office 365 Dev Blog

Two new EWS Operations ExportItems and UploadItems where introduced in Exchange 2010 SP1 that allowed you to do a number of useful things that where previously not possible using Exchange Web Services. Any object that Exchange stores is basically a collection of properties for example a message object is a collection of Message properties, Recipient properties and Attachment properties with a few meta properties that describe the underlying storage thrown in. Normally when using EWS you can access these properties in a number of a ways eg one example is using the strongly type objects such as emailmessage that presents the underlying properties in an intuitive way that's easy to use. Another way is using Extended Properties to access the underlying properties directly. However previously in EWS there was no method to access every property of a message hence there is no way to export or import an item and maintain full fidelity of every property on that item (you could export the...

One of the new features that was added in Exchange Web Services in 2010 SP1 (and improved in the Exchange Management Shell) was the ability to add Inbox Rules. Previously the only method for doing this programatically was a variety of Mapi methods some of which where not particular easy to use. Using the Exchange Management Shell New-InboxRule, Get-InboxRule and Set-InboxRule cmdlets offers an easy one-liner approach for the Admin but if you want to run your code as a non admin or you want to take advantage of EWS Impersonation to create rules on behalf of the user then Exchange Web Services is a good option for this. There are 3 major components to rules RuleConditions RuleExceptions (Optional) RuleActions Rule Conditions and Exceptions are essential the same they use the same objecttype RulePredicates the difference is that the conditions in ruleconidtions dictate what items a rule fires on and the exceptions dictates the conditions it doesn't fire on. With both the ...

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...