The Migration mailbox for the organization is either missing or invalid.

I was contacted about this error by one of my blog readers after posting Cannot Open Microsoft System Attendant Mailbox Error During Exchange 2013 Mailbox Move. In this case, the error message is clear enough.

The issue was that the Microsoft Exchange Migration (Migration.8f3e7716-2011-43e4-96b1-aba62d229136) arbitration AD account was present, but without an associated mailbox.

The solution was to configure a mailbox for the account using the command below.

Enable-Mailbox “Migration.8f3e7716-2011-43e4-96b1-aba62d229136” –Arbitration

Once the migration arbitration account was configured, the mailbox move was successful.

The post The Migration Mailbox For The Organization Is Either Missing Or Invalid Error During Exchange 2013 Mailbox Move appeared first on HOW EXCHANGE WORKS.

Exchange 2013 doesn’t have system attendant mailbox or even the System Attendant service (mad.exe).

But, the error clearly mentions about the failure to open the attendant mailbox. Though System Attendant mailbox & service have been removed from Exchange 2013, the object is still present in the configuration partition.

But, that was not the cause of the error. Exchange 2013 has a new arbitration mailbox “Migration.8f3e7716-2011-43e4-96b1-aba62d229136” with a display name “Microsoft Exchange Migration”.

In my case, the database hosting this arbitration mailbox was dismounted for some reason. I mounted the database back and the move was successful. In short, this arbitration mailbox is required for successful mailbox moves.

If you have deleted it by mistake or it doesn’t exist in your Exchange (for whatever reason), you can always re-create the AD account by running Setup.exe/PrepareAD. Once the account is created, configure a mailbox for the account by running the command below.

Enable-Mailbox –Arbitration –identity “Migration.8f3e7716-2011-43e4-96b1-aba62d229136”

The post Cannot Open Microsoft System Attendant Mailbox Error During Exchange 2013 Mailbox Move appeared first on HOW EXCHANGE WORKS.

In order to provide failure isolation in the database level in 2013, Microsoft has introduced two new processes as part of the managed store concept. First is the Store Worker Process(Microsoft.Exchange.Store.Worker.Exe) which does the same job that store.exe handled in previous versions. The only difference in 2013 is that a single Store Worker Process is only responsible for one database.

The benefit with this model is that if there is anything wrong with a single database process, it only affects that database. All other databases will be online as they are serviced by different worker processes. So, if you have 5 databases mounted, you will have 5 separate store worker processes.

The second one is the Store Service Process(Microsoft.Exchange.Store.Service.Exe) & it is the process that controls the different store worker processes. When a database gets dismounted, it is the store service process which terminates the store worker process that was responsible for that database. Similarly, when a database gets mounted, the store service process brings a new store worker process for that database. The store service process is a controller of all the other store worker processes.

The question I got from Simon (via email) was about finding a way to determine which store worker process handled a mailbox database. In short, he wanted to map all the mailbox databases to it’s store worker process. Let’s find out how easy it is.

I have three databases mounted on my server.

As you would expect, I have a single store service process and three worker processes.

I can find out the process ids of the worker processes using the Details tab of the task manager, but it doesn’t tell me which worker process maps to which database.

In order to find the mappings, launch Exchange Shell & run the command below.

Get-MailboxDatabase –Status | ft name, workerprocessid

Now that you have the store worker process & the process id from the task manager and database name & process id from the Shell, it is easy to find out which worker process is handling which database. In my case, worker process with pid 5764 maps to DB1, 8872 to DB2 & 8608 to DB3.

If you find that one store worker process is hot on CPU or memory, you can find the database behind it this way and take administrative action.

The post How To Find Which Store Worker Process Is Responsible For A Mailbox Database In Exchange 2013 appeared first on HOW EXCHANGE WORKS.

In Exchange 2010 ECP, end users were able to edit their contact details, address etc depending on the role assignment policy. In Exchange 2013 ECP ( OWA –> Options), the end user can see his current photo in AD & change it with a new one if required.

Login to OWA 2013 & click on “Options”. This brings the familiar “My Account” page. By default, no photo is selected for the user (unless it is set already).

The user can click on “Edit information” option at the bottom of the page to make changes to the account info, including changing the photo.

This brings up a new window, with options to edit the account details. The first tab lets the user to change/upload photo.

Browse to the photo of your choice and save. The photo will be displayed in the “Options” page immediately.

And sure enough, photo gets displayed in your inbox. If you have Lync or SharePoint deployed, the photo will be displayed there as well.

This may be an option that needs to be restricted, depending on how strict the company policies are. You don’t want any offensive pictures displayed in the GAL

The post Upload GAL Photos Using Exchange 2013 OWA Options (ECP) appeared first on HOW EXCHANGE WORKS.

While browsing the EAC, I noticed that the OWA virtual directory displays that the OWA Version as Exchange 2010 & not 2013. This happens in an Exchange 2013 only environment.

The Shell displays the same info.

MS, Is it a bug in the code or a typo?

Update: The issue is the same in Exchange 2010 RTM and if you have moved from RTM to CU1. Fresh install of CU1 fixes the issue.

The post OWA 2013 (RTM & CU1 Upgrade) Virtual Directory Displays The OWA Version As Exchange 2010 appeared first on HOW EXCHANGE WORKS.

I take this opportunity to thank all my readers for your continuous support. I couldn’t have done this without you guys.

The post 2 Million Hits & 2.67 Million Page Views appeared first on HOW EXCHANGE WORKS.

The name has been changed as the calculator now makes recommendations for both the Mailbox and CAS roles. If anyone out there is still confused, this is the 2013 equivalent of the 2010 Storage Calculator.

The look and feel is the same as the 2010 calculator.

Download the calculator here.

Now that the 2013 CU1 & SCOM Management Pack is out along with the calculator, there is nothing stopping the admins (ofcourse, the brave ones ) to start deploying Exchange 2013 in production.

The post Exchange 2013 Server Role Requirements Calculator v5.1 appeared first on HOW EXCHANGE WORKS.

The Microsoft Exchange Server 2013 Management Pack provides comprehensive service health information for the Exchange organization and is engineered for organizations that include servers running Exchange 2013.

The key feature of this management pack is user focused monitoring. The simplified dashboard focuses on the user experience and makes it easier for admin to quickly determine exactly what users are experiencing.

The pack can be used with SCOM 2007 R2, SCOM 2012 RTM or later.

Download the management pack here.

The post Exchange Server 2013 Management Pack Released appeared first on HOW EXCHANGE WORKS.

The calculator is an Excel spreadsheet that calculates WAN bandwidth requirements for a Lync Server deployment based on administrator-specified user profiles and network information.

With the Lync Server 2010 and 2013 Bandwidth Calculator, you can enter information about your users and the Lync Server features that you want to deploy and the calculator will determine bandwidth requirements for the WAN that connects sites in your deployment.

Download the calculator here

The post Lync 2010 & 2013 Bandwidth Calculator Released appeared first on HOW EXCHANGE WORKS.

From Exchange 2013 RTM onwards, whenever a new database is created, the information store service should be restarted for proper memory management. The warning is not displayed in 2013 RTM, but the CU1 exposes it.

Even if you don’t restart the service, the database will get mounted and will be operational. You can move mailboxes to it and perform regular admin tasks, but caching won’t be efficient. The requirement to restart the service is due to the new memory management model and Managed Store in 2013. The store calculates the amount of memory it needs to manage all of the databases only on two occasions – server start-up and when the information store service gets restarted.

This requirement will change the way admins manage databases currently and will push for an approved change request (CR) to create a new database and have it fully operational. Check Tony Redmond’s article where he explains the topic in detail.

The post Restart Information Store Service After Creating New Database In Exchange 2013 appeared first on HOW EXCHANGE WORKS.