1. Exchange Management Shell (EMS)
2. Outlook Web Access

Option 2 provides a graphical way of accomplishing the task, but if you feel like getting your hands dirty with a little PowerShell go ahead and choose option 1.

1. Extend booking time with EMS
Open Exchange Management Shell
Check the current settings of the resource mailbox by typing the following command:

Get-MailboxCalendarSettings confroom01 |fl

This will list the properties of the resource mailbox:
AutomateProcessing : AutoUpdate
AllowConflicts : False
BookingWindowInDays : 180
MaximumDurationInMinutes : 1440
AllowRecurringMeetings : True
EnforceSchedulingHorizon : True
ScheduleOnlyDuringWorkHours : False
ConflictPercentageAllowed : 0
MaximumConflictInstances : 0
ForwardRequestsToDelegates : True... etc...

As you can see this brings up the properties of the resource mailbox. If you attempt to change the BookingWindowInDays value from its default 180 days it will fail. What controls if this value can be changed is the EnforceSchedulingHorizon vaule. Change it by typing the following command:

Set-MailboxCalendarSettings confroom01 -EnforceSchedulingHorizon false

Now change the BookingWindowInDays value to the wanted number of days as follows:

Set-MailboxCalendarSettings confroom01 -BookingWindowInDays 360

Validate the changes by running the Get-MailboxCalendarSettings command.

2. Extend booking time using OWA
Log on to OWA with an account that has administrative privileges on the resource mailbox.
Click on your user name in the top right corner of the browser window. This will bring up the “Open Other Mailbox” dialogue box.

Enter the name or alias for the Room Mailbox and press ENTER. This will bring up a new OWA window for the Resource Mailbox. Click the Options link and then Resource Settings in the menu on the left.

Click the check box “Automatically process meeting requests and cancellations” and you will have access to all the options where you can set maximum number of days, limit meeting duration etc.

Task at hand
Last friday (090109) I realized that Windows Server 2008 R2 Beta had been made available on MSDN and I couldn’t wait to get my hands on it to try one of the new clustering features - Live Migration. After downloading the ISO I had the task of upgrading the host cluster to Windows Server 2008 R2. Just going ahead upgrading the parent partitions is a no go as the Hyper-V role needs to be removed before upgrading.

Here are the steps I followed to perform the upgrade:

1. I started with shutting the VM down on the current VM owner
2. Backed up the entire VM folder to a network share, just in case things would go horribly wrong
3. Deleted the VM from Services and Applications in Failover Cluster Manager
4. Evicted both cluster hosts from the old cluster
5. Destroyed the old cluster and removed the Failover Clustering feature from the clustered hosts. Make sure no traces of the old cluster remains to avoid issues further down the road
6. Removed the Hyper-V role from both hosts
7. I disconnected the iSCSI disks after deciding to redo the connections post upgrading
8. Started upgrading the 2 hosts to Windows Server 2008 R2 (took me about 2½ hrs)
9. After both hosts were upgraded to R2 I added the Hyper-V role. Since I performed an upgrade I didn’t have to redo the NIC setup, they were still identical on the 2 host servers with correct IP-addresses and everything. I was surprised to find that all my Virtual Network settings in Hyper-V Manager were intact, nice =)
10. Reconnected the 2 iSCSI volumes (Quorum & Shared Storage) to the 2 hosts
11. On one of the host servers I added the VM and installed Integration Services on it
12. Added the Failover Clustering feature on both hosts and ran configuration validation in Failover Cluster Manager (since I had remnants of my old cluster lingering on one of the hosts I got some errors from the validation. I cleaned up and the validation went through)
13. Built a new cluster with the 2 host servers and gave it a new IP and a new cluster name
14. Added a HA VM under Configure Services and Applications and chose my VM from one of the Hyper-V hosts. Done!

Now I had a new HA VM running Windows Server 2008 R2 Failover Clustering and I couldn’t wait to try Live Migration out. I set up a ping to the VM and made the mistake of choosing “Move virtual machine(s) to another node”. I was heart broken when I lost 5 pings while the VM moved over. I went back and this time I chose “Live Migrate this virtual machine to another node”. This time I lost 1 ping to the VM. I was kind of expecting not to lose a single ping after watching Microsoft’s Live Migration demos on YouTube.

I wasn’t too disappointed though as R2 still is in a Beta stage and hopefully Microsoft will perfect Live Migration until R2 goes live in 2010.

Well those are my 50 cents on Live Migration so far…

Regards
Nico