Blocking Outlook App for iOS & Android

imageYesterday, Microsoft announced the immediate availability the Outlook for iOS and Outlook for Android preview. These apps are the former app named Acompli, which was acquired by Microsoft in December, last year. It is unlikely that Microsoft will develop and support two similar apps, so one can assume the new Outlook app will replace the current OWA for iOS and OWA for Android (or just OWA for Devices) apps.

The app isn’t without a little controversy:

  • The app stores credentials in a cloud environment from Amazon Web Services for e-mail accounts that don’t support OAuth authorization.
  • The app makes use of a service sitting between the app and your mailbox. This service acts as a sort of proxy (hence it requires those credentials), fetching, (pre)processing and sending e-mail. In some way this is smart, as it makes the app less dependent on back-end peculiarities, using a uniform protocol to communicate with the proxy service.
  • The app does not distinguish between devices (device identities are assigned to your account, which makes sense since the app uses a service to retrieve and process your e-mail).
  • The app does not honor ActiveSync policies, like PIN requirements. While true, this app is not an ordinary Exchange ActiveSync client.

You can read more about this here and here.

In all fairness, when the app was still named Accompli, nobody cried foul. But the app is now rebranded Outlook and property of Microsoft, so it seems this made the app fair game. I hope Microsoft is working behind the scenes to make the new Outlook app enterprise-ready, and I’m sure it won’t be long before we see the app’s services move from AWS to Azure. The whole outrage in the media also seems a bit misplaced, as Connected Accounts in Exchange Online, which will retrieve e-mail from a POP or IMAP mailbox, will also store credentials ‘in the cloud’.

It is recommended to treat the app as a consumer app for now, and you may want to block the app in your organization. I have written on how to accomplish blocking or quarantining faulty iOS updates before. However, in those articles I used the reported OS version to block or quarantine devices. The Outlook app proxy service reports itself as “Outlook for iOS and Android” as device model when querying your mailbox, allowing us to use the DeviceModel parameter for matching.

The cmdlet to block or quarantine the new Outlook app in Exchange 2010, Exchange 2013 or Office 365,  is:

New-ActiveSyncDeviceAccessRule –QueryString 'Outlook for iOS and Android' –Characteristic DeviceModel –AccessLevel Block

or, to quarantine:

New-ActiveSyncDeviceAccessRule –QueryString 'Outlook for iOS and Android' –Characteristic DeviceModel –AccessLevel Quarantine

For examples of alternative blocking methods using TMG or F5, check this article. If you need to specify the user agent string, use “Outlook-iOS-Android/1.0″ (or partial matching on “Outlook-iOS-Android” to block future updates of the app as well).

As goes for all mobile devices in enterprise environments, as an organization it may be better to test and aprove devices and OS versions rather than to be confronted with mobile apps with possible faulty behavior after an update or which may violate corporate security policies.

End of Exchange 2010 Mainstream Support

Exchange 2010 LogoWith all the media attention for Windows 7 going out of mainstream support, one might forget today also marks the end of mainstream support for Exchange Server 2010.

Exchange 2010, which was released in October, 2009 (which seems centuries ago now), and which still has a very large installed base, is going into the extended support phase.

Depending on your support contract, this means Microsoft will no longer provide free support for this product. Patches for security issues will still be available, and owners of premier support contracts are eligible for non-security updates through extended hotfix support option.

Exchange Server 2010 will reach end-of-life on January 14th, 2020.

Exchange 2010 SP3 Rollup 8v2

Exchange 2010 Logo

UPDATE (December 12th, 2014): Exchange 2010 SP3 Rollup 8 v2 is released, addressing the issue mentioned below in the initially published version. The new version number is 14.3.224.2 (was 14.3.224.1). You can download RU8v2 here.

UPDATE (December 10th, 2014): Exchange 2010 SP3 Rollup 8 has been pulled after discovery of Outlook MAPI issues. It is currently recommended not to deploy RU8 and when you have installed RU8, to revert to RU7 to prevent walking into this issue. Other protocols, such as EAS or IMAP4, as unaffected which is why you might not encounter this problem immediately.

