Content Server Upgradation

Reply 1
Upgrading should of course work, but there are tons of situations where it doesn't.
Anyway, we have done several migrations to new server recently, and tried this approach, without encountering any problems

1. Install a new contentserver with version 6.5SP1
2. Create new repository with same name and id.
3. Stop repository
4. Rename data area on disc, copy data from old contentserver
5. Restore database backup from old contentserver to new database.
6. Run script to clear crypo information, see below.
7. Modify dm_location pointers if necessary due to change in disk letters
8. Modify the dm_location object point to 5.3\fusion\fusion.exe to point to 6.5\fusion\fusion.exe
9. Modify dm_mount_point objects if necessary
10. Update dm_job target_server attribute to reflect changes
11. Start repository
12. Run repository upgrade from Document Server Manager

This has worked nicely for us on several occasions.
One thing you have to consider thoroughly is the global bof registry.
There are many scenarios here

1. You have none or an own in your 5.3 environment -> Create a new one in 6.5
2. Your repository is also global bof. This has been a bit tricky on one occasion.
Basically, the main point was NOT designate the global bof registry during the installation of the new repository on 6.5,
but follow the instructions on how to designate this later

Reply 2

This one has been posted MANY time, and I've translated this into SQL statements,

/*

1. Shutdown all the repositories on the target server

2. Backup the database

3. Rename the AEK file or rename it and move it some where else

4. From sql on the database update dm_docbase_config_s set i_crypto_key = ' '

5. From sql on the database update dm_docbase_config_s set i_ticket_crypto_key = ' '

6. from sql: SQL> select r_object_id from dmi_vstamp_s where i_application = 'dm_docbase_config_crypto_key_init';

7. delete from dmi_object_type where r_object_id = 'returned r_object_id from above';

8. SQL> commit;

9. SQL> delete from dmi_vstamp_s where r_object_id = 'returned r_object_id from step above'

10. SQL> commit;

11. SQL> select r_object_id from dmi_vstamp_s where i_application = ¿dm_docbase_config_ticket_crypto_key_init¿;

12. SQL> delete from dmi_object_type where r_object_id = 'returned r_object_id from above';

13. SQL> delete from dmi_vstamp_s where r_object_id = 'returned r_object_id from step above'

14. SQL> commit

15. run this file from $DM_HOME/bin: dm_crypto_create  THIS WAS NOT DONE!!

16. - To re-encrypt the dbpasswd.txt file do the following

cd $DM_HOME/bin

17. dm_encrypt_password -repository <repository name> -rdbms -encrypt <database password>

18. You need to do all modification on the database for each repository NOT just step 15!!

19. Startup the repositories.

*/

update dm_docbase_config_s set i_crypto_key = ''

update dm_docbase_config_s set i_ticket_crypto_key = ''

delete from dmi_object_type where r_object_id in (

select r_object_id from dmi_vstamp_s where i_application = 'dm_docbase_config_crypto_key_init')

delete from dmi_vstamp_s where r_object_id in (

select r_object_id from dmi_vstamp_s where i_application = 'dm_docbase_config_crypto_key_init')

delete from dmi_object_type where r_object_id in

(select r_object_id from dmi_vstamp_s where i_application = 'dm_docbase_config_ticket_crypto_key_init')

delete from dmi_vstamp_s where r_object_id in

(select r_object_id from dmi_vstamp_s where i_application = 'dm_docbase_config_ticket_crypto_key_init')

delete from dm_cryptographic_key_s

delete from dm_public_key_certificate_s

Reply 3
>>>2. Create new repository with same name and id.

This process is commonly called cloning, and described in several thread and support notes, I think.
Basically, you do need to install a dummy repository with same id and name to
prepare the new content server by means of registry settings etc etc etc.
The data files and db for this dummy can be simply ignore

4. Rename data area on disc,

Basically, you could even delete it, as it is going to be replaced with the data area from
the original content server. I prefer to rename it, in case of failure, you can simply
go back without starting the entire process from scratch

copy data from old contentserver

See above, you overwrite the data area on your new content server. At this point,
you simply restore a backup of your original cs into the db of your new one.
Dba can fix this for you in a second, not my strongest side, I'm afraid

Does this mean to copy the data directory from the 5.3 system?
i.e Copy D:\Documentum\data\REPOSITORY\content_storage_01, >>>replica_content_storage_01, replicate_temp_store, streaming_storage_01, >>>thumbnail_storage_01 etc to the new D65 Data directory?

Exactly

12. Run repository upgrade from Document Server Manager

Since you have already created a 6.5 repository and mapped the data restored to
database why do you have to perform the step 12?

Your database and content files are still in 5.3 format, even if the CS is 6.5.
Running this step upgraded db tables etc etc, so that you have a true 6.5 repository.

Do you think this approch will work for an upgrade from 5.2.5 to 5.3?

Absolutely, we've done it this way very often, and that was the reason why we
tried this from 5.3SP5 to 6.5SP1 directly.


Content Server logs file location

he Content Server installer and configuration program both create log files. The log files may be stored in one of the following directories:

• The current working directory. For the installation program, the current working directory is the directory from which you started the program. For the configuration program, the current working directory is typically $DM_HOME/install (UNIX) or %DM_HOME%\install (Windows).
• The parent directory of the installation directory, if the installation owner does not have write permission on the current working directory.
• The user's home directory, if the installation owner does not have write permission on the parent directory.

The log filenames are install.log and installation_owner_username.ServerConfigurator.log. Each script that runs during repository configuration creates a log file. These are stored in the $DOCUMENTUM/dba/config/repository_name directory.

Content Server stores other log files in the $DOCUMENTUM/dba/log directory. After you install or upgrade Content Server, examine the log file for the repository for error reports. The log is called repository_name.log.save.date.time. repository_name is the name of the repository you created or upgraded, and date and time are the date and time the log was saved.

Another log file is $DM_HOME/install/SetupError.log, which contains information about the operating system environment, the Content Server version, Java environment and hardware.