So you’re cleaning out a storage group, and there are a bunch of mailboxes that you don’t seem to be able to move?
If you check the Eventlog, do you find these events?
The MAPI call ‘OpenMsgStore’ failed with the following error:
The information store could not be opened.
The MAPI provider failed.
MAPI 1.0
ID no: 8004011d-0289-00000000
For more information, click http://www.microsoft.com/contentredirect.asp.
Failed to open mailbox ‘/o=CONTOSO/ou=First Administrative Group/cn=Recipients/cn=JohnDoe’ in mailbox store ‘/o=CONTOSO/ou=First Administrative Group/cn=Configuration/cn=Servers/cn=ContosoMailServer/cn=Microsoft Private MDB81234567′ on server ‘ContosoMailServer’.
Error: The information store could not be opened.
The MAPI provider failed.
MAPI 1.0
ID no: 8004011d-0289-00000000
For more information, click http://www.microsoft.com/contentredirect.asp.
Quickly check if these users are not disabled. Mailboxes with disabled users as associated account cannot be moved. The workarounds are to enable the user accounts – which is not that desireable for your company’s Security staff – or assign SELF as the associated account.
More info at Microsoft.
So you’re happily clicking and typing away, and you need to relink a mailbox to another AD user. So you do the obvious:
- Go into the Exchange 2007 Management Console (or Shell)
- Find the mailbox in the Recipient Configuration
- Write down the server the mailbox is stored
- Disconnect the mailbox from the original AD user
- Get a list of disconnected mailboxes on the server you wrote down
Only to find that the mailbox is not listed. Panic!
Did you forget to check the Deletion Settings on the mailbox store? No, on second glance they are the default 30 days, so the disconnected mailbox should still be available.
But, wait… On Exchange 2003, didn’t you run the Cleanup Agent to find disconnected mailboxes?
No such a thing in Exchange 2007, or is there?
Yes there is. Clean-Mailboxdatabase is your cmdlet and friend. Run Clean-Mailboxdatabase <databasename> in an Exchange Management Shell and reload your list of disconnected mailboxes.
You saved the day! Or at least Exchange saved your job 
.
So next time:
- Get-Mailbox john@contoso.com | Format-Table Name, Database
- Disable-Mailbox john@contoso.com
- Clean-MailboxDatabase “Mailbox Server\Mailbox Database Storagegroup Name”
- Connect-Mailbox -Database “Mailbox Database” -Identity “John Peoples” -User john@fabrikam.com
Today, I received my invitation to BlueBear’s new Kodiak 0.0.3. Kodiak is a virtual infrastructure management tool created in Adobe’s AIR and should be multi-platform in both server and client technology. Currently, any AIR platform is supported as client platform, and from Kodiak you can manage VMware ESX, ESXi and Server products. BlueBear claims that Xen support is underway, and HyperV should happen in the future too.
I’ve been trying Kodiak now for a few hours on OS X and although it looks pretty and helps me visualize my test environment running on VMware Server 2, I am still unable to use the console. Kodiak’s documentation is sparse, which is not helped by it’s current apply-and-you-might-ever-get-allowed-to-the-beta program. But I hear positive comments when running it on Windows, so if you want to try Kodiak out, don’t wait and head over to their website to register yourself into the beta program.
BlueBear Kodiak 0.0.3 screenshot
One small reminder: if you want to connect to your VMware host (let it be ESX, ESXi or VMware Server 2), make sure you use the same server address as you currently use in your VMware Infrastructure Client: servername-or-ip:portnumber. It saves you the humiliation of running into error #2032, which actually means that AIR and Kodiak is not able to connect to your VMware environment.
And I want my console to work!
Update: Bluebear came out with 0.0.4 of their Kodiak management software, with some SSL modifications that would make working with self signed certificates much easier.
Ever run into a problem where you revert a domain member server or Windows XP domain client toa previously taken snapshot, and when trying to log on the domain, the logon fails?
I did in 2007, and never really thought of it until I ran into the following article 1006764 on the VMWare knowledge base.
The cause is very simple, and so is the solution: Member servers and clients have, just like users, accounts with passwords. If set up like this, these passwords are reset every set period. If you revert a machine back to an old snapshot, chances are that the password stored in the snapshot is not up to date with the password stored in Active Directory, and hence, Active Directory does not allow the machine to log on again.
So you’ve set up yourself a nice farm of production, testing and acceptance SharePoint servers, and you want to build a new test server.
You make a backup through the Central Administration website, and on your soon to be testing server, you restore the backup.
And then you want to connect the restored Content database, only to discover that SharePoint claims that this database does not contain any sites… Oops? Continue reading ‘Restoring SharePoint sites, doesn’t!’
