Quick update on the bug that I reported a few weeks ago...

 

During the MCM class, I had a chance to follow up on the SPManageAccount issue.  It turns out that the Managed Account feature simply looks up the account based on the actual string representation of the account (i.e. domain\account) rather than relying on the SID.

 

When I uncovered this problem, we had been actively using the account, discontinued use (but left it in the SPManagedAccount collection), and deleted the account from AD.  Since we had already loaded the information into memory, the netlogon api had effectively cached the user information.  Thus, subsequent lookups appeared to fail even though we had tried the simple process of recreating an identically named account (cached sid value didn't match the new sid value).  If we had just waited 15-20 minutes for the cache to timeout, we would have found that creating a new account with the same name would have worked. 

 

Net result: the bug is not as bad as it seems.  You are not required to restore the orginal account (sid).  Wait for the system to flush out the old cached values, then create a new account with the same login name.  At that point in time, you should be able to regain functionality and properly clean up your SPManagedAccount collection.

 

Thanks to Todd and Sean for helping unravel the issue...

 

-Maurice