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.

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.

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 on the VMWare knowledge base: http://kb.vmware.com/selfservice/viewContent.do?externalId=1006764&sliceId=1

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.

In one such case, I could log into the domain controller with an administrative account in the domain of the domain controller.  However, when trying to log into the domain controller with a account from a trusted domain, I kept getting the same error message and denied logon.  The domain controller is hosted off-site in another timezone.

I made sure both domain controllers were synchronised correctly, manually corrected the time (which was already synchronous) and even rebooted the faulty domain controller.

It was only until I went to check the Timezone settings that I found something peculiar: the time zone settings indicated that the location was 3 hours ahead of GMT, while my location was 1 hour ahead.  And still, the difference between my location’s time and the culprit’s location was only one hour.

Again, the error was in a Daylight Saving Time setup which was outdated as described in one of my previous posts, and the local admin manually correcting the time into a time which was actually one hour behind our domain’s time.

You can use the following Microsoft Knowledge Base article to read up on making sure your domains are up to date with new Timezone settings: http://support.microsoft.com/kb/914387/en-us