There has been a long-lacking feature in Outlook – the ability to automatically set your Out of Office message to turn on and off on a scheduled basis.

It would be great to be able to have a bounce back on anything sent outside your working hours, but it isn’t easily possible natively unless you use a vbs script inside an Outlook rule – requiring Outlook to actually be running.

I decided to come up with my own solution. This isn’t good for individuals, but is good for centralised mailboxes, say an IT Helpdesk mailbox that you want people to know when someone will look at their request or not.

Step 1 – Set the Out Of Office message you want on your mailbox manually. Outlook, OWA, however you do it, it doesn’t matter. Your message will be saved on the server.

Step 2 – Save the script below as a .ps1, and change the variables to what you want. I have two scripts, one that enables, and the other that disables Out of Office

Step 3 – Create two Scheduled Task on a server. One will be when you want the Out of Office on, and the other when you want it off. Below I’ve created one for the ‘on’ part, which triggers weekly on Monday, Tuesday, Wednesday, Thursday and Friday at 7:30am. The Off would do the same, but at 5pm.

The conditions of the Scheduled Tasks would be to run the powershell script files, again matching up the on and offs. The command to use is “powershell.exe” and the arguments pointing to the location of your newly created ps1 scripts in the format ” -file “C:\scripts\admin\Out Of Office On.ps1″ ”

The task needs to be set to ‘Run whether user it logged on or not’.

The account used to run the task needs to have the correct role based permissions to connect to Exchange, and make changes to the auto reply config.

The script will also generate an email to advise that the status of Out Of Office has been changed, pulling the value afterwards so you can check that it’s toggled correctly.

If the script doesn’t run automatically, you may need to adjust your Execution Policy settings.

That’s it. You should have two scheduled tasks that run to turn Out of Office off and on against the mailbox you want.

PowerShell Script:

#TODO – Definie Mailbox name and state enabled or disabled
$mailbox = “name”
$state = “enabled”
$exchangeserver = “exchange server name”

#Connect To Exchange PowerShell Session
$session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri http://$exchangeserver/Powershell -Authentication Kerberos
Import-PSSession $session
#Turn Out Of Office On
Set-MailboxAutoReplyConfiguration $mailbox -AutoReplyState $state
$results = Get-mailboxautoreplyconfiguration $mailbox |select Autoreplystate

#Emails the current status
send-mailmessage -to “Displayname 1 <[email protected]>” -from “Displayname 2 <[email protected]>” -subject “IT Help OOO Status” -body “The OutOf Office Message is now $results” -SmtpServer smtp.yourserver.com.au

Remove-PSSession -Session $session

Update 15th March 2016

I’ve also realised that Softera Adaxes which I reviewed previously, can do the above quite easily. Here’s how their scheduled tasks work, but simply put you can create a scheduled task to run on weekdays, that sets the Out of Office message and turns it on today, then off today +1 day (i.e. tomorrow), and run that daily to update the date! That’s a more elegant solution, but you need to buy Adaxes or already have it. I’m still using it and recommend it, and decided to do the above this cleaner way. This isn’t a sponsored comment :)

After migrating from Exchange 2007 to 2010 and addressing all immediate issues, we eventually hit a new issue. Managers of Distribution lists who previously could add and remove members, now couldn’t do it!

Changes to the public group membership cannot be saved. You do not have sufficient permission to perform this operation on this object.

So, why would this break going from Exchange 2007 to 2010, and why would there be a delay?

Role Based Access Control (RBAC) was a new feature introduced in Exchange 2010 which changed the way a lot of security worked. There’s a greatly detailed 4 part article from msExchange.org here http://www.msexchange.org/articles-tutorials/exchange-server-2010/management-administration/exchange-2010-role-based-access-control-part1.html which explains this in detail.

As far as the groups are concerned, they stay in a 2007 mode until they get updated. When updated (by something like adding/removing a member) you’ll get prompted about changing the object:

To save changes on object “Silly name”, the object must be upgraded to the current Exchange version. After the upgrade, this object cannot be managed by an earlier version of hte Exchange Management Tools. Do you want to continue to upgrade and save the object?

Once you do this, that particular object (distribution group) now runs under the new RBAC security settings.

By default, the RBAC security settings out of the box don’t allow anyone to be able to add or remove members to distribution groups. The Exchange Team Blog explains this perfectly here: http://blogs.technet.com/b/exchange/archive/2009/11/18/3408844.aspx and also leads onto a script which will probably set things up how you want. If you don’t read this carefully, you may end up applying the built in ‘MyDistributionGroups’ role to the ‘Default Role Assignment Policy’ which means everyone can create distribution groups – definitely not ideal in most environments. I started reading another blog post which said to do exactly that, but didn’t explain why or how it worked. Sure it fixes your immediate issue, but you’re opening up a lot more than what you should.

So it’s a fairly easy fix once you now how, but if you haven’t had to worry about RBAC before there’s a little bit to get your head around first before ticking boxes and hoping for the best.

A big thanks to @ExchangeGoddess and @24x7ITConnect for their assistance and guidance on this information.