atcomsystems.ca/forum Forums VOIP Phones & IP PBX Cisco Telephones and Systems The install finally begins - UC560

So today was the big day. After 9 months of research, quotes, more quotes, meetings, then purchasing, fighting over pricing changes, re-cabling the locations etc. It has begun.

I will try and keep a log of the install and how things are going, I will also try and post items that bite me in the ass and just plain silly items that come up.

Here is a quick over view of our install:

Cisco UC560 connected to a PRI
Cisco SF300 48 port POE switch
Cisco 2960S 24 port POE switch
Cisco ASA 5510 firewall
72 IP phones - 1 7945G, 1 509G, 70 504g
4 ATA adapters
11 locations
Cisco 891W at each remote location
Cisco SF302 8 port switch for 2 locations.

As you can see we are a Cisco shop.

We started today with the UC itself and the main switch. UC and switch mounted in the rack.

First step was to update all the IOS's. Why on earth they do not ship new equipment with current IOS installed I do not know. That process ate up an hour while the UC did its upgrade, good time for lunch.

Once the upgrade was complete we started the UC initial config wizard.

We created the user spreadsheet, scanned all the phone MAC's and mapped them to users. Then created the xml file to import into the UC.

- Issue - you must add your licenses before you can add the users, this is sort of ass backward as the wizard allows you to add licenses later in the wizard!!??

Once that was completed we successfully imported the users.

- Issue - you cannot use "-" in users names, this causes issues with any users that have "-" in their lastnames. You can use and "_" but that is not acceptable to users, so we just eliminated the "-" and the space. Users also cannot have a space in their first name, so any worker with names such as Betty Sue, must be listed as bettysue, or some other workaround.

After we sorted those issues out, we came to the Blast/Hunt group page. The first thing that popped up is the fact that you are limited to 10 blast groups, which is not listed anywhere in the paperwork. Since we have the need of 12 total blast groups, I have an issue to sort out.

As we were configuring the blast groups we got to group #10 and the wizard promptly crashed. Which caused the loss of another 30-40 minutes as we had to recreate all the groups and assign users.

Once we stepped through that we completed the wizard with some basic settings for the AA stuff.

As a last item for the day we plugged in the switch, plugged in a phone to see if it would talk to the UC.

The phone updated itself, picked up the correct extension and allowed a network connection to pass through the phone to the world.

All in all a good day, couple glitches but nothing to major.

Tomorrow starts the heavy lifting with the updating/registering of all the phones and some testing at remote locations.

I will try and post up again tomorrow with any items/issues/successes.

On that SF300 switch...make sure you load the 1.1.2.0 firmware image on it. Older versions (1.1.1.8 and below) have a MAC table bug. Entries no longer expire and new entries don't come in, and the stuck entries are ignored. This causes port flooding; the switch would behave like a hub, sending multicast traffic to all ports with all traffic. When I called Cisco support they told me that it appears after 49.8 days of uptime. Reboot and it behaves for 49 more days. Cisco initially sent me beta firmware with the fix, but they have since fixed this in 1.1.2.0. Good luck on your install, let us all know how it goes!

Thanks, that was the first thing we did when we pulled the switch out. Currently sitting at 1.1.2

Biggest issue we are having today is the UC email integration. Cannot get it to pass voicemail to email.

I can ping the 10.1.10.1 and 10.1.10.2 addresses from the mail server but cannot ping the mail server from the 10.1.10.2 interface. Will update if I find a solution.

Okay big problem.

Inside phones - the ones connected at the main admin office, work like a charm. Plug them in and off they go.

Remote sites - nothing. No connect nothing.

Now the fun begins in trying to track things down.

My setup -

Main admin site -
192.168.0.0/24 - data
10.1.100.0/24 - voice

Remote sites - they start at 192.168.5.0/24 and go up in 5 increments. 192.168.10.0/24 etc.

Phones pick up an IP from the local routers giving them the IP from the 192.168.5.0 etc ranges. They will not attempt to grab an IP from the 10.1.100.0 subnet.

I have tried adding the ip helper-address of 10.1.100.1 but still nothing.

I have added static routes on the remote sites pointing them to the UC data connection.

I tried turning off the firewall at the remote sites to see if that was the issue, still no go.

I am taking a break from it now as I see if I can sort out why things are not doing what they are supposed to.

Ok, so you've separated your voice and data network which is a very good practice. How are you getting the VLAN tags to your remote sites? GRE tunnel? Site-to-site VPN? Sounds like the voice VLAN tags are being stripped out by the remote edge routers.

Each site has a site to site VPN using the 871/891 to the ASA.

And yeah I think its partly a VLAN issue.

But its also not pushing the 10.1.100.0 traffic through the VPN tunnel. Right now the only traffic passing through the tunnel is the 192.168.0.0/24

If I set up static route on the remote sites of:

ip route 10.1.100.0/24 192.168.0.15 (UC Data IP)

then run a tracert to 10.1.100.1 its not passing through the tunnel to 192.168.0.15, its going out the WAN port and being dropped on the outside.

If I run tracert to 192.168.0.15 its two hops:
192.168.10.1
192.168.0.15

Once I get it sorted out on one site, the rest should be easy, its always the first one!

As mentioned many times at this site (any system is only as good as the installing company). Why are you installing this and not the company you purshed it from?

Major routing issues methinks.

Do the ASA and 891Ws have Smartnet coverage?

If so, just submit a TAC request and let them walk you through the configuration.

If this isn't an option, I have done a setup similar to what you are doing with ASAs on both ends and could probably get you some config examples. In my case, I setup two networks at the remote site, each with it's own subnet and VLAN. Then we routed both of them through the VPN tunnel to the main office, where they each connected to a corresponding network.

So using your addressing scheme, the first office would have:

192.168.5.0/24 routed to 192.168.0.0/24
10.1.105.0/24 routed to 10.1.100.0/24

You also need to decide if you want a split tunnel on the data network so computers at remote sites can access the net without going through the main office.

