Some quick notes on UC on UCS Installations

1.)There is quite good documentation on CCO, including the SRND
2.)Some stuff i did have to search in the Docs
a.)the suggested Disc Setup for Co-Res on C-Series is:

• Disks 1+2 as Raid 1
• The other 8 Disks as a Raid 5

 b.)When using the pre-boot cli for Raid creation, the Enclosure IDs in the docs might be wrong for newer server (not "252" but "18" on a c210m2).
You can check this via the command:
encinfo -a0 -page 20
(the page option gives paged output)
Disk IDs for me did not start at zero (again, some docs state this but not all). This you will just have to try.
Otherwise a very nice installation.

XML Services with Cisco Phone Proxy: Part 1 - the easy part

The ASA phone proxy is a very nice feature where a ASA acts as Skinny or SIP proxy for cisco phones. Generally i prefer the new phone vpn feature in UCM 8, there are very valid reasons to use phone proxy for remote worker phones.

Key to understand phone proxy is, that it only proxies signalling (secure signalling to be exact) and media traffic to ucm. anything else is not proxied, and this means XML services (e.g. Extension Mobility Login/Logout). So these services do not work by default.
Generally opening up those XML services to the outside world SHOULD not be an option ;-).

There is a new feature to help with this since ASA 8.2 but is very well hidden.
When looking at the ASA config guide at http://www.cisco.com/en/US/docs/security/asa/asa82/configuration/guide/unified_comm_phoneproxy.html, there is the proxy-server configuration command, which is described as follows:

If the operational environment has an external HTTP proxy to which the IP phones direct all HTTP request, configures a proxy server.

You can configure only one proxy server while the phone proxy is in use.

By default, the Phone URL Parameters configured under the Enterprise Parameters use an FQDN in the URLs. The parameters might need to be changed to use an IP address if the DNS lookup for the HTTP proxy does not resolve the FQDNs.

Note If the IP phones have already downloaded their configuration files after you have configured the proxy server, you must restart the IP phones so that they get the configuration file with the proxy server address in the file.

So, the command can actually be used to at least make the services on the UCM directly available WITHOUT an extra proxy.
for this, just configure the following under the phone proxy configuration

proxy-server a.b.c.d interface <inside>

where a.b.c.d is the internal IP of the communications manager and <inside> is the name of the inside interface.
For example:

phone-proxy ASA-phone-proxy
   proxy-server 192.168.214.10 interface inside

would make the services available on the UCM 192.168.214.10 directly

Et voila, this will open a dynamic pinhole for port 8080 for all registered phones to the UCM and it will allow the phones to use the services that are directly located on the UCM (even though the UCM is of course not a proxy server as such)

If you need other XML services, you need to use a external proxy. A configuration example for such a case follows during the next days.

Kerberos Authentication in Cisco Unified Videoconferencing Manager: Too large SPNEGO Token

Cisco Unified Videoconferencing Manager (CUVCM) is the current Cisco Videoconferencing Manager Product (Radvision OEM). Which means it won't be the future product since it will be replaced by Tandberg VCS and TMS I guess (this actually makes a lot of sense).
Still, there is quite an installed base of this product in the field and there will be one for quite some time in the future.  So for those who have an installation and want to replace the build in NTLMv1 SSO here is a caveat i fought with:
Basically the setup is pretty straight forward, just go according to the guide here:
www.cisco.com/en/US/docs/video/cuvcm/7_1/configuration_guide/kerberoscuvcm71.pdf

Some things to look at in detail:
->Make sure the principal matches your hostname
->Sniff traffic on the CUVCM server to make sure you are hitting the right Domain Controller


For us it still did not work initially. After search together with TAC for a long time, a Linux server admin at the customer put us on the right track for resolution:
The customer had a relatively large AD with multiple domains. Therefore the SPNEGO header used for Kerberos became comparatively large.

It turns out, Tomcat (and quite a lot of other Web Servers put a limit to the maximum size of the HTTP header that is being processed. The large SPNEGO token pushed us over that limit.

So to change that limit for the HTTP header in the Tomcat SAR (CUVCM is actually using JBOSS which is using tomcat as the embedded Servlet Container):
Open the following file:
\JBOSS_DIR\server\default\deploy\jbossweb-tomcat55.sar\server.xml 

Change the value for : maxHttpHeaderSize to something larger than the default of 8192 (8KB), e.g. 16384 or 32768

Reset CTL on Cisco Unified Personal Communicator (CUPC) 8

One of the new features of CUPC 8 (or CSF in general) is that it supports a lot of the UCM encryption and security features.
If you are hopping between different clusters (because you are an SE) you might run into troubles with this.
For example you might have connected to a secure cluster before and now your CTL (Certificate Trust List) does not match with the new cluster. Therefore CUPC Presence and chat will work but the Softphone component will not.
In this case the CTL needs to be deleted.
This can be done by delete the CTL file in the following directory:
C:\%USERPROFILE%\AppData\Cisco\Unified Communications\Client Services Framework\Security\sec\lsc0

Be aware, that the "AppData" part might be localized, e.g. "Anwendungsdaten" in German.

Auto Configuration for SCCP VGs

a lot of people don't know you can autoconfigure vg202s (and 204s and 224s) not only when using mgcp but also when using sccp.
Unfortunately it is not zero touch, so you need to put some commands in before deploying the device.

1.)Put the device into the ccm. Otherwise there won't be a config file on the TFTP to download for the device :-)

