Friday, May 20, 2016

Improved “Automatic Reply” options in OWA

You might have noticed that since last April Microsoft has added a few new (great!) options to the Automatic Replies feature in Outlook on the Web:


These options make it easier to clear our calendar and automatically decline meetings before we head out for some time away from the office. When we set an automatic reply in Outlook on the web, Outlook offers to do the following on our behalf:
1. Block our calendar so people know we are away;
2. Clear existing meetings on our calendar by declining/cancelling them;
3. Automatically send a response to incoming invitations while we are away.



Block my calendar for this period
This option will create an appointment for the duration of our automatic reply with the title we specify:


Automatically decline new invitation for events that occur during this period
Outlook is now able to automatically decline a new invitation on our behalf while we are away! With this option, users will immediately know we will not be attending a meeting that gets scheduled while we are away. After responding on our behalf, Outlook will leave the invitation in our inbox so we know what happened while we were gone.

Decline and cancel my meetings during this period
That last option is to decline and cancel events currently in our calendar. When we now set an automatic reply, Outlook on the web finds all events that occur while we are away and gives us the option to indicate which meetings we would like to cancel or decline, as well as give you reply options to include.

First we select a reply to use when cancelling these meetings:

And then we can select which meetings we actually want to cancel:

Outlook on the web selects all meetings with attendees by default, leaving events without any attendees unchecked (as these are normally reminders or notes users create for themselves). If there is a meeting we don’t want to cancel, we simply uncheck it from the list and Outlook on the web will leave the event in our calendar.

How cool are these new options?! No more manually blocking our calendar and rejecting meetings one by one! Now I just hope this will come to Exchange on-prem soon, but it won’t surprise me if it takes a few good months...


Wednesday, May 18, 2016

Outbound DKIM Signing in Office 365

About a year ago, I wrote an article entitled DKIM and DMARC in Office 365 where I explored what DomainKeys Identified Mail (DKIM) and Domain-based Message Authentication, Reporting & Conformance (DMARC) are, and how exactly they work with Exchange Online in Office 365.

At the time of writing that article, Office 365 only supported inbound validation of DKIM over IPv4 and IPv6. Outbound DKIM signing was not yet available but was in the roadmap. Well, it is here now!

To continue reading about DKIM signing in Office 365, please check this article at MSExchange.org.

Remote Exchange Monitoring and Reporting using Email

We all know how crucial a messaging service is to most organizations. With the exception of maybe telephones, businesses today rely on email and messaging systems more than any other piece of infrastructure. Every Exchange administrator knows the importance of continuously monitoring Exchange, not only to prevent downtime and quickly fix problems after they occur, but also to be aware of the health of the infrastructure and to help identify potential problems and performance degradations before they turn into problems and cause downtime.

Monitoring solutions like Microsoft’s System Center Operations Manager, SolarWinds, Nagios, MailScape, etc., are just some examples of monitoring tools for Exchange. However, some organizations do not provide access to these tool’s consoles or dashboards outside the internal network. So what happens if an administrator is out and about without anything other than his/her phone and needs to check if this user has gone over their quota and cannot send emails, on which server a particular database is mounted, or even if ServerA has just been rebooted?

These type of situations might be rare, but I have personally been there and it would have been extremely useful if I could send an email to my mailbox with a particular PowerShell cmdlet and get the output of that cmdlet back. And this is what this article is about. We will develop two basic scripts that will monitor incoming emails between two users (for security reasons), run the cmdlet(s) in the email’s subject and reply with the output from that same cmdlet. The first script will use Message Tracking Logs while the second Exchange Web Services (EWS).

To continue reading, please check this article at MSExchange.org.
 
 

Saturday, May 14, 2016

Clutter Disabled by Default in Exchange Online? No!

There have been some discussions online where people are saying that Clutter seems to be disabled by default for new mailboxes in Exchange Online. It turns out that Clutter has not been disabled by default for new Office 365 mailboxes. As we know, Clutter is a learning system, and it requires a certain lower limit of messages in the mailbox to confidently learn about a user's behaviour before Clutter is auto enabled for a mailbox. This means that, for newly created mailboxes and mailboxes that are migrated from an on-premises environment into Exchange Online, the following requirements need to be meet:
  1. At least 1,000 messages delivered to the mailbox after the mailbox was created or migrated;
  2. The user needs to have logged into the mailbox once after creation/migration.
 