Today the Exchange Team released Rollup 8 for Exchange Server 2010 Service Pack 3 (KB2986475). This update raises Exchange 2010 version number to 14.3.224.1.

This Rollup contains a security update to fix a potential elevation of privilege issue (bulletin MS14-075), as well as the following fixes:

  • 3004235 Exchange Server meetings in Russian time zones as well as names of time zones are incorrect after October 26, 2014
  • 3009132 Hybrid mailbox moves to on-premises environment but finishes with CompletedWithWarnings status
  • 3008999 IRM restrictions are applied to incorrectly formatted .docx, .pptx, or .xlsx files in an Exchange Server 2010 environment
  • 3008370 Group members are not sorted by display name when HAB is used with OAB in Exchange Server 2010
  • 3008308 Public folder database migration issue in a mixed Exchange Server environment
  • 3007794 Hub Transport server cannot deliver messages when a database fails over to a cross-site DAG in Exchange Server 2010
  • 3004521 An Exchange server loses its connection to domain controllers if a public folder server is down in Exchange Server 2010
  • 2999016 Unreadable characters when you import ANSI .pst files of Russian language by using the New-MailboxImportRequest cmdlet
  • 2995148 Changing distribution group takes a long time in an Exchange Server 2010 environment
  • 2992692 Retention policy is not applied to Information Rights Management protected voice mail messages in Exchange Server 2010
  • 2987982 Issues caused by ANSI mode in Exchange Server 2010
  • 2987104 Email message is sent by using the “Send As” instead of “Send on Behalf” permission in Exchange Server 2010
  • 2982017 Incorrect voice mail message duration in Exchange Server 2013 and Exchange Server 2010
  • 2977279 You cannot disable journaling for protected voice mail in Exchange Server 2013 and Exchange Server 2010

Notes:

  • If you want to speed up the update process for systems without internet access, you can follow the procedure described here to disable publisher’s certificate revocation checking.
  • If you got a DAG and want to properly update the DAG members, check the instructions here.
  • Rollups are cumulative per service pack level, i.e. they contain fixes released in earlier update Rollups for the same product level (RTM, SP). This means you don’t need to install previous Rollups during a fresh installation but can start with the latest Rollup package.

As with any Hotfix, Rollup or Service Pack, I’d recommend to thoroughly test this rollup in a test and acceptance environment first, prior to implementing it in production.
You can download Exchange 2010 SP3 Rollup 8 here.

Exchange-Processor Query Tool: PowerShell Edition

powershellAnyone sizing for Exchange Server 2013 or even still Exchange Server 2010, using the Server Role Requirements Calculator, has to determine processor requirements at some point. This is accomplished by looking up the SPECint_rate2006 score of the planned processor configuration and matching that against the calculated number of required megacycles by the calculator. To account for fail-over situations, additional overhead needs to be added to the number of megacycles. The process as part of the overall sizing has been explained in detail by Jeff Mealiffe here.

The Exchange consultants’ Swiss army knife when determining SPECint rates is the Exchange Processor Query Tool, an Excel sheet designed by Scott Alexander from Microsoft, which allows you to easily look up and determine the SPECint_rate2006 value by inputting a processor model. While still useful, the tool has been out there since 2011. Also, it would be nice sometimes to see which systems are eligible for a certain sizing specification, rather than validating if the planned processor configuration meets the sizing requirements.

So, I wrote a PowerShell script which can query the SPECint rates for you. Because the rating scores are returned as objects, you can perform additional tasks using PowerShell functionality, such as:

  • Use additional criteria, such as vendor, min/max number of cores, etc.
  • Calculate the average SPECint2006 Rate Value for a certain CPU/cores configuration.
  • You can use the SPECint value calculated by the Server Role Requirements Calculator  to find hardware configurations which meet the required total megacycles requirements, optionally including a required overhead percentage.
  • You can select if you are sizing for Exchange Server 2010 or Exchange Server 2013.

Requirements
The script requires PowerShell and internet access to query the SPECint database.

