CUCIMOC having Connectivity issues after installation

[IT Dept]

Platform: Win 7x64 client with OCS 2007 R2, connecting to CUCM 7.1.3 with CUCIMOC 8.0.785 client.

After installation it looks like I can log in cleanly with my windows credentials.  However, I do get an error in the Server Status window, as attached.  Not too sure where to go from here, as the Registry settings for HKEY_CURRENT_USER\Software\Cisco Systems, Inc.\Client Services Framework\AdminData are correct as far as I can tell.  Using LDAP servers listed via nslookup, ccmicpserver, ctiserver and tftpserver entries all point to the CUCM and its failover, LDAP_UserLogonDomain is correct as well.

Any ideas?  I've got nothing so far that seems to help after a bit of searching about.

[Jonathan Schulenberg]

This can get a little tricky. Posting a copy of this registry hive would be helpful to get a second pair of eyes on it. A few things to check off the top of my head:

• LDAP_UserLogonDomain should be a FQDN (e.g. domain.local), not a NetBIOS domain.
• LDAP_Server_1 should be a URI (e.g. ldap://server.domain.local:389).
  Be careful about the port here: 389 and 3268 for non-secure while 636 and 3269 are for using SSL. Make sure you get this working non-secure first. The 3268/3269 ports are required if the server is a global catalog.
• LDAP_SearchBaseDN_1: I've fat-fingered this a few times. This should look similar to: OU=People,DC=domain,DC=local. Remember that the default container in Active Directory is actually CN=Users,DC=domain,DC=local.
• ContactService_UseCredentialsFrom should be set to PHONE if you want to use the same credentials that you used to login to CUCIMOC. If you don't do this, you'll need to provide them manually through the settings button.

[IT Dept]

• LDAP_UserLogonDomain should be a FQDN (e.g. domain.local),  not a NetBIOS domain.
• value is %companyname%.com (i.e., domain.local)
  • LDAP_Server_1 should be a URI (e.g.  ldap://server.domain.local:389).
    Be careful about the port here: 389  and 3268 for non-secure while 636 and 3269 are for using SSL. Make sure  you get this working non-secure first. The 3268/3269 ports are required  if the server is a global catalog.
• I've gone without setting up the ports so far, but I'll add them now and test.
  • LDAP_SearchBaseDN_1: I've  fat-fingered this a few times. This should look similar to:  OU=People,DC=domain,DC=local. Remember that the default container in  Active Directory is actually CN=Users,DC=domain,DC=local.
• Admittedly I've avoided confgiuring this entry in the registry, as I didn't think it relevant to simple server connectivity.  It's been set up now, though.
  • ContactService_UseCredentialsFrom  should be set to PHONE if you want to use the same credentials that you  used to login to CUCIMOC. If you don't do this, you'll need to provide  them manually through the settings button.
• I've been logging in manually for now, which seems to be successful so far -- no errors at least.

Result:

So, I've added this data and now I'm starting to get login errors.  Next step is to add the ContactService key and see what I get.

Result: added.  Current error is "A phone initialization error has occurred.  Failed to get configuration."  Going to look at either registry entries to hard-code the login information, or other configuration issues related to the error.  I think it was the port definition in the LDAP_Server_1 entries that got me past the current hurdle.

[IT Dept]

Does anyone have an idea for the new problem?

CUCIMOC loads, but after a manual login (it does cache the ID and password, at least), it gives an error of  "A phone initialization occurred.  Failed to get configuration."  I've got the option to sign in again, but that's about it as far as interface options go.  I've loaded up all the expected registry values I'm aware of, and I know if I change the ID and password it shoots back a failed/bad password error -- so it's authenticating, at least.

Ideas?  I'm not seeing much when I hunt for the error elsewhere.

[IT Dept]

An error I'm seeing in the core.log is as follows, and looks like it might be the source of the problem:

2010-11-01 15:14:50,608 INFO  [provider-runner] [com.cisco.uc.core.sm.StateMachine] [StateMachine.logTransition(301)] - [       STARTING] -> PROVIDER_START_FAILURE   -> [           INIT] : class com.cisco.uc.core.broker.phone.StartSoftPhoneFailureHandler
2010-11-01 15:14:50,609 ERROR [ws-pool-thread-2] [PhoneService] [PhoneServiceImpl.initialize(1012)] - Problem initializing the Phone service. Server(s) unavailable
com.cisco.uc.core.common.exceptions.config.FailedToGetConfigurationCoreException: Server(s) unavailable
    at com.cisco.uc.core.broker.config.CUCMConfigSubService.fetchPhoneConfig(CUCMConfigSubService.java:531)
    at com.cisco.uc.core.broker.config.ConfigServiceCoreImpl.fetchPhoneConfig(ConfigServiceCoreImpl.java:1043)
    at com.cisco.uc.core.broker.phone.StartSoftPhoneHandler.handleEvent(StartSoftPhoneHandler.java:61)
    at com.cisco.uc.core.sm.StateMachine.runEvent(StateMachine.java:279)
    at com.cisco.uc.core.sm.StateMachine.runEvent(StateMachine.java:239)
    at com.cisco.uc.core.provider.manager.ProviderController$ProviderRunner.run(ProviderController.java:336)

For reference, of course.