Download Java 7 Update 25 offline installers

Have Java Runtime Environment 7 Update 45 installed and need the older Update 25 offline installers?  Here you go...

Java Runtime Environment 7 Update 25 (Windows 32-bit installer) http://javadl.sun.com/webapps/download/AutoDL?BundleId=78825

Java Runtime Environment 7 Update 25 (Windows 64-bit installer) http://javadl.sun.com/webapps/download/AutoDL?BundleId=78827

Cisco CUCM modify or create custom ringtone

You can find specifics regarding the required CUCM ringtone file type in your phones administration guide.  One example is here: http://www.cisco.com/en/US/docs/voice_ip_comm/cuipph/7965g_7945g/6_1/english/administration/guide/7965cst.html#wp1h088184

Download a ringtone to a SFTP server.  I am using FreeFTPd from http://www.freesshd.com/ on a Win7 laptop.

Just a note about FreeFTPd... I would suggest NOT installing it as a service if you only run it occasionally as administration is much easier, and if on Win7, when starting the application, right click and run as administrator to allow changes being committed to the FreeFTPd config (i.e. users, home directories, etc.).

Here's an example of how to download a ringtone (in this case, Vibe) via the CUCM CLI:

login as: platformadministrator
platformadministrator@10.11.12.13's password:
Command Line Interface is starting up, please wait ...

   Welcome to the Platform Command Line Interface

VMware Installation:
        2 vCPU: Intel(R) Xeon(R) CPU           E5506  @ 2.13GHz
        Disk 1: 80GB
        4096 Mbytes RAM

admin:file get tftp Vibe.raw
Please wait while the system is gathering files info ...done.
Sub-directories were not traversed.
Number of files affected: 1
Total size in Bytes: 16080
Total size in Kbytes: 15.703125
Would you like to proceed [y/n]? y
SFTP server IP: 192.168.111.112
SFTP server port [22]:
User ID: sftp
Password: ********

Download directory: /
.
Transfer completed.
admin:

Since the ring files are in a headerless / RAW format, you'll need an application to open, play and manipulate them, accordingly.  I use Audacity from http://audacity.sourceforge.net/.

Audacity will not know the format of the file, so rather than simply using File | Open, use File | Import | Raw Data.

There you will need to change the Encoding to U-Law and the sample rate to 8000.

At that point, you should have the file open, and be able to play or modify it to your liking.

When you are happy with the modifications, rather than simply saving, you will need to use the File | Export menu option.

When prompted with the Export File dialog box, enter a file name and location for your modified ringtone. The Save as type should be Other Uncompressed files.  Then click the Options button.

When prompted with the Specify Uncompressed Options dialog, set the header to RAW and the Encoding to U-Law. Click OK and Save.

You now have a new ringtone that can be uploaded to your CUCM server(s).

Cisco CUCM SIP CUBE calls fail early media

This fix is documented in various places on Cisco's site, but a common point of confusion.

See Update below for symptoms found after first resolution

I've run into two different scenarios where a users on a CUCM deployment with CUBE routers as the demarcation point to the PSTN via SIP trunks has had problems dialing numbers terminating on IVR or automated attendants.  One, frighteningly, was calls to 911, the emergency number in the US.  The callers would either experience continuous ringing, or no audio although the call did not appear to be dropped.

You don't want emergency calls going to dead air.

CUCM -> SIP trunk -> CUBE -> SIP trunk -> PSTN

The short story is that "early media" cut-through needed to be enabled.

This is enabled by default on the CUBE routers but could be potentially disabled or modified on the router using the "disable-early-media" command.  After reviewing the configuration, I found no variations of the command applied to the CUBE configuration.

The answer then is to send a PRACK via the CUCM configuration.  This is disabled by default in CUCM.

In CUCM, navigate to Device | Device Settings | SIP Profile.
Find the profile associated with the SIP trunk between CUCM and CUBE.
Modify the SIP Rel1XX Options. I've found Send PRACK for all 1XX messages to be universally successful.

Before:

After:

From CUCM help:

This field configures SIP Rel1XX, which determines whether all SIP provisional responses (other than 100 Trying messages) get sent reliably to the remote SIP endpoint. Valid values follow:

Disabled (default) — Disables SIP Rel1XX.
Send PRACK if 1XX contains SDP — Acknowledges a 1XX message with PRACK, only if the 1XX message contains SDP.
Send PRACK for all 1XX messages — Acknowledges all1XX messages with PRACK.

Update:

Found with this configuration above, users had issues with transferring incoming PSTN calls to external PSTN calls.  Incoming PSTN call could not be transferred or conference with another off premise call until until the callee answered.

I found disabling the SIP Rel1XX options and simply checking Early Offer support for voice and video calls (insert MTP if needed) allowed both successful calls to the network based IVRs and transfer / conferencing in a timely basis.

After:

Cisco UCS C220 C-series serial numbers

Note: this post originally did not include the correct cURL commands.  Blogger does not allow < or > characters in posts without HTML encoding, so my hasty copy and paste of  the raw script excluded many details.  Sorry for the confusion. 

After a Cisco UCS C220 server was rebuilt piece by piece by TAC and then ultimately declared DOA, I was requested by our Smartnet manager to retrieve all the serial numbers for all the minor components. Because it was a stand alone rack mount server, I did not have UCSM available to pull the information.  I was also disappointed to find CIMC did not provide the serial numbers for all the components.

Outside of disassembling the server, it seems then that the UCS XML API interface was my answer.

By the time I managed to find all the class IDs of all the components and get a script working, we found the serial numbers on packing labels, a much simpler solution.  For those interested in some real UCS XML API examples, below is a snippet of a script I was putting together.

I was using Strawberry Perl from http://strawberryperl.com/ on MS Win7 for scripting and curl from http://curl.haxx.se/dlwiz/ for the communication with the UCS XML interface.

#! perl

use 5.010;
use strict;
use warnings;

my $ucsip = 'PUT YOUR UCS SERVER IP ADDRESS HERE';
my $ucsuser = 'PUT YOUR UCS ADMIN USERNAME HERE';
my $ucspassword = 'PUT YOUR UCS ADMIN PASSOWRD HERE';
my $cookie;

# print info re: script
sub print_header {
print "####################\n";
print "#\n";
print "# Get serial numbers from the UCS server\n";
print "# and it's components\n";
print "#\n";
print "# Ray Maslanka 11/29/2013\n";
print "#\n";
print "####################\n";
}

