Moving To Server 2012R2

Install SQL Server 2012R2 or 2014 (if you have access to it).  It is recommended that you install the "Enterprise" edition so that you can encrypt your database with TDE encryption.  Install the basic SQL Server service.  Analysis Server, Reporting Server, and the other subsystems of SQL Server are not needed, so should not be installed.  Be sure to update SQL Server and the OS to the latest security patches.

Install the 64 bit version of the Oracle client.  A minimum of the 11GR2 version of the client should be installed.  Use the Oracle NetManager to configure your TNSNames entries for SIDPERS and RCASDBOR, or edit the TNSNames.ora file directly if you are familiar with how to do that.  Make sure you can connect to the SIDPERS and RCASDBOR systems using tnsping SIDPERS and tnsping RCASDBOR or use the "Test" option in the NetManager (it's a little DB icon with a check box on it on the left hand side). 

NOTE: if you get a "Connection Closed" error message while testing the RCASDBOR connection, this is likely caused by your server's IP address not being defined in the SQLNET.ORA file on the RCAS database server.  Your server's IP address needs to be allowed access to the database via the entry in the SQLNET.ORA file.

Recreate the linked servers of "SIDPERS" and "RCASDBOR" (under SQL Management Studio -> Server Objects -> Linked Servers).  You can copy the linked server connection information from the old server.  The linked server should include:

1. SIDPERS or RCASDBOR for the linked server name.
2. "Other Data Source" and "Oracle Provider for OLEDB" as the server type.
3. SIDPERS or RCASDBOR for the product name.
4. Data Source should match with the TNSNames entry so should be either SIDPERS or RCASDBOR.
5. Provider String should be "DistribTx=0".
6. Copy your security information from the old database server.

Under the Server Objects -> Linked Servers -> Providers, right click on the "OraOLEDB.Oracle" entry and select "Properties".  Check the "Allow inprocess" and click "Ok".

Once the linked servers are recreated, you can test the connectivity by running these queries:

select * from OPENQUERY(SIDPERS, 'select count(*) from SIDPERS.PERS_PERSON_TBL')
select * from OPENQUERY(RCASDBOR, 'select count(*) from PER.MILPO_ORDER_LOG')

These queries should return record counts.

Recreate any application logins in the new SQL Server (e.g. cmsuser).  Stop the old web server to ensure that no further transactions are occuring to the database server.  Back up your databases from the old server and take them offline, then restore them to the new server.  These databases can include the following (NOTE you may not have all databases depending on what products you are running):

• CMS
• CMSWebServices
• Discharges
• ETransMgr
• PERMSIntegrator
• TWAwards
• TWDischarges
• TwinEnginesServices
• TWRecruiting

Go into each database and change the "Compatibility Level" to the latest version (under Properties->Options), plus make sure the "Recovery Model" is set to "Simple". 

When restoring, you may run into issues with the SQL Server accounts needing to be reattached to the databases.  Test the SQL Server accounts you move over and make sure you can access each of the databases.  If the account cannot access the database, use the sp_dropuser [sql server account] statement to drop it from the database, then add it back with the "dbo" database role using the "User Mappings" on the login properties through Security -> Logins. 

PERMS Integrator Note: PERMS Integrator runs on multiple desktops.  You will need to reconfigure PERMS Integrator on each system it is installed on to point to the new server before it will be operational again.

Move the scheduled job from your old SQL Server that runs the synch processes for the CMSWebServices suite.  This is a job that most likely runs hourly and executes the SQL:

exec CMSWebServices.dbo.usp_SynchProcesses_Run

Establish a backup schedule for the databases.

At this point, you could point your old web server to the new database server.  Use the Start -> All Programs -> CMSWebServices -> Set Database Login and Start -> All Programs -> TwinEngines Web Applications -> Set Application SQL Login to point the web applications to the new servers.  You can then restart the web service and test to ensure that everything is operational. 

There are test pages available at:

https://servername/cmswebservices/test.htm
https://servername/twinengines/test.htm

You can use these to ensure that the applications are connecting to the new database server properly.

Make sure the following roles are included with your web server:

• Windows Authentication
• ASP
• ASP.NET 3.5 and 4.5

You also need the SSL certificate from DISA for the server and have it bound to the default web site.  Be sure to install all the DA root certificates and apply all the latest security patches.  Optionally you can try moving the SSL certificate from your old server using this process:

https://www.sslshopper.com/move-or-copy-an-ssl-certificate-from-a-windows-server-to-another-windows-server.html

Download the latest versions of the software from our downloads page here.

Contact ngsales@twinengines.com to get new license keys for your applications.

Run the CMSWebServicesSetup.exe.  You will be prompted for a SQL Server login and password that has SQL Server admin rights in order to upgrade the database.  You will also be prompted for a login for the applications to use (e.g. cmsuser).

Run the ETransMgrSetup.exe, DischargesSetup.exe, and TwinEnginesWebSetup.exe to install the remaining applications.

Go into IIS Manager and set the "Enable 32 Bit" to "True" for the CMSWebServices and TWProducts AppPools.  For each website that was created (e.g. CMSWebServices, Discharges, ETransMgr, TwinEngines), under the SSL settings, set "Require SSL" and select "Client Certificates: Require". 

Try the "test" pages to ensure the system is working:

https://servername/cmswebservices/test.htm
https://servername/twinengines/test.htm

For any questions or issues, contact ngsupport@twinengines.com