Cisco has historically advocated separate data and audio/video VLANs. This is a great best practice as it enables Access Control Lists (ACLs) to be easily added at the Layer 3 boundary to control both signalling and media traffic. This has worked well for many years, but unfortunately the proliferation of mobile soft clients, such as Jabber, has somewhat broken the traditional design guidance. Whether it’s due to Jabber deployed on laptops using the wired infrastructure, or on smart phones over wireless, the topological demarcation between the data and collaboration environments has disappeared. This can make it very complex to use traditional VLANs to secure access to core collaboration services; as Jabber enabled devices can roam the Enterprise and often share the same VLAN with non-Jabber enabled data devices. From a security perspective this creates a problem, which the traditional VLAN approach doesn’t really provide a good answer for. What is really needed for modern security conscious collaboration deployments is a dynamic policy based enforcement solution. Hence, it’s a good thing that Cisco Security Technology Group invented TrustSec! For the uninitiated TrustSec is Cisco’s software defined segmentation technology embedded into its network infrastructure equipment. TrustSec uses contextual data about whom and what is accessing the network, and enables role based access using Security Group Tags (SGT) to segment the infrastructure. To learn more about TrustSec please click here. The rest of this Blog discusses a recent Proof of Concept that was put together to demonstrate to partners and customers how a Cisco Collaboration deployment could be integrated into an Enterprise’s TrustSec implementation. The following diagram shows simplified lab topology with the associated functional components. Figure 1 – TrustSec POC Lab Topology Note: Everything described below for Phones is equally applicable to dedicated Personal or Room based Video Systems. One of the advantages of TrustSec is that it allows an organisation to map out their policies for device to device, or device to service communication, and then implement these by the allocation of SGTs to ensure the infrastructure is correctly segmented. As can be seen from the above diagram each element of the collaboration deployment was assigned a different SGT. In the case of the endpoints, Jabber (Emp_Mgd_Assets – SGT20) and Phones (UC_Endpoints – SGT21), the SGTs were allocated upon a successful 802.1x authentication. The core devices (UC_Servers – SGT50) and the Cisco Unified Border Element (UC_Supp_Services – SGT51) received their SGTs based upon static IP address mapping. In a real world scenario additional SGTs might be used due to factors such as topology and availability of additional collaboration services. A key strength of TrustSec is its design flexibility. The basic lab set up only allowed media traffic to pass between the collaboration endpoints and signalling only from the endpoints to the core (Unified CM/IMP) servers. Where appropriate, access was also granted to LDAP and DNS services. The general lab policy was to not allow anything other than collaboration media streams between any access layer endpoints. A summary of the permitted traffic flows is shown below: Figure 2 – Collaboration Traffic Matrix At the time of writing, the specific signalling and media ports permitted were obtained from the latest, Unified CM and Jabber port guides. From a Security perspective, large unsegmented networks are a significant risk. Segmentation helps limit lateral movement in the event of a successful attack and shows compliance with regulatory and audit requirements. Hence, given the requirements for peer to peer and client/server Security Group Access Control Lists (SGACLs) the Nexus 7K, Catalyst 4500 and the Catalyst 3650 switches were enabled as TrustSec enforcement points. This not only allowed for segmentation policies to be created and enabled between the Branch/HQ and the Datacentre (DC), but also within VLANs at the access layer. This is important because in Figure 1 the Jabber enabled Employee Managed Assets share the same VLAN as BYOD Contractor laptops that don’t have Jabber deployed on them. This did not create a segmentation problem because the BYOD Contractor devices were issued with different SGTs. The downloaded policy from the ISE ensured that the Contractors had no access to the core UC Servers in the DC, were isolated from the Phones in the Voice VLAN and also segmented from the Jabber clients that shared the same network. In keeping with traditional best practice the POC phones were allocated their own Voice VLANs, and as mentioned previously, 802.1x authentication was used to allocate the appropriate SGT. This is undoubtedly the most secure approach but it is also possible to statically map Voice VLANS to a SGT, if for any reason, an organisation was unable to implement Network Access Control (NAC) for either phones or video endpoints. In the lab the UC Supplementary Services (SGT=51) category was represented by a Cisco Unified Border Element Session Border Controller (SBC). In reality additional supplementary services could be provided by other types of devices such as MCUs and DSP farms. These could either be distributed across the infrastructure or centralised in datacentres depending on the system design. In the POC it was decided to give supplementary devices, such as Cisco Unified Border Element, their own Security Tag so that their individual signalling requirements to and from the core collaboration servers could be appropriately locked down. Figure 3 – Looking at the Bigger Picture Figure 3 shows the addition of three different classes of data application servers. The Collaboration SGACLs, with their implicit deny statements ensured that Phones and Jabber devices could not access these servers.  Even though a Jabber client shared the same VLAN with a BYOD Contractor laptop that had been granted permission to connect the application server types; TrustSec policies enforced the correct segmentation. Part 2 of this Blog will provide the configuration details associated with the lab, including 802.1x settings, details on the ISE TrustSec deployment and the SGACLs used for the Collaboration signalling and media. In the meantime if anyone has any questions or comments, please feel free to post them. ... View more

I'm a believer! I've seen Spark grow from an internal proof of concept into a rapidly evolving business tool that really does change the way organisations collaborate with their customers and partners. For me the true power of the cloud is that it breaks down the inter company and business to consumer barriers that have previously existed with traditional on premise solutions. In my opinion this is interesting because as important as internal productivity is, most Enterprises will be more successful by communicating better with the people who buy from them, or help them take their products/services to market. One of the activities I’ve been engaged upon to help my colleagues “learn” more about Spark is the production of a number of short “home-made” video demonstrations. My aim has been simply to showcase new client and platform capabilities as they become available. They have been pretty well received by my teammates so I thought they might also be of general interest to a wider community. With that said I’ve posted the content I’ve created this far and will use this blog to add additional videos as they become available. I’m also happy to take requests and will either endeavour to deliver a demo, or provide a valid reason why I can’t. So here goes: Using the Spark Calendar Connector The Calendar Connector hybrid service integrates into Exchange to allow users to easily create Spark rooms and schedule WebEx meetings from their calendars. Video Link : 14808 Spark Instagram Integration via IFTTT It is now possible to use Spark APIs to integration our Team Rooms with Enterprise business applications. Check out the developer site to learn more. All you need is a Spark login. As well as custom developments Spark also allows a multitude of “out the box” integrations with well know consumer applications. The video below shows how easy it is to connect into the Instragram community! Video Link : 14754 Spark Box Integration This video shows how I can share files from Spark even when I’m mobile. The Box integration is fully integrated into the Cisco service. Video Link : 14755 Spark Important Filter The Important Filter has been designed to overcome any potential noise that is generated when participating in a large number of team rooms. In reality not all conversations are equal. By marking team rooms are Important it allows a user to rapidly navigate to their priority content. Video Link : 14756 Spark Mentions Using the @Mention feature of Spark provides a way to directly reference an individual within a Team Room. This then allows that person to be visibly notified that somebody is directing a comment, content or a question straight to them. Video Link : 14757 Spark Searches One of the foundational principles of the Spark services is that it is fully encrypted end to end. This actually makes searching for historical content while maintaining security actually quite challenging. The good news is that Spark offers great searching capabilities while still maintaining security. Video Link : 14758 ... View more

