Voicemail Retention in Exchange UM

Every Exchange admin freaks out at least a little bit when you start talking about storing voicemails in Exchange, except for maybe the handful that are blessed with unlimited storage.

Most users are pretty bad about managing their mailboxes unless you have implemented storage quotas on their mailboxes. I've seen mailboxes with email going back years. Even though the actual storage requirements for a single voicemail is pretty low (especially compared to large pdf's, spreadsheets, Word docs, etc) it does add up over time.

Older systems typically performed automatic cleanup of old voicemails, usually after 14 or 30 days. Since this is not a default behavior of Exchange, Microsoft has introduced a retention tag specifically for voicemail. This is only available through PowerShell, not through the Console.

Using the New-RetentionPolicyTag command, you can specify the Voicemail Message Class (this is the only class you can specify, all other tags use All). You can then specify an action to be applied after the retention age limit has expired. You will probably want to specify an action like PermanentlyDelete or DeleteAndAllowRecovery.

To create the new retention tag, your command will look like:

New-RetentionPolicyTag -Name “Delete Voicemail after 30 days” -Type All -MessageClass Voicemail -AgeLimitForRetention 30 -RetentionAction PermanentlyDelete

You will then need to create a new retention policy (New-RetentionPolicy) or assign this tag to an existing policy (Set-RetentionPolicy). After you have a policy it needs to be assigned to mailboxes using Set-Mailbox -RetentionPolicy. To assign it to a database, you will need a command like

Get-Mailbox -Database "DB01" | Set-Mailbox -RetentionPolicy "Delete Voicemail after 30 days"

~ brad

Fun Fact:
Douglas Englebart, the inventor of the mouse, has never seen a dime from the patent. That’s because his patent expired just before the device became widely used with almost every computer. But he’s not cursing his luck – Englebart has had a hand in a multitude of other inventions, including hypertext.

Managing Users with Default Policies

User Management is always fun. The longer you have Lync installed, the more policies seem to build up and overlap. Frequently I will pull and manage users based on the policies that they have assigned. This can be done through the Console, but it does get slow the more users you are trying to manage.

While I do have all of my Global policies configured, I prefer to keep specific policies assigned for the major policies. Like I mentioned above this can be slow and tricky in the Console. Finding users who already have a policy assigned is pretty easy using a command like:

Get-CsUser -filter {ConferencingPolicy -eq "Lync-Conferencing-Gold"}

This will pull up all the users with the specified policy name, and can easily be piped to another command such as Grant-CsMobilityPolicy.

Finding the users that are inheriting the default Global policy is a little trickier. Running the command

Get-CsUser -filter {ConferencingPolicy -eq "Default"}

will give you the following error.
   "Get-CsUser : Cannot bind parameter 'Filter' to the target. Exception setting "Filter": "Policy "Default" is not a user policy. You can assign only a user policy to a specific user."

In order to find all the users with the default policy assigned you will need to use a command like:

Get-CsUser -filter {ConferencingPolicy -eq $Null}

~brad

Fun Fact:
In a short period of ten years Van Gogh made approximately 900 paintings.

Persistent Chat Settings Disappear

One of the best new features in Lync 2013 is the built-in Persistent Chat role. This is a new role for me and lately we have been piloting the feature in my environment. Everything is working great, but a couple of my pilot users complained about the notification settings in the client not being retained. After some testing, I found that the 2013 client would hold the settings on a simple log out, log in; but if you did a full restart of the client or rebooted the machine that settings would revert back to default of no notifications.

Doing some research, I didn't find much. These settings don't appear to be stored in the registry as the values don't change when settings are changed.

The Persistent Chat policy in Lync is very basic, basically one setting to turn persistent chat on or off for the user base. By default a Global policy is created when you enable Persistent Chat in the topology. Like most Global Policies that are assigned by default, when you look at a user in PowerShell the field shows up blank.

Global automatic policies are a great idea, but in this case appears to only partway work. It does enable users to use Persistent Chat but doesn't save their settings related to it.

As a workaround, I created a new pool policy for the pool my account is in. A few minutes later I was able to exit the client and relaunch it, and my settings remained.

The Technet article for New-CsPersistentChatPolicy doesn't mention a pool policy, but it is available through the Control Panel.

~brad

“What we now want is closer contact and better understanding between individuals and communities all over the earth, and the elimination of egoism and pride which is always prone to plunge the world into primeval barbarism and strife... Peace can only come as a natural consequence of universal enlightenment...” 
~ Nikola Tesla