Usage
The script is called Exchange-PQT.ps1, in honor of the Processor Query Tool (PQT).  The syntax is as follows:

Exchange-PQT.ps1 [-CPU <String>] [-Vendor <String>] [-System <String>] [-Overhead <Int32>] [-MinMegaCycles <Int32>] [-Type <String>] [-MinCores <Int32>] [-MaxCores <Int32>] [-MinChips <Int32>] [-MaxChips <Int32>] [<CommonParameters>]

The information returned and which you can use for post-processing is: Vendor, System, CPU (processor description), Cores, Chips (number of CPU’s), CoresPerChip (number of Cores per CPU), Speed, Result, Baseline, MCyclesPerCore (megacycles per core), MCyclesTotal (total megacycles), OS and Published. Note that megacycles calculations are based on the selected Exchange version, by default this is Exchange Server 2013.

A quick walk-through on the parameters:

  • CPU, Vendor or System can be used for partial matching on the respective attribute.
  • Type specifies what calculation to perform. Possible values are 2010 for Exchange Server 2010 and 2013 for Exchange Server 2013. Default value is 2013.
  • MinCores/MaxCores can be used to only return information for systems with this minimum or maximum number of cores. Note that you can not use MinCores and MaxCores at the same time.
  • MinChips/MaxChips can be used to only return information for systems with this minimum or maximum number of CPU’s. Note that you can not use MinChips and MaxChpis at the same time.
  • MinMegaCycles can be used to specify a treshold for the total megacycles value for returned items, using the specified Type for calculations.
  • Overhead can optionally be used to take into account a certain percentage for megacycles overhead. Default is 0 (0%).

Few notes:

  • MinCores/MaxCores and MinChips/MaxChips are mutually exclusive, because we can not specify both in the query against the SPECint database. However, you can use additional filtering on objects returned in the pipeline to distill information, e.g.
    Exchange-PQT.ps1 –MaxCores 32 –MaxChips 8 | Where { $_.Cores –ge 4 –and $_.Chips –ge 2}. 

    Do note that usage of these parameters is recommended when possibe, as it will minimize the result set from SPECint.

  • Make sure you set Type to 2010 when sizing for Exchange 2010.

Examples

Lookup the specifications of the server used by Jeff in his sizing example (Hewlett-Packard DL380p Gen8 server with Intel Xeon E5-2630 processors @2.30GHz). You will notice 25,481 is slightly off from Jeff’s 25,479, which is due to Jeff rounding numbers:

.\Exchange-PQT.ps1 -System 'DL380p Gen8'  -CPU 2630 | select System,MCycle*

Search all specs for systems from Dell containing x5470 processors and return megacycle information for Exchange 2010 calculations:

.\Exchange-PQT.ps1 -CPU x5470 -Vendor 'Dell Inc.' -Type 2010 | Select System,*cycle*

image

Calculate average SPECint 2006 rate values for  hex-core x5450 systems:

.\Exchange-PQT.ps1 -CPU x5470 | Where { $_.Cores -eq 8 } | Measure -Average Result

Search all specs for Dell systems using x5670 CPUs, with a minimum total of 16,000 megacycles and 20% megacycle overhead:

.\Exchange-PQT.ps1 –Vendor Dell -CPU x5670  -MinMegaCycles 16000 -Overhead 20 

image

Download
You can download the script from the TechNet Gallery page.

Feedback
Feedback is welcomed through the comments. If you got scripting suggestions or questions, do not hesitate using the contact form.

Revision History
See TechNet Gallery page.

Exchange 2010 SP3 Rollup 7

Exchange 2010 LogoToday the Exchange Team released Rollup 7 for Exchange Server 2010 Service Pack 3 (KB2961522). This update raises Exchange 2010 version number to 14.3.210.2.

