Find and list inactive Exchange mailboxes with powershell

So, I tinkered with this a while back and found the following commands very useful to complete the routine task most system admins have of disabling inactive mailboxes. In this case, I needed to list inactive mailboxes on our Exchange 2007 mailbox servers. Then, I needed commands or tasks to run against this list. Here’s my script:

1.Find mailboxes with no login in over 30 days and output list to a txt file. Edit the path to your mailbox database and path to txt file output:
Get-MailboxStatistics | where {$_.Database -eq “Server1StorageGroup1MailboxDatabase1” -and $_.LastLogonTime -lt (get-date).addDays(-90) -and $_.ObjectClass -eq “Mailbox”} | sort-object lastlogontime | ft DisplayName >C:ExchangeCleanupNoLogin90Days.txt
2.Use “.TrimEnd” to clean up trailing spaces and rewrite the cleaned up txt file:
$list1 = get-content C:ExchangeCleanupNoLogin90Days.txt
$list1 | foreach {$_.TrimEnd()} > C:ExchangeCleanupNoLogin90Days.txt
3.Disable the mailboxes that were in the NoLogin90Days.txt file:
get-content “C:ExchangeCleanupNoLogin90Days.txt” | disable-mailbox

Now, you’re correct that I could just take the output from step 1 and go straight into step 3. HOWEVER, I’d like to be able to review the list of inactive users, and edit the list if needed to avoid disabling any system or service mailboxes that don’t actually have users logging into them.
Another task I use this for is to move the inactive accounts to mailbox servers with more space. I usually run this before step 3 above:
get-content “C:ExchangeCleanupNoLogin90Days.txt” | move-mailbox -targetdatabase “Server2StorageGroup2MailboxDatabase2”

I strongly recommend that you please test these commands in a test environment before running them on your production systems. I’ve tested functionality on Exchange 2007 and 2010, but your environment may differ.
Rick Estrada
Pastebin for reference:

It’s been a while, huh?

Sorry about not posting for a while, but I’ve been tackling projects left and right, trying to shorten the list on my boss’ desk.

So major issue broke out this morning: password changes in Active Directory were failing with error: 
The password does not meet the password policy requirements. Check the minimum password length, password complexity and password history requirements
Even through command line, (net user /domain username password) the error persisted. So I tried the usual, editing default domain policy, allowing/blocking inheritance on Domain Controller’s OU in GPMC, editing domain controller’s policy, the usual stuff you find googling the error. (¬†Nothing worked… until, I noticed the same error in the application event log, over and over:
The description for Event ID ( 5 ) in Source ( WinPSAFilter ) cannot be found. The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer. You may be able to use the /AUXSOURCE= flag to retrieve this description; see Help and Support for details. The following information is part of the event: .
And I didn’t notice that it started at about the same time users began reporting issues changing their passwords. Well, the WinPSAFilter belongs to our SSO product, Computer Associates, CA SSO.
Long story short, this software sucks. I uninstalled the Password Sync Agent from all of our DCs, and that was it. Password changes were now allowed.
Does anyone out there use this product? Have you had problems like this with it?
We were going to use it in a test environment, but have now decided that it just isn’t going to work out.
I have another Cisco tip to post, but I’ll post after work.
Rick Estrada