I had occasion to download the latest cucimoc version today, but cisco have recently revamped their entire site. I cheerfully put cucimoc into their search engine under product downloads, as I have done many times before… no results found. Then followed 5 minutes of putting every permutation of Cisco Unified I could think of. Again no results.
This is daft, I always found the download this way. I started going through the menu’s under Download Software, this took near on 30 mins of going down each avenue, only to not find it! Eventually I find it. So to save you all the incredulous searching here’s where it is! Cisco Unified Communications for Microsoft Office Communicator download
Here’s a pic to illustrate the menu layer
Hope it saves you a few minutess, oh and Cisco, fix that search engine, it’s pointless!
Cucimoc 7.1.x was and is a decent product for the feature set it offers, but as of the beginning of June 2010, Cisco have released Cucimoc 8.0(1).
There are some significant differences between the 2 products.
- Cucimoc 8 no longer uses the TabUrl area to display the applet/pane, instead it ‘bolts’ itself to the bottom of the screen, like this: Excellent improvement.
- TabUrl can now be set to a unc file share or URL to a centrally held config (strictly speaking you could do this in 7, but cucimoc had to be part of it)
- Conversation History now displays a an alert for missed calls, with the number of them missed.
- The options for device selection move from the OCS Tools menu, to the options button on the cucimoc pane itself, much better and quicker to get to.
- You can now connect to MeetingPlace or Cisco Unified MeetingPlace Server -CUMS (though Meetingplace Express won’t work for me, the notes show Cisco Unified MeetingPlace Express VT 2.0 is supported) from within cucimoc.
- Place and receive video calls, with greater video support not only from the front pane, with ability to answer as video or voice only from the prompt.
- You can also connect through to Voicemail and Visual Voicemail, this is essentially done using IMAP.
- The park feature which I had some trouble with in 7, works perfectly in 8.
Windows 7 support is there for 32 bit, but there is still a Q2/2011 being suggested on some Cisco documents for full 64 bit support. However, the release notes suggest support for 64 bit already being there with the exception stating [On 64-bit editions of Windows 7, you cannot use video when you have Cisco UC Integration for Microsoft Office Communicator set to use your desk phone for phone calls.] (pg8 Table6)
That said, I have it working on 64 bit, on both version 7.1.x and 8.0, but drag and drop calling would not initially work on 7.1.x. This seems common based on the technet msg boards having similar questions. We have got it working however by installing both the x86 and x64 C++ 2008 redistributable packages. I will continue to work on this, as it’s a little messy. In addition to this, more testing shows that on 64 bit versions it’s best to install using the .exe rather than the .msi as it has C++ and .Net as bundled stubs.
The release notes can be found here:
The Installation Guide can be found here:
Annoyances? Well, maybe just 1 or 2 :) . If you use extension mobility (EM) and login to an alternate deskphone you get an alert message saying you have selected an unknown device. This happens in either version 7.1.x and 8.0. You get a handy little instruction to go the the Communicator menu, Tools ->Select device. However in version 8, they have moved the ‘select device’ to the options tab on the cuci pane, it’s just that the alert message still says the exact same thing… a little QA missing.
It can also be a little sluggish on low bandwidth/dsl links (phone call pop; login etc)
Finally, on a few XPSP3 installs I see this when I use alt-tab to flick between apps. Again, poor QA.
Lastly, the voicemail feature, it changes your voicemail icon to be red when you have voicemail, nice, but, it is slow to react, and doesn’t extinguish until there is a state change (i.e hard phone to softphone switch etc)
All that said, I like it, just want to tweak a few more bits.
I have spent the best part of 3 weeks wrestling with CUCIMOC. It’s fair to say I haven’t been the biggest supporter of this particular piece of software during this time. I respect the feature set, but I can dial a colleague with almost as few clicks on the handset as easily as I can through cucimoc, and the same goes for creating conference calls etc.
One document I would say is prescribed reading is this article. It holds loads of information, but imho is not very clear about valuable points.
Out of the box, getting the integration with CM7 was quite simple, we put the necessary framework devices in place, logged into CUCIMOC with telephonenumber and ‘pin’. All good, or so we thought….
Then we went through the process of integration the CUCM7 servers with AD, opting to use telephonenumber as the primary login mechanism for handsets (who wants to tap out first.last on their 7960 when they use extension mobility!!)
Straight after that, the CTI control of the hard phone (7940/7960) instantly broke. The softphone option would work on occasion, but we simple couldn’t get the hard phone to work again.
A long week of trying various things in our test lab it all came down to the selection of login choice, pin number and password. We are currently CUCM4.x users and in that environment we use pin and password interchangeably, but in CM7 with ldap/AD integration, they become 2 separate items, your pin logs you into a hard phone device and your password is integral to anything you sign into under software emulation of phone devices.
Armed with this in our heads, we went back through our CUCM7 (with AD integration) config, placed all the framework services into the system, then logged into CUCIMOC with telephone number, and password. Hooray RCC/CTI works!
So, that working reliably and predictably, we moved onto the final section of getting ldap to work from the client for CSF data. The CSF data comes into play when someone rings you who isn’t in your Outlook contacts, isn’t a MOC user, but is held in your directory. CSF facilitates that you get a name to reflect against an incoming phone number. This is done via your client talking ldap to AD to retrieve a name for the phone extension. I have done several attempts at getting this to work, but each time I ended up with a disconnected session in the ‘server status’ section of CUCIMOC.
I used wireshark to sniff this conversation, and saw I was getting: W80090308: LdapErr: DSID-0C090334, comment: AcceptSecurityContext error, data 52e, vece.
Several Googles later I was left confused, was this indeed a context auth error, a password error or an invalid Kerberos token. I went over the wireshark packet trace again and noted that although my username etc was parsing correctly, the password had ’123456′ in clear text. This is the pin i was using in the test lab! So here it was passing correct AD creds with pin number. I changed the login field to use telephone number etc and got variants of these pair of pin/password/extension no/sAMAccount. Never the combo I needed!
I kept putting ldap://<ldapservername> into a browser and would get an error like this:
I then went over the sample data offered with the CUCIMOC client (cucimoc-Admin-ffr.7-1-3.zip) and in particular the file held in ..\Config\SampleCUCIMOC-CUCSFAdminData.bat file.
This clearly defines what entries you will need for stand alone or ADM configured machines via policy. Not only this, but it provides a means (via the batch file) for deploying these settings in basic login scripts etc.
I studied these values, comparing them over and over again with my own, held in my HKCU registry. I could see nothing that helped me, but I keenly tried any variant I could think of. One key kept jumping out at me though, as something I would need to give careful consideration, namely: POLICY_CREDENTIALS_IsLdapSynchronizedWithCucm. Now I’d always assumed that as we had integated CUCM integrated into AD, I would have to have that set to true, and so I did. Again, rebooting between each change to be sure they were taking effect, I was unsuccessful.
So I went back to wireshark/thinking/reading and discussing. A chance conversation with our CUCM Admin, got me closer to the pin vs password conundrum I highlighted above. they are 2 different things in CUCM7 integrated to AD. I was used to CUCM4.
I went back to CUCIMOC and logged it in correctly, with my phone extension as the username and my AD password as the password. Hoorah, MOC logs in, phone control works for CTI and softphone, but… ldap is still disconnected.
I started to read the documentation again, thinking about pins/passwords/samaccountname/userprinciplename/telephone number etc. I then re-read this article which made me start to think about the POLICY_CREDENTIALS_IsLdapSynchronizedWithCucm string value. What if I changed that, that would allow me to specify ldap creds surely.
Changing this to ‘false’ then provides exactly the change highlighted in the document, specify samaccountname and password and bingo.. ldap working at last!
Something I was struggling to find during this little process, was a WORKING example of the registry settings, so hopefully to save you some pain, here are mine.
Why isn’t this documented more clearly, if you make the seemingly inane choice to use telephonenumber as your login mechanism of choice whilst integrating CUCM with AD, you set in place your inability to get ldap to auth properly without having to specify a username and password seperately for client ldap, and you HAVE to set POLICY_CREDENTIALS_IsLdapSynchronizedWithCucm=”false”
Hurrah it works! I’ll not get those tedious hours of my life back though….