Bulk Deployment Utility & 7925G wireless phones...

[John.Gerlach]

I had a hard time determining the best location to post this one since this has components in wireless, IPT, and authentication.  But the root of my problem is actually a time issue.  If there is a better area to post this please let me know.

We have begun to test the Cisco 7925G wireless phones on our network and are looking forward to deploying them en masse.  There is a Bulk Deployment Utility that looks like it meets our needs and the general idea is to easily connect to the wireless network, pull down and apply a template generated by the Bulk Deployment Utility from a TFTP server, and restart the phone.  When the phone restarts it would be configured to connect to the production wireless voice network and should authenticate with the stored profile credentials in the template that was applied.  After completing authentication the phone would contact the Call Manager in the DHCP scope and should begin downloading firmware to replace the MFG firmware the new units are shipping with.  This is the part that fails and from what I can tell it is because the wireless authentication is failing since the date on a newly powered up phone is 02/01/00.  I am able to work around this by connecting the phone to a PC via the USB interface, browsing to the phone, entering the default admin credentials, and changing the time and date.  After I do that, then the wireless authentication is able to complete and the the new firmware from the Call Manager is downloaded, the phone reboots and completes the connection to the Call Manager.

Has anyone had to deal with a situation like this?  If I can find a way for the 7925G to update its time to a time server or Cisco switch I believe everything would work exactly the way we were hoping.  And I did try using option 4 in the DHCP scope to see if I could grab a current time from a Microsoft Domain Controller but that didn't seem to get referenced or used.

We are hoping that we can avoid manually touching each phone just to set the time.  We will need to be doing this to add in per-device credentials but it would be a big timesaver if we could just power on 10 phones and walk away for a while and just have to enter in the final credentials later.

Thanks.

[John.Gerlach]

I think I may have resolved this - I used the Cisco switch as the time source instead of a Microsoft Domain Controller and it began downloading the firmware.

[John.Gerlach]

Unfortunately, my earlier bit of success appears to be an anomaly and I have been unable to recreate.  One phone after one hour of trying downloaded updated firmware.  The system time even updated although it is still way off from current time (it now reads 11/29/10).  I've had another phone repeatedly trying for the past 4 hours but no movement on that one.

[wsulzer]

Hi guys
of course it's probably not relevant any more.
However, I had a similar problem:
TFTP download of the WLANDefault.xml to the 792x worked, but the config was never taken over. The ip phone downloaded the file again and again, but the new ssid from the xml file was never taken over. The reason was the WPA pre-shared key was too short.
As soon as the WPA pre-shared key had a valid length, all worked well.

Hope this helps.

[#5]

It's probably really not relevant any more.

But, I also had a similar problem just like wsulzer, specifically in regards to using pre-shared keys. I would see the TFTP download of WLANDefault, but the config on the phones never changed. Our pre-shared key is an ASCII key.

It only began working after I changed the PreSharedKeyType to Hex instead of ASCII in the bulk update tool. After resetting the phone, boom, there was my new network profile.

What’s really strange though is when I look at the WLAN config in the phone it shows that the Key Style is set to ASCII.

So it looks like the bulk update tool has the PreSharedKeyType values flipped. When you choose ASCII, it actually sets it to Hex in the WLANDefault.xml file. When you choose Hex it actually sets it to ASCII.

So why it was failing before was because when the phone grabbed it’s config from the TFTP server it saw the Key was set to Hex, but the key wasn’t a valid Hex value so it refused the file. Now, it sees the key is set to ASCII and has a valid ASCII value, and so it accepts the file and updates the profiles on the phone.

Hopefully this saves someone from having to struggle with this like I did.

[Leo Laohoo]

I use the USB because it's the only way for the wireless credentials get entered correctly.

[John.Gerlach]

Thanks for the reply.  We are hoping to avoid the USB connection if we can.  Then we could have multiple people staging phones and not have to have a computer available for each phone we are simultaneously working on.

Within the last 30 minutes I figured out that my issue doesn't appear to be time at all.  After the device initially connects to the network and pulls down the config file I just had to reboot the phone.   That is where I was getting stuck.  It looked like it was trying to establish a connection after the new config file was applied but it is possible the new profile may not have been active until a restart.  At least it is consistent in its behavior.

1) Grab new phone, insert battery or connect power

