Good summary and collection of links.
Unfortunately I don't agree with step2 at the moment. We've done it (8/2016 Hotifx at patch 001) and after installation SRM can't create backend tickets. The corrected date funktions in ARS HF seems buggy, SRM tries to create tickets with date information 1/1/1970 instead of the real dates. Maybe a problem only with german date formats, but an fatal issue for such a big and important HF and library date changes.
With patch 001 only, all works fine! Newer is not always better, do not blindly trust!
Currently we discuss it with BMC support, but this takes time as you know.
I will look into this issue.
We see a trend of BMC asking to install cumulative packages of hot-fixes for any kind of issue detected. However hot-fixes never should be installed if not needed to solve a critical issue. As hot-fixes normally are developed quickly and outside normal development and testing processes, the risk to apply hot-fixes in a production environment is to high for non critical issues.
I fully agree with Stefan and Jan. In my opinion, step 2 should only recommended IF you have enough time to re-do all your UAT testing (including system stability tests) on a QA environment which contains those hotfixes.
We just barely survived a huge upgrade from 7.6.04 SP5 to 9.1 SP1 (many hotfixes installed). The vast majority of our go live issues were not present during our UAT which was completed successfully on 9.1 SP1 (no hotfixes). As soon as we installed the absolutel latest hotfixes in PROD during go live cutover (as per BMC strong recommendations which we received), we started having all kinds of issues during our first go live week, with many functionalities now broken (and I mean MANY) which were extensively tested successfully before the hotfixes were applied.
I can say that I will never go for hotfixes again like that.
I will only agree to a hotfix install to fix a VERY specific issue in a CRITICAL situation with no workaround possible.
This was like trying to cure a cold we didn't know we had and then getting a life threating pneumonia in the process.
We are in the process of upgrading from ITSM 8.1 to ITSM 9.1. This is an upgrade in place using Windows, Oracle and Tomcat. Our UAT environment is very straight forward: 3 app hosts, Server Grouped, and three web hosts, all behind load balancers. Running the upgrade against non Server Grouped environments went well enough with only a few minor issues; items not documented that tool support calls to correct.
However, the upgrade of UAT has not gone well. Getting the installers just to run was a challenge because of Server Grouping, we think. Took several support calls to BMC to find the hidden settings needed to allow the installers to work. The installers finished with no errors but we have been struggling to get all three servers running sharing processes. There are so many changes that are not clearly documented, makes debugging the issue very difficult.
We have been working with BMC for almost two weeks and still do not have a working UAT environment. Sometimes one of the app servers won't even start and if it does it will stop responding for no apparent reason. The failing over of process is not working and FTS and approval will not run; log files are full of Java errors that are totally cryptic.
Wondering if any one has successfully upgrade from 8.1 to 9.1 using server grouping?
We upgraded successfully with server grouping, but it was from 7.6.04 SP5 and not 8.1. Doesn't make a difference for the issue you mention anyway.
We had very similar awkward behavior in prod in regards to failover, and in our case, it was only fully fixed after BMC applied a hotfix, targetting specifically a failover bug in 9.1 SP1.
you mean 9.1.00 Patch 001 instead of SP1, right? As I remember SP1 don't exist for ARS / Core. Can you post the defect number so we can ask for the hotfix you mentioned. The official ARS HF (Aug. 2016) is too buggy to install as is.
Should be patch 1 for ARSystem and Atrium Core for 9.1.00
Hot fixes are:
ITSM does have a SP1 for 9.1.00
Thank you for posting. Just concerned around these "hidden settings" that need to be done for the installation to work successfully. Would you be willing to share what settings were changed or will BMC be updating their online documentation to include these steps?
5 of 5 people found this helpful
The following is a list of issues we ran into after upgrading from ITSM 8.1 to ITSM 9.1:
- Java ARDBC LDAP Plugin issues: with the introduction of the Centralized Configuration module ARDBC connections were no longer showing; a new ar.cfg parameter "Configuration-name" was introduced and the server values needs to match the underlying server name, with the same case.
- Vendor form issues using Java ARDBC LDAP. Queries were not being correctly formatted. a hotfix was provided.
- The Remedy license keys were no longer valid after the upgrade. This happened in 3 environments; same license keys we've had for years on the app VMs no longer worked. BMC did not have a reason/solution.
- TCP ports 61617 and 40001 needed to be opened in the firewall rules for Server Grouping.
- Several SYS:Notification Messages records we customized were overwritten by the upgrade.
- RKM status transition records we modified were overwritten by the upgrade.
- RKM SYS:PredefinedQueries we modified were overwritten by the upgrade.
- RKM Relevancy Boost increments we updated were overwritten by the upgrade.
- RKM Problem Solution data source we disabled was enabled during the upgrade.
- Server Context plugin errors opening SHR:LandingConsole. Per BMC disable filter SHR:LHP:InitSvc_GetServiceContextFlag.
We have spent that last 2+ weeks trying to get Server Grouping working (3 ARS servers). We have applied 3 ARS hotfixes and none of them have worked. We think the Server Grouping issue is preventing one of the ARS servers from starting. Next step is to restore the environment and retry the upgrade.
3 of 3 people found this helpful
ditto on the LDAP ARDBC issues, same here. We also had a lot of challenges in the CMDB area, since we used Assetlifecycle status in Reconjobs, and since that attribute is no longer available on the CMDB forms as such (moved to AST:Attributes), we had to redesign a bit those jobs.
We had similar bumps to get the server group 100% correctly (which it is now). We have 2 integration servers (one being the admin server) and 3 end user servers. In our case, after quite a few hectic days of not being able to get the server group working, even after installing hotfixes and having assistance from BMC 3rd level teams, we went back to the basics and it was what fixed it for us:
- we took down all servers down except the admin.
- Then we removed the admin from the server group, cleared ranking form entries and started it as individual server.
- We made sure that server was working ok as an individual server (no major errors in logs, etc)
- Also cleared stuff from forms like application pending.
- Then we added this admin to the server group again and restarted to see if ranking was populated fine, components like dispatcher, approval and so on were working ok, also checking the database tables which reflect server group status/information (stuff like servgrp_board and so on).
- Once that looked fine, then we ensured all config of secondary servers was consistent across all servers (ar.cfg and so on) and gradually added the other servers to the server group, always allowing some time in between to verify if the new server was behaving properly.
- During this time, logs like servergroup logs were always enabled and quite helpful, especially during failover tests (which we executed once we had 2 servers in the server group, before adding more).
Is there any documentation on going from 7.6.04 to Remedy 9.1? Specifically, we are having trouble with the AST:Attributes change but aren't sure how to correct it.