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.

Do it quicker.

You can, using the Command Prompt or Run in the Start Menu, type in the corresponding Microsoft Management Console Snap-in Control file to open the correct domain.

For instance, to open up the Active Directory Users and Computers console for Contoso’s subsidiary in Paris (domain “paris.contoso.com”) you could use the following:

dsa.msc /domain=paris

This will open the Active Directory Users and Computers console with the paris domain opened.

Some of the other snap-ins you can open directly:

Any ADSI or WMI query to a list of your group memberships will turn out to 1000 members in Windows 2000 mode, or 1500 in Windows 2003 native mode. Only by using ADO range limits, you can go by this soft limit.

This shouldn’t pose a problem when you are just adding members to an already big group. However, it does.

$userOU = [ADSI] "LDAP://cn=myUser,ou=Users,dc=contoso,dc=com"
$groupOU = [ADSI] "LDAP://cn=myGroup,ou=Users,dc=contoso,dc=com"
$groupOU.Member = $groupOU.Member + $userOU.distinguishedName
$groupOU.SetInfo()

Adding the myUser user to the myGroup group will work fine if the group member count is below 1500. Once above, your group will suddenly loose an amount of members until you are left with a group of just 1500 members, and then added by the new member.

What actually happens is self-explanatory when reading the code: the group members is the group member list plus the new member. When the group member list only returns 1500 members, and then you add one member, you are left with 1501 members, and not your original amount of members + 1.

A workaround is this:

$ADS_PROPERTY_APPEND = 3
$userOU = [ADSI] "LDAP://cn=myUser,ou=Users,dc=contoso,dc=com"
$groupOU = [ADSI] "LDAP://cn=myGroup,ou=Users,dc=contoso,dc=com"
$groupOU.putEx($ADS_PROPERTY_APPEND, "member", @($userOU.distinguishedname))
$groupOU.SetInfo()

In this workaround, we are going to use putEx to append a member to a group, instead of loading the full member list (with a limit of 1500) and then adding a new member.

Source.