UCCX Demo License

Disclaimer: The following information is for research and experiment purpose only.  It's not the author's intention to circumvent Cisco's licensing.  Neither does the author encourage software piracy.  You cannot hold the author responsible for any disputes/lawsuits caused by this information.  If you disagree, please stop reading.

UCCX installation DVD comes with some demo licenses.  Unfortunately, unlike CUCM, UCCX demo license expires in 30 days.  And you'll get the warning every time you log into UCCX administration page.

If you look at the NodeConfig in CET Tool, you'll see the "Grace Period Starting Date" and "Demo License Flag".

To stop the demo license from expiring, three things need to be done:
1) "Demo License Flag" should be "false"
2) "Grace Period Staring Date" should be blank.
3) Most importantly, your license MAC has to match the MAC in license file (which is "FFFFFFFFFFFF" in this case).

For #1 and #2, you need to modify the XML file in directory /opt/cisco/uccx/ClusterData/default/com.cisco.crs.cluster.config.NodeConfig.  Change the last 16 characters in the block to 0 (zero).

First 8 characters (4 bytes) is the "Grace Period Starting Date" in epoch time format.  Second 8 characters (4 bytes) is the "Demo License Flag" (1 stands for "true" while 0 stands for "false").

Before:

After:

Then change the License MAC to "FFFFFFFFFFFF".

Before:

After:

Reboot the system to take effect.  You'll notice that you don't get the license expiring warning when you log into UCCX admin web page.

Restart CET just to verify the changes we made:

 

P.S.

1.  "/opt/cisco/uccx/ClusterData/default/com.cisco.crs.cluster.config.NodeConfig" is a directory.  The file names in this directory are randomly created.  You need to modify the one with .xml extension.

 

2. This method was last verified on UCCX 10.5.1.10000-24, though 8 additional octets were added to the end of the xml file.

XML file before:

XML file after:

CET Tool for UCCX

Back in the age of Windows-based CallManager (4.x and before), UCCX (a.k.a CRS) stores its configuration in CallManager DC Directory.

When CallManager moves to Linux based (CUCM 5.0 and above), it removes the concept of DC directory.  Thus UCCX has to store its configuration on UCCX server in XML files.

Cisco provides a tool called CET (Configuration Editing Tool?) to edit those configurations.  The tool is supposed to be used by Cisco TAC only.

For Windows-based UCCX (7.x and before), you may find the CET tool on UCCX server C:\program files\wfavvid\cet.bat.  Just the the cet.bat file.

For Linux-based UCCX (8.0 and above), you may find the CET installer on the UCCX installation DVD (\Installer\CetTool\CetTool.exe).  Or download from an already-installed UCCX server http://142.100.64.14/uccxinstalls/CetTool.exe (case-sensitive).  You'll have to install it on a Windows workstation.

You may use CET tool to modify the configuration of UCCX, such as removing license file or reset the system back to before-initialization state (for password recovery purpose).  Please note that on Linux-based UCCX, you'll need a root credential to use CET tool.  Either get it from Cisco TAC or follow instructions here.

You may also modify the configuration without CET tool.  But it requires some reserve engineering.

For example, you want to set the UCCX 8.5 back to FRESH INSTALL state.  You may edit the XML file in /opt/cisco/uccx/ClusterData/default/com.cisco.crs.cluster.config.AppAdminSetupConfig.  Look at the blobValue.  It's encoded in ASCII.

Translate that with the ASCII table:

You'll get:

46 = F
52 = R
45 = E
53 = S
48 = H
5F = _
49 = I
4E = N
53 = S
54 = T
41 = A
4C = L
4C = L

If you want to set the value to a specific string, you'll translate the string into ASCII code and put it in blobValue.

Modify License MAC

Cisco used to bind license file to physical MAC address.  Now, it moves to "License MAC", which is a hash value of multiple system parameters such as NIC speed, NTP, DNS, hostname, etc.

To view the license MAC, you need to install the system first (CUCM, UCCX, CUPS, etc.).  Then use the "show status" command.

 

This is somehow inconvenient:

1) You cannot get the license file before finishing the installation.

I personally prefer to get everything ready before starting the installation, such as IP address, hostname, password, license file, installation media, etc.  You could run into lots of surprises when trying to get the license file.

2) When the system parameter was changed, the license file yield invalid.

For example, you add/change DNS server settings on the system, which is pretty common during system integration.

It would be better if you could dictate what license MAC the system use.  You may also use some schema like: AABBCCDDEEFF, where AA is the product code, BB is the site code, CC is the node number, DD is the version number, etc.

In the example above, the "License MAC" was changed to "abcdef123456".

Since you can use whatever License MAC you like, you may:

• Get the license file before the system was installed
• Keep using the same license file after system parameters was changed (such as DNS)

To specify the license MAC, you need to have root access to the system.  Then you'll modify the file /usr/local/bin/base_scripts/LicenseMac.sh.  To the bottom of the file, replace the line

FinalString=`expr substr "$SHA1sum" 1 12`

to

FinalString="abcdef123456"

In newer versions, you might have to change the /etc/selinux/config file so that selinux runs in permissive mode.

Reminder: Don't be evil.  ;)

Database Access

Many UC appliances (like CUCM, CUPS, etc.) use database to store configuration.  For security and supportability reason, the regular CLI provides limited access to database.  However, if you could get root access to the box, you would have full access.

su - informix

Change user role to 'informix' which is a built in Linux user to access the Informix database.

dbaccess $(dblutil -c) -

dbaccess is a SQL client to access Informix database.  'dblutil' is a DB role.

select * from licenseinfo

A standard SQL command to view all records in 'licenseinfo' table.

Notes:

• Press Ctrl-D to execute SQL commands
• Press Ctrl-C to exit
• On some terminals, you may have to press Delete to Backspace

If you want to know the relationship between different database tables, refer to "Data Dictionary" on CCO Docs.

To list all tables:

select tabname from systables where tabid > 99 and tabtype = "T"

Grab a some books like "SQL for Dummies" and test in your lab.

I wondered what does this do?  ;)

Root Access on Linux-based UC appliances

There are many posts on Internet teaching you how to get root access on CUCM.  This is not a secret.  Since CUCM is Linux-based, the method is pretty straight forward - use a Linux boot CD to boot into rescue mode and modify the relevant files.  Here's a simple walk through.

Assuming CUCM was already installed.  Boot the box with a Linux installation CD (e.g. RedHat).  Type "linux rescue" in the boot prompt.

Chose language.  Default is 'English':

Choose keyboard.  Default is 'US':

We don't need to set up network.  Thus choose 'No' here.

Choose "Continue" to mount the CUCM file system.

The following message is telling you that the CUCM file system has been mounted under /mnt/sysimage.  If you want to map the root directory to the CUCM file system (which is recommended), you may use command "chroot /mnt/sysimage".

Below are the commands and explanations.

chroot /mnt/sysimage

This is to map the root directory to CUCM file system.

cd /etc

Change the working directory to /etc, where most of the system configuration files are stored.

rm securetty

Remove file "securetty" to allow remote connections with root.

passwd root

Reset (change) password for the root user.  Type a password that is easy for you to remember.  Retype it to confirm.  If the password was changed successfully, you'll see the prompt "passwd: all authentication token updated successfully".

Notes:

• If you typed a simple password, you might get a warning like "BAD PASSWORD: it is based on a dictionary word".  Just ignore it and retype to confirm.
• There's no screen display for the password you're typing.  Type carefully.

The following steps require some basic knowledge of the vi editor.  If you're not familiar with vi, please search Internet for vi commands help.

vi passwd

Change the passwd file so the root user has a shell (command line interpreter) to use.  Use vi commands.  Change the line

 To

Save and exit file.

For those who are not familiar with vi, here are the command sequence (case-sensitive):

1. Type /s to search for character 's'
2. Type D to delete to the end of line
3. Type A to enter append mode
4. Type bin/bash to set the shell
5. Press ESC key (it's a key on the upper-left corner of your keyboard) to exit append mode
6. Type :wq to save and exit file.

vi ssh/sshd_config

Change the sshd_config file so you can SSH as root (it's disabled by default).  Use vi commands.  Change the line

 

To

Save and exit file.

For those who are not familiar with vi, here are the command sequence (case-sensitive):

1. Type /Per to search for the word begins with 'Per'
2. Type X to delete the letter on the left (which is '#' in this case)
3. Type :wq! to save and exit this read-only file

Back to command prompt and type exit command twice to reboot the system.


Use a SSH client (such as putty) to test.  You should be able to SSH into CUCM with root account.

This method applies to all Linux-based appliances such as Unity Connection, CUPS, CER, UCCX (Linux version), etc.

P.S. If the active partition is /PartB, you might run into an error like this:

Just hit "Enter" key to get to the shell.  Then use the following commands:

mount --bind /dev /mnt/sysimage/dev
chroot /mnt/sysimage

===================================================
Updated 3/13/2015:

I got many comments that "this works on CUCM version xx but didn't work on version yy".

Please understand that CUCM is just an application running on top of the RedHat Linux (which Cisco uses for many of its "appliances").

The rooting process is more OS related than application related.  If it didn't work, there could be only two reasons:

1) Some steps were missed or weren't done right (most likely).
or
2) RedHat changed how the authentication works between versions (very unlikely).

In a nutshell, the rooting is not specific to CUCM.  It's not even specific to Cisco.  You may root any appliance that is based on a common OS (such as Linux).

Last but not the least, this still works on my CUCM 10.5.  :)

Bypass CUCM/Unity hardware check

I was trying to install the UC 8.6.1 suite on my VMware ESXi.  I'm pretty savvy at VMware and UC, thus I didn't bother to download the OVA template from Cisco.  I created a VM with 75G hard drive and 2G RAM.

I had no problem getting UCM installed.  However, when it came to Unity Connection, I realized that the option was not presented on  screen like it did in previous versions (see below).

Maybe there's some magic in the OVA template.  So let's download it.

Open up the OVA file with Notepad.  You'll see that the minimum hardware requirement is 4G RAM and 160G hard disk.

If you're just testing it in the lab and want to save some hard disk space, you may choose "Thin Provision" while deploying the OVA.  VMware will dynamically allocate space as needed up to 160G.  ie. if the initial install occupies 75G, it'll only takes 75G physical space (even though the hard disk "looks like" 160G).  This is not recommended for production environment for performance consideration.

But if you're the kind of people that like to control everything, this is pretty annoying.  Why can't it just install on a 75G disk?  Ya, why not?  Let's hack it.

On the installation disc, look for the folder "Cisco/Install/conf".

Open the file "callmanager_product.conf" and search for "Unity Connection VMware rule".  A couple lines below, you'll see the line "NOT,   VMware,     *,      *,    *,      *,     *,      *,    *,      *".  Change it to "VAL,   VMware,     *,      *,    *,      *,     *,      *,    *,      *".  This will allow any virtual machine specification.

You may do the same if you want to use a physical server.  For example, if you have an old 7825H server and want to install Unity Connection 8.6.1 on it, just change the line "NOT,    7825H,     *,      *,    *,      *,     *,      *,    *,      *" to "VAL,    7825H,     *,      *,    *,      *,     *,      *,    *,      *".

You may also change the sections for CUCM and CUCM BE so they have less restricted requirements.

Save the file to the disc (image).  Boot from it.  Now you see the Unity Connection is available as shown below.

By the way, UC 8.6 supports VMTools (finally).  However the VMTools bundled with the install might not be up to date.

From CUCM CLI:

You may update the version from VM client.

The installation will take a while.  During install, you'll see the VMTools status as "not running".  This is normal.

When the install is completed, you'll see the version is updated.

 

From CUCM CLI:

Some tools for home lab

1) Pegboard - A board with holes so you can hang things on it.
So you can hang IP phones like this:

2) Remote Power Switch - allows you to power on/off device remotely through network.

I got NPS 115 from eBay for about $40. I used it a lot when I'm away from home. So I can practice from office or hotel room.
Please note that this one has 8 outlets and allows you to power on/off devices (routers/switch) individually. Some cheaper ones (like $20) have only one outlet. You have to power everything on or off at once.

Voice IE: Mysterious phone registration issue

It's a hub-and-spoke topology - CUCM was at the HQ site while two branches BR1 and BR2 are connected to HQ router via Frame-Relay.

One of the phones on BR2 was not able to register to CUCM. The phone's screen displays "Registering".

Since the other phone on BR2 was able to registered, I thought the problem was specific to the phone. Thus I checked the phone configuration, reset the phone, restore it to factory default, re-located it to HQ site, etc.

The phone was able to register while it's on HQ. But it doesn't work while it's on BR2. So it seems to be site specific. However, if it's site specific, why the other phone on the same site could register?

Since the network path was "phone -> BR2 router -> Frame Relay -> HQ router -> CUCM", I focused on every elements on the path. The phone was able to get the correct IP config (subnet mask, default gw, TFTP) from DHCP. I wiped out the router configuration and reconfigure it. I deleted the phone from CUCM and re-added it. Reloaded CUCM and routers. Still no avail.

I pinged the BR2 phones from CUCM CLI. I can ping phone1 but not phone2. Then I realized it HAS TO be the network. But how come? For two hosts in the same subnet, if I could ping one but not the other, it HAS TO be the host's issue. But I already proved phone2 was working fine when it's on HQ site.

With the help of "debug ip packets detail", I found out that HQ router chose different paths for phone1 and phone2. But I didn't configure host routes. How could this happen?

"show ip route" discovered that BR1 was advertising same route as BR2. They both claimed to have the BR2 phones' subnet. Since they are equal cost routes, HQ router will load-balance the two routes (uses BR2 to reach phone1, then uses BR1 to reach phone2). That's why phone1 is always reachable while phone2 is always unreachable.

By reviewing BR2 router's config, I found out that I fat-fingered the IP address for the data VLAN (with the address of BR2 voice subnet).

This kind of mistake could easily cost you couple hours in the lab unless you had experienced it before and have some routing knowledge.