This Rollup includes the following fixes:

  • 2983261 “HTTP 400 – Bad Request” error when you open a shared mailbox in Outlook Web App in an Exchange Server 2010 environment
  • 2982873 Outlook Web App logon times out in an Exchange Server 2010 environment
  • 2980300 Event 4999 is logged when the World Wide Web publishing service crashes after you install Exchange Server 2010 SP3
  • 2979253 Email messages that contain invalid control characters cannot be retrieved by an EWS-based application
  • 2978645 S/MIME option disappears when you use Outlook Web App in Internet Explorer 11 in an Exchange Server 2010 environment
  • 2977410 Email attachments are not visible in Outlook or other MAPI clients in an Exchange Server 2010 environment
  • 2976887 eDiscovery search fails if an on-premises Exchange Server 2010 mailbox has an Exchange Online archive mailbox
  • 2976322 Assistant stops processing new requests when Events in Queue value exceeds 500 in Exchange Server 2010
  • 2975988 S/MIME certificates with EKU Any Purpose (2.5.29.37.0) are not included in OAB in Exchange Server 2010
  • 2966923 Domain controller is overloaded after you change Active Directory configurations in Exchange Server 2010

Notes:

  • If you want to speed up the update process for systems without internet access, you can follow the procedure described here to disable publisher’s certificate revocation checking.
  • If you got a DAG and want to properly update the DAG members, check the instructions here.
  • Rollups are cumulative per service pack level, i.e. they contain fixes released in earlier update Rollups for the same product level (RTM, SP). This means you don’t need to install previous Rollups during a fresh installation but can start with the latest Rollup package.

As with any Hotfix, Rollup or Service Pack, I’d recommend to thoroughly test this rollup in a test and acceptance environment first, prior to implementing it in production.

You can download Exchange 2010 SP3 Rollup 7 here.

Impersonation: To be, or pretend to be

imageAs frequent readers of this blog may know, I made several Exchange-related scripts available to the community. Some of these scripts make use of what is called Exchange Web Services (EWS). I receive lots of questions via e-mail and through the comments about configuring impersonation or permission-related issues when running those scripts, which support delegated access as well as impersonation, against mailboxes. This blog shows how can configure delegation, why you should use impersonation, and how to configure impersonation on Exchange 2007 up to Exchange 2013 and Exchange Online in Office 365.

Introduction

EWS provides functionality to allow client applications, such as Outlook or OWA apps, tools, or in my case scripts, to communicate with Exchange server. Even Exchange itself makes uses of EWS when performing Free/Busy lookups by the Availability services for example. EWS was introduced in Exchange Server 2007 back in December 2006, which now seems decades ago.

Some of these EWS scripts or tools access or even manipulate mailbox contents. In the MAPI era, in order for you to access a mailbox that’s not yours, you required delegated full access permissions. These permissions could be granted at the mailbox, mailbox database or mailbox server level. The latter would grant you access to all mailboxes hosted in that mailbox database. For example, to grant an account Archibald full access permission on the mailbox of Nestor, you would typically use something like:

Add-MailboxPermission –Identity Nestor –User Archibald –AccessRights FullAccess –InheritanceType All

Note: Specifying InheritanceType is sometimes overlooked. Not specifying it only configures an Access Control Entry (ACE) on the top level folder (InheritanceType None), resulting in symptoms like scripts not processing subfolders for example.

EWS enables you to use another access method besides delegation, which is impersonation. Impersonation, as the many online available dictionaries may tell to you, is ‘an act of pretending to be another person for the purpose of entertainment or fraud’ or something along those lines. In the Exchange world, this means you can have an account which has the permission to pretend to be the owner of the mailbox, including being subject to the same effective permissions. So, if for some reason the owner only has Read permission on a certain folder, so will the impersonator. Typical use cases for impersonation are for example applications for archiving, reporting or migration, but also scheduled scripts that need to process mailboxes could be one.

