Glen's Exchange and Office 365 Dev Blog

While Exchange 2010 provides some really good cmdlets now for setting and changing folder permissions such as Set-MailboxFolderPermission http://technet.microsoft.com/en-us/library/ff522363.aspx . Using EWS to do this can still be useful in circumstances where the cmdlets can't be used or your having problems with localized folder names or you want to take advantage of EWS Impersonation to get around any issues your having with acquiring the correct rights to make the changes you might need. I'll look at the example of changing the default calendar permissions of the default ACL on the calendar as this is one of the harder things to do and there are a few points that can catch you out. First point is that when you modify permissions with EWS you basically grab the DACL from the server make your changes locally to the DACL and the post it back in a Update Folder operation. This means the logic you use on the client side needs to be up to dealing with this. The permissions ob...

While this is now something you can do in one line in Exchange 2007 and 2010 if your migrating or managing 2000/3 you may want to get the Size and Item Count details of one particular mailbox folder for all users on a server eg how big the Inbox,SentItems or Calendar folder is. In Exchange 2003 you could get the Mailbox Size via WMI but to get an individual folder size you need to access the Mailbox itself (eg you can use pfdavadmin etc). To do this via Power shell for all users on the server you first need an ADSI query to get all the mailboxes on a particular server then you can use with WebDAV via the virtual admin root or MAPI via RDO\Redemption  http://www.dimastr.com/redemption/ which works well in Powershell. I have two scripts that use show how do to this using each of these API's which I've posted a downloadable copy here To run these scripts you need to use the Netbios name of the server as a commandline parameter the RDO version of the script looks like $snServer...

Search folders are one of the suite of Exchange search options you can use programatically or to provide users with different views of their mailbox data in Outlook or OWA. Essentially a search folder is like a regular mailbox folder, except that it contains only links to messages in other folders that meet the criteria set in the search filter restriction which means that search folders are great for nonchanging, nondynamic queries. Search folders like Search Filters make use of restrictions in Exchange rather then using the Content Index which means that this comes along with some compromises ,if you are going to use search folders (or a lot of search filters) defiantly have a read of  http://technet.microsoft.com/en-us/library/cc535025%28EXCHG.80%29.aspx . To create Search Folders using the EWS Managed API its pretty simple for search folders to be visible in Outlook you need to use the SearchFolders WellKnownFolderName enumeration which in a Mailbox relates to the Finder ...

Although there are a few better methods of doing this these days this is still handy to have especially if your running older versions of Exchange or you want to audit the raw ACE's that are being added by RBAC in Exchange 2010. Extended rights get used for a number of things EWS Impersonation is one, SendAs is another anyway here's an old C# sample I tripped over today. using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.Collections; using System.Security.AccessControl; using System.DirectoryServices; namespace showImpRights { class Program { static void Main(string[] args) { DirectoryEntry rootdse = new DirectoryEntry("LDAP://RootDSE"); DirectoryEntry cfg = new DirectoryEntry("LDAP://" + rootdse.Properties["configurationnamingcontext"].Value); DirectoryEntry exRights = new DirectoryEntry("LDAP://cn=Extended-rig...

Search folders in Exchange make searching for items in multiple folders a little more easier and/or allows you to group and find email with certain properties easier eg things like Unread email, Flagged for followup etc. Outlook 2010 makes use of these features for To-Do list etc. One useful search folder that gets created by Outlook 2010 when its used against a Exchange 2010 server is the AllItems search folder. eg this one This is a search folder that gets created in the NON_IPM_Subtree folder and essentially allows you to do a generic search of all the folders within a Mailbox. This can be useful in a powershell script if you do need to enumerate every item within a mailbox to use the Allitems search folder you first need to do a search for this search folder in the Mailbox Root and then you can use some normal findItems enumeration code. To filter a findfolders operation to only return search folders you can use the PR_Folder_Type extended property if this property is set to 2 then...

When it comes to scripting Exchange autodiscover can be a great source for all types of configuration information about an Exchange mailbox and in 2010 it now returns a lot more information about a users mailbox. The EWS Managed API 1.1 provides some new objects that allows a more granular use of Autodiscover which can be helpful in different situations for example during migrations where DNS records for autodiscover may not exist or point to different server etc. To look at one example lets take Office365 if you want to connect to mailboxes in the Exchange Online cloud using EWS but DNS isn't setup your hosted domain for autodiscover you could use the following script to discover the EWS URL to use. $mailbox = "glen@mydomain.inthecloudblah.com" [System.Net.ServicePointManager]::ServerCertificateValidationCallback = {$true } $dllpath = "C:\Program Files\Microsoft\Exchange\Web Services\1.1\Microsoft.Exchange.WebServices.dll" [void][Reflection.Assembly]::LoadFile(...

When you’re looking at automating Office365 and Exchange Online from managed code you need to be aware of the 2 sets of cmdlets that you may need to use depending on the tasks that your trying to perform. Most of the administration of ExchangeOnline is done using remote powershell where Exchange Online provides a subset of the normal on-premise Exchange 2010 SP1 cmdlets. The other cmdlet set to be aware of is the MSOnline powershell module which you need download and install http://onlinehelp.microsoft.com/en-us/office365-enterprises/hh124998.aspx . The MSOnline module contains cmdlets to allow administration of the wider Office365 service and perform more of the directory/service and service provider functions more akin to Active directory management in a on premise environment (eg adding users to groups etc). So when using this from Managed code to use Remote powershell against Exchange Online you use the standard code you would use against an on-premise Exchange 2010 deployment aga...