Exchange: shared calendars?

[Cerulean]

Greetings,

I am trying to figure out how to create a shared calendar and to access it. On a basic level, it's easy and I am able to do it, but consider this scenario:

I have stuff in my Exchange calendar which is not shared (meant to be private). I create another calendar and I share it with my test user. My test user accepts the invitation to the shared calendar, but mistakenly removes it from their Outlook and has also deleted the invitation e-mail they received. According to the permissions of the shared calendar, they still have permissions to do stuff on it. But when my test user adds my name from Active Directory using the "Add Calendar --> From Address Book" context menu option, it doesn't present them with any choices of which calendar to add -- it adds my Exchange calendar and shows all my entries but replaces all my entries with a text that reads "Busy".

Let's assume that I'm gone. In fact, I get terminated. What happens to the calendar that >I< created and shared? Unlike a shared mailbox, doesn't my calendar stop working too?

Basically, in my real situation, I am needing to setup a shared travel calendar operated by the secretary in the Executive department that will be read and accessed by personnel from all over the company. Should the secretary retire, it would be messy to deal with transitioning the calendar / deactivation of user account. Is it not possible to have a "Shared Calendar" on the same level as "Shared Mailbox" (accountless / owned by the system)?

 

[slunge]

what level of AD are you using / version of exchange?

in exchange 2003 - easiest way would have been to use public folders (we still use them here to a certain extent as i transitioned on to exchange 2007 and they moved as part of the transition, now retired the old exchange).

I think in ex 2007/2010 - its a case of using specific mailbox type, for example we now use room mailboxes here which are essentially mailboxes with calendars, with the mail side disabled. you can then delegate access to this calendar, and its irrelevant if anyone leaves, the room/shared mailbox etc remains.

 

[Cerulean]

Exchange 2013

I will try the room calendars -- I saw that and was thinking that it would be possible to use that despite its name.

 

[Cerulean]

OK, so I've found a downside or two to using Rooms:

You cannot keep the data of Rooms private and unreadable. You can hide it from the address book, but doing so prevents anyone (including people on the delegates list for that Resource) from being able to add the Room Resource. With a shared calendar, you can accomplish this by setting the permissions for Anonymous; a Room Resource on the other hand does not have a security permissions tab.

Problem is, a shared calendar is tied to an account. I observe that if I disable the owner account the calendar can still be accessed by those who have it. However, permissions cannot be seen and if the calendar has been renamed and no one knows you have to use PowerShell (probably) to figure out which AD account the calendar is actually linked to. If users who have access to the shared calendar do not have the "Owner" level of permissions, they cannot see or read permissions on the calendar in the Summary tab. If a user has the "Owner" level of permissions, they can see and modify the permissions, but they can also remove their own "Owner" level and lose their authority.

With a shared mailbox, the scenario can be accomplished to criteria without the cons of these. I would create a shared mailbox and hide it from the address book; give the secretary in the Executive department full access to the shared mailbox; create a calendar, rename it as "Travel Calendar", and share it out and set permissions. This would allow for the calendar to be completely hidden, administration easy (worst case scenario technician just needs to give a user full access to shared mailbox, no PowerShell necessary), fully customizable permissions on the shared calendar, and calendar hidden from public.

The reason Rooms as a Resource would not work for this scenario is that it can be viewed publicly. If you hide it, then no one can add it. That is primarily the reason why I chose a shared mailbox over rooms for this scenario; the Corporate travel calendar does not need to be seen by anyone except those that need to see it. One difference between Rooms and shared calendars is that you can fully customize the permissions on a shared calendar but you can't with a Room resource. In addition, though very minor, there are many options that are missing from Rooms that calendars (whether shared or not) have that might be handy, although admittedly for my particular scenario that is irrelevant.

 

[Cerulean]

Where would you draw the line between SharePoint and shared calendars (via shared mailboxes)?

I ask because now I'm coming up with a naming convention for things such as..

rm-location-nameOfroom
(Room Resource)

eqp-type-#
(Equipment Resource)

cal-department
cal-location-department
cal-company
(Shared Calendar via Shared Mailbox delegated to an operator)

When I got to cal-company it really made me think about this because ... imagine trying to share out a calendar to 'everyone' X_X i don't think this is the right way to do it and obviously SharePoint would be better for this. Or is it possible to share a calendar en masse by force? donno, but thinking about it even if you wanted to have a calendar for a whole department SharePoint is really the more appropriate thing. I wonder if the Executive Travel Calendar is something that would be more appropriate in SharePoint as well . . .

could anyone confirm my thinking?

 

[jpochedl]

I'm not sure there's any hard or fast rule that can be applied to choose between a shared mailbox or a Sharepoint Calender in the scenario you've laid out... I think it will just depend on where you and your users are most comfortable. If your users are very "Outlook centric" then the shared mailbox might be the simplest option... If your users are comfortable with Sharepoint, that it probably going to be the more flexible option over the long term...