Thursday, December 29, 2011

Parental control application review - Bluecoat's K9 Web Protection

This may seem a bit off topic, but most IT professionals, who have kids, would or should be dealing with this issue at some point.
As someone that is concerned with his kids internet security, I'd like to mention an application I'm using for that purpose.

That application is called K9 web protection and it is a free tool provided by Bluecoat (, a commercial company that specialize in internet protection for corporate and is making its personal solution available to the public free of charge.

The filtering is based on an online database that is operated and maintained by bluecoat which monitor and classify internet hosts based on their content and credibility. This is not different from other vendors like Websense's master database or Cisco's SenderBase, but as far as I know, those other companies don't have a free solution for parental control. If they do I'd be happy to try and discuss here.

It is free but registration is required and an email will be asked for the license delivery, they don't spam the email so I wouldn't worry about using a special spam mailbox for that. The installation is simple and the license is asked during its progress, a password would also be required and it should not be given to the kids since that's how we keep control on the allowed and disallowed web categories.

Once installed you are presented with the option to allow or disallow categories based on bluecoat's classification, as shown below:

If you decide to customize the settings, there are  many options to choose from, as can be seen below:

Finally, when your child is accessing a blocked category, the following screen is displayed and a bark (K9) sound is heard, you are also being presented with the option to allow this site temporarily or permanently but this option is password protected:

Under the hood, the application is installing a device driver that can probably be tampered with if a techie kid that has administrative permissions is getting blocked by it. if that's the case for you, you probably want to prevent administrative rights for that computer.

By the way, its never too early to install parental control on your child's computer, even a harmless four years old can click on the wrong link.

Tuesday, December 27, 2011

Controlling the CCX script flow based on time and date variables

This post is the second of two that are dedicated to Cisco unified contact center express (UCCXor CCX) scripting. In this one I'll explain how variables can be used for time/date based script control. The first post can be found here. This example was created with a CCX system integrated with Cisco Unified Communication Manager (CUCM) also known as Cisco CallManager.

A common things to do in a UCCX script is to present different option to callers based on the time they are calling. If it's after hours, they should be getting a closed message and the same goes for holidays. Creating a static script behavior that is based on the "time of day" and "day of week" general steps is one way to do that, but it requires script editing whenever there is a change and it requires a script per customer in multiple queue scenario.
Another option is to act based on a database or XML file query, both are valid but require deeper programming skills and premium licensing (for the SQL query option).

There is another option that I have recently used and would like to discuss here. With this option a date variable is defined in the script and compared to other variables (which are also parameters) and the script behavior is determined based on those comparisons. By using parameters, the open/closed hours can be controlled outside of the script from the CCX appadmin interface.

To further explain here is how this can be implemented in order to check for a weekend day and act differently if this is a weekend day.
First define a date variable and call it currentDayTime, make sure it is initialized as D[now] which means it will be set to the current CCX server system time.

This is how it will look in script editor:

Now define two integer variables and set them to be a parameter, those would be used to configure the weekend days. The variables are initialized in the script to 1 and 7 which correspond to Sunday and Saturday, but this can be adjusted to other days since it's a parameter.
The relevant lines in the script editor would look like the following:

In the uccx script use an IF condition to check if the current day is a weekend day and define what to do based on the comparison. Here is how the IF condition would look like:

The xxx.dow method in a date variable represent the day of week in a numeric value of 1 through 7. This IF can be nested to check for public holidays and more variables/parameters for additional functionality. In order to check for the current hour, use the xxx.hod method, which represent the hour of the day in 0 through 23 values.

Clear as mud, right?  :)

Comment if you have questions and I'll be happy to explain.

Friday, December 23, 2011

CCX programming variables and parameters

This is the first of two posts I'm going to dedicate to Contact Center Express programming. This one is going to discuss a fundamental aspect of CCX scripting: variables and variables that are parameters. The second post can be found hereThis example was created with a CCX system integrated with Cisco Unified Communication Manager (CUCM) also known as Cisco CallManager.

This is a basic topic in programming and advanced CCX scripters would probably find it boring, but I'm going to cover it anyway :)

A variable is a memory address which store information that a program is using during its operation, and within a script it can be used to store things like calling number, hour, date and the name of a .wav file to be played. CCX supports many variable types, integers, strings and more.

When a variable is defined as a parameter, the system administrator would have the option to define it outside of the script editor. This is an important functionality because it allows the creation of a generic script that can be used in many situations.

Lets look at an example, the following image shows a script that plays a prompt based on a comparison of the current hour with an integer variable called openHour:

When this script is configure to be an application in CCX admin, the screen will look like the following:

As can be seen, the openHour variable is internal to the application and the administrator cant change its value without editing the script.

In the next example, the exact same script is shown but with the variable configured to be a parameter:

This will change the application config screen to look like the following:

As can be seen, the openHour variable is now exposed to the system admin and can be changed from the CCX admin interface for things like holiday schedule (late opening hour) or temporary extended hours (holiday season shopping support). The grayed out 0 is going to be used as the variable initial value unless the check box near the parameter is selected and a different value is entered in the content field.

The following screen capture shows how the non default screen would look like, as can be seen, the application is smart enough to tell us its an integer type of variable.

That's it on this topic, the next post will be based on this post and expand on date and time based parameters and variables.

Tuesday, December 6, 2011

Installing CCX 8.5 in vmware workstation

Recently, I needed to install Cisco Unified Contact Center Express (aka CCX or UCCX) on a workstation for testing purposes. This post will be dedicated to what it took to get that task completed. This example was created with a CCX system integrated with Cisco Unified Communication Manager (CUCM) also known as Cisco CallManager.

I'd like to make sure that this process is not something you would use to install a production CCX, as vmware workstation is not a supported platform for CCX. For lab and testing its a sufficient.

Back in the windows based CCX (or IP IVR or CRS or UCCX), the challenge was to trick the Cisco customized windows install to think it is being installed on a supported hardware. With the current Cisco Unified Communication products and Cisco's line of servers (UCS), VMware is supported but you still need to use a Cisco provided template which was created for VMware ESXi and not workstation (as I found out later).

The first thing you need is a bootable installation media for CCX 8.5 (or iso image, bootable too), and then you would need the template for it, which is an OVA file that can be downloaded from Cisco. There are various options for the OVA, depending on your install size, but the options apply to production and not to LAB, in LAB the smallest option should be used. In my case I used the file called UCCX_100_agents_v2.0_vmv7.ova .

After downloading the file and since I did that install on a supported VMware product before, I was optimistic enough and tried to create a VM based on that template, the results were:

The attempt was made from the Import/Export menu under VMware Workstation.

The error was not an expected one and I started to research around and found out that OVA is not a supported template for VMware Workstation.

After further investigating and spending an hour trying to create a VM myself and making the install support it, to which the result was always the following failure screen:

And it didn't matter if I used 4 gig of ram or 146 gig of hard drive, the end was always the same. Finally I gave up and googled how to use an OVA in workstation, I found out that there is a way to get it done by using a tool called ovftool. I then downloaded the ovftool, installed it and tried to figure out how can it help me to use the OVA template in VMware workstation.

The ovftool is a command line tool that when trying to see its help screen, a long and very detailed output is displayed. The help was not that easy to figure out but with the help of google and some attempts I realized the syntax was:

ovftool <filename.OVA> <directory_for_vm> or in my case:

C:\VM-Tool>ovftool c:\ova\UCCX_100_agents_v2.0_vm v7.ova c:\vm\

The tool created a directory under my c:\vm which is called:

and in it two files were created:
UCCX_100_agents_v2.0_vmv7-disk1.vmdk (disk file)
 UCCX_100_agents_v2.0_vmv7.vmx (vm settings file)

The created .vmx file should be opened from vmware workstation, configured to boot from the install disk (or iso image in my case) and that was all that the install needed to run smoothly and finish the CCX 8.5 installation.

Hopefully that will save time for someone somewhere, comments/questions are welcome

Additional VMWare related reading: