Your meeting request was declined – Exchange shared calendar’s

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!

 

Communicator cannot synchronize with the corporate address book.

OK I know this is an old subject for an old tech but I was recently on a clients site who had this issue and it gave me a few days of head scratching to get this resolved.

My client was running Exchange 2010 on premise with OCS 2007R2 with end users running Outlook ’10 and the MOCS ’07 client on a mixture of XP and 7.

Symptoms included the old red exclamation mark which when clicked gave the “Cannot synchronize with the corporate address book. This may be because the proxy server setting in your web browser does not allow access to the address book. If the problem persists, contact your system administrator” and Outlook Find a Contact feature being empty or not displaying contacts.

I checked the usual suspects, non existent proxy server, browsing the URL of the OCS from the client IE. Spent a lot of time reading TechNet articles and other peoples blogs but to no avail.

What was interesting is that some clients were experiencing the issue and others weren’t. It made no difference what the OS was, it was just frustratingly random and difficult to replicate consistently, some clients worked others just plainly refused to play ball.

The final piece of the puzzle was when someone happened to mention that they had had a new PKI environment built and that’s when the alarm bells jumped up and slapped me across the face.

Now in my defence I had no prior knowledge of the customer’s infrastructure and I had originally checked the certificates on the OCS server to make sure they hadn’t expired, they did seem to be valid. The client didn’t mention that they were in the process of removing the current CA and implementing PKI otherwise we may have go to the resolution a little quicker.

The issue was caused by CRL (certificate revocation list). Easily identified by checking the OCS server certificate and making sure the CRL path is still valid.

The other way to quickly determine if it is CRL and indeed for a quick fix if you can’t request a new certificate is to edit the registry (disclaimer – Back up your registry first, I cannot be responsible for any corruption that may occur by incorrectly editing your registry)

Edit or create the following key in your registry.

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\

CertificateRevocation

Value = 0

This key just forces the client to ignore the CRL of the certificate, it will NOT force it to ignore expired certificates and I suggest once you have resolved the certificate issue on the server that this reg hack is removed or returned to its former state.

I hope this saves someone some time!