Cisco WebEx Meeting Server (CWMS) is Cisco’s on premise web conferencing platform and evolved from our SaaS based Cloud service, which has a similar look and feel. Architecturally, CWMS has a number of components that sit behind an organisation’s firewall, which perform administrative, management and conferencing functions. Depending on the system sizing and redundancy design, these reside on one or more Virtual Machines (VMs). The system also has an Internet Reverse Proxy (IRP) capability that normally sits in the DMZ; like the internal CWMS elements the IRP function will be comprised of one or more VMs. To facilitate authentication and encryption of the various platform services CWMS will install with a self-signed SSL certificate. In today’s security conscious world the best practice recommendation is to always use an Enterprise or Public CA signed certificate and this of course also applies to the WebEx Meetings Server. I think it’s truthful to say that the guidance on how to create a CWMS SSL certificate has historically been a bit hazy, so I’ve written this blog to help you craft a valid SSL certificate for single and dual datacentre deployments. To get started let’s take a look at an example CWMS deployment for a company with a domain called acme.com. Before CWMS 2.5 MR5: Figure 1 – Example CWMS Deployment Each of the VMs that make up the CWMS deployment has a Fully Qualified Domain Name (FQDN) and there are also URLs that provide web access to the Administration pages and Conferencing service.  For example, in the drawing above the FQDN for the two CWMS servers in the internal network are dc1-cwms-pri.acme.com and dc1-cwms-ha.acme.com. The system URLs (that map to Virtual IP (VIP) addresses) are https:\\conf-dc1.acme.com and https:\\conf-dc1-admin.acme.com and these point to the web meetings service and web administration service respectively. The IRP VMs will also have FQDNs, but as we’ll discuss further a little later on these are not relevant with respect to the SSL certificate creation. The two types of generic certificates supported by CWMS are wildcard and multi-server. Wildcards provide the flexibility to simplify the certificate configuration, as long as all the system elements reside in the same domain, down to a single entry in the Common Name (CN) field (e.g. *.acme.com). Although in my experience most Enterprise security teams I’ve encountered would not normally countenance the deployment of wildcards. The preferred option is to go with a multi-server certificate approach, so let’s see how we tackle this. From a CWMS perspective the first thing we do is to choose whether we will use an Enterprise or Public CA to sign the system’s SSL certificate. If no one outside your organization will ever use the platform then you can use, if you have one, your Enterprise CA to sign the certificate. As long as the root certificates (for your CA hierarchy) are in the trusted root stores of your conferencing clients everything will work well. However, if you want to invite people from outside your company to join conferences, the advice is to use a Public CA to sign the SSL certificate. This avoids those nasty browser security warnings that your external guests will hate. Once we have chosen who will sign the certificate the next thing we need to determine is what we put into the CN and Subject Alternate Name (SAN) fields. The best way to do this is to use a couple of examples. Let’s start by looking at a single datacentre deployment that has redundant CWMS and IRP VMs. Figure 2 – Single Datacentre Certificate Example Once you have examples of the CN and SAN entries it is quite easy to determine how to create the Certificate Signing Request (CSR). You use the main service URL for the CN and the SAN field is made up of the FQDN of all the internal VMs and both the service and admin URLs. The notable exception is the absence of the IRP FQDNs. This is because these servers will never been accessed directly via their FQDN. Since the release of CWMS 2.5 we’ve had the ability to deploy a redundant dual data centre configuration, so let’s look at how this affects the SSL certificate. The answer actually turns out to be quite straight forward. We just double up on certificates! Figure 3 – Dual Datacentre Certificate Example If you have read the literature on the redundant datacentre model then you will know that we use Common URLs to globally identify the admin and conference URLs, with each datacentre still retaining locally significant URLs. To create each datacentre’s SSL certificate we can legally use the global conferencing URL in the CN and then add the datacentre specific FQDNs and URLs (including the global ones) into the SAN field. Remember that we don’t add the IRP’s FQDNs. For the acme.com example this will give us the SSL certificate format shown above. Are we finished? Well not quite. As I stated above we can legally use the global conferencing URL in each datacentre’s certificate CN, which I’ve seen deployed, but this is not actually best practice when we want to also secure the audio conferencing function using encryption. Figure 4 – CN Requirement for Secure Audio Conferencing In the case where we plan to secure audio conferencing we cannot use the global conferencing URL as the CN entry for both datacentre certificates. The reason for this is that CUCM treats certificates with the same CN as the same certificate and will overwrite the first uploaded certificate with the second one, so you will never be able to create a secure TLS trunk with the datacentre whose certificate you uploaded first. For this reason and to ensure you have complete flexibility on how you can trunk to your CUCM deployment, you should use the locally significant conferencing URL in the CN of each datacentre’s SSL certificate. One of the common questions I’ve received is can we use a single SSL certificate for both datacentres? The short answer is no. The current CWMS administrative interface does not allow you to create a single certificate, and if you think about it having two separate certificates is a good thing from an operational perspective. Two certificates enable you to make changes to the certificate of one datacentre without disruption to the operations of the other one. I’ve not gone into the detail of how to generate the Certificate Signing Request, but once you understand what elements of the system need to be included in the CN and SAN fields you can use the CWMS manual to guide you through the GUI CSR process. Hint: To make life easier the GUI actually pre-populates the SAN entries for you. From CWMS 2.5 MR5: In MR5 the SSL certification has been split into two. We now have a separate SSL certificate for the web conferencing service and an internal SSL certificate for the other components of the system. This allows us to use a Public CA for the web conferencing URL and either a self-signed or Enterprise CA signed certificate for the other elements. This change increases overall security of the system as it means none of the system’s FQDNs or its admin URL needs to be exposed outside of the organization. It also allows internal domain names, such as “.local”, to be used without causing issues when using a Public CA. Figure 5 – Single Datacentre Split SSL Certificate Example In the diagram above I’ve shown the resulting CWMS 2.5 MR5 certificates for a single DC deployment. A point to note is that the CN for the internal system SSL cert will now be the local admin URL, whereas in previous versions the system used the conferencing URL. When we apply the changes introduced in MR5 to the dual datacentre deployment model we now end up with four SSL certificates. Two internal and two used for the conferencing URL. I’ve shown a representation of this for acme.com below: Figure 6 – Dual Datacentre Split SSL Certificate Example To guarantee we can always support encrypted audio conferencing with CUCM we ensure that the CN of each datacentre’s Internal System SSL certificate is different. In the example above it is conf-dc1-admin.acme.com and conf-dc2-admin.acme.com for dc1 and dc2 respectively. Using the above guidance for pre and post CWMS2.5 MR5 dpeloyments you should now be able to create the necessary SSL certificates for the system. My advice would be to double check the release notes of any subsequent versions of CWMS to ensure no additional SSL certificate related enhancements have been made since this blog was created. However, once you’ve digested the contents of this document, understanding future incremental changes should be much easier. ... View more

