Ok part 2 of 2 posts on some new reasons MSExchange annoys me….
I was pinged on a thread discussing a problem with the msExchMailBoxGuid being the same as the objectGUID for some mailbox enabled users and whether or not it was “bad”. The first thought is, have I ever seen this? I do a quick scan and realize that all of the system mailboxes have the same GUID for both. This is obviously supported at least for those so it can’t be entirely bad…
On the surface you think, and I did think, hey this is probably fine, maybe this might even be a good idea. Why have all of these different unique ways to mean a single user… Then on further reflection and testing the realization hit me that there indeed could be a rather big issue with this. Exchange, for some reason I have no understanding of, uses the following query to resolve mailboxes to user objects
( | (msExchMailboxGuid=6418167d-6b02-4ebe-8f0e-1a628945ba71) (objectGUID=6418167d-6b02-4ebe-8f0e-1a628945ba71) )
If you enable tracing on a DC being (ab)used by Exchange or crank up inefficient/expensive query logging you will see just a ton of those queries. So, do you see the issue?
The issue is, what if instead of getting a single user object back, Exchange gets two back? I can tell you what Exchange does. It freaks out. I disconnected a mailbox from a user which I had forced the two GUIDs to be the same on. I then reconnected it to another user. This means two different accounts would resolve from that query…
So after I did this I saw about 50 events per second from 5:07:13PM to 5:10:18PM, the exact time I had the mailbox set up that caused this problem. That’s right almost 10,000 events. All of the events were
Source: MSExchangeIS
Event ID: 9536
Description:
An ambiguous Mailbox Guid xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx was found on 0x2 mailboxes in the DS. The store cannot map this Mailbox Guid to a unique user.
This actually makes some other things make sense that I have to check into now at some point.
The next question is how does this happen in the first place? It seems that if you use an LDAP modify to tweak a couple of the attributes on a mail-enabled user to make them a mailbox-enabled user (these attributes would be to clear proxyAddresses and targetAddress and set a homeMDB value) you run into the case where the RUS will set the mxExchMailBoxGuid to the same value of objectGuid of the user. WTF? Why would it do that? When you mailbox enable an account just by setting the mailnickname and homeMDB values it doesn’t do this, why does it do it in this case? In what instance is this the right thing to do? Dare I say bug? Well I might dare to and someone might actually agree inside of MS but the only word you will ever hear back is that it is by design and modifying accounts via LDAP isn’t supported so stop it.
Anyway, how do you get around this? Well the easiest way is to listen to MS and don’t mail*-enable users with LDAP mods, use only the supported toolsets. LOL.
Hmm back to reality… They suck and they are doing LDAP mods themselves, see previous post as to WHY you may want to AVOID the Exchange programming interfaces which doesn’t even mention the idea that you might want to manage an org in a forest your machine isn’t a member of which is YAT that CDOEXM sucks at. Plus, the cool thing about storing stuff in AD is the ability to use LDAP to modify the info. If Exchange doesn’t like it, get the Exchange data out of AD. Many of us are kind of sick of the half in half out integration that was done anyway, especially on permissioning.
So next?
When mailbox enabling a mail-enabled user, clear all attributes and then set the mailbox enabled specific attributes. The alternative is to generate a GUID yourself and verify its uniqueness and then set that when setting the other attributes previously mentioned. This last is probably the best way and probably the mechanism I will put into ExchMbx when I add the NON-CDOEXM based functions for doing mail-enabled to mailbox-enabled whenever I get a chance to do that.
joe —
just wanted to remark that i searched for any events that correlate to what you’re describing above in mom. nothing came up. does that mean that the exch product group doesn’t believe this situation would occur in the wild? 🙂
::m
Not sure. Could be that MS IT never saw it because I think that is where most of the stuff MOM catches comes from. Since I was initially asked to look at this I have been talking to quite a few folks though who are seeing a lot of this. Just depends on how their provisioning system works. Any provisioning system that doesn’t strictly use cdoexm to do the conversion from mail-enabled to mailbox-enabled could have the problem. The way you have to do it in cdoexm is mail-disable, then mailbox-enable.
Joe,
As long as we’re on the subject of GUID’s, is there anyway to change the GUID of the mailbox. If I need access to a users mailbox (including all dumpster items) without the user knowing, it would be very easy to just restore the database to the RSG and mount in in a production DB. The only problem – it’s not possible to connect another AD account to that mailbox because the original mailbox has the same mailbox GUID.
To get around this issue, Glen at gsexdev.blogspot.com created a script to access all items including dumpsters for every folder.
Teo
Changing the mailbox GUID, if possible at all, would require something reaching into the mailbox store with MAPI and modifying it, I doubt MS has anything exposed to do this. In fact it almost seems like they don’t want anyone using MAPI but themselves and then you calling interfaces they expose, of course this leaves you up a creek when you want to do something they don’t forsee like doing decent mailbox reconnects, etc.