Before we dive into the configuration itself, first some of the reasons why you should should prefer Impersonation over delegated access:

  • No mailbox needed for the account requesting access.
  • Throttling benefits, since the operation is subject to the throttling policy settings configured on the mailbox accessed, not the throttling policy configured on the mailbox requesting access. To bypass these delegate limits, one had to configure and assign a separate throttling policy with no limits for the account. Of course, a bad behaving application could then run without boundaries from a resource perspective, something throttling policies try to limit.
  • In Exchange 2010 and up, impersonation leverages Role Based Access Control, which is better manageable than a collection of distributed  ACEs.
  • Actions performed by the impersonator are on behalf of the impersonated. This may complicate auditing, as logging will come up with actions performed by the impersonated user, not the impersonator.

Note that where ‘user’ is specified below with regards to granting permissions, one could also specify a security group as well unless mentioned otherwise.

Impersonation on Exchange 2007

On Exchange 2007, you configure impersonation by granting the following two permissions:

  • The ms-Exch-EPI-Impersonation permission grants the impersonator the right to submit impersonation calls. It is configured on Client Access Servers. This does not grant the impersonation right, just the right the make the call through a CAS server.
  • The ms-Exch-EPI-May-Impersonate when granted, allows the impersonator to impersonate selected accounts.

To configure these permissions in your Exchange 2007 environment, use:

Get-ClientAccessServer | Add-AdPermission –User svcExchangeScripts –ExtendedRights ms-Exch-EPI-Impersonation

Then, we can configure impersonation permission on the mailbox level:

Get-Mailbox Tintin| Add-ADPermission –User svcExchangeScripts –ExtendedRights ms-Exch-EPI-May-Impersonate

on the database level:

Get-MailboxDatabase MailboxDB1 | Add-ADPermission –User svcExchangeScripts –ExtendedRights ms-Exch-EPI-May-Impersonate

or mailbox server level:

Get-MailboxServer MailboxServer1 | Add-ADPermission –User svcExchangeScripts –ExtendedRights ms-Exch-EPI-May-Impersonate

Be advised that members of the various built-in Admin groups are by default explicitly denied impersonation permissions on the server and database level, and deny overrules allow. You will notice this when querying impersonation configuration settings, for example on the database level (in the screenshot example, olrik was granted impersonation permissions):

Get-MailboxDatabase | Get-AdPermission | Where { $_.ExtendedRights –like ‘ms-Exch-EPI-Impersonation’} | Format-Table Identity, User, Deny, IsInherited, ExtendedRights –AutoSize

image

Note that permissions assigned on the mailbox may not immediately be reflected as you are administering them in Active Directory. Changes in Active Directory are subject to AD replication, and the Exchange Information Store caches information for up to 2 hours, so worst case it may take up to 2 hours and 15 minutes for new permission settings to be re-read from Active Directory.

Impersonation on Exchange 2010 and 2013

Exchange 2010 introduced Role Based Access Control, better known by its acronym RBAC. For a quick introduction to RBAC, see one of my earlier blogs here. There is a management role associated with impersonation, which is ApplicationImpersonation.

To enable a user impersonation rights, create a new assignment for ApplicationImpersonation and assign it to the user:

New-ManagementRoleAssignment –Name 'AIsvcExchangeScripts' –Role ApplicationImpersonation –User svcExchangeScripts

Note that if we want to assign these permissions to a security group, we need to use the SecurityGroup parameter instead of User, specifying the group name.

Now be careful, when used like this you will have granted that user or group permission to impersonate all users in your Exchange organization. Here is where RBAC comes into play, or more specific the RBAC feature named management role scopes. With write scopes for example, you can limit the scope of where you can make changes in Active Directory. For more information on management role scopes, see here.

Let  us assume we want to limit the scope to a distribution group named ‘All Employees’, using New-ManagementScope in combination with RecipientRestrictionFilter. Note that when specifying MemberOfGroup in the filter, you need to use the distinguishedName of the group:

New-ManagementScope –Name 'Employee Mailboxes' –RecipientRestrictionFilter { MemberOfGroup –eq 'CN=All Employees,OU=Distribution Groups,OU=NL,DC=contoso,DC=com'} 

We can then apply this scope to the assignment created earlier:

Set-ManagementRoleAssignment –Identity 'AIsvcExchangeScripts' –CustomWriteScope 'Employee Mailboxes'

