AS I write this, my friends at Microsoft Product Support Services (MSPSS) are currently remote-controlling my PC in an attempt to resolve my problem with my manging partner’s Exchange mailbox. Essentially, I reached the end of my attempts this morning, as I even attempted to remove all Exchange attributes on the user and recreate them. Interestingly enough, when a new user is created, this problem does not exist. Furthermore, this is the only user for which this problem exists. All of the other users in my organization don’t have this problem.
One of the items I attempted to perform in my early morning troubleshooting was to even recreate the user account for the user and reconnect it to the mailbox. This, of course, had no effect on the problem at all. It did, however, create the one problem I forgot about–it munged his local profile on his laptop. I forgot that when one creates a new account in Active Directory, a new SID is created. Obviously, the SID is tracked within the registry to track who has access to the local profile. When my user logged in this morning, he had a new profile created in %SystemDrive%\Documents and Settings\ of the form username.domainname. This was no good to me, since we had everything else we needed for the user in their local profile.
After lunch, I had to do some quick research on the subject as none of my earlier attempts to swap profiles did not work. Thanks to
Drew Mclellan at “Recovering a Windows Profile.” One caveat to this fix is that your user account will have to have NTFS rights to the old profile directory, and the user will probably need to have local administrator rights to the workstation. The short way to fix this is to:
- Make sure to login to the local machine as an administrator or equivalent.
- Click Start|Run, then type regedit in the Open field.
- Navigate to HKLM\Software\Microsoft\Windows NT\CurrentVersion\ProfileList. You should see a series of keys on the left that will look like S-1-234567890. These are SIDs, and they correspond to the actual users logging into your system.
- Hit CTRL+F to bring up the Find dialog box. In the Find what: field, enter %SystemDrive%\Documents and Settings\oldusername.domainname. Essentially, you should find this entry once. The SID this was associated with was your old user account.
- Edit the value of this key such that it has the name of your old profile directory. In other words, make the value %SystemDrive%\Documents and Settings\oldusername.
- Reboot your machine, and now login as the user again–making sure to log into the domain. Your new settings should be restored as they were before.
I am still watching MSPSS work their magic, but I don’t think my tech quite understands my issue. It looks like I might be here for a while watching him remote control my workstation. At least their per incident support charge is cheaper than Novell’s ever was. 😉
As I was thinking, the mailbox will need to be deleted and recreated, then reconnected with the user. Looks like ExMerge is going to play a role in this process. Wonder how ExMerge handles over 2GB of mail? The problem in this case was that someone–presumably a consultant that preceded me–gave Full Mailbox Access rights to the group Mail Operators. Mail Operators includes all of my users–something I need to fix. As a result, in the case of this mailbox, they had full access to our partner’s mail folders. Once this was removed, access to his folders behaves as it should.