Over recent years there has been a massive proliferation of the use of smart phones within the Enterprise and one of the accompanying trends has been to adopt a BYOD (Bring Your Own Device) strategy. There are some pros and cons with using personal devices for business but I suppose these are almost irrelevant as BYOD looks like it’s here to stay for the foreseeable future. From an IT perspective that leads to the fundamental question of how am I going to manage my corporate applications? The current answer seems to be either using MDM (Mobile Device Management) or alternatively MAM (Mobile Application Management). Although having said that, Cisco is also a member of the new ACE (Application Configuration for Enterprise) forum that is promoting secure configuration of applications via standard APIs available within IOS and Android for Work. For more information I’ve provided the link below: http://www.appconfigforenterprise.org/ Look out for Cisco UC client ACE support in the future. With respect to this blog we’re going to take a high level look at the MAM approach and how it currently relates to Cisco’s Jabber and WebEx clients. Before we do that let’s quickly discuss the reasons why MAM might be used instead of MDM for a BYOD deployment. MDM policy enforcement applies to the entire phone, these policies can include SSID lockdown, content wiping and GPS location tracking. Such capabilities in the hands of IT may be acceptable for corporate owned phones but for some end users who have spent their own money on a device, which they also use for their personal lives, this may prove too intrusive. Hence, the rise of MAM, which provides secure compartmentalization for corporate applications and the ability to manage these without impact to the end user’s personal applications and data. Resultantly, Cisco has received a number of customer requests asking if it is possible to use a third party MAM product to wrap Jabber and WebEx clients. The act of “wrapping” is simply the term used to describe the process of packaging an application for deployment and management by the MAM solution. Take a look at the simple diagram below that outlines the generic wrapping procedure for Jabber and WebEx clients. At the time of writing, if you want to wrap a Cisco UC client the first thing you need to do is to sign a MAM agreement. Cisco will then provide a copy of the unsigned client; this correctly implies that you cannot “wrap” code that is downloaded straight from a public App Store. You then follow the MAM vendor’s “wrapping” process, which digitally signs the Cisco software with the appropriate Enterprise Application key. Post deployment, Jabber and/or WebEx clients will be stored in a secure MAM container partitioned off from the end user’s own personal data and applications. This then allows IT to securely manage the Cisco clients on the BYOD device. The specific management functions will vary by MAM manufacture, but wiping the corporate applications (without removing user data) would be an example capability. Sounds simple? In reality there are a couple of things to consider: 1) Application “wrapping” Cisco UC clients is still in its infancy and there are currently no formal test documents or “how to” guides published by Cisco engineering on this topic. 2) Although Cisco engineering will do their best to help a customer or partner use their chosen MAM vendor to “wrap” Jabber and the WebEx clients, there is no formal TAC support. The comment about TAC support is important. The “wrapping” process invalidates support, so any issue would need to be reproduced on a “non-wrapped” version of the client before troubleshooting could commence. Mobile Application Management looks like it will become increasingly prevalent, whether it’s based upon application “wrapping” or native phone APIs. If you are interested in a Jabber/WebEx MAM deployment my advice is to work closely with your Cisco Collaboration Specialist to obtain an unsigned version of the clients, but most importantly, make sure you fully understand the support position. ... View more

Has anyone taken a look recently at our newly revamped Cisco Developer site? https://developer.cisco.com/collaboration It’s been greatly improved and is much more developer friendly, with code examples and even a free sandbox capability that makes it really easy to get started. If you have any software developers in your organization I suggest you get them to check it out. Embedding Cisco technology into web applications or creating your own Cisco based software solutions to support innovation and business productivity has never been easier. As a result of Cisco’s increased focus on supporting our development community, I’ve seen a recent surge in activity from a number of EMEAR based Collaboration focussed ISVs, who have started to use our Jabber SDK to help their customers do things differently. A good example of this is the Jabborate proposition from a company called Bulpros. In simple terms these guys have provided integrated access to Cisco’s collaboration portfolio from a number of industry standard business applications such as IBM Connections, Microsoft SharePoint and most recently SAP. From a high level perspective the Jabborate solution is a JavaScript client that can run in a common browser without the need for a dedicated local Windows for Jabber client. This provides customers with an option to simplify their desktop deployment model, while still retaining important communications features such as Presence, Instant Messaging and Audio/Video calling. For any customers that wish to deploy the traditional Jabber for Windows experience, Jabborate can be configured as middleware to integrate supported business applications with the standard client. Sounds interesting? Have a look at the following simple video demonstration: Video Link : 13296 You can find more details about the Bulpros solution on the Jabborate web site: http://jabborate.com/ One of the things that most impressed me about the new Cisco Developer site is that there is a ton of learning labs available, so if you’re new to a particular technology you can access a tutorial and get some online education. This coupled with the previously mentioned Sandbox function should make it simpler to create your own applications. Some more good news is that our Developer Community is free to join and also offers free support. If you want to further investigate driving innovation though software development on Cisco’s open platform, then why not take a moment to join Cisco’s Developer Community and benefit from a deeper look! https://developer.cisco.com/site/devnet/overview/ ... View more

I recently wrote a blog discussing the Value of Medianet in which I listed the benefits and associated costs of adoption. Remember that in simple terms Medianet enables a granular QoS policy and also provides a systematic approach for video troubleshooting. In this article I’m going to provide an example of Medianet in action as it has been my experience that most people, at least initially, struggle to visualize the impact Medianet has on the day to day operations of a Cisco collaboration solution running over a Cisco networking infrastructure. In my previous blog I said that “Medianet reduces operational support costs”. I’m now going to attempt to show you how. The first thing we can enable is edge monitoring, which allows the IT team to centrally check upon the health on any given endpoint and also ascertain its call status. Take a look at this video below: Video Link : 11366 As useful as it is, end point monitoring is only of limited benefit when problems start to occur. Electronic confirmation of what impacted end users are seeing is not what is actually required. We need a way to proactively troubleshoot issues as soon as they appear. The combination of Medianet enabled applications communicating with a Medianet enabled network, which is overseen by an intelligent management application is the means by which Cisco provides this. Let’s assume there is an executive video conference taking place and the attendees start to experience a quality issue. How would your IT organization isolate the root cause of the problem in real time? The good news is that in a Cisco Medianet environment as soon as pre-configured error thresholds are exceeded the system can begin to automatically troubleshoot itself. This means the impacted executives don’t even need to alert IT to get someone looking at the problem; in reality it is conceivable that the support team could proactively call the relevant conference rooms and reassure the meeting attendees that troubleshooting is already in progress. Having historically worked in a support role I personally know that this type of unsolicited communication is usually very appreciated by end users. Now let us look at how we use Medianet to identify the problem: Video Link : 11367 When we logged onto the Cisco Prime Collaboration platform, it was immediately obvious there was a video conference in session with associated alarms. The Medianet troubleshooting process had automatically begun because configured packet loss and jitter thresholds were breached. When we navigated to the troubleshooting page it was easy to identify the source of the problem using an endpoint initiated trace that: • Provided a graphical view on the exact path the video media took across the network • Took into consideration the bi-directional nature of the video media • Displayed specific hop by hop error statistics and DSCP mapping information for the monitored video conference In the video we quickly identified that we were dropping packets and had increased jitter on the link between two of the routers. In a real life situation the support team would then probably: 1) Verify the integrity of the connection between the two routers. 2) Troubleshoot the QoS bandwidth settings on the impacted router interfaces Without the above troubleshooting capability this issue could have taken days of investigation to isolate but it now only takes minutes and at the same time the IT organisation can confidently inform their customers they are in control of the situation. The value is clear to me; the cost of human resources normally makes up most of the operational budget so any toolset that saves a large amount of time has a hard return on investment. A soft benefit is that the IT organisation will see a positive impact on the video service adoption when they can demonstrate their ability to operate a robust platform. I’d like to end with a question, if you operate a Cisco switch and router network and have (or are planning to) deploy Cisco collaboration applications or video end points; are there any reasons why you would not investigate using Medianet to reduce your operation support costs? ... View more

Is interactive video an important business tool for your organisation? If yes, then read on. Medianet is an architecture that Cisco often talks about and it seems like it’s been around for ages (well 5 years to be exact), but its true value is often obscured by complex diagrams and techno speak that Cisco engineers (like myself) love. So what exactly is the benefit of EX90 TE6 MSI firmware delivering Medianet metadata to an Access Layer Catalyst 4500? How does the combination of MSI, metadata, perfmon and Mediatrace save you time and money? Unless you have a degree in Cisco acronyms this might be hard to answer! What I’m going to attempt in this short blog is to try and translate the Medianet architectural jargon into the potential cost savings that Medianet offers customers who deploy our video endpoints and applications over a Cisco switch and router network. As nothing in life is free, I’ll also list out the main costs associated with deploying Medianet. In simple terms a Medianet aware application or end point will advertise itself to a Cisco network even if it is natively encrypted or tunnelled in HTTP/S. This gives the network complete visibility of any composite audio, video and data flows that resultantly traverse the infrastructure from the endpoint or application. Ignoring all the engineering behind the scenes this results in savings for an organization: Medianet reduces operational support costs A common challenge with large scale video deployments is the day 2 support. It’s often the case that the operations team has to deal with intermittent quality issues on video calls and are left with the difficult task of troubleshooting. Historically, the approach has been for the video team to gather stats from the end-points with the network team doing likewise from the infrastructure. Then someone has to sit down in a quiet room to try and work out what is happening. This process can take many hours if not longer; so what happens if there are multiple incidents reported simultaneously in different parts of the organisation. Are these linked or separate issues? All of this can lead to the operational team being overwhelmed and may force drastic remedial actions such “throwing bandwidth” at the problems, which is an unplanned cost. Or worst case may result in the removal of the video service completely, which then wastes the original capital investment. The benefit of Medianet is that it connects Cisco video applications and Cisco infrastructure to a management platform to simplify the task of end to end troubleshooting. Support staff can now trace video quality issues from a centralised console to generate a graphical report which will show them exactly where in the network packet loss is occurring, where the Jitter is too high or where the QoS mapping is misconfigured. No more manually collecting statistics and reading through command line logs looking for errors! Thus the automation of the video troubleshooting process saves a huge amount of support staff time, which is a tangible cost saving and also allows IT to effectively resolve issues. Medianet can control video bandwidth costs Isn’t the cost of bandwidth falling? The issue is that the demand for bandwidth, driven by interactive video, is increasing at a faster rate, so in real terms the cost of bandwidth is rapidly increasing regardless of any reduction in tariffs. The ability to effectively troubleshoot a large scale video deployment can mitigate the need to mask intermittent video issues by bandwidth oversubscription, which is a cost saving in its own right. But the real way to be able to control bandwidth costs associated with video is to make the video traffic easily identifiable so that IT departments can determine which video flows are mission critical and which ones are not. Medianet does this by providing granular differentiation between such applications as Jabber, WebEx and Telepresence. This then allows an organisation to make an informed decision as to whether the cost of a bandwidth upgrade is justified. Such an approach allows the network to be “Right Sized” based upon business priorities rather than “Over Sized” to cater for all video types. Medianet can utilize redundant paths for less critical business video When an IT department “Right Sizes” their network there may be some types of video traffic (such as Jabber video) that are not deemed business critical “enough” to justify large scale bandwidth upgrades. Without Medianet this would probably mean that these lower value services could not be offered. Medianet provides an Enterprise with additional options. For example, a Jabber client can inform the network which of its packets are video and which are audio. This allows the infrastructure to mark the video so that it only receives best effort quality of service. Or more interestingly, it is actually possible to break out the Jabber video traffic and use policy routing to send it via an alternative path through the infrastructure. One scenario might be for a branch office where Jabber video traffic could now be forwarded across a low cost redundant link such as a VPN broadband connection; while data, Jabber voice and mission critical video (such as Telepresence) would be routed across the site’s primary, QoS enabled connection into the corporate network.   Even if the benefits of the Medianet enabled network look interesting an organization will need to understand the deployment costs before it can make any informed decisions on whether to enable this technology. The potential costs associated with Medianet are: Equipment Upgrades – Hardware and Software The first thing the network team needs to do is to ascertain if their current infrastructure is Medianet ready or whether Hardware and/or Software upgrades are required. The good news is that Medianet does not need to be turned on across the entire network overnight. It can actually be applied to “hot spots” in the infrastructure where issues regularly occur (such as WAN routers), or where improved traffic visibility will provide the most return for the investment in terms of improved bandwidth planning. Over time Medianet can be rolled out across the network as part of planned software upgrades or hardware refreshes. Network Management Application Deployment It is actually possible to use Medianet’s tool set from the network’s CLI but it’s more practical to use a network management application such as Cisco Prime Collaboration. There are also a number of third party vendors who support Medianet. The question to ask is whether your existing operational management platform is Medianet aware and if not how much it will cost to enable it, either via a software upgrade or by the addition of a new management application? Resources required for Medianet implementation To roll out Medianet onto the Network will require engineering effort to perform any necessary upgrades and also to develop and test the configurations for the different types of switches and routers that are deployed in the infrastructure. Once this has been done most organisations will use some form of automated deployment tool or script to push the configurations to the individual devices. Thereafter engineers will need to run through a test plan to ensure the new Medianet configuration has been deployed successfully. Training Budget should also be set aside for training staff (depending on their job role) on the implementation and support of a Medianet enabled network. The ability to troubleshoot intermittent service impacting issues, coupled with the ability to conduct accurate bandwidth planning and the means to simply provision QoS based upon metadata will result in a stable video service that provides a consistent quality of experience to the end user community. This should result in soft benefits such as good service adoption and the desired improvement in productivity the video solution was deployed to enable. For most organisations calculating the costs of implementing Medianet will be relatively straight forward but what’s the cost of not being able to effectively troubleshoot or capacity plan an evolving video deployment? Any organisation that is looking to roll out either dedicated video endpoints or video enabled desktops needs to have a clear strategy on how they will fix incidents in a timely manner and also keep a close watch on their bandwidth utilisation in order to control costs. Medianet is Cisco’s preferred option for this; what are the alternatives? ... View more

