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! :)

Friday, April 29, 2016

Empty StorageLimitStatus when running Get-MailboxStatistics in Exchange 2013/2016

The old version of this script, used to gather some statistics out of mailboxes, made use of the StorageLimitStatus attribute of mailboxes (when running the Get-MailboxStatistics cmdlet). However, if you run the script in an Exchange 2013/2016 environment, you will notice that this attribute is always blank while with Exchange 2010 it is not... Unfortunately, this is by design...
 
Unlike versions of the Information Store earlier than the one that comes with Exchange 2013, the Information Store in Exchange 2013 does not cache the values of mailbox quotas. Therefore, the Information Store makes frequent calls to Active Directory (AD) to retrieve the values of mailbox quotas for each mailbox that is specified in the Get-MailboxStatistics cmdlet. Because of the frequent calls to AD, admins may experience poor performance in Exchange. To avoid this, the default Get-MailboxStatistics cmdlet does not retrieve the mailbox quotas and does not display a value in the StorageLimitStatus field...
 
To work around this issue, all we can do is either use the Exchange Admin Console (EAC):
  1. Log on to EAC by using a user account that is assigned at least the Mail Recipients role;
  2. In the feature pane, click recipients. A list of mailboxes is displayed;
  3. Select the mailbox of which you want to verify the quota status and then click the Edit button on the toolbar;
  4. Click mailbox usage. The mailbox quota usage is displayed.
Or we can use the Exchange Management Shell and run the following cmdlet:
Get-Mailbox "user" | FT *quota*, *size -AutoSize

The script has now been updated for Exchange 2013/2016 environments to work around this "issue".

Outlook Chinese NDR

There is a known bug with Outlook 2010 and 2013 that causes Non Delivery Reports (NDR) to be converted to Chinese-like characters when they are forwarded:


The same NDR does not get converted when being forwarded using OWA or when forwarded as an attachment.

The good news is that there are updates to fix this:

Saturday, April 23, 2016

Monitor Mailbox Database Transaction Logs

Excessive database and/or transaction log growth is, unfortunately, not an uncommon problem in Exchange deployments. On top of being hard to troubleshoot, if it is found too late, it can cause serious issues for users and even the business. As such, it is crucial to have an adequate monitoring solution. However, this is not the case in every single organization, so I decided to write a basic script to keep an eye on the number of logs being generated across databases.
 
You can, for example, run the script every hour and if any database currently has more logs than a specified threshold, it sends an alert by email with the number of transaction logs for all databases, highlighting the one(s) that triggered the alert, and the current free space for the database (you might need to update it depending on whether you have the .edb file and logs on the same or different locations).
 
The script simply counts all files in the LogFolderPath location (variable for each database) as this makes it quicker than only looking for *.log files, and still be accurate for what we want to achieve.

You can download the complete final script from the TechNet Script Gallery.

Friday, April 22, 2016

Preserving Auto-Forwarded Messages in Exchange

Over the last few versions of Exchange, the Information Protection team has done an amazing job in improving Exchange’s compliance capabilities. One of these features, called In-Place Hold, does a great job in preserving mailbox items. However, it did not capture emails automatically forwarded by users. This can be important as sometimes emails are forwarded without a copy of the email being stored in the user’s mailbox.



If the email does not get delivered to the mailbox at all, it cannot be placed on hold and, as such, will not be available for eDiscovery. For organizations wanting to stay in compliance, the recommendation has been to either disable automatic forwarding completely or to use Journaling.

Well, not anymore! Microsoft has rectified this and now Exchange Online is able to capture auto-forwarded messages. Transport detects if the user that has AutoForwarding configured is on hold and, if yes, automatically preserves a copy of the email in the Recoverable Items folder, making it available to eDiscovery.

At the time of writing this tip, this feature does not yet seem to be available in Exchange 2016 RTM, but it is already available in Exchange Online. In the following screenshot, we can see an eDiscovery search that contains an item that was sent from Nuno to Mota when Mota had auto forwarding configure to an external recipient without a copy being saved in Mota's mailbox. As we can see, the email was still placed on hold:
 

Thursday, April 21, 2016

Search Admin Audit Log Old Properties

When searching the Admin Audit Log using the Search-AdminAuditLog cmdlet, you might find some useful information missing:
Search-AdminAuditLog -Cmdlets Set-TransportService

ObjectModified     : EXAIO
CmdletName         : Set-TransportService
CmdletParameters   : {MessageTrackingLogMaxAge, MessageTrackingLogMaxDirectorySize, Identity}
ModifiedProperties : { }
Caller             : nunomota.pt/Users/Admin
Succeeded          : True
Error              : None
RunDate            : 9/10/2015 8:47:48 AM
OriginatingServer  : EXAIO (15.00.1104.000)

From the above, we can see what was changed (the maximum age for the logs and the maximum allowed size for the directory) but not what these settings were changed to...

To see this, we have to dig deeper into CmdletParameters:
(Search-AdminAuditLog -Cmdlets Set-TransportService).CmdletParameters

Name                                 Value
----                                 -----
MessageTrackingLogMaxAge             45.00:00:00
MessageTrackingLogMaxDirectorySize   10 GB (10,737,418,240 bytes)
Identity                             EXAIO

Now we know exactly what the user Admin changed! But what about if we want to know what these settings were before this change?

By default, the administrator audit log records only the cmdlet name, cmdlet parameters (and values specified), the object that was modified, who ran the cmdlet, when the cmdlet was run, and on what server the cmdlet was run. The administrator audit log does not log what properties were modified on the object. If we want the audit log to also include the properties of the object that were modified, we need to enable verbose logging by setting the LogLevel parameter to Verbose:
Set-AdminAuditLogConfig –LogLevel Verbose

When we enable verbose logging, in addition to the information logged by default, the properties modified on an object, including their old and new values, are included in the audit log:
(Search-AdminAuditLog -Cmdlets Set-TransportService).ModifiedProperties

Name                                 NewValue      OldValue
----                                 --------      --------
MessageTrackingLogMaxAge             45.00:00:00   31.00:00:00
MessageTrackingLogMaxDirectorySize   10 GB         5 GB

Now we know exactly what got changed and what the old configuration was!

User Photo in Exchange, Lync and Active Directory

There are several posts out there about how to upload users’ photos into Active Directory (AD) so they can be used by Exchange or Lync, but very few on how this works or how to export them if we need to.

In AD we can use images no greater than 96×96 pixels in resolution and 100KB or smaller in size. This looks ok in the Lync and Outlook client, but results in a blurred photo when Lync, for example, attempts to upscale the image for use in a conference.

In Lync 2013 (and Skype for Business Server 2015) photos can be stored in the user's mailbox (when using Exchange 2013), allowing for photo sizes up to 648x648 pixels. In addition to that, Exchange automatically resizes these photos for use in different products as needed:
  • 64x64 pixels (96 dpi, 24 bit depth, approx. 2KB), the size used for the AD thumbnailPhoto attribute. If we upload a photo to Exchange, Exchange will automatically create a 64x64 pixel version of that photo and update the user's thumbnailPhoto attribute. However, if we manually update the thumbnailPhoto attribute in AD the photo in the user's mailbox will not automatically be updated. This photo is only used by Lync 2010 or legacy clients, so we are ok;
  • 240x240 pixels if the original picture is larger than 240, otherwise 96 (96dpi, 24 bit depth, approx. 8KB), for use in Outlook, OWA, Skype for Business Web App, and Skype for Business;
  • 648x648 pixels for use in Skype for Business and Skype for Business Web App.


Importing Photos
To use high resolution photos, we have to use the Set-UserPhoto Exchange cmdlet:
Set-UserPhoto “Nuno Mota” -PictureData ([System.IO.File]::ReadAllBytes(“D:\Photos\nuno.jpg”)) –Confirm:$False

As already mentioned, the Set-UserPhoto cmdlet does two things: it stores a copy of a high resolution image in the user’s Exchange mailbox, and stores a copy of the photo as a 64×64 image in the thumbnailPhoto AD attribute.


Exporting Photos
To check someone’s photo, we can use Exchange Web Services and the following URL (updating the user’s email and maybe image size):
https://mail.domain.com/ews/Exchange.asmx/s/GetUserPhoto?email=nuno@domain.com&size=HR648x648
 
If we want to export a user’s photo from AD, we can PowerShell and the following commands:
$photo = (Get-ADUser nuno -Properties thumbnailphoto).thumbnailphoto

We can now save this photo into a JPEG file and or import it directly to a different user for example (useful if the user gets a new account):
Set-Content “D:\Photos\nuno.jpg” -Encoding byte
Set-ADUser mota -Replace @{thumbnailphoto = $photo}

