Daniel Seveso

Why does mailbox size increase by 30-40% when moved to Exchange 2013/2016?

dseveso — Fri, 02 Sep 2016 20:26:40 GMT

We get this question very often and its answer is right on the Exchange's release notes "Mailbox size increase when migrating from previous Exchange versions". However, I wanted to provide a little more detail along with good resources already on the web. In Exchange 2013/2016 the mailbox size calculation, includes space that was not accounted for before, but effectively was part of messaging data that ultimately belong to users activity. In Exchange 2007, mailboxes, folders and item's parts, shared common tables in the database. In this scenario, supporting database structures (let's call them overhead) were not “charged” to any particular mailbox when computing the mailbox size. In fact, it was a common topic of customer's concern, when the sum of mailboxes space was always less than the total database size on previous versions of Exchange. In Exchange 2013 the design of the database schema changed, every mailbox is stored in its own table. As a consequence, is now straightforward (and fair) to assign the space of these supporting structures to the quota of the owning mailbox. While the increase in computed size typically goes about 30-40%, it could actually be a wider range, theoretically from 1% to 200% in rare scenarios. The reason for this inconsistency is due to mailbox composition. For instance, Number of folders, number of items per folder, attachment content and more importantly, Item composition of folders. E.g. a folder with 10,000 1KB items might appear to be larger (than before) when compared to a folder with 100 100KB items. Since no two inboxes are the same, hence the variance. I have computed this table in a clean environments to illustrate the actual incidence of the mailbox shapes. I just created brand new mailboxes and new IPM.Note items using our EWS API, with 1024 characters in the body and save it in the different mailbox configurations. For the attachments test, a 1024 characters attachment txt file was attached to each message in addition to the original body. In conclusion, Exchange 2013 and 2016 brought a good change in terms of accuracy to how big a mailbox really is, but the side effect of it, is that you will need to increase your user's mailbox quotas and warning limits during migration from pre 2010 versions. Check these related articles by Tony Redmond: Exchange 2013 counts data within databases better—may affect user mailbox quotas Increase in Exchange 2013 mailbox sizes is simply "Store tax"

Error accessing Public Folders Hierarchy in coexistence environment 2007-2013

dseveso — Fri, 19 Aug 2016 20:00:09 GMT

This is a specific issue we have encountered in several deployments, for customers migrating from Exchange 2007 to Exchange 2013, or simply by having the two versions coexisting in their environments due to specific requirements. When you attempt to manage your legacy Public Folders from the Public Folder Management console in this scenario, you can connect to the PF server, but the PF hierarchy might not be visible under Default Public Folders node. If you use Exchange Management Shell instead, Get-Publicfolder or Get-Publicfolder \ -Recurse would return the following error:

Get-PublicFolder : There is no existing PublicFolder that matches the
 following Identity: '\'. Please make sure that you specified the correct
 PublicFolder Identity and that you have the necessary permissions to view
 PublicFolder.
 At line:1 char:1
 + Get-PublicFolder
 + ~~~~~~~~~~~~~~~~
 + CategoryInfo          : NotSpecified: (0:Int32) [Get-PublicFolder], Mapi
 OperationException
 + FullyQualifiedErrorId : C00ECE14,Microsoft.Exchange.Management.MapiTasks
 .GetPublicFolder

This issue does not prevent Outlook clients to access public folders. When Exchange 2007 sets up the mapi session to access the public folder database and read the PF hierarchy, it builds the system attendant mailbox DN based on the server's DN that hosts the oldest (first created) private MDB object. Assuming that the oldest database in the organization was created in Exchange 2007, everything should work fine. However if Exchange 2013 joins to the organization and, later, the Exchange 2007 databases are recreated, it is possible that an Exchange 2013 private MDB becomes the oldest database in the environment, causing the issue described above. The problem is that due to architectural changes in Exchange 2013, the server's system attendant object is no longer populated with the homeMDB attribute used by Exchange 2007 to create the mapi session (remember Databases no longer belong to servers after Exchange 2010, but to Administrative Groups). A quick workaround to this issue, is to set the homeMDB attribute of the Microsoft System Attendant object under the Exchange 2013 server hosting the oldest database in the environment. If this database is part of a DAG with copies in multiple servers, each system attendant object under each server should be modified. You will need to perform this change using a low level directory service tools like ADSIEdit, and as such, this change is unsupported in nature, please proceed at your own risk. How do we know how old is a database object? just by inspecting its whenCreated attribute in AD. Get-MailboxServer | Get-MailboxDatabase | Sort-Object whencreated| fl name , server, whencreated, will give you a list of mailbox database objects in your environment ordered by creation date. Which homeMDB name should we use for the property value? You can select the DN of one of the databases hosted on the server being modified. In the example below, assuming the oldest database is active on server EXHR-2006, you will be populating the homeMDB attribute of the "Microsoft System Attendant" object with its value equals to the distinguishedName property of the "Mailbox Database 1450518890". Another, more difficult workaround, would be to re-create the conflicting Exchange 2013 databases so that their whenCreated attribute is greater than the whenCreated attribute of the oldest Exchange 2007 private database. Depending on the number of Exchange 2013 databases and how recent is your oldest 2007 database, this workaround could be unfeasible.

Alternate way to get your Exchange build numbers

dseveso — Wed, 03 Aug 2016 19:40:09 GMT

I wanted to share a little script that turned to be very useful for me. Get-ExchBuild.ps1 lists the build numbers for all versions of Exchange listed in the official TechNet page, but from the convenience of the PS command line. You can run it without parameters to return them all, or restrict the output to certain versions of Exchange (tab autocompletes). Specifying the -Cloud parameter returns the Exchange build of the mailbox server hosting your Office 365 mailbox, if you happen to own one. Just create a text file, paste the script code from here, and save it as Get-ExchBuild.ps1 in c:\windows or anywhere in your $env:path. Your execution policy should be set as RemoteSigned in order to run local scripts on your system. Due to its dependency on the TechNet page it's likely that the script will break if there's significant changes in its content. I'll try to keep it running. Thanks!

Not all 106 are created equal

dseveso — Fri, 08 Jul 2016 19:09:00 GMT

Of course that's not accurate. When MSExchange Common source writes an event 106 about performance counters, the format of each event is exactly the same and reads:

ID:       106
Level:    Error
Source:   MSExchange Common
Machine:  server1.contoso.com
Message:  Performance counter updating error. Counter name is <counter name here>, category name is <category name here>. Optional code: . Exception: <actual exception here>...


What I mean by the title, is that depending on the reported Exception message, the actual issue and its consequences could be profoundly different. Understanding some of those differences helps on assessing the issue at hand.

 
There are at least 3 common exception messages, these are examples
(Counter, Category, and Exception message vary):

Performance counter updating error. Counter name is Percentage of MSAUserNetID Cache hits for last minute, category name is MSExchange Global Locator Processes. Optional code: 3. Exception: The exception thrown is : System.InvalidOperationException: The requested Performance Counter is not a custom counter, it has to be initialized as ReadOnly.

This is the most common exception and normally not affecting more than the counter itself. Depending on the counter being reported the root cause can be code trying to access counters on an instances that is no longer running or disabled. The call stack could give us more insight on the specific situation.

 

Performance counter updating error. Counter name is Time in Resource per second, category name is MSExchange Activity Context Resources. Optional code: 2. Exception: The exception thrown is : System.InvalidOperationException: Instance 'ad-umworkerprocess-umworkerprocess.exe' already exists with a lifetime of Process.  It cannot be recreated or reused until it has been removed or until the process using it has exited.

This is normally thrown by MSExchange Activity Context Resources and related to processes running multiple instances with the same name on the server (i.e. microsoft.exchange.store.worker.exe , umworkerprocess.exe, etc.). In this case, a conflict with the name of the counter instance causes only the first counter to be created and the subsequent counter instances to fail. This issue has been internally reported and likely to be fixed in upcoming  CUs.

 

Performance counter updating error. Counter name is Cache misses in the DistributionListMembership cache/sec, category name is MSExchangeIS Store. Optional code: 2. Exception: The exception thrown is : System.InvalidOperationException: Custom counters file view is out of memory.

This exception message is particularly important because it seems to be the only one with real impact beyond the counter itself. The issue comes when the category MSExchangeIS Store is affected. If Exchange is running in a DAG environment, failing to update any database instance of that counter category, can cause problems activating databases with an error similar to:
Log Name:      Microsoft-Exchange-HighAvailability/Operational
Source:        Microsoft-Exchange-HighAvailability
Event ID:      306
Task Category: Database Action
Level:         Information
Keywords:      
User:          SYSTEM
Computer:      server2.contoso.com
Description:
Initiating move for database 'DB1' (FromServer=server2.contoso.comm, ToServer=, MoveComment=UnexpectedDismount)
This happens when Active Manager is unable to read the ProcessID counter from MSExchagneIS Store on the pasive database instance. If you're wondering whether you're running into this problem, check on the MSExchangeIS Store counters in perfmon and verify if they have values other than zero for all the database instances.

If the exception message for MSExchangeIS Store is "System.InvalidOperationException: Custom counters file view is out of memory" it is possible that the custom value FileMappingSize is missing from the service's registry key.
This value is created by Exchange Setup when the counters are registered, and it is probably gone if the counters were recreated on your server without specifying this FileMappingSize value (i.e. if a script has been used to reload all Exchange counters in bulk).

The value for Exchange 2013 and 2016 (CU13 and CU2 respectively at the time of this writing) is:
FileMappingSize : 5242880 (DWord)
PSPath          : Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\system\currentcontrolset\services\MSExchangeIS Store\Performance
It this value is missing, it can be manually created in the registry . Restart the server to make sure the value is read when each store worker instance starts.