Category Archives: #IAMMEC


Join us for a discussion around the new Shell Shock vulnerability, Windows 10 preview, iPhone 6, iOS8, Exchange CU6 release and more!

Subscribe in iTunes!

Show notes:

  1. Shell Shock – 2:58 –
  2. BendGate – 10:30 –
  3. iPhone 6 and Apple Pay – 17:26 –
  4. Windows 10 – 22:03 –
  5. Microsoft Exchange 2013 CU6 Released! – 28:21 –
  6. Problems with Microsoft Exchange 2013 CU6 – 30:58 –
    2. KB:2997209 – Exchange Server 2013 databases unexpectedly fail over in a co-existence environment with Exchange Server 2007
    3. KB:2997847 – You cannot route ActiveSync traffic to Exchange 2007 mailboxes after you upgrade to Exchange 2013 CU6
  7. Registry Entry to Control MAPI over HTTP – 35:53 –
  8. Block AutoDiscover – 36:48 –
  9. Microsoft Round 2 of layoffs  – 40:37 –
  10. iOS 8 Issues – 45:21


Subscribe in iTunes!

Show notes:

  1. Surface Pro 3 – Weeks later – 2:35
  2. Phone 8.1 Update 1 released for developer preview –  7:45 –
  3. What Happened to TechEd? – 10:15 –
  4. OneNote Update – 19:45 –
  5. NFL and the Surface  –  22:20 –
  6. Secure Exchange – 31:50 –
  7. Managing Mailbox Quotas – 35:45 –
  8. Gather Transaction Logs Easy – 40:30 –
  9. Active Directory and Azure  – 43:10 –
  10. Exchange 2013 Hybrid Deployment Updates – 44:40 –
  11. PAM and Cluster Core Resources – 46:05 –

How To: Exchange 2013 SP1 and MAPI over HTTP

The list of features available with Exchange 2013 SP1 when combined with Outlook 2013 SP1 is certainly compelling. This specific combination, in particular, introduces a new client connection mechanism using Messaging Application Programming Interface (MAPI) over HTTP. Why the change in the client connection method? The reliability of the existing RPC over HTTP connection method between the Client Access server and Outlook client became problematic within certain network environments. The complexities of load balanced VIP’s along with connected Outlook clients changing networks (LAN to WLAN) proved to tax the performance of the legacy RPC Proxy found within IIS. Enter MAPI over HTTP! This connection method will allow Outlook to dump the aging RPC protocol in favor of an HTTP-based protocol. There are two clear benefits to using the MAPI over HTTP protocol. First, performance gains will be recognized because only TCP connections need to be reestablished after network hiccups not the full range of RPC connections. This allows Outlook clients to recover quickly and reconnect to the users mailbox when changing WLAN networks, connecting to a wireless hotspot (MiFi), or resuming a laptop from a hibernated state. Secondly, MAPI over HTTP allows Exchange to own the user session data and is not solely dependent on the current session (like RPC).


To provide backwards compatibility, Exchange 2013 SP1 servers are able to respond to AutoDiscover requests for MAPI over HTTP or RPC over HTTP requests.

The method by which MAPI over HTTP clients actually receive Exchange URL’s does not change. Outlook clients will have to inform Exchange though of the connection protocols that they can support. Configured MAPI over HTTP clients will send Exchange an AutoDiscover request using a specific x-header (x-MapiHttpCapability). An Exchange 2013 SP1 server will then validate AutoDiscover requests that include an x-MapiHttpCapability header. This is to ensure that the header value is greater than zero and that the server itself supports the mapiHttp protocol. If this works and the x-MapiHttpCapability headers are valid, the server provides the MAPI over HTTP URL’s. If this does not work then Exchange will present the RPC over HTTP URL’s. Backwards compatibility makes life easy!


As with most new software features there are significant caveats and a supported configuration that must be met in order to utilize MAPI over HTTP.

  1. First, your Client Access and Mailbox environment must be running Exchange 2013 SP1 with .NET Framework 4.5.1.
  2. Secondly, your mail clients need to be running Outlook 2013 SP1.
  3. Next, you need to ensure that the performance of your Client Access Servers is in line with the new sizing guidance from the product group. The CPU requirements for Client Access Servers configured to support MAPI over HTTP has increased by 50% over traditional RPC over HTTP sizing guidance.
  4. Lastly, MAPI over HTTP clients’ can/will have connectivity issues to public folders that reside on legacy Exchange servers (2007/2010). MAPI over HTTP configured clients’ will need to access 2013 modern public folders. If you are not using legacy public folders this does not apply to you (lucky!).

How to Configure MAPI over HTTP

 Let’s first verify what the standard Outlook 2013 SP1 connection status looks like. In the screenshot below you will see a standard RPC over HTTP connection. Notice the protocol column is showing RPC/HTTP.

Screen Shot 2014-05-07 at 9.11.29 AM

Next we need to take a look at what our InternalUrl is set to on our Client Access Servers.

Get-MapiVirtualDirectory | ft server,internalurl

Screen Shot 2014-05-07 at 10.28.54 AM

Since the InternalUrl is set to a FQDN that is not on our certificate, we need to change the InternalUrl to https://mail.contoso.local/mapi.

Set-MapiVirtualDirectory -Identity “srv3\mapi (Default Web Site)” -InternalUrl https://mail.contoso.local/mapi -IISAuthenticationMethods Negotiate

Screen Shot 2014-05-07 at 10.30.53 AM

Alternatively you can set the InternalUrl on all servers this way:

Get-MapiVirtualDirectory | Set-MapiVirtualDirectory -InternalUrl https://mail.contoso.local/mapi

Screen Shot 2014-05-07 at 10.31.13 AM

Next, we need to enable MAPI over HTTP at the organization level. First lets verify that MAPI over HTTP is not enabled.

Get-OrganizationConfig | FL *mapi*

Screen Shot 2014-05-07 at 10.34.05 AM

We see that MapiHttpEnabled is set to false within our organization.

In order to enable MAPI over HTTP we issue the following command.

Set-OrganizationConfig -MapiHttpEnabled $true

After setting this parameter we can then verify the change.

Screen Shot 2014-05-07 at 10.39.18 AM

After several minutes any user connected with Outlook 2013 SP1 will receive a prompt that Outlook will need to be restarted. A fix to suppress this client-side alert is in the mix for an upcoming CU release this summer.

Screen Shot 2014-05-07 at 11.54.20 AM

After restarting Outlook 2013 SP1 you will see a standard MAPI over HTTP connection. Notice the protocol column is showing HTTP.

Screen Shot 2014-05-07 at 12.15.12 PM

Additionally, the AutoDiscover log for this Outlook session generated by Test E-mail AutoConfiguration will display the new MAPI over HTTP Autodiscover provider listed.

Screen Shot 2014-05-07 at 12.17.47 PM

Administration and Troubleshooting

It is noteworthy that Microsoft has provided several different methods to troubleshoot MAPI over HTTP.

First, a URL has been provided that displays basic connectivity diagnostics. The page displays the Client Access and Mailbox server that we have connected to, Exchange version, and vdir path. This page can be accessed using the following URL.


Screen Shot 2014-05-07 at 10.50.35 AM

Secondly, we have three different log locations that can be reviewed. The MAPI over HTTP logs can be found here:

%ExchangeInstallPath%Logging\MAPI Address Book Service\

%ExchangeInstallPath%Logging\MAPI Client Access\


Lastly, we can use the Test-OutlookConnectivity cmdlet to verify that MAPI over HTTP is working on our server SRV3 by way of the Microsoft Exchange Health Manager service.

Test-OutlookConnectivity -RunFromServerId srv3 -ProbeIdentity OutlookMapiHttpSelfTestProbe

Screen Shot 2014-05-07 at 11.29.11 AM 


The addition of an HTTP-based protocol for the myriads of mobile Outlook users will be a welcome change! The layers between the end user and the Exchange server has been simplified, thus providing the ability for users to switch from a work WLAN to their personal hotspot (and back again!) with minimal disruption to the Outlook session. Deploying MAPI over HTTP within a large enterprise will definitely be challenging given the significant caveats and supported configurations that must be met. I’m sure over time the enterprises’ that have already invested in Exchange 2013 will address these caveats and reap the rewards of MAPI over HTTP.

Simplicity is magical when it works!

005 Geeks With A Blog Podcast – TechEd Preview with Paul Robichaux. #MSExchange #iammec #podcast #tech

Subscribe in iTunes!

Show notes:

TechEd sessions presented by Paul Robichaux – 2.10

Thoughts on premium clients released for non-Microsoft platforms – 5.50

Is Lync on-premise following in the footsteps of Exchange? – 10.00

How will Lync Online get around the lack of enterprise voice? – 14.34

Market opportunities and Regulatory concerns with Enterprise Voice – 17.18

The process and challenges of writing Exchange 2013 Inside Out: Clients, Connectivity, and UM – 19.38

Discussion of the Microsoft Exchange Preferred Architecture blog post – 30.56

Managed Availability Discussion – 43.54

What is the future of Exchange – 50.48

Paul’s upcoming sessions – 59.18

How To: Exchange 2013 SP1 and Active Directory-Detached Clusters: #MSExchange #iammec

Working in the Technology industry for 16 years has afforded me many opportunities to serve as the celebrated, distinguished, and illustrious ‘on-call’ contact. During the 10 years or so working at various levels and stages of a system administrator, there seemed to be a very consistent theme with being on-call. If I did not plan anything on the weekend – the phone did not ring. However, if I planned on a nice dinner with my wife on Friday night – the phone would ring. Most of the time the calls were not critical situations, but rather something relatively minor. About once a year though, a true critsit would come my way. Nothing was more infuriating as when these outages were a result of another engineer (or myself) shooting themselves in the foot. In my experience though – most outages were revealed to be self-inflicted during post-mortem exercises. This scenario plays out in most organizations and is something that the Microsoft support organization is well aware of. After all, they are the ones that receive the critsit calls from grumpy and embarrassed engineers. As a result, Microsoft has been preaching simplicity.

Since the release of Microsoft Exchange 2010, the Database Availability Group (DAG) has become the crowning jewel around the high availability and site resilience story, and the technology continues to evolve. This of course is my opinion after working with many third-party products that claimed to provide the same level of protection for Exchange 2003 and 2007, but seemed to cause too many sleepless nights.

The addition of a DAG into a messaging design allows a perimeter to be created for database replication, failovers and switchovers. It is important to note that a best practice DAG design also leverages the concept of incremental deployment. This means that we first create an empty Active Directory (AD) object that contains important information about our DAG. Then, we build upon the AD object by adding Mailbox servers to participate in the DAG. This step uses the Windows Failover Clustering components to create a cluster (CNO, IP Address etc.) that is unique to the DAG and manages database mount status, continuous replication and Active Manager duties. The final building block is to create and add database copies into the DAG.

The high availability story for Exchange 2013 SP1 (with Windows Server 2012 R2) has evolved into an even stronger story. Now, (using 2013 SP1 and 2012 R2) Mailbox servers configured with a DAG do not require the creation of a cluster administrative access point or IP address.

Screen Shot 2014-05-01 at 7.39.39 PM

This means that the Windows Failover Clustering Manager can no longer be used to manage the DAG (specific PowerShell cmdlets are used against each individual cluster member instead) as the IP Address and cluster Network Name resources are not present.

Screen Shot 2014-05-01 at 7.33.50 PM

With this configuration, PowerShell cmdlets are used to manage all aspects of the DAG (much like a non-Exchange Active Directory-detached cluster). It is also important to note that the CNO and cluster A record within DNS are also missing. The DAG-name is no longer required to be resolvable within your companies internal DNS. The removal of the CNO, IP Address and Network Name dependencies are a result of changes introduced with the release of Windows 2012 R2. Now, Exchange can leverage an Active Directory-detached cluster. The removal of these legacy dependences helps to simplify both deployment and administration.

Regarding deployment, we no longer require AD permissions to create objects or to pre stage cluster computer accounts. Administrators can now rest easy that an over-eager employee can no longer delete the CNO because they did not recognize the name. Microsoft’s effort for simplicity in design, implementation and administration is evident.

Let’s delve into how we leverage all these new enhancements with a step-by-step tutorial.

For the purpose of this walkthrough, we will utilize a box called SRV1 to house the FSW, SRV3 and SRV4 to run the Exchange 2013 SP1 Mailbox role.  Each of these servers have Windows 2012 R2 installed. While there will certainly be other servers/roles within the Exchange/AD architecture, these are the relevant boxes for this walkthrough.

We need to determine what server is going to host the file share witness for our two server DAG. Once the server has been determined, the Exchange Trusted Subsystem needs to be added to the local admin group on the server.

Next, we issue the PowerShell command from SRV3 to create the DAG. The server srv1.contoso.local will be used for our example. Notice in the syntax below the IP Address is set to None.

New-DatabaseAvailabilityGroup -Name DAG01 –DatabaseAvailabilityGroupIPAddresses ([System.Net.IPAddress]::None) -WitnessServer srv1.contoso.local –WitnessDirectory “c:\fsw“

If you did not add the Exchange Trusted Subsystem to the local administrators group, on the computer configured to host the file share witness, the following error will be displayed:

Screen Shot 2014-04-24 at 11.29.55 AM

Once the DAG is created successfully, the first Mailbox server can be added. Exchange will first check within AD to verify that the Mailbox server is not already part of an existing  DAG. To add the first Mailbox server to our newly created DAG (DAG01) the following PowerShell command from SRV3 is issued:

Add-DatabaseAvailabilityGroupServer -identity DAG01 –MailboxServer srv3

Screen Shot 2014-04-24 at 11.44.18 AM

Once the Mailbox server has been identified as not part of an existing DAG, the Windows Failover Clustering components are installed.

Screen Shot 2014-04-24 at 11.44.25 AM

Screen Shot 2014-04-24 at 11.49.15 AM

Once our first Mailbox server (SRV03) has been added to the DAG (DAG01) we can then add the second Mailbox server from SRV3.

Add-DatabaseAvailabilityGroupServer -identity DAG01 –MailboxServer srv4

Now that both our Mailbox servers (SRV03, SRV04) have been added to the DAG, we need to verify our work thus far. We will use PowerShell from SRV3 to show the two Mailbox servers we just added.


Screen Shot 2014-04-24 at 12.01.48 PM

In order to show how the DAG IP address is reported when no cluster administrative access point or IP address is configured, the PowerShell command below is used. We will want to take note of the DatabaseAvailabilityGroupIpv4Addresses and DatabaseAvailabilityGroupIpAddresses values.

Get-DatabaseAvailabilityGroup | fl

Screen Shot 2014-04-24 at 12.03.39 PM

When we created the DAG and specified the FSW (server) location, you may of noticed that this folder was not immediately created. The FSW folder is actually not created until the second Mailbox server is added to our DAG. Once the second Mailbox server is added into the DAG, thus requiring quorum,  the FSW folder is created on SRV1 as you see below.

Screen Shot 2014-04-24 at 12.01.16 PM

At this point, we are ready to create a new DAG-protected  database on SRV3. For our example we are going to add the database called mbx01 to SRV3.

The following PowerShell command from SRV3 is used to add a DAG protected database:

New-Mailboxdatabase -server srv3 -name mbx01 -Edbfilepath “C:\Program Files\Microsoft\Exchange Server\V15\Mailbox\mbx01.edb” –logFolderPath “C:\Program Files\Microsoft\Exchange Server\V15\Mailbox”

Screen Shot 2014-04-24 at 12.07.57 PM

After the new database has been added, a warning to restart the Information Store service on SRV03 is provided. The following command from SRV3 will be used restart the service:

Restart-Service MSExchangeIS

Screen Shot 2014-04-24 at 12.09.47 PM

In order to verify that mbx01 is mounted we need to run the PowerShell command from SRV3 below:

Get-MailboxDatabaseCopyStatus -Identity mbx01\srv3 | ft name,Status,ContentIndexState,ReplayQueueLength,CopyQueueLength

Screen Shot 2014-04-24 at 12.17.41 PM

At this point we have SRV3 and SRV4 participating as members in our DAG. However, only SRV3 has a copy of the database (mbx01) that we want to make highly available. On our second server Mailbox server (SRV4) we want to add a copy of the mbx01 database. To accomplish this, we will need to issue the following PowerShell command from SRV4:

Add-MailboxDatabaseCopy mbx01 -MailboxServer srv4

Screen Shot 2014-04-24 at 12.22.08 PM

After adding a copy of mbx01 to SRV4, a warning that the Information Store needs to be restarted is presented. From an Exchange PowerShell window on SRV4 we will need to restart this service.

Restart-Service MSExchangeIS

Now that we have created a highly available cluster of Mailbox Servers, and added a second copy of the mbx01 database on both servers, we need to verify database health. In the example below, we can see that MBX01\SRV3 is showing as mounted. Also, MBX01\SRV4 is showing healthy as the status. The CopyQueueLength and ReplayQueueLength are both set at zero and the ContentIndexState is healthy. From either Mailbox server we can issue the following command

(Get-DatabaseAvailabilityGroup) | ForEach {$_.Servers | ForEach {Get-MailboxDatabaseCopyStatus -Server $_}}

Screen Shot 2014-04-24 at 12.32.00 PM

As you can see from our example of setting up a new DAG with a highly available mailbox database, Microsoft has both simplified and streamlined the process. The overarching theme when combining Windows Server 2012 R2 with Exchange 2013 SP1 is ‘Simplicity.’

Personally, I look forward to not receiving a call during the middle of the night that “the Exchange mailbox databases on the cluster wont mount and Systems Center is complaining about missing a CNO or something like that.” While we may not be able to get out of on call duty, we may be able to make our systems a bit more resilient thanks to Microsoft’s latest chapter in the Exchange high availability story.


004 Geeks With A Blog Podcast – My Preferred Architecture. #MSExchange #iammec #podcast #tech

Subscribe in iTunes!

Show notes:

Azure AD Sync Preview – 2.52

Exchange 2013 SP1 Arch Poster Download – 7:10

Windows 8.1 Million downloads in a week – 10:10

Nike kills sports band and focuses on software17:06–wearables–revolution-dies-before-it-begins-145640361.html

Cortana Animations – 24:22

Xbox Operations Center – 27:38

Surface 64 GB 28% off  – 30:06

The Surface 64 GB went from $499 to $329 with touch cover

As the world of Exchange turns – Exchange News

Microsoft Exchange Preferred Architecture – 36:28

Did You Know: MAPI over HTTP and .NET: #MSExchange #iammec

Do all the great additions of Exchange 2013 SP1 have you thinking about turning on MAPI over HTTP? If so, are you running .NET Framework 4.5.1? The release notes for this framework mention that performance and reliability improvements are provided. New performance features such as ASP.NET app suspension and multi-core JIT improvements are now available; for instance, ASP.NET app suspension allows IIS 8.5 and Windows 2012 R2 to suspend sites based on request timeout values, thus freeing up CPU and memory on the server. When a suspended site is requested, the site is then loaded up into memory allowing for accelerated performance.

The Exchange Team echoes the performance improvements of .NET Framework 4.5.1 for 2013 SP1 customers in their latest blog post. Specifically, if MAPI over HTTP is going to be used within your messaging environment, then it is “critical” to install .NET Framework 4.5.1. The reason stated in this blog post is that the framework contains “important fixes that impact both performance and scalability of MAPI over HTTP at the CAS layer.”


Remember the Migration!

Now that Exchange 2013 SP1 (15.00.0847.032) has been released, those that work as consultants will start to see a spike in billable hours. The reason being is that our enterprise customers will now seek to begin migration projects. While the validity of that best practice has fallen by the wayside many years ago, I still experience many customers standing their ground about not executing a large-scale migration project until SP1 of the product has been released. Certain habits are difficult to break no matter how hard we challenge that line of reasoning during the pre sales process. Just to highlight the diligence around patching a messaging infrastructure, I’m sure all those that have installed 2013 SP1 have also installed the required post SP1 fixes.

