Glen's Exchange and Office 365 Dev Blog

If it hadn't escaped your notice Exchange 2010 SP2 was released this week although from an EWS perspective there isn't that much to shout about one of the interesting new operations is the GetPasswordExpiration operation. This allows you to get the DateTime when the password for an account will expire. Currently version 1.1 of the Managed API doesn't support this operation but from the information that has been released the next version should. In the meantime you can take advantage of this new operation using some raw SOAP. The following is a quick sample script that makes a GetPasswordExpiration request there is some SSL ignore code so it should run okay in a test environment without a valid SSL cert. To use this script you need to configure the following variables. $MailboxName = "user@domain.com"         $cred = New-Object System.Net.NetworkCredential("user@domamin.com","password") If you don't have autodiscover configured if y

Following on from my previous post on using MailTips and one of my other popular posts the FreeBusy board the following script creates an Out of office board that shows in one page peoples out of office status and if the out of office message is turned on it displays the OOF message for that user.Here's a quick picture of what it produces So how does it work it takes advantage of MailTips within EWS to get the OOF status of a user and what the OOF message is if its set. If you have a large number of users it batches the MailTips request in batches of 100 to ensure the request is successful. To get the list of users to query it takes advantage of using Remote powershell and uses the Get-Mailbox cmdlet. The following script is setup to work with Office365 but will work OnPremise as well if change around the remote powershell URL. The following variables are those that need to be configured to run this script $UserName = "user@domain.com" $Password = "passw

MailTips is one of the really useful new features of Exchange 2010 that can be exceedingly useful to anybody using Exchange Web Services. It provides access to Information such as the OOF status of a user or users within one WebService call and without the need for Full Access or elevated rights you would normally need with a GetUserOofSettings operations or using the Remote powershell cmdlets such as Get-MailboxAutoReplyConfiguration. The other thing MailTips are useful for apart from the other standard Mail-tips listed http://msdn.microsoft.com/en-us/library/dd877060%28v=exchg.140%29.aspx (things like the Max message size is useful for anybody sending email via EWS etc)  is the ability to create Custom MailTips. This gives you the ability to now retrieve a custom property that is stored within Active Directory via EWS. Which provides a workaround to not being able to access the information in the AD Custom Attributes http://technet.microsoft.com/en-us/library/ee423541.aspx curre

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 fold

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

One of the most important learning points when thinking about programing or designing Transport agents is to understand the different between a P1 (Delivery Envelope) and P2 (Display Envelope) The P1 (Delivery Envelope) contains the recipient To and From information that is transmitted to the MTA server be it Exchange or any other SMTP server in the SMTP conversation and is the actual information that will be used for delivery of the message. Eg the Evaluating MTA will only examine the P1 recipients to determine what recipients a message would be delivered to. The P2(Display Envelope) contains all the information that that the user will see when they receive the message this includes the From, To ,CC and Subject of a message. The important point to understand is that the MTA that is processing the message doesn’t look at these headers to determine whom to deliver the message to. BCC’s One of the things that confuses a lot of people when they look at messages via an API or within an Tr

Message classifications have been around since Exchange 2007 and are a feature of Exchange that allows you to setup your email system to add classification to messages to comply with e-mail policies and regulatory responsibilities that Governments and other bodies may require of an organization. If you want to set a message classification on a Message your sending pro-grammatically via EWS you need to first find out what the GUID of the classification you want to set is. There are a few ways of doing this the easiest is using the Get-MessageClassification cmdlet http://technet.microsoft.com/en-us/library/aa996911.aspx the value you will need for your app or script is the ClassificationID which represents the PidLidClassificationGuid Mapi property which if you’re playing around with Transport Agents this gets converted into the x-ms-exchange-organization-classification x-header. You can also grab it out of your classification xml file if you have deployed it to Outlook. All the propert

When your dealing with Archive and Retention policies in Exchange 2010 one of the important questions to ask is what property is used to calculate the age of an Item. While it might be tempting to use some of the easy to get to datetime properties the important property to use in relation to Archive and Retention policies is the PidTagStartDateEtc property which is documented in http://msdn.microsoft.com/en-us/library/ee179537%28v=exchg.80%29.aspx. So as stated this is a composite property with the first 4 bytes belonging to the default retention period if it has been applied then the final 8 bytes gives the UTC Datetime from which the Message object's age is calculated. The following is a quick sample of how to extract this datetime from that property using the EWS Managed API. ExtendedPropertyDefinition PidTagStartDateEtc = new ExtendedPropertyDefinition(12315, MapiPropertyType.Binary); Object StartDate = null; itItem.TryGetProperty(PidTagStartDateEtc, out StartDate); long fileT

Just a quick note to let everyone know who is interested in reading more about the search capabilities of Exchange Web Services against Exchange Online (Office 365) and Exchange 2010 Check out my article that's just been published on MSDN http://msdn.microsoft.com/en-us/library/hh148195%28v=EXCHG.140%29.aspx

While there are plenty of cmdlets within the Exchange Management Shell to calculate the Mailbox and Folder sizes and even Item sizes within public folders there is no cmdlets you can currently use to look at the age of the content within a mailbox to see how old it is and what affect an retention policy may have for example you may want to know how much data will be shifted to an archive store(Search-Mailbox kind of does it but...). To look at Mailbox Content the EWS Managed API provides a easy entry point and the flexibility to do this . On Exchange 2010 to scan for content between a particular date range using a Content Index query via Exchange Search is the quickest and most efficient way of querying this data. The EWS Managed API allows you to perform a CI search via Exchange Search using the AQS querystring overload parameter of the FindItems method see http://msdn.microsoft.com/en-us/library/ee693615%28v=exchg.140%29.aspx . With AQS the operator .. can be used to search between