Issues with July Updates of Windows

bandaidLast Update July 19th: Corrected Update information.

About a week ago, Microsoft released the July Updates for Windows systems. Unfortunately, something must have gone wrong in quality control, because people were reporting all sorts of issues, mostly related to IIS and Exchange servers.

The issue is created at the operating system level, probably due to changes in networking as mentioned in the July update notes. Therefor, symptoms can be experienced on systems running Exchange Server 2016 or even back to Exchange Server 2007.

Some of the symptoms are:

  • The World Wide Web Publishing Service – W3SVC – won’t come up, remains in a “stopping” state, but cannot fully stop or it cannot be restarted.
  • Exchange Transport and SMTP services becomes unresponsive or stops, causing mail flow issues (Source).

The issues were serious enough to have the Exchange PG publish a notice.

Meanwhile, Microsoft has released a superseding update for Windows Server 2016, and updates for older operating systems. However, looking at the information provided with updates for older operating systems, there are fixes for the original security updates, and (previews of) Monthly Rollups for the July updates. Replacements and updates may manifest themselves in Windows Update only after installing the original – faulty – update, meaning you might have to go through more than one Windows Update cycle (and possibly reboot) for the updates to become visible and installable. This applies to the Monthly Rollups as well.

The table below contains information on the original rollups and updates, the update you need to apply, and the type of update.

Operating System Original Update Update Type Comments
Windows Server 2016 KB4338814 KB4345418 Monthly Rollup Replacement
Windows Server 2012 R2 KB4338815 KB4338831 Monthly Rollup Replacement
KB4338824 KB4345424 Security Update Update for v1
Windows Server 2012 KB4338830 KB4338816 Monthly Rollup Replacement
KB4338820 KB4345425 Security Update Update for v1
Windows Server 2008 R2 KB4338823 KB4345459 Security Update Update for v1
KB4338818 KB4338821 Monthly Rollup Replacement
Windows Server 2008 KB4295656 KB4345397 Security Update Update for v1

Finally, apart from adopting a less aggressive updating strategy, this again shows unfortunately that having a separate production environment next to your test environment is no frivolous luxury.

Security Updates for Exchange 2016, 2013 and 2010

Ex2013 LogoA quick heads-up for those that missed it that earlier this month, as Microsoft released security updates for supported releases of Exchange Server 2016 and 2013 as well as Exchange Server 2010.

The security updates patch issues as reported in the following Microsoft Common Vulnerabilities and Exposures:

  • CVE-2018-8151 – Microsoft Exchange Memory Corruption Vulnerability
  • CVE-2018-8154 – Microsoft Exchange Memory Corruption Vulnerability
  • CVE-2018-8159 – Microsoft Exchange Elevation of Privilege Vulnerability
  • CVE-2018-8153 – Microsoft Exchange Spoofing Vulnerability
  • CVE-2018-8152 – Microsoft Exchange Server Elevation of Privilege Vulnerability

You can download the security updates here:

You may notice that Exchange 2013 Service Pack 1 is still in there, but this is because Cumulative Updates and Service Packs are on a different servicing model. Every Cumulative Update is supported for three months after the release of the next Cumulative Update; Exchange 2013 SP1 entered extended support early April, and will only receive critical updates such as this one.

Be advised that for Exchange 2013 and 2016, Security Updates are Cumulative Update level specific. While the downloaded security updates may carry the same name, the files are different and you cannot apply the downloaded security update file for Exchange 2016 CU8 to Exchange 2016 CU9. I suggest adding some form of identification of the Cumulative Update to the file name when you save it, e.g. Exchange2016-KB4092041-x64-en-CU9.msp.

As with any patch or update, I’d recommend to thoroughly test this in a test and acceptance environment first, prior to implementing it in production.


Exchange 2010-2016 Security Fixes

Ex2013 LogoMicrosoft released security updates to fix a remote code execution vulnerability in Exchange Server. The related knowledge base article is KB4018588.

More information is contained in the following Common Vulnerabilities and Exposures articles:

  • CVE-2017-8521 – Scripting Engine Memory Corruption Vulnerability
  • CVE-2017-8559 – Microsoft Exchange Cross-Site Scripting Vulnerability
  • CVE-2017-8560 – Microsoft Exchange Cross-Site Scripting Vulnerability

Depending on the lifecycle status of the product, fixes are made available either through a Rollup or as a security fix for the following product levels:

As you might notice, the security fix is made available for the N-1 builds of Exchange 2013 and Exchange 2016. This could imply the issue was addressed in the latest builds of those products. I hope to receive official confirmation on this soon.

The issue is deemed Important, which means organizations are advised to apply these updates at the earliest opportunity. However, as with any update, it is recommended to thoroughly test updates and fixes prior to deploying them in a production environment.

MS17-015: Security Fix for Exchange 2013 SP1+CU14 & 2016 CU3

Ex2013 LogoMicrosoft published security fixes for the issue described in bulletin MS17-105. Fixes have been released for the following product levels:

You are reading it correctly: the later Cumulative Updates are not affected. Earlier builds will not receive a security fix, as support is provided up to N-2 generation builds. Reason for Exchange 2013 SP1 being in there is that Service Packs are on a different support scheme.

Note that this Rollup or security fix replaces MS16-108 (kb3184736) – you can install MS13-105 over installations containing this security fix (no need to uninstall it first).

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.

Comparing Active Directory Permissions

Every now and then you might be required to compare Active Directory account permissions. When it concerns one or few accounts, you could do the manual side-by-side comparison using Active Directory and Computers. However, when you need to check multiple accounts this task becomes tedious.

Now you could follow the practice laid out by Exchange fellow Andy Grogan here,  generating permissions output using Quest Active Roles and comparing the textual output with a comparison utility like WinMerge or WinDiff. But you can also perform this comparison using PowerShell’s Compare-Object cmdlet, which I’ll show you here.

For this task we’re going to use the Quest AD extensions (Active Roles), which you can download here. Install these extensions on a domain-joined system where PowerShell is already installed. After installation, start the ActiveRoles Management Shell and enter the following, where IdA and IdB are the Identities of the objects you want to compare:

$a= Get-QadPermission <IdA> -Inherited -SchemaDefault
$b= Get-QadPermission <IdB> -Inherited –SchemaDefault

Now $a and $b contain the permission sets of both objects. Next, we’re going to utilize compare-object to compare these two sets. When we use Compare-Object $a $b you get the following output:


Not quite helpful this output but it isn’t unexpected. Since we’re comparing two object sets compare-object generates a result with objects. We can make this more readable by specifying the PassThru parameter so we can post-process these objects, like displaying certain fields using the Format-Table cmdlet, e.g.

Compare-Object $a $b -PassThru | ft SideIndicator,AccountName,Rights,Source,ApplyTo


Presto! The SideIndicator  is included to see in which set the attribute is contained, e.g. “<=” means the element is contained in the 1st specified (reference) object and “=>” means its is contained in the 2nd (difference) object.

If you want to include equal objects in the output as well, add the IncludeEqual parameter to the Compare-Object cmdlet.

SSL client compatibility

Exchange fellow Jetze Mellema blogged (in Dutch) about a useful online check, which will allow you to check your current client – computer or smartphone – against a set of certificates from different vendors. The short – and more memorable and mobile friendly – URL for this test is as follows:

The creator, SSL reseller FairSSL, also keep a total overview, which is located at Note that the table’s titles are hard to read, but when hovering above the cells the corresponding product will be displayed.

Exchange Server 2010 Architecture poster

Finally, the long awaited Exchange Server 2010 Architecture Poster is here!

This is similar to the Exchange 2007 Component Architecture poster and contains the architecture highlights and feature set of Microsoft Exchange Server 2010. This architecture poster is additional to the already published Microsoft Exchange Server 2010 Transport Server Role Architecture Diagrams which you could already get here.

You can download the Microsoft Exchange Server 2010 Architecture poster here.

Outlook 2003 & Exchange 2010

Problems connecting Outlook 2003 to Exchange 2010 could turn out to be an unpleasant surprise after migrating to Exchange Server 2010 over the weekend. The problem is caused by Outlook 2003 not using encrypted RPC connections to the Exchange Server by default, and Exchange 2010 requiring  encrypted RPC connections (contrary to earlier Exchange versions). The solution is simple but you have several options; The way you should proceed not only depends on your situation but you also need to check the company’s security policies regarding communications encryption which might restrict your options.

Change how Outlook connects

Enabling RPC encryption in Outlook can be performed per configuration (Outlook profile) or using a Group Policy Object.To manual change the way Outlook connects:

  1. Open Control Panel > Mail > Show Profile > <Select Profile>
  2. Select Properties > E-mail Accounts > View or Change existing e-mail accounts
  3. Select Next > Microsoft Exchange Server > Change > More Settings > Microsoft Exchange Server > Security
  4. There, check Encrypt data between Microsoft Office Outlook and Microsoft Exchange Server
  5. Close everything with OK > Next > Finish > Close > OK.

You can also control the RPC encryption setting centrally for Outlook clients using the following registry value as part of a GPO:

DWORD: EnableRPCEncryption
Value: 1

For a more detaild guide on implementing the Outlook profile change or implementing the GPO using an administrative template, consult KB2006508.

Change how Exchange 2010 accepts
To change the way Exchange 2010 accepts RPC connections, i.e. disable the RPC encryption requirement, you need to disable the RPC encryption for Exchange Server 2010 CAS servers (remember, in Exchange 2010 RPC connections are handled by the CAS server role), use the following cmdlet:

Set-RpcClientAccess –Server <Server Name> –EncryptionRequired $False

Exchange 2010 Role Based Access Control

Those who are about to switch to Exchange 2010 from Exchange 2007 will encounter major changes (and challenges) in the Exchange permissions model.  For those still on Exchange 2003 (or earlier ..), changes are more or less the same.

Exchange 2007

Before we dive into Exchange 2010 we’ll have a quick look at how permissions and delegations are managed in Exchange 2007. In Exchange 2007 we get the following security groups out of the box:

  • Exchange Organization Administrators;
  • Exchange Recipient Administrators;
  • Exchange Server Administrators;
  • Exchange View Only Administrators;
  • Exchange Public Folder Administrators.