Jabber supports a Notes Calendar integration which allows appointments created in the IBM client to be viewed in the Cisco client’s Meetings Tab. Jabber will also use Notes calendar entries to change the user’s presence status to “In a Meeting”. Figure 1 – Notes Calendar Jabber Integration The calendar integration is really simple to enable as it just requires the end user to select the Notes integration from the File>Options>Integration menu Figure 2 – Enabling the Integration One point to note is that this useful feature is subject to the Notes email client’s API security policy and by default each time you start the Jabber client you will be prompted to authenticate with the Notes calendar API. Take a look at this video. Video Link : 10865 Here is an example of the Notes Calendar API authentication challenge shown in the previous video. Figure 3 – Notes API Password Authentication Some organisations may choose to live with these additional authentications as this is how the Lotus Notes calendar API behaves by default, but others may want to look at their options to minimise the number of passwords end users need to type. The following discussion is based upon testing I conducted in my lab and I am sharing the results as observed. If anyone sees different behaviour or disagrees with my conclusions please feel free to comment as necessary. My lab environment was based upon Notes 8.5.3 and Jabber 9.2 on my Windows 7 desktops and Domino 8.5.3, which was used for the backend. After a basic install each client (Notes and Jabber) requested its own username/password combination to start up. The first change I made to my default Notes client was to locally enable “Don’t prompt for a password from other Notes-based programs (reduces security)”, this parameter can be accessed from File>Security>User Security as shown in the short video clip below. Video Link : 10866 My testing results showed that enabling the “Don’t prompt for a password from other Notes-based programs (reduces security)” parameter decreased the number of authentications required for the Jabber integration with the Notes calendar API. I have tabulated my results: Notes Jabber Scenario Details “Don’t Prompt” = Off “Don’t Prompt” = On Started before Jabber Started after Notes Neither Notes nor Jabber were running on my desktop. I started the Notes client first; I entered in the Notes password to authenticate. Then loaded the Jabber client, I entered the Jabber password when prompted. Calendar API Password Required Calendar API Password not Required Started after Jabber Started before Notes Neither Notes nor Jabber were running on my desktop. I started the Jabber client and authenticated with my Jabber password. Then I loaded Notes and authenticated using my Notes password. Calendar API Password Required Calendar API Password Required Notes Client Online Restart Jabber Both clients were running on my desktop. I restarted Jabber and authenticated with my Jabber password when prompted. Calendar API Password Required Calendar API Password not Required Restart Notes Jabber Client Online Both clients were running on my desktop. I restarted Notes and authenticated with my Notes password when prompted. I also tested starting Notes from the “Meeting Details” option within Jabber. Calendar API Password not Required (This includes clicking the “Meeting Details” option in the Jabber Calendar). Calendar API Password not Required (This includes clicking the “Meeting Details” option in the Jabber Calendar). Note: The password requirement in the above table relates to the Notes Calendar API authentication depicted in Figure 3 and not the Jabber/Notes password required each time the client is launched/re-started. The “Don’t Prompt” columns equate to the “Don’t prompt for a password from other Notes-based programs (reduces security)” security setting. Just for interest I also tested setting the “Don’t prompt for a password from other Notes-based programs (reduces security)” parameter via a Domino explicit policy configuration. From the research I’ve done my understanding is that IBM introduced the “Don’t prompt” policy field from Domino version 8.5.3+. I captured a short video from my Domino Administrator client to show you where to find the setting: Video Link : 10867 In my lab once I had created the Jabber for Notes Security settings document and added it to an explicit policy I assigned it to a test user “Steve Smith”. In your organisation you would add the policy setting to any Notes users who also ran the Cisco Jabber client. The final change I made to my lab was to look at the impact of linking the Notes email login with that of the Windows operating system. This IBM feature is known as Shared Login, which ties in Notes authentication with my Windows login. Just like the previous Security Setting configuration, I implemented Shared Login via Notes Policy from my Domino Administrator: Video Link : 10868 After enabling Shared Login I retested and it appears that the Notes Shared Login configuration (with or without the “Don’t prompt” policy enabled) completely removes the requirement to authenticate Jabber against the Notes calendar API. For reference I captured the scenario where I start Jabber before I start my Notes client as for all previous test cases this scenario had always required me to authenticate: Video Link : 10869 Here are my results table for Shared Login: Notes Jabber Scenario Dateails Shared Login (“Don’t Prompt = On/ Off”) Started before Jabber Started after Notes Neither Notes nor Jabber were running on my desktop. I started the Notes client first; there was no need to enter a password due to the shared login config. I then loaded the Jabber client; I entered the Jabber password when prompted. Calendar API Password not Required Started after Jabber Started before Notes Neither Notes nor Jabber were running on my desktop. I started the Jabber client and authenticated with my Jabber password. I then started the Notes client; there was no need to enter a password due to the shared login config. Calendar API Password not Required (Assumes Jabber and OS password are the  same) Notes Client Online Restart Jabber Both clients were running on my desktop. I restarted Jabber and authenticated with my Jabber password when prompted. Calendar API Password not Required Restart Notes Jabber Client Online Both clients were running on my desktop. I restarted Notes; there was no need to enter a password due to the shared login config. I also tested starting Notes from the “Meeting Details” option within Jabber. Calendar API Password not Required (This includes clicking the “Meeting Details” option in the Jabber Calendar). I would very much appreciate it if anyone can provide feedback as to whether they observe the same client behaviour when Shared Login is enabled? I am also happy to update this blog if anyone has any input on other Notes authentication or SSO options and how they specifically impact Cisco Jabber’s interaction with the Calendar API. ... View more

