Update: Estimating the size of an Exchange (online) Archive

Hi all!

A couple of years back, I created a (very basic) script to help estimating the size of an Exchange Archive by looking at the age of a message and comparing it to time periode you envision to use in the the retention/archive policy. Originally, I believe I had posted the script on my personal OneDrive, but the file since seems to have gone missing.

After a few requests, I decided to upload the file to Github for a few reasons:

  1. You can download it again.
  2. People can contribute to improve the script. As I mentioned earlier, it was a very basic script and not super efficient. Unfortunately, I lack the time to spend much time on it, but that doesn’t mean others can’t and help the community by doing so.

You can find the script here, now. (https://github.com/mvanhorenbeeck/EstimateExchangeArchiveSize)

Please note the script is provided as-is with no warranties. I suggest you test the code before trying it in production as I had to pull this source file from an old repository and it may or may not be the same version as I posted originally.

Good luck!

-Michael

Blog PowerShell

Summary of announcements for Hybrid Exchange @ Ignite

Today, Microsoft has made some quite big (and important!) announcements around the work they are doing to improve the experience for Hybrid Exchange customers. These announcements were all “dropped” during session BRK3155 (How to thrive as an organization in Exchange Online), and – for most – came quite unexpected. If there’s one piece of feedback I would give Microsoft, it would be to better align the title of such sessions to their content!

This being said, with everything that was mentioned, I figured it would be a good idea to summarize it all (without going into too much detail) in a short write-up. As time permits, I will go into more detail on each of these items later this week.

If you’re not interested in more information about each feature, and just care about the headlines, here’s what was announced:

  1. Cross-premises delegation permissions (e.g. Send-on-Behalf, Calendar permissions, …) will be fully supported. Expected timeframe is Q1/2018. Fix for this is already rolling out in the service.
  2. Microsoft is working to solve the Automapping problem in hybrid deployments. Fix is being rolled out and (Private) Preview starting soon.
  3. In the future you will be able to remove the last Exchange server after having moved all mailboxes to the cloud. Plumbing for this has already started and expected to be released in the coming 12-18 months. Though with Microsoft, you never know!
  4. Microsoft is working on allowing you to move mailboxes cross-tenant. The capability to do so has been demoed in the session, but more work is needed to offer a more holistic approach. This is important, because cross-tenant migrations entail more than just moving mailboxes. There’s mail routing, there’s other workloads and – perhaps most importantly – there’s the need for proper governance. None of which was discussed (or showed) at this time. The timeline for this capability is the coming 12-18 months. This means that 3rd-party vendors (like QuadroTech, BinaryTree) are still very much needed to facilitate such scenarios today. Microsoft isn’t just there yet. Future will tell how useful Microsoft’s capability will be and how 3rd-party vendors will adopt to enhance the experience even further.
  5. To drive down complexity for hybrid deployments, a new hybrid solution backbone is being developed. This backbone which uses a “connector” will no longer require inbound connections (no more firewall ports to be opened) and is part of the solution for earlier new features. Think of the connector like an Azure App Proxy which uses the same principle (I wouldn’t be surprised that it’s a modified version thereof). Exchange Online will then, instead of using the “Public” Internet, route traffic to the connector through which it then makes its way to on-prem (outbound TCP443 connection). Timeline is in the next 6 months or so.
  6. Send-As permissions are a bit harder to solve. This will require item 4 to be solved (which will probably require item 5 to be done too). However, once that is done, this scenario will be covered as well. Today, however, the workaround is to explicitly define permissions in both EXO/On-Prem (it works!).

Other news – not necessarily hybrid related – that was announced in this session:

  1. Client Access Rules are coming to Exchange Online. These rules allow you to control how someone can access Exchange Online.
  2. new On Send events allow you to create add-ins which can fire when someone sends a message (e.g. DLP, content inspection, classification etc.). Currently only for OWA. Outlook clients coming (much) later.

There’s plenty of exciting stuff coming in the next few months. For now, we will still have to work with the limitations that exist, but if you are in the planning phase for Hybrid Exchange, it might be worth keeping these announcements in the back of your mind.

As things unfold over the coming weeks and months, I will be covering a lot of the details here, and in the Office 365 for IT Pros ebook. Make sure to grab your copy here!

Cheers,

Michael

Blog Exchange Hybrid Exchange

“Conference season” is about to start!

Every year in September, right after the summer holidays, there is an unofficial start of a new “work season”. For some this unofficial start moment comes a bit earlier, for others a bit later. Some even say their work season lasts the entire year… But that’s besides the point. The fall traditionally also heralds a myriad of tech conferences, each fighting for a moment in the spotlights. With Microsoft’s massive Ignite conference moving in from May, this year’s “conference season” promises to be exceptionally busy.

I’ve always liked going to conferences. Although content is important, having the opportunity to talk to peers and interact with the speakers (experts) is something I’ve learned to value more and more with each conference I attended in the past.

This year, I’m lined up to speak at a bunch of conferences again. If you have read some of my previous announcements, you’ll notice that I’m speaking at a pretty much the same conferences as before. Continue reading to find out why!

Blog Events News

Exchange Virtual Directory HTML Report

Update 12/09/2016: script updated to version 1.8:

  • Included support for Exchange 2016 CU2+
  • Made some minor changes to the code + output now shows a message if successful/unable to write the html file.

Previous updates in version 1.7:

  • Added more recent Exchange build numbers
  • Updated download location to TechNet Script Gallery

You can download v1.8 here

Hi,

as a consultant, I regularly come across situations in which I have to troubleshoot an existing Exchange server environment or perhaps have to make an assessment, health report, etc.

Almost every time, I found myself looking up the information from the different (commonly used) virtual directories like: Autodiscover, ActiveSync, OWA, ECP, Web Services, OAB… That’s why I thought it became about time I automated this process so that I didn’t have to type the commands in manually anymore.

The result is a simple script which will query the Exchange Client Access Servers in your environment and will query them for their virtual directory information. Depending on the use of the virtual directory, different object are shown:

image

Blog Exchange PowerShell

A closer look at the “Minimal Hybrid Configuration” option

Just a few weeks ago, Microsoft announced a new feature in its line-up of hybrid Exchange capabilities: the Minimal Hybrid Configuration option. With the introduction of this new capability, Microsoft seems to have responded to a long-standing question from customers who can now move mailboxes to Office 365 without the need to deploy a ‘full’ Hybrid configuration.

Blog Exchange Hybrid Exchange Office 365

Exchange Hybrid Deployments and cross-premises Full Access permissions

Nothing but excellent news in the hybrid Exchange realm these days! Microsoft recently updated the support statement for cross-premises permissions in a hybrid deployment. As of now, Full Access delegate permissions are supported cross-premises. I know many customers will be delighted to hear this as this has been a big ask for quite some time now.

It’s important to understand that the support only applies to Full Access permissions, as stated here. Other permissions like Send-As, Receive-As or Send-on-Behalf are still not supported. Note that Microsoft is in the process of updating its documentation; you should see a more consistent message across TechNet over the next few days!

Although full access permissions have been reported to work intermittently, no cross-premises permissions were supported previously. As such, you could not rely on them working either. From what I understand, the plumbing was already in place for a while but the intermittent results were partially due to the Outlook client not honoring them quite as one would expect. Provided you have the November 2015 update to Outlook 2013, you should no longer run into any problems.

As you move mailboxes to Office 365, permissions are migrated along. If you already had permissions assigned before the move, there is nothing you need to do. Although the permissions were also migrated previously, you had to move connected mailboxes at the same time so they would be hosted in the same organization in order for them to work. Not too long ago, I was talking to a customer who started out with a handful of mailboxes to move to Office 365 but ended up with a huge migration batch because of the interweaved permissions… As of now, this is no longer needed, making planning for migration batches a lot easier!

You should now also be able to add the Full Access permissions after mailboxes have been moved. This means you can give an on-premises mailbox access to a mailbox in Office 365 and the other way around without having to set the permissions prior to moving the target mailbox to Office 365.

In order to explain things more clearly, I have put together a Q&A. I hope this helps!

Until later,

Michael

What cross-premises permissions are supported in a hybrid deployment today?

Full Access only. Other delegate permissions like Send-As, Receive-As or Send-on-Behalf are not. There are no changes to cross-premises calendar delegation either. That continues to work the same way it did before.

Will the permissions work both ways?

Yes. On-premises mailboxes can access Office 365 mailboxes and vice versa.

What do I need to do to make this work?

Nothing, really. Just make sure you are using an up-to-date Outlook client. For Outlook 2013, this means you need at least the November 2015 Cumulative Updates. Needless to say, the more up-to-date you are, the better!

In order to add permissions for a recipient in the other organization, you can either use PowerShell or the Exchange Admin Center. Unlike the EAC in Office 365, you cannot use the on-premises EAC to grant an Office 365 mailbox access to an on-premises mailbox. For that you must revert to using PowerShell.

How do I add permissions to an Office 365 mailbox for an on-premises recipient?

Follow these steps to add Full Access permissions to an Office 365 mailbox for an on-premises recipient:

  1. Login to the EAC in Office 365 (Exchange Online)
  2. Navigate to recipients > mailboxes and then select properties of the mailbox you want to add Full Access permissions for.
  3. In the properties window, navigate to mailbox delegation
  4. Scroll down to you get to the Full Access From there, use the recipient picker (plus-sign) to add the on-premises mailbox you wish to grant permissions to:
    hybridperm1
  5. Click save.

How do I add permissions to an on-premises mailbox for an Office 365 recipient?

As mentioned earlier, you cannot use the EAC to add permissions for an Office 365 recipient. Instead, you must use the on-premises Exchange Management Shell. Don’t worry it’s quite simple!

Add-MailboxPermission –Identity <On-Prem_mailbox_to_give_permissions_for> -User <O365_mailbox_to_give_permissions_to> -AccessRights FullAccess –AutoMapping $false

For example:

Add-MailboxPermission –Identity onpremmbx@domain.com –User clouduser@domain.com –AccessRights FullAccess –AutoMapping $false

Unlike for permissions in the same environment, the AutoMapping feature is not supported. Hence why I specified the –AutoMapping $false parameter. I suspect the permissions to work without adding the parameter too!

What will my users see?

There is no difference in how Outlook displays an Office 365 mailbox over an on-premises mailbox you have access to. However, an on-premises user might get prompted for credentials when trying to access a mailbox in Office 365. This is because, in the back, the Outlook client must establish a connection with the Office 365 service first.

How that looks, depends on a number of things like the version of the Outlook client, whether you use Modern Authentication and whether or not they already have another Office 365 mailboxes in their Outlook profile.

Blog Exchange Hybrid Exchange News Office 365

Hybrid Free/Busy lookups might fail if Outlook Anywhere is disabled

Recently, I bumped into Jaap Wesselius’ article about an issue he encountered about Hybrid Free/Busy lookups failing. As this relates to Hybrid Exchange, I was – of course – intrigued and remembered that I (once) encountered a similar scenario, but could not remember how I resolved the problem back then.

After some digging, I came across the following KB article which describes the behavior of Free/Busy requests and why they might fail of Outlook Anywhere is disabled (blocked) on the user-level: http://support2.microsoft.com/kb/2734791/en-us?sd=rss&spid=13159

To make a long story short, if Outlook Anywhere is disabled at the user level, Autodiscover does not return the External EWS URL which is required to make the Free/Busy call.

The solution is as simple as the problem itself: re-enable Outlook Anywhere for the user and you would be fine. Of course, this might – depending on your environment – be a little challenging. This being said, however, I do suggest that you configure and (if possible) use Outlook Anywhere as it will make your life easier down the road (e.g. for migrations to Exchange 2013).

Exchange 2013 Hybrid Exchange Office 365

Azure AD Synchronization HTML Report

In 2013, Exchange Server MVP Mike Crowley wrote a script which would interactively report on the Office 365 Directory Synchronization tool. In 2014, Mike and I worked to update the script so that an HTML report would be generated. This would allow you to schedule the script and have the output emailed to you without the need to run the script interactively.

Before you can actually run the script, you will have to install SQL PowerShell on the AADSync machine first. DirSync had this installed by default, but it seems that AADSync does not. To install the SQL PS module, you must install the following components separately:

  1. Microsoft® System CLR Types for Microsoft® SQL Server® 2012
  2. Microsoft® SQL Server® 2012 Shared Management Objects
  3. *Microsoft® Windows PowerShell Extensions for Microsoft® SQL Server® 2012

The binaries can be installed from the installation instructions on the following page: http://www.microsoft.com/en-us/download/details.aspx?id=29065

Once you have installed the components, run the following command from the AADSync server and verify that the SQLPS module is listed:

Get-Module -ListAvailable

Once you have verified the SQLPS module is installed and available, you can run the script.

This time around I have decided to publish the script through Github. You can download it from HERE. Alternatively, the script also available from the Technet Script Gallery, HERE.

Please use the script for what it’s worth, and always test in a lab first. Comments/feedback and feature requests are always welcome!

Blog Office 365 PowerShell

Microsoft manages to ship yet another broken Cumulative Update…

A few days ago, Microsoft released Cumulative Update 6 for Exchange 2013 to the world. There used to be a time where Exchange server updates were fairly safe. However, pretty much like in every other Cumulative Update for Exchange 2013, this one also includes some bugs which break functionality in one way or another. While one would say that it starts to become painful for Microsoft, I’m starting to believe it’s more of a joke.

Exchange Server MVP Jeff Guillet was the one to first report the issue. As it turns out, the Hybrid Configuration Wizard in CU6 runs just fine, but some of the features (like initiating a mailbox move from the on-premises EAC or the ability to switch between the on-prem/cloud EAC) no longer work. Although the scope of the break is somewhat limited (it only applies to customers in a hybrid deployment), one could argue it’s an important focus area for Microsoft – especially given that it’s cloud-related. Microsoft has been trying really hard (with success, may I add) to promote Office 365 and get customers to onboard to “the service”. As such, I find it really surprising that it’s the n-th issue related to hybrid deployments in such a short time. In Cumulative Update 5, the Hybrid Configuration Wizard is broken and now there’s this.

Needless to say, you are warned about deploying Cumulative Updates into production. Pretty much every MVP which announced the Cumulative Update made the remark that you should better test the update before deploying it. I would say this is a general best-practice, but given the history of recent Exchange Server updates, I wouldn’t dare to deploy one without thoroughly testing it.

This brings me to another point: what happened to testing, Microsoft? I understand that it’s impossible to test every customer scenario that you can find out there, but how come that pretty obvious functionalities like these manage to slip through the cracks? If it were a one-time event, I could understand. But there’s a clear trend developing here.

Running a service like Office 365 is not easy. More so, the cadence at which the service evolves can be really scathing. On-premises customers have been struggling to keep up with the updates that are being released in the cloud, but it seems that Microsoft itself is having a hard time to keep up too.

On a final note, I’m wondering what customers with a hybrid deployment should do. According to Microsoft support guidelines, hybrid customers are requested to stay current with Exchange Server updates. But given that this is now two consecutive update that are causing problems, one might start to wonder if it’s not better to stay at CU4 as it was the last CU which did not have any hybrid issues…

I imagine that Microsoft is working hard on a fix for this issue, even during a holiday weekend… Let’s wait and see what happens early next week!

Until then, I would hold off on deploying CU6 and revert to using CU5 with the interim update which fixes the HCW bug or – if you don’t like IUs – stick to CU4/SP1.

Blog Exchange 2013 Hybrid Exchange News Office 365

Some thoughts on using the Exchange Integration Pack for Orchestrator…

Recently a customer decided to start using System Center Orchestrator to automate some of the recurring tasks with regards to the management and support of their Exchange organization. More specifically, they wanted to create a custom interface to which the support organization would get access to in order to request specific actions like mailbox moves, message tracking logs etc. This would allow them to execute some (basic) tasks themselves without needing any Exchange permissions or being forced to use PowerShell or the Exchange Management Console.

In fact, Orchestrator is very powerful when it comes down to automating things like this. The Integration Packs for products like Exchange, Active Directory and SharePoint allow you to easily develop such solutions.

What is described below are merely some thoughts I had while building the solution along with a colleague of mine. I’m in no way an expert in the use of Orchestrator, but that’s why I thought this information might be interesting to you.

Before diving into the quirks which may (or may not) be “by design”, let’s have a look at what we were trying to build.

The solution

The customer wanted to have a custom interface (not specified what it needed to be) which would allow members of the Service Desk to request message tracking information without the need for an Exchange administrator to intervene. After some debates on whether or not PowerShell should be leveraged to develop such a GUI, we decided to move forward using SharePoint lists. SharePoint lists are easy to setup and use and because it was already heavily used within this organization, it seemed like the logical step.

In order not to complicate things, we decided that we would ask the support engineer for the following information:

  • Sender Email Address
  • Recipient Email Address
  • Date + Time (hour)

 To enter the information into the SharePoint list, a custom form was created which also took care of data validation. As such, the engineer would be able to enter only a sender address, a recipient address or both. The date + time are always required and needed to be in a specific format (yyyy-mm-dd). The reason why we chose to do data validation in the form is two-fold. First, it’s extremely easy to do and secondly, it would save us quite a bit of code later on when building the solution in Orchestrator. The date + hour indication are used to indicate for what time the message tracking logs are requested. We found that 95% of all requests all were within a 24 hour timespan. That’s why the code we built (more about that later) would look in the message tracking logs 12 hours before and 12 hours after the indicated time.

Whenever an engineer would enter a new item in the list, it should automatically get processed by Orchestrator which would then fetch the information from the Message Tracking logs and write it to a CSV file which would be attached to the list item in SharePoint when finished processing.

All-in-all, the requirements were are pretty straight forward which should make the final solution relatively easy to build. In order to meet these requirements, we needed to following components in Orchestrator:

  • SharePoint Integration Pack
  • Exchange Integration Pack
  • Active Directory Integration Pack

Below is a screenshot of the actual runbook which we built:

image

As you can see, it’s not the most advanced runbook (and maybe not the most efficient either). However, it does the trick. As you will notice, we did built in some logging (in order to have a history what happened) and also do some data validation using the built-in capabilities of Orchestrator.

The quirks

Monitor Item Lists activity

The first problem we came across was using the “Monitor List Items” activity. When first adding this activity to the runbook, it automatically detects all the fields in the list and allows you to use them throughout the runbook as published data from that activity:

image

The problem, though, is that – for some reason – it doesn’t pick up changes made to the list after the activity has been added to the runbook. When you have designed your SharePoint list to have all the necessary fields from the get-go, this probably isn’t much of an issue. In our case, unfortunately, the customer tends to changes his mind once in a while…
No matter what we tried, newly added fields would not show up in the published data for that activity. The only workaround is to remove the activity and add it again. While this might work for very simple workflows, in larger workflows – like the one above – dealing with this is particularly painful. Especially because the published data from the activity is used in multiple places. This means that when you remove/re-add the activity, you have to go in to all the other activity where you referenced the data and ‘reconfigure’ it. Again, this is not a big problem if you know this up front, but it can cost you some time if you decide to make changes to the SharePoint list. So one word of advice: plan carefully!

Exchange Management Shell code

The Exchange Integration Pack allows you to directly run a bunch of Exchange PowerShell commands when you add the Run Exchange Management Shell activity. Pretty easy, right?!  Not really. As it turns out, not everything you can do in the Exchange Management Shell works in this activity.

For instance, in the Exchange Management Shell, the following code would work beautifully:

[code language=”powershell”]Get-TransportServer | Get-MessageTrackinglog[/code]

Bizarrely enough, this won’t work here. Instead, you have to break the pipeline as follows:

[code language=”powershell”]$servers = Get-TransportServer
$servers | Get-MessageTrackingLog[/code]

My best guess is that the runbook activity is already executing a pipeline which limits what you can do with it. Again, this isn’t a big problem. But it’s just something to keep in mind when developing code to be used in Orchestrator.

Here’s the code I (we) used:

[code language=”powershell”]#Defining Variables

$Subject = "{MT-Subject from "Monitor List Items"}"
$Sender = "{MT-Sender from "Monitor List Items"}"
$Recipient = "{MT-Recipient from "Monitor List Items"}"
$data = "{MT-Date from "Monitor List Items"}"
$Hour = "{MT-Hour from "Monitor List Items"}"

#Check Date Input
try{
[datetime]$inputdate = $date+" "+$Hour+":00:00"
[datetime]$startDate = $inputdate.AddHours(-12)
[datetime]$endDate = $inputdate.AddHours(+12)
}
catch{
$returnMsg = "Input date format invalid"
$returnMsg
exit
}

#Convert DateTimes back into usable format
$strStartDate = $startDate.ToString("yyyy/MM/dd HH:mm:ss")
$strEndDate = $endDate.ToString("yyyy/MM/dd HH:mm:ss")

#Construct cmdlet
$cmd += "Get-MessageTrackingLog -Server `$_.Name"

if($Subject -ne $null -and $Subject -ne ""){
$cmd += " -MessageSubject `"$Subject`""
}
if($Sender -ne $null -and $Sender -ne ""){
$cmd += " -Sender `"$Sender`""
}
if($Recipient -ne $null -and $Recipient -ne ""){
$cmd += " -Recipient `"$Recipient`""
}

$cmd += " -Start `"$strStartDate`""
$cmd += " -End `"$strEndDate`""

#workaround for Orchestrator limitation (limitation while executing pipeline)

$servers = Get-TransportServer
$result = $servers | %{
Invoke-Expression $cmd
}

$result | Select EventID,Source,Sender,Recipients,MessageSubject,MessageID[/code]

Exchange Management Shell code output

This is probably the biggest quirk we had to deal with. When you execute code within Orchestrator, the output from the code is then pushed to the next activity (provided that you subscribed to the data, of course). In this case, if multiple results came back from the Exchange Management Shell activity, it would fire the following activity for each result. To avoid this and to bundle the results and send them off to the next activity as a whole, you need to “flatten” the output first:

image

That was easy, wans’t it…? Well, that wasn’t really the problem either. When you take a closer look at the symbol used for separating the results, you’ll notice that we reverted to using a rather rarely used symbol. There’s a specific reason.

Here’s why: for some (stupid) reason, the results which are returned by the EMS runbook activity look like the following:

“[EventId: RECEIVE]
[Source: SMTP]
[Sender: member@linkedin.com]
[Recipients:email@domain.com]
[MessageSubject: email, please add me to your LinkedIn network]
[MessageId: somethinghere@somethingelse]
,[EventId: SEND]
[Source: SMTP]
[Sender: member@linkedin.com]
[Recipients: email@domain.com]
[MessageSubject: email, please add me to your LinkedIn network]
[MessageId: somethinghere@somethingelse]”

No this is not a weird way of display a hash table, it’s literally a large string which is passed on. This makes it incredibly difficult to deal with. In fact, there is no way that you can just push this into a CSV file and make something useful out of it without dealing with the output first.

A quick look on the internet, brought me to the following article: http://blog.coretech.dk/jgs/scorchestrator-2012-ps-function-for-parsing-the-result-of-the-run-exchange-management-shell-cmdlet-activity/

The author of that article suggested to parse the code and to convert the output into something usable. This seemed fair enough to me and I decided to re-use the code (although I needed to modify it to make it work in our case). This was then added to a second activity called “Convert Output” which is the “Run .NET Script” runbook activity. Here’s the code I used:

[code language=”powershell”]$inputText = "{Command Output for "Get MessageTracking Results"}"

if($inputText -ne ""){

$collection = $inputText.Split("¶")
$returnCollection = @()
foreach ($item in $collection)
{
$keypairCollection = $item.Split("`n")

$EventID = $keypairCollection[0].Trim().TrimStart("[").TrimEnd("]").TrimStart("EventId: ")
$Source = $keypairCollection[1].Trim().TrimStart("[").TrimEnd("]").TrimStart("Source:").TrimStart(" ")
$Sender = $keypairCollection[2].Trim().TrimStart("[").TrimEnd("]").TrimStart("Sender: ")
$Recipients = $keypairCollection[3].Trim().TrimStart("[").TrimEnd("]").TrimStart("Recipients: ")
$MessageSubject = $keypairCollection[4].Trim().TrimStart("[").TrimEnd("]").TrimStart("MessageSubject: ")
$MessageId = $keypairCollection[5].Trim().TrimStart("[").TrimEnd("]").TrimStart("MessageId: ")

$obj = New-Object -TypeName PSObject
Add-Member -InputObject $obj -MemberType NoteProperty -Name "EventID" -Value $EventID
Add-Member -InputObject $obj -MemberType NoteProperty -Name "Source" -Value $Source
Add-Member -InputObject $obj -MemberType NoteProperty -Name "Sender" -Value $Sender
Add-Member -InputObject $obj -MemberType NoteProperty -Name "Recipients" -Value $Recipients
Add-Member -InputObject $obj -MemberType NoteProperty -Name "MessageSubject" -Value $MessageSubject
Add-Member -InputObject $obj -MemberType NoteProperty -Name "MessageId" -Value $MessageId

$returnCollection += $obj
}
$output = $returnCollection | convertto-csv -delimiter ";"
}
else{
[string]$output = "No messages could be found with the specified parameters."
}[/code]

You might still wonder why I had to use the ¶ symbol as a delimeter for the output from the “Get MessageTracking Results” activity… The problem with parsing the code is that you have to split the individual results returned by the activity. Using a regular comma or semi-colon is out of the question as it’s quite likely that the subject for a message contains that same character which would cause the output conversion to fail (I found out the hard way). So we needed to decide on a symbol which allowed us to safely parse the code. Hence the ¶ symbol. For now, this does mean that if someone uses the ¶ symbol in the subject and it is returned by the message tracking logs, the above code will fail and there won’t be any output for the message tracking request.

If you have a better alternative: feel free to comment and let me know!

Some final thoughts

All in all, Orchestrator proves to be quite a flexible platform to perform tasks like the one described in this article. Especially the combination with SharePoint makes it very easy to build ‘custom’ tools which can be used by anyone without needing to provide them with permissions in Exchange (even though RBAC provides a nice framework to do just that). I only wish that some of the quirks got solved as it will remove the need for additional steps (and code) which only add complexity…

Exchange 2013 PowerShell