Then on the 891W, create VLANs for each network. Set the switchports to send voice traffic to the voice VLAN (The phones will automatically configure to the voice VLAN using CDP). Create DHCP for the voice network (Optional if there is only 1 or 2 phones, but I'd do it to be consistent across all sites).

Big caveat - I have done the above with an ASA5505 at the remote site. I don't know if an 891W can do all this. Again, TAC would be my first call tomorrow if I were in your shoes.

Good luck and thanks for sharing your experience!

Wouldn't the remote routes point to the edge ASA in front of the UC and not the UC itself? I haven't set up an ASA yet (only PIX), but those routes might not be correct. 192.168.0.15 is the destination, but not necessarily the next hop or gateway to get there. The ASA might be looking for an address it knows, such as the address of another ASA in the site to site configuration. Some VPNs also use virtual gateways within the VPN address pool, such as 172.16.0.1.

So hopefully Keep got either TAC or the vendor to get this setup already, but this discussion got me thinking about an 861 router I had lying around. So today I set a system like this up to demo for client using EZ-VPN to connect to their UC560.

This is not as complex as Keep's setup (ASA5510 in front of the UC560 vs using the UC560 as the endpoint), but the 861 config file would be about the same as his 891s.

So if you still need help Keep, let me know and I'll post some configs.

Bingo.

I am "assisting" in the installation, but the tech the company sent has never set anything this complex up......needless to say after a mostly wasted day today I am not a very happy camper.

I will post more of the fun we had today after dinner.

And yes I have smartnet coverage on everything so a call to Cisco will most likely be coming in the very near future.

Okay where to start.

I tried to get on here earlier today but couldn't get here! Probably due to me fixing my "firewall" issues that are causing the phones not to connect to the UC......

So today was spent realizing that the VPN's were not passing the 10.1.100.0/24 or the 10.1.10.0/30 we finally got that sorted out with the addition of some accesslist rules and crypto map entries. I can now see the 10.1 traffic going through the tunnel on both ends.

All to no end. Remote phones will not talk to the UC and register.

Then to add insult to injury the email to voicemail is not functioning.

I will most likely do as rcsinfo mentioned and create a whole separate network for the phones themselves at the remote sites.

As for me doing most of the leg work here, yeah thats got me pretty ticked. But that will be sorted out with a couple of phone calls.

Good thing I did not have any firm cut over dates as I insisted that everything be up and tested before I even entertain a date.

Just think of the experience you (and your installer) are gaining.

Justin

Experience on your dime....oh FWIW this is NOT a complex setup by any means esp after 9 months for approx 70 phones? Really? Keep posting..this is good stuff for other people doing this.

That's about the only way i can look at it without getting ticked off.

So the plan for today is to configured separate voice subnets at the remote locations.

Then establish VPN's on those new subnets for all the voice traffic to pass through to the UC.

and on and on

Yeah I was told repeatedly that this was not a hard setup and it should be no problem.

Anyone know the static routes that need to be on the UC itself?

Some success today.

The voicemail to email issue turned out to be an Exchange issue.

We are running exchange 2010. It did not like the fact that the UC was trying to send email using the 10.1.10.2 ip addr.

To fix this I needed to go into Exchange and setup a new "Receive connector" pointing to the 10.1.10.2 addr. Once we did that we successfully sent the voicemail notification to my email box.

Still have a call out to TAC on the vpn/routing issues. But using the split subnets on the remote site I managed to get one remote phone to register.

Now 9 more to fix, well once I figure out exactly what I did to fix it!

Some more success. Spent some time on the phone with the Cisco TAC guys, man that was impressive. After the usual tech support you get on the phone I was expecting some walk you through the manual type support, holy crap was I wrong.

End result is that one remote site is up. I learned a some things from this site:

1 - make sure you were told to point things to the correct spot. Early on we were told the tftp server address for the UC was 10.1.100.1, this is wrong and a big reason why things did not connect. The correct answer is 10.1.10.2

2 - activate the phones locally before trying to plug them in remotely. The one phone I took as a test to see if it would update and install, did not take the update. So it will be registered locally first.

3 - The split networks worked like a charm, though it did come with some headaches on the ASA side with the NAT configurations.

Thats all for this week. I will start working on the other remote sites Monday. I have a classic car cruise to go on.

Thanks for posting the updates. This is good stuff.

Justin

Today is Sunday, I'll pray for you, I think you need it.
All the best
Ken

The one thing that really really stand out here is how unqualified the installers are.

I personally would never attempt, nor allow my company, to take on work that we don't know how to complete.

That may be the biggest difference between phone guys and others doing phone work.... we just have to have 99.999% uptime or something just isn't right!

Did they give you the impression that they knew this stuff?? if so i would wreak havoc and tell them you need a more qualified installer!

Of course they knew their stuff. The engineer they sent out during the purchase phase, knew all the right things to say had all the proper letters at the end of his name (CCIE, CCVP)and gave me a very good feeling, that they could accomplish the install with little hassle.

The tech they sent out for the install admitted he had "Never done anything this complex" as he was used to installing single location systems that took a few hours to accomplish. Had no certs on the system we were installing and while he was willing to attempt the project, does not do me much good as an end user.

I will be talking to all the players tomorrow and voicing my concerns/complaints about the umm level of support we have gotten so far.

As for the prayers, thanks I have a feeling another 70+ hr week is coming.

As for the Company "performing the installation" wink wink, they are not a small company, they are one of the Big 3 up here. I know folks here do not like people naming companies so I will leave that out.

I agree with your plan to talk to the players... tell them what you were promised is not what your are getting.

So they sent out a CCIE/CCVP to sell you the system and then sent a tech with no certifications to install it? This explains a lot of your problems.

The concern I would have is that even if this guy gets the system up and running, there could be some problems under the hood. Did this guy get everything secured or are you at risk for a $10000 phone bill? Are your 911 calls correctly routed at the remote offices?

I am assuming that a job this size was net 30 or payment by job milestones. I'd insist that the CCVP signs off on your UC560 configuration and the CCIE signs off on your ASA and 891 configurations before your company makes the final payment.

Yup that's what they did. I will insist things are signed off before things are finalized.

So for today I spent the day installing the reset of the main site phones, I has held off on some as we did some testing. So the main site is complete, including the receptionists phone with addon modules.

As I was testing I came across a new issue.

We have 3 extension ranges -
3000-3005 strictly for our crisis call phones
3100-3120 these are for location based extensions - all blast groups and DID's are in this range
3200-3300 - individual users.

The 3100 range will not let me dial into them. If I attempt to dial any extension in this range is stops after 31.. and gives me an "Unknown number" error. Have not figured out where in the dial plan this is. The installer is supposed to look at it the next time he is on site.....

If I am at a location that has a 3100 series extension I can dial out to the world and dial out to other extensions. I just cannot dial any of them.

Now at the remote locations.
I have 3 up and running.
- I can dial out to the world - everything works
- I can dial out to remote extensions - everything works
- I can dial other extensions at the location BUT I cannot hear anything.

Still some bugs to work on, more added to the list of things to complain about.

Good thing I like learning new stuff.

For your missing audio issue, do you have MTP enabled on the remote phones?

If you are using CCA, check "Use as Teleworker Phone". If you are using the CLI, input "mtp" under the ephone configuration for each phone.

Also for your 3100 extensions if you are using CCA, look under "Troubleshoot" -> "Telephony Diagnostics" -> "Dial Plan Test". This lets you test out different numbers to see how the dial plan interprets them.

I will give that a look. I do not remember setting that up at all.

Okay MTP solved that problem! Thanks for that.

Another item learned today.

When working behind an ASA (or PIX) the voicemail to email notification would not work. The ASA drops the packets since it doesn't have an interface for the 10.1.10.0/30 subnet.

To fix this issue. Add a static route on your mail server to point to the data side of the UC.

Here is my route:

route add 10.1.10.0 Mask 255.255.255.252 192.168.0.15 -p

Make sure you use the -p or it will get lost on reboot...

The 192.168.0.15 is my UC Data IP.

Hope this helps save someone a few hours of headaches!

Oh yeah I almost forgot.

The solution to the 3100 range not working?

Change the range to 3300..........

Luckily it was only 10 extensions/blast groups to change.

Works like it should now, and we never did find the reason the 31## numbers would not dial.

Though I have not dug into the phones themselves to see if 31# is some sort of shortcut combo. I will investigate that after things settle down.

Some day you will have to figure how much time per handset you have spent. Still 10 extension out of 70 is quite a few. Keep up the good work!

This is an amazing ordeal you have went through. My customers would never had accepted that they had to help with the install, and quite frankly, I would never have let them. I am curious what you got billed for installation, and if they plan on reducing the charges in any way. Would you be as so kind as to tell us who you compared to Cisco? and why you went with Cisco versus another brand?

Based on what I've read, AVAYA IP Office would have been started and finished over a weekend. This is not a large install.

I am not sure I want to sit down and figure out the hours. It has been a ton.

I now have a firm understanding of what needs to be done at each remote location to make things work. So the time spent at each will be much lower in the next week.

As for installation. It was quoted at 30 hours to do the entire setup from start to finish. This included all testing and final cut-over.

I spent that many hours in the first 2.5 days....

As for the systems we had quoted:

Hosted solution - through local cable company, lowest up front cost, highest monthly cost and I had little control over it.

Panasonic solution - lowest cost, but quote did not include any installation fees, not a very good feeling from the salesman.

Cisco - 2nd lowest cost, we had an existing Cisco network and it was coming from a large company. Plus they gave us a price break on the PRI if we ordered the equipment, this was the deciding factor.

Allworx - This was a VERY close 2nd, and I was very much wanting to go this way but the price break on the PRI tipped it in the other direction.

Toshiba - current vendor wanted to tie 3 existing systems together, add more systems at remote locations and basically keep building on what we had, this was in my eyes a mess and a bigger administration headache. Plus it was the 2nd highest cost.

Shoretel - great product, great presentation, even greater price, was just out of the budget as it was twice what the Cisco system came in at.

2nd quote on the Cisco solution. Had another large vendor quote the same cisco system, came in quite a bit higher then the one we went with.

That was the quoting process and solutions we were presented with. I really really liked the Allworx setup, but the price breaks on the Cisco were the deciding factor.

And now I know why.....

As for me doing a lot of the work.

In the beginning when we sat down with the engineers and went through my network I was told, "It should work with the setup you are running now"

Turns out they were wrong in that aspect and thus why I had so many issues. If they would have said in the beginning "You will need to setup a separate voice network thoughout the agency" I would have had that up and running before the gear even showed up. But the fact that I was told "It will work as is" is what is really really ticked me off.

On top of that the fact that our install is/was being used as a training tool just pushed me more.

I voiced that concern yesterday to the entire "team" and was met with a lot of apologies and claims of responsibility, but no resolution.

I will wait to see what happens on Tuesday when I am back in the office as its a long weekend up here and I am in need of a break.

Its Sunday again, and I will pray for you again.
Boy you really got the shaft with this one.

This tread will become part of my next sales proposal when we go against CISCO.

I'm supprised you did not look at AVAYA IP Office, it would have knocked Cisco out of the box.

Thanks again Tomorrow is a Holiday up here so no fighting with any systems.

None of the vendors pitched an Avaya solution. Though one of them mentioned it then pitched the Shoretel.

As for Cisco, its not Cisco's fault my vendor sucks. I have had nothing but great dealings when I have talked to the Cisco TAC folks.

It certainly is Cisco's fault ...... they allowed that vendor to become a Cisco dealer!

I have a customer that had a UC560 ..... until the vendor told them in order to program the system for the PRI they had ordered it would require the system to be removed from service for a week and sent out to someone to program. When he told me this i told him i could walk him through programming a PRI on systems i sell in about 30 seconds.

Really??

What is a business supposed to do without their phone system for a week??

In the time it took their old vendor just to program a PRI we had ordered and installed a brand new system and he put the UC 560 in the garbage.

And the reason he went to Cisco in the first place was that the vendor / sales rep promised that 5 or so advanced applications would work ..... NONE of them did.

Welcome to phones from the computer industry!

I’ve been reading this thread from the beginning, thinking that this is such a simple installation. What’s the big deal; just another day at the office.

What really surprises me is that being where you are located you did not have a Mitel dealer bid on this. Their systems would have gone in super easy too given the scenerio you have described.

In all fairness a properly trained vendor of any brand would have been able to do this without all of these issues .... including many Cisco dealers i am sure.

The really surprising part is how poor of an install the vendor is doing .... if i were the customer i would be creating a big stink and getting a qualified, trained technician on site (if they have one?) ... or kicking this vendor off the job.

I admittedly don't know Cisco but the feedback i got when we replaced the UC 560 for my customer is that most of their emphasis is on the call manager platform so not very many people are trained on the UC 560 thus the need to remove it from service and ship it to someone else to program. In this case the vendor does well in excess of $10,000,000 per year in business..... hard to imagine they would hang a customer out to dry like that.

Again I completely agrre with upstate, the IS Cisco's fault for allowing a vendor to treat you loke this. You should be on the phone with Cisco management about this vendor and get relief and help from them. And you are you doing the remote locations.
I hope you were not involved in the decision to go with this vendor because there is a complete lack of researching this vendor.

Have to say that if he made the decision to go with these guys, as the expert that took 9 months making the decision, I would think he would be worried about his job at this point. I suppose it would matter how important the phones really are though. I have seen MANY IT managers fired over these things for far less downtime. Just another example of how Cisco can talk to IT peeps and tell them what they want to hear or understand.

To quote the old AT&T sales guys ... "no one gets fired for buying AT&T" ... they used that line all the time and bottom line is there is some truth behind it.

It would be interesting to see the total man hours to install the 70 phones when this project is all done and working.

I never claimed I was an expert in phone system. I am an IT Manager, NOT a phone guy, I mentioned that at the very beginning!

CISCO DID NOT SELL ME THE SYSTEM! I do not know how many times I can repeat that. Its a Cisco system but they are not the vendor.

We have had no downtime as our current phone systems will continue running until I have this all sorted out. I will have this whole setup, up running and tested for at least a week before I consider cutting over, everyone in my agency understands and completely agrees with this approach. I am in no way worried about my job.

As for the final decision on the vendor, no I did not say "I want this vendor". Did I recommend them, yes I did. They did a great snow job on me. As I said before, the tech the sent out during the quote phase knew his stuff, answered all the questions, offered up suggestions etc.

I researched all the vendors that I got quotes from, both good and bad, as every single company out there has. The good out weighed the bad. I just ended up on the bad side so far.

Now back to the install:

Better day today, two more remote sites up and running. 4 more to go, should have the rest up by Thurs.

I am closing in on 100 hours. I will pass that in the next couple of days.

Keep, I was not making a slight on you. I am AMAZED that an install of this small size and simplicity is talking this long. Please, this is NOT meant to insult you better rather I feel your pain.

Ditto ...... hope you aren't taking any of this as a slight on you.

It is just really interesting to see an install from the IT side after doing them from our side ..... and we obviously have different standards.

I go back to my original statement about calling the vendor out for not delivering what they promise.

No worries, its been a long and lately very frustrating process!

Its been an interesting journey so far. But with an end to the setup in sight (okay its still pretty distant) its been a pretty neat one as well.

The biggest plus is for the workers that will be using it, every site I get setup are happy campers, we have been "making due" with what we have had for the last couple of years and the staff are happy for the upgrade.

The call quality so far between sites and internally is outstanding.

Besides the ongoing issues with the vendor its been a pretty good process, its also been a very slow one, though nothing in this industry moves really quickly...lol

1.5 more remote sites up today, had to cut the day short for other commitments.

I have saved the biggest remote sites for last, not sure why it just worked out that way.

Then comes the tweaking, still need to finalize the AA's get all the scripting setup and setup the roaming users for our crisis call center. (All this is on the vendor not me) Then its testing and cut over.

Still a long way to go but there seems to be an end in sight.

I have a serious question about this whole project.
ARE YOU JOKING WITH US, this is 70 sets and several locations, no matter how bad the vendor is, no company would put up with this.

Nope no joke, why would I joke about this?

I am a one man IT department, running a shop that supports 175+ workers, 90+ computers and 12 locations. Not to mention servers, the old phone systems, cell phones, blackberrys...etc etc etc.

We (Agency management staff) knew going into this it would not be a quick transfer, between everyday issues and the "OMG I cannot work until you fix this" stuff the phone system is being installed. On top of that I was told not to work any more overtime getting things installed. So I am working as fast as I can.

I know most of you are used to going in and knocking things out in quick order, most likely with a few guys that know what they are doing. I figured thats how things would have went, the first day was that way, things went as planned. It did not go down hill until we started on things the vendor had no clue about, then it just snowballed.

In between issues today I did get one more site up. I can knock out the remote sites in short order now, 15 minutes to reconfigure the routers, then its just plugging in and testing the phones. Now its just getting to the remote sites!

In case I did not point this out before, I have not had the vendor on site since the 21st. I told them they can come back on site once I had the remote sites up and running. There was no point in them being here if they could not reconfigure the routers to make the phones work.

I have to physically go to each site to reconfig the routers as I have turned off remote administration on the routers.

Ok so you are serious.
Then let me ask this.. Does your company understand what a prize they have in you.
You are far and above what a employee should do in a situation like this.
You ever move to NYC and need a job call me first.

hahaha Yes actually they do.

But I will keep your offer in mind if I ever move back down south!

Largest remote site came up without issue. One remote site left, I ran out of power adapters for the phones so I had to stop.

Had a couple of phones that were supposed to be on a POE switch that ended up not being connected and used up my adapters :|

Staff are actively using the system and so far are very happy.

I am also making my list of things the vendor needs to do once they are back onsite.

Hopefully should have a cutover date in the next couple of weeks. I was told once I say "Go" its a 5-10 business day process.

Why are you out of power adapters, didnt the vendor supply enough. There is something very wrong with this picture.
If your using the system what are you cutting over.
Heaven help you.

Nope the power adapters are on me. I had two phones that were supposed to be on a POE switch, that I ended up pulling, so I am 2 short. I ordered them on Thursday, should have them on Monday.

We are using the system internally. None of our phone number have been ported to the PRI yet. I would not allow that until I had all the sites up and tested. So I currently have the old systems running along side the new one.

Ok for the adapters, and you seem to have most of the install under control.
I for one appretiate the infomation and time you spent keeping us informed of this.
This is certainly a big BLACK EYE for Cisco and there vendors. I've seen other Cisco vendors who know very little about communications and the end users suffer.
You have taken control for your company, well done.

Okay the hardware install is complete! (does a little happy dance)

I spoke with the vendor today, tech will be out on Weds to finalize configs. Then we will test for a bit and set a cut over date.

Things I have left for vendor to do:

Extension mobility for 3 users, should be pretty easy (hahahaha like everything else in this install)

Finalize AA setup - I have some questions about linking DID's to AA sub-menues.

Get all the scripts done, and pass them to someone with a decent voice to create!

Setup shared extension buttons.

And I think that's all.

Thanks.

Yeah I ate the one on the adapters. Lost count as I was going along.

No problem with sharing, I have received plenty of help from this place over the years, figured I could share some myself.

Once this is all complete I will post up a lessons learned post on some of the tweaks I had to do to get things running.

it seems that the higher priced Cisco vendor more accurately quoted the job and probably would have resulted in less labor from you. Was the vendor you bought the Cisco from also the same vendor that suppled the PRI?

Yes and the price break they gave us on the PRI was one of the deciding factors in the decision to go with this vendor.

While the UC500 series has had lots of problems over the years, I feel I must say this in their defense.

This configuration is not officially supported by the Small Business team or the system. Remote sites are supported through specificly supported routers and/or an additional system at a remote site.

I have the same setup that we were able to make work and it had nothing to do with the phone system at all, in fact I changed no programming on the system to make it work. In the end it was ALL about access-list and nat rules. Once that was done the phones connected automatically across the site to site vpn (asa to asa).

This was an Out of band solution so no UC500 support could/would help. In fact the UC540/560 is supported by their small business group, not TAC.

The fault in Keep's case as I see it, was with the salesman selling the UC500 solution as a standard CME install rather than understanding the product and its limitations. I am not saying the UC500 series doesnt have faults but in this case I dont see how Cisco failed at all. If its an unsupported feature or solution then you technically shouldnt do it.

I did my OOB solution and am happy with it but now have a fiber link between locations so it no longer matters.

As far as Cisco allowing partners behaviors, does ANY manufacturer do that? I gained a great deal of business from customers leaving Avaya/Cisco/Nortel vendors over the treatment and support they recieved from their current vendors. Its the same all around for almost any manufacurer. Local vendors can be good or bad regardless of the product lines they offer.

See now not once was it ever mentioned that my install was not a supported installation for this product.

I did the same thing with access-lists and NAT rules to make it work. But not once was I ever told that it was not supported. Hearing that now, just pisses me off. Where is it stated that this type of installation is not supported? I would really like to read that one.

Anyway. More Cisco quirky items came out today.

I have each of my locations setup with a blast group, (call group) each blast group has General Delivery voicemail box. You cannot set up an MWI for the GD mailbox....huh? Yeah you heard that correctly, you cannot set a MWI anywhere for a GD box. Even better to access the GD box, you must log into a personal mailbox that is a member of the blast group. So what do you do if none of the members have a personal mailbox? I guess the messages just sit there in limbo.

Solution.

Set up phantom extension with voicemail box say - 3000, set the DID to 3000, CF all calls into 3000 to the blast group pilot number say 3100. Now if no one answers, it will leave a voicemail at ext 3000, that you can add as a "watch" button on the phones to indicate there is a voicemail message in the general box.....what kind of hoaky setup is that?

I also got my analog adapters today, the ATA 186's were replaced with the ATA187's which I got. Guess what, not supported by my current setup.............I get to upgrade all the software on the system to add functionality that should have been included out of the box.

And I thought I was almost done with the configs.

Ha finally found the cause of this issue!

None of the "default" 3 digit extensions were cleared out of the system. So there extension "311" was in the database, of course with nothing attached to it, it was causing issues when trying to dial 3110. Ahhhh its always the little things.

If I were in your shoes I would toss that vendor off the job, hire another one to finish and then go after the first one for damages.

Well I just have to chime in here & hope it helps more customers who might read this thread. It has been posted on this site MANY times to check out your vendor. Bad vendor = bad experience & therefore leads to the customer having a bad taste in their mouth with the manufacturer regardless if the platform is tried & true in the field.

I would like to thank Keep for joining our community & doing an outstanding job as well as keeping us all informed of the "experience" during this process. :toast:

That's the kicker. I did research the vendor, I read online reviews, I talked to previous installation sites. I did everything I could to ensure things should go as planned. Then they sent me a tech that had never done an installation as complex as ours. No way I could have foreseen that.

As for the vendor, I have requested that a new tech be sent out when they come back on site. I am awaiting to see if they do it.

As for my installation.

The ATA187's recommended to replace the ATA186's are not supported by my platform. The vendor is in the process of trying to determine how they were recommended when they should have been flagged as not compatible. In other words they are looking for someone to blame.

I was told that I could possible "trick" my equipment into using these devices by telling them they are a different piece of equipment. But I am not going to do that, no way I am going to hack a bunch of stuff to make equipment work when I can find a know adapter that will work.

I have located some new ATA186's near me and will probably be picking them up on Monday. The vendor cannot order them anymore as they are no longer supported, or supplied by Cisco. There are a ton of posts on the Cisco site about this blunder. And no solution for the small business guy in sight.

On the plus side, I go some of the optional features all setup and working, things like the One number reach and voicemail to email. Its pretty neat but I am not sure I want to be able to be contacted anywhere at anytime...lol Maybe I will disable that feature on my phone

Not really a lot of progress on the system this week, had a few other fires to put out on the IT side. I was also told by my Exec Director that there is "No real rush" on the phone system as its the slow time of the year for us and we have working phones at all the locations, but personally I would like this thing up and running and off my radar for a bit!

Is there an end in sight?

Its in sight, if you have really really good vision...lol

I picked up the ATA186's today. I will start to fight with them tomorrow. In Cisco's infinite wisdom, I as the end user cannot download the UC560 software package, without providing them a service contract number. The serial number registered to me for my new system is not enough, so I must wait until I can get a copy from my vendor.

This is needed to install the phone packages for the ATA's.

Other then that, its only scripting and AA tweaks then I can give them the go ahead to start porting numbers over.

I am going to see if they will allow me to cut locations over one at a time instead of all at once. This will allow me to track down any issues easier then if they all dropped at once.


Anyone know if I can link a DID to an AA submenu?

I would like to setup one main AA with each "program" having a submenu. Then I would like to have a DID point directly to that submenu. I have no clue if this is possible! If its not, then I will have to setup individual AA for each program, there would only be 4, but I like 1 better then 4 for admin purposes.

On Unity Connection, you just assign the DID as the extension that's assigned to the mailbox or call handler. I would assume your setup would be similar. In Call Manager, the DID is pointed at Unity via a CTI Route Point. I'm sure it's different in the UC560, but maybe the concept from Call Manager will get you going in the right direction.

Justin

I'm going to take a beating for saying this but I see a huge IT ego problem with keep, he took over this job when he should have insisted the company who sold the Cisco get a qualified/certified tech on the job now. There was no dead line for the cut over so he and his company had the time to demand from the seller to get the certified people and finish what was agreed on.

No beating coming. I admit, I hate having gear in my shop I do not know how to setup.

Since the main issue according to the vendor came from "Network setup" it was not under their install umbrella...so it fell to me to figure it all out without much support at all from the vendor. Even though throughout the entire process I was told it would work "No problem" with the way things were setup at the start.

There are aspects of this install I will not touch as its out of my comfort zone, items such as call plans, PRI setup and all that fun stuff is being left to the vendor, but all the network stuff got dropped in my lap.

In the end it will make me better able to support the system, but it sure does suck getting there!

As for my install.

I picked up 4 no longer supported, EOL ATA 186's from a local guy that had them on the shelf. Brought them here, added them to the UC database, plugged them in and they worked as they are supposed to.

I am still sitting here scratching my head trying to figure out why Cisco would EOL a product without a valid replacement for the UC system.

Oh and this marks the end of the hardware install at all locations. :banana:

Congratulation on that milestone. I don't have any criticism for you, other than for not giving the vendor more grief for the island they left you high and dry on. Other than that, you're darned right; this experience made you a better tech, and better able to support your envoironment. Now, get to learning the stuff that's out of your comfort zone; you owe it to yourself to do that, since you own much of the rest of the config.

Justin

You should go out and look for a job as a tech installing Cisco phone systems .... i know one vendor who would probably hire you!

Yeah I could have been harder on the vendor at the time, but after fighting without getting anywhere I gave up on that issue, until it was time for them to come back on site.

Though we are not done with the vendor on the installation they have already lost a shot at more money from our agency. But that is another story!

Not a lot going on with the install, all sites are up and we are doing internal testing between all the sites to see if we have any issues. Only items that have popped up are:

- one of the remote sites, if they dial another extension local to that site there is an echo, or its like talking to someone down a hallway.

- the MWI lights have stopped working, I do not know when along the way they stopped, but I have not had a chance to troubleshoot that one yet.

I hope your next post is "Finally the Nightmare is Over"