Introduction Cisco has provided client side plug-in integrations for the standalone and Notes integrated versions of Sametime for many years. The newest Cisco plug-in “CUCI-IBM-Sametime” adds, amongst other features, an Audio/Video softphone, which makes it easy to establish communications with other telephony and video devices. As interest grows in an integrated companywide Unified Communications platform that uses Cisco plug-ins to link the IBM and Cisco domains together at some point the following question will arise; “how do we actually roll out Cisco plug-ins”? During most proof of concepts the plug-ins are usually manually installed, client by client using the local plug-in installation options, but this is clearly not practical for a production environment. Thus, the aim of this informal document is to walk you through a mass deployment example for the two consumption models for Sametime: Lotus Notes configured with an integrated Sametime sidebar. A standalone Sametime Connect client Note: This application note relates to the client side plug-ins that are available from Cisco Connection Online (CCO) but does not cover the installation of the WebEx Sametime plug-in, which is deployed using WebEx Productivity Tools. Two Different Approaches The Cisco Sametime plug-ins are deployed differently depending on whether your organization uses the standalone Sametime Connect client or utilises Sametime from the integrated Notes sidebar. The two deployment examples highlighted in this document either use Domino or Sametime Server management tools. Note: The two laboratory tested deployment scenarios in this application note are intended as an unsupported guide for customers and partners and the information presented comes for laboratory testing. As the IBM tools described later in this document are intended for generic IBM and 3 rd party plug-in roll outs, any specific functional and troubleshooting questions about these tools should be addressed by your IBM support team. The two approaches identified by this document are not necessarily the only mechanisms available to deploy 3 rd party (Cisco) plug-ins into a Sametime environment. Experienced IBM administrators may recommend alternative approaches more suited to their own customized environment. The IBM SW versions used for testing were: Domino 8.5.2, Notes 8.5.3 and Sametime 8.5.2. Notes Integrated Sametime Sidebar The tested deployment approach for integrated Sametime clients is to utilise Notes widgets to centrally roll out the Cisco plug-ins. There are a number of widget definitions available on the web but in the context of a Cisco plug-in a widget is simply a XML file that references a plug-in (for example, CUCI-IBM-Sametime) and also includes additional informational elements such as the plug-in version number. Sample widget files are provided later in this document. An overview of the deployment process is shown below: Figure 1 – An Overview of the Deployment Process The steps used in the test lab to push the Cisco plug-ins to the lab clients were as follows: Step A – Configure the Cisco Plug-in The client side plug-ins that are downloaded from CCO ship with a configuration utility that is used to set the parameters required for the customer’s specific Cisco and Sametime environments. Detailed configuration guidance can be found here: http://www.cisco.com/en/US/partner/products/ps12774/tsd_products_support_configure.html Step B – Upload the Cisco Plug-in to the Domino Eclipse Update Site Domino 8.X provides an Eclipse Update site template that allows you to create a NSF-based plug-in store for the Cisco (and any other) plug-ins. The instructions that explain how to initialise the plug-in repository are provided here: http://publib.boulder.ibm.com/infocenter/domhelp/v8r0/index.jsptopic=%2Fcom.ibm.help.domino.admin85.doc%2FH_CREATE_IMPORT_NSF_UPDSITE_STEPS.html By following the steps provided in the Domino documentation you will be able to upload your configured plug-ins as shown below. Figure 2 – Importing Plug-ins to the Update site In the lab example shown above, it can be seen that CUCI-IBM-Sametime uploads as two separate plug-ins, one listed as Phone Control and Presence and the second as Unified Messaging. This is the same naming convention as the older (non Client Services Framework) enabled plug-ins, but you can identify the CUCI-IBM-Sametime plug-in by its 9.X (or above) version number. As there are two plug-ins in the update store, two Notes widgets are created in Step C to install each plug-in separately. Step C – Create the Cisco Plug-in widget’s XML file The following Cisco plug-in widget file was used for the CUCI-IBM-Sametime Phone Control element. In the Cisco lab environment the XML widget files were stored on the Domino server in an appropriately named windows folder. The text highlighted in bold is specific to the lab configuration: <?xml version="1.0" encoding="UTF-8"?> <webcontextConfiguration version="1.1"> <palleteItem id="com.cisco.sametime.phone.featurest800" imageUrl="" providerId="com.ibm.rcp.toolbox.prov.provider.ToolboxProvisioning" title="cuci-ibm phone control" url="nrpc://hyde.stlab.net/__802579b400578e10/site.xml"> <preferences> </preferences> <data> <installManifest> <![CDATA[ <install> <installfeature description="cuci-ibm phone control" id="com.cisco.sametime.phone.featurest800" name="cuci-ibm phone control" required="true"> <requirements>   <feature id="com.cisco.sametime.phone.featurest800" version="9.0.1.215"/> </requirements> </installfeature> </install> ]]> </installManifest> </data> </palleteItem> </webcontextConfiguration> The information required to customize your XML widget is easily obtained from the Eclipse Update Site. Figure 3 – Identifying the XML file’s plug-in settings The “cuci-ibm phone control” text is simply an administrator defined label and is used in the “title”, “Installfeature” “description” and “name” fields. For completeness the CUCI-IBM-Sametime Messaging widget is shown below: <?xml version="1.0" encoding="UTF-8"?> <webcontextConfiguration version="1.1"> <palleteItem id="com.cisco.sametime.voicemail.feature" imageUrl="" providerId="com.ibm.rcp.toolbox.prov.provider.ToolboxProvisioning" title="cuci-ibm messaging" url="nrpc://hyde.stlab.net/__802579b400578e10/site.xml"> <preferences> </preferences> <data> <installManifest> <![CDATA[ <install> <installfeature description="cuci-ibm messaging" id="com.cisco.sametime.voicemail.feature" name="cuci-ibm messaging" required="true"> <requirements>   <feature id="com.cisco.sametime.voicemail.feature" version="9.0.1.211"/> </requirements> </installfeature> </install> ]]> </installManifest> </data> </palleteItem> </webcontextConfiguration> Step D – Add the Cisco widget to the Domino Widget Catalog Domino 8.X supports a native Widget Catalog which can be created using the following IBM documentation: http://publib.boulder.ibm.com/infocenter/domhelp/v8r0/index.jsptopic=%2Fcom.ibm.help.domino.admin85.doc%2FH_CREATING_A_TOOLBOX_CATALOGUE_OVER.html Figure 4 – The Domino Widget Catalog When you add each widget to the Domino catalog you will be taken to the following screen. Fill out the title and description and add the XML file as shown below: Figure 5 – Adding a Cisco Widget to the Catalog An important administrative consideration is the creation of a Widget Category. As shown in the Figure above the Category used in the Cisco lab was labelled “cuci-ibm”. In large scale deployments, where you might need to create different plug-in files associated with different Cisco Unified Communications Manager clusters, you will create multiple widgets; the widgets for each different cluster should be placed into differently labelled Categories. Recommendation: create your own meaningful category label so it is easily identified for use during the policy based deployment procedure described in the following steps. Step E – Configure the desktop settings for the Cisco widget After the successful completion of Step D the Cisco plug-ins are ready for deployment via the Notes widgets you have created.  Lotus Notes desktop policy settings will now be used to make the widgets available, to the distributed client population. The Domino desktop settings are created and accessed from the People & Groups tab via a Domino Administrator client. See below: Figure 6 – Accessing Settings via the People & Groups Tab In the Cisco lab the cuci-ibm Widget settings were configured as shown in the following diagram. Figure 7 – cuci-ibm Widget Desktop Settings The IBM documentation states that when the Widget desktop settings document includes a catalog category” then any associated widgets will be automatically deployed and updated the next time the Lotus Notes user logs into their client. Step F – Configure a managed plugin_customization_ini setting for the roll out To support 3 rd party presence capabilities, such as a CUP controlled onhook/offhook phone status icon, the Sametime client needs the EnableExtendedStatus setting (normally found in the Sametime client’s “plugin_customization.ini file) set to enabled. From Sametime version 8.5.1 and above, this parameter is no longer enabled by default and needs to be configured during the plug-in deployment. There are many ways this might be achieved, in the Cisco lab the “Custom Settings” tab was used to automatically set EnableExtendedStatus=true.   Figure 8 – Adding the EnableExtendedStatus=true to the cuci-ibm settings Step G – Create an explicit desktop policy; then assign users To install the plug-ins you will need to assign the Desktop Settings that contain the Widgets and Custom Settings to a policy document that is applied to the target user community. In the Cisco lab a specific Expli cit Policy document was created as shown below: Figure 9 – Adding the cuci-ibm-sametime Policy Document During the policy document creation you need to assign the Desktop Settings that include the Widgets and Custom Settings defined in earlier steps. Figure 10 – Assign the cuci-ibm Desktop Settings to the Policy Document You then need to add the CUCI-IBM-Sametime users to the policy document. There are a couple of ways this can be done. The first is to add the policy assignment directly to an individual’s Person document or the second is to use the IBM recommendation (determined from pop up messages in Domino), which is to add the names and groups of CUCI-IBM-Sametime users directly into the policy document via the Policy Assignment tab. Figure 11 – Assign the CUCI-IBM-Sametime plug-in users to the Policy Document At this point if the widget is properly formatted, the Desktop Settings are correctly configured and the appropriate users have been assigned to the policy you are ready to begin testing the deployment. Testing the desktop settings Auto Deployment As previously mentioned when you add Cisco widgets to a specific category and include it in the Widgets configuration created in the Desktop Settings document, the widget and then by association the CUCI-IBM-Sametime plug-ins will be deployed, assuming WidgetCatalog Replication and Sync is enabled appropriately, the next time the user logs onto their Notes client. To test automatic installation, perform the following: Install the Notes 8.5.3 client and upgrade the Sametime sidebar to 8.5.2 Add the Notes user to the CUCI-IBM-Sametime policy document Log onto the Notes client. After a short period of time you should receive the plug-in installation window. You may need (depending on your plug-in_customization.ini or policy settings) to manually select “Install this plug-in”. Figure 12 – Plug-in Install window Remember if you create two widgets there will be two plug-ins to install and the end user may receive a separate install window for each plug-in. Self Service Deployment: Alternatively if a self service installation model is preferred then one way of achieving this is to set the “Show the My Widgets panel in the sidebar” to Yes. The end user can then “browse the widget store” from the integrated Sametime client and install the widgets by dragging and dropping them into the “My Widgets” window. Figure 13 – Self Service Deployment You can force the Sametime client to ignore the signature warning (shown in Figure 12 above) and automatically install the plug-in by add the following commands into the plugin_customization.ini file: com.ibm.rcp.security.update/EXPIRED_SIGNATURE_POLICY=ALLOW com.ibm.rcp.security.update/UNSIGNED_PLUG-IN_POLICY=ALLOW com.ibm.rcp.security.update/UNTRUSTED_SIGNATURE_POLICY=ALLOW          Note: There are also policy settings in Domino that can be used to ignore the unsigned plugin warning and force an automatic install. Standalone Sametime Connect The deployment approach for the standalone Sametime Connect client relies on the generic “update site URL” tool available on the Sametime server. The basic configuration procedure is to place the configured plug-in on a HTTP share (this could be the HTML directory on the Sametime server) and then insert the URL of the plug-in location into the Sametime server field shown in the diagram below. The “update site URL” field is available in each separate Sametime policy. For a large scale environment where there might be separate CUCM clusters (and hence different versions of the Cisco plug-ins), you will need to create different Sametime policy groups for the different CUCM clusters and then ensure the appropriate users are assigned to them. Fig 14 – Sametime Server Update Site URL After a server restart, the Cisco plug-in will be deployed and installed shortly after a user has logged onto their Sametime client. They will then be prompted to restart their client. Figure 15 – Restart the Sametime Client As is the case for the Sametime Integrated sidebar option for Notes, 3 rd party presence support requires the configuration of the EnableExtendedStatus feature. From Sametime versions 8.5.1 and above, this parameter is no longer enabled by default and needs to be configured during the plug-in deployment. One way of achieving this is to create an XML file (managed-settings.xml) that contains the EnableExtendedStatus=true definition, place it on a HTTP share and then use the Sametime Server’s Update site URL tool to push the “plug-in_customization.ini” configuration out to the clients. Figure 16 – Deploying the EnableExtendedStatus=true Parameter An example “manage-settings.xml” file is provided below: <?xml version="1.0" encoding="utf-8"?> <ManagedSettings> <settingGroup name="com.ibm.collaboration.realtime"> <setting name="enableSUT" value="false"/> <setting name="enableTelephonyStatus" value="false"/> <setting name="enableExtendedStatus" value="true"/> </settingGroup> </ManagedSettings> Using the methodology provided above it should be noted that the roll out of the Cisco plug-ins for Sametime versions 8.5.1 and above requires two separate installation phases, the first one for the plug-in install and the second for the EnableExtendedStatus=true update. ... View more