That seems limited and very task oriented. Memberships are managed using the Exchange Management Console or through the cmdlets Add-ExchangeAdministrator, Get-ExchangeAdministrator en Remove-ExchangeAdministrator. Also, by default, Recipient Administrators get permissions on all recipients within the Exchange organization. Domain or OU delegations are possible, but require a little additional configuration (see

Exchange 2010

Here comes Exchange 2010. New in Exchange is management of delegation and permissions through the so called Role Based Access Control model, shortened to RBAC. RBAC is partially configurable through the RBAC User Editor (Exchange Management Console > Toolbox) or fully using cmdlets. The RBAC model is based on three pillars, Who, What and Where.


The Who (not the band) determines which user (in RBAC users are represented by mailboxes) or group (Universal Security Group) receives permissions. This information is stored in Role Groups, which can be managed through the RoleGroup and RoleGroupMember cmdlets.

To create a new Role Group we use the New-RoleGroup, like:
New-RoleGroup “UM Pincode Resetter” –Roles “Reset UM Pin”

Users or groups can be added directly to the Role Group at creation time, or can be added by using the Add-RoleGroupMember, like:
Add-RoleGroupMember “UM Pincode Resetter” –Member Angelique

To manage a Role Group, one has to be a member of the Organization Management Role Group or be the manager of the Role Group as determined by the ManagedBy attribute. Pay attention, members of the Organization Management Role Group manage the Organization Management Role Group. You could create a situation where nobody is able to manage anything.

Take note that a Role Group is nothing else but a Universal Security Group with a special flag indicating the USG is a Role Group. In Active Directory, Role Groups are located in the Microsoft Exchange Security Groups OU.


The What decides what permissions are assigned by creating sets of cmdlets and parameters. This information is stored in RBAC’s Management Roles which can be managed through the ManagementRole and ManagementRoleEntry cmdlets.

Of itself, Exchange 2010 knows about 65 Management Roles, which can be queries using:

The permissions of a Management Role can be retrieved through the Get-ManagementRole (Roles attribute) or through the Get-ManagementRoleEntry cmdlet:
Get-ManagementRoleEntry “UM Mailboxes\*”

What we see are all cmdlets and parameters available to the Management Role “UM Mailboxes”.

When creating our own Management Role, we need to specify an existing Management Role, the so called parent:
New-ManagementRole –Name “Reset UM Pin” –Parent “UM Mailboxes”

Be advised only custom Management Roles can be removed and all permissions of a Management Role should be removed before the Management Role itself can be removed. By specifying the recurse parameter in the Remove-ManagementRole cmdlet you can perform cascaded deletes of custom Management Roles with a parent-child relationship.

After creating the custom Management Role with initial settings taken from the parent, we can start adding or removing permissions. Be advised that Management Roles require at least one Management Role Entry. Also, in order for Set cmdlets to work, you should allow the Get counterparts, so we will start by removing all ManagementRoleEntry items but one:
Get-ManagementRoleEntry “Reset UM Pin\*” | where { $ –ne “Get-UMMailboxPIN”} | Remove-ManagementRoleEntry

Next, we can add custom permissions using Add-ManagementRoleEntry:
Add-ManagementRoleEntry “Reset UM Pin\Set-UMMailboxPIN” –Parameters “Identity,Pin,PinExpired,LockedOut”

What might be helpful is that Get-ManagementRoleEntry can be used to retrieve all Management Roles which are allowed to execute certain cmdlets with what parameters, e.g.:
Get-ManagementRoleEntry “*\*” | where { $_.Name –eq “Set-User” }

Where determines the scope, which can be anything from a certain group of users, a server or an Active Directory site to an Organizational Unit or complete organization. RBAC has two types of scopes. First are Implicit scopes, which are scopes defined by the default Management Roles, e.g. Organization, MyGAL, Self, MyDistributionGroups, OrganizationConfig and None. Second type are Explicit scopes, which are predefined or custom scopes.

To view the scopes of a Management Role use the Get-ManagementRole, e.g.:
Get-ManagementRole “UM Mailboxes” | fl *scope*

As we can see, a Management Role has four scopes:

  • Recipient Read Scope: Which AD recipient objects one can read from;
  • Recipient Write Scope: Which AD recipient objects one can write to;
  • Configuration Read Scope: Which AD configuration objects one can read from;
  • Configuration Write Scope: Which AD configuration objects one can write to.

As said earlier, new Management Role entries must be based on an existing Management Role. At creation time the new Management Role will inherit (i.e. copy settings) the original scopes from the parent, after which they can be changed. Also, remember that the Write scope must be equal or smaller than the Read scope; you need to be able to Get things before you can Set things.

To create a custom scope use the New-ManagementScope cmdlet with one of the following, mutually exclusive, filters:

  • RecipientRestrictionFilter to filter Recipients. You can optionally specify the root using the RecipientRoot, otherwise it will apply to the whole organization;
  • ServerRestrictionFilter to filter Server objects;
  • ServerList to filter server names.

New-ManagementScope –Name “NL Site” –ServerRestrictionFilter {ServerSite –eq “NL”}
New-ManagementScope –Name “Staff Secretaresses” –RecipientRoot “domain.local/Staff” –RecipientRestrictionFilter {
memberofgroup -eq “cn=Secretaries,ou=Users,dc=domain,dc=local” }

Regarding the possibilities of filtering Exchange 2010 refers to Exchange 2007 documentation, see For more background information on scopes, see


After defining the Who, What and Where we can start combining these elements by using Role Assignments. A Role Assignment is the link between a Role Group and a Management Role, with additional attributes like Recipient and Configuration Scopes.

Existing Role Assignments of a Role Group can be retrieved using Get-RoleGroup, e.g.:
Get-RoleGroup “UM management” | fl

The attribute RoleAssignment contains the current Role Assignments. All Role Assignments can be queried using Get-ManagementRoleAssignment, e.g.:
Get-ManagementRoleAssignment “UM Mailboxes-UM Management” | fl

As we can see, Microsoft used a combination of the ManagementRole and RoleGroup names to label Role Assignments. This is good practice and makes it easier to understand – and remember – which Role Assignment affects which Management Role and Role Group.

Using New-ManagementRoleAssignment we can assign a ManagementRole to a Role Group or other USG, a policy (more on this perhaps in another article) or user (mailbox), e.g.
New-ManagementRoleAssignment –Name “Reset UM Pin-UM Pincode Resetter” –Role “Reset UM Pin” -SecurityGroup “UM Pincode Resetter” –CustomRecipientWriteScope “Staff Secretaresses”


The Exchange 2010 and RBAC model create new opportunities for customers. Large companies, who probably already have complex delegation models in-place, will like the more fine grained controls to support business requirements. Their challenge lies in converting their existing model to the new designed RBAC model. For smaller customers the default set of roles, groups, scopes and assignments might appear overwhelming at first, but eventually be found an asset as it supports least privilege security model and get rid of the (Exchange) Adminsistrators surplus.