New Exchange patches

UPDATE:
the Exchange 2010 Rollup8 has a bug in it so Microsoft removed the download link and will replace this rollup. If you happen to be fast and already installed KB2986475, Microsoft recomend to uninstall it and wait for the updatged rollup.Exchange Server 2013 Cumulative Update 7 (CU7) is released.
A version 2 of Exchange 2010 SP3 UR8 is now released, download here.
 
Exchange 2013 Cumulative Update 7.
Download link and KB2986485
Exchange Server 2010 Service Pack 3, Update Rollup 8.
Download link and KB2986475
Exchange Server 2007 Service Pack 3, Update Rollup 15.
Download link and KB2996150
Notice that there is Active directory schema updates that must be applied before installing Exchange 2013 CU7.

Exchange cmdlet Extension Agents

Cmdlet extension agents are components within Exchange 2013 that are invoked when Exchange cmdlet’s run. Agens can do additional action when Exchange cmdlet are run such as modify,add functionality or validate input parameters.

Several agents exists out of the box when installing Exchange 2013. Run Get-CmdletExtensionAgent to see. note that they can be disabled/enabled and have a priority.

The one agent we can manipulate with ease is the “Scripting Agent”. It runs Exchange cmdlets located in an XML file, $exbin\CmdletExtensionAgents\ScriptingAgentConfig.xml. This file does not exists by default but there is a sample file in the same directory which contains examples.

The most common scenario I would think of is to run some cmdlet after a cmdlet is run. for example. when you create a mailbox you can also run some cmdlet to set some additional parameters on the mailbox. My example here is to enable SingleItemRecovery and also change de default permission on calendar to LimitedDetails for everyone to see the subject of calendar objects.

   1: <?xml version="1.0" encoding="utf-8" ?>

   2: <Configuration version="1.0">

   3:     <Feature Name="MailboxProvisioning" Cmdlets="Enable-Mailbox">

   4:         <ApiCall Name="OnComplete">

   5:             if($succeeded) {

   6:                 $ErrorActionPreference = "SilentlyContinue"

   7:                 $MaxTime = 60

   8:                  for ($LoopVar = 0;$LoopVar -lt $MaxTime;$LoopVar++) {

   9:                     if($provisioningHandler.UserSpecifiedParameters["Identity"] -ne $null) {

  10:                     $user = Get-user $provisioningHandler.UserSpecifiedParameters["Identity"] 

  11:                     $mbx = Get-Mailbox $user.DistinguishedName

  12:                     If (-not($mbx)) {

  13:                         Start-Sleep 1

  14:                         continue # with the for loop

  15:                     } 

  16:                     else

  17:                     {

  18:                         # Enable SingleItemRecovery

  19:                         Set-Mailbox $mbx -SingleItemRecoveryEnabled $true

  20:                         WriteToLog (' enabled singleitemrecovery on ' + [string]$mbx.alias)

  21:                         # set sharing permissoin on calendar folder

  22:                         $CalendarName = (Get-MailboxFolderStatistics -Identity $mbx.alias -FolderScope Calendar | Select-Object -First 1).Name

  23:                         $folderID = $MBX.alias + ':\' + $CalendarName

  24:                         Set-MailboxFolderPermission -Identity $folderID -User 'Default' -AccessRights 'LimitedDetails'

  25:                         WriteToLog (' set sharing permission on calenderfolder on ' + [string]$mbx.alias)

  26:                         break # out of for loop

  27:                     }

  28:                     }

  29:                 }

  30:                 $ErrorActionPreference = "Continue"

  31:             }

  32:         </ApiCall>

  33:     </Feature>

  34:     <Feature Name="MailboxProvisioning" Cmdlets="New-Mailbox">

  35:         <ApiCall Name="OnComplete">

  36:             if($succeeded) {

  37:                 $ErrorActionPreference = "SilentlyContinue"

  38:                 $MaxTime = 60

  39:                  for ($LoopVar = 0;$LoopVar -lt $MaxTime;$LoopVar++) {

  40:                     if($provisioningHandler.UserSpecifiedParameters["Name"] -ne $null) {

  41:                     $user = Get-user $provisioningHandler.UserSpecifiedParameters["Name"] 

  42:                     $mbx = Get-Mailbox $user.DistinguishedName

  43:                     If (-not($mbx)) {

  44:                         Start-Sleep 1

  45:                         continue # with the for loop

  46:                     } 

  47:                     else

  48:                     {

  49:                         # Enable SingleItemRecovery

  50:                         Set-Mailbox $mbx -SingleItemRecoveryEnabled $true

  51:                         WriteToLog (' enabled singleitemrecovery on ' + [string]$mbx.alias)

  52:                         # set sharing permissoin on calendar folder

  53:                         $CalendarName = (Get-MailboxFolderStatistics -Identity $mbx.alias -FolderScope Calendar | Select-Object -First 1).Name

  54:                         $folderID = $MBX.alias + ':\' + $CalendarName

  55:                         Set-MailboxFolderPermission -Identity $folderID -User 'Default' -AccessRights 'LimitedDetails'

  56:                         WriteToLog (' set sharing permission on calenderfolder on ' + [string]$mbx.alias)

  57:                         break # out of for loop

  58:                     }

  59:                     }

  60:                 }

  61:                 $ErrorActionPreference = "Continue"

  62:             }

  63:         </ApiCall>

  64:     </Feature>

  65:  

  66:     <Common>

  67:         <!-- common functions -->

  68:  

  69:         function WriteToLog {param ([string]$text)

  70:             $t = Get-Date -Format yyyyMM

  71:             $LogFile = 'C:\temp\scriptingAgent_' + $t + '.log'

  72:  

  73:             # $text = text to be written to logfile

  74:             $t = Get-Date -Format yyyyMMdd:HHmmss

  75:             $text = '[' + $t + '] ' + $text

  76:             $text >> $LogFile

  77:         } #end function LogToFile

  78:     </Common>

  79:  

  80: </Configuration>

the XML elements to notice here is Feature, ApiCall and Common. Feature hold the Cmdlet attribute , here you put in the Exchange cmdlet you want to do something with. ApiCall you enter what you want to do, I use OnComplete which will trigger after the cmdlet in feature element.

Both Feature and ApiCall can be in the XML file multiple times.


You can see in my example here (line 3 and 4) that the *Scripting Agent” will run a script block after Enable-mailbox is completed. I start by doing a trick to allow the Active Directory replication have a chance to finish before we actually do something. line 19 to 25 is where the stuff I actually want to happen after Enable-Mailbox.


Line 34,35 is when you run New-Mailbox. I could have have the New-Mailbox and Enable-Mailbox together but separated them because in they use different anchor to the mailbox (line 10 and 41).  
The common section in the XML file contains a small powershell function to write some information to a text file.

Other things I hear customer do is to apply some policies to mailboxes and disable things such as pop/imap.

So now that you have a XML file to work with you can simply add your own logic when some Exchange cmdlet is run and not only to when provisioning mailboxes, it could be for DL’s or whatever your imagination can come up with.

Of course you must enable “Scripting Agent” with

Enable-CmdletExtensionAgent “Scripting Agent” and also copy your XML file to every Exchange server in your environment.

Exchange Health Manager bug

You hopefully know that Exchange Health Manager monitor the Exchange server by sending Probes. The result is picked up by Monitors which decide if a Responder needs to do something about the problem.

The other day I found that a HealthSet on the server was UnHealthy. This was found by running this commands.

Get-HealthReport -Server ex1 | where {$_.AlertValue -eq 'UnHealthy'} | ft –AutoSize

Result showed that “OutlookMapiHttp” HealthSet was to blame.
You can trigger a probe to execute at any time, first we need to know what the probe name is.

Get-MonitoringItemIdentity -Server ex1 -Identity OutlookMapiHttp | ft Identity, ItemType, Name

Result show the probe name for the OutlookMapiHttp HealthSet, “OutlookMapiHttpCtpProbe”.

Since we are dealing with outlook connectivity problem here we should use the Test-OutlookConnectivity cmdlet to trigger the probe to run.

Test-OutlookConnectivity -RunFromServerId ex1 -ProbeIdentity OutlookMapiHttpCtpProbe

Another way of trigger the probe would be
Invoke-MonitoringProbe -Server ex1 -Identity OutlookMapiHttp\OutlookMapiHttpCtpProbe

Both cmdlets took a about 90 seconds before they come back with a result saying “Failed to find proberesult”
Could this be a performance issue? This server showed no peformance related problem, it is actually a oversized box.
I fired up event viewer and looked in different eventlogs under Microsoft\Exchange\ManagedAvailability and Microsoft\Exchange\ActiveMonitoring. Events here show probe definitions and firing, monitors reading probe results and what responders do and the result of responders as well. The best way of reading this info is to switch from General to Details and filter on Errors.

I could find snippet of text “The remote server returned an error (404). Not Found and a reference to a Health Mailbox.
This was strange. monitoring mailboxes is created on demand when the Health Manager service do its thing, so I trigger a restart of it but no difference. waited several hours and did a reboot but no difference even when waiting until the next day.
Discussed this with en engineer at Microsoft and he eventually suggested to change the time zone on the server from the current GMT+1 to a time zone used in America. Did that and nothing happened. In desperation I rebooted the server again and bang, now the “OutlookMapiHttp” healthset showed Healthy.
I played around with time zone and restart of Exchange Health Management service and could make the problem come and go as I changed time zone.

I haven’t tried all time zones but it looks like if you’re using GMT+something this bug will surface.
f you don’t want to change time zone on server you can create on monitoring overide.

Add-ServerMonitoringOverride -Identity OutlookMapiHttp\OutlookMapiHttpCtpMonitor -ItemType monitor -PropertyName Enabled -PropertyValue 0 -Server ex1 -ApplyVersion 15.0.913.22

In a few minutes you would see your healthset go healthy. together with the OutlookMapiHttp healthset there is also another healthset that also shows unhealthy “OutlookMapiHttp.Proxy” and is subjct to same bug with time zone. to make an override for it use.

Add-ServerMonitoringOverride -Identity OutlookMapiHttp.Proxy\OutlookMapiHttpProxyTestMonitor\MSExchangeMapiFrontEndAppPool -ItemType monitor -PropertyName Enabled -PropertyValue 0 -Server ex1 -ApplyVersion 15.0.913.22

We can only hope that this is fixed in the next CU of Exchange 2013.

Outlook update

Microsoft published an update for outlook 2013 on August 12. It was suppose to fix several things.
Sadly it also introduced a bug where you could not get access to Exchange archive in some circumstances.
Well so it happens that Microsoft has now reacted and pulled the update for further investigation. If you have already installed this patch and encounter problem you could easily uninstall it.

Read KB2881011 for more info.

So another update that introduces problem. It feels like Microsoft don’t test updates that much anymore My guess is that the “Cloud/Mobile first” mantra Microsoft advertise makes the internal processes at Microsoft spin a little to fast and then quality is sacrificed. This is something we have seen the last year and I can only hope it gets better.

Using Windows 8.1 mail app without a Microsoft account

Running Windows 8.1 you have a choice of either using Microsoft account/local account or an Active Directory account if the computer is joined to an Active Directory domain.
Having the computer joined to an AD domain is the common scenario in the corporate world and you then most of the time use the Active Directory account to logon to the computer. To do email and calendaring there is big chance you’re using Outlook but what if you want to run the built in mail app in windows 8?  When starting mail app you’re then prompted to change the computer settings to logon/sign-in with a Microsoft account.

This will of course not go very well when computer is joined to an AD domain so what to do?
When using a domain joined account you might see this wizard instead if the Switch to a Microsoft account.

Happy you enter your corporate email account and password but the wizard comes back with bad password and prompt you to enter the information correctly. It seems that it only works for hotmail/LiveID/Microsoft accounts and not for a regular Exchange account. So what to do?

I found a group policy setting “Administrative Templates\Windows Components\App Runtime\Allow Microsoft account to be optional”.
If you enable this policy , mail app won’t prompt you to change computer settings to use Microsoft account but instead simply prompt for corporate account and password for the email account you want to use. This policy can be set either on user or computer and as a local policy. Description for the policy implies that other windows store app might behave similar as mail app do and allow user to enter the corporate creds instead of the Microsoft account.
Mail app uses the computer policy to configure this setting.

Time to edit a group policy perhaps ?

Who and what is using the Exchange Web Service

Exchange Web Service (EWS) has been around since Exchange 2007. You  should know that outlook uses EWS for several functions and primary for calendar stuff such as Free/Busy queries. There is also several flavor of Mac that uses EWS as its only API for communicating with Exchange.
Toss in Lync client in the mix and you will also see it communicating with EWS.
To get a complete list of what us using your Exchange servers EWS you have to look in the IIS-logs. Your buddy here is the good old logpaser which can be found here LogParser 2.2 download.
Copy the IIS logfiles you want to analyze into a folder of your choice. Start a command prompt and run:
"C:\Program Files (x86)\Log Parser 2.2\LogParser.exe" "SELECT cs(User-Agent) as UserAgent, count(*) as hits FROM "path to iis logfiles" WHERE cs-uri-stem LIKE '/EWS/Exchange.asmx' AND cs-username GROUP BY UserAgent" –I:IISW3C
Output will show the UserAgent and number of corresponding hits.
You can add “-O:tsv > outputfilename.txt” at the end of the logparser query to save the output in a tab separated text file for easier reading.
You can also run the logparser query in LogParserStudio. You see here that there is a number of different clients using EWs and they also have different patch levels. UserAgent OC/15 is Lync 2013 client and OC/4 is Lync 2010 client.
ExchangeServicesClient is an appl. made by EWS managed API.