I once attended a customer meeting quite a few years ago where someone in the room stated that, “regardless of the collaboration channel employed, Unified Communications should provide everyone with a single identity to make it really easy for customers to reach the company’s employees”. I remember agreeing that although a worthwhile goal, providing users with a solitary identifier was not going to be technically feasible due to the fact we didn’t address emails with a phone number and we unfortunately had (and still do have) the “PSTN” (Public Switched Telephone Network) to deal with. Has anything changed? I’d really like to know if anyone in the industry is predicting that we’ll ever be able have a unique global communications address, or like me, you have the opinion that the current multi-identity status quo will continue for the foreseeable future. In our current electronic communications world most of us have a minimum of two to three identities. I’m globally reachable via a couple of Cisco E.164 telephone numbers, one for my desk phone and the other for my mobile. I also have a corporate URI (Universal Resource Identifier), which most people would recognise as my email address, but nowadays also represents me as an Instant Messaging entity as well as associating me with three personal video endpoints. I think people naturally know when it is appropriate to use asynchronous (email or IM) communications or synchronous (telephony or video) communications, which is why we’ve all just accepted the evolution of different identities for different types of dialogue. What’s recently blurred the situation is the wide scale adoption of video URI dialling within Enterprises and across the Internet resulting in a more complex addressing environment for our real time interactions. Do I call someone on their telephone number or their video URI, or should I send them an Instant Message to ask them? In Cisco the answer has been to make the technology smarter by providing the ability to blend multiple identities in our call control platform and link them to an individual in the system. In other words my numeric phone number and my video URI are now associated with my profile and will be intelligently used when I make or receive calls. For example, if a customer calls my EX60 video unit over the internet and I am away from my desk I can still pick up the call, although minus the video, on my wireless IP phone associated with my profile. This does not mean that my handset now supports URI addressing; it’s just that the system recognises I have a shared line appearance between my EX60 video endpoint and my wireless phone and is intelligent enough to use the correct numeric address when extending the call to the telephony device. To take it a stage further, if I am actually out of the office at the time of the call, my call control platform can take the received URI and map it to my single number reach profile so that the customer call is extended to my cell phone. From an architectural perspective Cisco’s blended identity concept is supported across multiple call control instances so scales to a global level. The good news is that the exchange of individual URIs between call processing elements is dynamic so that each one builds up a comprehensive table of video URIs for the system as a whole. Even if an Enterprise only uses a single organisational domain, such as “acme.com”, any given URI is also associated with a piece of information called a “route string” which is analogous to the postal address of the user’s home call control location. This means that a URI call will always be routed to the correct destination regardless of the complexity or simplicity of the deployed domain structure. Needless to say all of the technical details are invisible. All a customer needs to do is call my URI from their video terminal or dial my phone number and I will be able to answer their call on any of my devices regardless of whether I’m next to my high end personal video system or using an old fashioned analogue phone. This is definitely a step in the right direction but I’m not sure I’d ever want my phone to ring if someone sent me an email! Or would I? As technology evolves I expect we’ll be use polices to control our communications equipment in any way we like. What type of reachability should we be aiming for and where should we draw the line? ... View more