However, if we are using Exchange 2013, we should use Exchange cmdlets to manage users’ photos. This way we can export the 648x648 pixels photo from the user’s mailbox instead of the small one from AD:
(Get-UserPhoto nuno).PictureData | Set-Content “D:\Photos\nuno.jpg” -Encoding byte

If you want to use high resolution photos in Lync as well, you might want to ensure you update your Lync Client policy with a MaxPhotoSizeKB of at least 100 instead of just 30.

Mailbox Database Seed Status

Seeding large mailbox databases can potentially take a long time. Although it is something that usually does not need to be monitored, it is always good to keep an eye on it to see how it is doing. The Get-MailboxDatabaseCopyStatus cmdlet gives us all the information we need for this.

Usually I use this cmdlet in the following format to ensure the mailbox database copies on a particular server are mounted and/or healthy:
Get-MailboxDatabaseCopyStatus -Server "server_name" | Sort Name


But we can use it to get further details for a particular mailbox databases (the following output has been shortened to only include the most relevant information for this tip):

[PS] C:\>Get-MailboxDatabaseCopyStatus “MDB01\EXAIO” | FL

Identity : MDB01\EXAIO
DatabaseName : MDB01
Status : Seeding
MailboxServer : EXAIO
ActiveDatabaseCopy : EXMBX01
ActiveCopy : False
ActivationPreference : 3
IsLastCopyAvailabilityChecksPassed : False
LastCopyAvailabilityChecksPassedTime :
IsLastCopyRedundancyChecksPassed : False
LastCopyRedundancyChecksPassedTime :
ActivationSuspended : True
ContentIndexState : FailedAndSuspended
ContentIndexErrorMessage : Reseeding of the index is required.
ContentIndexErrorCode : 22
CopyQueueLength : 718053
ReplayQueueLength : 0
ReplicationIsInBlockMode : False
ActivationDisabledAndMoveNow : False
AutoActivationPolicy : Unrestricted
ReplayLagStatus : Enabled:False; PlayDownReason:None; Percentage:0; Configured:00:00:00;
Actual:00:00:00
DatabaseSeedStatus : Percentage:33; Read:95.19 GB; Written:95.19 GB; ReadPerSec:23.65 MB; WrittenPerSec:23.67 MB

DiskFreeSpacePercent : 60
DiskFreeSpace : 434.7 GB (466,730,405,888 bytes)
DiskTotalSpace : 717 GB (769,869,737,984 bytes)
DatabaseVolumeMountPoint : E:\Mount\edb09\
LogVolumeMountPoint : E:\Mount\edb09\



If we are particularly interested on the progress of the seed operation, we can filter the above output to only include what we want:
(Get-MailboxDatabaseCopyStatus “MDB01\EXAIO”).DatabaseSeedStatus

Saturday, April 9, 2016

Analyze Mailbox Items Class or Type

The purpose of this script is to go through every single item in a mailbox and produce a report listing the class (or type) of each item and how many items of each class were found in the mailbox:

Processed 52 folders and 19163 items.

Name Value
---- -----
IPM.Appointment                          194
IPM.Appointment.ReadiManagerMeeting      2
IPM.Contact                              164
IPM.Note                                 16911
IPM.Note.Exchange.ActiveSync.MailboxLog  2
IPM.Note.Microsoft.Conversation          1616
IPM.Note.Microsoft.Conversation.Voice    67
IPM.Note.Microsoft.Missed                2
IPM.Schedule.Meeting.Canceled            3
IPM.Schedule.Meeting.Request             43
IPM.Schedule.Meeting.Resp.Neg            3
IPM.Schedule.Meeting.Resp.Pos            20
IPM.Schedule.Meeting.Resp.Tent           2
IPM.Sharing                              120
IPM.StickyNote                           14


I created this script to have an idea of how items had been archived by EnterpriseVault across the users’ mailboxes (IPM.NOTE.EnterpriseVault.Shortcut class). The script reports on all item classes, but it can easily be changed to only look for a particular class, such as EV stubs for example.

To download the complete final script, please head on to the TechNet Script Gallery.

Friday, April 8, 2016

Office 365 Admin App for Windows 10

Microsoft has released the beta version of the Office 365 Admin app for Windows 10, which is available for both Windows 10 Desktop and Mobile!

This app gives admins the ability to administer Office 365 directly from their desktop. It supports notification integration with Windows 10 as well as Microsoft Partner scenarios, allowing admins to easily switch organizations if they manage Office 365 for multiple tenants. The mobile version has the exact same user experience making switching from desktop to the mobile app extremely easy.

