Archive for October, 2012

Version 2.1 of WizBang Exchange Message Tracker

October 18, 2012 24 comments

Version 2.1 of WizBang Exchange Message Tracker is now available.

Bug Fixes:

  • Fixed bug where hours on graph were sometimes wrong
  • Fixed bug where messages with multiple recipients were counted in sent totals for each recipient. Each unique sent message is now counted a maximum of once in internal sent total and once in external sent total.
  • Added code to check for null values in $unkey, $sndarray, and $recparray before attempting to add to collection

New Functionality:

  • Added export to html button on dashboard

Please see this post for details on the WizBang Exchange Message Tracker.

You can download the latest version here (change extension to .ps1).


Properly Terminating User Access

October 6, 2012 8 comments

Security is a big part of any IT professional’s job. Employee turnover is inevitable in any organization and when employee and organization part way, it is not always amicable. For this reason, it is important that when an employee is terminated, they immediately lose access to all company systems. If you ask most IT professionals what they do when HR notifies them that an employee has been terminated, you will get answers like:

  • Change user’s passwords
  • Disable user’s accounts
  • Issue wipe command to mobile devices

Those are certainly good security practices but imagine performing those steps then getting an angry call from the VP of Sales that the Account Manager who just left the company for a position with the competition is sending emails to clients, from their company email account, informing the clients that he now works for company X, which has a superior product.

Your immediate reaction is that this isn’t possible as you have disabled the accounts and changed the passwords. You check Exchange message tracking and verify the emails are indeed coming from the terminated account. What you don’t realize is that disabling an account or changing the password will prevent a new authentication session but it will not affect a current session. In this case, the terminated employee could be logged to the mailbox with a mobile device that hasn’t been wiped, an OWA session, or an Outlook Anywhere session from a personal computer. Those sessions will remain active until they time out, which could be hours or days.

You could perform a IIS reset on your Exchange CAS server, which will reset the connection, but that could be disruptive to other users as their sessions will also be reset. A better way to ensure the terminated employee’s sessions are disconnected is to set the logon hours on the AD account to never. As soon as the current time falls outside the allowed logon hours on an AD account, any active sessions are immediately terminated.

To set the logon hours to never, open the user account in ADUC and go to the Account tab, then click the Logon Hours button.


In the Logon Hours window, click the Logon Denied button.


Ensure the whole grid is white then click OK. Once this change replicates throughout your directory, any active sessions this users has will be terminated.

If you would prefer to set the logon hours to never with powershell, you can run the following command, which requires the Quest AD cmdlets:

Get-QADUser user | Set-QADUser -ObjectAttributes @{logonhours=[byte[]](,0*21)}

The credit for this command is this discussion on the powergui forum.

If you set the logon hours to never as part of your termination process, you will ensure you never get into a situation where a terminated employee continues to have access to resources.