The customer keeps his wireless NIC on all the time; when he is in the office it is connecting to a different SSID than the UC520 for compatibility purposes, but everything is on the same subnet.  Routing isn't the issue; the problem is the licensing, which is based on MAC address of the NIC in use when the UCC software was licensed.  This is obviously a problem when there are two NICs in use and the UCC software picks the wrong NIC to verify the license.  I'll try setting the preferred NIC to the wireless NIC, which may solve the problem on his machine.

However, the problem still remains for someone who uses the wired NIC in the office, and the wireless NIC on the road (with VPN client and IP Communicator).

I sent an internal email to the UCC team and hope to have an answer shortly.   Sorry for the delay.

I got some feedback.....  Let us know if this helps:

A lot of the 1.5 testing was performed with notebooks with dual NIC (wired and wireless). The recommendation is that at the time of the license activation, the both network adapters should be enabled – they do not have to be connected to either network. The activation logic records these MAC addresses.

Once activated, either of  these networks adapters can be in use, without effecting the license checking logic as long as both of them are enabled i.e. not disabled.

If the wireless adapter is always enabled, and the wired is sometimes disabled, then the client should be re-activated with the wired disabled and the wireless enabled. When the client performs the license checking, if it can find the wireless adapter, then it will satisfy the binding requirement.

--------------------------------

The UCC licenses are bound to the physical machine information which includes the NIC/MAC id.  This binding is performed during the license activation process. A requirement is that the network adapters that are in the enabled state, during activation, also be there when the license checking is performed when the UCC client is run. On PC with dual-network adapters, please ensure that the adapter (s) that are going to be used when the UCC client is run are in the enabled state both during activation and also when the client is started.

If the NIC card changes or the application needs to be ported to another machine, then the license needs to be de-activated. This can be done by sending a request with the serial number to the cs-callconnector@external.cisco.com alias. We will clear the activation record allowing the client to be re-installed on another machine.

When the UCC personal client was installed on the customer's machine both NICs were active.  Playing with it further, however, the problem appears to come into play when the phone is re-registered while the UCC is up.  This seems to sometimes confuse the UCC until all services are stopped, the client is closed, then reopened.  If the services are restarted without closing the client, the UCC seems to be unable to figure out what NIC to use for licensing.  If the UCC is closed, then reopened without stopping all services, it has trouble acquiring lines.

Hello and hope your well.

The UCC license checking is unrelated to the TAPI registration to the ip-phone, but I have discussed this with the test teams to try to re-create the scenario.

The license checking does use the NIC card information. This binding takes place during the activation process. To re-set the binding, please send an email to the cs-callconnector@extenal.cisco.com alias. Please supply the serial number that you need reset.  Then you can relicense with BOTH NICs on.  I think tyhat may help.

Steve D

SE Sales Channel U.S.