This resource can only be scheduled up to 365 days in advance. The end time should fall before dd/mm/yyyy.
This resource can only be scheduled up to 180 days in advance. The end time should fall before dd/mm/yyyy.
I hit an issue the other day with a user trying to create room bookings for the year ahead on calendars within public folders and returns one of the errors above.
Scenario – The user creates from their calendar an appointment which is, lets say 380 days in advance, they then click the invite attendees and selects rooms. They add the room they want to book, complete the details etc. and hits send. Within a few moments the user receives an email from the room booking email address declining the meeting. The message body will look something like the one below.
This is because the booking window set for the mailbox calendar is less than the number of days (from the current date) than the number of days in advance you are trying to create the appointment for.
Under testing the same happens for reoccurring appointments, this is because the Exchange server calculates the 180 or 365 days based on the creation date of the meeting/appointment, and NOT the meeting start date.
Now the interesting thing here is even though the message returned to you says that it was declined, the appointment IS actually scheduled!
Easily resolved by changing the booking window for the calendar in question using cmdlets via the Exchange Management Shell.
Open up the Shell on the Exchange server and run the following cmdlet to determine the booking window for the calendar in question.
get-CalendarProcessing -Identity “MailboxName” | fl
This will return the properties of the mailbox and within the details you will clearly see the number of days of the booking window
As you can see the booking window is 365 days and the meeting in the scenario was 380 days in advance, outside of the booking window set.
This can be changed by setting the booking window to a number of days of your choosing with this cmdlet.
set-CalendarProcessing -Identity “MailboxName” -BookingWindowInDays 381
Run the get cmdlet again to check the booking window and test.
A word of caution here, I wouldn’t go with a booking window too far in advance for numerous reasons such as users leaving, meeting and projects change and even meeting rooms being turned into offices and no longer being there when the time of meeting arrives. Nothing worse than turning up to a meeting room hundreds of miles away to find that the meeting room in question is now a break out room with a ball pit! I guess what I’m getting at is, be sensible with the window you want to create.
Now go off and keep that Exec Secretary or PA happy with your impressive IT skills!
WorldOfCrop 