Keeping track of the exceptions in Exchange

Filed in Microsoft Exchange 2010, Microsoft Exchange 2013, PowerShell, SecurityTags: , , ,
Share this solution!

If your organization is anything like mine, they like to have up to the minute information on who has access to what and why. If your organization isn’t like mine, what’s wrong with it? (I’m kidding, of course. Every organization has different security needs.)

I make use of many of Exchange’s features to keep the system manageable. For example, my default mailbox size is 2GB. That’s enormous by last decades standards, but some users can eat that up pretty quickly depending on how they use email. I have some users who deal with natural disaster management and recovery issues–as in wildfires, floods, tornadoes, etc.–and their mailboxes can fill up quickly at some very inopportune moments. This means we have to be flexible and allow for higher mailbox quotas for higher bandwidth and higher profile users. Unfortunately, over time it can become difficult to keep track of who has what exemptions and why. I manage this problem in three ways:

  1. Policy-exemption authorizations are stored in a central location so I can refer back to the original request if necessary.
  2. A scheduled task generates a report of key mailbox properties and emails it to me once per month.
  3. I use Exchange’s CustomAttribute fields as a quick reference for why and when a particular user was exempted from a policy.

I love automated reports. They save a lot of time. Unfortunately, they can still contain a lot of data that can be tedious to sift through. When I first set up this report, I would spend the better part of one day each month verifying each anomaly with the authorized exemptions. That’s why I started using the CustomAttributes. I map attributes to exemptions like this:

Property Name Exemption Type Sample Data
CustomAttribute1 Mailbox Quota 5GB;10/3/2011
CustomAttribute2 Archive Quota 10GB;10/3/2011
CustomAttribute3 Recipient Limit 10000;12/24/2012

 

When a particular user is authorized to send to more than the default number of recipients, I file the exemption and add a note to CustomAttribute3 for that user. You can do that using the EMC or a PowerShell command, whichever is easier for you. Here’s the PowerShell command I would use to set the Recipient Limit for jay.test to 1000:

Set-Mailbox jay.test -RecipientLimits 1000 -CustomAttribute3 “1000;4/17/2013″

When I receive the monthly mailbox report, I don’t have to look up the specific exemption for jay.test to make sure it’s set correctly. (I can do that annually or semi-annually if I’m paranoid about someone changing those custom attribute fields when I’m not looking.) In my report, I made sure that CustomAttribute3 appears right next to RecipientLimits so I can immediately see that I authorized jay.test to send to 10000 recipients at a time on April 17, 2013.

It seems very simple–and it is–but it really saves me a lot of time. It’s important to eliminate as much of the tedium as possible from your work. Unless you love audits, bookkeeping, and stare-and-compares, you should consider making use of custom attributes as a quick-and-dirty auditing method.

 
Click to view/hide

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Powered by sweet Captcha

 
Click to view/hide