Glen's Exchange Dev Blog

401 errors in Exchange Online using EWS WSDL proxy code and raw HTML

2012-01-25T21:38:00.000+11:00

If your developing EWS code against Exchange Online or possibly another large load balanced Hosted Exchange system you may find that a lot of the sample code you see on MSDN or other places that uses EWS Proxy code will always return 401 errors when you try to use it against Exchange Online (The Managed API isn't affected) eg a standard example is something like http://msdn.microsoft.com/en-us/library/bb408524%28v=EXCHG.140%29.aspx. What can cause this problem is the failure to process the exchangecookie in an appropriate way. There is description of what the exchangecookie is used for on http://blogs.msdn.com/b/exchangedev/archive/2011/07/20/client-access-server-affinity-and-network-load-balancing-considerations-for-programmatic-access-to-exchange-online.aspx . Although this says nothing about Authentication if the request object your using be its a SOAP proxy or HttpwebRequest doesn't have the cookiecontainer initialized (which by default they don't) before you submit the first request you'll get a 401. So basically if you have a normal EWS sample after you set the URL or Credentials make sure you initialize the cookie container.eg.

esb.Url = "https://CAS01.contoso.com/EWS/exchange.asmx";

esb..CookieContainer = new CookieContainer();

If your using Raw HTML and a HttpWebRequest make sure you do the same thing before submitting the first request.

A code sample is worth a 1000 words so here's a basic Exchange Online/Office365 Autodiscover and WDSL proxy sample that just does a simple GetFolder to the Inbox.

String MbMailbox = "user@domain.onmicrosoft.com";
String AutoDiscoURL = "https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml";
NetworkCredential ncCred = new NetworkCredential("user@domain.onmicrosoft.com","password");
String EWSURL = null;
String auDisXML = "<Autodiscover xmlns=\"http://schemas.microsoft.com/exchange/autodiscover/outlook/requestschema/2006\"><Request>" +
"<EMailAddress>" + MbMailbox + "</EMailAddress>" +
"<AcceptableResponseSchema>http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a</AcceptableResponseSchema>" +
"</Request>" +
"</Autodiscover>";
System.Net.HttpWebRequest adAutoDiscoRequest = (System.Net.HttpWebRequest)System.Net.HttpWebRequest.Create(AutoDiscoURL);
byte[] bytes = Encoding.UTF8.GetBytes(auDisXML);
adAutoDiscoRequest.ContentLength = bytes.Length;
adAutoDiscoRequest.ContentType = "text/xml";
adAutoDiscoRequest.Headers.Add("Translate", "F");
adAutoDiscoRequest.Method = "POST";
adAutoDiscoRequest.Credentials = ncCred;
Stream rsRequestStream = adAutoDiscoRequest.GetRequestStream();
rsRequestStream.Write(bytes, 0, bytes.Length);
rsRequestStream.Close();
adAutoDiscoRequest.AllowAutoRedirect = false;
WebResponse adResponse = adAutoDiscoRequest.GetResponse();
String Redirect = adResponse.Headers.Get("Location");
if (Redirect != null)
{
adAutoDiscoRequest = (System.Net.HttpWebRequest)System.Net.HttpWebRequest.Create(Redirect);
adAutoDiscoRequest.ContentLength = bytes.Length;
adAutoDiscoRequest.ContentType = "text/xml";
adAutoDiscoRequest.Headers.Add("Translate", "F");
adAutoDiscoRequest.Method = "POST";
adAutoDiscoRequest.Credentials = ncCred;
rsRequestStream = adAutoDiscoRequest.GetRequestStream();
}
rsRequestStream.Write(bytes, 0, bytes.Length);
rsRequestStream.Close();
adResponse = adAutoDiscoRequest.GetResponse();
Stream rsResponseStream = adResponse.GetResponseStream();
XmlDocument reResponseDoc = new XmlDocument();
reResponseDoc.Load(rsResponseStream);
XmlNodeList pfProtocolNodes = reResponseDoc.GetElementsByTagName("Protocol");
foreach (XmlNode xnNode in pfProtocolNodes)
{
XmlNodeList adChildNodes = xnNode.ChildNodes;
foreach (XmlNode xnSubChild in adChildNodes)
{
switch (xnSubChild.Name)
{
case "EwsUrl": EWSURL = xnSubChild.InnerText;
break;
}
}
}
ExchangeServiceBinding esExchangeServiceBinding = new ExchangeServiceBinding();
esExchangeServiceBinding.Credentials = ncCred;
esExchangeServiceBinding.Url = EWSURL;
esExchangeServiceBinding.CookieContainer = new CookieContainer();
DistinguishedFolderIdType[] dsFolderid = new DistinguishedFolderIdType[1];
dsFolderid[0] = new DistinguishedFolderIdType();
dsFolderid[0].Id = DistinguishedFolderIdNameType.inbox;
GetFolderType gfFolderType = new GetFolderType();
gfFolderType.FolderIds = dsFolderid;
gfFolderType.FolderShape = new FolderResponseShapeType();
gfFolderType.FolderShape.BaseShape = DefaultShapeNamesType.Default;
GetFolderResponseType gfGetFolderResponse = esExchangeServiceBinding.GetFolder(gfFolderType);
if (gfGetFolderResponse.ResponseMessages.Items[0].ResponseClass == ResponseClassType.Success) {
FolderType Folder = (FolderType)((FolderInfoResponseMessageType)gfGetFolderResponse.ResponseMessages.Items[0]).Folders[0];
Console.WriteLine(Folder.DisplayName);
}

EWS Managed API and Powershell How-To series Part 2 - Folders

2012-01-23T17:27:00.000+11:00

This is Part2 in my continuing EWS Managed API and Powershell how to series, in this post im going to look at using Mailbox Folders in Exchange Web Services. When you look at mailboxes from a structured content point of view the most obvious data structure is the folders within it. Dealing with these structures can provide a number of challenges which I'll go through.

Binding to and Accessing a Folder

To access a folder using EWS you must first know its folderId which from a useability perspective presents most people with a bit of a challenge. eg you may know the path to the folder you want to access is \Inbox\Subfolder but the FolderID itself is a large Base64 Enocded value.For all the standard folders in a mailbox such as the Calendar, Contacts, Inbox, SentItems folders there is a WellKnownFolderName enumeration that makes things easy eg so this basically provides you with a very easy way to bind to the Inbox, Calendar etc. For example to bind to the Inbox folder

$folderid= new-object Microsoft.Exchange.WebServices.Data.FolderId([Microsoft.Exchange.WebServices.Data.WellKnownFolderName]::Inbox,"user@mailbox.com")
$Inbox = [Microsoft.Exchange.WebServices.Data.Folder]::Bind($service,$folderid)

If your dealing with a folder outside of the WellKnownFolderName enumeration then you need to search and find the folder in question. There are a couple of ways you could do that one would be to use a DeepTraversal of all the folders in the Mailbox and then filter the results. The method I like to use is to split the search path and then do a Shallow traversal search of all the folders in the path eg

## Find and Bind to Folder based on Path
#Define the path to search should be seperated with \
$PathToSearch = "\Inbox\Blah"
#Bind to the MSGFolder Root
$folderid = new-object Microsoft.Exchange.WebServices.Data.FolderId([Microsoft.Exchange.WebServices.Data.WellKnownFolderName]::MsgFolderRoot,"user@domain.com")
$tfTargetFolder = [Microsoft.Exchange.WebServices.Data.Folder]::Bind($service,$folderid)
#Split the Search path into an array
$fldArray = $PathToSearch.Split("\")
#Loop through the Split Array and do a Search for each level of folder
for ($lint = 1; $lint -lt $fldArray.Length; $lint++) {
$fldArray[$lint]
#Perform search based on the displayname of each folder level
$fvFolderView = new-object Microsoft.Exchange.WebServices.Data.FolderView(1)
$SfSearchFilter = new-object Microsoft.Exchange.WebServices.Data.SearchFilter+IsEqualTo([Microsoft.Exchange.WebServices.Data.FolderSchema]::DisplayName,$fldArray[$lint])
$findFolderResults = $service.FindFolders($tfTargetFolder.Id,$SfSearchFilter,$fvFolderView)
if ($findFolderResults.TotalCount -gt 0){
foreach($folder in $findFolderResults.Folders){
$tfTargetFolder = $folder
}
}
else{
"Error Folder Not Found"
$tfTargetFolder = $null
break
}
}
$tfTargetFolder

The Tale of Two Folder Roots

If you have ever looked at a mailbox in a Mapi Editor like MFCMapi or OutlookSpy you know there are actually two different Folder Roots in a Mailbox the IPM_Subtree (represented by the "Top of the Information Store" in the below image) which is what the user sees in Outlook in their Folder Tree and the Non_IPM_Subtree which is the level above the IPM_Subtree where a lot of the Meta-Information for a mailbox gets stored (represented by the "Root Container" in the below image)

When you look at the WellKnowFolderName enum the Non_IPM_Subtree is

[Microsoft.Exchange.WebServices.Data.WellKnownFolderName]::Root

and the IPM_Subtree is

[Microsoft.Exchange.WebServices.Data.WellKnownFolderName]::MsgFolderRoot

This becomes import when you want to look at getting and modifying Mailbox configuration information also if your are trying to calculate the total mailbox size you need to make sure you include these folders in your calculation.

Properties on a Folder

When you Bind to a folder in EWS the standard folder properties provided by the Strongly typed Folder class are returned. This is good but you may find that a lot of the properties that you really want to access for example things like the FolderSize or the FolderPath aren't returned. To Access these you need to make use of the Extended properties on the Folder which allows you to access any of the underlying (Exchange/Mapi) properties of that folder object.. To use an Extended property you first need to define the particular property you want to access (as always i recommend you use a Mapi editor to work out what the Tag,Datatype of the property is you want to access a good), add that property to a PropertySet and then tell EWS to load those properties when ether you bind to the folder, search for the folder or use the Load Method.Some Extended properties that are usefull on Folders are

The PR_Folder_PathName property returns the fullpath to a folder that is delimited by the byte order mark FE-FF so if you want to return a \ delimited path you need to replace these values in the Unicode string that is returned when you retrieve this property.

The PR_MESSAGE_SIZE_EXTENDED property is a 64 Bit Integer that represents the size of the all Items in the Folder

PR_Folder_Type is a Interger property that tells you what type of folder this is which is useful if you want to tell if a folder is a SearchFolder

Enumerating all Folders in a Mailbox

One common building block of scripts is the ability to enumerate ever folder in a Mailbox which can be achieved using the FindFolders Operation in EWS with a DeepTraversal Scope. If the mailbox your enumerating has more then 1000 folders you need to take throttling into account in 2010. Here's an example that gets all the folders in a Mailbox deal with throttling and also show how to use the Extended Properties I mentioned above.

#Define Function to convert String to FolderPath
function ConvertToString($ipInputString){
$Val1Text = ""
for ($clInt=0;$clInt -lt $ipInputString.length;$clInt++){
$Val1Text = $Val1Text + [Convert]::ToString([Convert]::ToChar([Convert]::ToInt32($ipInputString.Substring($clInt,2),16)))
$clInt++
}
return $Val1Text
}
#Define Mailbox to access
$MailboxName = "glen@mymailbox.domain.com"
"Checking : " + $MailboxName
#Define Extended properties
$PR_FOLDER_TYPE = new-object Microsoft.Exchange.WebServices.Data.ExtendedPropertyDefinition(13825,[Microsoft.Exchange.WebServices.Data.MapiPropertyType]::Integer);
$folderidcnt = new-object Microsoft.Exchange.WebServices.Data.FolderId([Microsoft.Exchange.WebServices.Data.WellKnownFolderName]::MsgFolderRoot,$MailboxName)
#Define the FolderView used for Export should not be any larger then 1000 folders due to throttling
$fvFolderView = New-Object Microsoft.Exchange.WebServices.Data.FolderView(1000)
#Deep Transval will ensure all folders in the search path are returned
$fvFolderView.Traversal = [Microsoft.Exchange.WebServices.Data.FolderTraversal]::Deep;
$psPropertySet = new-object Microsoft.Exchange.WebServices.Data.PropertySet([Microsoft.Exchange.WebServices.Data.BasePropertySet]::FirstClassProperties)
$PR_MESSAGE_SIZE_EXTENDED = new-object Microsoft.Exchange.WebServices.Data.ExtendedPropertyDefinition(3592,[Microsoft.Exchange.WebServices.Data.MapiPropertyType]::Long);
$PR_DELETED_MESSAGE_SIZE_EXTENDED = new-object Microsoft.Exchange.WebServices.Data.ExtendedPropertyDefinition(26267,[Microsoft.Exchange.WebServices.Data.MapiPropertyType]::Long);
$PR_Folder_Path = new-object Microsoft.Exchange.WebServices.Data.ExtendedPropertyDefinition(26293, [Microsoft.Exchange.WebServices.Data.MapiPropertyType]::String);
#Add Properties to the Property Set
$psPropertySet.Add($PR_MESSAGE_SIZE_EXTENDED);
$psPropertySet.Add($PR_Folder_Path);
$fvFolderView.PropertySet = $psPropertySet;
#The Search filter will exclude any Search Folders
$sfSearchFilter = new-object Microsoft.Exchange.WebServices.Data.SearchFilter+IsEqualTo($PR_FOLDER_TYPE,"1")
$fiResult = $null
#The Do loop will handle any paging that is required if there are more the 1000 folders in a mailbox
do {
$fiResult = $Service.FindFolders($folderidcnt,$sfSearchFilter,$fvFolderView)
foreach($ffFolder in $fiResult.Folders){
"Processing : " + $ffFolder.displayName
$TotalItemCount = $TotalItemCount + $ffFolder.TotalCount;
$FolderSize = $null;
$FolderSizeValue = 0
#Try to Get the FolderSize Value and output it to the $FolderSize varible
if ($ffFolder.TryGetProperty($PR_MESSAGE_SIZE_EXTENDED,[ref] $FolderSize))
{
$FolderSizeValue = [Int64]$FolderSize
}
$foldpathval = $null
#Try to get the FolderPath Value and then covert it to a usable String
if ($ffFolder.TryGetProperty($PR_Folder_Path,[ref] $foldpathval))
{
$binarry = [Text.Encoding]::UTF8.GetBytes($foldpathval)
$hexArr = $binarry | ForEach-Object { $_.ToString("X2") }
$hexString = $hexArr -join ''
$hexString = $hexString.Replace("FEFF", "5C00")
$fpath = ConvertToString($hexString)
}
"FolderPath : " + $fpath
"FolderSize : " + $FolderSizeValue
}
}while($fiResult.MoreAvailable -eq $true)

Creating Folders

After all the other stuff I've just covered creating folders is actually quite simple eg to create a subfolder under the Inbox folder all you need is

#Define Mailbox to access
$MailboxName = "glen@mailbox.domain.com"
## Bind to the Inbox Sample
$folderid= new-object Microsoft.Exchange.WebServices.Data.FolderId([Microsoft.Exchange.WebServices.Data.WellKnownFolderName]::Inbox,$MailboxName)
$Inbox = [Microsoft.Exchange.WebServices.Data.Folder]::Bind($service,$folderid)
$NewFolder = new-object Microsoft.Exchange.WebServices.Data.Folder($service)
$NewFolder.DisplayName = "My New Folder123"
$NewFolder.Save($Inbox.Id)

To Check if a folder already exists before doing so you need to first do a search for the existing folder here's how you can do that

#Define Folder Name to Search for
$FolderName = "My New Folder123"
#Define Folder Veiw Really only want to return one object
$fvFolderView = new-object Microsoft.Exchange.WebServices.Data.FolderView(1)
#Define a Search folder that is going to do a search based on the DisplayName of the folder
$SfSearchFilter = new-object Microsoft.Exchange.WebServices.Data.SearchFilter+IsEqualTo([Microsoft.Exchange.WebServices.Data.FolderSchema]::DisplayName,$FolderName)
#Do the Search
$findFolderResults = $service.FindFolders($Inbox.Id,$SfSearchFilter,$fvFolderView)
if ($findFolderResults.TotalCount -eq 0){
"Folder Doesn't Exist"
}
else{
"Folder Exist"
}

Deleting a Folder

Deleting a folder is rather simple all you really need to do is call the delete Method but lets look at a more complicated sample. Given the above sample of creating a folder under the Inbox folder lets look at something that first binds to that folder which would have a path of "\Inbox\My New Folder123" and then deletes it.

## Find and Bind to Folder based on Path
#Define the path to search should be seperated with \
$PathToSearch = "\Inbox\My New Folder123"
#Bind to the MSGFolder Root
$folderid = new-object Microsoft.Exchange.WebServices.Data.FolderId([Microsoft.Exchange.WebServices.Data.WellKnownFolderName]::MsgFolderRoot,$MailboxName)
$tfTargetFolder = [Microsoft.Exchange.WebServices.Data.Folder]::Bind($service,$folderid)
#Split the Search path into an array
$fldArray = $PathToSearch.Split("\")
#Loop through the Split Array and do a Search for each level of folder
for ($lint = 1; $lint -lt $fldArray.Length; $lint++) {
$fldArray[$lint]
#Perform search based on the displayname of each folder level
$fvFolderView = new-object Microsoft.Exchange.WebServices.Data.FolderView(1)
$SfSearchFilter = new-object Microsoft.Exchange.WebServices.Data.SearchFilter+IsEqualTo([Microsoft.Exchange.WebServices.Data.FolderSchema]::DisplayName,$fldArray[$lint])
$findFolderResults = $service.FindFolders($tfTargetFolder.Id,$SfSearchFilter,$fvFolderView)
if ($findFolderResults.TotalCount -gt 0){
foreach($folder in $findFolderResults.Folders){
$tfTargetFolder = $folder
}
}
else{
"Error Folder Not Found"
$tfTargetFolder = $null
break
}
}
if($tfTargetFolder -ne $null){
#Delete the Folder using HardDelete
$tfTargetFolder.Delete([Microsoft.Exchange.WebServices.Data.DeleteMode]::HardDelete)
"Folder Deleted"
}

Emptying or Deleting old items from a folder

In Exchange 2010 you can use the Empty Method to empty all the Items from a folder (or essentially delete all the Items from a folder a once). The is pretty easy to do for example to delete all the Items in the Inbox and all subfolders you can use

$Inbox.Empty([Microsoft.Exchange.WebServices.Data.DeleteMode]::HardDelete, $true);

If your using 2007 or you want to delete Items in the Calendar folder you need to select the Items first and do a batch delete. For example to Clean all the Items in the Calendar folder

# Bind to the Calendar folder
$folderid= new-object Microsoft.Exchange.WebServices.Data.FolderId([Microsoft.Exchange.WebServices.Data.WellKnownFolderName]::Calendar,$MailboxName)
$Calendar = [Microsoft.Exchange.WebServices.Data.Folder]::Bind($service,$folderid)
#Set Itemview to 1000 to deal with throttling
$ivItemView = New-Object Microsoft.Exchange.WebServices.Data.ItemView(1000)
$fiResult = ""
do{
$fiResult = $Calendar.FindItems($ivItemView)
#Define ItemIds collection
$Itemids = [activator]::createinstance(([type]'System.Collections.Generic.List`1').makegenerictype([Microsoft.Exchange.WebServices.Data.ItemId]))
"Delete " + $fiResult.Items.Count + " Items"
foreach($Item in $fiResult.Items){
$Itemids.Add($Item.Id)
}
#Delete the Items
$Result = $service.DeleteItems($Itemids,[Microsoft.Exchange.WebServices.Data.DeleteMode]::SoftDelete,[Microsoft.Exchange.WebServices.Data.SendCancellationsMode]::SendToNone,[Microsoft.Exchange.WebServices.Data.AffectedTaskOccurrence]::AllOccurrences)
[INT]$Rcount = 0
foreach ($res in $Result){
if ($res.Result -eq [Microsoft.Exchange.WebServices.Data.ServiceResult]::Success){
$Rcount++
}
}
$Rcount.ToString() + " Items deleted successfully"
$ivItemView.offset += $fiResult.Items.Count
}while($fiResult.MoreAvailable -eq $true)

Search Folders

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 tell if a folder is a search folder the extended property PR_Folder_Type is useful if the PR_Folder_Type is set to 2 then this indicates its a search folder.

For an example of creating a search folder have a look at http://gsexdev.blogspot.com/2011/09/create-search-folder-using-ews-managed.html

For an example of finding and binding to the AllItems search folder in Exchange 2010 see

http://gsexdev.blogspot.com/2011/08/using-allitems-search-folder-from.html

To find and delete a search folder see http://tst.social.technet.microsoft.com/Forums/en-US/exchangesvrdevelopment/thread/426a37c8-f1dd-4438-a081-e2b0e378bc5a

Public Folders

When thinking about public folders its useful to consider them similar to a mailbox however unlike mailboxes you can't do a Deep Traversal of Public folders so when trying to access a public folder you need to either do a shallow traversal search for each folder level eg using a script similar to what i posted above. The other method of accessing a public folder directly is to use the Exchange Management Shell cmdlets and cover the HexEntryID you can get with the EMS to the EwsID. To connect to the Root of the Public folder store you use the following enumeration.

$folderid= new-object Microsoft.Exchange.WebServices.Data.FolderId([Microsoft.Exchange.WebServices.Data.WellKnownFolderName]::PublicFoldersRoot,"user@mailbox.com")
$PublicfolderRoot = [Microsoft.Exchange.WebServices.Data.Folder]::Bind($service,$folderid)

Other bits and pieces for folders

To Set the Homepage of folder in EWS see http://www.infinitec.de/post/2011/10/05/Setting-the-Homepage-of-an-Exchange-folder-using-the-EWS-Managed-API.aspx

That's about it for this post if you have any specific question about folders in EWS with powershell post a comment and I'll try to update this post. In the next post in this series well look into Items.

EWS Managed API and Powershell How-To series Part 1

2012-01-10T20:51:00.000+11:00

I thought I'd start the year with a series of posts that goes back over the basics of using the EWS Managed API from Powershell and provides a modular remarked example that you can easily cut and paste to build your own scripts. Along the way in this series I'll show a whole bunch of examples around specific things.

As a starting point for versions this will be Powershell Version 2.0 and the EWS Managed API 1.1 (which will soon change to 1.2 once released) http://www.microsoft.com/download/en/details.aspx?id=13480.

The starting point for any EWS script your going to write is connecting to Exchange for which there are three important pieces of information you will need. Firstly you need to know the version of Exchange your running in this script its going to be held in the following variable

$ExchangeVersion = [Microsoft.Exchange.WebServices.Data.ExchangeVersion]::Exchange2010_SP1

Other valid values for Exchange 2007 would be

$ExchangeVersion = [Microsoft.Exchange.WebServices.Data.ExchangeVersion]::Exchange2007_SP1

The next thing you need to know is what security credentials your going to use to connect to the Mailbox you want to access. There are two options available for this you can specify the credentials in your code (or prompt for them using Get-Credential). Or the other option is to use the default logged on user credentials (or from a scheduled task etc).

The last thing piece of information you need is the URL to the CAS (Client Access Server) you are going to send the EWS requests through which you can find using Autodiscover if this is setup or you can hard code the URL of a CAS server to use. One word of note with Auto-discover and the Managed API is by default it will first perform a SCP look-up of Active Directory to find the Autodiscover EndPoint and if that fails it will then perform a DNS lookup. If you want more control over this process have a look at another script I've posted http://gsexdev.blogspot.com/2011/07/using-autodiscover-in-powershell-with.html.

The last optional section in the connectivity script is an option to use EWS Impersonation this allows you to access another users mailbox with the effective security credentials of the owner of that mailbox. EWS Impersonation is configured via RBAC on 2010 see http://msdn.microsoft.com/en-us/library/bb204095%28v=exchg.140%29.aspx. For more information on impersonation see http://blogs.msdn.com/b/exchangedev/archive/2009/06/15/exchange-impersonation-vs-delegate-access.aspx

Thats about it from a connectivity and security perspective in the next post I'll go over folders inside and out. I've posted a copy of the connectivity script here the script itself looks like.

## EWS Managed API Connect Script
## Requires the EWS Managed API and Powershell V2.0 or greator
## Load Managed API dll
Add-Type -Path "C:\Program Files\Microsoft\Exchange\Web Services\1.1\Microsoft.Exchange.WebServices.dll"
## Set Exchange Version
$ExchangeVersion = [Microsoft.Exchange.WebServices.Data.ExchangeVersion]::Exchange2010_SP1
## Create Exchange Service Object
$service = New-Object Microsoft.Exchange.WebServices.Data.ExchangeService($ExchangeVersion)
## Set Credentials to use two options are availible Option1 to use explict credentials or Option 2 use the Default (logged On) credentials
#Credentials Option 1 using UPN for the windows Account
$creds = New-Object System.Net.NetworkCredential("user@domain.com","password")
$service.Credentials = $creds
#Credentials Option 2
#service.UseDefaultCredentials = $true
## Choose to ignore any SSL Warning issues caused by Self Signed Certificates
[System.Net.ServicePointManager]::ServerCertificateValidationCallback = {$true}
## Set the URL of the CAS (Client Access Server) to use two options are availbe to use Autodiscover to find the CAS URL or Hardcode the CAS to use
#CAS URL Option 1 Autodiscover
$service.AutodiscoverUrl("email@domain.com",{$true})
"Using CAS Server : " + $Service.url
#CAS URL Option 2 Hardcoded
#$uri=[system.URI] "https://casservername/ews/exchange.asmx"
#$service.Url = $uri
## Optional section for Exchange Impersonation
#$service.ImpersonatedUserId = new-object Microsoft.Exchange.WebServices.Data.ImpersonatedUserId([Microsoft.Exchange.WebServices.Data.ConnectingIdType]::SmtpAddress, "email@domain.com")

Using the new EWS password expiration operation in Exchange 2010 SP2 in Powershell

2011-12-08T21:51:00.001+11:00

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 your trying in a dev/test enviroment you can also hardcode the CASURL in

$mbMailboxFolderURI = New-Object System.Uri("https://192.168.42.132/ews/exchange.asmx")

I've put a download of this script here the script itself looks like

$MailboxName = "user@domain.com"
$cred = New-Object System.Net.NetworkCredential("user@domamin.com","password")
$dllpath = "C:\Program Files\Microsoft\Exchange\Web Services\1.1\Microsoft.Exchange.WebServices.dll"
[void][Reflection.Assembly]::LoadFile($dllpath)
$service = New-Object Microsoft.Exchange.WebServices.Data.ExchangeService([Microsoft.Exchange.WebServices.Data.ExchangeVersion]::Exchange2010_SP1)
$service.TraceEnabled = $false
$service.Credentials = $cred
$service.autodiscoverurl($MailboxName,{$true})
## Code From http://poshcode.org/624
## Create a compilation environment
$Provider=New-Object Microsoft.CSharp.CSharpCodeProvider
$Compiler=$Provider.CreateCompiler()
$Params=New-Object System.CodeDom.Compiler.CompilerParameters
$Params.GenerateExecutable=$False
$Params.GenerateInMemory=$True
$Params.IncludeDebugInformation=$False
$Params.ReferencedAssemblies.Add("System.DLL") | Out-Null
$TASource=@'
namespace Local.ToolkitExtensions.Net.CertificatePolicy{
public class TrustAll : System.Net.ICertificatePolicy {
public TrustAll() {
}
public bool CheckValidationResult(System.Net.ServicePoint sp,
System.Security.Cryptography.X509Certificates.X509Certificate cert,
System.Net.WebRequest req, int problem) {
return true;
}
}
}
'@
$TAResults=$Provider.CompileAssemblyFromSource($Params,$TASource)
$TAAssembly=$TAResults.CompiledAssembly
## We now create an instance of the TrustAll and attach it to the ServicePointManager
$TrustAll=$TAAssembly.CreateInstance("Local.ToolkitExtensions.Net.CertificatePolicy.TrustAll")
[System.Net.ServicePointManager]::CertificatePolicy=$TrustAll
## end code from http://poshcode.org/624
$expRequest = @"
<?xml version="1.0" encoding="utf-8"?><soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<soap:Header><RequestServerVersion Version="Exchange2010_SP2" xmlns="http://schemas.microsoft.com/exchange/services/2006/types" />
</soap:Header>
<soap:Body>
<GetPasswordExpirationDate xmlns="http://schemas.microsoft.com/exchange/services/2006/messages"><MailboxSmtpAddress>$MailboxName</MailboxSmtpAddress>
</GetPasswordExpirationDate></soap:Body></soap:Envelope>
"@
$mbMailboxFolderURI = New-Object System.Uri($service.url)
$wrWebRequest = [System.Net.WebRequest]::Create($mbMailboxFolderURI)
$wrWebRequest.KeepAlive = $false;
$wrWebRequest.Headers.Set("Pragma", "no-cache");
$wrWebRequest.Headers.Set("Translate", "f");
$wrWebRequest.Headers.Set("Depth", "0");
$wrWebRequest.ContentType = "text/xml";
$wrWebRequest.ContentLength = $expRequest.Length;
$wrWebRequest.Timeout = 60000;
$wrWebRequest.Method = "POST";
$wrWebRequest.Credentials = $cred
$bqByteQuery = [System.Text.Encoding]::ASCII.GetBytes($expRequest);
$wrWebRequest.ContentLength = $bqByteQuery.Length;
$rsRequestStream = $wrWebRequest.GetRequestStream();
$rsRequestStream.Write($bqByteQuery, 0, $bqByteQuery.Length);
$rsRequestStream.Close();
$wrWebResponse = $wrWebRequest.GetResponse();
$rsResponseStream = $wrWebResponse.GetResponseStream()
$sr = new-object System.IO.StreamReader($rsResponseStream);
$rdResponseDocument = New-Object System.Xml.XmlDocument
$rdResponseDocument.LoadXml($sr.ReadToEnd());
$ExpNodes = @($rdResponseDocument.getElementsByTagName("PasswordExpirationDate"))
$ExpNodes[0].'#text'

Creating an Out of Office Board using Remote Powershell, Mailtips and the EWS Managed API

2011-11-28T22:02:00.001+11:00

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 = "password"

This is the username and password to use for both the remote powershell connection and it will also be used in the EWS Connection.

$MailboxName = $UserName

This line is setting the Sender email Address for MailTips to the above username if your using UPN's that are different from your SMTP addresses then you will need to change this variable.

$rpRemotePowershell = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell -credential $adminCredential -Authentication Basic -AllowRedirection

If your using this in a OnPrem environment then you need to change the URL and auth to suit your environment currently this is setup to connect to Office365.

I've put a download of this script here the script itself looks like

$UserName = "user@domain.com"
$Password = "pasdfawrd."
$mbHash = @{ }
$MailboxName = $UserName
$batchSize = 100
$global:oaBoard = ""
$Mailboxes = @()
$cred = New-Object System.Net.NetworkCredential($UserName,$Password)
$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 -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell -credential $adminCredential -Authentication Basic -AllowRedirection
$importresults = Import-PSSession $rpRemotePowershell
}
get-mailbox -ResultSize unlimited | where-object {$_.HiddenFromAddressListsEnabled -eq $false} | foreach-object{
if ($mbHash.ContainsKey($_.WindowsEmailAddress.ToString()) -eq $false){
$mbHash.Add($_.WindowsEmailAddress.ToString(),$_.DisplayName)
}
$emailAddress = $_.WindowsEmailAddress.ToString()
$Mailboxes += $emailAddress
}
$dllpath = "C:\Program Files\Microsoft\Exchange\Web Services\1.1\Microsoft.Exchange.WebServices.dll"
[void][Reflection.Assembly]::LoadFile($dllpath)
$service = New-Object Microsoft.Exchange.WebServices.Data.ExchangeService([Microsoft.Exchange.WebServices.Data.ExchangeVersion]::Exchange2010_SP1)
$service.TraceEnabled = $false
$service.Credentials = $cred
$service.autodiscoverurl($MailboxName,{$true})
function GetMailTips{
$mbMailboxFolderURI = New-Object System.Uri($service.url)
$wrWebRequest = [System.Net.WebRequest]::Create($mbMailboxFolderURI)
$wrWebRequest.KeepAlive = $false;
$wrWebRequest.Headers.Set("Pragma", "no-cache");
$wrWebRequest.Headers.Set("Translate", "f");
$wrWebRequest.Headers.Set("Depth", "0");
$wrWebRequest.ContentType = "text/xml";
$wrWebRequest.ContentLength = $expRequest.Length;
$wrWebRequest.Timeout = 60000;
$wrWebRequest.Method = "POST";
$wrWebRequest.Credentials = $cred
$bqByteQuery = [System.Text.Encoding]::ASCII.GetBytes($expRequest);
$wrWebRequest.ContentLength = $bqByteQuery.Length;
$rsRequestStream = $wrWebRequest.GetRequestStream();
$rsRequestStream.Write($bqByteQuery, 0, $bqByteQuery.Length);
$rsRequestStream.Close();
$wrWebResponse = $wrWebRequest.GetResponse();
$rsResponseStream = $wrWebResponse.GetResponseStream()
$sr = new-object System.IO.StreamReader($rsResponseStream);
$rdResponseDocument = New-Object System.Xml.XmlDocument
$rdResponseDocument.LoadXml($sr.ReadToEnd());
$RecipientNodes = @($rdResponseDocument.getElementsByTagName("t:RecipientAddress"))
$Datanodes = @($rdResponseDocument.getElementsByTagName("t:OutOfOffice"))
for($ic=0;$ic -lt $RecipientNodes.length;$ic++){
if($Datanodes[$ic].ReplyBody.Message -eq ""){
$global:oaBoard = $global:oaBoard + "<tr>" + "`r`n"
$global:oaBoard = $global:oaBoard + "<td>" + $mbHash[$RecipientNodes[$ic].EmailAddress] + "</td>" + "`r`n"
$global:oaBoard = $global:oaBoard + "<td bgcolor=`"#41A317`">In the Office</td>" + "`r`n"
$global:oaBoard = $global:oaBoard + "<td></td>" + "`r`n"
$global:oaBoard = $global:oaBoard + "</tr>" + "`r`n"
}
else{
$global:oaBoard = $global:oaBoard + "<tr>" + "`r`n"
$global:oaBoard = $global:oaBoard + "<td>" + $mbHash[$RecipientNodes[$ic].EmailAddress] + "</td>" + "`r`n"
$global:oaBoard = $global:oaBoard + "<td bgcolor=`"#153E7E`">Out of the Office</td>" + "`r`n"
$global:oaBoard = $global:oaBoard + "<td>" + $Datanodes[$ic].ReplyBody.Message + "</td>" + "`r`n"
$global:oaBoard = $global:oaBoard + "</tr>" + "`r`n"
}
}
}
$expHeader = @"
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<soap:Header><RequestServerVersion Version="Exchange2010_SP1" xmlns="http://schemas.microsoft.com/exchange/services/2006/types" />
</soap:Header>
<soap:Body>
<GetMailTips xmlns="http://schemas.microsoft.com/exchange/services/2006/messages">
<SendingAs>
<EmailAddress xmlns="http://schemas.microsoft.com/exchange/services/2006/types">$MailboxName</EmailAddress>
</SendingAs>
<Recipients>
"@
$global:oaBoard = $global:oaBoard + "<table><tr bgcolor=`"#95aedc`">" +"`r`n"
$global:oaBoard = $global:oaBoard + "<td align=`"center`" style=`"width=200;`" ><b>User</b></td>" +"`r`n"
$global:oaBoard = $global:oaBoard + "<td align=`"center`" style=`"width=200;`" ><b>Status</b></td>" +"`r`n"
$global:oaBoard = $global:oaBoard + "<td align=`"center`" style=`"width=200;`" ><b>Message</b></td>" +"`r`n"
$global:oaBoard = $global:oaBoard + "</tr>" + "`r`n"
$expRequest = $expHeader
$bCount =0
foreach($mbMailbox in $Mailboxes){
$bCount++
$expRequest = $expRequest + "<Mailbox xmlns=`"http://schemas.microsoft.com/exchange/services/2006/types`"><EmailAddress>$mbMailbox</EmailAddress></Mailbox>"
if($bCount -eq $batchSize){
$expRequest = $expRequest + "</Recipients><MailTipsRequested>OutOfOfficeMessage</MailTipsRequested></GetMailTips></soap:Body></soap:Envelope>"
GetMailTips
$expRequest = $expHeader
$bCount = 0
}
}
if($bCount -ne 0){
$expRequest = $expRequest + "</Recipients><MailTipsRequested>OutOfOfficeMessage</MailTipsRequested></GetMailTips></soap:Body></soap:Envelope>"
GetMailTips
}
$global:oaBoard = $global:oaBoard + "</table>" + " "
$global:oaBoard | out-file "c:\oofboard.htm"

Using MailTips in EWS to get the OOF (Out of Office) Status of users with C# and Powershell

2011-11-08T17:08:00.002+11:00

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 currently in EWS.

To use the EWS Mailtips operations you need to use WSDL Proxy objects or Custom SOAP code as currently these operations aren't available for use within the EWS Managed API. If you want to script it I would still combine it with EWS Managed API code because of ease of access to things like Autodiscover this gives you.

I've created a powershell and C# sample of using the GetMailtips operation the C# looks like

ExchangeServiceBinding esb = new ExchangeServiceBinding();
esb.Credentials = new NetworkCredential("user@domain.com", "password", "");
esb.Url = "https://ch1prd0302.outlook.com/EWS/Exchange.asmx";
esb.RequestServerVersionValue = new RequestServerVersion();
esb.RequestServerVersionValue.Version = ExchangeVersionType.Exchange2010_SP1;
GetMessageTrackingReportRequestType gmt = new GetMessageTrackingReportRequestType();
GetMailTipsType gmType = new GetMailTipsType();
gmType.MailTipsRequested = new MailTipTypes();
gmType.MailTipsRequested = MailTipTypes.OutOfOfficeMessage;
gmType.Recipients = new EmailAddressType[1];
EmailAddressType rcip = new EmailAddressType();
rcip.EmailAddress = "user@domain.com";
gmType.Recipients[0] = rcip;
EmailAddressType sendAs = new EmailAddressType();
sendAs.EmailAddress = "sender@domain.com";
gmType.SendingAs = sendAs;
GetMailTipsResponseMessageType gmResponse = esb.GetMailTips(gmType);
if (gmResponse.ResponseClass == ResponseClassType.Success) {
if (gmResponse.ResponseMessages[0].MailTips.OutOfOffice.ReplyBody.Message != "")
{
//User Out
Console.WriteLine(gmResponse.ResponseMessages[0].MailTips.OutOfOffice.ReplyBody.Message);
}
else {
//user In
}
}

With the Powershell example the following information needs to be configured

$MailboxName = "sender@domain.com"

Mailbox which will do the check from

$Mailboxes = @("user1@domain.com","user2@domain.com")

Mailbox you want to check the OOF of (this is just an array or Strings)

$cred = New-Object System.Net.NetworkCredential("user1@domain.com","password@#")

Credentials to use

I've put a download of the script here the code itself looks like

$MailboxName = "sender@domain.com"
$Mailboxes = @("user1@domain.com","user2@domain.com")
$cred = New-Object System.Net.NetworkCredential("user1@domain.com","password@#")
$dllpath = "C:\Program Files\Microsoft\Exchange\Web Services\1.1\Microsoft.Exchange.WebServices.dll"
[void][Reflection.Assembly]::LoadFile($dllpath)
$service = New-Object Microsoft.Exchange.WebServices.Data.ExchangeService([Microsoft.Exchange.WebServices.Data.ExchangeVersion]::Exchange2010_SP1)
$service.TraceEnabled = $false
$service.Credentials = $cred
$service.autodiscoverurl($MailboxName,{$true})
$expRequest = @"
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<soap:Header><RequestServerVersion Version="Exchange2010_SP1" xmlns="http://schemas.microsoft.com/exchange/services/2006/types" />
</soap:Header>
<soap:Body>
<GetMailTips xmlns="http://schemas.microsoft.com/exchange/services/2006/messages">
<SendingAs>
<EmailAddress xmlns="http://schemas.microsoft.com/exchange/services/2006/types">$MailboxName</EmailAddress>
</SendingAs>
<Recipients>
"@
foreach($mbMailbox in $Mailboxes){
$expRequest = $expRequest + "<Mailbox xmlns=`"http://schemas.microsoft.com/exchange/services/2006/types`"><EmailAddress>$mbMailbox</EmailAddress></Mailbox>"
}
$expRequest = $expRequest + "</Recipients><MailTipsRequested>OutOfOfficeMessage</MailTipsRequested></GetMailTips></soap:Body></soap:Envelope>"
$mbMailboxFolderURI = New-Object System.Uri($service.url)
$wrWebRequest = [System.Net.WebRequest]::Create($mbMailboxFolderURI)
$wrWebRequest.KeepAlive = $false;
$wrWebRequest.Headers.Set("Pragma", "no-cache");
$wrWebRequest.Headers.Set("Translate", "f");
$wrWebRequest.Headers.Set("Depth", "0");
$wrWebRequest.ContentType = "text/xml";
$wrWebRequest.ContentLength = $expRequest.Length;
$wrWebRequest.Timeout = 60000;
$wrWebRequest.Method = "POST";
$wrWebRequest.Credentials = $cred
$bqByteQuery = [System.Text.Encoding]::ASCII.GetBytes($expRequest);
$wrWebRequest.ContentLength = $bqByteQuery.Length;
$rsRequestStream = $wrWebRequest.GetRequestStream();
$rsRequestStream.Write($bqByteQuery, 0, $bqByteQuery.Length);
$rsRequestStream.Close();
$wrWebResponse = $wrWebRequest.GetResponse();
$rsResponseStream = $wrWebResponse.GetResponseStream()
$sr = new-object System.IO.StreamReader($rsResponseStream);
$rdResponseDocument = New-Object System.Xml.XmlDocument
$rdResponseDocument.LoadXml($sr.ReadToEnd());
$RecipientNodes = @($rdResponseDocument.getElementsByTagName("t:RecipientAddress"))
$Datanodes = @($rdResponseDocument.getElementsByTagName("t:OutOfOffice"))
for($ic=0;$ic -lt $RecipientNodes.length;$ic++){
if($Datanodes[$ic].ReplyBody.Message -eq ""){
$RecipientNodes[$ic].EmailAddress + " : In the Office"
}
else{
$RecipientNodes[$ic].EmailAddress + " : Out of Office"
}
}

Changing Folder and Calendar Permissions in Exchange using the EWS Managed API and powershell

2011-10-22T11:26:00.000+11:00

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 object in the Managed API has a Add and Remove methods and you have the ability to modify am ACE within the permissions collection. The one problem you can have is if the Folder permissions is currently set to custom and you try to use one the default FolderPermissionLevel. You will also have problem if you don't check the current collection and try to add a duplicate ACE into the collection.

A simple way to solve this is to first search the current collection for any existing ACE entries and remove the existing ACE then add the new rights you want set using the Add method. The other issue you need to deal with when setting the calendar folder permission is to also make sure you set the corresponding rights on the FreeBusy Data folder or you may have problems such as explained in http://support.microsoft.com/kb/184151

I've put together two examples both of these use EWS Impersonation which you can configure in 2010 via RBAC http://msdn.microsoft.com/en-us/library/bb204095%28v=EXCHG.140%29.aspx

There are 3 varibles in the script you need to modify

$MailboxName = "user@domain.com"

This is the mailbox you want to make the changes and what will be impersonated

$Permission = [Microsoft.Exchange.WebServices.Data.FolderPermissionLevel]::Editor

This is the rights you want to set

$credentials = New-Object System.Net.NetworkCredential("user@domain.com,"password")

These are the user credentials to use this user must have impersonation rights

I've posted both examples up here

In the first example this shows how to set the Default permissions for the default user on the Calendar to Editor

The second Example shows how to set calendar permission for a particular user to Editor this example looks like

$MailboxName = "mailbox@domain.com"

$credentials = New-Object System.Net.NetworkCredential("user@domain.com","Password#")
$NewACLUser = "newacl@domain.com"
$dllpath = "C:\Program Files\Microsoft\Exchange\Web Services\1.1\Microsoft.Exchange.WebServices.dll"
[void][Reflection.Assembly]::LoadFile($dllpath)
$Permission = [Microsoft.Exchange.WebServices.Data.FolderPermissionLevel]::Editor
$service = New-Object Microsoft.Exchange.WebServices.Data.ExchangeService([Microsoft.Exchange.WebServices.Data.ExchangeVersion]::Exchange2010)
$service.Credentials = $credentials
$service.AutodiscoverUrl($MailboxName,{$true})
$service.ImpersonatedUserId = new-object Microsoft.Exchange.WebServices.Data.ImpersonatedUserId([Microsoft.Exchange.WebServices.Data.ConnectingIdType]::SmtpAddress, $MailboxName);
function addFolderPerm($folder){
$existingperm = $null
foreach($fperm in $folder.Permissions){
if($fperm.UserId.StandardUser -eq $null){
if ($fperm.UserId.PrimarySmtpAddress.ToLower() -eq $NewACLUser.ToLower()){
$existingperm = $fperm
}
}
}
if($existingperm -ne $null){
$folder.Permissions.Remove($existingperm)
}
$newfp = new-object Microsoft.Exchange.WebServices.Data.FolderPermission($NewACLUser,$Permission)
$folder.Permissions.Add($newfp)
$folder.Update()
}
"Checking : " + $MailboxName
$folderidcnt = new-object Microsoft.Exchange.WebServices.Data.FolderId([Microsoft.Exchange.WebServices.Data.WellKnownFolderName]::Calendar,$MailboxName)
$Calendar = [Microsoft.Exchange.WebServices.Data.Folder]::Bind($service,$folderidcnt)
"Set Calendar Rights"
addFolderPerm($Calendar)
$sf1 = new-object Microsoft.Exchange.WebServices.Data.SearchFilter+IsEqualTo([Microsoft.Exchange.WebServices.Data.FolderSchema]::DisplayName,"Freebusy Data")
$fvFolderView = New-Object Microsoft.Exchange.WebServices.Data.FolderView(1000)
$fvFolderView.Traversal = [Microsoft.Exchange.WebServices.Data.FolderTraversal]::Shallow;
$folderidRoot = new-object Microsoft.Exchange.WebServices.Data.FolderId([Microsoft.Exchange.WebServices.Data.WellKnownFolderName]::Root,$MailboxName)
$fiResult = $Service.FindFolders($folderidRoot,$sf1,$fvFolderView)
if($fiResult.Folders.Count -eq 1){
"Set FreeBusy Rights"
$Freebusyfld = $fiResult.Folders[0]
$Freebusyfld.Load()
addFolderPerm($Freebusyfld)
}

Using EWS Streaming notifications in Powershell to trigger a script when new mail arrives in Exchange 2010 SP1

2011-09-30T17:34:00.000+10:00

EWS Streaming notifications where a great addition to Exchange 2010 SP1 that went some way to filling that large emotional gap that all Exchange developers felt with the demise of Store Event sinks in Exchange 2010. There is some good information and samples of using Streaming notifications in .NET which are a good read at http://msdn.microsoft.com/en-us/library/hh312849%28v=exchg.140%29.aspx and http://blogs.msdn.com/b/exchangedev/archive/2010/12/22/working-with-streaming-notifications-by-using-the-ews-managed-api.aspx

Notifications in EWS are the method you can use to get real-time notifications of email arriving or a calendar appointments being created. To distill what happens with streaming notification in a few lines is that when you create a subscription request for a particular Exchange mailbox folder with a CAS server that connection remains open for a maximum time of 30 minutes (this bit is important). During the next 30 minutes if something happens in the folder your subscribed to the server can use the connection your app has opened to notify you that something has happened. If you understand how ActiveSync works the process is very similar using a hanging http request. After 30 minutes you then need to re-establish the connection which re-establishes the notifications channel to your application. (this 30 minute period can be changed but 30 is the MAX)

To use this within Powershell requires using some of the event features added in version 2.0 in particular the Register-ObjectEvent cmdlet. The cmldet allows you to subscribe to the events that are generated by a Microsoft .NET Framework object the object in question in this context is the StreamingSubscriptionConnection. This object has a few events the main one that fires when a NewMail arrives or an Item is created is the "OnNotificationEvent". The other import event is the "OnDisconnect" event which will fire when the subscription period ends or something else happens on the CAS side. The third event is the OnSubscriptionError which you need to work with for error checking and reliability.

The following script uses Register-ObjectEvent to create a subscription that will start a process that will log the Subject of the Message that caused the notification to fire. What you receive from the server when a notification is fired is the ItemId of the object that fired it. To get more information about what caused the notification you need to bind to this Item Id. To achieve this the ExchangeService object is passed in via the MessageData and a normal EWS bind is done.

The OnDisconnect Event is also registered so when this event fires the StreamingSubscriptionConnection open method is called which re-establishes the registration for another 30 minutes.

Reliability as this is pretty simple example it just listens to one folder in a mailbox (you can change the subscription type to listen to all folder in a mailbox) and only works withing a currently opened powershell session. To create a reliable process that could be relied on in a business context requires that you put some form of maintenance routine around the Notification subscription which in fully blown .NET is a lot easier to handle so using powershell and notifications outside of prototyping isn't something I'd recommend. The other things to consider when using EWS notification is the default throttling limits in 2010 SP1. For EWS Subscriptions the maximum number subscription you can have by default is 20 Subs per account so if your looking a subscribing to say a large number of calendar folders your going to have problems with throttling once you go past 20 users (remembering throttling is enabled by default) this is particular acute if your trying to use ExchangeOnline where you can't change since (ouch).

I've put a download of this script here the code itself looks like

$MailboxName = "user@domain.com"
$dllpath = "C:\Program Files\Microsoft\Exchange\Web Services\1.1\Microsoft.Exchange.WebServices.dll"
[void][Reflection.Assembly]::LoadFile($dllpath)
$service = New-Object Microsoft.Exchange.WebServices.Data.ExchangeService([Microsoft.Exchange.WebServices.Data.ExchangeVersion]::Exchange2010_SP1)
$service.TraceEnabled = $false
$service.Credentials = New-Object System.Net.NetworkCredential("user@domain.com","password")
$service.AutodiscoverUrl($MailboxName ,{$true})
$fldArray = new-object Microsoft.Exchange.WebServices.Data.FolderId[] 1
$Inboxid = new-object Microsoft.Exchange.WebServices.Data.FolderId([Microsoft.Exchange.WebServices.Data.WellKnownFolderName]::Inbox,$MailboxName)
$fldArray[0] = $Inboxid
$stmsubscription = $service.SubscribeToStreamingNotifications($fldArray, [Microsoft.Exchange.WebServices.Data.EventType]::NewMail)
$stmConnection = new-object Microsoft.Exchange.WebServices.Data.StreamingSubscriptionConnection($service, 30);
$stmConnection.AddSubscription($stmsubscription)
Register-ObjectEvent -inputObject $stmConnection -eventName "OnNotificationEvent" -Action {
foreach($notEvent in $event.SourceEventArgs.Events){
[String]$itmId = $notEvent.ItemId.UniqueId.ToString()
$message = [Microsoft.Exchange.WebServices.Data.EmailMessage]::Bind($event.MessageData,$itmId)
"Subject : " + $message.Subject + " " + (Get-Date) | Out-File c:\log2.txt -Append
}
} -MessageData $service
Register-ObjectEvent -inputObject $stmConnection -eventName "OnDisconnect" -Action {$event.MessageData.Open()} -MessageData $stmConnection
$stmConnection.Open()

Getting Size and Item details for single folders in Exchange 2003 via Powershell

2011-09-16T21:16:00.000+10:00

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

$snServerName = $args[0]

$Global:rptCollection = @()

function QueryMailbox($mb){
$mb
$rdoSession = new-object -com Redemption.RDOSession
$rdoSession.LogonExchangeMailbox($SmtpAddress,$snServerName)
$calendar = $rdoSession.Stores.DefaultStore.GetDefaultFolder(9)

$Itmcnt = "" | select DisplayName,SMTPAddress,ItemCount,Size
$Itmcnt.DisplayName = $displayName
$Itmcnt.SMTPAddress = $SmtpAddress
$Itmcnt.ItemCount = $calendar.Items.Count
$Itmcnt.Size = [System.Math]::Round(($calendar.Fields(235405315) /1024),2)
$Global:rptCollection += $Itmcnt
$Itmcnt
$rdoSession.logoff()
}

function GetUsers(){
$root = [ADSI]'LDAP://RootDSE'
$cfConfigRootpath = "LDAP://" + $root.ConfigurationNamingContext.tostring()
$dfDefaultRootPath = "LDAP://" + $root.DefaultNamingContext.tostring()
$configRoot = [ADSI]$cfConfigRootpath
$dfRoot = [ADSI]$dfDefaultRootPath
$searcher = new-object System.DirectoryServices.DirectorySearcher($configRoot)
$searcher.Filter = '(&(objectCategory=msExchExchangeServer)(cn=' + $snServerName + '))'
$searcher.PropertiesToLoad.Add("cn")
$searcher.PropertiesToLoad.Add("gatewayProxy")
$searcher.PropertiesToLoad.Add("legacyExchangeDN")
$searcher1 = $searcher.FindAll()
foreach ($server in $searcher1){
    $snServerEntry = New-Object System.DirectoryServices.directoryentry
        $snServerEntry = $server.GetDirectoryEntry()
    $snServerName = $snServerEntry.cn
    $snExchangeDN = $snServerEntry.legacyExchangeDN
}
$searcher.Filter = '(&(objectCategory=msExchRecipientPolicy)(cn=Default Policy))'
$searcher1 = $searcher.FindAll()
foreach ($recppolicies in $searcher1){
         $gwaddrrs = New-Object System.DirectoryServices.directoryentry
        $gwaddrrs = $recppolicies.GetDirectoryEntry()
    foreach ($address in $gwaddrrs.gatewayProxy){
        if($address.Substring(0,5) -ceq "SMTP:"){$dfAddress = $address.Replace("SMTP:@","")}
    }

}
$arMbRoot = "https://" + $snServerName + "/exadmin/admin/" + $dfAddress + "/mbx/"
$gfGALQueryFilter = "(&(&(&(& (mailnickname=*)(!msExchHideFromAddressLists=TRUE)(| (&(objectCategory=person)" `
+ "(objectClass=user)(msExchHomeServerName=" + $snExchangeDN + ")) )))))"
$dfsearcher = new-object System.DirectoryServices.DirectorySearcher($dfRoot)
$dfsearcher.Filter = $gfGALQueryFilter
$searcher2 = $dfsearcher.FindAll()
foreach ($uaUsers in $searcher2){
         $uaUserAccount = New-Object System.DirectoryServices.directoryentry
        $uaUserAccount = $uaUsers.GetDirectoryEntry()
    foreach ($address in $uaUserAccount.proxyaddresses){
        if($address.Substring(0,5) -ceq "SMTP:"){$uaAddress = $address.Replace("SMTP:","")}
    }
    $SmtpAddress = $uaAddress
    $displayName = $uaUserAccount.DisplayName[0]
    QueryMailbox($uaAddress)
}
}

GetUsers
$Global:rptCollection | Export-Csv -NoTypeInformation c:\mailbox.csv

Create Search Folders using the EWS Managed API in a Mailbox or Archive Store using Powershell

2011-09-07T22:21:00.000+10:00

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 folder in the Non_IPM_Subtree.

Eg the following will create a Search folder to find Items greater than 5 MB in a Mailbox

$MailboxName = "user@domain.com"

$dllpath = "C:\Program Files\Microsoft\Exchange\Web Services\1.1\Microsoft.Exchange.WebServices.dll"
[void][Reflection.Assembly]::LoadFile($dllpath)
$service = New-Object Microsoft.Exchange.WebServices.Data.ExchangeService([Microsoft.Exchange.WebServices.Data.ExchangeVersion]::Exchange2010_SP1)
$service.TraceEnabled = $false

$service.Credentials = New-Object System.Net.NetworkCredential("user@domain.com","password")
$service.AutodiscoverUrl($MailboxName ,{$true})

$svFldid = new-object Microsoft.Exchange.WebServices.Data.FolderId([Microsoft.Exchange.WebServices.Data.WellKnownFolderName]::SearchFolders,$MailboxName)
$SearchFilter = new-object Microsoft.Exchange.WebServices.Data.SearchFilter+IsGreaterThan([Microsoft.Exchange.WebServices.Data.ItemSchema]::Size, (5*1024*1024));
$SearchFolder = new-object Microsoft.Exchange.WebServices.Data.SearchFolder($service);
$searchFolder.SearchParameters.RootFolderIds.Add([Microsoft.Exchange.WebServices.Data.WellKnownFolderName]::MsgFolderRoot);
$searchFolder.SearchParameters.Traversal = [Microsoft.Exchange.WebServices.Data.SearchFolderTraversal]::Deep;
$searchFolder.SearchParameters.SearchFilter = $SearchFilter
$searchFolder.DisplayName = "Bigger then 5 MB";
$searchFolder.Save($svFldid);

If you want to create a Search folder in the Archive Store there's no enumeration for the SearchFolders root folder in the Archive Store so you first need to find the Finder folder in the Archive Store then you can use this when you create the Search Folder for example the following will create a Search folder to find Items greater than 5 MB in the Archive Store.

$MailboxName = "user@domain.com"

$dllpath = "C:\Program Files\Microsoft\Exchange\Web Services\1.1\Microsoft.Exchange.WebServices.dll"
[void][Reflection.Assembly]::LoadFile($dllpath)
$service = New-Object Microsoft.Exchange.WebServices.Data.ExchangeService([Microsoft.Exchange.WebServices.Data.ExchangeVersion]::Exchange2010_SP1)
$service.TraceEnabled = $false

$service.Credentials = New-Object System.Net.NetworkCredential("user@domain.com","password")
$service.AutodiscoverUrl($MailboxName ,{$true})

$FolderView = New-Object Microsoft.Exchange.WebServices.Data.FolderView(1);
$fsf = New-Object Microsoft.Exchange.WebServices.Data.SearchFilter+IsEqualTo([Microsoft.Exchange.WebServices.Data.FolderSchema]::DisplayName, "Finder");
$ffResult = $service.FindFolders([Microsoft.Exchange.WebServices.Data.WellKnownFolderName]::ArchiveRoot,$fsf, $FolderView)

$SearchFilter = new-object Microsoft.Exchange.WebServices.Data.SearchFilter+IsGreaterThan([Microsoft.Exchange.WebServices.Data.ItemSchema]::Size, (5*1024*1024));
$SearchFolder = new-object Microsoft.Exchange.WebServices.Data.SearchFolder($service);
$searchFolder.SearchParameters.RootFolderIds.Add([Microsoft.Exchange.WebServices.Data.WellKnownFolderName]::ArchiveMsgFolderRoot);
$searchFolder.SearchParameters.Traversal = [Microsoft.Exchange.WebServices.Data.SearchFolderTraversal]::Deep;
$searchFolder.SearchParameters.SearchFilter = $SearchFilter
$searchFolder.DisplayName = "Bigger then 5 MB";
$searchFolder.Save($ffResult.folders[0].Id);

Reading Extended Rights on an Exchange database using ADSI and C#

2011-08-31T13:26:00.004+10:00

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-rights," + rootdse.Properties["configurationnamingcontext"].Value);
Hashtable exRighthash = new Hashtable();
foreach (DirectoryEntry chent in exRights.Children) {
if( exRighthash.ContainsKey(chent.Properties["rightsGuid"].Value) == false){
exRighthash.Add(chent.Properties["rightsGuid"].Value,chent.Properties["DisplayName"].Value);}
}

DirectorySearcher cfgsearch = new DirectorySearcher(cfg);
cfgsearch.Filter = "(objectCategory=msExchPrivateMDB)";
cfgsearch.PropertiesToLoad.Add("distinguishedName");
cfgsearch.SearchScope = SearchScope.Subtree;
SearchResultCollection res = cfgsearch.FindAll();
foreach (SearchResult se in res)
{
DirectoryEntry ssStoreObj = se.GetDirectoryEntry();
ActiveDirectorySecurity StoreobjSec = ssStoreObj.ObjectSecurity;
AuthorizationRuleCollection Storeacls = StoreobjSec.GetAccessRules(true, true, typeof(System.Security.Principal.SecurityIdentifier));
foreach (ActiveDirectoryAccessRule ace in Storeacls)
{
if (ace.IdentityReference.Value != "S-1-5-7" & ace.IdentityReference.Value != "S-1-1-0" & ace.IsInherited != true)
{
DirectoryEntry sidUser = new DirectoryEntry("LDAP://");
Console.WriteLine(sidUser.Properties["DisplayName"].Value.ToString());
Console.WriteLine(exRighthash[ace.ObjectType.ToString()].ToString());
}

}
}

}
}
}

Using the AllItems Search folder from Outlook 2010 on Exchange 2010 with Powershell and the EWS Managed API

2011-08-05T21:31:00.007+10:00

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 you know the folder is a search folder

$PR_FOLDER_TYPE = new-object Microsoft.Exchange.WebServices.Data.ExtendedPropertyDefinition(13825,[Microsoft.Exchange.WebServices.Data.MapiPropertyType]::Integer);

The following sample script shows how to return items that where received in January 2011 in all folders within a mailbox using the AllItems search folder with an AQS query. I've put a download of the code here the script itself looks like

$AqsString = "System.Message.DateReceived:01/01/2011..01/31/2011"
$MailboxName = "domain.com"

$dllpath = "C:\Program Files\Microsoft\Exchange\Web Services\1.1\Microsoft.Exchange.WebServices.dll"
[void][Reflection.Assembly]::LoadFile($dllpath)
$service = New-Object Microsoft.Exchange.WebServices.Data.ExchangeService([Microsoft.Exchange.WebServices.Data.ExchangeVersion]::Exchange2010_SP1)
$service.Credentials = New-Object System.Net.NetworkCredential("user@domain.com","passwod")

$service.AutodiscoverUrl($MailboxName,{$true})
$PR_FOLDER_TYPE = new-object Microsoft.Exchange.WebServices.Data.ExtendedPropertyDefinition(13825,[Microsoft.Exchange.WebServices.Data.MapiPropertyType]::Integer);

"Checking : " + $MailboxName
$folderidcnt = new-object Microsoft.Exchange.WebServices.Data.FolderId([Microsoft.Exchange.WebServices.Data.WellKnownFolderName]::Root,$MailboxName)
$fvFolderView = New-Object Microsoft.Exchange.WebServices.Data.FolderView(1000)
$fvFolderView.Traversal = [Microsoft.Exchange.WebServices.Data.FolderTraversal]::Shallow;
$sf1 = new-object Microsoft.Exchange.WebServices.Data.SearchFilter+IsEqualTo($PR_FOLDER_TYPE,"2")
$sf2 = new-object Microsoft.Exchange.WebServices.Data.SearchFilter+IsEqualTo([Microsoft.Exchange.WebServices.Data.FolderSchema]::DisplayName,"allitems")
$sfSearchFilterCol = new-object Microsoft.Exchange.WebServices.Data.SearchFilter+SearchFilterCollection([Microsoft.Exchange.WebServices.Data.LogicalOperator]::And)
$sfSearchFilterCol.Add($sf1)
$sfSearchFilterCol.Add($sf2)
$fiResult = $Service.FindFolders($folderidcnt,$sfSearchFilterCol,$fvFolderView)
$fiItems = $nulll
$ItemView = New-Object Microsoft.Exchange.WebServices.Data.ItemView(1000)
if($fiResult.Folders.Count -gt 0){
$fiResult.Folders[0].DisplayName
do{
$fiItems = $fiResult.Folders[0].findItems($AqsString,$ItemView)
$ItemView.offset += $fiItems .Items.Count
foreach($Item in $fiItems.Items){
$Item.Subject
}
}while($fiItems .MoreAvailable -eq $true)
}

Using Autodiscover in powershell with the EWS Managed API and Exchange 2010 and hosted Orgs

2011-07-20T21:40:00.006+10:00

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($dllpath)
$adAutoDiscoverService = New-Object Microsoft.Exchange.WebServices.Autodiscover.AutodiscoverService([Microsoft.Exchange.WebServices.Data.ExchangeVersion]::Exchange2010);
$uri=[system.URI] "https://autodiscover-s.outlook.com/autodiscover/autodiscover.svc"
$adAutoDiscoverService.Url = $uri
$adAutoDiscoverService.Credentials = New-Object System.Net.NetworkCredential("username","password")
$adAutoDiscoverService.EnableScpLookup = $false;
$adAutoDiscoverService.RedirectionUrlValidationCallback = {$true};
$adAutoDiscoverService.PreAuthenticate = $true;
$UserSettings = new-object Microsoft.Exchange.WebServices.Autodiscover.UserSettingName[] 1
$UserSettings[0] = [Microsoft.Exchange.WebServices.Autodiscover.UserSettingName]::ExternalEwsUrl
$adResponse = $adAutoDiscoverService.GetUserSettings($mailbox , $UserSettings);
$adResponse.Settings[[Microsoft.Exchange.WebServices.Autodiscover.UserSettingName]::ExternalEwsUrl]

A few things to note about this script is first the hardcoded URL to autodiscover this means no autodiscover DNS records are needed for the email your looking up.

$uri=[system.URI] "https://autodiscover-s.outlook.com/autodiscover/autodiscover.svc"
$adAutoDiscoverService.Url = $uri

But as I've said the Autodiscover service isn't just not limited to retrieving URL's have a look at the usersettingname enumeration http://msdn.microsoft.com/en-us/library/microsoft.exchange.webservices.autodiscover.usersettingname%28v=exchg.80%29.aspx . With this you can do things such as use Alternate mailboxes to see if an online archive is configured.

$UserSettings[0] = [Microsoft.Exchange.WebServices.Autodiscover.UserSettingName]::AlternateMailboxes
$adResponse = $adAutoDiscoverService.GetUserSettings($mailbox , $UserSettings);
$adResponse.Settings[[Microsoft.Exchange.WebServices.Autodiscover.UserSettingName]::AlternateMailboxes]

$adAutoDiscoverService.EnableScpLookup = $false;

Which means that the Managed API won't try an Active Directory look up of SCP records for autodiscover which can be very useful to speed up on the discovery process and help during migrations or other AD config issues.

Running Exchange Online and Office365 Powershell cmdlets in C# and managed code

2011-07-10T20:45:00.004+10:00

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 against the endpoint https://ps.outlook.com. With the Office365 MSOnline module you need to load this into a runspace and then firstly use the Connect-MsolService cmdlet to connect to and authenticate against Office365. Then you execute as per normal the desired cmdlets.

Here's some sample code the first sample uses remote powershell to connect to ExchangeOnline.

System.Security.SecureString secureString = new System.Security.SecureString();
string myPassword = "password";
foreach (char c in myPassword)
secureString.AppendChar(c);
PSCredential credential = new PSCredential("glen@domain.com", secureString);
WSManConnectionInfo connectionInfo = new WSManConnectionInfo(new Uri("https://ps.outlook.com/PowerShell-LiveID?PSVersion=2.0"), "http://schemas.microsoft.com/powershell/Microsoft.Exchange", credential);
connectionInfo.AuthenticationMechanism = AuthenticationMechanism.Basic;
connectionInfo.SkipCACheck = true;
connectionInfo.SkipCNCheck = true;

connectionInfo.MaximumConnectionRedirectionCount = 4;
Runspace runspace = System.Management.Automation.Runspaces.RunspaceFactory.CreateRunspace(connectionInfo);
runspace.Open();
// Make a Get-Mailbox requst using the Server Argument
Command gmGetMailbox = new Command("get-mailbox");
gmGetMailbox.Parameters.Add("ResultSize", "Unlimited");
Pipeline plPileLine = runspace.CreatePipeline();
plPileLine.Commands.Add(gmGetMailbox);
Collection RsResultsresults = plPileLine.Invoke();
Dictionary gmResults = new Dictionary();
foreach (PSObject obj in RsResultsresults)
{
gmResults.Add(obj.Members["WindowsEmailAddress"].Value.ToString(), obj);
}
plPileLine.Stop();
plPileLine.Dispose();

This second example loads the MSOnline powershell module into a runspace

InitialSessionState iss = InitialSessionState.CreateDefault();
iss.ImportPSModule(new[] { "MSOnline" });
using (Runspace psRunSpace = RunspaceFactory.CreateRunspace(iss))
{
psRunSpace.Open();
using (System.Management.Automation.PowerShell powershell = System.Management.Automation.PowerShell.Create())
{
powershell.Runspace = psRunSpace;
Command connect = new Command("Connect-MsolService");
System.Security.SecureString secureString = new System.Security.SecureString();
string myPassword = "password";
foreach (char c in myPassword)
secureString.AppendChar(c);

connect.Parameters.Add("Credential", new PSCredential("glen@domain.com", secureString));
powershell.Commands.AddCommand(connect);
Collection results = null;
Collection errors = null;
results = powershell.Invoke();
errors = powershell.Streams.Error.ReadAll();
powershell.Commands.Clear();
Command getuser = new Command("Get-MsolUser");
getuser.Parameters.Add("MaxResults", 100);
powershell.Commands.AddCommand(getuser);
results = null;
errors = null;
results = powershell.Invoke();
}
}
}

Processing BCC's in Exchange Transport Agents

2011-06-29T21:26:00.003+10:00

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 Transport Agent is that most API’s include the ability to set and get BCC address’s but they will always appear blank when you attempt to read them for example when a message is passing through the transport pipeline. The simple explanation for this is if you have understood about P1 and P2 recipients is that BCC’s when a message is submitted become P1 recipients of the message for the first MTA to process but they are never added to the P2 envelope. From the MTA’s perspective because delivery of TO, CC or BCC are treated exactly the same these elements are merely display information and the MTA just treats these recipients as another RCPT TO entry. To detect BCC in a Transport Agent you can do two things the first is reconcile the P1 Recipients against the P2 Recipients if you find a P1 recipient that doesn’t have a matching P2 entry then you can assume that this is either a BCC or potentially an alternate or journal recipient. The other way is to look at the Microsoft.Exchange.Transport.RecipientP2Type http://msdn.microsoft.com/en-us/library/aa579279%28EXCHG.140%29.aspx EnvelopeRecipient.Properties Property this returns an Integer that tells you what type of recipient each P1 envelope entry is.

For example

foreach (EnvelopeRecipient envelopeRecp in QueuedMessage.MailItem.Recipients) {
object RecpType = null;
if (envelopeRecp.Properties.TryGetValue("Microsoft.Exchange.Transport.RecipientP2Type",out RecpType))
{
switch((Int32)RecpType){
case 1 : // Process To
break;
case 2 : // Process CC
break;
case 3 : // Process BCC
break;
}
}
}

Sending a message with a classification in EWS in C# and Powershell

2011-05-14T10:51:00.007+10:00

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 properties that relate to classification are documented in http://msdn.microsoft.com/en-us/library/ee217686%28v=EXCHG.80%29.aspx. At the most basic level if you want to set a classification on a message your sending you need to set the following two properties on that message.

PidLidClassificationGuid which you set to the GUID of the classification you want applied to the message

PidLidClassified which is a Boolean that tells the Exchange this message is classified.

With the EWS Managed API in C# this look like

EmailMessage emEmailMessage = new EmailMessage(service);
emEmailMessage.ToRecipients.Add("user@domaim.com");
emEmailMessage.Subject = "test Classify";
emEmailMessage.Body = new MessageBody("test");
ExtendedPropertyDefinition PidLidClassificationGuid = new ExtendedPropertyDefinition(DefaultExtendedPropertySet.Common, 34232, MapiPropertyType.String);
emEmailMessage.SetExtendedProperty(PidLidClassificationGuid, "e67e794b-f6d1-4c8f-9f63-1118d21dafa6");
ExtendedPropertyDefinition PidLidClassified = new ExtendedPropertyDefinition(DefaultExtendedPropertySet.Common,34229, MapiPropertyType.Boolean);
emEmailMessage.SetExtendedProperty(PidLidClassified, true);
emEmailMessage.SendAndSaveCopy();

In Powershell it looks like

$MailboxName = "user@domain.com"
$dllpath = "C:\Program Files\Microsoft\Exchange\Web Services\1.1\Microsoft.Exchange.WebServices.dll"
[void][Reflection.Assembly]::LoadFile($dllpath)
$service = New-Object Microsoft.Exchange.WebServices.Data.ExchangeService([Microsoft.Exchange.WebServices.Data.ExchangeVersion]::Exchange2010)
#$service.Credentials = New-Object System.Net.NetworkCredential("glen@domain.com","password")
$service.AutodiscoverUrl($MailboxName,{$true})
$message = New-Object Microsoft.Exchange.WebServices.Data.EmailMessage($service)
$message.Subject = "Test"
$message.Body = "Test 123"
$message.ToRecipients.Add("user@domain.com")
$PidLidClassificationGuid = New-Object Microsoft.Exchange.WebServices.Data.ExtendedPropertyDefinition([Microsoft.Exchange.WebServices.Data.DefaultExtendedPropertySet]::Common, 34232,[Microsoft.Exchange.WebServices.Data.MapiPropertyType]::String);
$message.SetExtendedProperty($PidLidClassificationGuid, "e67e794b-f6d1-4c8f-9f63-1118d21dafa6");
$PidLidClassified = New-Object Microsoft.Exchange.WebServices.Data.ExtendedPropertyDefinition([Microsoft.Exchange.WebServices.Data.DefaultExtendedPropertySet]::Common,34229,[Microsoft.Exchange.WebServices.Data.MapiPropertyType]::Boolean);
$message.SetExtendedProperty($PidLidClassified, $true);
$message.Send.Invoke()

Making use of the PidTagStartDateEtc to calculate the age of an object for Achive and Retention policies

2011-05-09T21:10:00.008+10:00

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 fileTime = BitConverter.ToInt64((Byte[])StartDate, 4);
DateTime ItemAge = DateTime.FromFileTime(fileTime);

Article on using EWS to search mailboxes

2011-05-04T19:33:00.003+10:00

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

Using EWS to calculate the age of Items and affect of archive and retention policies in Exchange 2010

2011-04-25T20:06:00.005+10:00

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 a range of values for example you could use it to search for Messages between 5 and 10 MB using a AQS String like System.Size:1mb..5mb. When searching for age based content you want to search for items between a particular date range for example to search for items 3 years old you could use 01/01/1990..01/01/2008.

What I've done is create a EWS Managed API script that put this all together it firstly does a query to get the folder hierarchy adding a few other useful properties like the folderpath and the current folder size then using measure-object this sums a collection of folder items based on the Item size. The script produces a CSV file of all the folders in a mailbox that contain items with the Daterange and what the size of those items is and what percentage of the total size of the mailbox folder is the output should look like

With this script the following two variables control the data range for the AQS query and the mailboxes to access

$Range = "01/01/1990..01/01/2008"
$MailboxName = "user@domain.com"

I've put a download of this script here the code looks like

$Range = "01/01/1990..01/01/2008"
$MailboxName = "user@domain.com"
$AQSString = "System.Message.DateReceived:" + $Range
$rptCollection = @()
function ConvertToString($ipInputString){
$Val1Text = ""
for ($clInt=0;$clInt -lt $ipInputString.length;$clInt++){
$Val1Text = $Val1Text + [Convert]::ToString([Convert]::ToChar([Convert]::ToInt32($ipInputString.Substring($clInt,2),16)))
$clInt++
}
return $Val1Text
}
$dllpath = "C:\Program Files\Microsoft\Exchange\Web Services\1.1\Microsoft.Exchange.WebServices.dll"
[void][Reflection.Assembly]::LoadFile($dllpath)
$service = New-Object Microsoft.Exchange.WebServices.Data.ExchangeService([Microsoft.Exchange.WebServices.Data.ExchangeVersion]::Exchange2010)
#$service.Credentials = New-Object System.Net.NetworkCredential("username","password")
$windowsIdentity = [System.Security.Principal.WindowsIdentity]::GetCurrent()
$sidbind = "LDAP://<SID=" + $windowsIdentity.user.Value.ToString() + ">"
$aceuser = [ADSI]$sidbind
$service.AutodiscoverUrl($MailboxName,{$true})
$PR_FOLDER_TYPE = new-object Microsoft.Exchange.WebServices.Data.ExtendedPropertyDefinition(13825,[Microsoft.Exchange.WebServices.Data.MapiPropertyType]::Integer);
"Checking : " + $MailboxName
$folderidcnt = new-object Microsoft.Exchange.WebServices.Data.FolderId([Microsoft.Exchange.WebServices.Data.WellKnownFolderName]::MsgFolderRoot,$MailboxName)
$fvFolderView = New-Object Microsoft.Exchange.WebServices.Data.FolderView(1000)
$fvFolderView.Traversal = [Microsoft.Exchange.WebServices.Data.FolderTraversal]::Deep;
$psPropertySet = new-object Microsoft.Exchange.WebServices.Data.PropertySet([Microsoft.Exchange.WebServices.Data.BasePropertySet]::FirstClassProperties)
$PR_MESSAGE_SIZE_EXTENDED = new-object Microsoft.Exchange.WebServices.Data.ExtendedPropertyDefinition(3592,[Microsoft.Exchange.WebServices.Data.MapiPropertyType]::Long);
$PR_DELETED_MESSAGE_SIZE_EXTENDED = new-object Microsoft.Exchange.WebServices.Data.ExtendedPropertyDefinition(26267,[Microsoft.Exchange.WebServices.Data.MapiPropertyType]::Long);
$PR_Folder_Path = new-object Microsoft.Exchange.WebServices.Data.ExtendedPropertyDefinition(26293, [Microsoft.Exchange.WebServices.Data.MapiPropertyType]::String);
$psPropertySet.Add($PR_MESSAGE_SIZE_EXTENDED);
$psPropertySet.Add($PR_Folder_Path);
$fvFolderView.PropertySet = $psPropertySet;
$sfSearchFilter = new-object Microsoft.Exchange.WebServices.Data.SearchFilter+IsEqualTo($PR_FOLDER_TYPE,"1")
$fiResult = $Service.FindFolders($folderidcnt,$sfSearchFilter,$fvFolderView)
foreach($ffFolder in $fiResult.Folders){
"Processing : " + $ffFolder.displayName
$TotalItemCount = $TotalItemCount + $ffFolder.TotalCount;
$FolderSize = $null;
$FolderSizeValue = 0
if ($ffFolder.TryGetProperty($PR_MESSAGE_SIZE_EXTENDED,[ref] $FolderSize))
{
$FolderSizeValue = [Int64]$FolderSize
}
$foldpathval = $null
if ($ffFolder.TryGetProperty($PR_Folder_Path,[ref] $foldpathval))
{
}
$binarry = [Text.Encoding]::UTF8.GetBytes($foldpathval)
$hexArr = $binarry | ForEach-Object { $_.ToString("X2") }
$hexString = $hexArr -join ''
$hexString = $hexString.Replace("FEFF", "5C00")
$fpath = ConvertToString($hexString)
$fiFindItems = $null
$ItemView = New-Object Microsoft.Exchange.WebServices.Data.ItemView(1000)
$psPropertySet1 = new-object Microsoft.Exchange.WebServices.Data.PropertySet([Microsoft.Exchange.WebServices.Data.BasePropertySet]::IdOnly)
$psPropertySet1.Add([Microsoft.Exchange.WebServices.Data.ItemSchema]::Size)
$ItemView.PropertySet
$itemCollection = @()
do{
$fiFindItems = $ffFolder.findItems($AQSString,$ItemView)
$ItemView.offset += $fiFindItems.Items.Count
foreach($Item in $fiFindItems.Items){
$rptobject = "" | select Size
$rptobject.Size = $Item.Size
$itemCollection +=$rptobject
}
}while($fiFindItems.MoreAvailable -eq $true)
$outObj = $itemCollection | Measure-Object Size -Sum -Average -Min -Max
if($outObj -ne $null){
Add-Member -InputObject $outObj -MemberType NoteProperty -Name Mailbox -Value $MailboxName
Add-Member -InputObject $outObj NoteProperty -Name Folder -Value $ffFolder.DisplayName
Add-Member -InputObject $outObj NoteProperty -Name FolderPath -Value $fpath
Add-Member -InputObject $outObj NoteProperty -Name TotalFolderSize -Value $FolderSizeValue
Add-Member -InputObject $outObj NoteProperty -Name DateRange -Value $Range
$rptCollection += $outObj
}
}
$rptCollection | select Mailbox,Folder,FolderPath,@{label="FolderSize(MB)";expression={[math]::Round($_.TotalFolderSize/1MB,2)}},@{label="RangeSize(MB)";expression={[math]::Round($_.Sum/1MB,2)}},@{label="RangeCount";expression={$_.Count}},@{label="PercentOfSize";expression={'{0:P0}' -f ($_.Sum/$_.TotalFolderSize)}} | export-csv c:\temp\MbAgeReport.csv -NoTypeInformation

Displaying the OOF log in a mailbox using Exchange Web Services and Powershell

2011-04-05T13:21:00.006+10:00

On a Exchange 2007 and 2010 when changes are made to the Out of Office setting these changes are logged into an Item sitting in the Non_IPM_Subtree folder of a mailbox which has a message class of IPM.Microsoft.OOF.Log .

The log of changes is written to the body of this message and can be useful if for any reason you need a historical record of the oof setting for a particular mailbox. For instance if someone set an inappropriate OOF message and you need some evidence of this. You could also sequence this data to get picture over a certain time period of what users had their oof set and for how long it was enabled and did it say anything useful.

I've put together a script to show how to get at this log using the EWS Managed API and powershell and I've also included a parser to parse the log entries into an object to make it easier to export this data to csv or email etc.

I've put a download of this script here the script itself looks like

$MailboxName = "user@domain"
$rptCollection = @()

$dllpath = "C:\Program Files\Microsoft\Exchange\Web Services\1.1\Microsoft.Exchange.WebServices.dll"
[void][Reflection.Assembly]::LoadFile($dllpath)
$service = New-Object Microsoft.Exchange.WebServices.Data.ExchangeService([Microsoft.Exchange.WebServices.Data.ExchangeVersion]::Exchange2007_SP1)
$service.TraceEnabled = $false

$windowsIdentity = [System.Security.Principal.WindowsIdentity]::GetCurrent()
$sidbind = "LDAP://<SID=" + $windowsIdentity.user.Value.ToString() + ">"
$aceuser = [ADSI]$sidbind
# $service.Credentials = New-Object System.Net.NetworkCredential("user","password")
$service.AutodiscoverUrl($MailboxName ,{$true})

$nonipmRoot = new-object Microsoft.Exchange.WebServices.Data.FolderId([Microsoft.Exchange.WebServices.Data.WellKnownFolderName]::Root,$MailboxName)
$ivItemView = new-object Microsoft.Exchange.WebServices.Data.ItemView(2)
$sfSearchFilter = new-object Microsoft.Exchange.WebServices.Data.SearchFilter+IsEqualTo([Microsoft.Exchange.WebServices.Data.ItemSchema]::ItemClass, "IPM.Microsoft.OOF.Log")
$psPropertySet = new-object Microsoft.Exchange.WebServices.Data.PropertySet([Microsoft.Exchange.WebServices.Data.BasePropertySet]::FirstClassProperties)
$psPropertySet.RequestedBodyType = [Microsoft.Exchange.WebServices.Data.BodyType]::Text;
$fiItems = $service.finditems($nonipmRoot,$sfSearchFilter,$ivItemView)
foreach($itItem in $fiItems.Items){

$itItem.load($psPropertySet)
$itItem.Body.Text.Split("`r") | ForEach-Object{
$line = $_
if($line.indexof("Mailbox:")-gt 0){
$elen = $line.indexof("Mailbox:")
if($elen -gt 0){
$datetime = $line.SubString(1,$elen-3)
}
}
if($line.indexof("Mailbox:")-gt 0){
$slen = $line.indexof("Mailbox:")
$elen = $line.indexof("OofState:",$slen)
if($slen -gt 0){
$slen += 10
$mailbox = $line.SubString($slen,($elen-$slen)-3)
}
}
if($line.indexof("OofState:")-gt 0){
$slen = $line.indexof("OofState:")
$elen = $line.indexof("ExternalAudience:",$slen)
if($slen -gt 0){
$slen += 10
$OofState = $line.SubString($slen,($elen-$slen)-2)
}
}
if($line.indexof("ExternalAudience:")-gt 0){
$slen = $line.indexof("ExternalAudience:")
$elen = $line.indexof("InternalReply:",$slen)
if($slen -gt 0){
$slen += 18
$ExternalAudience = $line.SubString($slen,($elen-$slen)-2)
}
}
if($line.indexof("InternalReply:")-gt 0){
$slen = $line.indexof("InternalReply:")
$elen = $line.indexof("ExternalReply:",$slen)
if($slen -gt 0){
$slen += 15
$InternalReply = $line.SubString($slen,($elen-$slen)-2)
}
}
if($line.indexof("ExternalReply:")-gt 0){
$slen = $line.indexof("ExternalReply:")
$elen = $line.indexof("SetByLegacyClient:",$slen)
if($slen -gt 0){
$slen += 15
$ExternalReply = $line.SubString($slen,($elen-$slen)-2)
}
}
if($line.indexof("SetByLegacyClient:")-gt 0){
$slen = $line.indexof("SetByLegacyClient:")
$elen = $line.indexof("comment:")
if($slen -gt 0){
$slen += 20
$SetByLegacyClient = $line.SubString($slen,($elen-$slen)-3)
}
}
if($line.indexof("comment:")-gt 0){
$slen = $line.indexof("comment")
$elen = $line.indexof("'",$slen)
if($slen -gt 0){
$slen += 9
$comment = $line.SubString($slen,($elen-$slen))
}
}
$mbcomb = "" | select datetime,mailbox,OofState,ExternalAudience,InternalReply,ExternalReply,SetByLegacyClient,comment
$mbcomb.datetime = $datetime
$mbcomb.mailbox = $mailbox
$mbcomb.OofState = $OofState
$mbcomb.ExternalAudience = $ExternalAudience
$mbcomb.InternalReply = $InternalReply
$mbcomb.ExternalReply = $ExternalReply
$mbcomb.SetByLegacyClient = $SetByLegacyClient
$mbcomb.comment = $comment
$rptCollection += $mbcomb
}
}
$rptCollection

Reading custom MAPI properties in a Transport Agent

2011-04-02T20:03:00.006+11:00

In Exchange 2007 and 2010 all mail that is sent and received must transit its way through a Hub server where if your a developer you can create a transport agent to perform additional tasks on those messages before the are passed out of your org or into a mailbox. Sometimes these tasks may involve custom mapi properties that you may have created by using customized forms in Outlook or OWA or possibly a custom EWS application. When it comes to accessing these custom properties in a Transport Agent it involves using the TNEFReader in a transport agent to parse TNEF part of a message.

TNEF for those uninitiated stands for Transport Neutral Encapsulation Format which is a serialization format that Exchange uses to send the Mapi properties of a Item via email there is a protocol document that covers this http://msdn.microsoft.com/en-us/library/cc425498%28v=EXCHG.80%29.aspx. What the TNEFReader does is allows a Transport Agent to parse all the different property structures and data-types contained within the TNEF data stream.

One of the harder things to understand when dealing with Mapi properties is that they come in two different types. The following http://msdn.microsoft.com/en-us/library/cc979184.aspx page describes the difference between tagged properties and named properties. And there are different properties for different parts of a messages for instance there are Item properties for the Item, Recipient properties in the recipients collection for each recipients and attachment properties for each attachment. So when you are parsing an Item its not just as simple as reading one particular property collection (depending on what your trying to do).

For custom properties these should always be named properties and for the most they will use the PS_PUBLIC_STRINGS property set (but you may have created your own custom propset GUID) and either a long ID (LID) or String value for the PropertyName. This can all be confirmed using a Mapi Editor like MFCMapi or OutlookSpy to look at an item where this property has been set.

When you have gathered all this information your ready to use the property in your Transport Agent. The first thing to do when parsing a TNEF part in a transport agent is to work out at what level or properties you want to parse eg the Message properties or the attachment properties or possibly an embedded attachments properties (an Item attachment). The TNEFReader parses the properties in a forward direction to test if a property is a named property you use the

reader.PropertyReader.IsNamedProperty

If you want to check the propset GUID

reader.PropertyReader.PropertyNameId.PropertySetGuid

To see if this property is using a LID or String

reader.PropertyReader.PropertyNameId.Kind == TnefNameIdKind.Name

To demonstrate this I've put together a sample that pushes a particular custom property into a x-header which i find it useful for a number of things. I've put a download of the code here the agent looks like

using System;
using System.Collections.Generic;
using System.Text;
using System.Collections;
using System.Diagnostics;
using Microsoft.Exchange.Data.Transport;
using Microsoft.Exchange.Data.Mime;
using Microsoft.Exchange.Data.ContentTypes.Tnef;
using Microsoft.Exchange.Data.Transport.Email;
using Microsoft.Exchange.Data.Transport.Routing;
using Microsoft.Exchange.Data.Common;
using System.IO;
using Microsoft.Win32;
using System.Reflection;

namespace ExchangeRoutingAgents
{
public class MapiPropAgentFactory : RoutingAgentFactory
{
public override RoutingAgent CreateAgent(SmtpServer server)
{
RoutingAgent mpAgent = new MapiPropAgent();
return mpAgent;
}
}
}

public class MapiPropAgent : RoutingAgent
{
public MapiPropAgent()
{
this.OnRoutedMessage += new RoutedMessageEventHandler(MapiPropAgent_OnRoutedMessage);
}
void MapiPropAgent_OnRoutedMessage(RoutedMessageEventSource esEvtsource, QueuedMessageEventArgs qmQueuedMessage)
{
String myPropString = "myExtraInfo";
MimePart tnefPart = qmQueuedMessage.MailItem.Message.TnefPart;
if (tnefPart != null)
{
//Check the Mimeheader to see if the X-header exists
MimeDocument mdMimeDoc = qmQueuedMessage.MailItem.Message.MimeDocument;
HeaderList hlHeaderlist = mdMimeDoc.RootPart.Headers;
Header myPropHeader = hlHeaderlist.FindFirst(myPropString);
TnefReader reader = new TnefReader(tnefPart.GetContentReadStream(), 0, TnefComplianceMode.Loose);
while (reader.ReadNextAttribute())
{
//Find Message Level TNEF attributes
if (reader.AttributeTag == TnefAttributeTag.MapiProperties)
{

while (reader.PropertyReader.ReadNextProperty())
{
if (reader.PropertyReader.IsNamedProperty)
{
if (reader.PropertyReader.PropertyNameId.Name == myPropString)
{

String myPropStringValue = reader.PropertyReader.ReadValueAsString();
if (myPropHeader == null)
{
MimeNode lhLasterHeader = hlHeaderlist.LastChild;
TextHeader nhNewHeader = new TextHeader(myPropString, myPropStringValue);
hlHeaderlist.InsertBefore(nhNewHeader, lhLasterHeader);
lhLasterHeader = null;
nhNewHeader = null;
}
}
}

}

}
}
reader.Dispose();
}

}

}

Displaying Delegate Forward rule entries and removing any invalid entires with EWS and Powershell

2011-03-30T21:06:00.009+11:00

This post follows on a little from a previous post where i was talking about invalid delegates. One thing the current EWS Rule operations in Exchange 2010 and also the Get-InboxRule cmdlets can't do is that both of these wont display any information about the delegate forward rule if its been configured. Now you can tell using the delegate operation if a forward rule has been configured for a user but this still doesn't read the rule object directly. You could question why you would want to do this if that's the case and the reason is usually when your trying to diagnose why somebody maybe geting a bounce message when meeting messages are being forwarded to an invalid mailbox user (eg a deleted delegate).

If you want to find what delegates the delegate rule is forwarding to you need to read these directly from the rule object. On Exchange 2010 you can access Folder Associated Items (FAI) and the Delegate rule object. In EWS to find this you can create a searchfilter and look for the FAI item where the PR_RuleMsgProvider_W property is set to "Schedule+ EMS Interface". Once there the address that a delegate is forwarded to are stored in the PidTagRuleMsgActions property which is documented in Rules protocol document http://msdn.microsoft.com/en-us/library/cc463893%28v=EXCHG.80%29.aspx . Parsing this property however is not trivial basically this property is a stream of serialized MAPI properties so one property that stores other properties such as PR_DisplayName and PR_EMAIL_ADDRESS_W. Fortunately i had a bit of experience and code from the FTS Stream parser i wrote and with some simple adaption this code can be more or less plugged in and returns all the properties and value parsed correctly. For the purpose of reading the delegates a forwarding rule is forwarding to PR_EMAIL_ADDRESS_W is the important property.

So to make this usable from Powershell I've created some cmdlets that first allows you to read the raw actions property on the delegate rule. Display any of these rules that are invalid it does this by using a EWS getdelegate operation and then comparing the valid entries retrieved with the delegate rules that exist. Then there is a unsupported remove cmdlet although the method I've used in not that bad basically what the remove does is if it finds one valid delegate in the delegate rule it forces an update of this delegate rule using an update delegate operation which will cause the delegate rule to be updated which will remove the invalid entry (as long as you have cleaned up the invalid delegates in Outlook or the other Remove-MessageOps.MailboxDelegatesInvalid.Unsupported cmdlet).

Get-MessageOps.MailboxDelegateForwardingRules: This cmdlet retrieves the MailboxDelegate Forwarding rules by finding the rules object in the associated folders collection of the Inbox and then parsing the actions MAPI property on this object. Note because of the limitation in EWS in 2007 this cmdlet will only work on Exchange 2010.

Example: Get-MessageOps.MailboxDelegateForwardingRules –p $ewsprofile –identity mailbox@domain.com

Get-MessageOps.MailboxDelegateInvalidForwardingRules: This cmdlet retrieves the MailboxDelegate Forwarding rules by finding the rules object in the associated folders collection of the Inbox and then parsing the actions MAPI property on this object. It then compares the entries contained in the forwarding rule to check if there is a valid delegate for this entry by using a getdelegates operation. Any users that don’t have a valid delegate entry is returned as invalid.
Example: Remove-MailboxDelegateInvalidForwardingRules –p $ewsprofile –identity mailbox@domain.com

Remove-MessageOps.MailboxDelegateInvalidForwardingRules.Unsupported: This cmdlet retrieves the MailboxDelegate Forwarding rules by finding the rules object in the associated folders collection of the Inbox and then parsing the actions MAPI property on this object. It then compares the entries contained in the forwarding rule to check if there is a valid delegate for this entry by using a getdelegates operation. If an invalid entry is found depending on the number of delegate entries the following action are taken.

· If other valid entries are found a update delegate operation is performed on one these entries which should make the sever side process remove the invalid entry when the forward rule is updated.

· If no other valid entries are found the rule object is deleted.

Example: Remove-MessageOps.MailboxDelegateInvalidForwardingRules.Unsupported –p $ewsprofile –identity mailbox@domain.com

To use these cmdlets you need to download the following module http://www.messageops.com/downloads/MessageOps-Exchange-Module.zip

Exchange 2010 Administrator Audit log Powershell GUI

2011-03-29T14:45:00.005+11:00

An interesting and useful new feature of Exchange 2010 is Administrator audit logging where each time a EMS cmdlet is run in the Exchange in the EMS, EMC or ECP this is logged. Within ECP you can do a search of the admin Audit logs and have the result emailed to you and what you receive in your inbox is an email with an a attachment called searchresult.xml. While this file contains a lot of great information there are a few problems with this format for administrators firstly is that OWA and Oultook will usually block the XML attachments so it can firstly be hard to get to the attachment. Secondly XML isn't the most readable format when it comes to trying to intemperate what was going on especially if you search across a larger number of days. So what I've put together is a GUI that first uses the EWS Managed API to find these any of these emails within your inbox and then gives you the option of exporting the raw xml or converting the XML to a CSV file or lastly using a separate report winform that groups the data retrieved and displays it back to the user. The later i think is a lot more useful as it lets you work more intuitively with the data and the better you can do this the more likely it is that you would spot an abnormality which is one to the purposes of auditing. eg this is what it looks like

Note this GUI currently only handles the Admin Audit logs not the Mailbox Audit log which are in a different format.

I've put a download of this script here

Dealing with Invalid Delegates with Exchange Web Services and Powershell

2011-03-27T21:20:00.007+11:00

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 selected

The last things that gets changed is the publicDelegates active directory property.

What happens to the LocalFreeBusy object is of the most interest and has been documented in the http://msdn.microsoft.com/en-us/library/cc425488%28v=exchg.80%29.aspx protocol document basically it comes down to the following 7 Mapi properties on the LocalFreeBusy object.

PidTagScheduleInfoDelegatorWantsInfo
PidTagScheduleInfoDelegatorWantsCopy

PidTagScheduleInfoDelegateNamesW
PidTagScheduleInfoDelegateEntryIds
PidTagDelegateFlags

These last three properties contain specific setting for each delegate user including the X500DN of the delegated users within PidTagScheduleInfoDelegateEntryIds (Its stored as Addessbook entryid).

If your observant you would have only counted 5 properties which is all that are documented in the protocol document. If you look at the object with a Mapi editor however you would discover two more undocumented properties that also hold information about delegates.

x6870 and x6871

To get the localfreebusy object in a mailbox using EWS there are a few methods you can use the first is to search the NON_IPM_Subtree for and find the FreeBusy Data folder and then search that folder for an item with a subject of localfreebusy. The other option is to use is the PR_FREEBUSY_ENTRYIDS extended property on the Non_IPM_Subtree which contains an array of FreeBusy EntryID's which the 2nd element is the LocalFreeBusy Object which you can convert into a EWSid using a convertid operation and then bind directly to that item.

So if your using EWS and you get "The delegate does not map to a user in the Active Directory" and you want to find out which user this refers to you can compare whats returned in PidTagScheduleInfoDelegateNamesW with the valid delegates you back with normal operation you should be able to work out the invalid delegate.

To demonstrate this I've put some Powershell cmdlet's together so basically you can display firstly the Raw property values, show what is invalid doing the compare i talked about above and then lastly you can do a unsupported remove which basically will remove the invalid entries out of the extended properties. The reason i said this is unsupported because its not really tested and its also only modifies the raw properties so all the other things like mailbox permission, forward rules will still be in-place (although I've also created some cmdlets to clean up invalid forward rules as well that I'll talk about in a separate post).

Get-MessageOps.MailboxDelegatesRaw : This Cmdlet retrieves the delegates from a mailbox by reading the Raw Mapi properties from the Local Freebusy Item in a mailbox.

eg Get-MessageOps.MailboxDelegates –p $ewsprofile –identity mailbox@domain.com

Get-MessageOps.MailboxDelegatesInvalid : This Cmdlet retrieves the delegates from a mailbox by reading the Raw Mapi properties from the Local Freebusy Item in a mailbox and then compares them against what is retrieved using a normal getdelegate operation.

eg. Get-MessageOps.MailboxDelegatesInvalid –p $ewsprofile –identity mailbox@domain.com

Remove-MessageOps.MailboxDelegatesInvalid.Unsupported : This Cmdlet retrieves the delegates from a mailbox by reading the Raw Mapi properties from the Local Freebusy Item in a mailbox and then compares them against what is retrieved using a normal getdelegate operation. It then modifies the Raw Mapi properties on the local freebusy object and removes any entries that it finds are invalid. Note this doesn’t remove the delegate forwarding rules if it exists and also doesn’t remove any delegate permissions if they have been set.

eg. Remove-MessageOps.MailboxDelegatesInvalid.Unsupported –p $ewsprofile –identity mailbox@domain.com

To use these cmdlets you need to download the following module http://www.messageops.com/downloads/MessageOps-Exchange-Module.zip

Using the PR_Folder_Path property in Exchange Web Services to show the folder path

2011-03-10T20:55:00.003+11:00

The PR_Folder_PathName Mapi property is a useful property to use when migrating an application that uses WebDAV to EWS where the webdav application has used the DAV:href property paths or if you just want to display the fullpath to a folder delimited by "\" which may useful for other applications.

The PR_Folder_PathName property returns the fullpath to a folder that is delimited by the byte order mark FE-FF so if you want to return a \ delimited path you need to replace these values in the Unicode string that is returned when you retrieve this property.

eg in the managed API

static void getPath(ExchangeService service) {
ExtendedPropertyDefinition PR_Folder_Path = new ExtendedPropertyDefinition(26293, MapiPropertyType.String);
PropertySet psPropSet = new PropertySet(BasePropertySet.FirstClassProperties) { PR_Folder_Path };
Folder foFolder = Folder.Bind(service, WellKnownFolderName.RecoverableItemsDeletions, psPropSet);
Object fpPath = null;
foFolder.TryGetProperty(PR_Folder_Path,out fpPath);
String fpPathString = Encoding.Unicode.GetString(HexStringToByteArray(BitConverter.ToString(UnicodeEncoding.Unicode.GetBytes((String)fpPath)).Replace("FE-FF", "5C-00").Replace("-", "")));
Console.WriteLine(fpPathString);
}

static Byte[] HexStringToByteArray(String HexString)
{
Byte[] ByteArray = new Byte[HexString.Length / 2];
for (int i = 0; i < HexString.Length; i += 2)
{
ByteArray[i / 2] = Convert.ToByte(HexString.Substring(i, 2), 16);
}
return ByteArray;
}

Exporting and Uploading Mailbox Items using Exchange Web Services using the new ExportItems and UploadItems operations in Exchange 2010 SP1

2011-02-21T19:29:00.006+11:00

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 item as an EML but this doesn't provide any fidelity of the properties on item).

Now with these two new operations there is a method of exporting and uploading items and maintaining all the Mapi properties. The only real restriction is by default the maximum import payload is 25MB of base64 encoded data but these setting can be modified in the web.config file. The export/import format that these two operations use in the Fast Transfer Stream format which is a stream of all the Exchange properties separated with meta properties to represent the different property collections on the Item. This format while it bares some similarity to TNEF and Compound Message format (MSG) is not the same. If your interested in learning more about the Fast Transfer Stream format there is a good presentation here. To help read the FastTransferStream files that are produced by the ExportItems offline I've created a roughly little parser and browser and posted this on codeplex.

There are no methods in the EWS Managed API to use these operations so you need to use EWS Proxy code or just raw SOAP when writing applications or script to use this. However you do need the EWSid's of the Items and Folder to upload or export items and the Managed API is the easiest way of getting these. For this post I've create a sample of exporting the last received item in the Inbox first using the EWS Managed API to find the last item and then use raw SOAP to export the items.

Before i go through that sample I've also added some cmdlets to the powershell module that i've been working on that use these operations that simplifies the code from powershell down to a couple of lines of code rather then the long script i'll post below. The new cmdlets i wrote are.

Export-MessageOps.Item Exports an Item as a binary FTS Stream that can be stored in memory or written to a file

eg

$item = Get-MessageOps.Messages -p $ewsprofile -fp \\Inbox -MessageCount 1
Export-MessageOps.Item -ewsprofile $ewsprofile -ewsid $item.id -FileName c:\download\item.fts

Export-MessageOps.Items Exports multiple Items as a binary FTS Stream that can be stored in memory or written to multiple files in a directory

$items = Get-MessageOps.Messages -p $ewsprofile -fp \\inbox -MessageCount 20
Export-MessageOps.Items -p $ewsprofile -DirectoryName c:\temp -Items $items

Import-MessageOps.Item Imports an Item that has been exported using the Export cmdlets the input can be either a ExportItemsResponseMessageType or a FileName of a file that is in FTS format.

Import-MessageOps.Item -p $ewsprofile -fp \\inbox -Filename c:\item.fts

Import-MessageOps.Items Import multiple Items exported using the Export-MessageOps.Items cmdlet

$exItems = Export-MessageOps.Items -p $ewsprofile -Items $items
Import-MessageOps.Items -p $ewsprofile -fp \\inbox -Items $exItems

To use these cmdlets you need the following module http://www.messageops.com/downloads/MessageOps-Exchange-Module.zip

I posted a downloadable copy of the following EWS Managed API script here the code itself looks like

$MailboxName = "mailbox@domain.com"
$fileName = 'c:\exp.fts'
$cred = New-Object System.Net.NetworkCredential("username@domain.com","password")

$dllpath = "C:\Program Files\Microsoft\Exchange\Web Services\1.1\Microsoft.Exchange.WebServices.dll"
[void][Reflection.Assembly]::LoadFile($dllpath)
$service = New-Object Microsoft.Exchange.WebServices.Data.ExchangeService([Microsoft.Exchange.WebServices.Data.ExchangeVersion]::Exchange2010_SP1)
$service.TraceEnabled = $false

$windowsIdentity = [System.Security.Principal.WindowsIdentity]::GetCurrent()
$sidbind = "LDAP://<SID=" + $windowsIdentity.user.Value.ToString() + ">"
$aceuser = [ADSI]$sidbind
$service.Credentials = $cred
$service.autodiscoverurl($MailboxName,{$true})

$folderid = new-object Microsoft.Exchange.WebServices.Data.FolderId([Microsoft.Exchange.WebServices.Data.WellKnownFolderName]::Inbox,$MailboxName)

$view = New-Object Microsoft.Exchange.WebServices.Data.ItemView(1)
$findResults = $service.FindItems($folderid,$view)
$itemid = $findResults.Items[0].Id.Uniqueid

$expRequest = @"
<?xml version="1.0" encoding="utf-8" ?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:t="http://schemas.microsoft.com/exchange/services/2006/types"
xmlns:m="http://schemas.microsoft.com/exchange/services/2006/messages">
<soap:Header>
<t:RequestServerVersion Version="Exchange2010_SP1" />
</soap:Header>
<soap:Body>
<m:ExportItems>
<m:ItemIds>
<t:ItemId Id="$itemId"/>
</m:ItemIds>
</m:ExportItems>
</soap:Body>
</soap:Envelope>
"@
$mbMailboxFolderURI = New-Object System.Uri($service.url)
$wrWebRequest = [System.Net.WebRequest]::Create($mbMailboxFolderURI)
$wrWebRequest.KeepAlive = $false;
$wrWebRequest.Headers.Set("Pragma", "no-cache");
$wrWebRequest.Headers.Set("Translate", "f");
$wrWebRequest.Headers.Set("Depth", "0");
$wrWebRequest.ContentType = "text/xml";
$wrWebRequest.ContentLength = $expRequest.Length;
$wrWebRequest.Timeout = 60000;
$wrWebRequest.Method = "POST";
$wrWebRequest.Credentials = $cred
$bqByteQuery = [System.Text.Encoding]::ASCII.GetBytes($expRequest);
$wrWebRequest.ContentLength = $bqByteQuery.Length;
$rsRequestStream = $wrWebRequest.GetRequestStream();
$rsRequestStream.Write($bqByteQuery, 0, $bqByteQuery.Length);
$rsRequestStream.Close();
$wrWebResponse = $wrWebRequest.GetResponse();
$rsResponseStream = $wrWebResponse.GetResponseStream()
$sr = new-object System.IO.StreamReader($rsResponseStream);
$rdResponseDocument = New-Object System.Xml.XmlDocument
$rdResponseDocument.LoadXml($sr.ReadToEnd());
$Datanodes = @($rdResponseDocument.getElementsByTagName("m:Data"))
if ($Datanodes.length -ne 0){
$Data = [System.Convert]::FromBase64String($Datanodes[0].'#text')
$fsFileStream = new-object system.io.filestream $fileName, ([io.filemode]::create), ([io.fileaccess]::write), ([io.fileshare]::none)
$fsFileStream.Write($Data, 0, $Data.Length);
$fsFileStream.Close();
}

Creating Inbox Rules with the EWS Managed API in Exchange 2010 SP1 with Powershell

2011-02-08T15:17:00.003+11:00

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 RulePredicates and RuleActions to cater for actions such as moving items, replying with an auto response etc you will need to use other EWS operations to find the EWSID's of the particular folder or autoreply message you want to work with so this will require the use of other code. Also for conditions if you have used an email address the address's stored in rule objects are in EX type so using the EWS Resolve names operations can be useful to resolve the name back to an SMTP Address or users displayName.

The following example shows how to create a Move rule based on the Subject of a message it uses a function to find the EWS folderid of the folder to move the message to. Note this script could be easily adapted to instead of using the Subject to move the message move the message based on a X-header eg by modifying the following line

$nrNewRule.Conditions.ContainsHeaderStrings.Add("X-SpamScore: 7");

would add a condition to move a message based on a message header.

For those following along with the module code I've been writing I've written some rule cmdlets to go along with this. I haven't tried to Jam everything to be a one-liner like the EMS cmdlets but the advantage of the module is that you can make use of the other cmldets for getting folders, address etc without the need for other large functions for example the same script to create a rule using the module is

New-MessageOps.MailboxFolder -p $ewsprofile –id User@domain.com -fp "\\" -FolderName "SPAMFolder"
$nrNewRule = New-Object Microsoft.Exchange.WebServices.Data.Rule
$nrNewRule.DisplayName = "SPAMfolderRule";
$nrNewRule.Conditions.ContainsSubjectStrings.Add("Sales Reports");
$nrNewRule.Actions.MoveToFolder = (get-messageops.mailboxfolder -p $ewsprofile –id User@domain.com -FolderPath "\\SPAMFolder").Id
New-MessageOps.InboxRule -p $ewsprofile –id User@domain.com -Rule $nrNewRule

The other thing I've done with the Module is create a cmdlet that flattens out the Rule conditions and Actions into something that an admin can read. The is useful in reporting as its can be hard to spot using the native objects to use this for example

Get-MessageOps.InboxRuleReport -p $ewsprofile | export-csv -notype c:\InboxRules.csv

Will produce a human readable export of the rules and condition into a CSV file. To use any of these module cmdlets you need the following download http://www.messageops.com/downloads/MessageOps-Exchange-Module.zip

For the straight EWS Managed API powershell version I've put a download of this script here the code itself looks like

$mailbox = "user@domain.com"
$fldname = "\\Inbox\Sales"

Function FindTargetFolder($FolderPath){
$tfTargetFolder = [Microsoft.Exchange.WebServices.Data.Folder]::Bind($service,[Microsoft.Exchange.WebServices.Data.WellKnownFolderName]::MsgFolderRoot,$mailbox)
$pfArray = $FolderPath.Split("\")
for ($lint = 2; $lint -lt $pfArray.Length; $lint++) {
$pfArray[$lint]
$fvFolderView = new-object Microsoft.Exchange.WebServices.Data.FolderView(1)
$SfSearchFilter = new-object Microsoft.Exchange.WebServices.Data.SearchFilter+IsEqualTo([Microsoft.Exchange.WebServices.Data.FolderSchema]::DisplayName,$pfArray[$lint])
$findFolderResults = $service.FindFolders($tfTargetFolder.Id,$SfSearchFilter,$fvFolderView)
if ($findFolderResults.TotalCount -gt 0){
foreach($folder in $findFolderResults.Folders){
$tfTargetFolder = $folder
}
}
else{
"Error Folder Not Found"
$tfTargetFolder = $null
break
}
}
$Global:findFolder = $tfTargetFolder
}

$dllpath = "C:\Program Files\Microsoft\Exchange\Web Services\1.1\Microsoft.Exchange.WebServices.dll"
[void][Reflection.Assembly]::LoadFile($dllpath)
$service = New-Object Microsoft.Exchange.WebServices.Data.ExchangeService([Microsoft.Exchange.WebServices.Data.ExchangeVersion]::Exchange2010_SP1)
$service.TraceEnabled = $false

$windowsIdentity = [System.Security.Principal.WindowsIdentity]::GetCurrent()
$sidbind = "LDAP://<SID=" + $windowsIdentity.user.Value.ToString() + ">"
$aceuser = [ADSI]$sidbind
$service.autodiscoverurl($mailbox,{$true})

$irInboxRules = service.GetInboxRules

$nrNewRule = New-Object Microsoft.Exchange.WebServices.Data.Rule
$nrNewRule.DisplayName = "Move all Mails with Sales Reports in Subject"
$nrNewRule.Conditions.ContainsSubjectStrings.Add("Sales Reports");

FindTargetFolder($fldname)

$nrNewRule.Actions.MoveToFolder = $Global:findFolder.Id.UniqueId

$RuleOperation = New-Object Microsoft.Exchange.WebServices.Data.createRuleOperation[] 1
$RuleOperation[0] = $nrNewRule

$service.UpdateInboxRules($RuleOperation,$irInboxRules.OutlookRuleBlobExists)

Dealing with Throttling restrictions in Exchange Web Services on Exchange 2010 SP1 in scripts and code

2011-01-31T19:44:00.007+11:00

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. This is discussed in a little more detail here https://blogs.msdn.com/b/exchangedev/archive/2010/03/12/throttling-policies-and-the-ewsfindcountlimit.aspx.

The upshot of this is if you have code where you have set a page size greater than 1000 and your not checking IncludesLastItemInRange to ensure you have retrieved all the items within the scope of your findItems or findfolder request then your current code may will only retrieve the first 1000 items in a folder .To cater for this if your using Powershell and the EWS Managed API you need to use something like a Do{}(Where) to write code loop to ensure you make followup finditem/findfolder requests to retrieve all the items from a particular folder. For example to loop through all the messages within an inbox using a pagesize of 1000 would look like

$folderid = new-object Microsoft.Exchange.WebServices.Data.FolderId([Microsoft.Exchange.WebServices.Data.WellKnownFolderName]::Inbox,$MailboxName)
$ivItemView = New-Object Microsoft.Exchange.WebServices.Data.ItemView(1000)
$fiResult = ""
do{
$fiResult = $Service.FindItems($folderid,$ivItemView)
foreach($Items in $fiResult.Items){
$Items.Subject
}
$ivItemView.offset += $fiResult.Items.Count
}while($fiResult.MoreAvailable -eq $true)

The other setting to be careful of is the EWSFastSearchTimeoutInSeconds which is set to 60 seconds by default. If your querying folders with a large number of items with complex filters then this could be a problem. Fortunately the Entry point EWS offers to make Exchange Search queries should help counter problems with this.

Default Calendar permission Powershell GUI for Exchange 2010 SP1 and up

2011-01-24T17:13:00.004+11:00

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 export the settings to a csv file.

$rptCollection = @()
$mailboxes = get-mailbox -ResultSize Unlimited
$mailboxes | foreach-object{
$alias = $_.alias + ":\Calendar"
$displayName = $_.DisplayName
write-host $alias
$permissions = Get-MailboxFolderPermission $alias | Where-Object {$_.Identity.ToString() -eq "Default"}
if($permissions -ne $null){
$stringPerms = ""
foreach($perms in $permissions.AccessRights){$stringPerms = $stringPerms + $perms + " "}
Add-Member -InputObject $permissions -MemberType NoteProperty -Name "Alias" -Value $alias -Force
Add-Member -InputObject $permissions -MemberType NoteProperty -Name "StringAccessRights" -Value $stringPerms -Force
$rptCollection += $permissions
}

}
$rptCollection | export-csv -notypeInformation c:\defaultperms.csv

To then re-import them from a csv file you can use

import-csv c:\defaultperms.csv | foreach-object{
"Seting Rights on " + $_.alias
Set-MailboxFolderPermission -id $_.alias -User $_.Identity -AccessRights $_.StringAccessRights

}

Personally i like the GUI which is a little more snappier with the GUI I left the permission descriptions in Outlook format rather then switching them to the accessrights role format(the great thing about standards is there are so many to choose from). To run this GUI you need to first start a Remote powershell session and import the Exchange 2010 cmdlets or run it directly from within the EMS. I've put a download of the new script here the code looks like

[System.Reflection.Assembly]::LoadWithPartialName("System.Drawing")
[System.Reflection.Assembly]::LoadWithPartialName("System.windows.forms")

function GetPerms(){
$logTable.clear()

If ($seAuthCheck.Checked -eq $true){
$mailboxes = get-mailbox -server $snServerNameTextBox.Text -ResultSize Unlimited
}
else{
$mailboxes = get-mailbox -ResultSize Unlimited
}
$mailboxes | foreach-object{
$alias = $_.alias + ":\Calendar"
$displayName = $_.DisplayName
write-host $alias
$permissions = Get-MailboxFolderPermission $alias | Where-Object {$_.Identity.ToString() -eq "Default"}
if($permissions -ne $null){
Add-Member -InputObject $permissions -MemberType NoteProperty -Name "Alias" -Value $alias -Force
$stringPerms = ""
foreach($perms in $permissions.AccessRights){$stringPerms = $stringPerms + $perms + " "}
$logTable.rows.add($displayName,$permissions.alias,$stringPerms)
}

}
$dgDataGrid.DataSource = $logTable

}

Function UpdatePerms{
if ($dgDataGrid.SelectedRows.Count -eq 0){
$mbtoSet = $dgDataGrid.Rows[$dgDataGrid.CurrentCell.RowIndex].Cells[1].Value
$newperm = ""
switch ($npNewpermDrop.Text){
"None" {$newperm = "None"}
"FreeBusyTimeOnly" {$newperm = "AvailabilityOnly"}
"FreeBusyTimeAndSubjectAndLocation" {$newperm = "LimitedDetails"}
"Reviewer" {$newperm = "Reviewer"}
"Contributer" {$newperm = "Contributer"}
"Author" {$newperm = "Author"}
"NonEditingAuthor" {$newperm = "NonEditingAuthor"}
"PublishingAuthor"{$newperm = "PublishingAuthor"}
"Author" {$newperm = "Author"}
"Editor" {$newperm = "Editor"}
"PublishingEditor"{$newperm = "PublishingEditor"}
}
Set-MailboxFolderPermission -id $mbtoSet -User Default -AccessRights $newperm
write-host "Permission updated" + $npNewpermDrop.Text
}
else{
$lcLoopCount = 0
while ($lcLoopCount -le ($dgDataGrid.SelectedRows.Count-1)) {
$mbtoSet = $dgDataGrid.SelectedRows[$lcLoopCount].Cells[1].Value

switch ($npNewpermDrop.Text){
"None" {$newperm = "None"}
"FreeBusyTimeOnly" {$newperm = "AvailabilityOnly"}
"FreeBusyTimeAndSubjectAndLocation" {$newperm = "LimitedDetails"}
"Reviewer" {$newperm = "Reviewer"}
"Contributer" {$newperm = "Contributer"}
"Author" {$newperm = "Author"}
"NonEditingAuthor" {$newperm = "NonEditingAuthor"}
"PublishingAuthor"{$newperm = "PublishingAuthor"}
"Author" {$newperm = "Author"}
"Editor" {$newperm = "Editor"}
"PublishingEditor"{$newperm = "PublishingEditor"}
}
Set-MailboxFolderPermission -id $mbtoSet -User Default -AccessRights $newperm
write-host "Permission updated" + $npNewpermDrop.Text
$lcLoopCount += 1
}
}
write-host "end PermUpdate"
write-host "Refresh Perms"
GetPerms
}

$form = new-object System.Windows.Forms.form
$form.Text = "Calender Permission Enum Tool"
$Dataset = New-Object System.Data.DataSet
$logTable = New-Object System.Data.DataTable
$logTable.TableName = "ActiveSyncLogs"
$logTable.Columns.Add("DisplayName");
$logTable.Columns.Add("MailboxFolderId");
$logTable.Columns.Add("Default-Permissions");

# Add Server DropLable
$snServerNamelableBox = new-object System.Windows.Forms.Label
$snServerNamelableBox.Location = new-object System.Drawing.Size(10,60)
$snServerNamelableBox.size = new-object System.Drawing.Size(70,20)
$snServerNamelableBox.Text = "ServerName"
$form.Controls.Add($snServerNamelableBox)

# Add ServerNameText
$snServerNameTextBox = new-object System.Windows.Forms.TextBox
$snServerNameTextBox.Location = new-object System.Drawing.Size(90,60)
$snServerNameTextBox.size = new-object System.Drawing.Size(150,20)
$snServerNameTextBox.Enabled = $false
$form.Controls.Add($snServerNameTextBox)

$seAuthCheck = new-object System.Windows.Forms.CheckBox
$seAuthCheck.Location = new-object System.Drawing.Size(250,60)
$seAuthCheck.Size = new-object System.Drawing.Size(130,25)
$seAuthCheck.Text = "Filter by"
$seAuthCheck.Add_Click({if ($seAuthCheck.Checked -eq $true){
$snServerNameTextBox.Enabled = $true
}
else{
$snServerNameTextBox.Enabled = $false}})
$form.Controls.Add($seAuthCheck)

# Add Get Perms Button

$gpgetperms = new-object System.Windows.Forms.Button
$gpgetperms.Location = new-object System.Drawing.Size(10,20)
$gpgetperms.Size = new-object System.Drawing.Size(140,23)
$gpgetperms.Text = "Enumerate Permissions"
$gpgetperms.Add_Click({GetPerms})
$form.Controls.Add($gpgetperms)

# Add New Permission Drop Down
$npNewpermDrop = new-object System.Windows.Forms.ComboBox
$npNewpermDrop.Location = new-object System.Drawing.Size(350,20)
$npNewpermDrop.Size = new-object System.Drawing.Size(190,30)
$npNewpermDrop.Items.Add("None")
$npNewpermDrop.Items.Add("FreeBusyTimeOnly")
$npNewpermDrop.Items.Add("FreeBusyTimeAndSubjectAndLocation")
$npNewpermDrop.Items.Add("Reviewer")
$npNewpermDrop.Items.Add("Contributer")
$npNewpermDrop.Items.Add("Author")
$npNewpermDrop.Items.Add("NonEditingAuthor")
$npNewpermDrop.Items.Add("PublishingAuthor")
$npNewpermDrop.Items.Add("Editor")
$npNewpermDrop.Items.Add("PublishingEditor")
$form.Controls.Add($npNewpermDrop)

# Add Apply Button

$exButton = new-object System.Windows.Forms.Button
$exButton.Location = new-object System.Drawing.Size(550,20)
$exButton.Size = new-object System.Drawing.Size(60,20)
$exButton.Text = "Apply"
$exButton.Add_Click({UpdatePerms})
$form.Controls.Add($exButton)

# New setting Group Box

$OfGbox = new-object System.Windows.Forms.GroupBox
$OfGbox.Location = new-object System.Drawing.Size(320,0)
$OfGbox.Size = new-object System.Drawing.Size(300,50)
$OfGbox.Text = "New Permission Settings"
$form.Controls.Add($OfGbox)

# Add DataGrid View

$dgDataGrid = new-object System.windows.forms.DataGridView
$dgDataGrid.Location = new-object System.Drawing.Size(10,130)
$dgDataGrid.size = new-object System.Drawing.Size(750,550)
$dgDataGrid.AutoSizeColumnsMode = "AllCells"
$dgDataGrid.SelectionMode = "FullRowSelect"
$form.Controls.Add($dgDataGrid)

$form.Text = "Exchange 2010 Default Calendar Permissions Form"
$form.size = new-object System.Drawing.Size(800,730)

$form.autoscroll = $true
$form.topmost = $true
$form.Add_Shown({$form.Activate()})
$form.ShowDialog()

Calculating Mailbox Sizes using Exchange Web Services and Powershell

2011-01-17T21:16:00.004+11:00

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 of the Mailbox can be used.

One of useful things you can do with EWS that you can't do in EMS with the cmdlets is filter this query by the Mapi FolderClass (which is different from the folderscope property). In the large script posted below I've commented out the filter to do this but the lines are

##$folderItemType = "IPF.Note"
##$sfSearchFilter = new-object Microsoft.Exchange.WebServices.Data.SearchFilter+IsEqualTo([Microsoft.Exchange.WebServices.Data.FolderSchema]::FolderClass, $folderItemType)
##$fiResult = $Service.FindFolders($folderidcnt,$sfSearchFilter,$fvFolderView)

A small example using the EWS Module I've been working on condenses this down to

$ewsProfile = New-MessageOps.EWSProfile -id glen@domain.com
Get-MessageOps.MailboxSize -p $ewsprofile

To filter the result by foldertype you can use

Get-MessageOps.MailboxSize -p $ewsprofile -FolderItemType "IPF.Contact"

To use this you need download the module from http://www.messageops.com/downloads/MessageOps-Exchange-Module.zip

The normal EWS Managed API power shell script I've put a download of here the code looks like

$MailboxName = "user@domain.com"
##$folderItemType = "IPF.Note"
$rptCollection = @()

$dllpath = "C:\Program Files\Microsoft\Exchange\Web Services\1.1\Microsoft.Exchange.WebServices.dll"
[void][Reflection.Assembly]::LoadFile($dllpath)
$service = New-Object Microsoft.Exchange.WebServices.Data.ExchangeService([Microsoft.Exchange.WebServices.Data.ExchangeVersion]::Exchange2007_SP1)

$windowsIdentity = [System.Security.Principal.WindowsIdentity]::GetCurrent()
$sidbind = "LDAP://<SID=" + $windowsIdentity.user.Value.ToString() + ">"
$aceuser = [ADSI]$sidbind
$service.AutodiscoverUrl($aceuser.mail.ToString(),{$true})

$TotalItemCount = 0
$TotalItemSize = 0

"Checking : " + $MailboxName
$folderidcnt = new-object Microsoft.Exchange.WebServices.Data.FolderId([Microsoft.Exchange.WebServices.Data.WellKnownFolderName]::Root,$MailboxName)
$fvFolderView = New-Object Microsoft.Exchange.WebServices.Data.FolderView(10000)
$fvFolderView.Traversal = [Microsoft.Exchange.WebServices.Data.FolderTraversal]::Deep;
$psPropertySet = new-object Microsoft.Exchange.WebServices.Data.PropertySet([Microsoft.Exchange.WebServices.Data.BasePropertySet]::FirstClassProperties)
$PR_MESSAGE_SIZE_EXTENDED = new-object Microsoft.Exchange.WebServices.Data.ExtendedPropertyDefinition(3592,[Microsoft.Exchange.WebServices.Data.MapiPropertyType]::Long);
$PR_DELETED_MESSAGE_SIZE_EXTENDED = new-object Microsoft.Exchange.WebServices.Data.ExtendedPropertyDefinition(26267,[Microsoft.Exchange.WebServices.Data.MapiPropertyType]::Long);
$PR_DELETED_MSG_COUNT = new-object Microsoft.Exchange.WebServices.Data.ExtendedPropertyDefinition(26176,[Microsoft.Exchange.WebServices.Data.MapiPropertyType]::Integer);
$psPropertySet.Add($PR_MESSAGE_SIZE_EXTENDED);
$psPropertySet.Add($PR_DELETED_MESSAGE_SIZE_EXTENDED);
$psPropertySet.Add($PR_DELETED_MSG_COUNT);
$fvFolderView.PropertySet = $psPropertySet;
##$sfSearchFilter = new-object Microsoft.Exchange.WebServices.Data.SearchFilter+IsEqualTo([Microsoft.Exchange.WebServices.Data.FolderSchema]::FolderClass, $folderItemType)
##$fiResult = $Service.FindFolders($folderidcnt,$sfSearchFilter,$fvFolderView)
$fiResult = $Service.FindFolders($folderidcnt,$fvFolderView)
foreach($ffFolder in $fiResult.Folders){
$TotalItemCount = $TotalItemCount + $ffFolder.TotalCount;
$FolderSize = $null;
if ($ffFolder.TryGetProperty($PR_MESSAGE_SIZE_EXTENDED,[ref] $FolderSize))
{
$TotalItemSize = $TotalItemSize + [Int64]$FolderSize
}
$DeletedItemFolderSize = $null;
if ($ffFolder.TryGetProperty($PR_DELETED_MESSAGE_SIZE_EXTENDED, [ref] $DeletedItemFolderSize))
{
$TotalDeletedItemSize = $TotalDeletedItemSize + [Int64]$DeletedItemFolderSize
}
$DeletedMsgCount = $null;
if ($ffFolder.TryGetProperty($PR_DELETED_MSG_COUNT, [ref] $DeletedMsgCount))
{
$TotalDeletedItemCount = $TotalDeletedItemCount + [Int32]$DeletedMsgCount;
}
}
$rptobj = "" | select DisplayName,LegacyDN,TotalItemSize,TotalItemCount,TotalDeletedItemSize,TotalDeletedItemCount
$rptobj.DisplayName = $_.DisplayName
$rptobj.LegacyDN = $_.LegacyExchangeDN
$rptobj.TotalItemCount = $TotalItemCount
$rptobj.TotalItemSize = $TotalItemSize
$rptobj.TotalDeletedItemSize = $TotalDeletedItemSize
$rptobj.TotalDeletedItemCount = $TotalDeletedItemCount
$rptCollection += $rptobj

$rptCollection

Testing AutoDiscover and the OAB age using Powershell and the EWS Managed API

2010-12-28T09:39:00.009+11:00

One useful alternative to using the ubiquitous test-outlookwebservice cmdlet or https://www.testexchangeconnectivity.com/ for testing Autodiscover from powershell is to make use of the EWS Managed API and the verbose tracing feature this client side API offers. When you enable tracing on the ExchangeService object with the EWS Managed API you will then see the discovery process and the requests that are made to Autodiscover echo'd to the cmdline. This can add a new dimension to trying to diagnose an autodiscover problem that some of these other tools don't offer as you get to see both sides of the conversation.

A simple autodiscover test script for the EWS 1.1 Managed API looks like

$emailAddress = "Glen@domain.com"
$dllpath = "C:\Program Files\Microsoft\Exchange\Web Services\1.1\Microsoft.Exchange.WebServices.dll"
[void][Reflection.Assembly]::LoadFile($dllpath)
$service = New-Object Microsoft.Exchange.WebServices.Data.ExchangeService([Microsoft.Exchange.WebServices.Data.ExchangeVersion]::Exchange2007_SP1)
$service.traceenabled = $true
$service.Credentials = New-Object System.Net.NetworkCredential("username","password")
$service.AutodiscoverUrl($emailAddress,{$true})

The credential line is optional if you can use the currently logged on credentials just get rid of this line.

An example using the EWS Powershell module i posted about here we can reduce everything to one line

New-MessageOps.EWSProfile -id Glen@domain.com -EnableTracing $true

One other thing we've done with the module is to create specific cmdlets that make an autodiscover request outside of using the Managed API and the parse the result into a custom object so this information can then be easily displayed, exported or used in another application or test. One example where this can be useful is for seeing when the last time the Outlook Address Book was modified. In a normal powershell script you could do this using a HEAD command against the OABurl that shouldn't change much and get the lastmodified header. eg

$url = New-Object System.Uri("https://autodiscover-red001.mail.microsoftonline.com/OAB/4fa96c9b-8232-46a3-b329-d03662dc9484/oab.xml")
$htmlRequest = [System.Net.WebRequest]::Create($url)
$htmlRequest.Method = "HEAD"
$htmlRequest.Credentials = New-Object System.Net.NetworkCredential("user@domain","password")
$htmlRequest.timeout = 100000
$htmlRequest.ContentType = "text/xml"
$htmlRequest.Headers.Add("Translate", "F")
$htmlResponse = $htmlRequest.GetResponse()
if ($htmlResponse.StatusCode -eq "OK"){
$oabLastMod = $htmlResponse.GetResponseHeader("Last-Modified")
$rsResponseStream = $htmlResponse.GetResponseStream();
$oabLastMod
$htmlRequest = $null
}

With the module this can be made simpler and dynamic to run in most environments by making use of autodiscover eg a two-liner

$credential = get-credential
Get-MessageOps.OABSetting -id Glen@domaim.com -credential $credential -oaburl (Get-MessageOps.AutoDiscover -id Glen@domaim.com -credential $credential | where-object {$_.type -eq "EXPR" -band $_.oaburl -ne $null}).oaburl

If you want something that runs against BPOS there is a slightly different cmdlet which handles the different EntryPoints have a look at the sample post here. There are also different cmdlets for the different autodiscover entry points for liveEdu

To get a copy of the powershell module I've talked about this can be downloaded from http://www.messageops.com/downloads/MessageOps-Exchange-Module.zip

Using Remote Powershell and EWS on Office365

2010-12-22T20:38:00.007+11:00

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 -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell -credential $adminCredential -Authentication Basic -AllowRedirection
$importresults = Import-PSSession $rpRemotePowershell
}

$dllpath = "C:\Program Files\Microsoft\Exchange\Web Services\1.1\Microsoft.Exchange.WebServices.dll"
[void][Reflection.Assembly]::LoadFile($dllpath)
$service = New-Object Microsoft.Exchange.WebServices.Data.ExchangeService([Microsoft.Exchange.WebServices.Data.ExchangeVersion]::Exchange2010_SP1)

$windowsIdentity = [System.Security.Principal.WindowsIdentity]::GetCurrent()
$sidbind = "LDAP://<SID=" + $windowsIdentity.user.Value.ToString() + ">"
$aceuser = [ADSI]$sidbind
$service.Credentials = New-Object System.Net.NetworkCredential($username,$password)
$service.AutodiscoverUrl($UserName ,{$true})

$mbHash = @{ }

$tmValHash = @{ }
$tidx = 0
for($vsStartTime=[DateTime]::Parse([DateTime]::Now.ToString("yyyy-MM-dd 0:00"));$vsStartTime -lt [DateTime]::Parse([DateTime]::Now.ToString("yyyy-MM-dd 0:00")).AddDays(1);$vsStartTime = $vsStartTime.AddMinutes(30)){
$tmValHash.add($vsStartTime.ToString("HH:mm"),$tidx)
$tidx++
}

get-mailbox -ResultSize unlimited | foreach-object{
if ($mbHash.ContainsKey($_.WindowsEmailAddress.ToString()) -eq $false){
$mbHash.Add($_.WindowsEmailAddress.ToString(),$_.DisplayName)
}
}
$Attendeesbatch = [activator]::createinstance(([type]'System.Collections.Generic.List`1').makegenerictype([Microsoft.Exchange.WebServices.Data.AttendeeInfo]))

$StartTime = [DateTime]::Parse([DateTime]::Now.ToString("yyyy-MM-dd 0:00"))
$EndTime = $StartTime.AddDays(1)

$displayStartTime = [DateTime]::Parse([DateTime]::Now.ToString("yyyy-MM-dd 08:30"))
$displayEndTime = [DateTime]::Parse([DateTime]::Now.ToString("yyyy-MM-dd 17:30"))

$drDuration = new-object Microsoft.Exchange.WebServices.Data.TimeWindow($StartTime,$EndTime)
$AvailabilityOptions = new-object Microsoft.Exchange.WebServices.Data.AvailabilityOptions
$AvailabilityOptions.RequestedFreeBusyView = [Microsoft.Exchange.WebServices.Data.FreeBusyViewType]::DetailedMerged

$batchsize = 100
$bcount = 0
$bresult = @()
if ($mbHash.Count -ne 0){
$mbHash.GetEnumerator() | Sort Value | foreach-object {
if ($bcount -ne $batchsize){
$Attendee1 = new-object Microsoft.Exchange.WebServices.Data.AttendeeInfo($_.Key)
$Attendeesbatch.add($Attendee1)
$bcount++
}
else{
$availresponse = $service.GetUserAvailability($Attendeesbatch,$drDuration,[Microsoft.Exchange.WebServices.Data.AvailabilityData]::FreeBusy,$AvailabilityOptions)
foreach($avail in $availresponse.AttendeesAvailability.OverallResult){$bresult += $avail}
$Attendeesbatch = [activator]::createinstance(([type]'System.Collections.Generic.List`1').makegenerictype([Microsoft.Exchange.WebServices.Data.AttendeeInfo]))
$bcount = 0
$Attendee1 = new-object Microsoft.Exchange.WebServices.Data.AttendeeInfo($_.Key)
$Attendeesbatch.add($Attendee1)
$bcount++
}
}
}
$availresponse = $service.GetUserAvailability($Attendeesbatch,$drDuration,[Microsoft.Exchange.WebServices.Data.AvailabilityData]::FreeBusy,$AvailabilityOptions)
$usrIdx = 0
$frow = $true
foreach($res in $availresponse.AttendeesAvailability){
if ($frow -eq $true){
$fbBoard = $fbBoard + "<table><tr bgcolor=`"#95aedc`">" +"`r`n"
$fbBoard = $fbBoard + "<td align=`"center`" style=`"width=200;`" ><b>User</b></td>" +"`r`n"
for($stime = $displayStartTime;$stime -lt $displayEndTime;$stime = $stime.AddMinutes(30)){
$fbBoard = $fbBoard + "<td align=`"center`" style=`"width=50;`" ><b>" + $stime.ToString("HH:mm") + "</b></td>" +"`r`n"
}
$fbBoard = $fbBoard + "</tr>" + "`r`n"
$frow = $false
}
for($stime = $displayStartTime;$stime -lt $displayEndTime;$stime = $stime.AddMinutes(30)){
if ($stime -eq $displayStartTime){
$fbBoard = $fbBoard + "<td bgcolor=`"#CFECEC`"><b>" + $mbHash[$Attendeesbatch[$usrIdx].SmtpAddress] + "</b></td>" + "`r`n"
}
$title = "title="
if ($res.MergedFreeBusyStatus[$tmValHash[$stime.ToString("HH:mm")]] -ne $null){
$gdet = $false
$FbValu = $res.MergedFreeBusyStatus[$tmValHash[$stime.ToString("HH:mm")]]
switch($FbValu.ToString()){
"Free" {$bgColour = "bgcolor=`"#41A317`""}
"Tentative" {$bgColour = "bgcolor=`"#52F3FF`""
$gdet = $true
}
"Busy" {$bgColour = "bgcolor=`"#153E7E`""
$gdet = $true
}
"OOF" {$bgColour = "bgcolor=`"#4E387E`""
$gdet = $true
}
"NoData" {$bgColour = "bgcolor=`"#98AFC7`""}
"N/A" {$bgColour = "bgcolor=`"#98AFC7`""}
}
if ($gdet -eq $true){
if ($res.CalendarEvents.Count -ne 0){
for($ci=0;$ci -lt $res.CalendarEvents.Count;$ci++){
if ($res.CalendarEvents[$ci].StartTime -ge $stime -band $stime -le $res.CalendarEvents[$ci].EndTime){
if($res.CalendarEvents[$ci].Details.IsPrivate -eq $False){
$subject = ""
$location = ""
if ($res.CalendarEvents[$ci].Details.Subject -ne $null){
$subject = $res.CalendarEvents[$ci].Details.Subject.ToString()
}
if ($res.CalendarEvents[$ci].Details.Location -ne $null){
$location = $res.CalendarEvents[$ci].Details.Location.ToString()
}
$title = $title + "`"" + $subject + " " + $location + "`" "
}
}
}
}
}

}
else{
$bgColour = "bgcolor=`"#98AFC7`""
}
if($title -ne "title="){
$fbBoard = $fbBoard + "<td " + $bgColour + " " + $title + "></td>" + "`r`n"
}
else{
$fbBoard = $fbBoard + "<td " + $bgColour + "></td>" + "`r`n"
}

}
$fbBoard = $fbBoard + "</tr>" + "`r`n"
$usrIdx++
}
$fbBoard = $fbBoard + "</table>" + " "
$fbBoard | out-file "c:\fbboard.htm"

Exchange EWS Powershell module for the EWS Managed API

2010-12-15T21:40:00.007+11:00

One of the constant challenges in IT especially where scripting is involved is abstracting things that seem complicated and trying to make them easier. Because what we do a lot of the time are slightly different iterations of the same idea making simpler these repetitions can be a good thing. The EWS Managed API is a great tools for making it easier to access Exchange using powershell and other .NET languages. One of the freelance projects I've been working on over the past couple of months was firstly a powershell snapin just for BPOS that we have now turned this into a Powershell module that will work with any version of on premise Exchange (Starting with 2007) as well as BPOS and Office365. This module contains a bunch of growing cmdlets that help automate what would generally be a large number of lines of script within a normal EWS powershell script down to a one or two lines. The advantage of this was making it easy to reuse large chucks of code in simpler scripts to do more complicated tasks. Because it uses the EWS Managed API it exposes these objects and methods so you can mix and match between using the cmdlets and just pure Managed API code. Fortunately MessageOps who i wrote this for (and have a great array of other apps) have decided to provide it free to everyone to use. This is still a work in process so there are a few bugs here and there and the documentation is a little sparse but for the most it works pretty well you can download the module and some instructions and examples of how to use it from http://www.messageops.com/downloads/MessageOps-Exchange-Module.zip . As an example of what it can do here's how easy you can use this to create RSS feeds from Inbox or Public folder Items

Using the MessageOps Exchange PowerShell Module to generate a RSS feeds of a specific mailbox folder or public folder in Exchange.

The EWS Powershell module contains Out-MessageOps.MessagesToRSS cmdlet that will output a collection of EWS Messages Items to a RSS feed. To get the Collection of Items to Output to the RSS Feed you can use one either one of the following 3 cmdlets which will retrieve Items from a Mailbox or public folder.

Get-MessageOps.Messages : This is a generic retrieve and simple search cmdlets that returns messages and message details from a mailbox. Supports several switches to find messages based on Subject, Read Status, Attachments, etc. It returns information such as message recipients, sender information, message headers, message body, and attachment details.

Search-MessageOps.MailFolder : Allows you to search a mailbox folder based on a number or parameters such as StartDate, EndDate, Subject Contains, Body Contains.

Search-MessageOps.CrawlMailFolder : Allows more advanced searching of mailboxes. Allows you to use Regular Expressions in mailbox searches. Includes a built in Credit Card search function.

Which cmdlet you use depends on what your trying to achieve and how detailed the filtering you want to apply to the collection of messages you want in the RSS feed. Examples of using this with the different cmdlets

Before you start you need a EWSProfile object to create one use the following

$ewsProfile = New-MessageOps.EWSProfile -id “user@.domain.com”

Creating a feed of the last 20 items in the Inbox

$ItemCollection = Get-MessageOps.Messages -p $ewsprofile -fp "\\Inbox" -messagecount 20 -fulldetails $true

Out-MessageOps.MessagesToRSS -p $ewsprofile -FileName c:\outrss.xml -FeedTitle "Mailbox Feed" -Items $ItemCollection

Create a feed of the last 20 Items in Public Folder called company-emails

$ItemCollection = Get-MessageOps.Messages -p $ewsprofile -fp "\\publicfolderroot\company-emails" -messagecount 20 -fulldetails $true

Out-MessageOps.MessagesToRSS -p $ewsprofile -FileName c:\outrsspf.xml -FeedTitle "Public Folder Feed" -Items $ItemCollection -PublicFolder $true

Create a feed of just email from a specific address

$ItemCollection = Search-MessageOps.MailFolder -p $ewsprofile -fp \\inbox -from bob@domain.com -fulldetail $true -messagecount 20 -fulldetails $true

Out-MessageOps.MessagesToRSS -p $ewsprofile -FileName c:\outrs22s.xml -FeedTitle "Mailbox Feed" -Items $ItemCollection -PublicFolder $true

Using different options for unread email, attachments or use your own custom EWS Managed API searchfilter object can allow you to create any custom filter to suit most needs.

Simple Exchange Powershell Client V2

2010-12-01T13:51:00.005+11:00

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 Windows 7.0 and Powershell V2 the right click menu for the datagird will now work okay so I've added the ability to once you select the Items in the datagrid you can rightclick and then Delete, Copy or Move the selected Items to another folder (the deletes are soft deletes).

I've put a download of the new script here

Breadcrumb auditing in Exchange 2010 with EWS and Powershell

2010-11-16T13:18:00.004+11:00

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 the FAI collection of that particular folder.

To do this with EWS requires the use of some of the nice new features of EWS in Exchange 2010 such as the ability to access the associated Folder Items collection where these WunderBar Shortcuts are stored.

To access the associated folder Items collection in EWS you just need to change the Traversal type to Associated (note this wont work on 2007).

The Wunderbar Items themselves have a bunch of extended properties that contain information that is important to see what mailbox and folder this users was accessing. A full list of the shortcut properties can be found in the following Exchange protocol document http://msdn.microsoft.com/en-us/library/cc463899%28EXCHG.80%29.aspx. The Ones I've used in this script are

PidTagWlinkEntryId EntryID the ShortCut points to
PidTagWlinkStoreEntryId StoreEntryID the ShortCut points to
PidTagWlinkAddressBookEID Like the above but contains just the users info
PidTagWlinkFolderType Contains the GUID to let you know what type of folder it is
PidTagWlinkGroupName The name of the group

I've put this altogether is a powershell script that use the new EWS 1.1 Managed API beta (which allows you to access the associated folders collection). To use this script you need to customize the the following variable the output of this script is a html report.

$casserverName = "casservername"
$userName = "username"
$password = "password"
$domain = "domain"
$Mailboxname = "user@domain.com"
$fileName = "c:\report.htm"

I've put a download of this script here the script itself looks like.

$casserverName = "casservername"
$userName = "username"
$password = "password"
$domain = "domain"
$Mailboxname = "user@domain.com"
$fileName = "c:\report.htm"

$rptCollection = @()

function ReturnFolderType($guid){
switch($guid){
"0C78060000000000C000000000000046" { return "MailFolder"}
"0278060000000000C000000000000046" { return "Calendar" }
"0178060000000000C000000000000046" { return "Contacts" }
"0378060000000000C000000000000046" { return "Tasks"}
"0478060000000000C000000000000046" { return "Notes"}
"0878060000000000C000000000000046" { return "Journal"}
}

}

## Code From http://poshcode.org/624
## Create a compilation environment
$Provider=New-Object Microsoft.CSharp.CSharpCodeProvider
$Compiler=$Provider.CreateCompiler()
$Params=New-Object System.CodeDom.Compiler.CompilerParameters
$Params.GenerateExecutable=$False
$Params.GenerateInMemory=$True
$Params.IncludeDebugInformation=$False
$Params.ReferencedAssemblies.Add("System.DLL") | Out-Null

$TASource=@'
namespace Local.ToolkitExtensions.Net.CertificatePolicy{
public class TrustAll : System.Net.ICertificatePolicy {
public TrustAll() {
}
public bool CheckValidationResult(System.Net.ServicePoint sp,
System.Security.Cryptography.X509Certificates.X509Certificate cert,
System.Net.WebRequest req, int problem) {
return true;
}
}
}
'@
$TAResults=$Provider.CompileAssemblyFromSource($Params,$TASource)
$TAAssembly=$TAResults.CompiledAssembly

## We now create an instance of the TrustAll and attach it to the ServicePointManager
$TrustAll=$TAAssembly.CreateInstance("Local.ToolkitExtensions.Net.CertificatePolicy.TrustAll")
[System.Net.ServicePointManager]::CertificatePolicy=$TrustAll

## end code from http://poshcode.org/624

$dllpath = "C:\Program Files\Microsoft\Exchange\Web Services\1.1\Microsoft.Exchange.WebServices.dll"
[void][Reflection.Assembly]::LoadFile($dllpath)
$service = New-Object Microsoft.Exchange.WebServices.Data.ExchangeService([Microsoft.Exchange.WebServices.Data.ExchangeVersion]::Exchange2010)
$uri=[system.URI] ("https://" + $casserverName + "/ews/exchange.asmx")
$service.Url = $uri
$service.Credentials = New-Object System.Net.NetworkCredential($username,$password,$domain)
$rfFolderid = new-object Microsoft.Exchange.WebServices.Data.FolderId([Microsoft.Exchange.WebServices.Data.WellKnownFolderName]::Root,$MailboxName)
$fview = New-Object Microsoft.Exchange.WebServices.Data.FolderView(1000)
$Sfir = new-object Microsoft.Exchange.WebServices.Data.SearchFilter+IsEqualTo([Microsoft.Exchange.WebServices.Data.FolderSchema]::DisplayName, "Common Views")
$findfldResults = $Service.FindFolders($rfFolderid,$Sfir,$fview)
if ($findfldResults.Folders.Count -eq 1) {
$findfldResults.Folders[0].DisplayName
$PidTagWlinkEntryId = new-object Microsoft.Exchange.WebServices.Data.ExtendedPropertyDefinition(26700, [Microsoft.Exchange.WebServices.Data.MapiPropertyType]::Binary)
$PidTagWlinkStoreEntryId = new-object Microsoft.Exchange.WebServices.Data.ExtendedPropertyDefinition(26702, [Microsoft.Exchange.WebServices.Data.MapiPropertyType]::Binary)
$PidTagWlinkAddressBookEID = new-object Microsoft.Exchange.WebServices.Data.ExtendedPropertyDefinition(26708, [Microsoft.Exchange.WebServices.Data.MapiPropertyType]::Binary)
$PidTagWlinkFolderType = new-object Microsoft.Exchange.WebServices.Data.ExtendedPropertyDefinition(26703, [Microsoft.Exchange.WebServices.Data.MapiPropertyType]::Binary)
$PidTagWlinkGroupName = new-object Microsoft.Exchange.WebServices.Data.ExtendedPropertyDefinition(26705, [Microsoft.Exchange.WebServices.Data.MapiPropertyType]::String)
$Propset = new-object Microsoft.Exchange.WebServices.Data.PropertySet([Microsoft.Exchange.WebServices.Data.BasePropertySet]::FirstClassProperties)
$Propset.add($PidTagWlinkEntryId)
$Propset.add($PidTagWlinkStoreEntryId)
$Propset.add($PidTagWlinkAddressBookEID)
$Propset.add($PidTagWlinkFolderType)
$Propset.add($PidTagWlinkGroupName)
$iv = New-Object Microsoft.Exchange.WebServices.Data.ItemView(10000)
$iv.PropertySet = $Propset
$iv.Traversal = [Microsoft.Exchange.WebServices.Data.ItemTraversal]::Associated
$fiResults = $findfldResults.Folders[0].FindItems($iv)
foreach($itItem in $fiResults.Items){
$itItem.Subject
$WlinkStoreEntryId = $null
$rptobj = "" | select MailboxName,LinkName,GroupName,FolderType,DateCreated,LastModified
$lnLegDN = ""
if ($itItem.TryGetProperty($PidTagWlinkStoreEntryId,[ref]$WlinkStoreEntryId))
{

$leLegDnStart = 0
for ($ssArraynum = (([byte[]]$WlinkStoreEntryId).Length - 2); $ssArraynum -ne 0; $ssArraynum--)
{
if (([byte[]]$WlinkStoreEntryId)[$ssArraynum] -eq 0)
{
$leLegDnStart = $ssArraynum;
$lnLegDN = [System.Text.ASCIIEncoding]::ASCII.GetString(([byte[]]$WlinkStoreEntryId), $leLegDnStart + 1, (([byte[]]$WlinkStoreEntryId).Length - ($leLegDnStart + 2)));
$ssArraynum = 1;
}
}

}
else{
if ($itItem.TryGetProperty($PidTagWlinkAddressBookEID,[ref]$WlinkStoreEntryId))
{

$leLegDnStart = 0
$lnLegDN = ""
for ($ssArraynum = (([byte[]]$WlinkStoreEntryId).Length - 2); $ssArraynum -ne 0; $ssArraynum--)
{
if (([byte[]]$WlinkStoreEntryId)[$ssArraynum] -eq 0)
{
$leLegDnStart = $ssArraynum;
$lnLegDN = [System.Text.ASCIIEncoding]::ASCII.GetString(([byte[]]$WlinkStoreEntryId), $leLegDnStart + 1, (([byte[]]$WlinkStoreEntryId).Length - ($leLegDnStart + 2)));
$ssArraynum = 1;
}
}
}

}
if($lnLegDN -ne ""){
$ncCol = $service.ResolveName($lnLegDN)
$mbox = ""
foreach ($NameResolution in $ncCol)
{
$mbox = $NameResolution.Mailbox.Address
}
$FolderType = $null
if ($itItem.TryGetProperty($PidTagWlinkFolderType,[ref]$FolderType)){
$hexArr = $FolderType | ForEach-Object { $_.ToString("X2") }
$hexString = $hexArr -join ''
$rptobj.FolderType = ReturnFolderType($hexString)
$hexString

}
$GroupName = $null
if ($itItem.TryGetProperty($PidTagWlinkGroupName,[ref]$GroupName)){
$rptobj.GroupName = $GroupName
}
$rptobj.MailboxName = $mbox
$rptobj.LinkName = $itItem.Subject
$rptobj.DateCreated = $itItem.DateTimeCreated
$rptobj.LastModified = $itItem.LastModifiedTime
$rptCollection += $rptobj}
}
}
$rptCollection
$tableStyle = @"
<style>
BODY{background-color:white;}
TABLE{border-width: 1px;
border-style: solid;
border-color: black;
border-collapse: collapse;
}
TH{border-width: 1px;
padding: 10px;
border-style: solid;
border-color: black;
background-color:#66CCCC
}
TD{border-width: 1px;
padding: 2px;
border-style: solid;
border-color: black;
background-color:white
}
</style>
"@

$body = @"
<p style="font-size:25px;family:calibri;color:#ff9100">
$TableHeader
</p>
"@

$rptCollection | ConvertTo-HTML -head $tableStyle –body $body | Out-file $fileName

Making OWA canary's sing using cookies in your OWA scripts

2010-10-14T09:46:00.002+11:00

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 scripts is the MSXML2.ServerXMLHTTP object because this handles all the FBA cookies in OWA without the need to add lines of code. To Get the canary from the cookie collection once you have logged on it needs another request to the mailbox your going to access which if things go well means your cookie collection should now be populated and you can just parse the cookie with a few lines of script eg

req.Open "GET", "https://" & snServername & "/owa/" & Targetmailbox & "", False
req.SetOption 2, 13056
req.setRequestHeader "Content-Type", "application/x-www-form-urlencoded"
req.setRequestHeader "Content-Length", Len(xmlstr)
req.send szXml
reqhedrarry = split(req.GetAllResponseHeaders(), vbCrLf,-1,1)
for each ent in reqhedrarry
wscript.echo ent
Next
cookie = req.getResponseHeader("Set-Cookie")
if instr(cookie,"=") then
slen = instr(cookie,"=")+1
elen = instr(slen,cookie,"&")
canary = mid(cookie,slen,elen-slen)
wscript.echo "parsed canary : " & canary
end if

Once you have the canary you need to make sure you include it in your request for the junkemail script you need to modify the XML sent to look like

"<params><canary>" & canary & "</canary><fEnbl>1</fEnbl></params>"

And if everything is good your canary should sing to OWA to and achieve what it is your asking it to do. I've put a updated version of the junkemail script here

Modifying Outlook profiles in Outlook 2010 with VBS and Powershell

2010-10-11T08:56:00.009+11:00

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 are really good at is processing things quickly so if you wanted to for instance modify the cache mode setting within a profile in VBS you could use the following code to locate the default profile

Set WshShell = WScript.CreateObject("WScript.Shell")
strComputer = "."
HKEY_CURRENT_USER = &H80000001
Set oReg = GetObject("winmgmts:\\" & strComputer & "\root\default:StdRegProv")
keypath = "Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\"

profile = WshShell.RegRead("HKCU\"&keypath&"DefaultProfile")

Then enumerate all the keys under this profile to identify the key that has the cache mode value.

oReg.EnumKey HKEY_CURRENT_USER, (keypath & profile & "\"), arrSubKeys
For Each subkey In arrSubKeys
oReg.EnumValues HKEY_CURRENT_USER, (keypath & profile & "\" & subkey & "\"), arrSubValues
on error resume next
for each ValueKey in arrSubValues
if ValueKey = "00036601" then
oReg.GetBinaryValue HKEY_CURRENT_USER,(keypath & profile & "\" & subkey),"00036601",prProxyValRes
if not IsNull(prProxyValRes) then
if prProxyValRes(0) = "132" then
Wscript.echo "Cache Mode Enabled"
else
Wscript.echo "Cache Mode Disabled"
end if
end if
end if
next
on error goto 0
next

If you want to change the setting instead of just echoing it out the current setting then you would need to include something like

newValue1 = Array(&H84,&H05,&H00,&H00)
oReg.SetBinaryValue HKEY_CURRENT_USER,(keypath & profile & "\" & subkey),"00036601",newValue1

Note the hex value that you put in the second array element can vary depending on whether you want to enable the download public folder or shared folders check boxes.

If you think vbs is for mugs and you want to do this in powershell instead then you would need something like this

$RootKey = "Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles"
$pkProfileskey = [Microsoft.Win32.Registry]::CurrentUser.OpenSubKey($RootKey, $true)
$defProf = $pkProfileskey.GetValue("DefaultProfile")
$pkSubProfilekey = [Microsoft.Win32.Registry]::CurrentUser.OpenSubKey(($RootKey + "\\" + $defProf), $true)
foreach($Valuekey in $pkSubProfilekey.getSubKeyNames()){
$pkSubValueKey = [Microsoft.Win32.Registry]::CurrentUser.OpenSubKey(($RootKey + "\\" + $defProf + "\\" + $Valuekey ), $true)
foreach ($values in $pkSubValueKey.GetValueNames())
{
if ($values -eq "00036601"){
if(($pkSubValueKey.GetValue("00036601"))[0] -eq 132){
"Cache Mode Enabled"}
else{
"Cache Mode Disabled"
}
}
}

}

Recipient \ Email Address Policy GUI and browser for Exchange 2007 / 2010

2010-09-19T21:04:00.005+10:00

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

GatewayProxy - This contains the proxyaddresses that will be applied by the policy

msExchQueryFilter - This is the Opath filter for the policy

msExchPolicyOrder - This is the priority of the address policy

msExchPurportedSearchUI - This is a little bit of cheat as this property is used for the UI but it does contain a LDAP filter that can be used directly in ADSI so this is the property that I've used to search active directory for objects that the policy relates to.

GUID this is stored so it can be compared to the the msexchPoliciesIncluded property to work out if a policy has been applied to a specific object.

To work out if a policy has been applied to an object and also work out if policies have been disabled two properties are important. If polices have been disabled via the "Automatically update e-mail addresses based on e-mail address policy" then the msExchPoliciesExcluded will be set to 26491CFC-9E50-4857-861B-0CB8DF22B5D7.

Once a policy has been applied to an AD object the msexchpoliciesincluded will be updated with the GUID of the policy that has been applied. So when it comes time to enumerating applied polices using a script these a properties that you can put to use.

What happens when you hit the search button is the script does a ADSI query of active directory based on the LDAP filter and will return the objects that match this filter and tell you want policis has been applied to these objects. The radio button let you filter on all object, just the ones where the policy has been applied or disabled.

Some other things this script can be used for are backing up the current proxyaddress setting of accounts before you make any changes.

I've put a download of this script here the script itself looks like

[System.Reflection.Assembly]::LoadWithPartialName("System.Drawing")
[System.Reflection.Assembly]::LoadWithPartialName("System.windows.forms")
$form = new-object System.Windows.Forms.form
$raCollection = @()
$usrCollection = @()
$policyhash = @{ }
# $policyhash.Add("26491CFC-9E50-4857-861B-0CB8DF22B5D7","Disabled")

function UpdateListBoxPolicy(){
foreach ($prxobj in $raCollection){
if ($prxobj.PolicyName -eq $policyNameDrop.SelectedItem.ToString()){
$lbListView.clear()
$lbListView.Columns.Add("Property",80)
$lbListView.Columns.Add("Value",220)
$item1 = new-object System.Windows.Forms.ListViewItem("GUID")
$item1.SubItems.Add($prxobj.GUID.ToString())
$lbListView.items.add($item1)
$item1 = new-object System.Windows.Forms.ListViewItem("OpathFilter")
$item1.SubItems.Add($prxobj.OpathFilter.ToString())
$lbListView.items.add($item1)
$item1 = new-object System.Windows.Forms.ListViewItem("gatewayProxy")
if ($prxobj.gatewayProxy -is [system.array]){
$item1.SubItems.Add(([string]::join(";", $prxobj.gatewayProxy)))
}
else{
$item1.SubItems.Add($prxobj.gatewayProxy.ToString())
}
$lbListView.items.add($item1)
$item1 = new-object System.Windows.Forms.ListViewItem("LDAPFilter")
$item1.SubItems.Add($prxobj.LDAPFilter.ToString())
$lbListView.items.add($item1)
$item1 = new-object System.Windows.Forms.ListViewItem("msExchPolicyOrder")
$item1.SubItems.Add($prxobj.msExchPolicyOrder.ToString())
$lbListView.items.add($item1)
}
}
}

function ExportGrid(){
$exFileName = new-object System.Windows.Forms.saveFileDialog
$exFileName.DefaultExt = "csv"
$exFileName.Filter = "csv files (*.csv)|*.csv"
$exFileName.InitialDirectory = "c:\temp"
$exFileName.ShowHelp = $true
$exFileName.ShowDialog()
if ($exFileName.FileName -ne ""){
$logfile = new-object IO.StreamWriter($exFileName.FileName,$true)
$logfile.WriteLine("DisplayName,PrimaryEmailAdrress,ProxyAddresses,RecipientPolicy")
foreach($row in $msTable.Rows){
$logfile.WriteLine("`"" + $row[0].ToString() + "`"," + $row[1].ToString() + "," + $row[2].ToString() + "," + $row[3].ToString())
}
$logfile.Close()
}

}

function SearchforObjects(){
$policyobject = ""
foreach ($prxobj in $raCollection){
if ($prxobj.PolicyName -eq $policyNameDrop.SelectedItem.ToString()){
$policyobject = $prxobj.LDAPFilter.ToString()
}
}
$msTable.clear()
$dfDefaultRootPath = "LDAP://" + $root.DefaultNamingContext.tostring()
$dfRoot = [ADSI]$dfDefaultRootPath
$gfGALQueryFilter = $policyobject
$dfsearcher = new-object System.DirectoryServices.DirectorySearcher($dfRoot)
$dfsearcher.Filter = $gfGALQueryFilter
$dfsearcher.PageSize = 1000
$dfsearcher.PropertiesToLoad.Add("msexchPoliciesIncluded")
$dfsearcher.PropertiesToLoad.Add("proxyAddresses")
$dfsearcher.PropertiesToLoad.Add("mail")
$dfsearcher.PropertiesToLoad.Add("displayName")
$dfsearcher.PropertiesToLoad.Add("distinguishedName")
$dfsearcher.PropertiesToLoad.Add("msExchPoliciesExcluded")
$srSearchResult = $dfsearcher.FindAll()
foreach ($emResult in $srSearchResult) {
$emProps = $emResult.Properties
$DisplayName = ""
$PrimaryEmailAdrress = ""
$ProxyAddresses = ""
$RecipientPolicy = ""
if($emProps.msexchpoliciesincluded -ne $null){
$polarray = $emProps.msexchpoliciesincluded[0].Split(",")
foreach($pol in $polarray){
$pol = $pol.ToString().Replace("{","").Replace("}","")
if ($policyhash.ContainsKey($pol.ToString())){
$RecipientPolicy = $policyhash[$pol.ToString()]

}
}
}
if ($emProps.msexchpoliciesexcluded -ne $null){
foreach($pol in $emProps.msexchpoliciesexcluded){
$pol = $pol.ToString().Replace("{","").Replace("}","")
$pol.ToString()
if ($pol.ToString() -eq "26491CFC-9E50-4857-861B-0CB8DF22B5D7"){
$RecipientPolicy = "Disabled"

}
}
}
$DisplayName = $emResult.Properties["displayname"][0]
$PrimaryEmailAdrress = $emResult.Properties["mail"][0]
$ProxyAddresses = [string]::join(";",$emProps.proxyaddresses)
if($rbinc.Checked -eq $true){
$msTable.rows.add($DisplayName,$PrimaryEmailAdrress,$ProxyAddresses,$RecipientPolicy)
}
if($rbinc1.Checked -eq $true -band $RecipientPolicy -eq $policyNameDrop.SelectedItem.ToString()){
$msTable.rows.add($DisplayName,$PrimaryEmailAdrress,$ProxyAddresses,$RecipientPolicy)
}
if($rbinc2.Checked -eq $true -band $RecipientPolicy -eq "Disabled"){
$msTable.rows.add($DisplayName,$PrimaryEmailAdrress,$ProxyAddresses,$RecipientPolicy)
}

}
$dgDataGrid.Datasource = $msTable
}

$root = [ADSI]'LDAP://RootDSE'
$cfConfigRootpath = "LDAP://" + $root.ConfigurationNamingContext.tostring()
$configRoot = [ADSI]$cfConfigRootpath
$searcher = new-object System.DirectoryServices.DirectorySearcher($configRoot)
$searcher.Filter = "(objectClass=msexchRecipientPolicy)"
$searchresults = $searcher.FindAll()
foreach ($searchresult in $searchresults){
$plcobj = "" | select PolicyName,GUID,gatewayProxy,OpathFilter,LDAPFilter,msExchPolicyOrder
$Policyobject = New-Object System.DirectoryServices.directoryentry
$Policyobject = $searchresult.GetDirectoryEntry()
$plcobj.PolicyName = $Policyobject.Name.Value
$plcobj.GUID = [GUID]$Policyobject.ObjectGUID.Value
$plcobj.OpathFilter = $Policyobject.msExchQueryFilter.Value
$plcobj.gatewayProxy = $Policyobject.GatewayProxy.Value
$plcobj.msExchPolicyOrder = $Policyobject.msExchPolicyOrder.Value
foreach ($val in $Policyobject.msExchPurportedSearchUI){
if($val -match "Microsoft.PropertyWell_QueryString="){
$plcobj.LDAPFilter = $val.substring(35,($val.length-35))
}
}
$raCollection += $plcobj
$policyhash.add($plcobj.GUID.ToString(),$plcobj.PolicyName)
}

$msTable = New-Object System.Data.DataTable
$msTable.TableName = "ProxyAddress"
$msTable.Columns.Add("DisplayName")
$msTable.Columns.Add("PrimaryEmailAdrress")
$msTable.Columns.Add("ProxyAddresses")
$msTable.Columns.Add("RecipientPolicy")

$PolicylableBox = new-object System.Windows.Forms.Label
$PolicylableBox.Location = new-object System.Drawing.Size(10,20)
$PolicylableBox.size = new-object System.Drawing.Size(120,20)
$PolicylableBox.Text = "Select Policy Name : "
$form.controls.Add($PolicylableBox)

# Add Policy Drop Down
$policyNameDrop = new-object System.Windows.Forms.ComboBox
$policyNameDrop.Location = new-object System.Drawing.Size(130,20)
$policyNameDrop.Size = new-object System.Drawing.Size(200,30)
$policyNameDrop.Enabled = $true
foreach ($prxobj in $raCollection){
$policyNameDrop.Items.Add($prxobj.PolicyName)
}
$policyNameDrop.Add_SelectedValueChanged({UpdateListBoxPolicy})
$form.Controls.Add($policyNameDrop)

$policySettingslableBox = new-object System.Windows.Forms.Label
$policySettingslableBox.Location = new-object System.Drawing.Size(340,20)
$policySettingslableBox.size = new-object System.Drawing.Size(80,20)
$policySettingslableBox.Text = "Policy Settings"
$form.controls.Add($policySettingslableBox)

$lbListView = new-object System.Windows.Forms.ListView
$lbListView.Location = new-object System.Drawing.Size(450,20)
$lbListView.size = new-object System.Drawing.Size(350,100)
$lbListView.LabelEdit = $True
$lbListView.AllowColumnReorder = $True
$lbListView.CheckBoxes = $False
$lbListView.FullRowSelect = $True
$lbListView.GridLines = $True
$lbListView.View = "Details"
$lbListView.Sorting = "Ascending"
$form.controls.Add($lbListView)

# Add RadioButtons
$rbinc = new-object System.Windows.Forms.RadioButton
$rbinc.Location = new-object System.Drawing.Size(150,50)
$rbinc.size = new-object System.Drawing.Size(220,17)
$rbinc.Checked = $true
$rbinc.Text = "All objects Policy Query matches"
$form.Controls.Add($rbinc)

$rbinc1 = new-object System.Windows.Forms.RadioButton
$rbinc1.Location = new-object System.Drawing.Size(150,70)
$rbinc1.size = new-object System.Drawing.Size(220,17)
$rbinc1.Checked = $false
$rbinc1.Text = "Only objects with Apply policy enabled"
$form.Controls.Add($rbinc1)

$rbinc2 = new-object System.Windows.Forms.RadioButton
$rbinc2.Location = new-object System.Drawing.Size(150,90)
$rbinc2.size = new-object System.Drawing.Size(220,17)
$rbinc2.Checked = $false
$rbinc2.Text = "Only objects with Apply policy disabled"
$form.Controls.Add($rbinc2)

$exButton1 = new-object System.Windows.Forms.Button
$exButton1.Location = new-object System.Drawing.Size(10,70)
$exButton1.Size = new-object System.Drawing.Size(125,20)
$exButton1.Text = "Search"
$exButton1.Add_Click({SearchforObjects})
$form.Controls.Add($exButton1)

# Add Export Grid Button

$exButton2 = new-object System.Windows.Forms.Button
$exButton2.Location = new-object System.Drawing.Size(10,760)
$exButton2.Size = new-object System.Drawing.Size(125,20)
$exButton2.Text = "Export Grid"
$exButton2.Add_Click({ExportGrid})
$form.Controls.Add($exButton2)

# Add DataGrid View

$dgDataGrid = new-object System.windows.forms.DataGridView
$dgDataGrid.Location = new-object System.Drawing.Size(10,145)
$dgDataGrid.size = new-object System.Drawing.Size(1000,600)
$dgDataGrid.AutoSizeRowsMode = "AllHeaders"
$form.Controls.Add($dgDataGrid)

$form.Text = "Address Policy GUI"
$form.size = new-object System.Drawing.Size(1200,750)
$form.autoscroll = $true
$form.Add_Shown({$form.Activate()})
$form.ShowDialog()

Cleaning up and Reporting on Items based on the Subject on Exchange using a EWS search with Powershell

2010-09-10T11:23:00.003+10:00

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 date so it makes sense to make your query more efficient by only searching for items that where received in the last 7 days. So a search filter for 2007 would look like

$Sfir = new-object Microsoft.Exchange.WebServices.Data.SearchFilter+IsEqualTo([Microsoft.Exchange.WebServices.Data.EmailMessageSchema]::Subject, $subjecttoSearch)
$Sflt = new-object Microsoft.Exchange.WebServices.Data.SearchFilter+IsGreaterThan([Microsoft.Exchange.WebServices.Data.ItemSchema]::DateTimeReceived, $MailDate)
$sfCollection = new-object Microsoft.Exchange.WebServices.Data.SearchFilter+SearchFilterCollection([Microsoft.Exchange.WebServices.Data.LogicalOperator]::And);
$sfCollection.add($Sfir)

The AQS query for the same thing would look like AQSQuery = "Received:this week AND subject:`"" + $subjecttoSearch + "`"" . There is one very important catch with the AQS query is that it will do a exact phrase match but not a exact subject match. So for example if you where trying to match the phrase "here you have" in the subject it would also match "here you have a example of" there are different operators that you can use in AQS but not one that i could find that would do a exact property match(I anybody finds an AQS query that works (emphasis on works rather then should work based on the documentation) please let me know). To get around this and also as a double check before you delete anything a simple logic if statement can be used in your code.

When it comes to deleting Items in the EWS Managed API you can use the Delete method of the Item object which would basically call a deleteItem operation each time you called this method or a faster method is create an array of itemid's that you would like deleted and then use the batch deleteItems method which is the method I've used.

The scripts are setup to use Delegation but if you want to use impersonation instead just add the following line

$service.ImpersonatedUserId = New-Object Microsoft.Exchange.WebServices.Data.ImpersonatedUserId([Microsoft.Exchange.WebServices.Data.ConnectingIdType]::SmtpAddress, $MailboxName)

Because searching like this is not only usefully for deleting Items but for also reporting on things I've created a reporting version of the scripts as well that just emails a html report of a what it finds within a mailbox and includes the transport headers of the messages in question. The script I've created does a deep traversal to get the folderid details and then a single finditems on each folder the 2007 version using searchfilters and the 2010 version use AQS.

The delete scripts do a SoftDelete meaning the item goes into the dumpster of the folder it was deleted from (you could make this a hard delete).

Before using these script you need to customize the following variable with the subject you want to search for the example I've used is I hate spam

$subjecttoSearch = "I hate Spam"

You also need to set the mailbox name to run against or change it to $arg[0] and run the script with a cmdline argument. In the reporting script the To,From and SMTP server needs to be set.

I've put a download of all 4 scripts here the 2007 delete version looks like.

$MailboxName = "user@mailbox.com"

$subjecttoSearch = "I hate Spam"
$MailDate = [system.DateTime]::Now.AddDays(-7)

$dllpath = "C:\Program Files\Microsoft\Exchange\Web Services\1.0\Microsoft.Exchange.WebServices.dll"
[void][Reflection.Assembly]::LoadFile($dllpath)

$deleteMode = [Microsoft.Exchange.WebServices.Data.DeleteMode]::SoftDelete
$aptcancelMode = [Microsoft.Exchange.WebServices.Data.SendCancellationsMode]::SendToNone
$taskmode = [Microsoft.Exchange.WebServices.Data.AffectedTaskOccurrence]::AllOccurrences

$service = New-Object Microsoft.Exchange.WebServices.Data.ExchangeService([Microsoft.Exchange.WebServices.Data.ExchangeVersion]::Exchange2007_SP1)

$windowsIdentity = [System.Security.Principal.WindowsIdentity]::GetCurrent()
$sidbind = "LDAP://<SID=" + $windowsIdentity.user.Value.ToString() + ">"
$aceuser = [ADSI]$sidbind

$service.AutodiscoverUrl($aceuser.mail.ToString())

$rfRootFolderID = new-object Microsoft.Exchange.WebServices.Data.FolderId([Microsoft.Exchange.WebServices.Data.WellKnownFolderName]::MsgFolderRoot,$MailboxName)
$rfRootFolder = [Microsoft.Exchange.WebServices.Data.Folder]::Bind($service,$rfRootFolderID)
$fvFolderView = New-Object Microsoft.Exchange.WebServices.Data.FolderView(10000);
$fvFolderView.Traversal = [Microsoft.Exchange.WebServices.Data.FolderTraversal]::Deep
$fvFolderView.PropertySet = $Propset
$ffResponse = $rfRootFolder.FindFolders($fvFolderView);

foreach ($ffFolder in $ffResponse.Folders){
"Checking " + $ffFolder.DisplayName
$Sfir = new-object Microsoft.Exchange.WebServices.Data.SearchFilter+IsEqualTo([Microsoft.Exchange.WebServices.Data.EmailMessageSchema]::Subject, $subjecttoSearch)
$Sflt = new-object Microsoft.Exchange.WebServices.Data.SearchFilter+IsGreaterThan([Microsoft.Exchange.WebServices.Data.ItemSchema]::DateTimeReceived, $MailDate)
$sfCollection = new-object Microsoft.Exchange.WebServices.Data.SearchFilter+SearchFilterCollection([Microsoft.Exchange.WebServices.Data.LogicalOperator]::And);
$sfCollection.add($Sfir)
$sfCollection.add($Sflt)
$ivview = new-object Microsoft.Exchange.WebServices.Data.ItemView(20000)
$frFolderResult = $ffFolder.FindItems($sfCollection,$ivview)
$Itembatch = [activator]::createinstance(([type]'System.Collections.Generic.List`1').makegenerictype([Microsoft.Exchange.WebServices.Data.ItemId]))
foreach ($miMailItems in $frFolderResult.Items){
if ($miMailItems.Subject -eq $subjecttoSearch){
"****** Found" + $miMailItems.Subject
$Itembatch.add($miMailItems.Id)
}
}
"Number of Items found in folder : " + $Itembatch.Count
if($Itembatch.Count -ne 0){
"Deleting " + $Itembatch.Count + " Items"
$DelResponse = $service.DeleteItems($Itembatch,$deleteMode,$aptcancelMode,$taskmode)
foreach ($dr in $DelResponse) {
$dr.Result
}
}

}

Getting the Folder Size of a folder using EWS

2010-09-09T22:13:00.004+10:00

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 Get-MailboxFolderStatistics eg if you wanted to show the size of ever folder in a mailbox you can use the following script I've put a download of this here

$MailboxName = "user@domain.com"

$dllpath = "C:\Program Files\Microsoft\Exchange\Web Services\1.0\Microsoft.Exchange.WebServices.dll"
[void][Reflection.Assembly]::LoadFile($dllpath)

$service = New-Object Microsoft.Exchange.WebServices.Data.ExchangeService([Microsoft.Exchange.WebServices.Data.ExchangeVersion]::Exchange2007_SP1)

$windowsIdentity = [System.Security.Principal.WindowsIdentity]::GetCurrent()
$sidbind = "LDAP://"
$aceuser = [ADSI]$sidbind

$service.AutodiscoverUrl($aceuser.mail.ToString())

$rfRootFolderID = new-object Microsoft.Exchange.WebServices.Data.FolderId([Microsoft.Exchange.WebServices.Data.WellKnownFolderName]::MsgFolderRoot,$MailboxName)
$rfRootFolder = [Microsoft.Exchange.WebServices.Data.Folder]::Bind($service,$rfRootFolderID)
$fvFolderView = New-Object Microsoft.Exchange.WebServices.Data.FolderView(10000);
$PR_MESSAGE_SIZE_EXTENDED = new-object Microsoft.Exchange.WebServices.Data.ExtendedPropertyDefinition(3592, [Microsoft.Exchange.WebServices.Data.MapiPropertyType]::Integer)
$Propset = new-object Microsoft.Exchange.WebServices.Data.PropertySet([Microsoft.Exchange.WebServices.Data.BasePropertySet]::FirstClassProperties)
$Propset.add($PR_MESSAGE_SIZE_EXTENDED)
$fvFolderView.Traversal = [Microsoft.Exchange.WebServices.Data.FolderTraversal]::Deep
$fvFolderView.PropertySet = $Propset
$ffResponse = $rfRootFolder.FindFolders($fvFolderView);

foreach ($ffFolder in $ffResponse.Folders){
$fldObject = "" | select FolderName,FolderSize
$folderSize = $null
$ptProptest2 = $ffFolder.TryGetProperty($PR_MESSAGE_SIZE_EXTENDED, [ref]$folderSize)
$fldObject.FolderName = $ffFolder.DisplayName
$fldObject.FolderSize = [INT]$folderSize
$ReportingCollection += $fldObject
}
$ReportingCollection

Reporting on deleted retained items with EWS on Exchange 2007

2010-08-30T20:22:00.003+10:00

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. While this is a little disappointing what you can do is still useful and worth putting to use. The following script makes use of this by going through ever folder in a mailbox and use the following properties to determine if more investigation is needed.

ptagDeletedOnFlag which details when a Item was deleted

PR_DELETED_MSG_COUNT which is the count of the delete Items with the dumpster view.

PR_DELETED_MESSAGE_SIZE_EXTENDED is the size of the Items in the dumpster view.

Using these properties when going through the folder hierarchy you can tell which folders currently have items of interest in the deleted Items view and is something that you should run a softdeleted traversal on. That's it the rest of the script uses some objects and html to email a report of the mailbox you run it against.

To use this script you need to have delegate access to the mailbox your reporting on or configure the script to use EWS Impersonation. The script has a few variables that need to be configured

$MailboxName = "mailbox@domain.com" Mailbox you want to audit

and

$sendAlertTo = "sendto@domain.com"
$sendAlertFrom = "report@domain.com"
$SMTPServer = "smtpservername"

I've put a download of this script here

$MailboxName = "mailbox@domain.com"

$sendAlertTo = "sendto@domain.com"
$sendAlertFrom = "report@domain.com"
$SMTPServer = "smtpservername"

$dllpath = "C:\Program Files\Microsoft\Exchange\Web Services\1.0\Microsoft.Exchange.WebServices.dll"
[void][Reflection.Assembly]::LoadFile($dllpath)

$service = New-Object Microsoft.Exchange.WebServices.Data.ExchangeService([Microsoft.Exchange.WebServices.Data.ExchangeVersion]::Exchange2007_SP1)

$windowsIdentity = [System.Security.Principal.WindowsIdentity]::GetCurrent()
$sidbind = "LDAP://<SID=" + $windowsIdentity.user.Value.ToString() + ">"
$aceuser = [ADSI]$sidbind

$service.AutodiscoverUrl($aceuser.mail.ToString())

$rptCollection = @()

## Define Extended Properties

$PR_DELETED_ON = new-object Microsoft.Exchange.WebServices.Data.ExtendedPropertyDefinition(26255, [Microsoft.Exchange.WebServices.Data.MapiPropertyType]::SystemTime)
$PR_DELETED_MSG_COUNT = new-object Microsoft.Exchange.WebServices.Data.ExtendedPropertyDefinition(26176, [Microsoft.Exchange.WebServices.Data.MapiPropertyType]::Integer)
$PR_DELETED_MESSAGE_SIZE_EXTENDED = new-object Microsoft.Exchange.WebServices.Data.ExtendedPropertyDefinition(26267, [Microsoft.Exchange.WebServices.Data.MapiPropertyType]::Long)
$PR_DELETED_FOLDER_COUNT = new-object Microsoft.Exchange.WebServices.Data.ExtendedPropertyDefinition(26177, [Microsoft.Exchange.WebServices.Data.MapiPropertyType]::Integer)
$PR_Sender_Name = new-object Microsoft.Exchange.WebServices.Data.ExtendedPropertyDefinition(26177, [Microsoft.Exchange.WebServices.Data.MapiPropertyType]::String)

## End Define Extended Properties
## Define Property Sets
## Folder Set

$fpsFolderPropertySet = new-object Microsoft.Exchange.WebServices.Data.PropertySet([Microsoft.Exchange.WebServices.Data.BasePropertySet]::FirstClassProperties)
$fpsFolderPropertySet.add($PR_DELETED_ON)
$fpsFolderPropertySet.add($PR_DELETED_MSG_COUNT)
$fpsFolderPropertySet.add($PR_DELETED_MESSAGE_SIZE_EXTENDED)
$fpsFolderPropertySet.add($PR_DELETED_FOLDER_COUNT)

## Item Set

$ipsItemPropertySet = new-object Microsoft.Exchange.WebServices.Data.PropertySet([Microsoft.Exchange.WebServices.Data.BasePropertySet]::IdOnly)
$ipsItemPropertySet.add($PR_DELETED_ON)
$ipsItemPropertySet.Add([Microsoft.Exchange.WebServices.Data.ItemSchema]::Size)
$ipsItemPropertySet.Add([Microsoft.Exchange.WebServices.Data.ItemSchema]::Subject)
$ipsItemPropertySet.Add([Microsoft.Exchange.WebServices.Data.EmailMessageSchema]::From)
# End Set

$rfRootFolderID = new-object Microsoft.Exchange.WebServices.Data.FolderId([Microsoft.Exchange.WebServices.Data.WellKnownFolderName]::MsgFolderRoot,$MailboxName)
$rfRootFolder = [Microsoft.Exchange.WebServices.Data.Folder]::Bind($service,$rfRootFolderID)
$fvFolderView = New-Object Microsoft.Exchange.WebServices.Data.FolderView(10000);
$fvFolderView.Traversal = [Microsoft.Exchange.WebServices.Data.FolderTraversal]::Deep
$fvFolderView.PropertySet = $fpsFolderPropertySet
# $service.traceenabled = $true
$ffResponse = $rfRootFolder.FindFolders($fvFolderView);
foreach ($ffFolder in $ffResponse.Folders){
$dcDeleteItemCount = $null
$fptProptest = $ffFolder.TryGetProperty($PR_DELETED_MSG_COUNT, [ref]$dcDeleteItemCount)
if($fptProptest){
if ($dcDeleteItemCount -ne 0){
$ffFolder.DisplayName + " - Number Items Deleted :" + $dcDeleteItemCount
$bcBatchCount = 0;
$bcBatchSize = 1000
$ivItemView = new-object Microsoft.Exchange.WebServices.Data.ItemView($bcBatchSize, $bcBatchCount)
$ivItemView.Traversal = [Microsoft.Exchange.WebServices.Data.ItemTraversal]::SoftDeleted
$ivItemView.PropertySet = $ipsItemPropertySet
$service.traceenabled = $false
while (($fiFindItems = $ffFolder.FindItems($ivItemView)).Items.Count -gt 0)
{
foreach ($item in $fiFindItems.Items)
{
$lnum ++
write-progress "Processing message" $lnum
$delon = $null
$ptProptest = $item.TryGetProperty($PR_DELETED_ON, [ref]$delon)
$Itemobj = "" | select Type,DeletedOn,From,Subject,Size
$Itemobj.DeletedOn = $delon
$Itemobj.From = $item.From.Name
$Itemobj.Subject = $item.Subject
$Itemobj.Size = $item.Size
$Itemobj.Type = "Item"
$rptCollection += $Itemobj
}
$bcBatchCount += $fiFindItems.Items.Count
$ivItemView = new-object Microsoft.Exchange.WebServices.Data.ItemView($bcBatchSize, $bcBatchCount)
$ivItemView.Traversal = [Microsoft.Exchange.WebServices.Data.ItemTraversal]::SoftDeleted
$ivItemView.PropertySet = $ipsItemPropertySet
}
}
}
$dcDeletedFolderCount = $null
$fptProptest = $ffFolder.TryGetProperty($PR_DELETED_FOLDER_COUNT, [ref]$dcDeletedFolderCount)
if($fptProptest){
if ($dcDeletedFolderCount -ne 0){
$ffFolder.DisplayName + " - Number folders Deleted :" + $dcDeletedFolderCount
$fvFolderView1 = New-Object Microsoft.Exchange.WebServices.Data.FolderView(10000);
$fvFolderView1.Traversal = [Microsoft.Exchange.WebServices.Data.FolderTraversal]::SoftDeleted
$fvFolderView1.PropertySet = $fpsFolderPropertySet
$ffResponse2 = $ffFolder.FindFolders($fvFolderView1)

foreach ($ffDelFolder in $ffResponse2.Folders){
$dcDeletedSize = $null
$fptProptest = $ffDelFolder.TryGetProperty($PR_DELETED_MESSAGE_SIZE_EXTENDED, [ref]$dcDeletedSize)
$Deletedon = $null
$ptProptest = $ffDelFolder.TryGetProperty($PR_DELETED_ON, [ref]$Deletedon)
$Itemobj = "" | select Type,DeletedOn,From,Subject,Size
$Itemobj.DeletedOn = $Deletedon
$Itemobj.Subject = $ffDelFolder.DisplayName
$Itemobj.Size = $dcDeletedSize
$Itemobj.Type = "Folder"
$rptCollection += $Itemobj

}
}
}

}

$tableStyle = @"
<style>
BODY{background-color:white;}
TABLE{border-width: 1px;
border-style: solid;
border-color: black;
border-collapse: collapse;
}
TH{border-width: 1px;
padding: 10px;
border-style: solid;
border-color: black;
background-color:#66CCCC
}
TD{border-width: 1px;
padding: 2px;
border-style: solid;
border-color: black;
background-color:white
}
</style>
"@

$body = @"
<p style="font-size:25px;family:calibri;color:#ff9100">
$TableHeader
</p>
"@

$SmtpClient = new-object system.net.mail.smtpClient
$SmtpClient.host = $SMTPServer
$MailMessage = new-object System.Net.Mail.MailMessage
$MailMessage.To.Add($sendAlertTo)
$MailMessage.From = $sendAlertFrom
$MailMessage.Subject = "Dumpster Report for " + $MailboxName
$MailMessage.IsBodyHtml = $TRUE
$MailMessage.body = $rptCollection | ConvertTo-HTML -head $tableStyle –body $body
$SMTPClient.Send($MailMessage)