Be advised that in a multi-forest environment, impersonation doesn’t work when you assign permissions to cross-forest accounts. You either need to assign impersonation permissions to an account residing in the same forest as Exchange, or create a linked role group.

Impersonation on Exchange Online

Impersonation is available in most Office 365 plans, but currently not in the small business plans.  To configure Impersonation in Exchange Online we need to connect anyway, so we’ll first open a remote PowerShell session to Exchange Online:

$EXO= New-PsSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell -AllowRedirection -Authentication Basic
Import-PsSession $EXO

Provide tenant administrator credentials when prompted. You can then see if you have the ApplicationImpersonation role at your disposal using:

Get-ManagementRole –Identity ApplicationImpersonation

If nothing is returned, you may need to resort to delegate access permissions.

Configuring impersonation is identical to configuring it in Exchange 2013. Nonetheless, some people may be more comfortable using the Exchange Admin Center. If so:

  1. Open up Exchange Admin Center.
  2. Navigate to Permissions > Admin Roles
  3. Now we can’t directly assign a management role through EAC, so assume we’ll create a role group for our application account by clicking New (+).
  4. Enter a name for your role group, e.g. ExchangeMaintenanceScripts.
  5. Add the role ApplicationImpersonation.
  6. Add the accounts which need Impersonation permissions, e.g. svcExchangeScript.
  7. Optionally, you can also select a Write Scope, which you need to create upfront through Exchange Management Shell.
  8. In Exchange on-premises, instead of a Write Scope you will have the option to select a a specific OU instead (scope filter RecipientRoot parameter) .
  9. When done, Save.

image

One word of caution: scopes are not automatically updated when objects referenced are relocated or change names. Now, for your own environment you may have this under control through some form of change management process. For Exchange Online however, your tenant might get relocated without notice. Therefor, should impersonation fail, verify any management scopes you may have defined for distinguishedName references, and check if they require updating, e.g.

Set-ManagementScope -Name 'All Employees' -RecipientRestrictionFilter { MemberOfGroup -eq 'CN=All Employees,OU=contoso.onmicrosoft.com,OU=Microsoft Exchange Hosted Organizations,DC=EURPR05A001,DC=prod,DC=outlook,DC=com'}

Final words

Note that many EWS-based scripts or tools do not natively support EWS but make use of the Exchange Web Services Managed API. This installable package consists of support files (e.g. DLL’s) which provide EWS functions to your PowerShell environment. You can download the current version of EWS Managed API here (2.2). You can read more on developing with EWS Managed API here, or you can have a peek at the source of code of one of my EWS scripts or the ones published by Exchange MVP-fellow Glen Scales’ here.

Exchange 2010 SP3 Rollup 6

Exchange 2010 LogoToday the Exchange Team released Rollup 6 for Exchange Server 2010 Service Pack 3 (KB2936871). This update raises Exchange 2010 version number to 14.3.195.1.

This Rollup includes the following fixes:

  • 2960652 Organizer name and meeting status field can be changed by EAS clients in an Exchange Server 2010 environment
  • 2957762 “A folder with same name already exists” error when you rename an Outlook folder in an Exchange Server 2010 environment
  • 2952799 Event ID 2084 occurs and Exchange server loses connection to the domain controllers in an Exchange Server 2010 environment
  • 2934091 Event ID 1000 and 7031 when users cannot connect to mailboxes in an Exchange Server 2010 environment
  • 2932402 Cannot move a mailbox after you install Exchange Server 2010 SP3 RU3 (KB2891587)
  • 2931842 EWS cannot identify the attachment in an Exchange Server 2010 environment
  • 2928703 Retention policy is applied unexpectedly to a folder when Outlook rule moves a copy in Exchange Server 2010
  • 2927265 Get-Message cmdlet does not respect the defined write scope in Exchange Server 2010
  • 2925273 Folder views are not updated when you arrange by categories in Outlook after you apply Exchange Server 2010 Service Pack 3 Update Rollup 3 or Update Rollup 4
  • 2924592 Exchange RPC Client Access service freezes when you open an attached file in Outlook Online mode in Exchange Server 2010
  • 2923865 Cannot connect to Exchange Server 2010 when the RPC Client Access service crashes

