Can we return to previous version of AES if we already give command
upgrade -p

?

In bundled server, the previous release is in /root2, so it is possible, but not recommended and not supported. Also you will need some knowledge of linux boot and lilo. The bundled server has active partition(current /) and standby partition(/root2). you can see these partitions and mount points by using df command. AnywayTo back to the previous release, edit lilo.conf to boot into the partition of /root2 and type "/sbin/lilo". Please be careful, you may lose current release.

Thanks
hj

Hi again,

The method described in my previous mail is possible only when you upraded between the same release, for example upgrade from 3.1.3 to 3.1.3 or from 4.0 to 4.0. If you upgraded from 3.1.x to 4.0, then there is no way to recover the previous one.

Thanks

hj

I find which partition I need to be aactive. Now it's sda6, but I need sda1. But I can't edit /etc/lilo.conf without root access. Sroot can't edit this file.

sroot is a superuser account same as root, sroot can edit or change the permission of any file inside server.

thanks

hj

that was my fault. now i change it and get back to 3.0.

as i understand at this time we can't generate upgrade license from 3.0 to 3.1? and should upgrade to 4.0?

No, I think the license is compatible between 3.0 and 3.1, but if you upgrade from 3.x to 4.0, you will need new license for 4.0.

thanks

hj

No, license not the same. and avaya have doc called "RFA License Changes for 3.0 and 3.1 February 2006 RFA Release"
and here some words from this doc.
The following upgrade situations will always require a new license:

--   Upgrade to 3.1 when AES is used for CMAPI applications.
--   Upgrade to 3.1 with existing Advanced TSAPI licenses.


we use adv tsapi. and it doesn't work. thats why i want to get back.

When a 3.0 system is upgraded to 3.1, a migration code will be provided according to ASD rules for systems with existing TSAPI Advanced licenses. This migration code will set the AEC_XX_ADVANCED feature only, in a quantity of 1 for the CM platform it is designed on. It will not set TSAPI_ADVANCED_USERS as that feature should already be set based on the original purchase.
If an Advanced TSAPI migration code is placed on a design by ASD, but no ADVANCED RTUs exist in the 3.0 license, TSAPI Advanced functionality will fail due to the lack of TSAPI_ADVANCED RTU. A purchase of TSAPI Advanced 3.1 licenses will be required in this case.

now we have 85 qt. adv tsapi users, but from 3.1 we need 1qt AES_SMALL_ADVANCED

I would recommend you to work with your DevConnect representative to understand the licensing intricacies of TSAPI on various releases.

Thanks

hj