2) Power on the device - it connects to the 'cisco' ssid and pulls down and applies config from WLANDefault.xml file which it pulls from the TFTP server (IP address specified in DHCP Option 150).

3) Reboot the phone

4) Phone connects to the production network and pulls down the latest firmware.

Date never completely syncs up but I believe that will occur once the phones are defined on the Call Manager and phone registration completes.

I still need to test out the Bulk Export option (per MAC address user credentials) in the Bulk Deployment Utility then hopefully I can hand all of this off. 

Leolaohoo, since you use the USB option does that imply that you have tried the Bulk Export option and just decided it was too much of a pain to use?

Thanks.

[Leo Laohoo]

Didn't try the bulk option because we get 3 or so phone requests.  So I didn't really consider this. 

[Ven Taylor]

I'm stuck on the wlandefault.xml portion.

I've used the utility to create the file, but it's always corrupt.

My settings were simple enough. 

  SSID is CALLME

security is open WEP with a 128bit key

pulling DHCP.

Every time I delete and re-create the file, it's corrupt.

Thoughts?

Maybe someone send me a non-corrupt xml file that I can just edit to meet my needs??

Thanks!

Ven

[John.Gerlach]

Are you sure it is a corrupt profile?  I know when I save my XML files I am prompted for a password and then the file is encrypted to obscure any sensitive data contained within it such as login names, passwords, or WEP keys.  I just recently had to remember how I got all of this working since the people I handed it off to waited until the last minute to test out the process.  But it does work I can tell you that - we just did a nice batch of 60-65 phones yesterday using the Bulk Export (per MAC address) configs.

Are your phones attempting to download the WLANDefault.xml file from your DHCP server?  Or where does it appear you are breaking down?

[Ven Taylor]

Thanks for the reply.  I JUST NOW figured out the flaw in my process.

I was winging it because the documentation was pretty scarce.

I didn't realize you had to add the mac address into the userinfo.csv file.

Once I did that, the phone grabbed the config, automatically rebooted, and was registered with our CM.

Go figure... When you do it right, it just works. 

Two phones down.  Solid documentation done.

198 more phones to go.

Ven

[John Powell]

Perhaps you can help out with my issue:

I created the WLANDefault.xml file, copied to the TFTP server and booted the phone.  I see in TFTP server log that the WLANDefault.xml fiel is sent.  THis is where I seem to go nowhere...the phone does not reboot and a quick check of the profile shows the default config is still on the phone.  Any ideas?

[Ven Taylor]

Funny you should mention that.  I had the same exact problem.

Did you add your mac addresses to the userinfo.csv file?

If your phones are factory fresh or factory reset, just create an excel file called userinfo.csv

You should have three headers

In cell 1A, put the word MAC.

In cell 1B, put the word Username

In cell 1C, put the word Password

In column 1 (under MAC) put all your mac addresses.

In column 2, (under Username) put the word admin

In column 3, (under Password) put the word Cisco

Once you do this, save that file.  To make it simple, I just pointed my tftp server software to the Cisco Systems/7921BD directory.

Now open the Bulk Deployment Utility again, then choose your settings, then choose File / Bulk Export.

This should create a monkey-buttload of xml files with the name WLANXXXXXXX.xml (XXXXX is the mac address of each phone).

Once this is done, you can power on your phones and watch the magic.

Ven

[John.Gerlach]

I just wanted to double-check that you are manually restarting the phones after the phones pull down the WLANDefault.xml file from the TFTP server.  That hung me up for too long when I was first trying to figure this all out.  I was expecting that once the phone downloaded the config that it would automatically reboot using the new config.  That didn't happen but usually you could see the new profile info in the phone prior to the restart so I am a little puzzled there.  But then typically a manual restart of the phone finished off the process and the phone would start back up using the new downloaded configuration.

Since you are trying to use the WLANDefault.xml file I assume you are trying to push the same configuration (including shared credentials?) to all phones right?  And are you trying to use Profile1 on the phones?  I am aware of a requirement when using per phone (MAC address) configuration files where it is only able to apply user credential information from your CSV file to the first profile, I am not sure if that is an issue when using the WLANDefault.xml configuration file though.

[Ven Taylor]

John:

I never had to do that.  The phones downloaded their proper config, then automatically rebooted.

I had a few hang up because my dhcp scope was full (had to adjust my reservation timer) but other than that, I was good to go.