Humor aside, this is a good time to review several salient reminders that were pointed out during the Microsoft Exchange Conference concerning mailbox migrations to 2013.

  • Exchange 2013 has changed the methodology in which a user’s actual mailbox size is reported. Now, a more precise calculation is used which reports back all properties of a user’s mailbox and not a partial set of properties like in the legacy versions. According to Microsoft, the net effect of this change is that legacy Exchange users that are migrated into 2013 will see the “reported” size of their mailbox increase around 30%. It is important to note that the physical size on disk has not increased; rather the logical reporting size of the mailbox has increased. This means that legacy users close to their quota (~75%) will require additional attention prior to migration. Users that are close to their quota within the legacy environment and then are moved to 2013 most likely will exceed their enforced quota. An unanticipated effect may be that the user cannot send or receive new mail after migration. This is of course dependent on what the configured quota restrictions in place are. A simple fix is to increase the quotas by 30% at the database level (or mailbox) on the legacy Exchange system prior to migration. Remember to check the following limits on your legacy Exchange databases: Issue warning at (GB), Prohibit send at (GB), and Prohibit send and receive at (GB). You can verify your configured database limits prior to migration by using the following PowerShell command: Get-MailboxDatabase <database name> | fl *quota*.
  • During migration projects for larger enterprise customers, any production impacting changes will need to be coordinated through a change review board. These changes are then approved through a committee vote and scheduled for a precise start and end time. During an approved change, a conference bridge is setup (with a cast of thousands) where you will need to announce when you are making a change, when the change is completed, and when the change has been tested. Don’t be the consultant that requests the DNS team to make a change to an A record for a namespace cutover only to realize the TTL is set to 86400 seconds (24 hours) while on the bridge. I guarantee that you will never forget that mistake. As part of your steps during a namespace cutover, make sure to verify and document the TTL of all relevant DNS records. If the TTL is set to a longer than desired time, then change the TTL of these DNS records 24 hours prior to the actual scheduled namespace cutover.
  • It is important to review how the Offline Address Book (OAB) within your legacy Exchange environment is configured. Many mailbox databases have a setting of $null for their default OAB. This configuration simply means that the default OAB is used. However, when the first Exchange 2013 Mailbox server is introduced into the environment a new ‘default’ OAB is created. This means the Exchange 2013 will now be responsible for generating and distributing the OAB. This becomes problematic if your environment has a large OAB (some are 100 MB+) with thousands of Outlook clients distributed over many types of networks with varying degrees of available bandwidth. Yes – think about how popular you will be with the network team on Monday morning when 10,000 users open up Outlook and initiate a full OAB download at the same time. Brutal. The easy work around is to configure all legacy Exchange databases with the legacy OAB prior to install Exchange 2013. The following PowerShell command can help: Set-MailboxDatabase –Identity <database name> -OfflineAddressBook “<default OAB Name>.” For a more detailed explanation of this situation read the article written by fellow Microsoft Certified Master (and MVP) Andrew Higginbotham.
  • The timing of when to swing the SMTP endpoint from the legacy Exchange infrastructure to 2013 is often discussed. The best practice for larger migrations is to make this change once 50% of users have been move to 2013.
  • Some scenarios can benefit from installing newly built Exchange 2013 servers into an empty Active Directory Site. This will allow you to configure the 2013 environment fully, while providing a logical separation from internal domain joined clients AutoDiscover SCP requests. The 2013 servers can be moved to the production Active Directory site once you have completed all necessary configuration steps.
  • Don’t forget all the great tools that Microsoft provides us with to help with migrations! We have the:

Hopefully, some of these reminders can help you to avoid being the consultant that has to request an emergency extension to a change control window because you forgot something!

Now where is my Exchange 2013 post SP1 project plan…


Did You Know: Managed Store Performance and .NET: #MSExchange

During last week’s Microsoft Exchange Conference, Jeff Mealiffe recommended that the fixes found in KB2803754 or KB2803755 should be applied when installing Exchange 2013. Specifically, KB2803755 will ensure that the .NET Framework 4.5 becomes properly tuned for the Exchange Information Store within Windows 2012. The same fix for Windows 2008 R2 is contained in KB2803754.

According to the KB article, a registry entry must be configured in order to activate this hotfix. The KB instructs the user to create the following registry key:

Create a DWORD value at [HKLM\Software\Microsoft\.NETFramework\DisableRetStructPinning] registry subkey, and set the DWORD value to 1.

After the registry key is added the server must be rebooted for all changes to be fully realized.

Now the question may be raised as to how a .NET fix can enhance the performance of an Exchange 2013 database? During the development of Exchange 2013 the store.exe process was redesigned and coded as a managed store. The managed store within Exchange 2013 now has fault isolation properties. In order to achieve this isolation, a Store.Service.exe is utilized to manage worker processes. A separate worker process (Store.Worker.exe) runs for each mounted database on a Mailbox server.

To illustrate this point, using the screenshot in the example below, there are two mounted databases (eu-01 & db01) running on a test Exchange 2013 Mailbox server.

Screen Shot 2014-04-11 at 12.30.45 PM

Now if we take a look at the task manager for this server, there is the overarching Store.Service.exe running that manages Store.Worker.exe processes. There is a Store.Worker.exe process for each active database that is running.

Screen Shot 2014-04-11 at 12.26.00 PM

The managed store relies heavily on the .NET Framework so we need to be especially aware of any .NET patches released.

This patch will help reduce the amount of memory that the Store.Worker.exe processes consume on each Mailbox or Multi-role server within your environment.