You might also find other UserAgents in there such as “Sipe/1.18.2” or “Evolution/3.10.2”.
You might want to stop them from accessing EWS, how is this done?
If you have configured your LoadBalancer to do Layer 7 inspection you probably could stop these UserAgents but a much easier way is to do this.
Configure some properties on the Organization object.
First have a look of current and default configuration. We see here that by default everyone is allowed to communicate with EWS
Get-OrganizationConfig | fl EWS*
EwsAllowEntourage          :
EwsAllowList               :
EwsAllowMacOutlook         :
EwsAllowOutlook            :
EwsApplicationAccessPolicy :
EwsBlockList               :
EwsEnabled                 :
How do you stop certain clients or only allow some?
Set the EwsApplicationAccessPolicy parameter to either EnforceAllowList or EnforceBlockList and then us the EwsBlockList or EwsAllowList which is an array of UserAgent (case sensitive) of the applications. You must also set the Enable EwsEnabled parameter to true to get this to work.
So there is actually a way to allow only certain applications to communicate with EWS. have a look at the Set-OrganizationConfig cmdlet http://technet.microsoft.com/en-us/library/aa997443(v=exchg.150).aspx

Why is my Exchange server unhealthy

Your Exchange 2013 server was just installed and you thought everything should look nice and shiny. But after you install SCOM management pack and start to collect information from Exchange servers you notice that many things is flagged as unhealthy.

You try the Exchange management cmdlet “Get-HealthReport <servername> and see some components show up as unhealthy. Not surprisingly it is the same things SCOM flags as unhealthy. SCOM management pack is totally different for Exchange 2013 than previous versions of Exchange. Previous version SCOM did a lot of testing to verify that Exchange was healthy. Now Exchange do this natively with Manages Exchange server health service, a.k.a. Managed Availability and SCOM is just reading the eventlog. Well it does more than just reading the eventlog but that’s not the scope for this article neither is the Managed Availability stuff except that it has Probes, Monitors and Responders.

Common things to show unhealthy are:
FEP: Forefront Endpoint Protection. Reason for this is that FEP is not installed on your server. You can of course install FEP on the server. if you do, carefully exclude processes/folders otherwise FEP will interfere with Exchange and possibly destroy functionality. Anti-Virus Software in the Operating System on Exchange Servers.
If you don’t want to install FEP you can make the unhealthy status go away in two ways. Edit the FEPActiveMonitoringContext.xml file and set the Enabled parameter to False. File is located in Exchange installation directory\bin\monitoring\config. You can also configure a MonitoringOverride with Add-ServerMonitoringOverride cmdlet. You can either create an override that’s last for up to 60 days or by version. Here is the command for creating an override by version.
Add-GlobalMonitoringOverride -Item Monitor -Identity "FEP\MaintenanceFailureMonitor.FEP" –PropertyName Enabled -PropertyValue 0 –ApplyVersion 15.0.847.32

Version can be found by running
Get-ExchangeServer e15-ex3 | fl AdminDisplayVersion
Versoin 15.0.847.32 happens to be Exchange 2013 SP1.

Identity is found with
Get-MonitoringItemIdentity -Identity FEP –Server <servername> | ft Identity,ItemType,TargetResource
it will produce a list of stuff related to FEP and it’s the monitor you would like to an override on, hence the Identity “FEP\MaintenanceFailureMonitor.FEP” in the overridemonitoring command.

When you have created the override monitor for FEP you should see the unhealthy status go away after a few minutes.

CASProxy’s
One of the most common reason for CASproxies to show up as unhealthy is that you’re using Basic auth only on the virtual directories. Reason for this is often that you’re using a reverseproxy that do authentication and authenticate to Exchange with basic auth.
configure your virtual directories to allow windows integrated or FBA. Seems like the probe only cannot use Basic authentication. Note.  This seems to be fixed in the just released CU5 for Exchange 2013.
You could also create a GlobalMonitoringOverride as you did for FEP.

There is of course several other things that could end up being flagged as unhealthy but use the Eventlog and look into the crimson channel logs and Get-MonitoringItemIdentity  to get more information whats wrong. Perhaps there is a real problem or just something that you need to do correct with an override

I recommend doing override with the version parameter because you don’t know what happens in the next Cumulative Update for Exchange. In the case with CASproxy’s it seems that Microsoft has correct the probe to also use Basic Authentication.
Remember though that when applying upcomgin CU you probably need to create new monitoringoverrides that match the new version.

Protect your SMTP domain with SPF records

If you  haven’t created a SPF record to protect your SMPT domain on Internet this is for you.

SPF is not a single thing , it is two things. One thing is to verify incoming mail to your servers that they originate from a list of trusted servers. an example would be when your serves receive a mail that claims to be from domain.com , your server will do a lookup in DNS for information (the SPF record). This info will (if existing) have list of servers that are authorized to send mail with sender with SMTP address in domain.com domain. next step is for the receiving server to verify this SPF info together with header info in mail message and IP address of the sending server, if everything is OK it server will simply accept the email but if there is mismatch you have to decide and configure your server what to do, perhaps let email through anyway or mark it as spam.

The other thing is to create your own SPF record for others to verify mail claiming to come from your SMTP address space.

Easiest way to create your SPF record is to use one of the multiple wizards on Internet. Microsoft also has one https://www.microsoft.com/mscorp/safety/content/technologies/senderid/wizard/ which is quite good. Remember that no wizard will never provide you with good results unless you enter good information into it so next step is to find all servers that send SMTP mail with senders from the SMTP domain you want to edit the SPF record for, this is key for a proper working SPF deployment.
SPF record itself is a plain TXT record in the zone authoritative for the SMTP domain and you can enter information in a variety of ways, IP addresses, server name, MX or a combination of them.

some examples of SPF records in domain.com zone.
v=spf1 ip4:10.10.10.10 ~all
This means that only a server with IP 10.10.10.10 is allowed to send mail with senders addresses in domain.com zone.

v=spf1 mx ~all
only servers listed in the MX record are allowed

v=spf1 a mx ip4:10.10.10.10 ~all
Only servers with A records or MX records or IP equal to 10.10.10.10 is allowed

The all parameter:
all parameter in SPF is prefixed with different chars such as – ~ ? +
- means that the information must match, it is otherwise illegal.
~ means that it should match but could also mismatch.
+ means that it is absolutely fine for other servers than listed to send email for domain.com
? means either way, it may or may not originate from the servers specified.

Outsourced domain
Sometimes you need to let someone else deliver mail for your domain such as news mail sent from a provider or perhaps you have configured your Exchange in a hybrid setup with some users on on premise and some in Office 365. you can of course simply add the providers IP addresses to your SPF record but this impractical because could change without you knowing and they could also be multiple causing the SPF syntax to be invalid.

Why would SPF be invalid when you have a lot of information in it?
the RFC states that the receiving server must be able to figure out each SPF record with 10 or less NS queries.
solution for outsourced email or many NS queries is to use the include parameter.

v=spf1 mx include:provider.net ~all
this means either mail are authorized to come from servers listed as MX or whatever the spf record says in the provider.net zone. With this technique you can manage your servers and the provider can manage their environment independent and also making the verifying server only do 2 NS queries. first for your MX records and the other one for the SPF record in provider.net zone, now there is a new spf record giving us 10 additional queries to use.

Good practice in my opinion.
Collect information about all system that could send mail for domain.com.
Start with ?all parameter and try to log what’s happening. by logging I mean log what NS queries is done against the domain.com zone. this is a lot easier if you run and manage the NS hosting the domain.com zone than if it outsourced to a provider which might not be that helpful with statistics.
Don’t change to –all unless you are very sure that the spf record is correct.
Don’t use your production domain for bulk marketing mail, create a separate domain for this because if something goes wrong, only the marketing stuff will fail.
Verify your SPF syntax, here is on tool that can be used http://www.kitterman.com/spf/validate.html
If you have a lot of info in your SPF, use the include parameter.
Verify incoming email to your environment

make Exchange verify incoming email.
Install the ant spam agents which is already deployed if you’re using Edge. configure the SenderID transport agent.
Configure it with appropriate action.
Set-SenderIdConfig -SpoofedDomainAction StampStatus

spoofedDomainAction could be Delete, Reject of StampStatus. StampStatus is interesting since it will allow mail to be received but Exchange will stamp it and later in the transport pipeline the content filtering agent will consider this stamping and most likely classify the email as more likely to be spam.

