Book Contents

Book Index

Methodology for K2 program reinstallation

Book Contents

Book Index

Introduction

You will get acquainted with the graphical form of individual steps of reinstallation in the form of a diagram.

Book Contents

Book Index

Dictionary of terms

Reinstallation Manager is a function of K2 that helps with the reinstallation of K2.

License management is a function of K2 that will be used in this document to remotely log off users from  K2.

SQL Server Management Studio (SSMS) is a Microsoft® product that is used to manage MS SQL servers and databases.

Oracle SQL Developer is an Oracle Corporation® product that is used to manage Oracle servers and databases.

Reinstallation of build type - small is the type of reinstallation, when only the last number of the version, the so-called build, is changed. This type should only solve bug fixes and add minor improvements. This reinstallation should not endanger the existing functionality. No identifiers that are used in scripts are removed unless they are evaluated as incorrect. As an example, we will give the omission of canceling the identifier when upgrading to a higher release or generation version. Use may result in unwanted behavior or algorithm error.

Reinstallation of the release type - medium is a type of reinstallation when the middle number of the version, the so-called release, is changed. New functionalities can be added to individual releases. The same rules apply as in the previous - "small" reinstallation, with the difference that it is advisable to perform a test reinstallation before the reinstallation itself and then test the key functions of K2.

Reinstallation of Generation version type - large is the type of reinstallation when the first number of the version is changed. This is a fundamental change, when completely new functionalities are added to K2 or the existing ones are fundamentally redesigned or canceled. This type always requires reinstallation in a test environment, as situations can occur especially during conversions that cannot be reliably treated in laboratory conditions during development. The reinstallation of the production K2 is thus performed first in the test environment, when the test folder is taken over, and after testing and debugging of all conversions and functionalities, the reinstallation is then performed on the production K2.

The application server (AS) is a non-visual superstructure of K2, which performs automatic tasks, scheduled tasks, communicates with other K2 products, eg web services server (SWS), serves web client, etc.

Taking over an existing installation is a state where the folder with the K2 is used for a new installation. This situation should not normally occur because of the installationthe Windows mechanism retains all the msi files from which it installed in the system folders and information in the registry until the program is uninstalled. It  follows from the logic of the matter that constantly downloading one K2 will  weed out the registry and reduce the space on the system disk by the size of the msi file with  each reinstallation. Another consequence is that there are multiple records of installation in the records of theK2 installer, even if there is only one K2. Maximum number of records for K2 instances is 100, and no more instances can be added any more.

When to use takeover?

  1. When you create a test environment and copy the complete production K2 to the new folder.
  2. We are installing from  a different computer than before. You still need to be careful because installing from  multiple computers in a network environment can cause file inconsistencies.
  3. When the removing the original K2 during reinstallation was failed.
  4. If an error occurs during the reinstallation in the installation phase and the installation terminates unexpectedly.

Book Contents

Book Index

Create a test environment for reinstallation

There are several ways to create a test environment so  that you can reinstall a folder. The minimum condition for the folder to be considered as K2 is the presence of the files k2.ini and sysk2.ini and the data in them refer to the existing server and database. However, an optimally prepared test environment is performed by creating a copy of sharp databases on database servers, it can be  within one SQLserver or the data can be transferred to another one, by copying the folder of the sharp K2 to a new folder and by overwriting the link to the database, or the server, in the k2.ini The copy created in this way is identical to the sharp K2 and thus all possible problems can be solved before reinstalling the sharp K2. Adjustments in  the data, which must be done during the test reinstallation, so that, eg. conversions take place without errors,can be done, and it is also recommended, in parallel to the test, and in operation.

When creating a test K2, it is a good idea to consider whether you need to transfer all databases or schemas. For test reinstallation, it is advisable to use only databases of sharp clients. There is no need to make copies of DEMO, INIT or test clients. E.g. the sharp K2 contains the following clients: DEMO (demonstration database supplied by K2), INIT (demonstration database supplied by K2), COMPANY (production database), COMPANY2 (production database of another company or branch), COMPANY2_TEST (test database created by a copy of COMPANY2). In this case, only COMPANY and COMPANY2 clients are used for testing purposes. Other databases are not needed. However, if only some databases are copied, you must modify the COMPANY table in the configuration database. This can be done either by directly editing the tables using SQL queries, or by editing the table with a tool such as SSMS, or in database administration in the K2. It is important that the company table only contains records that match the databases used in the test.

Book Contents

Book Index

Reinstallation procedure

Book Contents

Book Index

Scheme

The scheme is designed so that it can be applied to any situation where it is necessary to reinstall K2.

pic_4969.png

Picture: K2 reinstallation scheme

The scheme in its main branch shows the reinstallation without any problems on the installed K2.

The other branches, which you will find in chapters Check of required initialization of version Check of all databases structures and Update extensions, come in a non-standard situation.

Book Contents

Book Index

Colors and shapes of blocks in the scheme

pic_4959

The beginning or the end of the scheme or subscheme.

pic_4960.png

A decision block, when the scheme branches according to the specified condition.

pic_4962.png

A block of the process. Performing an action.

pic_4963.png

A block of the subprocess. A subprocess contains a subschema that contains multiple actions.

pic_4966.png

Indicator of the direction of the scheme, including the result of the decision when this branch occurs.

Book Contents

Book Index

Use of the scheme

The scheme in its main branch shows the reinstallation without any problems on the installed K2.

Other branches come in a non-standard situation. Non-standard situations are understood when the reinstallation has been performed only partially, there was a problem during the removal of the previous version, a copy of the production K2 was created in order to test the reinstallation, etc.

Book Contents

Book Index

Individual steps of reinstallation

In order for the diagram to be complete, it is necessary to explain each step of the reinstallation. You will learn what needs to be done at each level, what the troubleshooting options are, or where to find support  resources problem solution.

Book Contents

Book Index

Decision making: Is the executable K2 available?

Decisive person: IS K2 administrator

Description: Executable K2 means the state when the complete K2 is located in the folder, which can be executed and can be used in it. At this point, it does not matter whether the folder was created by the installation or copied from the operating K2 as a copy. If the K2 is executable, continue with the point Plan the reinstallation, if it is not, continue with the point Decision making: The databases are identical to the installed K2 version.

Book Contents

Book Index

Plan the reinstallation

Location: Information system K2

Start: IS K2 administrator

Authorization: Right - Administrator/General/Service actions (right number 1)

Condition: An optional action, this is a manufacturer's recommendation

Description: During The reinstallation, no users must be logged in to K2, so that there will be no conflicts when writing files or changing data after the backups and the entire preparation for the reinstallation have been performed. To avoid unnecessary problems with logged-in users before the reinstallation, it is possible to schedule the date and time of the reinstallation directly in the K2. This functionality ensures that no one, except the user who set this status, logs in to K2 from the set date. Users who log in before the deadline are notified that a reinstallation will be performed from a certain date.

"Reinstallation Manager" tool in K2 is used to schedule the reinstallation. It is available in the tree menu "Administrator / System / Reinstall manager" or as a function  number 753.

pic_4936.png

Picture: Reinstallation manager

After checking the "Login prohibited" option, the date, time and message, that should be displayed to users who want to log in to K2, will be set.

pic_4937.png

Picture: Setting the date and time of reinstallation

When subsequent login attempt, users receive a message that is set up in the reinstallation manager. This message can be changed as desired. If it is necessary to display the date and time from, %s will be added to the text, which  will be automatically replaced in the message by the value from the Login prohibited from field.

pic_4938.png

Picture: Report of scheduled reinstallation

Book Contents

Book Index

Log off all users

Location: Information system K2

Start: IS K2 administrator

Authorization: Right - Administrator/General/Service actions (right number 1)

Condition: Mandatory action - cannot be reinstalled if  users are logged in to K2

Description: All K2 users must be logged out before the reinstallation. Their list and the possibility to log out can then be found in the "License Administration",  which is available  in the "Administrator / System / License Administration" menu or as the function number 678.

pic_4939.png

Picture: Licence administration and logged-in users

To log off the user, open the record detail and press the "Log off" button. Advantageously, running application servers can be shut down in this way without the need to connect to computers where the AS is running.

pic_4940

Picture: The logout users from the K2

Note

It is up to the administrator whether to disconnect the user directly from the form or to find out for each person in person if they have any records in progress. By pressing "Log off" button a user will be logged off without saving records in progress.

There may be situation where the user cannot log out under any circumstances and, in addition, it is found that the user does definitely not have the running K2. In this case, you need to "kill" the session on the SQL server. To find users on MS SQL, the sp_who command is used, which lists the table with  existing connections to the server.

pic_4941

Picture: List of connections with MS SQL server

To terminate the relevant connection, it is necessary to know which database the user, who is not logged-out, is connecting to. Usually there are one or two records in the statement, depending on how many connections remain "hanging". The spid, status, loginame, hostname, dbname, and cmd columns are important. The spid column is the connection number we need to know to terminate it, status is the connection status, loginame is the user under which K2 logs into the database, hostname is the name of the computer from which K2 is or was started, dbname is or are the names of databases, to which K2 is connected and cmd is the command that is currently being executed. For safe termination the login, the status column should be in the sleeping state and cmd AWAITING COMMAND. The other previously listed columns must match the credentials and names of the unlogged-off user to disconnect the correct connection. The kill command is used for this, where the number of the connection we want to terminate is entered: kill64.

Th following queries are used on Oracle:

select SID, SERIAL#, CLIENT_INFO, TERMINAL, LOGON_TIME FROM "SYS"."GV_$SESSION"

where USERNAME='K2' AND REGEXP_LIKE("CLIENT_INFO", 'K2/./.*/.*/.*/.*/.*')

order by TERMINAL

and

alter system kill session '19,46574';

For the kill command, the session values are 'SID, SERIAL #'.


Book Contents

Book Index

Backup all databases

Location: Database Management Tool (SQL Server Management Studio)

Start: IS K2 administrator

Authorization: According to the permissions set on the SQL server

Condition: An optional action, this is a manufacturer's recommendation

Description: Before each reinstallation, the administrator should back up all databases that are affected by the reinstallation. It is a system database K2 - CONF and all company databases. Other databases such as INIT and DEMO do not need to be backed up. Backups can then be used in the event that an error occurs during the reinstallation, when it is necessary to return the K2installation to its original state before the reinstallation. When it is necessary to restore the backup will be described in the next steps of the reinstallation.

Note

We  use various client tools for database operations. For Microsoft, it is recommended to use Microsoft SQL Server Management Studio (SSMS). For Oracle, for example, data pumps or Oracle Recovery Manager (RMAN) are used.

Book Contents

Book Index

Reinstall manager - preparing to reinstall

pic_4970.png

Picture: Pre-installation preparation

Location: Information system K2

Start: IS K2 administrator

Authorization: Right - Administrator/General/Service actions (right number 1)

Condition: Mandatory action - cannot be reinstalled if K2 is not set in reinstallation mode

Description: Reinstallation manager is primarily used to  set K2 to the so-called reinstallation mode. This is a situation where it is ensured that no users are logged in to theK2, new users cannot log in, and it is also true that K2 has passed all the checks that are implemented for the given version. The individual actions that are performed in the Reinstall manager are described in the following chapters.

Was it performed?

First of all, it is necessary to check whether there is a so-called "Pre-installation preparation" in the default version. These are operations that must be performed before the actual reinstallation to a higher version. If the preparation is not performed, it is not possible to reinstall.

If a higher generation version is not installed, the pre-installation preparation will not start!

Note

If a pre-installation preparation exists, there is a button with the given information on the form.

pic_4942.png

Picture: Reinstall manager - Pre-installation preparation

If there is a pre-installation preparation and it has not been performed, continue with the next point Perform pre-installation preparation. If it does not exist, you can continue with the point Check of required initialization of version for all databases.

Book Contents

Book Index

Perform pre-installation preparation

Location: Information system K2

Start: IS K2 administrator

Authorization: Right - Administrator/General/Service actions (right number 1)

Condition: The required action if upgrading to a higher generation version - you cannot set the reinstall mode if it did not perform

Description: If there is a pre-installation preparation, it is necessary to apply it to the default version. Pressing the button displays a form with  more detailed information or inputs for preparation.

pic_4943.png

Picture: Example of a pre-installation preparation

Note

Successful completion of the pre-installation preparation is one of the conditions for the upgrade to a higher generation version and is checked only by the installer, because only the installer knows for sure how "big" the reinstallation is.

Book Contents

Book Index

Perform required initializations in clients where they are missing

Location: Information system K2

Start: IS K2 administrator

Authorization: Right - Administrator/General/Initialization of version (right number 755)

Condition: Mandatory action - you cannot set the reinstall mode unless all required initializations have been performed

Description: The start of required initializations is available in the"Administrator / Initialize version" menu or via the function 552. Then continue by pressing the "Required" button in the form. After successful initialization, we can return to the step Check of required initialization of version through all databases, which will perform a recheck.

pic_4946.png

Picture: Starting the required initialization

Note

If the initialization is not successful, it is necessary to report the problem to K2. To solve the problem faster, it is advisable to log the manifestation of the error to a file, according to the instructions in the K2 technical documentation. In some cases, there may be an error in the initialization that is fixed in a higher build version. If it is a reinstallation of the build type, then the missing initialization can be ignored because the error is fixed and the initialization will be performed during the reinstallation. It is up to the user whether to ignore the check because he/she knows he/she will not reinstall to a higher release or generation version. If the check is ignored and nevertheless, the reinstallation to a higher release or generation version is performed, the instalator will draw attention to this situation and will not allow the ignoration any more.

Book Contents

Book Index

Backup all databases 2

After repairing the database structures, it is recommended to back up those that have been affected. Step is defined in Point Backup all databases. Continue with the point Check disk space (C, installation, database).

Book Contents

Book Index

Decision making: The databases are identical to the installed K2 version

Start: IS K2 administrator

Description: This is the decision step we will get  if executable K2 is not available. See the Decision making: Is the executable K2 available?

If we have backups from the version that correspond to the installed version of K2 or from that it is possible to perform conversions to the installed version and at the same time there are k2.ini and sysk2.ini files with the correct values ??in the folder where we want to install, such a K2 torso can be considered a version to which it can be reinstalled. Further continue with the Decision Making step: Are there database backups?, otherwise we must take a step Restore databases from a backup.

A database restore is performed in the cases when errors occurred during the installation, especially in the SQL conversion section. Depending on the extent of the errors, it is possible either fix these errors or restore the database and solve the problems in the previous version so that the next conversion takes place properly. It is advisable to solve possible fixes with the technical department of K2. On the one hand, the correction may seem trivial, but it is followed by other logic, which could have taken place without an error message, but due to a previous error, it worked with bad data. Another reason is that the error did not appear during testing, but only on specific customer data.

Book Contents

Book Index

Decision making: Are there database backups?

Start: IS K2 administrator

Description: In this decision step, we decide whether it is necessary to make database backups and we can continue with the step Restore databases from a backup or whether the backups are needed to made and then we continue with step Backup all databases 2.

Book Contents

Book Index

Restore databases from a backup

Location: The database management tool

Start: IS K2 administrator

Description: The step is performed using the database management tools that allow you to make database backups and which were mentioned in the Backup all databases step.

Book Contents

Book Index

Check disk space (C, installation, database)

Location: OS Windows

Start: IS K2 administrator

Authorization: Administrator authorization to  administer the computer for K2 and database server installation

Condition: Optional operation. This is a manufacturer's recommendation. It is advisable to prevent situations where on any of the affected disks runs out the space during the installation of K2.

Description: To avoid problems with insufficient  disk space when reinstalling theK2, it is recommended to check the amount of free space on all affected disks. This is especially the C drive on the computer where the K2 is installed. The MSI file is copied to this system disk as installation media before reinstallation. At the same time, after the reinstallation is complete,  this installation package is stored in the temporary Windows directories until  K2 is uninstalled.

If the K2 is installed on a disk other than the system disk, it is advisable to perform a check also in this location before the reinstallation.

The last place is the disks for databases directly on the SQL server. During the reinstallation, we work with databases, for example, data is imported, structures are converted, etc., so it is advisable to make the check here as well.

Note

The amount of space required on each disk depends on the size of the installation media and also on the size of the database. In some cases, a check, whether there is enough free space, is made, for example when starting the installation. There are situations when the check cannot be performed. It is therefore recommended to always check this information.

Book Contents

Book Index

Start the reinstallation

Location: K2 Instalator

Start: IS K2 administrator

Authorization: Administrator authorization to install applications on the given computer

Condition: The current version supports the upgrade to the selected newer version.

pic_4958.png

Picture: Records with K2 installations

The reinstallation can be done in two modes.

The first is the classic reinstallation, when there is a complete functional K2 version, which is  available in K2installer on the "Installed" tab, see the Picture: Records with K2 installations. Above this installation, the update to the new version will start.

In the second case, it is a so-called new installation by taking over an existing K2 installation. This procedure involves a new installation, including the creation of a new entry in the K2 installer after a successful installation. This update is very similar to the classic variant, except that it is used in the following cases:

We only have a "torso" from the current K2 installation

This means that we do not have K2 binaries available, there are only data files, databases, configuration files, etc. The so-called a "torso" can be created, for example, after uninstalling K2. This  state can occur, among other things, in a situation where the uninstallation takes place within the update and after the uninstallation itself, an error occurs during the subsequent update. In this case, the K2 remains in a state where it cannot be started and only data and configuration files remain on the disk.

There is no installation record in the K2 installer

The another reason is the missing installation record. In this case, we can not run the update because this option is not available. This can happen, for example, when the installation is being migrated to another server, or we need to reinstall from a different computer than before.

Note

We will use this installation in all cases where we do not have binary files available or there is no installation record.

Note

If we update theK2 in this way, when the situation does not require it, the installation will be OK, but the installation records will accumulate on the "Installed" tab in  the K2Installer and the installation files ("msi"), which the system uses for uninstallation, will accumulate in the Windows system. When we then run the uninstall over any duplicate entry in the K2 installer, the files are removed from the K2 directory, K2 will not be executable, and one installation file is released from the operating  system. Other records in the system remain as inconsistent data, including the remains of the installation file in the Windows system. Please note that each such file takes up about 1.7 GB of data. It is therefore recommended to perform the K2 updates in the form of a classic update over an existing entry on the "Installed" tab in the K2 Installer.

After evaluating the status of the installation, it is necessary to decide how we will continue. If it is necessary to perform anew installation as a so-called "takeover", continue with the Decision making: Is the executable K2 available? If a reinstallation can be performed in the standard way, then continue with the point Start the reinstallation.

Description

To upgrade to a newer version, there must be an entry in the K2 installer with  the current version on which the upgrade will run.

The second condition is that the current version can be updated to the selected newer version. We will verify this fact by selecting the version to update in K2 Installer. For the installation record, you can select the version in the drop-down menu in the "Installation" column. If no version  is available in the menu, it probably may not be possible to update the current version to a newer version that is part of the K2Installer.

If there is not available version to select, it is possible to hover the mouse over the"?" on the right side of the installation record and the K2 installer displays information about the current installation, including why no version was offered. This makes it possible to find out over which version the user must update to continue.

Note

The K2 installer works in two modes. In the first mode, the K2Installer is part of a zip archive with a specific K2 version downloaded from  the K2 info service. In this case, case, only the option to update to the version for which the archive is intended is available. Thus, there will be no version One version or none in the offer to update, depending on the condition.

In the second mode, the K2Installer is installed on the computer used for  installations, the user logs on to the K2 FTP server after launch and has all currently released versions of K2 and other products available. In this case, there will be a version in the "Installation" drop-down menu, to which the given installation can be updated.

To start the K2 update, select the version and click on the "Execute" button in the  installation record of the K2Installer.

The installation continues with the next step.

Book Contents

Book Index

Decision making: Is there an original K2?

Location: K2 Instalator

Start: K2 Instalator

Description: There is an executable K2 in the folder specified by the installer or selected during installation. If so, the checks of required initializations of version and checks of database structures are performed automatically. The procedure and possible corrections are described in the points Check of required initializations of version through all databases and Check of all databases structures.

Book Contents

Book Index

Decision making: Is there a record in the K2 installer?

Location: K2 Instalator

Start: K2 Instalator

Description: This decision is made internally in  the installer and the user does not interfere in this decision. Record in installer means that the installation was started from the Installed page, see the Picture: Records with K2 installations. If such a record exists, proceed to the next step, otherwise it continues to Install the new version files.

Book Contents

Book Index

Remove an existing K2 installation

Location: K2 Instalator

Start: K2 Installer Wizard (MSI file)

Description: The first step that the K2 Installer performs when updating K2 in the standard way is to remove the existing installation. This process removes all files that have been installed. The files that have not been added by installation, remain in the installation directory. If any file from the installation is modified, so it does not correspond to the file that was installed, it is also left by the Installer.

Book Contents

Book Index

Decision making: Removal OK?

An error may occur when removing the original installation. Likewise, an error may  occur in the  next step when a new installation is started. If this happens, we are in a state where we do not have the K2 installation because it was removed, so we do not have a record  to run the update that ended with an error.

If the removal of the installation was successful and the new installation has started, continue with the step Install the new version files.

If the removal or a subsequent update failed and the existing installation was removed, we return to the beginning of the reinstallation and continue with the point: Decision making: Is the executable K2 available? or we can terminate the installation process, but the K2 will not be available at this time.

Book Contents

Book Index

Install the new version files

Location: K2 Instalator

Start: K2 Installer Wizard (MSI file)

Description: The new installation is started after the successful removal of the previous installation, or if we update K2 by taking over the existing installation. In this step, the new files that are part of the K2 installation will be copied. After a successful copying, an installation record is created in the OS Windows.

After the successfully files copying, the update automatically continues with the next step, which cannot be influenced by the user. This is the SQL conversion step.

Book Contents

Book Index

SQL conversion

Location: K2 Instalator

Start: K2 Installer Wizard (MSI file)

Description: At this stage, the K2 installer runs the files with SQL conversion scripts which convert the database structure for the new version. Depending on what update it is, a different number of files are run.

The following table summarizes the list of files that run depending on the database platform and also on the scope of the update. In case of an upgrade to a new version, for example K2 mia › K2 luna, all these files are run. In minor updates, only some files are run.

File

Platform

Description

New version

New release

New build

K2_C2020.sql

MS SQL

CONF database

X

 

 

K2_C2020Ora.sql

Oracle

CONF database

X

 

 

K2_C2020Additional.sql

MS SQL

CONF database

X

X

X

K2_C2020OraAdditional.sql

Oracle

CONF database

X

X

X

K2_D2020.sql

MS SQL

company database

X

 

 

K2_D2020Ora.sql

Oracle

company database

X

 

 

K2_D2020Additional.sql

MS SQL

company database

X

X

X

K2_D2020OraAdditional.sql

Oracle

company database

X

X

X

In the conversion files that run when new version, it is a one-time, non-repeatable conversion. In these cases, there are large conversions which involve the transfer of data and so  on. Such operations can no longer be rerun. This could damage database structures or cause inconsistencies in data.

Other conversion files are always run. These are usually operations such as adding a new field to a database table, new table, etc. These files are ready to be run again without the risk of damaging the database or its consistency.

If an error occurs during the conversion, each error is written to the output file "sql_inst.log", which is located directly in the K2 installation directory. If there is an error, this file is displayed to the user at the end of the conversion.

Note

If an error occurs during the update after the conversion has been made and the entire update needs to be performed again, the databases must first be restored from the backup. This is only a state where conversions are triggered that cannot be run repeatedly, see the table above. If the database was backed up only before the entire reinstallation and not after all the checks, you will need to install or restore the original K2 file system from the backup in order to perform all the checks and preparations.

After performing the database conversions, the update continues with the point Required initialization part 2/2.

Book Contents

Book Index

Required initialization part 1/2

Location: K2 Instalator

Start: K2 Installer Wizard (MSI file)

Description: As part of the required initializations of phase 1, only corrections of structures are performed, which could not be performed by running some sql script.

Book Contents

Book Index

Decision making: Was there an original K2 exe?

Location: K2 Instalator

Start: K2 Installer Wizard (MSI file)

Description: If the k2.exe startup file was missing in the folder where the new K2 is installed, and therefore the structure checks could not be performed before the reinstallation, these checks will be performed now. If the checks have already been run on the original K2, continue without these checks to the step Update extensions.

Book Contents

Book Index

Data import

Location: K2 Instalator

Start: K2 Installer Wizard (MSI file)

Description: New data for DEMO and INIT system clients are imported into the K2. Furthermore, system records for various tables are imported into all clients and the standard scripts are being updated.

Book Contents

Book Index

Required initialization part 2/2

Location: K2 Instalator

Start: K2 Installer Wizard (MSI file)

Description: This part of the installation performs actions that  could not be performed within conversions, or that require K2logic, or for which a new script is required.

Book Contents

Book Index

Import license

Location: K2 Instalator

Start: K2 Installer Wizard (MSI file)

Description: A new license is imported into K2 from the file that was selected during installation. This import is performed only when reinstalling the version or takeover of the installation.