Category Archives: Exchange 2007

Post navigation

Today, the Exchange Team released the March updates for Exchange Server 2013 and 2016, as well as Exchange Server 2010 and 2007. The latter will receive its last update, as Exchange 2007 will reach end-of-life April 11, 2017.

As announced in December updates, Exchange 2013 CU16 and Exchange 2016 CU5 require .NET 4.6.2. The recommended upgrade paths:

If you are still on .NET 4.6.1, you can upgrade to .NET 4.6.2 prior of after installing the latest Cumulative Update.

If you are on .NET 4.52, upgrade to Exchange 2016 CU4 or Exchange 2013 CU15 if you are not already on that level, then upgrade to .NET 4.6.2, and finally upgrade to the the latest Cumulative Update.

The Cumulative Updates also include DST changes, which is also contained in the latest Rollups published for Exchange 2010 and 2007.

KB4014076 Migration ends and errors reported when you on-board or off-board a mailbox through Exchange Online in an Exchange Server 2010 hybrid environment

KB4014075 UNC path does not open in OWA when the path contains non-ASCII characters in an Exchange Server 2010 environment

KB4013917 You cannot search in a shared mailbox through OWA in an Exchange Server 2010 Service Pack 3 (Update Rollup 15 or 16) environment

KB4012911 Culture element is added in the wrong order when you use the ResolveNames operation in EWS in Exchange Server 2010

Notes:

Exchange 2016 CU5 doesn’t include schema changes, however, Exchange 2016 CU5 as well as Exchange 2013 CU16 may introduce RBAC changes in your environment. Where applicable, use setup /PrepareSchema to update the schema or /PrepareAD to apply RBAC changes, before deploying or updating Exchange servers. To verify this step has been performed, consult the Exchange schema overview.

When upgrading your Exchange 2013 or 2016 installation, don’t forget to put the server in maintenance mode when required. Do note that upgrading, before installing the Exchange binaries, setup will put the server in server-wide offline-mode.

Once installed, you can’t uninstall a Cumulative Update nor any of the installed Exchange server roles.

The order of upgrading servers with Cumulative Updates is irrelevant.

Caution: As for any update, I recommend to thoroughly test updates in a test environment prior to implementing them in production. When you lack such facilities, hold out a few days and monitor the comments on the original publication or forums for any issues.

Today, the Exchange Team released the December updates for Exchange Server 2013 and 2016, as well as Exchange Server 2010 and 2007.

Changes introduced in Exchange Server 2016 CU4 are an updated OWA composition window, and on Windows Server 2016, KB3206632 needs to be present before CU4 can be deployed. This KB fixes – among other things – the problem with DAG members experiencing crashing IIS application pools. Be advised that the KB3206632 update for Windows Server 2016 is a whopping 1 GB. You can download this update here.

The biggest change for Exchange Server 2013 is support for .NET 4.6.2. Be advised organizations running Exchange 2016 or 2013 on .NET 4.6.1 should start testing with and planning to deploy .NET 4.6.2, as the March updates will require .NET 4.6.2, which is currently still optional.

Both Cumulative Updates introduce an important fix for indexing of Public Folder when they were in the process of being migrated. To ensure proper indexing, it is recommended to move public folder mailboxes to a different database so they will get indexed properly.

The Cumulative Updates also include DST changes, which is also contained in the latest Rollups published for Exchange 2010 and 2007.

KB 3211326 “ConversionFailedException” error when emails are sent on the hour in Exchange Server 2013

Notes:

Exchange 2016 CU4 doesn’t incldue schema changes compared to CU4, however, Exchange 2016 CU4 as well as Exchange 2013 CU15 may introduce RBAC changes in your environment. Where applicable, use setup /PrepareSchema to update the schema or /PrepareAD to apply RBAC changes, before deploying or updating Exchange servers. To verify this step has been performed, consult the Exchange schema overview.

When upgrading your Exchange 2013 or 2016 installation, don’t forget to put the server in maintenance mode when required. Do note that upgrading, before installing the Exchange binaries, setup will put the server in server-wide offline-mode.

Once installed, you can’t uninstall a Cumulative Update nor any of the installed Exchange server roles.

The order of upgrading servers with Cumulative Updates is irrelevant.

Caution: As for any update, I recommend to thoroughly test updates in a test environment prior to implementing them in production. When you lack such facilities, hold out a few days and monitor the comments on the original publication or TechNet forum for any issues.

Exchange 2016 CU1 includes schema changes, and Exchange 2013 CU12 may introduce RBAC changes in your environment. When applicable, make sure you run PrepareSchema /PrepareAD before deploying. To verify this step has been performed, consult the Exchange schema overview.

If you have deployed KB3097966 on your Exchange server running on Windows Server 2012 R2, you may want to manually recompile the .NET assemblies before upgrading Exchange to significantly speed up the process. To accomplish this, run the following on every Exchange server on Windows Server 2012 R2:“%windir%\Microsoft.NET\Framework64\v4.0.30319\ngen.exe update”
Don’t get upset by the messy output and any error messages; if the result of this command shown in the output is ‘0’ you’re good to go.

