What kind system is this on? On our 406v1 I had to do the same as was suggested in going to 3.1.65 which was shut off the system, disconnect all modules, T1, PRI, power on and upgrade from a PC connected directly to the 8 port switch. Then after a successful upgrade, power off, reconnect everything and then power on and upgrade the other modules.
Note to self. If you were one of those folks who have two versions of Manager on your Machine. That's a big NO NO.
Here's the weird thing the box hung at the reboot stage. After the upgrade started. I closed my 3.2 version of manager and launch my 2.1 version of manager and with out even logging in it started to upload the (now here's the weird part) version from the working directory that was a new folder that I just created. What's weird is this. I changed the working directory in the 3.2 Manager and doing that automatically changed it in the 2.1 manager.
So the moral of the story is you no longer can have both versions installed.
Need to validate that theroy by...
removing 2.1 from this machine.
uninstall the 3.2 app.
delete the 2.1 manager directory.
wack the registry entries for everything IP Office
reboot
reinstall the 3.2 manager app
test
hmmm now I'm stumped then. Becasue it was a brand new out of the box 406V2 that once the upgrade failed I figured it couldn't hurt to default it via the manager App
I have 7 versions of Manager/Call Status/Monitor/Phone Manger on my laptop and it has never caused and issue.
I have Alchemy 2.2(33), IPO 2.0(18), 2.1(73), 3.0(573)DT, 3.0(69), 3.1(65) & 3.2(17).
Changing the working directory on one does change the settings for the others as these are stored in the registry.
Has any one used 3.2 Manager to upgrade pre 3.2 systems.
ie
2.1>3.0 3.1(56)>3.1(65) etc
I would use the correct Manager for doing upgrades and also the correct Call Status/Monitor but would love to get rid of these from my laptop and remote PC in the office.
Jamie Green
Fooball is not a matter of life and death-It is far more important!!!!
We have done upgrades to lower firmware versiones ie. 2.1 3.1 via the 3.2 manager App but not with a machine running multiple versions of Manager this was are first one and it didn't go that well as you can see.
After everything went south during my first series of upgrades. This particular machine needed to be upgraded to a private build for intuity integration. 3.1 (65xxx)
I thought I'd give it one more shot to upgrade to this version with out uninstalling the other apps. I rebooted my laptop and ran the upgrade from 3.1 65 to the private build via the 3.2 manager app and it worked perfectly. Not sure if there is some bug. the one thing that I did wrond with the initial upgrade was I had Validate ticked on. That casued my origianl upgrade to fail. Retracing my steps I tried twice to upgrade with validate on. Then I defaulted the switch via manager then ticked off validate and that's when I had my first issue. The 406V2 was originally at 2.1 27. I first attempted to upgrade to 2.1 73. That was the upgrade that failed.
I don,t program everything under 3.2 with 3.2 because it will change things you don,t want but use it to check if there are problems in a config."
V3.2 Manager is Backwards compatible to V2.1 & will reconfigure itself depending on the config it has downloaded
it can be used to programm all systems V2.1 & above.
I don,t program everything under 3.2 with 3.2 because it will change things you don,t want but use it to check if there are problems in a config."
What will it change? i could see how it may open sectors in memory that don't exist in 2.1 but those fields should be blank and shouldn't upset the config. should it?
V3.2 would not even populate areas of the cfg the V2.1 did not use (v3.0 & V3.1 would & this DID cause issues)
V3.2 is designed to be used for al releasses from V2.1 upwards.
the prefered manager is V3.2 because this avoids the possibility of an engineer accidently using the incorrect manager & causing major problems (again this has happened on more than 1 ocasion)
Not trying to beat a dead horse but I still don't understand why you wouldn't want to use the 3.2 app to administer previous versions. Is it not truly backwards compatible?
And as far as the upgrades are concerned it's not changing configs, i don't see why it would hose a config.
I have not installed 3.2 manager, or implemented, or upgraded any system to 3.2, so this converstaion is very interesting. I am figuring I will wait until you guys beta test 3.2 before I move from the cutting edge to the bleeding edge.
I still think I would follow the upgrade path to 3.1.65 including the intermediate upgrades when needed. Then upgrade to 3.2, just because it would seem to be less reliant on the unseasoned 3.2 manager.
I do not upgrade except to fix known issues with the current release features that are in use, or to add desired features from the new release.
Am I too cautious? I have found some upgrades have some nice fixes, and some painfull breaks built in.
You do not always get what you pay for, but you never get what you do not pay for.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.