I have just finished an upgrade from Exchange 2007 (in a SBS 2008 environment) to Exchange 2013. There are a lot of changes when going from 2008 to 2013 but am glad that I was able to be part of the update. We ran into a few minor glitches along the road but overall the upgrade was a fairly smooth process. That was the truth except for one issue. It wasn’t a critical issue but it did end up causing some significant “client annoyance”.

During the upgrade I had installed the OS onto a 150GB Partition which is a fairly standard setup for us. This was all good as I had added an additional partition to place the mailbox databases on. The issue was that in all of the excitement of the upgrade I forgot to move the database over to the new drive.

So as you could imagine the primary partition filled up pretty quickly which started to cause all sorts of issue such as back pressure on exchange, etc etc etc. So this was picked up pretty quickly and to resolve it the balance of the mailbox moves were cancelled. A new database created on the correct partition and then the mailboxes moved from the existing database to the database in the correct location. Easy fix.

The issue that appears to have crept up from that error was that the mailboxes that were moved originally (a handful of them) started to receive the following message on the outlook clients on a regular basis.

The Microsoft Exchange Administrator has made a change that requires you quit and restart Outlook.

Now the message didn’t stop outlook from running. Once the message was cleared outlook worked without a glitch, except that regularly that message would re-appear. If the message was left in the background then everything worked fine. Despite this, it was a major pain for the customers as they always had this error message appear.

Now some of the users, if their profile was re-created would have the message go away for good, but others were not so lucky.

So what was causing the issue? It was a good question as there were no differences between an account that was getting it and one that wasn’t. So I researched the issue and stumbled across a number of helpful articles but none of them quite what I was looking for.

One of the tests that I performed was an “Outlook Connectivity” test from the Test Exchange Connectivity site. For the accounts that were having the trouble it received an odd error. The test would fail with an error “ecLoginFailure”

Great. I had something to go on. So I looked into this error and all that I found was a few MSDN Developer references, some references to service starting issues and some exchange 2003 references. Figured the best place to start would be the MSDN items. After reading the following articles.

• ROPLogon Codes
• Private Mailbox Logon

In the second article it says the following about the different error codes.

The server then finds the mailbox in the mailbox table. If the mailbox is not present in the table and the user has owner permission on the mailbox, the server creates the mailbox. That process includes creating the default folders and establishing the proper Receive folder values. For details about setting Receive folder values, see section 3.2.3. The server does not create the mailbox if the user does not have owner permission. In that case, the ROP fails with a ReturnValue of ecLoginPerm or a ReturnValue of ecAccessDenied; the return value is implementation specific.<27> Other failures to find the user in the mailbox table (beyond a “not found” error) MUST fail the operation with a ReturnValue of ecLoginFailure.

Well that is a little disappointing, from how I read it you either get authentication failed or ecLoginFailure which could be a whole range of other errors. This however is better then nothing so now I know the following..

• We are not getting an exLoginPerm or exAccessDenied error so the mailbox was present and the permissions were correct

My hunch on the error was that there was an error with the mailbox that Exchange was trying to correct but was not able to which is why the message continually re-appeared. So I thought that maybe it was an error with the mailbox that may be fixed up by moving it to a new database. It couldn’t hurt to give it ago. After creating a new database I performed the move request

New-MoveRequest -identity [email protected] -TargetDatabase “New Database”

Once the move was complete the message would appear on the client one last time and then not re-appear.

So the issue in the end was something to do with the original migration from Exchange 2007 to 2013. My guess is something to do with the way the mailbox was associated with the Exchange database???