I needed a quick way to gather all IIS logfile locations in several SharePoint farms. IIS has a nasty way to reference to numbers instead of names in their logging directory structure, so you need to watch the Advanced Settings panel in IIS to figure out which logging directory is for which website.
This could be done easier, I thought. And so thought many before me.
As a reminder for me, from http://vspug.com/wkkf/2007/05/09/changing-recipient-of-access-request-for-a-site-emails/
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:
- Navigate to the site in question
- 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.
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-00000000For 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-00000000For 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.
So you’re happily clicking and typing away, and you need to relink a mailbox to another AD user. So you do the obvious:
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:
