Disclaimer: Ryan is assisting with my TAC case, my response below is around the policy, not the current support being received.
Roger - serious discussions need to occur with management. There is still zero reason for this to be an option key (paid for that matter). Here are my comments based on what is in the document:
"Web Snapshots is a feature which allows administrators to take snapshots of all live video streams and presentations currently active on a TC software based video endpoint" - This is true, but disingenuous. They are low resolution snapshots, and require the system to be awake.
"In many countries, video monitoring of people without notification is illegal." - I can enable auto-answer on a codec and get high-resolution video AND audio from a system with no one being any wiser. Further more, your video bridge enables endpoints to be added without video and without the user knowing an additional system connected.
"Customers may not be aware of this feature and do not take the necessary precautions" - Correct me if I am wrong, but Cisco customers are the ones screaming for this feature back. In 7.2.x web snapshots were off by default and required admin to enable. Pre-7.2 this could only be done via the local in-room remote control.
"Customers are exposed to a security risk if the system is being hacked or the admin password gets in the hands of someone with the intent to retrieve information they are not entitled to." - This point is moot. Enabling remote monitoring via a key or option does nothing to curb security. If I have added the key for remote monitoring, then if someone gets the admin password your above point still exists. Also, the admin password would allow an outbound video call to be made, which in my opinion would pose a greater security risk than a low-res no audio snapshot.
"To ensure that customers are making a conscious decision before enabling this feature, Cisco is no longer providing Web Snapshots as a standard part of the product, but rather having it as a payable option." - Back the shareholders train up. Previously we had a conscious decision making process, it was called an end-user option. How does associating a $$$ amount to the feature make it any more conscious? As previously mentioned, you just further help competitors.
At the end of the day I can still monitor a room with HD video and audio without a user knowing, its called being in a video call. The only way for a user to be sure they are not being seen (justified or not) is to yank the power on a videoconference system. The web snapshots option key is something not thought through and causing more problems than what its worth.
Great to see so many bug fixes (a few of which were affecting me) but I think that taking away a feature that people already had is a sure fire way to irritate your customer base.
Yes, there was a lot of fixes in TC7.3.3.
I agree that some might not like that the feature is taken out of configuration and now has to be enabled with an option key. But if we consider the amount of clients that did not like this feature due to its security and privacy concerns I think this is a good solution that serves both parts. This does not fully remove the feature as customers who use it often will be able to enable it again.
Customers will be fully aware of what this feature is capable of upon acquiring the option key as they are actively seeking to enable it. The feature will have no notifications on screen what so ever. This is also something that customers who use this in their day to day business has been complaining about, the "Eye of Sauron" :).
Just a side note: I recommend everyone who has questions regarding cost or any other concerns to contact Cisco Licensing or go through the account team. I rather not start a cost discussion in the forums. Thanks.
I understand making customers fully aware. But why not make it a $0 or $1 SKU that you order when you purchase and is not part of an auto expand SKU? It would have to be a conscious decision to order, right?
That would fulfill the requirement of notification without the perception that Cisco is charging for a critical feature that was previously free.
how will users will be aware of the functionality of that feature through a new option key? The normal end users who are using the system will losing possibilities of control.
The enduser will never get the information if the licenses is installed or not and many IT departments will just order all licenses possible for the endpoint.
From my personal point of view now of your points regarding privacy is solved by that new solution. The only difference is partners have more work and the uers have still the "Eye of Sauron" but they get no information about. Is that really the best solution? For some companies maybe, for most the feature will now be inacceptable.
I’m happy to see this is being offered for “free” on existing systems, but this entire idea is ridiculous and completely unacceptable. A long established administration capability that we have all used for years has been removed, and reintroduced as a pain-in-the-butt “feature” requiring additional overhead to enable on each system.
Isn’t the entire idea to optimize our capabilities? On systems for which we already spend a large sum of money to purchase and support, why should we be asked to pay for something that we have used for years without additional cost, and then be required to install an additional option key to enable it? Who thinks up these brilliant ideas? No other manufacturers do this, why are you?
I understand your concern. Implementing this key for several thousand systems one by one is not a efficient way of re-enabling this feature. If you have a lot of systems you need to enable this option key on, please raise a TAC case and they should be able to provide the means to push keys to all the systems automatically.
The option key was introduced due to a massive pressure from users who did not want their systems subjected to monitoring. Some thinks this is a great feature other thinks of it as a security and privacy issue. By not having this feature by default, and letting customers who needs the feature enable it at will, provides an option for both parts. We want customers to be aware of what this feature can do (monitor systems and intrude privacy) and users will be aware of this if they have to have an option key and not just flip a switch.
The original setup was just fine. Web Snapshots had to be able enabled locally, and could not be enabled remotely. If this has to proceed this way, there should never be a cost, even for new system purchases, and key should be able to be obtained automatically through the licensing portal.
What possible ways could one "automate" the pushing of keys to the systems? Each system will require a unique key, correct?
I am pretty sure that CUCM cannot interact with a codec like this, i.e. adding a key to the system.
TMS would allow you to build a custom template to add the key, but by the time you create a template for each system with each systems unique key you could have loaded the key on each system.
The reason I ask is that I am sure partners & end users will see this post and attempt to open tickets with us to ask how to do this.
Ditto to Justin's question. Upgrading CUCM endpoints to 7.3.3 is already a pain in the butt because deploying .cop files to the TFTP servers and clusters is a "managed change" and takes just as long as upgrading the endpoint individually.
I also received a bunch of keys from TAC which are not working on 7.3.3 systems.....if I have to submit them by each model line....UGH....
Hi Justin, Aaron
We have a good API and with basic scripting, the commands can be distributed to multiple systems automatically so you do not have to apply the keys on a one by one basis. Yes, the key is unique, but you have to have all the keys in a CSV file (can be created with excel).
I have attached an example script on how this can be done. Obviously it´s up to you if you want to use it and it works in its current state for Linux, OSX and Windows as long as Python is installed. It´s written in Python and uses a CSV source file. The example script is provided as is and it is not supported officially by Cisco but we have tested it on many systems and it works fine.
The script can also be used as an example for other scripting languages you may know for example bash scripting as the API commands are the same.
So if you want to save your self the burden of enabling the key manually, this is a valid method to do it quicker.
Thank you for sharing this script, this will be very helpful. I would have never figured this out :)
Do you have also an elegant way to collect the serial numbers and system type to collect? I am really looking and cannot find anything useful in TMS for that....
In TMS I have gone to systems\system overview. Then pick what endpoints you need or pick the top level. Then in the system parameters on the right side, general settings tab, "hardware serial #" and "specific system type description" should give you what you need. It doesn't hurt to put the name or description too. Click view at the bottom, then export to Excel.