2.)device needs an ip, either via dhcp or statically. let's assume dhcp

3.)If you have set option 150 for the dhcp pool in quedtion you just need the following comminds

sccp local <interface>, e.g. sccp local fas 0/0

ccm-manager sccp

4.)if you don't have option 150 set or no dhcp you need to tell the box where the ccm is:
ccm-manager sccp

ccm-manager config server <tftp server>

that's it
works like a charm.

CIsco umi, what to think of it

Last week cisco announced Cisco umi, a home "telepresence" system. There is a lot of discussion about wether the system will take off or not. This is mostly focussing on price (600$ for HW, 25$ a month for the service plan).
These are definitely valid points. Unfortunately the info on the product is still quite light at this point but the following interview with Martin de Beer is the best info I found:
http://techcrunch.com/2010/10/07/cisco-umi-korea/
The interview touches some interesting topics (healthcare services via umi, interesting for rural areas) and shows some more strategy for the product ( a consumer device beachead for cisco). The Korea tie in is also of interest.

Still, as a voice and video professional i feel i need to point one thing out:

umi is a 600$ (if factoring in 1 year of service 900$) 1080p videoconferencing endpoint.

Let me repeat this:
A 1080p capable videoconferencing endpoint for under 1000$.

Crazy
I would love to see how much the unit actually costs from a manufacturing standpoint.

CIsco UCM Encryption: Scared of unplugging that USB Token?

So there are some ucm issues that pop up again and again.
One of those is a misunderstanding with regard to the Cisco Site Administrator Security Tokens (SAST) which is used to enable authentication and encryption for signalling and media on a cisco communications manager.
People tend to think you need to have those plugged into one of the UCMs (e.g. the publisher) to have encryption working. This is not the case.

The SAS tokens are actually just cisco branded aladdin security tokens which contain a security certificate rooted by a cisco manufacturing CA. You use the tokens with the Certificate Trust List Client (CTL Client) which can be downloaded from the Application, Plugin pages on the UCM Web interface.
The Cisco CTL Client has to be installed on a windows PC(!) which has access to the callmanager servers (!, notice the plural here).
Once you have installed the client you can switch the cluster to mixed mode, therefore allowing  both encrypted connection as well as unencrypted connections.

When you do this you will be prompted to a.)Enter a UCM Administrator password and b.)to insert 2 security tokens during the install.
The role of the tokens is quite clear once one understands what the CTL Client does. The CTL clients generates the certificate trust list (CTL) that is downloaded by phones. The CTL specifies all the certificates, that the IP phone trusts and will accept for connections.
So this means callmanager service certificates and tftp server certificates. If you are using TLS proxy you would also add the certs of the firewalls acting as TLS proxies.

When a "virgin" IP phones connects to a cluster it will at first accept any CTL. But once it has downloaded a CTL it will only accept a CTL that was signed by a certificate that is contained in the already installed CTL of the phone.

So this is what the tokens are atually for:
1.)One of the Security Tokens signs the CTL
2.)The phone will only accept a CTL that was signed by a token that it already knows (meaning it is part of the CTL)

So by adding 2 or more (I use 4 tokens for large installations) to the CTL you ensure that you have a token with which you can generate a new CTL that will be accepted by the rolled out phones. If you lose one of those tokens it is not a big deal since you can use another one and add a new token to the CTL.

When you finished the process of uploading the new CTL your job is done, the Callmanagers will be able to hand out certificates via CAPF and CTLs via the CTL providers without needed the tokens during normal operations.
You don't need the tokens in the servers. Actually they don't serve any purpose there (you can't even enter the security pw for the token on ucm).

Where does the misunderstand about the tokens then come from?
2 Sources:
1.)When we originally got the encryption feature it was on UCM 4.0. Everyone was running the CTL client directly on the windows based server. Therefore it seemed kind of logical to just leave the token plugged into the server...
2.)This: http://www.cisco.com/en/US/products/sw/iosswrel/ps5207/products_feature_guide09186a00802d1c31.html
the advisory says: "Cisco recommends that you store the security tokens in a location that you will remember. If you want to do so, keep one security token in the USB port at all times."
So it seems someone just thought the usb port of the server is a good place to store the tokens. 

What a stupid idea

Now where am I going to take the time for filling this blog?