Hi Tim,
Not something I would advise you to do, no two systems are the same, not even always in hardware thus working of a text file is fraught with danger... A properly built system with CCA should work with far less problems then a CLI based systems, and i know this for certain.
The issue at hand to try and keep the thread on topic without me Hijacking it, is quite simple.
- Cisco stuffed up with the introduction of the SBCS and the policies surrounding it, they failed big time in adequately training Select Partners on CCA, its concepts, and how the support mechanisms work... The biggest issue of all is that CCa is seriously miss-understood and is constantly given grief by the old school CLI masters, this is Cisco's fault and falls squarely at their feet. Those who understand CCA and its purpose (And I spent a truck load of hours in beta testing since version 1.9) know that it has a greater purpose, and not just a tool for those who are CLI illiterate or do not have the certification, it is a tool to future proof Cisco's SMB model by reducing unnecessary support demands and stripping away the inconsistencies that comes with CLI setups, every single CLI based configuration is based on the individual who wrote it up not on a standard set by Cisco because there is not one, imagine having to support this moving into the future with SMB products that have reached the masses??? Yes think about it for a second with some logic :-)
- The worst problem of them all was bringing in the policy that if you design and build the system in CCA and you are not EX-UC certified, they will not assist with configuration via CLI for things that CCA does not support yet, or had troubles doing, or is bugged out on etc..etc.. I will openly say it, who ever come up with this policy needs their heads read because not only is it stupid, but it is moronic and counter productive and should have even been considered when the policies were being drawn up
Actually when you think about it, it is really an oxy-moron and places un-due stress and pressure on a Select Partner who Cisco are supposed to be fully supporting... Seriously guys just for even a split second, think about this policy and reverse it, and create a new one that is compatible and works with the direction you are trying to head, do not enforce a CCA policy on Select partners, and then when something cannot be achieved with CCA leave partners out in the cold, it is a dumb and callas act PERIOD!!!
Now I know Michael and Tim's issue can be resolved to a degree with CLI, but since I have endevoured on all accounts to avoid reverting back to CLI I never persued it, thinking that Cisco would have resolved this months ago (Yes it has been happening for a long time now guys???).
If the issues progresses to a point where it puts you in jeopardy with your client, or it creates a hardship for your business, PM me and I will set the time aside to assist you with getting this to work, I can make sure it is CCA compliant so it at least will not break CCA, but I reiterate my comments above, please keep bashing on Cisco's door and force them (If you will) to resolve the issue and not sit idle on it.
Cheers,
David.
David Trad wrote:
Hi Tim,
Not something I would advise you to do, no two systems are the same, not even always in hardware thus working of a text file is fraught with danger... A properly built system with CCA should work with far less problems then a CLI based systems, and i know this for certain
For sure, you meant to say, a "CLI based system configured by an incompetent, or careless technician".
The issue at hand to try and keep the thread on topic without me Hijacking it, is quite simple.
- Cisco stuffed up with the introduction of the SBCS and the policies surrounding it, they failed big time in adequately training Select Partners on CCA, its concepts, and how the support mechanisms work... The biggest issue of all is that CCa is seriously miss-understood and is constantly given grief by the old school CLI masters, this is Cisco's fault and falls squarely at their feet. Those who understand CCA and its purpose (And I spent a truck load of hours in beta testing since version 1.9) know that it has a greater purpose, and not just a tool for those who are CLI illiterate or do not have the certification, it is a tool to future proof Cisco's SMB model by reducing unnecessary support demands and stripping away the inconsistencies that comes with CLI setups, every single CLI based configuration is based on the individual who wrote it up not on a standard set by Cisco because there is not one,
Actually, there are quality CLI configuration standards. And thinking that minor differences prevent people from understanding or achieving their goals, is an insult to their intelligence. Anyway, I want to say how Cisco is not alone in this painful situation.
Few months ago I was at the install site of small business, some sort of public school. They were struggling (among other things) with having a router/firewall made by a very prominent Cisco competitor, to work with a SIP trunk. The GUI of this box was a pitiful job, with configuration elements disjointed over different pages of little logicalness, it did not looked and performed any better that Cisco GUIs. Finally they called their TAC, that kind of laughed and said, "Oh, but you don't do that with the GUI!".
At the same location, they used some "cisco" 2000 gigabit PoE switches, due to their cheapness. I quickly learn i had to HIT ctrl-z to break into an IOS-resembling CLI just to do the very basic configuration needed. However to this day, the business unit that makes that products, thinks that the world is not smart enough for them to document the CLI - desplicable decision.
A final anedocts, I was in an holiday location trying to get the PPPoE credentials out of an Asian-made ADSL router, to replace it with my UC520 that incidentally I had with me. I failed in extracting the password, but learnt that -Oh, surprise- the device can be fully and completely configured with telnet.
I really don't seen the point in negating this simple fact, network devices are better managed by CLI, but the consumer or small business grade ones requires they come with a GUI. Cisco understood this some lustres ago and they are doing their things, fine with me as long that doesn't interfere with how the product really works.
imagine having to support this moving into the future with SMB products that have reached the masses??? Yes think about it for a second with some logic :-)
Actually when you think about it, it is really an oxy-moron and places un-due stress and pressure on a Select Partner who Cisco are supposed to be fully supporting... Seriously guys just for even a split second, think about this policy and reverse it, and create a new one that is compatible and works with the direction you are trying to head, do not enforce a CCA policy on Select partners, and then when something cannot be achieved with CCA leave partners out in the cold, it is a dumb and callas act PERIOD!!!I understand where do you come from but actually I totally agree with this Cisco policy. To me, it means the following:
- We (Cisco) know that we cannot sell SMB asking small dealers to "learn first and sell after". They, like their customer, want to be sweet-talked with "ease of use", and two 400-something pages manuals would scare them. It doesn't matter if any good PBX and CO switch has been adminsitered by decades with obscure CLIs compared to which IOS is plain English. JUST DON'T MENTION CLI BEFORE SALE IS MADE:
- We then introduce the best GUI we could, of course "everybody" with a little experience knows that it cannot do anything, and in some case, not even something. But, it's good enough to make the system work to an acceptable point. Of course, the definition of "acceptable" varies from an individual to another, and here where's the problems begin.
- Then, out of desperation or whatever reason, the dealer and end-users above, try the CLI, without any previous training or studying effort
The results are often catastrophic. We all have seen them before - configuration snippets sent as BMP screenshots, useless commands inserted anywhere just because they were in the examples, no understanding of the" basics of nature things" that dictate and why things works - or not. In a word, inability to properly and professional communicate with the TAC to get the issue solved.
- The Cisco decision is then logical - show me first that you put some effort in learning how to do things, and then I will start talking you in the real language - CLI.
And by the way, we all know how in this world of cheatsheets aweb-learning, how ridicusly easy the Cisco certifications have become. At a small partner I have been working with, the UC specialization has just been "tick'd on" by someone at Cisco - they figure that with a CCIE in house, another guy with decades of experience, and 2 or 3 TAC cases over 15 years, the partner deserved some trust.
Now I know Michael and Tim's issue can be resolved to a degree with CLI, but since I have endevoured on all accounts to avoid reverting back to CLI I never persued it, thinking that Cisco would have resolved this months ago (Yes it has been happening for a long time now guys???).
If the issues progresses to a point where it puts you in jeopardy with your client, or it creates a hardship for your business, PM me and I will set the time aside to assist you with getting this to work, I can make sure it is CCA compliant so it at least will not break CCA, but I reiterate my comments above, please keep bashing on Cisco's door and force them (If you will) to resolve the issue and not sit idle on it.
That is, of course where I agree 100%. When I joined Cisco in 1996, I did not just because they were the leader in what they were doing, but also because they showed they cared fixing their bugs and publicly showin them - beside documenting the product to the best of their abilities (most of the time). To this day, I yet have to see another I.T. company that does the same.
But, the entire process of Software Quality must also be customer driven, and cannot be put in motions if people sits on their bugs because they don't want to spend $150 for smartner contract, or simple laziness.
