Wednesday 25 February 2009

BIOS Flash Upgrades - Lessons learned

I've been looking to upgrade my main desktop for a little while - it is (was) an AMD-X2 4200+ (Socket AM2 - but that's a different story) on a ASUS motherboard with 4GB Ram running Vista-64bit - very happy it was too. I was looking at possibly moving up to a Phenom at the high end of the scale and for this I needed to flash my BIOS to give it support for the newer CPUs - not been keeping it up to date. So saturday afternoon I decided to do the necessary and flash the BIOS - no big deal, that is until the system wouldn't POST after the reboot - argh worst nightmare, so after trying everything in the manual and that I could find online I admitted defeat.

I am now the proud owner of a Gigabyte motherboard (with dual BIOS chips to allow you to mess up one of them), and an Intel i7 920 - yes change of architecture and I've wondered what I could do with 4 cores hyperthreaded and a potential 24GB of memory (I only got 6).

I am now in the process of re-installing Vista (something I didn't want to have to do, but hey) so here are some of my lessons from this tale:

1. Don't flash your BIOS unless you have to
2. Flash your BIOS before you go and buy that nice new processor
3. Intel processors need more power than AMD processors (did I mention the new 1000W power supply - overkill I know, but my 4 year old 500W couldn't get the thing going)
4. You want to hear only one beep when your motherboard boots - continuous short beeps means you need more power (see above)
5. Vista will not boot if you change the processor architecturedummy
, motherboard, raid controller etc and you will have to re-install.

So that's it - Vista is reinstalling and so will I be for the next few nights. Still I should now be able to really crank up my UC lab with VMWare sessions, and lightroom should fly :-)

Monday 23 February 2009

Agent Targeting Rules - Bye Bye to Device Targets

As a Unified Contact Center Enterprise (UCCE) system increases in size and complexity, in terms of numbers of Peripheral Gateways, IVRs and Agents, there are certain aspects of the system that start to cause more and more overhead in administration. Device Targets are one of these things that grow and grow the larger your system gets. Add another PG, need another label on your existing device targets, add another IVR, need another label on your existing devices targets, and on it goes. Fortunately, as of UCCE 7.1.3, Cisco has provided a mechanism to remove the need for device targets completely (at least for System, CallManager and Generic PGs)

First  a little back to basics, what is the purpose of a device target. It is a way of getting a call from one routing client to another. So in the simplest of systems (taking this to the extreme, ie no IVR), there is a device target with a label with the number of the extension of the agent and a routing client of a Call Manager. The Call Manager uses the information in this label to dial the agent.

Now what if this could be calculated and dynamic rather than a static label. This is where Agent Targeting Rules come in to play, and the best thing is you can implement them on either  new or existing systems without breaking anything (if you go through the below  phases).

So where do I find these Agent Targeting Rules – first, in the release notes for 7.1.3 <CCO Login may be required>,  - they are in Configuration Manager –> Tools –> List Tools.

There are three types of rules (only two of which I have used in a production environment): Agent Extension; Substitution Agent Extension; and Translation Agent Extension (which I haven’t used). All the rules are based on Peripheral, Routing Client and Number ranges (you did design your contact centre with agent phone numbers in nice contiguous blocks didn’t you ? No, well it doesn’t actually matter). The rules do exactly what they say
– agent extensions is used where the full number is dialable from the routing client without modification
- Substitute Agent Extension allows you to prefix the number and select the number of significant digits from the range specified
- Translation Agent Extension – this (I haven’t tested this) allows you to use a translation route between devices (assuming they have already been set up).

Peripheral Gateways can be configured to operate in three modes 
– ignore rules (ie use device targets)
- compare rules but fall back to device target and report an error if the rules are inconsistent with an existing device target
- ignore device targets (rules only – they’d better be right!)

The migration / creation process is this:
- Create Rules
- Change Peripheral Gateways (ICM configuration + restart) to
use “Rules Compare to Existing Device Target mode”
This mode compares the DT to the result generated by the rule, but will use the DT and report an error if the rule is inconsistent. If only the rule generates a label – it is used and no error generated.
- Test and correct rules if required
- Change PG to “Agent Target Mode”
- Delete device targets, if an existing installation (as they are no longer used)

So lets have a simpl(ish) example
Your contact centre has two location with a Call Manager PG at each location, and an IVR at each location, calls come into both Call Manager clusters and are passed onto their local IVR for call treatment. Site A has agent extensions in the range 1000-1999 with a site access code of 441 when dialled from site B. Site B has  agent extensions in the range 2000-2999  with a site access code of 442 when dialled from Site A. To set up this scenario you need the following set of rules (on site A – a similar set of rules is required on site B)
SiteA_Local_Agents
- Peripheral: SiteA_CCM_PIM (the location of the agents)
- Rule Type: Agent Extension
- Routing Client: SiteA_CCM_PIM.RC, SiteA_IVR_PIM.RC (the local Call Manager and IVR)
- Extension Range: 1000-1999

SiteA_Agents_From_SiteB
- Peripheral: SiteA_CCM_PIM
- Rule Type: Substitution Agent Extension
- Agent Extension Prefix: 441
- Agent Extension Length: 4
- Routing Client: SiteB_CCM_PIM.RC, SiteB_IVR_PIM.RC (the remote Call Manager and IVR)
- Extension Range: 1000-1999

And that is it, change the PG configuration and restart it.

I have this in a production environment, so this isn’t just a lab exercise. We have had one issue, there is a bug in 7.1(5) which causes the router to “forget” what it is supposed to be doing (corruption of routing table) – this is fixed with an ES. Other than that they work fine and I’ll be using them all the time from now on.

Bye Bye Device Targets.

Tuesday 17 February 2009

Appliance Based UC Servers – and keyboards

If you live in the US or have a US keyboard attached to your UC server (any of the appliance-based platform - Cisco Call Manager, Unity Connection or Unified Presence Server) then you will never come across this issue. Otherwise, here’s a quick tale of woe – and a doh moment!

I was building a set of Unified Communications Manager servers attached to a KVM in a server room. I was going through the setup entering user names, passwords and shared secrets as normal. I’d then go back to my desk and attempt to log-in remotely using the same user name and password as entered locally – no joy. A bit of head scratching – back to the server room, change the password, back to desk, password works from the desk. Hmm, maybe it’s a new feature to force you to change the password once the system is up! Don’t remember seeing that one in the release notes. Anyway, by the time this had happened to the third server (these were built over a period of months not hours), I was getting a little frustrated. Eventually I worked out the problem by typing the password onto the screen – not at the password prompt – I know I should have done this much earlier, but you forget these things when you don’t do it every day!  - and lo’ (or more accurately  “DOH”), there where my @ should be was a “.  Yes, default (and only) keymap on these servers is US.  Now I used to live in Australia, and when I came back to the UK, I was getting problems typing things for the exact opposite reason (Australia uses US as their keyboard layout – like “Rowter vs rooter”).

So there you have it – lesson of the day – always type a something to the screen if you have any doubts about the keyboard layout (or you just think you are going crazy)!