CA Service Management

Hello All, probably over a year ago now, I had posted some information about what we call the "Swing Box" migration method. Over the past few weeks I have been working on a project to update some of the Upgrade and Migration information available to our user community, and wanted to share a new revised version of the document for the "Swing Box" method with you. This will also be published as a TecDoc on support.ca.com shortly as well, but for those loyal users who come back to view this message board each week, I wanted to give all of you a sneak peek preview ;)

Here you are:

INSTRUCTIONS TO MIGRATE SERVICE DESK FROM 11.2/12.x to 12.7 - USING THE “SWING BOX” METHOD

Overview of this method:
The “SWING” Box Method is done by using a separate server (herein referred to as a SWING system) to replicate your current production system onto, and then run migration to 12.7, then move the migrated 12.7 data and customizations over to a clean (never migrated) and install on new hardware. The advantages of using this method are that it will leave your current prod system fully in-tact in case of DR issue or failed migration, and at the end of the process, you are running your new 12.7 Service Desk install on a clean, never migrated, system – usually on new more powerful hardware, with an updated version of the OS and DBMS. An additional advantage would be added if you have the ability to use a VMware environment as the “SWING” system, as you can use the snapshot functionality to test the migration process multiple times, gathering data on timings and steps, ensuring a higher comfort level for the parties involved in the migration day project.

To use this method most efficiently, there are a few requirements. They are as follows:
1.
NO form, or schema (tables and columns) customizations or changes should be made to any system (11.2/12.x prod or 12.7 dev, test, SWING etc.) once migration testing has been started. If you plan to add or modify additional tables or columns, it should be done either on 11.2/12.x and put into production prior to testing migration, OR during another outage planned after your PROD migration is complete and you are running Service Desk 12.7 on the NEW PROD system.
2.
You have already done a test migration of a replica of your production system, and have already completed re-customizing any of your custom forms from 11.2/12.x that are incompatible with 12.7, and have a final customized and complete and site\mods directory from a 12.7 environment where all proper testing was completed.
3.
You have replicated the most recent migrated 12.7 test environment install onto your NEW PROD hardware including your customized forms built for 12.7. This will save you a lot of time on migration day!

PART 1 – GATHER FILES/DATA FROM CURRENT PROD SYSTEM

1.
Do a SQL Backup of the MDB – save as .bak file (usually a normal SQL backup)
2.
Make a copy of the “C:\Program Files\CA\Service Desk\site\mods” directory – zip it up if possible. (not the whole site directory, ONLY the mods directory)
3.
Make a copy of the “C:\Program Files\CA\Service Desk\site\attachments” (or whichever directory your repositories are configured to store your attachments in) and zip it up if possible
4.
Copy above files to the SWING environment – but don’t put them in place yet, simply copy them to a stand-by directory on that machine.


PART 2 – PREPARE THE SWING ENVIRONMENT & REPLICATE PROD SWING

NOTE: If your SWING environment has both the DB and Application running on the same box, then you may start at step #3 in this section.
**For reference, in this section we will refer to the database server as “SWING-DB” and the application server as “SWING-APP”**

1.
On SWING DB – (assuming SQL is already installed), run the MDB installer wizard (from the SD 11.2/12.x install media)
2.
On SWING-APP – install the SQL client and native client (workstation tools also)
3.
Install Service Desk 11.2/12.x on SWING-APP and run configuration so that you have a vanilla 11.2/12.x Service Desk Manager installation running.
4.
Have your DBA run the SQL Restore and restore the MDB from your current PROD that you backed up, onto the SWING-DB server - Set option to “OVERWRITE entire database” when restoring.
5.
After the SQL restore is complete you must run the stored procedure in SQL to fix the orphaned users – which are created when restoring a db from one SQL instance to another.
SHOULD BE SOMETHING LIKE THIS: sp_change_users_login 'AUTO_FIX','ServiceDesk'
6.
Run pdm_configure –DO NOT SELECT TO LOAD DEFAULT DATA **In the configuration wizard when you click “next” at the database section it will pop up a box saying that “this database was previously configured by …… are you sure you want to configure it” you will click “Yes” here – this is only because you restored the MDB from a different environment.
7.
After pdm_configure completes, start Web Screen Painter (also called WSP) and log in
8.
Go to Tools > Schema Designer
9.
Click on any table on the tree on the left
10.
Put an “X” in the description field for that table on the right
11.
Go to File > Save
12.
Close the Schema Designer window
13.
In the main WSP window, click File > “Save and Publish”
14.
Click OK on the dialog boxes
15.
Exit out of WSP and close all WSP windows and browser windows
16.
Run: pdm_halt –w (this stops all SD Services)
17.
Run: pdm_publish (this will merge the schema and load the correct schema files)
18.
Copy the site\mods directory you backed up from current PROD and put in place on SWING-APP system
19.
Copy the site\attachments directory (or whichever attachments directory) you backed up from current PROD and put in place on SWING-APP system
20.
Run another pdm_configure – again DO NOT SELECT TO LOAD DEFAULT DATA
21.
After configuration is complete – start service desk services if not started, perform some testing of system functionality to make sure 11.2/12.x is running with your data, and customizations without issue, as a full replica of your production environment.

NOTE: If you are running your SWING environment on VMware, its best to take a snapshot at this point which you can then use later on your actual migration day. See the note in the next section for details.


PART 3 – UPGRADE & MIGRATE TO SERVICE DESK 12.7 ON THE SWING SYSTEM

This section is geared towards the testing process of first testing the migration so that you will be familiar with the process and what issues you may run into while migrating your production system on your actual migration day. If your SWING box is on a VMware environment, then its best to take a snapshot here first if you have not done so already, as you can simply roll back to that snapshot on your actual migration day, then simply take your production system down, do another SQL backup on Production, restore it to the SWING environment, and run the steps in this section again. This allows you to leave your 11.2/12.x production environment in tact just in case something goes wrong with your migration – all you would have to do is bring your 11.2/12.x production system back up and start services. You can then retest migration on the SWING environment again, and schedule it for another time once any bugs are worked out for your specific migration.

IMPORTANT NOTE: If your DB and Application are on separate servers, then you will first need to run the MDB installer for 12.7 from the 12.7 install media on the SWING DB Server, which will upgrade the MDB on SWING from 11.2/12.x to 12.7’s format. Then once that is complete, you can start the next set of steps here to upgrade the application and migrate the data. Note that the MDB installer does NOT migrate the data, but rather only upgrades the MDB to the right version in preparation for a migration.

1.
Mount the 12.7 install media from a local folder, or run the setup.exe from the local folder where the install media is being stored.

IMPORTANT NOTE: If you are extracting an ISO of the install media, it should be stored in a path and folder that has no spaces in its name such as “SD127Setup” – and should be run locally from the same drive volume that you plan to install 12.7 onto. Never run the installer from a network drive or mounted share as this has been known to cause install and even post install problems to occur.

2.
Click on “Installations”
3.
Click on “ Service Desk”
4.
Follow the prompts to perform this upgrade to 11.2/12.x from 12.7
5.
After the install is complete – the Migration Wizard will kick off
6.
Follow the migration wizard prompts and enter any necessary information when prompted
7.
This part may take a long time depending on the size of your 11.2/12.x database.
8.
**(see note below) – copy 12.7 site\mods folder from previous test/dev environment to this SWING box and run a pdm_configure to ensure all customizations are properly implemented.

**NOTE: If you are testing migration at this stage, you may skip this step as you would not have any 12.7 customizations at this point. However, if this is your production migration day, at this point, it is assumed that you have done a test migration on the SWING environment before doing this production migration, and you have already completed any re-customization or customization work to the forms on the SWING environment. If so, then follow this step as you should already have a copy of those customizations backed up.

9.
Now, fully test this migrated, and customized 12.7 SWING system for integrity and functionality.

NOTE: At this point, if this is your test run on the SWING environment, you will need to re-build your form customizations using the 12.7 forms delivered with the product as your previously customized 11.2/12.x versions will not work in 12.7. Once you have completed the rebuilding of your customizations, please take a backup of your site\mods directory on the SWING box and store it somewhere outside of this environment for use later (as described in step 8 above).

10.
If all tests are successfully completed, you may now start the process of moving your migrated data, and customizations to the NEW PROD hardware.


PART 4 – MOVE MIGRATED SWING BOX INSTALL TO NEW PRODUCTION HARDWARE

**As noted at the beginning of this document – your NEW PRODUCTION hardware should already be running a clean install of 12.7 with your tested 12.7 customizations in place.

Since the NEW PROD hardware is already running a clean install of 12.7 with your customizations in place (from your finalized 12.7 testing environment) – all you will need to actually do here is simply do a SQL Backup on the SWING system, and have your dba do a SQL Restore onto the SQL instance that your NEW PROD system is using, and follow these few steps:

1.
After the SQL restore is complete you must run the stored procedure in SQL to fix the orphaned users – which are created when restoring a db from one SQL instance to another.
**SHOULD BE SOMETHING LIKE THIS: sp_change_users_login 'AUTO_FIX','ServiceDesk'
2.
Run pdm_configure – again DO NOT SELECT TO LOAD DEFAULT DATA **In the configuration wizard when you click “next” at the database section it will pop up a box saying that “this database was previously configured by …… are you sure you want to configure it” you will click “Yes” here – this is only because you restored the MDB from a different environment.
3.
After configuration is complete – start service desk services if not started, perform FULL testing of system functionality to make sure your NEW PRODUCTION Service Desk 12.7 system is running with your data, and customizations and all functionality is in working correctly.

*************
Be sure to check back next week for more great tips and tricks :)

Thanks again, and have a GREAT week!

Jon Israel
Principal Support Engineer
CA Technologies

Thanks for providing the community with all this great information Jon! :grin:

Wow! Brilliant post on performing a migration, Jon!
I think that's the most comprehensive upgrade guide I've seen.

You'll be putting our Business Partners out of a job though. ;-)
(Or they can put their now extra time into improving business processes.)

I'd love to hear from anyone who runs through the procedure on their system - post to this thread!

ADDITIONAL
This is included in the steps outlined, but to break it out for emphasis, it is also useful watch for:

* Compare NX.env and web.cfg files pre and post to see if any variables have been left out.
This is to capture those cases where manual changes have been made to the underlying .tpl files that did not originate through the interface, such as increasing NX_MAX_DBAGENT.

* Extend the above to any "out of the ordinary" changes that have been implemented in the distant past, that do not flow through the areas covered.
Such as scripting files that are outside of site/mods/ but nonetheless part of the overall solution.

* Check that you have the same number of Knowledge Documents that you were expecting, with images.

* Check that BOXI works. And integrations in general.

* If you have performance metrics tools available, run them before and after. You should be rewarded with the warm glow of seeing better response metrics if on new hardware.
(A manual partial solution is to use SDM, View, Response Time Statistics and take a variety of times for tasks at a known busy time, and then repeat.)

* If possible, perform a "hardware migration" and the "software migration" as separate tasks. This is not required, but if there are problems, it does allow you to say "This is as a result of the hardware change" or "This happened after changing SDM versions" rather than "It could be a hardware or a software problem."

* "Full system testing" includes reviewing the SDM stdlogs for ERRORs.

* Clean up the data as much as possible before the upgrade.
Archive and Purge as much as possilbe, clean out not_log and sesion_log tables. The less that needs to run through migration, the better.

Again, great post Jon.

Kyle_R.

Thanks for this post Jon. We hope to use the Swing Box method for our next Service Desk Upgrade:
from – 12.5, Windows 2003 R2 64 bit SP2 Server (Data Center Ed.), and SQL 2005;
to – 12.6, Windows 2008 R2 64 bit Server (Data Center Ed.), and SQL 2008.

We have a few questions about the use of the Swing Box method:

1. When replicating the production environment to the Swing Box server, is it possible to use PDM_BACKUP and PDM_RESTORE to replicate the production configuration from a Windows 2003 Server to the new Swing Box Windows 2008 Server? Could this be done instead of reinstalling the 12.5 media on the Swing Box Server?

2. If we must install the 12.5 media on the Swing Box Server, would we also need to patch the server to the same level as the current productions server? Might this interfere with testing if we don’t use the current production configuration as the baseline?

3. Our Production Database is rather large, and we don’t necessarily want to copy the all of the production data to the Swing Box Server as this will eventually become our new Development Server. Is it possible to replicate the data from the development server to the Swing Box Server?

Again, thank you for your post Jon. Please let me know if this forum is the best method to address our questions or whether you prefer that we submit a support ticket.

Thank you and best regards,

Ed Mosqueda

Hi Guys,

Do you have any ideas here for Ed's questions?

Thanks!
Chris

EdMosqueda wrote:

We have a few questions about the use of the Swing Box method:

1. When replicating the production environment to the Swing Box server, is it possible to use PDM_BACKUP and PDM_RESTORE to replicate the production configuration from a Windows 2003 Server to the new Swing Box Windows 2008 Server? Could this be done instead of reinstalling the 12.5 media on the Swing Box Server?

Ever since r11.x, the backup and restore utilities don't do a 100% data restore on the target system. Having used this same method a few times, I always prefer doing straight MDB restores on the swing box.

EdMosqueda wrote:

2. If we must install the 12.5 media on the Swing Box Server, would we also need to patch the server to the same level as the current productions server? Might this interfere with testing if we don’t use the current production configuration as the baseline?

That's not entirely necessary, unless there are obvious reasons for the patches installed on production in the first place (i.e. .Net versions, Office, etc).

EdMosqueda wrote:

3. Our Production Database is rather large, and we don’t necessarily want to copy the all of the production data to the Swing Box Server as this will eventually become our new Development Server. Is it possible to replicate the data from the development server to the Swing Box Server?

If - customization wise - the Dev is identical to the Prod, then you could also replicate from Dev to the Swing Box. One advantage of using the Prod system is that you'll get more realistic timing on the upgrade step itself, this could help with the 'real' migration of the Prod system when you go live and do the upgrade.

Hi Ed,

Sorry for the delay in my response – we have been down for the count here since last Monday when the hurricane rolled through. With that, here are my responses to your questions:


1. We do not recommend pdm backup and pdm restore as a general rule as we have noted problems with it in the past. We have had a lot more successful experience in using sql backup and sql restore to copy the database to a new system. Additionally the sql backup and sql restore takes a lot less time than the pdm backup and pdm restore – which does a complete extract on the mdb which can take an extended period of time.


2. Yes, you should definitely patch the swing system to the same as your prod. This will ensure that you have a good replica to start from and will also help to mitigate the risk of any unknowns along the way. It can definitely interfere with testing if you do not have the same patch level – same goes for customizations ;)



3. I don’t recommend this as you will not have a complete replica of your production system on the swing environment. This will now allow you to get proper timings as well as get a really good idea of how your production system will migrate. You want to compare apples to apples here, which will mitigate the most risk of failure in a migration.


I hope this helps – let us know,

Thanks,

Jon Israel
Principal Support Engineer
CA Technologies
(631) 342-2231
jonathan.israel@ca.com<mailto:jonathan.israel@ca.com>
[Description: Description: Description: Description: C:\Program Files\CA\GIS\CASig\CA_AMP_email_Corporate.gif]<http://www.ca.com/>