To install it, search for “office 365 admin” in the Windows App Store and you should find it straight away. Click Install and, once installed, click Open: 

Alternatively, once installed, search for “office 365” in your start menu:

Simply add an account for an Office 365 tenant you want to manage:

Once logged in, the app’s dashboard provides some high level information about the service and the tenant itself:

We can search for all users provisioned in the tenant:

As well as perform a variety of actions on user accounts or gather further information about them:

We can check the current health of the Office 365 tenant:

Read any available messages:

And much, much more! Give it a try :)

Setting Distribution Groups Default OU in Exchange 2010/2013/2016

When creating a Distribution Group in the Exchange Shell or Console, we are given the option to choose which Organizational Unit (OU) in Active Directory (AD) we want the group’s object to be created in:

However, we do not necessarily need to choose an OU. We can tell Exchange where it should create all OUs by default using the Set-OrganizationConfig cmdlet. By default, no OU is selected which means Exchange will create all distribution groups in the Users OU:

Let us say we want all distribution groups to be created in the Exchange -> Distribution Groups OU:
 

Using the above cmdlet it is easy to globally set the default OU for any newly created distribution group from now on:

When creating a new distribution group now, we still get the exact same wizard with the Organizational unit field not populated. However, if we don’t choose any OU, the distribution group will now be created in the OU we set up above.


Distribution Group SendAs Denied

When trying to assign Send As or Receive As permissions to a Distribution Group in Exchange 2010, 2013 or 2016 using the Add-ADPermission cmdlet, you might get an error message saying Access is denied and insufficient access rights:

Active Directory operation failed on . This error is not retriable. Additional information: Access is denied.
Active directory response: 00000005: SecErr: DSID-031521D0, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0
+ CategoryInfo : WriteError: (0:Int32) [Add-ADPermission], ADOperationException
+ FullyQualifiedErrorId : 5557AD82,Microsoft.Exchange.Management.RecipientTasks.AddADPermission


 
 
This is because, by default, Exchange Trusted Subsystem is not granted the “modify permissions” permission. This causes the Add-ADPermission cmdlet to fail with an Access Denied error.
To resolve this problem, add the modify permissions permission for the Exchange Trusted Subsystem to the organizational unit that contains the Distribution Group:
1.       Open Active Directory Users and Computers;
2.       Click View, and then click Advanced Features;
3.       Right-click the OU that contains the distribution lists, and then click Properties;
4.       In the Security tab, click Advanced;
5.       In the Permissions tab, click Add;
6.       In the Enter object name to select box, type Exchange trusted subsystem, and then click OK;
7.       In the Object tab, select This object and all descendants objects in the Apply onto list, locate Modify Permissions in the Permissions list, and then set it to Allow;
8.       Click OK.

 

Friday, April 1, 2016

Exchange Distribution Group Creation Report

For some organizations, allowing end users to create and manage their own Distribution Groups is a standard practice. It usually alleviates work from ServiceDesk or second/third line support teams and gives users more responsibility and freedom to perform their role.

While this is indeed a great feature, it is always important to have a good naming convention in place and ensure that users adhere to it. But no matter how much we tell users how they should be creating a distribution group, we all know there will be situations where the group is not created as it should have been.

In one hand, for IT to check every day all the groups users created would cause some overhead. On the other hand, leave them for too long and then it might be difficult to rectify a wrongly-created distribution group. So why not automatically generate a report when new groups are created for IT to look at? That way they do not need to keep constantly checking and it is quick and easy to make sure the newly-created groups are OK.

To download the script and the read the entire article, please go to MSExchange’s Exchange Distribution Group Creation Report article page.

Exchange Meeting Room Statistics

Room mailboxes have been available for a very long time now, and most organizations make extensive use of them for all their meeting room bookings. In certain cases, having statistical information about these rooms helps organizations plan or redesign their offices in a more efficient way. This information can show how often certain rooms are utilized, the average meeting duration, who tends to book more meetings, and so on.

In this article we will develop a script to provide us with some of this information and to serve as a stepping stone to gather further information depending on the reader’s particular needs. The end result will look something like this:
 
In this example, I only searched one meeting room called ITD – 16A – Small CF VC. For the month of December we can see that a total of 115 meetings were booked, out of which 55% are recurring meetings. The average meeting duration was 46 minutes, each meeting had an average of 8 attendees and there were slightly more meetings booked in the morning.

To download the script and the read the entire article, please go to MSExchange’s Exchange Meeting Room Statistics article page.