Cisco IP Phone load for 7940/7960 IP Phone - Compatible CCM Version: 3.3 Version: 3.3(3) Released: 23-MAY-2003
Cisco IP Phone load for 7940/7960 IP Phone - Compatible CCM Version: 3.3 version: 3.3(4) Released: 07-JUL-2003
Cisco IP Phone load for 7940/7960 IP Phone - Compatible CCM Version: 3.1, 3.2 & 3.3 version: 5.0(1) Released: 07-JUL-2003
Any ideas what version we should use? I am currently using P00303030202 on Callmanager 3.3(2)
I found release notes for P00305000101
Hi Jeff -
We just installed 3.3(3) in our test lab, upgrading from 3.3(2). New phone loads came with the upgrade, specifically for the 7940/7960 - P00303030401. We are installing this into production tomorrow evening. We have also seen the new phone load / release notes for P00305000101. We have decided to hold off for now, because the firmware releases use signed binary files. Once you have upgraded to these loads, there is no downgrading to an earlier software release. This is mentioned in page 3 of the notes.
I did the same install in my test lab today and noticed the default phone load. I did upgrade my test phone to the P00305000101 to see if there was any noticable difference between P00305000101 and P00303030401. I agree I might hold off for now on going to the P00305000101 since you cannot go back if there is a problem. Let me know how your production install goes? Also do you use MLA (Multi Level Admin) I had it on my test system and when the 3.3(3) install was finished it removed it. I am wondering if this is a fluke or if we will need to reinstall it when I install in my production cluster...
Hi Jeff, I work with Ginger and MLA is listed in the compatibility matrix on CCO as supported when available. There was no date yet, but I hope it is not too long. We do use MLA in production, but we can do without it for a short time. MLA seems to always be out of sync with the upgrades. Like missing icons for 7912 phones. The software update for the 7912 phone installs the icons into the normal image folder, but it does not place a copy in the MLA image folder. No biggie, just something you spend time debugging.
We completed the CM 3.3.3 and OS 2.4 upgrade successfully. Everything is looking very good and no problems yet. We had a couple of issues during the upgrade.
1. The upgrade notes suggest that you can completely upgrade the Publisher before you start the subscribers, which is always the case with the CM upgrades. However, we needed to upgrade to OS 2.4 on all the servers before the Upgrade assistant would give us a passing score. After we installed OS 2.4 and the SR4 maintenance and the Backup 3.5(44) upgrade, we ran the upgrade assistant and it puked on broken SQL subscriptions. Sure enough all the replication pulls had failed on the subscribers. We decided to continue with the OS upgrade process on the subscribers. After we installed the same maintenance on the subscribers the replication pulls were back working. I am not sure if it was the maintenance or just rebooting the subscriber. But after we got all the servers in the cluster upgraded to OS 2.4, the upgrade assistant on the Publisher gave us a passing score. We continue with the install of CM 3.3.3 with no problems. Note: We did not re-install the new SQL sp3 maintenance since we all ready installed the SQL sp3 on OS 2.3.
2. The second issue is with MLA. The compatibility matrix indicates MLA support will be later. We opened a TAC case to verify and the TAC engineer said no problem go ahead and install MLA 1.2 with spA on CM 3.3.3. We did in our test lab and it worked. So, we installed in on our production system. Everything seemed to go well with the install, but the MLA process that reads the DC directory was failing to make the connection. We had the same problem when we installed MLA on CM 3.3(2). A Cisco developer ended up dialing into our system and updated the permission with the CCMUser account or at least that is what understand. We can log into CM using the CCMAdministrator account, but you can not access the user accounts for MLA. I know this will be fixable once we get in contact with the same developer. But, another TAC engineer advised us not to install MLA on CM 3.3.3 until the supported release is available towards the end of July. I did notice that MLA 1.2 does not have any of the new web pages that CM 3.3.3 added to the system. So we are going to uninstall MLA and wait for supported release of MLA, which is a bummer. We can get by without MLA, but that means I have to do all the work with MACs instead of the department support folks.
A cool new feature that was added to the gateway search page is the Related Dependencies. You click on the link and it pops up a window with all the related data, such as route groups or DNs on ports. Too cool!
All and all the upgrade went very smoothly. A bunch of reboots and time consuming, but most importantly it all worked and we still have a stable voice network with +500 phones and three CM servers and a bunch of gateways.
There are big problems with this upgrade if you do not removed the AD integration from the pub and subs before running the upgrade. I was burned by this myself and I am still trying to recover from it.
Use the AD plugin to remove the CCMs from the AD structure before even trying the upgrade! Cisco does not properly document this and it caused a major setback in my upgrade.
Can you please elaborate on your issues.. Because in my test lab I ran the upgrade with the AD plug in install and it went fine...
One other thing Cisco recommends is that you remove the machine as a member of a domain... Again in my test lab I did not and everything went fine...
What basically happened is that I did not uninstall AD integration before going ahead with the upgrade - although I did remove the machines from a domain.
When i first tried to do the upgrade the installation failed when trying to upgrade DC directory. After that point, even when I had removed AD intergration from the pub and the sub, the install still continued to fail at the same point (DC Directory install).
Since the pilot points are controlled by the AC user, all of my reception groups were down now as a result of removal of AD intergration and problems with the existing DC directory.
I had to "deletedib" and "avvid_restore_cfg" and replicate those changes to the sub in order to bring the DC directory database to a baseline. Once I made those changes it was sufficient for the upgrade installer to complete it's upgrade of DC directory and go on to CallManager and other related services.
I did troubleshoot this with a very helpful TAC engineer and we eventually got through it.
I don't know whether other people would have this problem or not, since we have been working with the same dataset since 3.1 when we were orignially using DC directory, but we have long since been intergrated with AD for all our needs.
When you began the upgrade, were the DC Directory services disabled?
Can you go into more detail on the "deletedib" and "avvid_restore_cfg"?
I am worried I am going to have the same problem. I have been on Active Directory integration since early 3.2 and don't even know what my DC Directory admin password is!
You probably won't run into any problems, but if you do when trying to upgrade to 3.3(3) do the following and it should work - otherwise contact the TAC.
1.) Uninstall AD integration on pub and subs using the plugin - reboot.
2.) on publisher, wipe the DC directory database by using the command "deletedib" at the CMD prompt
3.) restore the dc directory database from a baseline using the command "avvid_migrate_cfg
4.) migrate the changes to the sub by using the DCD script "reconfigure_cluster" (note: your Pilot points will be down at this point as they cannot access the "ac" user)
5.) install 3.3(3) upgrade as per cisco documents
6.) after successful upgrade, reintergrate with AD as per cisco documents
It worked for me!
I was re-reading the posts here and although the AD integration did not apply to us, I remember reading in the release notes the CallManager 3.3(3) upgrade requires schema updates to Active Directory. Sounds like the plug-in will load an *.ldf script and require Schema Master authority to make the updates to AD.