Notes:

  • If you want to speed up the update process for systems without internet access, you can follow the procedure described here to disable publisher’s certificate revocation checking.
  • If you got a DAG and want to properly update the DAG members, check the instructions here.
  • Rollups are cumulative, i.e. they contain fixes released in earlier update Rollups for the same product level (RTM, SP). This means you don’t need to install previous Rollups during a fresh installation but can start with the latest Rollup package.

As with any Hotfix, Rollup or Service Pack, I’d recommend to thoroughly test this rollup in a test and acceptance environment first, prior to implementing it in production.

You can download Exchange 2010 SP3 Rollup 6 here.

Exchange 2010 SP3 Rollup 5

Exchange 2010 LogoToday the Exchange Team also released Rollup 5 for Exchange Server 2010 Service Pack 3 (KB2917508). This update raises Exchange 2010 version number to 14.3.181.6.

This Rollup also adds support for using Windows Server 2012 R12 domain controllers in your Exchange 2010 SP3 RU5 environment as well as support for running Windows Server 2012 R2 forest and domain functional levels.

This Rollup includes the following fixes:

  • 2887459 Public folder expiry time is set incorrectly in Exchange Server 2010 SP3
  • 2892257 Email items are lost when you move items between shared folders by using EWS delegate access
  • 2897935 “Cannot save the object ‘\FolderName'” error message when you try to replicate Exchange Server 2010 public folders
  • 2898908 EdgeTransport.exe crashes if the From field is empty in an email message
  • 2903831 Only a single character is allowed in the disclaimer content in ECP
  • 2904459 RPC Client Access service crashes if you add “Signed By” or “Send From” column in Outlook online mode
  • 2913413 RPC Client Access service crashes with an exception in Exchange Server 2010
  • 2913999 Meeting request body and instructions are lost in delegate’s auto-forwarded meeting request
  • 2916836 EdgeTransport.exe crashes when a transport rule sends a rejection message to an empty address
  • 2919513 Memory leak or memory corruption occurs in Exchange Server 2010
  • 2924971 RPC Client Access service stops when you select an inactive search folder in Outlook 2007 in an Exchange Server 2010 SP3 environment
  • 2926057 EdgeTransport.exe crashes if seek operation failed in Exchange Server 2010
  • 2927856 Incorrect recurring meeting if disclaimer transport rule is enabled in Exchange Server 2010

Notes:

  • As of Service Pack 2 Rollup 4, its no longer required to disable/re-enable ForeFront Protection for Exchange using the fscutility to be able to install the Rollup properly. However, if you want to remain in control, you can disable ForeFront before installing the Rollup using fscutility /disable and re-enable it afterwards using fscutility /enable.
  • If you want to speed up the update process for systems without internet access, you can follow the procedure described here to disable publisher’s certificate revocation checking.
  • If you got a DAG and want to properly update the DAG members, check the instructions here.
  • Rollups are cumulative, i.e. they contain fixes released in earlier update Rollups for the same product level (RTM, SP). This means you don’t need to install previous Rollups during a fresh installation but can start with the latest Rollup package.

As with any Hotfix, Rollup or Service Pack, I’d recommend to thoroughly test this rollup in a test and acceptance environment first, prior to implementing it in production.

You can download Exchange 2010 SP3 Rollup 5 here.

Cmdlet Extension Agents & XML Case Sensitivity

Ex2013 LogoOccasionally, I get requests to come to the aid of a fellow IT professional (I seldomly get requests to come to the aid of fair maidens. Oh, well). This weekend I responded to one of those distress calls by someone who couldn’t get his Cmdlet Extension Agent to work. This post is a quick heads-up for the collective memory of IT Professionals as it took me quiet a bit of screen staring to spot the issue.

