Since a long time now I have some customers asking if it’s possible to prevent unrequested presence in OCS R2. In case this is really fresh lot’s of customers are submitting requests to get this work in OCS R2. Not in Wave14 but what are the possibilities right now out of the box? Well that’s a difficult question and after some investigation different options show up.
Question from a customer: How is achieved that mutual acceptance of contacts within OCS2007 R2 is required (like in Skype) if a contact is not a member of the same team in our central user administration database or in another user administration database?
Out of the box OCS R2 is designed to show presence for everyone into your organization. The only thing you have to know is the generated SIP address or a correct replica of your ABS to find the requested user. The strange thing is that when searching for a SIP end-user the presence is shown right away. No request or acceptance at all. Of course a invitation is popped up and gives the end-user the possibility to add the user to a specific Access Level. The main case is that the presence is already shown for this user.
After some investigation there is no easy way to fix this behavior. Of course this behavior sometimes fit perfectly but in some cases it’s not. By working on this issue the last couple of month’s now I really would like to share my outcome.
Possible scenarios:
Scenario (1)
Rip or strip the functional layer of the search functionality in OC. By entering somebody's name the ABS will return the corresponding records (client side the GalContacts.db will be accessed). When you look more closely on the ABS you will find the ABSConfig Tool (Office Communications Server 2007 R2 Resource Kit). On the Configure WMI tab you see that you can partition ABS by OU and create invidual ABS files per OU.
- PartitionOutputByOU Data type: boolean Access type: Read/Write Required. Controls whether data is partitioned by organization unit (OU).The default value is False. This option is really cool and gives the end-user a limited administrative overview of presence for end-users in the same OU. I need to make absolutely clear that this possible solution does not prevent end-user by entering the correct sip address and show the presence. By the end this can maybe a approach.
- Scenario (2)
- Creating a Group Chat virtual room by installing Group Chat Server and get more granular control on which user can access the secured room and who is managing those contacts. Sometimes this additional server role is not an option.
- Scenario (3)
- Create a fixed Exchange DL and manage this DL separately by adding a responsible person for that as manager on the DL. Same as the Group Chat option you get more granular control on who is in the group and who is not. I need to make absolutely clear that this possible solution does not prevent end-user to entering the correct sip address and show the presence.
Global Settings – User. Note that this will only work for user account that are not enabled for enhanced presence. Enhanced Presence is the engine in OCS R2 when you ask it me. So in scenarios this could be a possible solution to restrict that.
Scenario (5)
HMC 4.5 More info on this please review (source). Contact Tenant Isolation. Special thanks to provtest.
As we know, the default OCS deployment is catered for corporate environment. It means by default, all domain users (or all authenticated users) are allowed to search each other without restriction. This is obviously not acceptable in a hosted environment.
Fortunately, OCS uses a property set to determine whether a user is authorized to search other users in the organization using the Find functionality in OCS. The property set is RTCUserSearchPropertySet.
RTCUserSearchPropertySet is composed of a single attribute, msRTCSIP-PrimaryUserAddress
So, in order to ensure that only the authorized users can perform the search, the procedures will have you to remove the Authenticated users from the top so that it will not inherit downwards. And in order to allow authorized users to search that, you will notice that AllUsers@<domain> will be granted permission to that property set on their respective Organization OU.
As you can see this workaround is especially made for hosted OCS environments. We didn’t test it but it could be a solution for your specific environment even when you are not hosting OCS for your internal employees.
So these are the first five scenarios showing up when looking at this topic. As I speak I’m looking for other solutions to get more control on this. Stay tuned! Any feedback or additions please feel free to contact me.
No comments:
Post a Comment