Change the “Access request to a site” email recipient

As a reminder for me, from

By default SharePoint 2007 automatically configures the access requests for a particular site to go to the person who created the site. This is not always what you want and you may find yourself receiving  “Access request for a site” emails for sites you setup, but don’t actually manage. You can change this by doing the following:

  1. Navigate to the site in question
  2. Navigate to People and Groups > Site Permissions > Settings > Access Requests
  • Change the Send all requests for access to the following e-mail address: to the proper address.

    Error moving mailboxes?

    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

    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

    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.


    Lost your disconnected mailboxes on Exchange 2007?

    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:

    1. Get-Mailbox | Format-Table Name, Database
    2. Disable-Mailbox
    3. Clean-MailboxDatabase “Mailbox ServerMailbox Database Storagegroup Name”
    4. Connect-Mailbox -Database “Mailbox Database” -Identity “John Peoples”   -User

    Hydrating Microsoft Deployment Toolkit 2008

    The Microsoft Deployment Toolkit 2010 is already available in beta, but many companies are just getting up to speed using MDT 2008 for their deployment needs, not to mention the numerous companies that are still working with BDD 2007.  Microsoft’s deployment solutions are surely fast moving these days.

    What I missed in the documentation of MDT 2008 is a way for me as a consultant to set up an MDT environment with sources, settings and images, and being able to deploy these sources, settings and images to a client’s MDT.  This because most clients have similar set up environments, with all similar starting sources.  It is no use to send the first half day of your consulting job importing sources you have already imported numerous times for other clients and yourself.



    Windows clients forget their domain after you reset their snapshot?

    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.