Active Directory Products
Calls To Calendar
SMS To CSV
SMS To Gmail
Voicemail To Gmail
How Long For Me
<< Back To All Blogs
OCS 2007 Not Able To Communicate with Phone Switch or Make Calls
Monday, August 6th, 2012
We recently encountered an interesting issue with OCS 2007 in which OCS was enabled with Remote Call Control (RCC) and was working for some users, but not working for others.
When logging in and trying to call users integrated through OCS, our "broken" users would receive the error message "Cannot connect to the phone system".
We are running OCS 2007 R2 and our phone system is integrated through an Avaya 8800 AES server through a direct connection (with no sip gateway in between).
Our first thought was this was a phone system issue, which after troubleshooting and testing the issues directly on our AES server, call paths were working fine as were test calls to external and internal numbers.
Where we started to realize where our issue was coming from is when we opened ldp and ran a generic query for (&(objectClass=user)(msRTCSIP-Line=*)) under the AES service account. The msTRCSIP-Line attribute is where OCS stores tel objects in active directory when enabling users for OCS. A typical entry would look like tel:+15557778888. What we noticed is that it was only returning a subset of users, and the majority were in a specific OU in active directory.
Enter Active Directory permissions nightmare...
At this point we needed to do some very granular permissions checks for the service account.
I used a tool I wrote to export active directory permissions (both inherited as well as explicit) on both a working object and a failing object. You can also use PowerShell or a program of your choosing, but they need to be exported into a text file that can be easily compared.
Fire up WinDiff and compare the two files.
In our case the OU in question that was working had an explicit permission for the object and all descendants to have read on all properties.
The other 3 OUs which were problematic did not have the same explicit permission, and our default container permission was to deny reading of properties to all objects.
The reason some of our users in those groups were working is they had specific permissions given in the past.
Long story short: We had broken inheritance on our AD permissions structure which caused this issue. Our service account was not able to read the permissions, which meant that when users were trying to initiate calls in OCS directly it was failing as their account didn't have permissions to read the properties of active directory users.
Hopefully this will help someone out as it took us a while to figure out.
OCSin' Tom Out.
Blocking A Specific Number from Calling Company Extensions in Avaya CM
Resolving Avaya Denial Event 2378
Currently no comments.
Add A Comment
Email Address: (not public, used to send notifications on further comments)
Enter the text above, except for the 1st and last character: