Glen's Exchange and Office 365 Dev Blog

Information security and data breaches are a hot topic at the moment, there seems to be a constant stream of data breaches and vulnerabilities in different products being exploited on a daily basis. One topic that was brought up in the last few weeks has been Address Book data https://www.wired.com/2016/09/people-please-dont-store-private-data-address-book/  . Address books can be the proverbial open window on the house with bars on door and maybe not something that is commonly thought about.  If you want to detect if people are using Address book to store confidential information it can be a challenge because this data isn't searchable via a conventional eDiscovery type search. But this is where a scripted enumeration and filtering approach can do the job. I posted a Contacts Powershell module that consolidated a lot of EWS contacts function into one script last year so for this post I've extended this to include a Search that will enumerate all the contacts in a Mailbox...

Invalid delegates have always been a tricky issue in Exchange an Invalid delegate happens when a mailbox that has a delegate setup and the delegate user account is deleted or disabled(has the Exchange attributes removed). When your using the EWS delegate operations and a mailbox has an invalid delegate you get a message back to tell you the delegate doesn't map to an active directory user however it doesn't tell you who that user was and what type of delegate access that user had. You also can't use the EWS delegate operations to remove a user in this state so you end up with a kind of stalemate solution that requires a manual delete with Outlook. Before going any further its worth covering briefly what happens when you add a delegate to mailbox within Oultook there are three areas of the delegator's mailbox that gets modified. Local freebusy object in the mailbox Permissions on folders that are given access to Rules collection if forward meeting requests option se...

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

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