Determine Role Needed to Run Specific Exchange Cmdlets

Have you ever wondered what role(s) an account needs in order to run a particular cmdlet? This is important as most organizations follow the Principle of Least Privilege.

Let us say, for example, that we want a particular account to be able to run the Set-ActiveSyncMailboxPolicy cmdlet. What role(s) does that account need?! This is actually simple once we know which cmdlet to use to get this information.

For this example, all we need to run is:

Get-ManagementRoleEntry *\Set-ActiveSyncMailboxPolicy

Now we know that in order to run the Set-ActiveSyncMailboxPolicy cmdlet, we need to add the Recipient Policies role to the role group of the account we want to give access to.

Meeting Room Random Free/Busy Error MapiExceptionRpcServerTooBusy

The other day I was faced with an issue where one or more meeting rooms would randomly not show their free/busy information depending on how many meeting room I was querying at the same time in Outlook. If using Outlook on the Web (aka OWA), a few rooms would not have free/busy information available.

After some digging, I found the following two events logged in the Exchange server (the output has been truncated):

Log Name:      Application
Source:        MSExchange Availability
Event ID:      4009
Task Category: Availability Service
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      EXAIO
Description:
Process Microsoft.Exchange.InfoWorker.Common.Delayed`1[System.String]: Unable to open connection for mailbox SMTP:R_IT_01B_CF@nunomota.pt. Exception returned is: Microsoft.Exchange.Data.Storage.StorageTransientException: Cannot query rows in a table. ---> Microsoft.Mapi.MapiExceptionRpcServerTooBusy: MapiExceptionRpcServerTooBusy: Unable to query table rows.

Log Name:      Application
Source:        MSExchange Availability
Event ID:      4009
Task Category: Availability Service
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      EXAIO
Description:
Process Microsoft.Exchange.InfoWorker.Common.Delayed`1[System.String]: Unable to open connection for mailbox SMTP:R_HR_04B_CF@nunomota.pt. Exception returned is: Microsoft.Exchange.Data.Storage.StorageTransientException: Cannot open mailbox /o=ADIAEXCHANGE/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=EXAIO/cn=Microsoft System Attendant. ---> Microsoft.Mapi.MapiExceptionRpcServerTooBusy: MapiExceptionRpcServerTooBusy: Unable to make connection to the server.

The problem was that the RPC Pool limit was being reached. For each database we can have up to 32 concurrent RPC connections from the same client process. In my case, most meeting rooms were distributed across mainly two databases:

Count Name
----- ----
   83 MDB01
   51 MDB02
    5 MDB03
    3 MDB04
    7 MDB05
    5 MDB06
    4 MDB07
    1 MDB08
    1 MDB09

As you probably guessed, the resolution is to simply split meeting rooms across all databases (when possible). Once I distributed them so there is only 17/18 meeting rooms per database, this error no longer happened.

Create Shadow Copies on the same Active Directory Site

In the Transport High Availability in Exchange 2013 article we discussed, amongst other topics, Exchange’s Shadow Redundancy feature and how it generates redundant copies of e-mails before these being delivered to mailboxes and before Exchange acknowledging to the sending server successfully receiving them.

We also saw that in DAG environments, Exchange gives preference to creating a shadow copy of an email on a DAG member that is located in a different Active Directory (AD) site, if any. But what if we have a DAG that extends one or more AD sites but we want shadow copies to be created only within the same site? If we look at our Transport Config, we will see a ShadowMessagePreferenceSetting parameter (the following output has been truncated):

[PS] C:\> Get-TransportConfig | FL

MaxRetriesForLocalSiteShadow       : 2
MaxRetriesForRemoteSiteShadow      : 4
ShadowHeartbeatFrequency           : 00:02:00
ShadowMessageAutoDiscardInterval   : 2.00:00:00
ShadowMessagePreferenceSetting     : PreferRemote
ShadowRedundancyEnabled            : True
ShadowResubmitTimeSpan             : 03:00:00

The ShadowMessagePreferenceSetting parameters has three possible settings:

• PreferRemote: Exchange tries to make a shadow copy of the message on a server in a different AD site. If the operation fails, it tries a server in the local AD site;
• LocalOnly: a shadow copy of the message should only be made on a server in the local AD site;
• RemoteOnly: a shadow copy of the message should only be made on a server in a different AD site.

Please have in mind that this parameter is only meaningful when the primary server that is trying to make a shadow copy of the message is a Mailbox server that is a member of a DAG that spans multiple AD sites.

As such, if we want our shadow copies to be created within the same site, all we have to do is update the parameter to LocalOnly. However, when we try to do so we might get the following error depending if the other parameters still have their default values:

[PS] C:\> Set-TransportConfig -ShadowMessagePreferenceSetting LocalOnly

The value for MaxRetriesForRemoteSiteShadow must be set to zero for the LocalOnly shadow redundancy preference setting.

So what we need to do is to also update the MaxRetriesForRemoteSiteShadow parameter:

[PS] C:\> Set-TransportConfig -ShadowMessagePreferenceSetting LocalOnly -MaxRetriesForRemoteSiteShadow 0

ExMon for Exchange 2013/2016 Now Available

ExMon, also known as Microsoft Exchange Server User Monitor, has finally been updated for Exchange 2013 and 2016!

You can download the installation file here, as well as a PDF how-to guide on how to use ExMon.

Distribution Groups Statistics

As an Exchange Administrator, have you ever wondered if all those Distribution Groups are actually being used? Organizations running Microsoft Exchange Server are likely to have been running Exchange for a at least a few years and also likely to continue to do so for a while. After all those years, more and more distribution groups get created, some of them stop being used, some are simply forgotten, etc.

Maybe you got asked by the Audit department or by your manager for a list of the 20 most utilized groups, or maybe you are just curious. The good news is that as long as you have Message Tracking Logs enabled, you can easily get this information!

The easiest way to track messages sent to distribution groups is to list all the expansion events. When a user sends an email to a group, Exchange needs to expand that group in order to know who to send the email to. This gets registered with an EventID of EXPAND. Additionally, the RelatedRecipientAddress field in the EXPAND entry contains the PrimarySmtpAddress of the expanded group. And this is pretty much all the information we need.

Using the following cmdlet, we can get a list of all the emails sent to distribution groups on the 1st of January 2016:

Get-MessageTrackingLog -Start 01/01/2016 –End 01/02/2016 -EventID Expand | Select Timestamp, RelatedRecipientAddress, MessageSubject

But what we really want is to know how many emails were sent to which groups during a particular time. Not a problem! All we need to do is tweak the cmdlet above and add Group-Object:

Get-MessageTrackingLog -Start 01/01/2016 –End 01/02/2016 -EventID Expand | Group RelatedRecipientAddress | Sort Count –Descending | Select Count, Name

Do not forget to add Get-TransportService (or Get-TransportServer in Exchange 2007 and 2010) to get the logs across all transport servers if you have more than one!

If you are interested in getting the Top 20 most used groups, for example, this is also very easy:

Get-TransportService | Get-MessageTrackingLog -ResultSize Unlimited -Start 01/01/2016 -EventID Expand | Group RelatedRecipientAddress | Sort Count -Descending | Select -First 20 | FT Count, Name -AutoSize

Exchange Message Queue RiskLevel

When using the Get-Queue cmdlet to view configuration information for queues on Exchange servers, several properties are available for each queue such as DeliveryType, NextHopDomain, Status, MessageCount, LastError, Velocity, RetryCount, and many, many more.

Some of these properties have already been discussed in MSExchange.org articles and/or tips such as Exchange 2013 Queue Velocity. Another interesting one is RiskLevel:

So what is this Risk Level property? Well, according to the Queue filters TechNet article, “this property is reserved for internal Microsoft use, and isn't used in on-premises Exchange 2013 organizations.” As such, I am assuming on-premises customers do not need to worry about this. But just for information, according to the MSDN RiskLevel enumeration webpage, this property has four possible values:

• Normal: The associated message is normal risk.
• Bulk: The associated message is part of a bulk mailing.
• High: The associated message is high risk.
• Low: The associated message is low risk.