# log into UCS server, get and return cookie
sub curl_ucs_login_and_get_cookie {
    my $cookie;
print "Logging into UCS via web...\n";
# use curl to return login info and redirect stderr to stdout via 2>&1
my $curl = `curl -d "<aaaLogin inName='$ucsuser' inPassword='$ucspassword'></aaaLogin>" https://$ucsip/nuova -k 2>&1`;
print "Finding UCS cookie...\n";
if ($curl =~ /(outCookie=")(.{47})/){ # look for stuff starting with outCookie=" and then any 47 characters
print "Found cookie: $2\n"; # throw confirmation on screen
$cookie = $2; # put the regex in a variable to return
} else {
print "Can't find a cookie\n"; # something's bad, add some error checking
}
return $cookie;
}

# get UCS chassis serial number
sub curl_ucs_chassis_serial {
my ($cookie) = @_;
my $serial;
print "Getting chassis sumary from server...\n";
my $curl = `curl -d "<configResolveClass cookie='$cookie' inHierarchical='false' classId='computeRackUnit'/>" https://$ucsip/nuova -k 2>&1`; # use curl to return login info and redirect stderr to stdout via 2>&1
print "Finding chassis serial number...\n";
if ($curl =~ /(serial=")(.+?)(")/){ # look for stuff starting with serial=" 
print "Found chassis serial: $2\n"; # throw confirmation on screen
$serial = $2; # put the regex in a variable to return
} else {
print "Can't find a chassis serial number\n"; # something's bad, add some error checking
}
return $serial;
}

# get power supply serial numbers
sub curl_ucs_ps_serial {
my ($cookie) = @_;
print "Getting power supply details from server...\n";
my $curl = `curl -d "<configResolveClass cookie='$cookie' inHierarchical='false' classId='equipmentPsu'/>" https://$ucsip/nuova -k 2>&1`; # use curl to return login info and redirect stderr to stdout via 2>&1
local $/ = undef;
print "Retrieving power supply serial...\n";
while ($curl =~ /(serial=")(.+?)(")/g){
print "Found power supply serial: $2\n";
}
}

# get HDD serial numbers
sub curl_ucs_hdd_serial {
my ($cookie) = @_;
print "Getting HDD details from server...\n";
my $curl = `curl -d "<configResolveClass cookie='$cookie' inHierarchical='false' classId='storageLocalDisk'/>" https://$ucsip/nuova -k 2>&1`; # use curl to return login info and redirect stderr to stdout via 2>&1
local $/ = undef;
print $curl;
print "Retrieving HDD serial...\n";
while ($curl =~ /(driveserialnumber=")(.+?)(")/g){
print "Found HDD serial: $2\n";
}
}

# log out of UCS server
sub curl_ucs_logout {
my ($cookie) = @_;
print "Logging out of UCS via web...\n";
# use curl to return login info and redirect stderr to stdout via 2>&1
my $curl = `curl -d "<aaaLogout inCookie='$cookie'/>" https://$ucsip/nuova -k 2>&1`;
print "Logged out.\n";
}

# run the program
print_header();
$cookie = curl_ucs_login_and_get_cookie ();
curl_ucs_chassis_serial ($cookie);
curl_ucs_ps_serial ($cookie);
curl_ucs_hdd_serial ($cookie);
curl_ucs_logout ($cookie);


I hope this serves as a starting point for someone.  It at least demonstrates basic techniques for logging in, retrieving and using the UCS 'cookie', retrieving component information, finding interesting things via regex in perl, and logging off.

If you happen to finish this so all the serial numbers are retrieved, please link to a location where others may benefit from it.

Cisco Unity Connection Single Inbox 401 Authentication Errors - Windows Authentication and NTLM

After setting up a new Unity Connection 9 cluster to integrate with Exchange 2010, I ran into an issue with the authentication failures when running the test on individual Unified Messaging Accounts.  Running the test against the Unified Messaging Service passed, but this typically only verifies basic network access, domain name resolution and access to the Exchange EWS interface.  The Single Inbox feature will fail if the users' Unified Messaging Accounts can't authenticate to Exchange.

The "Unified Messaging Guide for Cisco Unity Connection Release 9.x" integration guide is quite good and covers about all the scenarios I've ever run into. Follow the guide, and all of the guide, and you should be in good shape.

Following that during a pretty typical setup (a single Exchange 2010 CAS server and another 2010 mailbox server with no DAG), I had an issue where testing the Unified Messaging Accounts failed with a "Failed accessing xxx@ayz.com Diagnostic=[] Verb =[] url=[] request=[] response[]" message.  It is a 401 error, pointing to basic authentication against Exchange issues.

Basic troubleshooting steps, found in just about every Unity Connection gude are:

Check the authentication method on both sides. Check settings in Internet Information Services (IIS) for both AutoDiscover and EWS.
- This was confirmed to be NTLM and HTTPS, under both EWS and Autodiscovery

Try different UM messaging account name formats (i.e. NAME, DOMAIN\NAME, NAME@DOMAIN).
- Tried every combination of names
Reset the UM messaging account password, and enter the password again on Unity Connection.
- Verified name and password via OWA
The UM account should not have a mailbox.
- Verified no Exchange mailbox with admin.
- Another nice method to confirm this again using OWA to check the username and password above.  You should be returned an error indicating there is no mailbox for the user.

Ultimately the issue was that assumptions were made that since Windows Authentication was enabled in Exchange in the EWS and Autodiscovery areas, that NTLM was enabled. The names are commonly interchangeable, but if you are not savvy in Microsoft technologies you may not realize NTLM is technically just a provider available under Windows Authentication.

The fix: Once you find Windows Authentication is enabled, you need to verify NTLM is added as a provider under Windows Authentication.

After losing hours checking and rechecking settings in Unity Connection, grepping Unity Connection logs for anything telling beyond the 401 error, rechecking Exchange settings and the service profile user roles, and furious Googling, my only consolation is that there appears to be an abundance of confusion by Exchange admins regarding this topic and how to effectively set it up in various scenarios.

FYI, while bashing around in Exchange looking for clues, we found some errors that look rather concerning.  Microsoft indicates those are "expected behavior".

Nice.