Glen's Exchange and Office 365 Dev Blog

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

Outlook profiles can present somewhat of a challenge to any mail administrator regardless of the size of the mail system. One way of looking at Outlook profiles is that they are just a whole collection of registry settings on a machine which is true but the number and compelxity of structures involved means that if you want to write a script that will modify a particular profile for a particular user its not just as simple as modifying a single registry key. In previous versions of Outlook you could generally rely on the GUID "13dbb0c8aa05101a9bb000aa002fc45a" to locate the key where the values for the Exchange settings are located but if you have done any work with Outlook 2010 on windows 7 you will generally find this is nolonger the case and its now more reliable to enumerate all the keys under a particular profile and find a particular setting which will indicate this particular key has the values for the Exchange Setting you want to modify. The one thing that computers a

Recipient policies where first introduced in Exchange 2003 and later became email address policies in Exchange 2007 where we where all introduced to the joys and sorrows of Opath. While policies are a simple idea and a good method to do this type of thing the complexities of what happens underneath can be hard to get your head around and test and this can at times lead to the odd mistake. While there is a preview box when your modifying an Address list policy if you wanted to look at the bigger picture of the filter that the address policy represents as it is and could be applied to active directory objects, this is where it can be useful to use a script. The other thing to take into account when looking a policies is the objects where the application of the address policies have been disabled. So what I've done is build a GUI to help this the first thing this script does is enumerate all the policy objects and retrieve the following properties that are associated with these objec

If your unaware there is nasty mass mailer virus outbreak at the moment if you haven't already i would strongly urge you to visit and implement the measures in http://social.technet.microsoft.com/wiki/contents/articles/worm-win32-visal-b.aspx The above gives the best and quickest method for cleaning the affects of an outbreak using the EMS export-mailbox cmdlet but i thought I'd give some alternate methods using EWS . I can't guarantee any of these methods like i would with Export-mailbox and I would expect them to be slower (and possibly very slow) but they may come in use especially if your access is limited but you can use EWS Impersonation or if you looking to do some reporting based on subject. Finding Items based on there Subject is relatively simple in EWS and involves the use of a Search filter or if your lucky enough to be using Exchange 2010 you can make use of AQS which I blogged about earlier here . With a virus outbreak they generally start on a particular

One of the things missing from the standard folder properties when you use EWS to access a mailbox or public folder is the size of the folder. Those that have used other API's to do mailbox and public folder size reporting should already know about the extended mapi property PR_Extended_Message_Size this is what you also need to use in EWS to get the folder size to define this in C# you can use ExtendedPropertyDefinition PR_Extended_Message_Size = new ExtendedPropertyDefinition(3592, MapiPropertyType.Long); PropertySet psPropertySet = new PropertySet(BasePropertySet.FirstClassProperties) { PR_Extended_Message_Size }; Folder Inbox = Folder.Bind(service, WellKnownFolderName.Inbox, psPropertySet); Object FolderSize = null; if (Inbox.TryGetProperty(PR_Extended_Message_Size, out FolderSize)) { Console.WriteLine(FolderSize); } You can also make use of this in a script if you want an alternative to Ge

On Exchange servers pre Exchange 2010 when someone deletes an Item in Exchange it goes via the dumpster 1.0. Which is explained in http://msexchangeteam.com/archive/2009/09/25/452632.aspx as " essentially a view stored per folder. Items in the dumpster (henceforth known as Dumpster 1.0) stay in the folder where they were soft-deleted (shift-delete or delete from Deleted Items) and are stamped with the ptagDeletedOnFlag flag. " . Being able to report on the items that are stored in these views can be useful for a number of auditing and admin reasons. With Exchange Web Services you query the items stored in these views using a SoftDeleted traversal of the folder in question. This works well for items that are stored in the dumpster of a normal mailbox folder but there is a problem when you have a hierarchy of folders that gets deleted. When this happens you can only query the first of the deleted hierarchy using a soft deleted traversal and the findfolders operation. W

As time passes we all receive more and more email, this is one of the irrefutable facts of life for any mail system or anybody with a mailbox. Even the most fastidious of deleters still can't avoid this so at some point in the future you may need to consider achieving. The fact is your users maybe already self archiving using PST files which like self medicating can lead to serious problems down the track when their laptop goes under a bus. Exchange 2010 introduced native achieving and SP1 when its released will build on these capabilities, for other versions of exchange there are a bunch of other fine products you can look at to do this. If your looking to ingest PST's into an online archive you may want to first review what content your going to be importing and look at things like how many attachments and what type are they and how old is the content to give you a feel for what your going to be storing and potentially having to backup. What this boils down to is if you wan

One of the great new features of Exchange Web Services on Exchange 2010 is the ability to use AQS (Advanced Query Syntax) when querying a mailbox folder. The reason this is helpful is that it provides an easily assessable entrypoint into the Exchange Search Service. The Exchange Search Service has been constantly improving with each new version of Exchange when you consider the size and Item counts of the modern mailbox this has now become a vital component of Exchange and something that those using EWS should consider taking advantage of. For the basics behind the difference between a Store Search and one use that utilizes the Exchange Search Service the Exchange Team blog has a great three part post on the subject. The main points of interest are that index searches are considerable quicker and can be used to do things such as look at the content of an attachment which a normal store search can not do. Of course there are also a number of things a store search can do

Last month i posted a script for getting the Iphone IOS version information for all users on a server using the Get-ActiveSyncDeviceStatistics cmdlet which worked okay but had one major flaw in that it doesn't pick up the updates to the O/S as pointed out in http://www.hedonists.ca/2010/07/22/blocking-the-iphone-part-i. So the only 100% way would be to parse the IIS logs where you can grab the same information about the devices as long as the cs-useragent is being include in the logs (if not you need to change this). This script is still useful for somethings and hopefully i should be able to re-purpose this to do something useful. There are good and bad things about parsing logs, the good is that this technique should work on any version of Exchange including 2003 the bad is that if your log files are large then there are much better ways then using Powershell to parse them (such as logparser). But using PS does have a number of advantages and if your whiling to wait while the s