Hi, Please help me to resolve this issue…When Auser send a meeting invitation to Buser at 4pm, and Buser also accepted that.
But on the sametime if another user C schedule a meeting with D user also at same time 4Pm. its accepted by server.
Please help me how to reject the romm reservation when its already booked by another user…
Regards
Dinesh
Subject: Are you booking an online meeting through Notes?
Hi, It isn’t clear to me the exact steps you are taking but I thought I would mention that if you are booking an online meeting through Notes, the Sametime piece to the meeting should always be accepted even if meetings are occurring at the same time since the room is virtual.
Subject: Meeting Invitation
This meeting is not related to Sametime. This is normal meeting from notes client.I explained here again-
Assume there are 4 users(A,B,C,D).
If A user scheduled a meeting invitation to B user at 10AM at meeting room 1. B user also accepted that- so meeting was confirmed.
Next - When C user schedule a meeting with D user at same day at 10AM on same meeting room 1.
Meeting room should declined to schedule meeting at same time on that room.
But in my case its accepts.
pLease help me how to reject the booking a meeting on sametime on sameroom.
Subject: Clustered R&R?
There are a couple possibilities for how your room got double booked. So I will cover them all and you can see which best fits your case:
1: Your R&R server is clustered, possibly over a WAN. If the Domino cluster gets ‘split’ with both servers still up then both servers will think the other went down and both servers will try to process requests as they arrive. If requests get delivered to the different servers that conflict then it is possible that Server1 will accept a request that conflicts with something booked on Server2 which Server1 does not know about.
If you have the Accept notices for UserA and UserC then you can check the RouteServers values or the $CSTrack items to see where the responses were created. For this case you would see Server1 listed on one notes items and Server2 listed in the others.
You can use the tell rnrmgr whoowns YOUR_RnR_DB_NAME_GOES_HERE.nsf console command on both servers to see which servers think they are in control. In cases like this you will get Server 1 saying it owns the dB while Server 2 says it does. Fixing this is pretty straight forward: restart the RnRMgr task of the server that should NOT be in control (e.g. the one with the OLDEST timestamp). This does not resolve the double bookings but it will stop future ones.
We do not really recommend you cluster across a WAN due to the high latency involved and the increased risk of getting a ‘split cluster’. If you have done this then I recommend you read the TechNote we have on WAN clustering and what to keep an eye on. (Sorry, I dont have the # handy; I am on vacation and not at my desk).
L2 has a tool which can help you find double bookings that were created so you can notify the affected users and let them resolve the conflict (or you can act on them manually if you are the dB Admin).
2: There is a problem in the busytime dB on the server: you have multiple records for the same room or you have replication conflicts.
The multiple record case is a rare and very intermittent one. In this case NSF has forgotten about the existing busytime record and so when RnRMgr asks NSF to return the current record so it can add a new reservation to it, it fails to return the existing doc. So RnRMgr assumes that this is the first request for the room and tells NSF to create a new record and put the new reservation on it. This means that all other prior bookings for the room get ‘forgotten’. If this is what you see in the busytime dB then you will need to follow the published TechNote on rebuilding busytime (sorry, I dont have that # handy) If you see this happening a lot then please consider opening a ticket with Support so we can work with you to try and gather some data about what may be causing it.
The replication conflicts case is a relatively new issue for busytime. The root cause is not clear. If you see this then please consider opening a ticket with Support so we can investigate it with you. As with the multiple doc case, the resolution is to rebuild the busytime dB.
As I mentioned earlier, you can contact Support to get a tool which will help you find any duplicate bookings in your R&R dB so that you can notify your users before their meetings happen.
Bruce
IBM
Subject: Forwarding to dev
I’ll get our R&R devs involved to help get your problem straightened out.
BK, MC