Thomas' Work Space

1. Symptoms: Students (in the cloud) do not receive an automatic response to their meeting request from the resource mailbox (on-premise). Their booking is not autoaccepted or auto-denied, rather remains tentative on the resource calendar. Students on their own calendar however see it as non-tentative.
2. Solution: maybe mail enabling cloud accounts late September/October?
3. Workaround (for film study students who are the only student that currently seem to book equipment): We, impersonating (“Load other mailbox” in OWA) the resource (the film study camera in high demand), from its calendar,
   1. send accept messages. Students expect accept messages from the documentation. Pointing them to the appointment on their calendar is not fair: it does not show the tentative status the  meeting has on-campus
   2. when student error forces us to: sort out conflicting meeting requests, on a “first come, first serve basis”, by sending denial messages, and include an explanation and  reminder: “Somebody else booked the camera before you. you could have seen this in the scheduling assistant tab of the meeting request. make another meeting request, load all cameras you could use, look at the timelines to find the one which has the resource time not already blocked  (= booked by somebody else already), remove the other cameras, and send. don’t forget to include any secondary resources (tripods, lights) that you can find in the system”.
   3. more online training and more face-to-face training, one-on-one, as hick-ups happen, is being provided, but is not the solution. We need automation..

Students, unlike staff, did not seem to receive automated messages from the resource booking attendant; instead, their meeting requests were put in tentatively in the resource calendar. They all did not understand how to use the scheduling assistant for checking manually for conflicts; this caused a lot of  delays when they came by to pick up equipment, since lrc assistants are not resource mailbox delegates and thus cannot rectify conflicting bookings.

We were hoping that this behavior would be improved with what happended on October 4 (“conversion of legacy mailboxes from exchange 2003”? “Mail-enabling students users in AD”) I did notice a change in the email addresses from student@uncc.edu to student@student.uncc.edu. But the in the handling of meeting requests from students to lrc reousvce mailboxes I have not observed an error (whether I can now share a calendar with a student I have not hacd the time to test yet).

However, I am not also observing new strange behavior for staff sending meeting requests. Staff does still receive messages from the resource booking attendant. However, the resource booking attendant does not seem to see scheduling conflicts for resources anymore. He always accepts. This was not the case when I tested end of august

I can change some (not all) settings without powershell when being signed in as the resource from options / more options / settings / resource:

I removed “allow conflicts” although I read that it refers to some unrelated behavior, but for debugging purposes I turned it off:

I still get no decline auto-responses – Instead I get autoresponse: tentative awaiting approval –

this seems to be to me in contradiction to the setting “automatically process” setting: autoaccept (is the setting still automateprocessing:autoaccept?, not automateprocessing:autoupdate, the former being my request, the latter being the default in exchange? According to the gui, “everyone” çan schedule automatically if the resource is available”it is (= allbookinpolicy as sub-option for automateprocessing:autoaccept)

For further testing, I turned of automateprocessing entirely, and the request remained in the inbox of the resource mailbox (this is not practical)

I turned automateprocessing back on, and the conflicting meeting request with the room resource is still accepted. Unlike for students, who do not seem to receive an calendarprocessing agent message at all, but get their request put in the resource’s calendar as tentative, and as more than tentative in their own calendar,  staff making conflicting requests receives an autoaccept, and the meeting gets put in the resource calendar as not tentative, despite it conflicting there with other meeting requests, like so:

However, when tplagwit sends another conflicting request, he gets a calendar resource attendant response tentative, where the calendar resource attendant is aware and warns against out-of-policy: conflicting prior meetings

To further complicate matters, lrchelp – apparently the exact status of the sender matters, even if no students are involved – gets quite a different response for a conflicting meeting request:

To summarize, these are the current settings for the room resource

And this is how things look like now in the room resource’s calendar :

What we want instead is simple only the first class, “tran” etc, going through, and all latecomers being automatically denied.

Would you know with which settings I  can achieve that?

And then not only for staff, but also for students? 

Here is another round of weird data: Teacher – possibly as a (doctoral) student in some information systems, but received autoresponses as late as yesterday – makes a meeting request to a room for where there are no conflicts.

1. the room is now set to not allow-conflicts and re-enabled-automateprocessing, including allbookinpolicy:
2. result
   1. the request sits in the resource inbox: no auto-response:
   2. the request does not make it to the resource-calendar, not even tentatively – so that others could be forewarned:
   3. but wait, the former holds true only for OWA: An additional complication is the type of client accessing the data: in Outlook, the request shows as tentative in the resource calendar (I thought TentativePendingApproval was an Exchange-server setting that applied to all connecting clients?)
   4. the request does not make it to the delegate inbox – I have to manually browse to the resource inbox and accept to the request:
   5. the response the requester receives will look like this cc: to myself:
3. status February
   1. The original conception to automate responses by the resource mailboxes and rely on messages from the resource boxes to keep the delegates informed  is not implemented. Instead, I load all resource mailboxes (100) in Outlook which first slowed my computer and then the Exchange server down. As a stop gap, my Outlook was disabled from polling upgrades. As far as I can tell, it synchs with the Exchange server now only on restart. This leads to oversights.
   2. AllowConflicts does NOT apply only to the handling of conflicts in recurring meeting requests (allowing recurring meeting instances where they do not conflict with prior meetings, while still not allowing conflicts, i.e. dropping conflicting meeting requests). How to reconcile this fact with this explanation?
   3. Protected: Students still in wrong time zones in live@edu
   4. Protected: live@edu Resource mailboxes not autoaccepting when requested from cloud?
   5. Protected: New resources mailboxes not visible in the GAL for student accounts in live@edu? – Now in sync.