After both these requirements are meet, Clutter is auto enabled for that mailbox within 24 hours.

"The Delegates page is not available" Error Message

The other day, a user was trying to give his new personal assistance Delegate permissions to his mailbox. However, whenever he clicked on Delegate Access:

He would receive an error message stating: “The Delegates page is not available. Cannot access Outlook folder.

After some troubleshooting and digging around, it turned out that this was being caused by a particular Outlook (Inbox) rule! I am still to investigate why this rule was causing this problem and why would any rule prevent configuring delegates, so this is still a mystery...

If you are experiencing the same problem, simply disable any existing rules one by one until you are able to configure delegates. Alternatively, you can start Outlook by typing “Outlook /CleanRules” in the Start Menu to start Outlook and delete all rules (probably not recommended).

Thursday, May 5, 2016

Product Review: Stellar Exchange Toolkit v7.0

In this product review, I reviewed the latest version of Stellar Exchange Toolkit, v7.0 launched in March 2016. This toolkit is designed to help Exchange administrators extract data from corrupt Exchange EDB or backup files, easily convert OST to PST files, and to reset domain account passwords. It supports all Exchange versions since 5.5 and all it requires is a machine running Windows Vista / Server 2003 or above to install the software, plus a version of Outlook compatible with the Exchange server being used in order to perform certain export/import operations.

The Toolkit, as the name suggests, is a collection of the following tools that we will review one by one:
  • Stellar Phoenix Mailbox Exchange Recovery
  • Stellar Mailbox Extractor for Exchange Server
  • Stellar OST to PST Converter
  • Stellar Mailbox Extractor for Exchange Backup
  • Stellar Phoenix Password Recovery for MS Exchange

To read the full review, please visit MSExchange.org.
 
 

Wednesday, May 4, 2016

Determine Client Used to Send Email

Just recently someone asked me if there was a way to determine which email client (Outlook, OWA or ActiveSync) was used to send a particular email. On top of that, this person was also interested is finding out how many emails are sent per day using each of these clients.

The good news is that the Message Tracking Logs register this information. Every email sent has a SourceContext property which contains, amongst other information, the ClientType used to send the email. The important thing is to check this property for SUBMIT events, i.e., when the Mailbox Transport Submission service successfully transmits the email to the Transport service.

For SUBMIT events, the SourceContext property contains the following details:
  • MDB: the mailbox database GUID;
  • Mailbox: the mailbox GUID;
  • Event: the event sequence number;
  • MessageClass: the type of message. For example, IPM.Note;
  • CreationTime: date and time of the message submission;
  • ClientType: for example OWA or ActiveSync.


Please note that this only applies to emails sent by internal users. There is no SUBMIT event when an external sender sends an email to an internal user, meaning there is no ClientType property for these emails. In these cases, the only information we have regarding the sender is what the email headers contain, which does not include email client information.

To check what email client was used to send a particular email, we can run something like the following cmdlet and look at the SourceContext field:
Get-TransportService | Get-MessageTrackingLog -ResultSize Unlimited -Start 05/11/2016 -EventID SUBMIT -Sender nuno@nunomota.pt -MessageSubject Test | Select SourceContext

This field will contain information like the following:
MDB:34f3dc86-91bb-4ee7-a6a5-3d3ddc536050, Mailbox:a1de664f-9826-43a3-b9c8-3db019c86d8b, Event:29647741, MessageClass:IPM.Note, CreationTime:2016-05-11T07:17:14.922Z, ClientType:MOMT

In this case, MOMT stands for MAPI on the Middle Tier, basically clients that connect using Outlook or any other application that connects using RPC/HTTP or MAPI/HTTP.

To count the number of emails sent using OWA today, we can run something like this:
(Get-TransportService | Get-MessageTrackingLog -ResultSize Unlimited -Start 05/11/2016 -EventID SUBMIT | Where {$_.SourceContext -match "OWA"}).Count

Easy as that! :)