Last, enable the SenderID agent with Set-SenderIdConfig -Enabled $true

The senderID agent has some other good to know configuration parameters. BypassedRecipients and BypassedSenderDomains which is self explainatory, there is also TempErrorAction which also has the Delete,Reject, StampStatus values.
TempErrorAction happens when the  verifying server encountered a transient error while checking the SPF, perhaps the spf syntax is incorrect, perhaps NS query timed out or something else that wasn’t considered to be normal.

Be safe and publish spf info in your DNS about your smtp domains and enable checking of the spf for incoming mail to your servers.

Have plenty of Public Folders and thinking Exchange 2013?

Think harder…
Microsoft some time ago published some information about modern public folder limitations in this TechNet article describing for example that you are only supported if you have less than 100 public folder mailboxes or no more than 10.000 folders.

Question is what you do when you have more than the limits mentioned? delete some, move some stuff to other solutions, don’t migrate to Exchange 2013 or at least do not migrate your public folders to 2013. None of the above don’t sound that appealing if you have decided to go for 2013. Easiest would be to leave public folders on your older Exchange but that has drawbacks as well such as not being able to enable Kerberos authentication or mapi/http. Exchange also behave a little strange sometimes when you’re using both Exchange 2013 and earlier version together.

Exchange Update Rollups and Service Pack released today

Exchange 2007 Service Pack 3 Update rollup 13 is now available for download from here. Read the corresponding KB2917522 for bugfixes which is almost zero.

Also Exchange 2010 SP3 UR5 was released and can be downloaded from here. The corresponding KB2917508 contains some interesting bugfixes and new functionality.

 

Exchange 2013 Service Pack 1 which is essentially CU4 but is named SP1 instead. it contains some new functionality such more DLP functionality and the big one, support for Windows Server 2012 R2 Domain Controllers, raising both Domain Function and Forest Functional Level to 2012R2, and installing Exchange 2013 SP1 on Windows 2012 R2.

Other new stuff is that Edge server is back. A new protocol used for client/server communication is introduced called MAPI/HTTP which is very similar to MAPI over RPC which is then tunneled over HTTP so in short, communication don’t rely on RPC layer which gives some advantages when it comes to authentication and reconnection of clients. It is disabled by default and you also need Outlook 2013 SP1 for leverage MAPI/HTTP.
If you use TMG or any other reverseproxy that filter on URL’s you need to add ‘/mapi/*’ as an allowed URL.

As usual there is the regular schema and AD prep stuff to do before you install the first SP1 server.

Release notes and What's new
Download link and KB2926248 link

ECP do not show all Organization Units in Active Directory

You may have seen this when you use Exchange 2013 ECP to create a mailbox and want to select a specific OU. Then for what it looks the OU picker don’t show all OUs, only some of them are shown.
Reason is that the ECP webapplication has a limit of not showing more than 500 OUs, rest of them wont simply be shown.
Don’t cry, there is a solution if you have some CPU cycles to spare. Edit the “web.config” in the ECP directory. Default path is “C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\ecp\”.
In the appsettings section, add the XML element
<add key="GetListDefaultResultSize" value="5000" /> where the 5000 is number of OUs you want to be shown.
When done recycle the MSExchangeECPAppPool to make ecp webapplication read the configuration and have it live and kicking.

The famous 9646 error on Exchange servers

Most Exchange administrators have at least one time seen an error with Event ID 9646 and some seen this many times.

An example might look like this.
Mapi session /o=Exchange_orgname/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=user with client type MOMT exceeded the maximum of 500 objects of type Folder.

another example might end with this:
.. exceeded the maximum of 250 object of type Folder View.

Why does this happen?
Exchange has some built-in thresholds for various things that try to stop bad user behavior or a client behaving badly to not use all resources on the server to make other users suffer.
You can try to change client configuration for users experiencing this problems by changing cached mode on/off and also for extra mailboxes opened, outlook add-ons might also cause this. upgrading clients to newer version might also help, but sometime you cant change what users do and you must change limits instead.

How to change limits
You change limits by registry values and Microsoft has a TechNet article that describe these values Exchange Store Limits. The key here is to read the error text and find what threshold exceeded its limit, then read the TechNet article and implement a new threshold by editing registry values.
One problem here is to decide what limits you should set, unfortunately you have to set a value and then see if its working or not.
To have it all working you must restart Exchange services so don’t count on this working until a restart is done.

Article don’t cover Exchange server 2013 but the same limits apply and also the same solution to add/edit registry values on your mailbox servers.