We are planning to upgrade the CA SD from r14.1.02 to r17.1.02, in this regard kindly let me know if we can follow the swing box approach to upgrade? Can anyone share any documents pertaining to this upgrade?
The page in the 17.1 documentation is here:
The 17.1 documentation has detailed steps regarding the SWING BOX upgrade method
Use the Swing Box Method to Upgrade to CA SDM 17.1 - CA Service Management - 17.1 - CA Technologies Documentation
Thanks Karen and Paul for the quick response, I understand that, with this version, we do have Jasper reports. Is it a separate file or is it part of the CA SD installation? Also if any links regarding that would be appreciated.
JasperSoft is a separate installation.
There is a separate ISO with the 17.1 install media set.
Please refer to the following documentation regarding JasperSoft installation and integration with SM 17.1:
CABI JasperReports® Server for CA Service Management - CA Service Management - 17.1 - CA Technologies Documentation
Be advised that if you currently have custom BOXI reports, these reports will need to be manually recreated in JasperSoft as there is no migration utility.
Hi Paul, We don't have any custom BOXI reports, we are using the SSRS.
It means we don't have to install it as it is a separate installer.
That is correct - you don't need to worry about the JasperSoft install since you are using SSRS for reporting.
And I was planning to install 17.1.02 patch as well, but I can see that in pre-requisite, we should have xFlow installed. Is the understanding correct ? if yes, do we have any documentation on the h/w requirements for xFlow?
xFlow is not a pre-requisite for the SDM 17.1 RU2 patch.
If you have xFlow installed, the 17.1 RU2 patch common installer will provide the option to install RU2 for SDM and xFlow.
Thanks Paul, Few more queries:
1. Can we use shared sql instance for CA Service desk?
2. I saw that the database server should not be in a virtual server (Checked in the KB article https://comm.support.ca.com/kb/ca-service-desk-manager-service-desk-and-ms-sql-server-performance/kb000021152)
Does this mean that it should not be on a VM machine?
Yes, you can use a SQL named instance.
We do not recommend installing SQL server on a virtual server for performance reasons. SQL Server is a very resource intensive application and resources adequate resources.
If you search the internet, you can find many articles regarding installing and configured SQL Server in a virtual environment. For example, https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/solutions/sql-server-on-vmware-best-practices-guide.pd…
I'm confused a bit now, is there a difference between shared and named instance?
Shared and named instance means the same thing.
So our plan is like this:
1. Development environment: Conventional configuration- 1 Primary Server, 1 Shared dB Server
2. New 17.1 Production environment: AA - 1 BG, 1 Stdby, 2 Apps
High level steps:
1. Install vanilla SD 14.1 in Development
2. Backup from current production, restore in vanilla db (Dev)
3. Run SDM Configuration(pdm_publish)
4. Run 17.1 upgrade
5. Do all form customizations
1. Take one of the Servers (out of 4) & install 14.1 vanilla.
2. Restore the current production backup(latest)
3. Run SDM Configuration(pdm_publish)
5. Run configuration to make this server as background server
6. Add rest of the servers in the server list from background
7. Install standby, application servers
8. Paste all the customizations
Successful go live
Does this look fine?
Initial plan was to have a separate server for swingbox(before go-live), instead we'll use one of the prod servers as mentioned above and make it background later. Will this cause any issue?
We did the upgrade using the swingbox method because we also needed to upgrade the OS on our server vms at the same time. The Upgrade seemed to mostly work OK, however, the Installer silently failed on our production servers and somehow left some 17.0 files not upgraded to 17.1. It worked properly in our dev environment, however. We also ran into an issue where options in Service Desk were set back to defaults and had to be re-entered manually.