RSS Subscription 168 Posts and 2,769 Comments

Archive for August, 2010

Exchange 2010 SP1 and Blackberry Enterprise Server (BES)

Many will be upgrading to Exchange 2010 SP1 soon.  Many of you also have Blackberry Enterprise Server.  RIM has provided a pre-installation guide for Exchange 2010 here.  I wanted to touch on one of these pre-installation steps.  This is where we increase the maximum number of connections to the Address Book service.  The specific guide for this step is located here.  As you can see, you have to go into the following file “” and set MaxSessionsPerUser to 100000.

Note: Blackberry now has full support for Exchange 2010 SP1 as of 10/12/2010.  RIM retroactively modified their September 29th document to have full support when the same September 29th document previously only had Exchange 2010 SP1 listed with limited support. Please see the following document for support guidance which includes versioning information as well as a support KB article on supporting BES with Exchange 2010 SP1:

In Exchange 2010 SP1, MaxSessionsPerUser does not exist anymore.  You can take a look at an Exchange 2010 SP1 “” file below:

<?xml version="1.0" encoding="utf-8" ?>
        <gcServer enabled="true" />
        <generatePublisherEvidence enabled="false"/>
        <add key="NspiEndpointEnabled" value="true" />
        <add key="RfrEndpointEnabled" value="true" />
       <!-- Set port to an empty string to disable ncacn_ip_tcp. -->
        <!-- Set the port to 0 to allow the server to assign a port number dynamically. -->
        <add key="RpcTcpPort" value="0" />
        <!-- Set port to an empty string to disable ncacn_http for the specific interface -->
        <!-- Standard port assignments: Nspi=6004, Rfr=6002 -->
        <add key="NspiHttpPort" value="6004" />
        <add key="RfrHttpPort" value="6002" />
        <!-- Enables and disables the logging for the address book service. -->
        <add key="ProtocolLoggingEnabled" value="true" />
        <!-- Specifies the folder in which log files will be generated. -->
        <add key="LogFilePath" value="D:\Program Files\Microsoft\Exchange Server\V14\Logging\AddressBook Service\" />
        <!-- Specifies the max size that a single log file can grow to before a new one is generated. -->
        <add key="PerFileMaxSize" value="10MB" />
        <!-- Specifies the max size that the entire directory of logs can grow to before the oldest log is deleted. -->
        <add key="MaxDirectorySize" value="1GB" />
        <!-- Specifies length of time in hours log files will be retained before being deleted. -->
        <add key="MaxRetentionPeriod" value="720" />
        <!-- Specifies if we need to switch log file each hour. -->
        <add key="ApplyHourPrecision" value="true" />

So the big question here is, what do we do?  What do we need to make sure of prior to upgrading to Exchange 2010 SP1 to ensure the BESAdmin account does not have issues connecting to the Address Book Service?  Well, the reason why there is no more MaxSessionsPerUser is that the throttling mechanism was moved to the Throttling Policies and is shared with the RPC Client Access Service which uses the RCA* parameters in the Throttling Policies.

One of the prerequisites steps in the BES Documentation (even for RTM)  is to create a Throttling Policy for the BES Admin Account.  You can see that step here.  Because the Address Book throttling has been moved to the Throttling Policy using the RCA* parameters instead of the “” we will want to take a look at the throttling policy we created for the BESAdmin account and make sure the RCA* parameters are set to $null.

Run the following command on Exchange 2010 to check the throttling policy:

Get-ThrottlingPolicy BESPolicy

We will see results as such:

As we can see, the RCA* parameters are set to $null which means we will be safe upgrading to Exchange 2010 SP1.  If these parameters are not set to $null, set them to $null.  This can be done by running the following command:

Set-ThrottlingPolicy BESPolicy -RCAMaxConcurrency $null -RCAPercentTimeInAD $null -RCAPercentTimeInCAS $null -RCAPercentTimeInMailboxRPC $null

If you are doing a greenfield deployment of BES and need to create a new Throttling Policy with all of the options and then assign the BES Mailbox (assuming the mailbox is BESAdmin), run the following commands:

  1. New-ThrottlingPolicy BESPolicy
  2. Set-ThrottlingPolicy BESPolicy -RCAMaxConcurrency $null -RCAPercentTimeInAD $null -RCAPercentTimeInCAS $null -RCAPercentTimeInMailboxRPC $null -EWSMaxConcurrency $null -EWSPercentTimeInAD $null -EWSPercentTimeInCAS $null -EWSPercentTimeInMailboxRPC $null -EWSMaxSubscriptions $null -EWSFastSearchTimeoutInSeconds $null -EWSFindCountLimit $null
  3. Set-Mailbox “BESAdmin” -ThrottlingPolicy BESPolicy.

Changes in Exchange 2010 SP1 Administrator Audit Logging

Exchange 2010 SP1 changes the way Administrator Audit Logging (AAL) works to some degree.  To see how Exchange 2010 RTM Administrator Audit Logging works, check out a great article by my fellow MVP Neil Hobson here.  This article is not going to explain what AAL is, just what the changes are.