For those unfamiliar with Cmdlet Extension Agents, they are modules which allow you to enhance or customize the behavior of cmdlets in Exchange. For example, the built-in Mailbox Resources Management agent is responsible for picking the database when creating new mailboxes when a database hasn’t been specified. By means of the Script Agent and an XML file named ScriptingAgentConfig.xml containing PowerShell code fragments, you can enhance and tailor Exchange cmdlets to your own needs. For those interested in Cmdlet Extension Agents, I did two earlier articles on Cmdlet Extension Agents, here and here.

The code provided was a simple agent to enhance New-Mailbox with enabling SingleItemRecovery after the mailbox was created:

<?xml version="1.0" encoding="utf-8" ?>
<Configuration version="1.0">    
        <Feature Name="Mailbox Provisioning" cmdlets="new-mailbox">
         <ApiCall Name="OnComplete">
             if($succeeded) {
                $newmailbox = $provisioningHandler.UserSpecifiedParameters["Name"]
                set-mailbox $newmailbox -SingleItemRecoveryEnabled $true
                }
        </ApiCall>
        </Feature>
</Configuration>

The Scripting Agent was enabled using Enable-CmdletExtensionAgent. Yet, for some reason after creating a new mailbox, SingleItemRecoveryEnabled wasn’t enabled. Running New-Mailbox in Verbose mode showed that the Scripting Agent did not come into play:

Capture1Now know that debugging and troubleshooting Cmdlet Extension Agents can be an unpleasant task since you put PowerShell code in XML files and there is no way to easily perform simple tests except running the Cmdlet you’re customizing or developing script fragments in an external PowerShell script and copy/paste it in the Scripting Agent XML file when you think it’s ready for and want to perform some final tests.

I didn’t immediately spot it, so to see if the problem was actually in the XML I picked the example of my 2nd article on Cmdlet Extension Agents and I compared it with the non-working XML using WinMerge (which by the way is an excellent tool to compare code or plain texts):

WinMergeIt took some time to discover why the Scripting Agent wouldn’t pick up the XML and it can be easily overlooked. The culprit in underlined in red: the C of the Cmdlets attribute in the Feature tag should be uppercase. Doh! This case sensitivity is perhaps not a primary suspect by Windows folks, as mostly we don’t have to worry about it and things “just work”, but in the case of XML it is essential. The XML standard prescribes that element names (<Feature> .. </Feature>) and attribute names (<Feature Cmdlets=..>) are case-sensitive entitling the Scripting Agent to be strict.

Can’t Create Mailboxes in Remote Sites

Ex2013 LogoRecently I got an e-mail from someone who had problems creating mailboxes in a new environment. When trying to create a mailbox, he received a following message stating, “Load balancing failed to find a valid mailbox database.” Apparently, the Mailbox Resources Management Agent (a Cmdlet Extension Agent) could not find an eligible mailbox database candidate.

image

The MRMA uses the following selection process when picking a candidate for mailbox creation or moving:

  1. Create a list of all mailbox databases;
  2. Remove databases marked for exclusion;
  3. Remove databases out of the management scope;
  4. Remove databases from remote (AD) sites;
  5. Pick a random online, healthy database from the list.

This person had a DAG, two mailbox databases (MDB1, MDB2) and two sites (AMS and LON).

We first checked the more or less obvious, which is to see if databases are not excluded from the provisioning process, so we entered Get-MailboxDatabase | fl *FromProvisioning:

image

Databases seemed enabled for provisioning. We then checked the status of the active database copies:

image

The copies looked healthy, but we noticed all databases were mounted in a remote site (derived from the server name starting with LON; we’re working from AMS). Looking back at the database selection process, it explained why it probably didn’t work and since the active copies should be moved back to the preferred site AMS anyway we moved the active copies back:

image

After moving the active database copies back to the location where we were performing our cmdlets from solved things.

Note that we could have discovered the issue using the Verbose parameter with the cmdlet. For example, New-Mailbox in conjunction with Verbose will show the selection process. The following screenshot shows an unsuccessful selection process considering available databases:

image

This screenshot shows a successful selection process.

image

More information on automatic mailbox distribution and controlling its behavior here.