Exchange Dev fixed a long running issue that causes 9548 errors on your Exchange Servers.
See blog entry here – http://blogs.technet.com/exchange/archive/2006/03/22/422799.aspx
What do I say about this? About damn time.
When I first encountered this back in around 2003 or so and it was actually causing issues on Exchange servers with hangs, etc and PSS explained it to me I was like “You have got to be kidding me…”. My response was, if the account is disabled and doesn’t have a masteraccountsid set, why don’t you just assume SELF and got the response back that if someone wants it set to SELF they would do it. I couldn’t get the point across to PSS/DEV that people don’t understand this and that they (Exchange Dev) broke a standard enterprise process of disabling user’s instead of deleting them.
Enterprises don’t like to delete, at least right away, because recovery is such a pain. So they don’t, they use a staged delete where the first phase is disable. This works great right up until you upgrade to Exchange 2000/2003. Then doing so without setting more attributes for Exchange causes Exchange to start hiccuping and enough of that and it can’t breath at all and starts to stumble. Dumb dumb dumb. Lots of different ways this could have been implemented versus just making an assumption but oh well, it wasn’t done that way and finally after years of lots of people bitching they finally corrected it.
It took so long to fix because it took that look for Exchange Dev to step up and admit it was a problem. I first heard last summer that they finally accepted this as a problem and were going to correct. Actually the people who told me seemed amazed by it as well and they were from Microsoft. It seems I am not the only one who thinks that Exchange Dev isn’t the most responsive to problems real customers experience.
Remind me to talk some time about the nasty bug in ESM/WMI for showing which GCs are in use that I have been debating with MS now since last summer. The best response to date was that WMI wasn’t intended t be used for monitoring…. How do you respond to that since that is one of the primary uses of it by Microsoft themselves. The runner up response was this is all fixed and done differently in E12…. Yeah so, it isn’t like every customer I help will jump to E12 as soon as you guys decide to release, I still talk to a ton of companies and people running E2K, they obviously aren’t in any upgrade hurry. At the moment I am on my 5th or 6th week I would guess of no response since being told, let me find out the status and I will get right back to you.
If I dig through my mailbox archive I could probably find
the e-mail chain where I reported this issue in the
Exchange beta program. Being in the UK it was hard to
get a response but we were eventually told this was
expected behavior and would be in the gold product
which of course it was 🙁 So we wrote our deprovisioning
around this and updated the masterAccountSID on the
(pending-delete) users. I was amazed that, seemimgly no
upgrade testing against a real, dirty AD had been done
and disappointed that the feedback was not (IMO) taken.
We since updated our deprovisioning to dump the AD
user object, take a final back up of filestore and profile
and exmerge dump the exchange mailbox before delete
to aid recovery.
I am amazed this has finally been fixed.