From: CA Service Management Global User Community [mailto:CommunityAdmin@communities-mail.ca.com]
Sent: Saturday, November 03, 2012 4:39 AMI don’t
To: mb.14300553.99560050@myca-email.ca.com
Subject: [Tuesday's Tips] RE: CA Tuesday Tip - The New and Improved "Swing Box" Migration Method

EdMosqueda:

We have a few questions about the use of the Swing Box method:

1. When replicating the production environment to the Swing Box server, is it possible to use PDM_BACKUP and PDM_RESTORE to replicate the production configuration from a Windows 2003 Server to the new Swing Box Windows 2008 Server? Could this be done instead of reinstalling the 12.5 media on the Swing Box Server?

Ever since r11.x, the backup and restore utilities don't do a 100% data restore on the target system. Having used this same method a few times, I always prefer doing straight MDB restores on the swing box.
EdMosqueda:

2. If we must install the 12.5 media on the Swing Box Server, would we also need to patch the server to the same level as the current productions server? Might this interfere with testing if we don’t use the current production configuration as the baseline?

That's not entirely necessary, unless there are obvious reasons the patches SW is installed on production (i.e. .Net versions, Office, etc).
EdMosqueda:

3. Our Production Database is rather large, and we don’t necessarily want to copy the all of the production data to the Swing Box Server as this will eventually become our new Development Server. Is it possible to replicate the data from the development server to the Swing Box Server?

If - customization wise - the Dev is identical to the Prod, then you could also replicate from Dev to the Swing Box. One advantage of using the Prod system is that you'll get more realistic timing on the upgrade step itself, this could help with the 'real' migration of the Prod system when you go live and do the upgrade.
Posted by:mitu
--
CA Communities Message Boards
99562590
mb.14300553.99560050@myca-email.ca.com<mailto:mb.14300553.99560050@myca-email.ca.com>
https://communities.ca.com

Hello,

I am about to inititate an upgrade in a customer from 12.1 to 12.7. We are
planning to use the SWING method (as stated in TEC578669). But reviewing this
procedure, I have seen that the usual step for upgrading custom fields
(extract wspcol and wsptbl in 12.1 and load in 12.7) is missed. So that means
that it is no longer necessary, or is a missing part in the procedure?

Un saludo,

Pablo

pespinar wrote:

Hello,

I am about to inititate an upgrade in a customer from 12.1 to 12.7. We are
planning to use the SWING method (as stated in TEC578669). But reviewing this
procedure, I have seen that the usual step for upgrading custom fields
(extract wspcol and wsptbl in 12.1 and load in 12.7) is missed. So that means
that it is no longer necessary, or is a missing part in the procedure?

Un saludo,

Pablo

Hello Pablo,

Customisations were mentioned in the paragraph beginning "To use this method most efficiently, there are a few requirements. "
And the few requirements covered off this to some extent.

But you're right, the details weren't there to do an extract and load, and these steps may be useful to some sites. But mention was made that this is a good time to revisit your customisations and see if any can be left out.

Happy to accept suggestions and tips or rewrites of paragraphs on how to improve this!


Thanks, Kyle_R.

TIP: Database user must be "master."

Hello All,

Thought I'd record details of a Sev 1. that was logged with the Swing Box method. I encourage other users/engineers who encountered issues to do the same, so that we can build up a reference of things to watch out for.

ENVIRONMENT
Upgrade from SDM 12.5 to SDM 12.7.
Remote SQL 2008 64 bit database on a cluster. All working with SDM 12.5.

SYMPTOMS
When installing remote components against the MDB for SDM 12.7, the following is displayed in the pdm_install_mdb.log:

23/01 15:01:10.123 INFO MSSqlDBType.java 431 Invalid object name 'sysdatabases'.

Also:

Failed to check SQL database

RESOLUTION
Database user for this installation/configuration process must be pointed to "master" and not to "MDB."

Once you know what the symptom and resolution are, there is an old TEC which references the resolution, even though the symptoms are different:
TEC478799. When installing Service Desk MDB remote components, it fails with error "failed to check sql permissions" in front end. log file shows "276 Invalid object name 'sysdatabases'..."

There's probably a better reference than that. But for now, just add in the above to your checklist - "master", not "MDB."

Thanks, Kyle_R.

Hello,

I am in the proccess of migrating a customer installation from 12.1 to 12.7 using the swing box method. One of the things we need to perform is the CABI upgrade. We have CABI version that shipped with 12.1 in a W2003 box, and we need to upgrade it to the CABI version that shipped with 12.7 and to another W2008 box. I have read the documentation but I am not clear about the procedure to follow. Is it possible to make a fresh CABI installation and the import universe, reports, and then like from the old box to the new box?

Un saludo,

Pablo

pespinar wrote:

Hello,

I am in the proccess of migrating a customer installation from 12.1 to 12.7 using the swing box method. One of the things we need to perform is the CABI upgrade. We have CABI version that shipped with 12.1 in a W2003 box, and we need to upgrade it to the CABI version that shipped with 12.7 and to another W2008 box. I have read the documentation but I am not clear about the procedure to follow. Is it possible to make a fresh CABI installation and the import universe, reports, and then like from the old box to the new box?

Un saludo,

Pablo

Hello,

Note that this query is being followed up in this thread: RE: [Tuesday's Tips] CABI Migration

Thanks, Kyle_R.

I wish that I could give this thread a separate thumbs up counter for every time that I referred a client to it.

It has been very helpful.

Thanks, Kyle_R.

Show!
Excellent Post

Thanks!

Hi Jon,

I would like to ask one question related to the upgrade of CA Service Desk MDB.

As per your suggestion we should point the master Data base to run the upgrade of CA SDM MDB.

My question here is we are planned to run the MDB upgrade to CA Service Desk MDB data base, why we need to point the Master database?

Thanks
Venkat

Swing Box and Oracle Sites

Hello Everyone,

Some interesting feedback for Oracle sites using the Swing Box method from user Efra.

I'd encourage any Oracle site considering using the Swing Box method to take a look - and to contribute further with Oracle Tips and Suggestions.

At some point, these tips will need to come into the next Swing Box document.


Thanks, Kyle_R.

Hello Everyone,

In a variation on the Swing Box procedure, is there any documentation for "cloning" a server?

Specifically an "all in one box" with Service Desk Manager, EEM, database, BOXI and all other major components installed on the one virtual box.

The aim is to clone this virtual box, then go through a run sheet to change:

• Hostname, IP address
• Update all major components, such as EEM, SQL (Or Oracle), BOXI, SDM etc to use the new hostname/IP address details.

We have a document for SDM 11.2, EEM 8.1:

• Guide to Cloning a Service Desk Server for Test Purposes

which does have detailed steps on a similar cloning scenario.

However, I have a site who is specifically looking for details on running EEM 8.4.217 and SDM 12.x .

And the EEM 8.4 details are different enough to EEM 8.1 that items referred to in the above document are not present.

Anyone does this or have feedback? Reinstalling the EEM is a possibility, but as this may be done on an ongoing basis, client is looking for switching hostname variables.

(Full text search for hostname and IP address would be one technical method of tracing down all locations for one specific box. )

Thanks! Kyle_R.