large IP phones deployment

[Hunt.Lee]

Hey guys,

I have a generic question of if I need to deploy say 2000 IP phones, what kind of stuff / tools I can use to standardize stuff? Is there any particular thing I need to watch out for / gotcha on large deployment as compared to small number of phones?

Thanks,

Hunt

[lfulgenzi]

We have pretty much completed our migration of over 7000 phones and we found it very efficient to scan the MAC addresses of the phones into a spreadsheet, and then copy them into the BAT templates while filling out the remaining information. Using phone templates, you configure the remaining information and then bulk load the phones. We bulk load the phones into a 'bulk load' partition which is not dialable, and then move them into the dialable partitions when the phones have been deployed.

Some people have used self registration, and that might work after a mass-migration for new phones, but we decided to go with BAT for a number of reasons. Many of our phones have multiple lines, and I'm not sure that's supported with auto-reg.

A few things I found was that you can't load phones with a phone button template of 1 line and no speed dials. It has to equal the number of buttons, so 1 line one speed dial on a 7940, or 2 line 4 speed dial on a 7960. We went back in and changed the phones to 1 line 0 speed dials.

[jasyoung]

As mentioned above, it's well established that BAT is the way to go for large deployments. Manual configuration of each phone is very time-consuming and error-prone. I second lfulgenzi's suggestion of initially importing the phones into an undialable partition if you're doing a gradual cutover from an old system (but there's no point if it's a "green field" new deployment).

Some people are okay with scanning in MAC addresses and importing those along with the phones. I don't understand that approach; TAPS is far easier. If you connect MAC addresses to phone profiles at import time, you have a stack of 7000 phones out of which you have to select one specific box and figure out the logistics to deliver it to Office 123, 3rd floor, Building 2, campus A, etc, 7000 times. If you use TAPS, you can do the exact same import with the exact same features, and all you have to deliver is the right type of phone - 7940 vs. 7960 vs. 7970, etc. It makes the physical delivery and installation of phones much easier and faster. There's some merit in scanning serial numbers this way, but you can also pick those off the phone's builtin webserver with a script once it's installed.

[lfulgenzi]

I think our concern was that you needed AutoReg enabled during the time you wanted to use TAPS, which meant anyone could plug in a phone and get an extension and then register an executive's extension. We saw this as a security risk. In addition, we wanted to deploy the phones on the desks of users fully working - we didn't want to go through the registration process while at the desk (optics I guess) and they didn't want to handle the phones 'twice' by going through TAPS in the inventory room then pack up the boxes.

We deployed our first 700 phones using TAPS and the next 700 phones uses Bulk Load with scanned MAC addresses. After comparing the two, we found option two more efficent (in our case).

As far as keeping track of the boxes, we scanned the MACs into a file along with the box numbers and then reversed them as we deployed into rooms. The students assigned the tasks of grabbing the boxes found it OK. I believe they wrote the extensions and names on the phone boxes before they actually deployed the phones too.

(All) that being said, TAPS is a slick product/process. You should try it out, and if you have a semi-secure area in which you can trust your users and they have the know-how, you might even be able to create instructions by which they register their own phones!

Lelio

[jasyoung]

lfulgenzi makes good and valid points above. It's a judgement call as to how you (the original poster) want to do it.

I'm (obviously) an advocate for the TAPS approach. We use it only to avoid having to associate phones to MACs at import and configuration time. We do the TAPS enrollment ourselves immediately when we place the phone instead of leaving it to the user. This helps in a number of situations. For instance, sometimes we don't have all (or any!) of the phones delivered yet when we want to do our import, so we don't have MAC addresses at all. We also don't have the benefit of student labor (which I would guess is free labor) to throw at the physical deployment part of the project.

There is some truth to the security concern, but in most large scale deployments, the initially imported phones will be disabled for incoming calls. Also, you can (and should!) stop the TAPS service when your installers aren't actively at work. You can also separate out executive/VIP phones for later import and more careful attention.

The TAPS service is the security-critical part of the equation, assuming you have properly configured your auto-registration setup such that those phones can't dial out. We've actually taken to setting up PLAR to the TAPS pilot number in the auto-registration CSS, such that all auto-registered phones immediately call TAPS when they go offhook. That saves a few seconds every time you go to register a phone.

If you deploy phones with the TAPS model and want the installers to do the enrollment, it is true here is a certain small efficiency loss. You have to either wait for the phone to boot up or come back later to do the TAPS enrollment. We typically walk back after deploying a block of 5 or 10 phones and enroll the ones behind us that have booted up and autoregistered. It takes almost no time at all to do the actual enrollment, on the order of 10-15 seconds.

If you have a well oiled "assembly line" operation deploying phones preconfigured with scanned MACs, it's probably possible to physically deploy a little faster. However, after lots of deployments in lots of different environments, we've had things get disorganized, phones get shipped to the wrong place, phones DOA out of the box, etc. We find the safety and flexibility afforded by TAPS deployment to outweigh the theoretical benefit of a perfect pre-scanned deployment.

[MARTIN STREULE]

Maybe we were just unlucky with the releases, but we had compatibility problems "TAPS/CSA".

TAPS also broke the "user/phone association" which caused almost more work then not using TAPS at all.

(The SEP-MAC address was not updated in DCD).

[jasyoung]

If you were using CallManager 3.3(3), there's a whole raft of issues with TAPS. Most have fixes or workarounds.

First, the service won't start if the JVM version isn't right. That's CSCeb20345, for which the workaround is to point it to a different version of the JVM in a different directory. Then you have CSCeb75001, wherein the workaround described in CSCeb20345 itself has a bug, so you need to apply both.

Then of course you noticed that CSA wants to shoot it down. That would be CSCee36705, which is fixed by upgrading CSA with a new policy.

And I've not personally run into the bug you mention where devices aren't reassociated, but a quick search reveals CSCec26063, which says something very much like that happens at least with CallManager 3.3(3)sr1.