Steps For Migrating RiskManager V6.x from Test To Production

From RiskWiki

Jump to: navigation, search



There is a very detailed installation process on RM625ENT Installation Instructions

However, this assumes an essentially manual installation process, essentially starting from a raw iron server, and includes installation of the OS components required. If you use the automatic installer (recommended) the process is much simpler. Production, generally differs from Test or Dev environments, however as the components maybe more widely distributed and you are generally starting with an at least partially configured server (unless you are dedicating a production application server instance to RiskManager).

Different sites do differing things for production, some reinstall completely others duplicate test into production, some do everything manually for production, while using the automated system for Dev, etc.

We recommend a reinstallation - partly because it is the least error prone, and possibly faster.

If You Have An Existing BPC RiskManager Production Installation

If you have an existing RM installation in production, you can actually just copy the changed files onto the server (replacing the existing files of the same name) and start the RiskManagerData server once, then close it down, and you are done, so the auto-installer is not actually necessary in this case. Alternativley, you can run the uninstaller in production to remove the previous installation, and then use the new installer to reinstall. You will NOT loose any of your configuration settings - so it is completely safe to do this. That will essentially make you existing system a raw machine EXCEPT that the connection settings will be in place already.

If this is your situation, the steps below are still correct BUT you should NOT let the installer create the database(s) for you - as you already have the connections present. Just say no to this question when it comes up during installation.

Performing the Migration To Production

Read the preceding section if your production server has a pre-existing RiskManager V6 installation. If you are migrating from BPC RiskManager Express or RiskMan, you DO NOT NEED TO UNINSTALL, BPC RiskManager V6.x will ignore the Express settings and installation.

Assuming we are starting with a W2003+ server that does not have a pre-existing RM installation, and that your SQL Server is on a separate computer:


  1. If using BPC support during installation email us to arrange a time for our call to assist you install.
  2. Decide whether you are going to enable SurveyManager as part of the installation, or later. (Ask the business)
  3. Decide how many databases will be set up in production (Can be increased later if desired, but easiest if known prior to installation as the installer does all the work for you).
  4. If you want to make an existing database available in production that has been set up in dev/test and you will NOT be using the same physical database as that set up in dev/test, decide whether you will be will be using the RM installer to restore a backup of the established database into production, or whether you will restore the backup separately (after installation completes). You should consider:
    • If you have already restored the database into production you probably do not the installer to attempt to create it
    • If the target database is the "DEFAULT" connection (so named) of the application server and the database does not already exist in production and the database server is essentially a single server solution with data and log files on the same server then either decision is appropriate, and it is probably simplest to let the installer create a database of the target name and then use the installer's restore option to restore the backup over the top of the newly created database.
    • If the target database is a uniquely named database connection of the application server and the database does not already exist in production and the database server is essentially a single server solution with data and log files on the same server then either decision is appropriate, and it is probably simplest to let the installer create a database of the target name and then use the installer's restore option to restore the backup over the top of the newly created database.
    • If the target database server is a complex configuration with log files and data files separated across multiple NAS/Servers etc, the installer will probably not be able to determine the configuration correctly as the information is not always available to it in the remote registry (although it will attempt to do it correctly). So restoring from backup on a remote machine may not succeed. You are probably best to do this manually prior to installing the server, or if the database does not yet exist on the target server, the simplest approach is to let the installer create an empty database of the same name and then restore your backup over the top of the newly created database after installation completes. If you choose the former approach, you will need to do some extra steps (instructions provided during installation below) so the client test will validate your install. If you do not create any databases during installation (or have a pre-existing database to which to connect) you will not be able to validate connection during installation. We strongly recommend that you at least let let the installer create its default database and test connection to that. You can always discard it later.
  5. Decide whether you will be using network compression comms or the default raw comms (see the instructions below for the implications of this decision – raw is simplest) and if both, which will be the default. (Can be enabled later if desired)
  6. Decide whether you will be enabling HTTP/HTTPS comms access as well. (Can be enabled later if desired)
  7. Decide whether you will be using the desktop client and or the browser plugin (we recommend the desktop client – both have the same functionality, but the plugin behaviour varies a little across different Win OS’s and IE versions due to MS security changes, so if you have mixed desktop OS’s not every desktop will behave exactly the same. If you want to know the implications or need this explained further, ask us or look on the riskwiki.
  8. Verify the installation site (eg the remote desktop on which the installer will be working) has phone access (preferably hands free), and that you know the telephone number for the phone, and, ideally, outbound internet (IE/Firefox/etc) access so you can look at the riskwiki if needed.
  9. You should do steps 1 – 9 below prior to the BPC support call.


  1. Verify server has the following infrastructure on it:
    • Functioning network connection to the rest of the network with port 211 (and ideally port 212 as well) and SQL Server TCP ports available – eg 1433.
    • Functioning installation of IIS 6+
  2. Verify the server either has on it or available to it:
    • Functioning SQL Server (any version) configured in Mixed mode authentication or SQL Authentication mode
    • Functioning SMTP server that will accept relays from this machine (this can always be configured later)
  3. Verify that you the person installing knows:
    • Server local system administrator user ID / PWD
    • SQL Server user id SA / PWD (If SA is not available you will need to speak to me again)
    • The name of the SQL Server and the instance (if not using the default instance)
    • The Administrator account user ID (usually Administrator) and PWD for the RiskManagement system. This is database specific, and more important when restoring than installing. Not knowing does not stop you installing, but may prevent you from connecting via a client when the test is run at the end of the installation. Otherwise, any RM Administrator account is fine to use. It is auto-created on first connection, so it can often be the user name of the person who does the installation. Ideally you settle on a common user name, and always use that across all databases and remember the password. Access by the root administrator account can be blocked by the RM system administrator after installation of a fresh database, so for restored databases, it may be that this account’s access is blocked anyway.
    • The http addressable name of the application server as it would be typed into browser address bar by a remote LAN client (eg: a human operating from her office)
    • The fully qualified domain name of the application server as it would be entered in the windows network browser of a remote user if they were able to browse to a folder on the application server (eg. the human again)
    (NOTE: Part of the installation process is to create special purpose limited rights SQL accounts, the installer either creates these for you, or expets you to know the passwords. I am assuming they do not exist yet on the target SQL server. You will need to provide a password during the installation for the “riskmanuser” sql server account. The installer will make this account if it is not available already, so you need to have decided what the password will be. I recommend using the same password as that used for dev. This is a limited rights ID. The other accounts will be set to use the same password. They can be changed manually later if desired.).
  4. If transfering the dev database into production:
    • Prepare a backup of the dev database.
    • Ensure the verison of SQL Server in production is the same as, or higher than, that in dev from where the backup comes (eg. You can NOT restore an SQL 2008 backup into an SQL 2005 server, but you can do the reverse)
  5. Confirm with the RM administrator how many databases they want in production. We recommend a minimum of two databases, the default auto names database, and another spare / empty database for future use. The auto named database will have the connection name “DEFAULT”, the other database can have whatever connection name you choose. The autonamed database will be called RiskManDB625 and the connection will be called “DEFAULT”. The connection name (and in fact the database name) can be changed later. The connection name is the name the user sees as the database name. The caonnection DEFAULT does not need to be entered at all by the user – so this is ideally the main database in use.
  6. Copy the RM Installer to a directory of the application server that will be accessable to the person performing the installation.
  7. Copy the backup file to a directory on the SQL server that the SQL server will be able to access (read from) during a restore. We recommend that that directory is the default backup directory for the targeted instance of the SQL server as that is where it will read from naturally (and if you use the installer to do it, the SQL server must be able to read the file – so it needs to be readable by the SQL server under the SA account).
  8. Verify that the place from which you will be connecting to the application server (ie the remote client) has a telephone preferrably able to run work in hands free mode (so we can talk you through the process by phone).
  9. Locate your BPC RiskManager registration code so you can enter it when asked. You will not need this until the client connects at the end of the installation process. If this is a new server and new database you will have up to 60 days to enter it.
  10. If you opted during the decision stage above to backup an existing RM database from Test and restore it into Production, you should do that now. (Or schedule it now to be done immediatley before the installation commences). Make sure you know the database name on the server.
  11. Send BPC an email or phone BPC to arrange a time for support to contact you – preferrably as long BEFORE you commence installing as possible. We will confirm the booking and contact you at that time. If you just wish us to be available should you need it during support, we will make sure we are able to take your call at that time, and email you a direct number to use should you need it.


  1. If using a remote client to connect to the application server and run the installation process (eg mstsc), verify that the remote client is set to operate at 96 DPI not 120 DPI (there is a bug in the installer display routine that hides some buttons at the 120 DPI resolution. If connecting via mstsc, enter mstc /console as the connection command in start/run from the remote computer so that you are operating in console mode. This is important so that you can see the system tray icons.
  2. (If using BPC support, await the call first). Run the installer in “Complete Mode”, read the onscreen instructions and answer all the questions.
    • Always create default database, during initial installation
    • If restoring a backed up dev database, the installer can do this AFTER the installer creates the databases, or you can do this after the entire process manually. For some complex SQL setups this may be required, as while the installer attempts to locate the correct places for database restoration from the SQL Server registry, this is not 100% reliable due to the various ways this information is stored in the registry across different versions and instances of SQL Server. Let the installer create the blamk database for you, so that all the connections are made, and then you can simply restore over the default database with your backed up database after the installation. If the SQL server is on the application server itself, there is a much higher probability of complete success in installer based restoration.
  3. The installer will auto-register the components and start the BPC RiskManager DataServer console. If you are NOT connecting to an existing database (ie you let the installer create new databases), you can go on to the next step - just select "End Process" on the consol window...other wise check the dot points below:
    • If want to connect to an existing database that was NOT created or restored during installation (ie. a database that exists but that is not yet known by the application server on THIS computer) AND you already have the database(s) set up on the production database server, you will need to configure the connections when the application server console window appears (ie. NOW): How to Connect the BPS RiskManager Application Server to an existing database
  4. Next, the installer will start the client locally for a test connection at the end to verify access to the default (or other) database. If you can connect and see the main screen after login you have successfully installed. NOTE: The installer will set the server up in single-user edition and auto-administration access mode. This does not prevent remote access but will (usually) need to be changed to your correct access settings for production enterprise deployment. See the section "After Installation" below.
  5. Switch the server into web edition - click on this link for instructions.
  6. Set up client access. Either (or all):
    • Copy the desktop client installer (there are two to choose from depending on whether you prefer single exe or MSI installers) from the /program files/bishopphillips/RiskManagerVxxx to a network share that will be accessible to users
    • Copy the already installed client from the /program files/bishopphillips/RiskManagerVxxx/win32client directory to a separate computer/folder and make the folder sharable, if you want people to simple run the client across the network from a remote folder. The client does not actually need to be installed on a destop to work, but installing it provides shortcuts / menus and enables the use of the network compression/encryption library in V6.2.5.x.
    • Install the client into a citrix (or other remote desktop) image.
    • Distribute the browser plugin ActiveX client to the Risk Manager web site.
  7. Go to a typical remote LAN computer and attempt to install/use the client set up in 13 to access the server using the same account used previously and verify remote connectivity to the application server.
  8. If intending to use streaming network compression/encryption, follow the instructions in the riskwiki for enabling this. Remember you will need to advise all users that the access settings are other than the defaults in the client. (a box has to be ticked and possibly a port changed in the login window). If using streaming network comms, we recommend 2 ports be enabled – one for raw comms and one for compressed comms. (Hence the suggestion at the start that you clear 211 and 212 for RM comms). In reallity RM does not care what port is used. By default it is set to expect communications on port 211, but you can set it to use any combination of ports you like. We advise sticking with the recommended (obviously). If using steaming compression, you should probably for simplicity enable that on port 211 – so clients only need to tick a box to enable it, and set the raw channel to be 212, as the raw channel is only for trouble shooting, and backup connection. Note, enabling compression/encryption will EXCLUDE the option of copying clients as a means of installation as the compression library is currently a separate lib in V625.x - that will change in a future release.

After Installation

Most of these actions require you to use the RiskManager application server configuration console. So firstly, on the application server computer locate the "BPC RiskManager DataServer" in the start menu and start it. When started, the application server appears as an icon in the Windows system tray, typically located in the lower right hand corner of your screen. Please double click on the icon Image:RM_App_Server_SysTrayIcon.png to interact with this program. The configuration console will open....and then..

  1. Now proceed to the instructions for completing the security/access set up:

  2. If you have additional databases to connect to riskmanager that you did not do during installation, you had better so that now: How to Connect the BPS RiskManager Application Server to an existing database

  3. Depending on which other components you are using (network streaming compression/encryption, email messaging, surveymanager, browser plugin client, etc.) there may be a few manual steps to complete the installation using the RM Configuration wizard after the installation finishes and tests have been completed. You should generally, in any case, access the IIS server after installation and enable “Unknown ISAPI extensions” – for surveymnager operation even if the surveymanager is not being used yet, as it will save you time later when RM decide randomly to create a survey. The explanation of how to do this is in the riskwiki instructions below. Now do each of these steps in order (note all are optional - the system will work without any of these configurations, but some things like email will not be available without them:

    1. BPC RiskManager - Send Mail Options Configuration
    2. BPC RiskManager - Mail Server Connection Properties
    3. BPC RiskManager - Logging Configuration (OPTIONAL)
    4. BPC RiskManager - Create the Root Administrator
    5. BPC RiskManager - Distribution of Client Components (Browser plugin ActiveX)
    6. BPC RiskManager - Configure Risk Mail Manager

  4. If you are using the survey engine, the installer will have set that up on the application server, but there are a couple of things you will need to do. In particular you will have to manually tell IIS to allow unknown "ISAPI extensions" and if you have connected to a pre-existing database (rather than one created during the installation process) you will need to configure it. Also, if your SurveyManager web server will be different from your application server computer (eg a web farm), you will need to do the config step for each database in the RiskManager environment. (There is special tab in the to help with the multi database situation efficiently).


CopyRight Bishop Phillips Consulting Pty Ltd 1997-2012 ( Steps For Migrating RiskManager V6.x from Test To Production )
Personal tools