There are a lot of scripts out there to report a mailbox’s current size and others to report the quota for a mailbox.  And some might even do both, but for an entire domain, server, etc.  I wanted one that I could use to list a single mailbox’s current size and where it falls within its quota.

This script allows you to find a user based on login name (samAccountName) or email address.  If multiple matches are found it will report on all of them.  It uses WMI to query Exchange for the mailbox’s current size and then uses LDAP to determine the quota.  Since there are multiple places a quota can be set (system policy, server, mailbox), the script factors those in and backtracks to the resulting quota in effect.

The results are output to the screen and to a popup window.  And since it is nice to know, it also will display if default or custom limits are in use.  This script is nice because you don’t have to customize anything.  Just download\copy it and run it.

Like a lot of my scripts, they start from the hard work that someone else has done.  This one began as a similar script that Glen Scales wrote and posted over on his blog.  His version enumerates the servers/stores in a domain and outputs the results to the screen.

My needs required some tweaking since I have servers in multiple domains, and I wanted it to email the results to multiple people who are responsible for backups.  I also needed to account for servers that don”t have public and/or private stores (e.g., front-end servers, conferencing servers).  The script will email the report in HTML format, grouping the stores alphabetically by server name.  Change the constants at the top to suit your needs and then schedule it to run daily.  My next step is to note stores that haven”t been backed up in X days (perhaps two or three) and highlight them in red so it is easy to spot those stores (since my report currently has 60+ stores in it).  Until then, download this version here, or copy it below.

Over on Michael Smith’s blog, he has a script to notify users when their password is about to expire.  This is handy for Exchange users who never log in to the network because they are offsite or on an extranet (i.e., POP3/IMAP4/RPC-HTTP users).  It will crawl an OU and check the days until expiration and, if less than a variable you set, send an email via CDO.

However, at my office we don’t have these kinds of users in one OU.  They are spread across multiple domains, but are all in a local group that has permission to a web page that allows them to change their password.  So I updated the script to enumerate the members of this group.  To accommodate different password aging settings in each domain I moved the domain query for this setting into the For loop.  I also added logging so you will have a record of what was sent, not sent, and why.  This way you can schedule it or run it interactively without having to adjust the code.  Download it here, or copy below.

When a user adds someone as a delegate of his/her mailbox and selects the option to have meeting requests go to the delegate, a hidden rule is created in the Inbox of the delegator. When you remove the delegate from the list the rule is deleted. But if the delegate isn’t removed before the delegee’s mailbox is deleted (presumably due to termination), the rule isn’t deleted. The delegate is removed from the Delegates tab so you can’t remove the rule, effectively orphaning the rule. Because the rule still exists, meeting requests will still be sent to the delegate. Since the mailbox doesn’t exist anymore, the meeting requestor will receive an NDR from a person they didn’t even invite to the meeting.

Microsoft’s solution is to use MDBView and go through the hidden items in the inbox until you find the corresponding rule and manually delete it. You can also use the better tool, MFCMapi, to do it. I wanted a better way to do it, and one that admins who don’t delve into raw MAPI viewers could use. So I wrote this WebDAV script that queries the target mailbox for the hidden items in the inbox, displays them in a table, and allows you No. to delete the message from the results window.

The delegate rule’s Rule Provider Content value is “Schedule+ EMS Interface.” If the delegator has multiple delegates who receive meeting requests (not that common) you won’t see multiple rules. There is only one rule, regardless of the number of recipients. If you don’t see an item with the Rule Provider Content Value above, then the user doesn’t have any delegates who receive meeting requests.

The script uses Exchange 2003 SP1’s ability to use the SMTP address in the URL, negating the need for a virtual directory for each SMTP namespace in your org. So you need SP1 for this to function. Just change the values near the top for the protocol and server name of your front-end or back-end server. I wrapped the script in a web page so it can be hosted on an IIS server and then you can just browse to it from anywhere. Note that it is not a server-side script. The code will be executed by the client and will prompt for credentials. Putting it in a web page is just a convenience. Just copy and paste it into a file, or download it here.