Hi Cisco Staff,
Before i go on, i wish to request that my post be not viewed as a complaint but more of an observation and or concern, i have pretty much exhausted Dave Harpers ears, and i really do not want to burn him out because of my gripes with CCA, so i figured i should raise this up with the rest of the Cisco Engineers. It is also quite possible that i was spoilt a little to much being apart of the CCC beta testing, which i found to be Cisco's best efforts thus far in designing a fully fledged system for managing, and maintaining the UC-500 series system.
I have been experiencing some unusual issues with CCA (Latest Build) that i just can not ignor any longer, they end up forcing me to have to revert back to CLI, using a TXT editor and doing a hell of a lot of copy and pasting, which i belive the purpose of the GUI system to is to make things much easier and more stream lined, it becomes even worse when you are onsite and CCA does some very unusual things without even giving warning (You can see it actively working when you run Term Mon for the CLI).
CCA Configures the full amount of available DN's that the system is licensed for, this in my opinion should not happen, it not only creates confusions but since using it to build the last 4 systems, i have found it creates the following problems:
Is it possible that CCA gives the user the option to either deploy the full amount of DN's or to just create them on the fly, i can understand and appreciate that in some instances this can be usefull to some people, but really CCA has some odd quirks and the current issues it is dealing out, puts me in a position with the last 4 deployments to remove all DN's entered and associated Ephones, re-create them in a text file and then dump them across, thus cleaning up the copious amounts of code deposited by CCA.
(NOTE) This was never experienced with CCC, i am not sure if this was intentional or if this programming was left out for a reason.
I am noticing CCA making adjustments to the system when it is exploring the system for information when it is loading up for the first time logging into the box, it was by accident that i discovered this when i was consoled in and i could see the modification notices popping up, mind you nothing was changed by me, so i have to assume that CCA made some changes to the system without my explicit permission, but i have noticed it does the following:
Is it possible to have CCA advise you that it would like to make changes to the system before anything is even touched, and if possible it tells you what it would like to change and where in the config it would like to change it. I understand that it should ask your permission before doing anything but i can say with absolute confidence this is not the case, it does though at times come up with a dialogue box informing you about the firewall and if you want to keep it or remove it as it does not recognize it, but this is the only time i see any such warnings come up.
Doing upgrades to systems for their IOS and CUE respectively is a bit of an issue at times, again i have noticed on the last 4 systems i have used CCA on that when i go to the upgrade section, click upgrade it advises me to wait for the Voice discovery process to finish, so i wait 10-15 minutes still nothing, it tells me to keep waiting, so i close CCA and try it again, this gives me about an 80% chance of it working this time, but not always sometimes it takes me 3 or 4 attempts to get it to allow me to do the upgrade.
With doing the upgrade at times it also advises me that the UC-500 does not meet pre-conditions to carry out the upgrade (First time i have seen this issue, did not see this in 2.0(mon), this only happens if i choose to do a full upgrade, if i log out and then restart CCA and chose IOS only, the upgrade then works, and then i have to do the CUE manually.
There are more funny quirky issues, but looking at my post it is already getting to be too long, i have raised these issues with Dave Harper in the past, and some of his suggestions have worked without issues, however the ones listed here just keep happening.
I am fairly confident that i am following correct CCA procedures, and have since gone through and read the material again just to make sure i am doing things right, i was not able to find resolution to the above problems, they just seem to be right out of the field to normal operation.
For now i will continue to use CCA for the telephony wizard as this is fast and efficient, even though i am still required to do manual editing after to clean it up it is still quicker then building it from a template config.
My apologies for the long post, and i am fairly certain no one else has raised these issues up, it might just be me that is having these problems and knowing my luck it will be, but regardless i do applaud the great work the engineering and staff working on the CCA project are doing, it all improved the Cisco experience regardless.
Not on Cisco's staff, and concur with most of your concerns/gripes. We have found and learned to live within the limits of CCA. Once you go down the CLI path to actually get the system to do what smaller more robust clients need, CCA just makes a mess of the config. CCA has gotten SIGNIFICANTLY better, but it is not the only tool that can be used in the real world. I hope the CCA Cisco team takes your comments and adds them, to the to do list for future CCA revisions.
Thanks for this feedback. Here in the Product Team we take this very seriously. I will send you a Private Message so we can discuss next steps.
Just to let you know that i am going to open up a TAC case to see if they can help me diagnose the problem(s), whilst the client has extended me much patience i am trying to avoid taking that for granted, i had only just finished rescuing them from a botched deployment which they have bared with for almost a year, a few more days shall not hurt them, they are satisfied they can at least use their phone system for what it was intended for.
Good luck. We had a very bad experience with a UC early adopter deployment and a client, but Cisco really step in and saved the deal. I would recommend at this point that you scrub the IOS by hand and forget about CCA. TAC will be very helpful if you can focus your issue.
I appreciate your Advice Finalconnect :)
However i have complete confidence in the Cisco Product team and also in their releases of CCA and other derivitive software suites, by hitting this current hurdle i can assure you that it does not deter me from continuing to use the Cisco designed and built products, after all they are designing them for us to use, and further more they are relying on the little more experienced people out there to help them iron the software bugs out over time.
I have learnt over time that at least 80% of errors are derived from humans (80-20 rules), and when i say that i even speak about myself, the current issues i have with CCA may result in the problems being in the way i am designing the system during the Telephony Wizard process, or me lacking the understanding of how Cisco use some terminologies, it would seem that everywhere i go Terminologies constantly change and the big wheel of confusion starts from there.
However i do suspect that CCA-2.0.1 does have some odd problems (Maybe even quirks), and i am not entirley fond of the way it dumps copious amounts of code onto the system, this to me just creates confusion even for the program that is trying to work with it, i say that because it had to be programmed by a human to assume certain variables, and on top of that it would have been programmed by multiple people with multiple types of assumptions, which again can lead to crossed wires (paths) which is what i think has possibly happened in my point of view.
But no matter what i will continue to support any Cisco released software and continue to raise my issues with them, without these very much needed products i personally believe myself we will see more botched deployments than what i am currently seeing now, i have learnt that those who bare the CC(XX) tags may not allways be in the know and tend to delve into things that are way over their heads
We should talk offline - www.finalconnect.com for phone then x201. If you have a direct feed to Marcos at Cisco, he has my info and could release my email - don't want to do it on a public forum. I concur with you and have no plans to ditch Cisco because they are trying harder than any vendor. Cisco will dominate the SMB phone market within 2 years, and we can avoid the inevitable or enjoy the ride. It is a work in progress, but Finalconnect has been rewarded significantly for being on the Cisco train. I am with you, and we sound like we are on the same page trying to help Cisco make a better product and feature set!!!!!
Thanks again, and this has been an enjoyable exchange.
I thank you both for your candid comments. Let's keep the conversation going. I have forwarded this thread to our engineering and management team. We have received a few complaints about the lack of predictability in CCA 2.0.1, which we have been treating as isolated, one-off kind of bugs. However, David's issues point to something more serious and not the occasional (and sometimes unavoidable) software defect. This affects the systemic bias expected from this type of tools, which is of course unacceptable.
If you have TAC cases, please collect them and send them to email@example.com.
If you have TAC cases, please collect them
I dont have a TAC case on this yet as i am still waiting on our account manager to bring this box serial number under my profile, it is still registered to a company that as far as i am aware is no longer around, i unfortunantly worked for that organisation and the client managed to track me down and asked if i would be willing to bring their system back to life.
I iz flying solo on this one :)
I am going to try and save up some mullah and buy me a UC-500 NFR and break it till my heart is content, i really need to stop breaking clients systems it is a bad habit to get into, onde day i wont be able to pull out the trouble it gets me into, and software being software it is never right, you and both know there will never be a CCA Final, it will have to keep evolving as the base code evolves and also the system(s) themselves.
But if i was to put forward an opinion, i would have to say hurry up and make a CCA for Linux, even better have one written in pure C or C#, i am not a huge fan of Java and i really hate the amount of resources it consumes on a system, if CCA Hangs you can watch it in task manager go from 145MB to 700MB in no time, this is the Java componant of it, and what makes it worse is that to get it to work again you have to reboot the system, this usually calls for a coffee break :).
I am not a M$ or Windoz basher in any way, but it is frustrating when we meger FOSS users appreciate the fine art of using a good solid OS, and it kills us to be ignored by those who use UNIX for some of their applicationsbut wont make us feel warm and fuzzy inside to have our own Linux client.
Oh for all you Java programmers out there who are cursing me right about now, i aint knocking it, it certainly has its many uses, i am just not really fond of its side affects, a drug addict once said "Everyone loves the highs, its the downers that really kill ya"...... it often makes me wonder if thats the feeling i get when i am working with CCA and it just bombs out for no apparant reason, worse when your screaming along and almost completed a major programming its like getting a BSOD LOL.
Hmmm its Saturday, i must be bored if i am on here ranting again... I guess i should go do the fatherly thing and play with the kids.
Hi all, tanks for this post. I also have experienced strange things using CCA 2.0.1. I made same configuration on two UC520 and had different responses from the UC520. Sometimes the CCA hangs, other times does not change what you want to.
Regarding the above I just want to ask you guys something; regarding the issues reported above we still need to use CCA to configure/initialize UC520, right?
If we don't use CCA and use CLI like a normal CCME does CISCO give support or the UC520? Nneed to have all the right templates and configuration made by CCA to have the Cisco Support.
I'm asking this because I have a customer that don't whant all the mess that CCA put on the UC520 - ispect, access list, auto assign and so on.
Does removing this stuff put the UC520 instable and not supported?
Hi all, tanks for this post. I also have experienced strange things
using CCA 2.0.1. I made same configuration on two UC520 and had
different responses from the UC520. Sometimes the CCA hangs, other
times does not change what you want to.
Exact same experience for me as well :)
It is funny, when i do the install on a Demo system, no two installs are the same, each install has a tottaly different setup even though i chose to do it exactly the same as per the previous....I lost count now ...times.
Regarding the above I just want to ask you guys something; regarding
the issues reported above we still need to use CCA to
configure/initialize UC520, right?
No you don't, i at times still use a template that i have pre-configured for really basic setups I.E <10 handsets and do not require anything fancy, however though this template was initially designed in CCA and then cleaned up somewhat, i find this to be a very quick way of doing it at times cause you can edit everything in the txt document and load it to the system fairly quickly, much quicker then doing it from scratch in CCA, the downside i guess is that you still have to use the GUI unless you want to manually copy and paste the information into the CUE (Not recommended).
If we don't use CCA and use CLI like a normal CCME does CISCO give
support or the UC520? Nneed to have all the right templates and
configuration made by CCA to have the Cisco Support.
I have never been denied support, not once by TAC because it was a manual config, infact it would be silly for them to do so, it defeats the purpose then if people learning, understanding and training on the command line. The GUI from my perspective is nothing more then a productivity suit, it is there to help with streamlining the process, and to ensure smoother or better builds (But not allways does it happen that way).
I'm asking this because I have a customer that don't whant all the
mess that CCA put on the UC520 - ispect, access list, auto assign and
Does removing this stuff put the UC520 instable and not supported?
Not at all, the first thing i do after a CCA build is go through and clean up the config, when i say clean up i mean i get rid of all the DN's it dumps in there and i stop the Auto-Reg (Wich for me is the biggest pain in the you know where), the Auto-Reg can cause a person infinite amounts of grey hair, that is the first thing on my radar to switch off, i do however enable it back on if the customer does not have a maintenance support agreement, but it is really not required, i normaly train them on how to use the web GUI which is more then enough.
All TAC staff should be able to read manual code, i have not come across one that can not, and you will also notice when dealing with TAC each member has their own way of operating on the CLI, right down to how they abreviate the commands :)
Your in the clear Jose, unless the staff on here tell you otherwise (Which i will then have to question their reasoning), you are all good to keep working in a semi manual enviroment, just make sure you try and obey the OOB programming so CCA can at least recognise the code.