angryciscoguy

Cisco removed the uninstaller from UCCX7 and states in their documentation that it is no longer supported. However, as the installer is based on microsoft’s msiexec.exe, we find that these options are still valid from the command line.

http://msdn.microsoft.com/en-us/library/aa367988(VS.85).aspx

Thus, “setup.exe /x” will allow you to bypass the restriction of the Cisco installer and allow successful (although unsupported) uninstallation.

So, I am seeing a lot of Cisco phone proxy installs lately and thought I’d put together a quick cheat sheet for the configuration that you will see in 99% of your installs. This of course is where you are not encrypting voice on the internal side so no fancy CAPF CTL to CM junk. The config is actually rather basic in this scenario (when you know what you are doing and understand the components involved).

Prerequisites:

• ASA 8.0.4 code release
• ASA already configured and working as basic firewall with inside and outside connectivity.
• A minimum of 2 Global (external) IP addresses for this feature
• Basic ASA configuration knowledge
• Basic Cisco Communications Manager knowledge
• > 2 working braincells

IP Configuration:

• Internal CM address    192.168.1.1 (required)
• Internal CM address    192.168.1.2 (optional)
• External TFTP Address #1  1.1.1.1 (required)
• External TFTP Address #2  2.2.2.2 (optional)
• External Media Address 3.3.3.3 (required and must be dedicated to this feature)
• External phones must be pointing to external TFTP IP address(es) as configured by ASA.

Config:

Below configuration includes the extra input as required. A show run will not show all these commands and will additionally show  auto generated configurations that are part of this config but not seen below. (for more details, see prerequisite #4 and #6). Additionally this config does not show you how to get the URL functions of the phone working (Enterprise Parameters setup in CM). That usually involves one of the 2 following configs: reverse http proxy to CM that you use to point the ip phones to (more secure, requires http reverse proxy server); pinhole in ASA (port forward) to point the external adddress ports to the internal http ports on the CM server (less secure).

So on to the ASA config…

(more…)

While SRST has it’s place, it limits are easily found. A while back Cisco introduced a new feature to CME that allows it to perform SRST functions with the added features that CME provides. I recently tried this configuration out myself and was pleasantly pleased in it’s performance. Check out the details for yourself here:

http://www.cisco.com/en/US/docs/voice_ip_comm/cucme/admin/configuration/guide/cmesrst.html#wp1015579

I chose to use the setup where the CME “learns” the config of the phones similar to how normal SRST works. A “gotcha” with this (that got me… >:8 grrr)  was the restriction that you dont save your IOS configuration while in fallback mode. And yes, it is documented… The reason for this is due to the way CME-as-SRST handles it’s ephones and ephone-dn’s. In a normal SRST setup you will nto see these in the config, however in the CME-as-SRST setup you will, but only during fallback. If you save the config you are essentially staticly configuring those phones and the system can no longer learn the configuration during the next fallback. The symtoms present themselves as phones that seem to revert to old configuration when fallback is operational. The fix is to delete all the learned ephones and ephone-dn’s while the system in not in fallback mode and then “write mem”.

At times it is not necessary for voicemail boxes or advaced auto-attendant features on a remote gateway that is serving a small office. This is especially true for remote non DID (ie FXO trunked) SRST gateways that are only active a small amount of time. Instead of adding a AIM-CUE or NM-CUE voicemail module in the gateway, basic auto attendant features can be provided right in IOS. (more…)

Many admins spend a great deal of money on management software for the sole reason of getting config backups on a regular basis from their Cisco IOS devices. With this simple setup, you can automate this directly from your device. You can send the config to any number of destinations. (more…)

Many of late are using GNS3 to simulate their lab. But many others are still using hardware the ole fashion’d way. A big part of getting a good lab setup is simulating the infrastructure. In most of the IE tracks, having a frame-relay network in place for simulating the connections between sites is a must. QOS, FRTS, etc. To do this you will need to have hardware in place to provide this infrastructure.

There are many options here. The easiest way to start is with a router that has several serial interfaces. I suggest a 2522 router as you can pick those up cheap. It has 8 serial ports. Otherwise, a nm capable router (26xx/36xx/etc) with a nm-4a/s or nm-4t is also a good start. (Need larger use a nm-8a/s or nm-8t) The big difference between the “a/s” and “t” version is the speed at which they clock. The “a/s” is limited to 128k connections and the “t” is at 2mb. (more…)