I use two separate Google calendars: one for Bredemarket, and one for personal non-Bredemarket meetings. I receive meeting invitations on both of these calendars. This usually isn’t a problem.
Over the last year, I have accepted a variety of calendar invites from external inviters, including invites to Zoom meetings, invites to Microsoft Teams meetings, invites to Google Meet meetings, and even old-fashioned invites for Plain Old Telephone Service (POTS) calls. (Yes, these still exist.) These have originated from Google-managed domains, Microsoft-managed domains, and other domains.
When you accept a calendar invite, you send a message to the inviter that contains your acceptance of the message, and this acceptance is recorded both on your calendar and on the inviter’s calendar.
Except for the invite that I received yesterday evening.
I was reading email on my mobile phone and received a calendar invite. When Gmail displays calendar invites, it displays them with “Yes,” “Maybe,” and “No” buttons.
So I clicked “Yes” on the invite…and received a message that I didn’t have permission to access to the target calendar.
That seemed odd, but I noticed that there was an “invite.ics” file attached to the invitation. While ics files are designed for Microsoft calendars, they can be imported into Google calendars, so I figured that I’d just import the invite.ics file when I had access to my computer the following morning.
So this morning I imported the invite.ics file…and got the same error stating that I didn’t have permission to access the target calendar.
Curious, I researched and found a solution:
“The solution for this is to manually edit the .ics file prior to importing it and replace all occurrences of “UID:” with “UID:X” (without the quotes). After doing this and saving the file, proceed with the import and all should be fine.”
So I opened up the invite.ics file in Notepad, performed the manual edit, and successfully imported the calendar entry.
As it turns out, the inviter doesn’t usually schedule meetings with people outside of the inviter’s domain, which explains why I was the first person to mention the issue.
While the problem was solved, I had no idea WHY the UID:X trick worked. And I’m not the only one asking this question.
Most of the time when I receive a meeting request in my gmail account, Google Calendar understands exactly what is going on and handles the request pleasantly.
But for some zoom meeting requests originating from one particular client, Google Calendar refuses to admit that it’s a meeting request until I edit the ICS file and insert an “X” after the “UID:” prefix per the suggestion here.
Looking at RFC 5545, it doesn’t look like the “X” is required but it’s not terribly clear.
Does RFC 5545 in any way require that “X” to be there?
As of this morning, no one has answered the question, but I found a comment in a separate thread that appeared to be relevant.
After investigating for a while, it seems adding the “X” is not a permanent solution. The
UIDis a global identifier, if two events have the same
UIDin the same calendar there’s a collision. Some calendar services like Outlook (which I use) seem to handle this, while Google and probably many others don’t.
So the mystery continues.
P.S. If you happen across this post and find it helpful, also see my 2009 tip about the spurious “remove probe” error for KitchenAid ovens. (TL;DR: use a blow dryer to remove moisture from the probe hole where the temperature probe is inserted.)