Be advised .NET Framework 4.6.1 is still not supported; make sure you don’t install this .NET update on your Exchange servers.

The Windows Management Framework (WMF)/ PowerShell version 5 is not supported. Don’t install this on your Exchange servers.

When using Exchange hybrid deployments or Exchange Online Archiving (EOA), you are required to stay current.

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.

Once installed, you can’t uninstall a Cumulative Update nor any of the installed Exchange server roles.

The order of upgrading servers with Cumulative Updates is irrelevant.

Rollups are cumulative per service pack level, meaning you can apply the latest Rollup for Service Pack X to a Service Pack X installation.

Finally, as always for any Hotfix, Rollup, Service Pack or Cumulative Update, I’d recommend to thoroughly test this in a test and acceptance environment first, prior to implementing it in production. When you lack such facilities, hold out a week or two and monitor the comments on the original article or TechNet forum for any issues.

The Exchange Team released Rollup 12 for Exchange Server 2010 Service Pack 3 (KB3096066) as well as Rollup 18 for Exchange Server 2007 Service Pack 3 (KB3078672). These update raise version numbers to 14.3.279.2 and 8.3.445.0 respectively.

Apart from a Daylight Savings Time update, documented here, these Rollups contain the following fixes:

KB 3097219 Organizer’s name isn’t displayed in the subject of the recurring meeting requests in Exchange Server 2010

KB 3106421 Very long URLs in an email message don’t open in OWA in Internet Explorer

KB 3115809 Mailboxes can be accessed when the DefaultNetworkCredentials option is selected when you use Exchange Web Services Managed API to connect to Exchange Server

Exchange Server 2007 SP3 Rollup 18:

KB 3106421 Very long URLs in an email message don’t open in OWA in Internet Explorer

Notes:

If you want to speed up the update process for systems without internet access, follow the procedure described here to disable publisher’s certificate revocation checking.

If you got an Exchange 2010 DAG, and want to properly update the DAG members, check the instructions here.

As for any Hotfix, Rollup, Service Pack or Cumulative Update, apply this update to a acceptance environment first, prior to implementing it in production. When you lack such facilities, hold out a certain period and monitor the comments on the release article or TechNet forum for any issues.

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 can apply the latest Rollup after installing a fresh installation of RTM or SPx version, for that product level.

The Exchange Team released Rollup 10 for Exchange Server 2010 Service Pack 3 (KB3049853) as well as Rollup 17 for Exchange Server 2007 Service Pack 3 (KB3056710). These update raises the version numbers to 14.3.248.2 and 8.3.417.1 respectively.

Rollup 10 contains the following fixes for Exchange Server 2010 SP3:

KB 3069055 Various DAG maintenance scripts do not work in an Exchange Server 2010 environment

KB 3057422 “MapiExceptionNoAccess: Unable to query table rows” error and some mailboxes cannot be moved

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 an Exchange 2010 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.

When running ForeFront Protection for Exchange, make sure you disable ForeFront before installing the rollup and re-enable it afterwards, otherwise the Information Store and Transport services may not start. You can disable ForeFront using fscutility /disable and enable it using the fscutility /enable command;

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;

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 2007 SP3 Rollup 15 here.

When running ForeFront Protection for Exchange, make sure you disable ForeFront before installing the rollup and re-enable it afterwards, otherwise the Information Store and Transport services may not start. You can disable ForeFront using fscutility /disable and enable it using the fscutility /enable command;

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;

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.

Like this:

As 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:

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:

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

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:

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:

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:

Optionally, you can also select a Write Scope, which you need to create upfront through Exchange Management Shell.

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) .

When done, Save.

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.

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.

This Rollup also adds support for using Windows Server 2012 R12 domain controllers in your Exchange 2007 SP3 RU13 environment; it does not add support for running Windows Server 2012 R2 forest or domain functional levels.

Notes:

When running ForeFront Protection for Exchange, make sure you disable ForeFront before installing the rollup and re-enable it afterwards, otherwise the Information Store and Transport services may not start. You can disable ForeFront using fscutility /disable and enable it using the fscutility /enable command;

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;

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.

Follow Us on Twitter

Follow Us via Email

Enter your email address to follow this blog and receive notifications of new posts by e-mail.

Copyright

Unauthorized use or duplication of this material without permission from EighTwOne is strictly prohibited. Excerpts and links may be used, provided full and clear credit is given to EighTwOne with appropriate direction to original content.

Disclaimer

Content is verified as far as possible, however, usage is at your own risk. EighTwOne does not accept liability for information contained on sites linked to. Opinions expressed are my own and do not represent my employer’s positions, strategies or opinions.

About Michel de Rooij

Michel is an Office Servers and Services MVP with a PowerShell affection, and publisher of EighTwOne. You can find him on Twitter, LinkedIn, Facebook, or Google+. Use the Contact form for questions, consulting, support or other engagements.