In Exchange 2010 RTM, when you configured AAL, you had to specify what mailbox you were going to store data in.  This first required you to enable AAL and then to set the AAL Mailbox.  An example of this (which is also shown in Neil’s article) is done by running the following command:

Set-AdminAuditLogConfig –AdminAuditLogMailbox

As an Administrator, you then had to give yourself full mailbox access to  For example, if your user account was, you would give yourself full mailbox access using the following cmdlet:

Add-MailboxPermission -User -AccessRights FullAccess

You can now open the mailbox via OWA or Outlook to view the Administrator Audit Logs.

The Changes (Good Changes)

All the steps above I have just explained completely change in SP1.  In short, the changes include:

  • No more specified Mailbox exists.  In fact, the parameter AdminAuditLogMailbox has been removed.  It now uses a hidden mailbox (an arbitration mailbox to be precise) and you cannot change this.
  • All reporting is done in the Exchange Control Panel (ECP) which then creates a report based on the option you specify and sends it to the mailbox of choice.

Administrator Audit Logging Mailbox

As you can see, there is no AdminAuditLogMailbox parameter anymore.

As stated earlier, the data is now being stored in an Arbitration Mailbox. I welcome this change as it is less administrative work to have an additional mailbox when there’s already an arbitration mailbox with unlimited quota that can be storing this data instead.

Exchange Control Panel (ECP)

Logging into the ECP as an Administrator, we have the options to Manage Your Organization.  In fact, if you are a normal user with no elevated RBAC roles, you will not even see the option to Manage Your Organization.

In fact, let’s take a look at my regular user account and we’ll see what I’m talking about.

Now, let’s take a look at my administrator account (yes, I have a regular user account and a separate administrator account, and you should too – it’s called principle of least privilege and protected groups – aka adminsdholder issues).

As you can see, I have an option to Manage My Organization.  The other options in that drop down include:

  • Manage Myself
  • Manage Another User

But as we know, depending on the Exchange 2010 Administrative Model known as RBAC, some options may or may not appear in the ECP due to ECPs modular nature.  So if a user who has been added to the “Recipient Management” Group logs into ECP, they will see Manage My Organization but they may not see the Auditing.  So the question, what Role Groups out of the box have any kind of access to Auditing? Well, I did some PowerShell kung-fu and easily ran a one-liner (Powershell rocks!) and searched for which groups have access to this Auditing feature.  The PowerShell command I ran was:

Get-ManagementRole | Get-ManagementRoleAssignment | Where-Object {$_.Role -like “*audit*”} | FT Role,RoleAssigneeName -wrap -autosize

The result was the following:

We can see that some of our Role Groups (Organization Management and Exchange Organization Administrators) have several iterations of the Role.  This is due to the deleation type.  Regular means that the the Group has access to the commands that are specified in the role Audit Logs.  DelegatingOrgWide means the Role Group (Organization Management and Exchange Organization Administrators) have the power to assign the role to other Role Groups.

Moving on… now that we are in Manage My Organization Mode, we can see there is a Roles & Auditing Section now with an Auditing subsection.  From there, we can see that we can view some Auditing Reports.  These include the following reports:

  • Run a non-owner mailbox access report – allows you to search mailbox audit logs for mailboxes that have been accessed or changed by someone other than the owner.
  • Run a litigation hold report – allows you to search the administrator audit log for users who’ve had litigation hold enabled or disabled for their mailbox.
  • Run an administrator role group report – allows you to search the administrator audit log for changes made to role groups, which are used to assign administrative permissions to users.
  • Export mailbox audit logs – allows you to search for and export information about non-owner access to a mailbox during a specific time period.
  • Export the administrator audit log – allows you to search for and export information about configuration changes made in your organization.

The jist of it is that the first 3 that start with Run show the results within ECP itself.  The two Export options will allow you to specify a mailbox in the organization for which a report will be sent.  The report will look just as it did in RTM; an XML style result.

Let’s run through an Export  example. Let’s say a change was made in the organization and it’s not showing up in the logs.  We suspect that a rogue administrator had disabled Administrator Audit Logging.  We know this issue happened sometime between July 21st and July 23rd.  So we go into the Export the administrator audit log section.

We set the Start date to July 21st and the End date to July 23rd.  We then click Select users so we can choose the mailbox the report gets sent to.

I search for my mailbox and choose my mailbox as the mailbox to send the export to.

We then get the export report in e-mail.

The report can take several minutes and even longer depending on how much of a time period we are searching through. Once the report has been received, we can save the attached XML file and open it up in an XML Editor.  I chose to use XML Notepad.  We can see who the rogue admin was (it was me!… only doing my test of course).

We can also see what was done and what the old and new value were.

<Parameter Name=”AdminAuditLogEnabled” Value=”False” />



<Property Name=”AdminAuditLogFlags” OldValue=”AdminAuditLogEnabled” NewValue=”None” />

<Property Name=”AdminAuditLogEnabled” OldValue=”True” NewValue=”False” />