This is short video demonstration I put together for Cisco Live London in CY13. It shows a subset of the featureset available when CUCI-IBM is used to link Sametime to Cisco's UC infrastructure. More information on this Cisco integration can be found here. ... View more

The Cisco WebEx Meeting Server (CWMS) is a neat solution for on-premise conferencing and provides the Cisco’s SaaS Meeting Centre experience from a server positioned behind a company’s firewall perimeter. For some customers this is exactly the deployment model their line of business or local legislation demands. Just like its SaaS big brother the Meeting Server supports Productivity Tools for scheduling but unlike its sibling the on-premise offering does not support Lotus Notes. The WebEx business unit’s position is that a Notes user will have to use the Meeting Server’s web portal when they schedule a conference. This leads to the obvious $64,000 question all of my IBM email customers ask: What does CWMS portal scheduling mean for them in terms of the user experience? To be honest the only way to really answer the above question is via a demonstration, so I’ve put some short video clips together to show what the Lotus Notes scheduling experience is really like with CWMS. Let’s start with creating a meeting: Video Link : 10753 In my lab I added a HTML tab into Jabber to provide an easy access point into the CWMS scheduling portal. This is a great way to anchor the scheduling experience within my Cisco Unified Communications client, but I want to stress that this is purely optional and a bookmarked web page will work equally as well. The video clip shows me creating a meeting between Jane and Jim, Jane is the host and Jim is the attendee. The first thing to note is that both participants actually receive a Notes calendar invite with the meeting details and click to attend URL. If you look closely at Jim’s invite you’ll see it does not include the host key; although Jane’s does because she is the host. For those of you familiar with our SaaS scheduling experience this is expected and required behaviour! When Jim accepts or declines his CWMS meeting invite Jane will receive notification. One caveat I did notice was that a received acceptance was purely informational and could not be processed further. I believe this is because the invite actually originated from CWMS across the SMTP connection. I’ll be very happy to be corrected by a knowledgeable Domino administrator! When I scheduled the meeting I actually did not enter Jim’s email address (I could have) but used finance@uclab.net i nstead, which is a distribution group address defined in the Domino directory. If required, I can also cut and paste multiple email addresses into the CWMS portal: Video Link : 10754 Cool, but what happens if I want to modify or delete my meeting? Well as long as I train my hosts to use the CWMS portal for scheduling changes the synchronization with the Notes calendar is maintained for all of the meeting participants: Video Link : 10755 Video Link : 10756 When it’s time to join a meeting the attendees simply click the web URL included in the Notes calendar entry. This is similar to the user experience you’d get from the WebEx SaaS service or from other email integrations such as Outlook: Video Link : 10757 Before I actually tested the CWMS portal scheduling approach with Lotus notes I was unsure whether it was a viable option for my customers to create/manage their WebEx invites and to be honest I was pleasantly surprised at the results. As long as I provide quick and easy access (maybe from Jabber?) to the scheduler and my users are trained to use the web tool for all of the web conference meeting changes, then the Notes integration is logical and intuitive to use. The current integration uses a SMTP connection between CWMS and Domino so does not require any Mail Template changes. For some customers this is actually seen as a benefit! I’m always looking for feedback and debate around Cisco’s integrations with IBM; I’d welcome any questions or comments. ... View more