We are coming to the end of this painful upgrade (I hope). Chris hit almost every pain point we are/have experiencing too. Give yourselve a six month window for this upgrade. We also found out that even after we got the installers to go through successfully on our staging box, that a lot of backend workflow was missing. The biggest piece is SLM. This may be one of the reasons Chris is not able to load service packs against his system. If you go down the staging server path make sure you validate everything. If you can get away with starting with a fresh build and keep the old data archived off for reporting purposes you will save yourself a lot of headaches. This upgrade is the hardest upgrade I have ever done and I have done a ton of upgrades.
Good luck. Brian On Wed, Nov 21, 2012 at 12:16 PM, strauss <stra...@unt.edu> wrote: > Pour a fresh cup of coffee (or whiskey) and settle in comfortably before > reading ;-) > > The following long and arduous process worked last year (May to August > 2011) for our upgrade from 7.1 to 7.6.04.01 <http://7.6.4.1/>: > > The production system was upgraded as follows, using a staging server for > the upgrades and overlay process, then restoring the db to a new production > server which was a new 64-bit install of the program files (upgrades on > same box remain in the (x86) structure): > > ARS from 7.1.00.002 to 7.1.00.011 to 7.5.00.007 to 7.6.03 to 7.6.04 > SP1 > CMDB from 2.1.00.002 to 2.1.00.006 to 7.6.00.002 to 7.6.03.001 to 7.6.04 > SP1 > AIE from 7.1.00.003 to 7.1.00.008 to 7.6.00.002 to 7.6.03.001 to 7.6.04 > SP1 > ITSM from 7.0.03.009 to 7.6.00.001 to 7.6.03 to 7.6.04 > SP1 > SLM from 7.1.00.002 to 7.6.00.001 to 7.6.03 to 7.6.04 > SP1 > > The upgrade was chosen because all attempts to migrate live SLM data > failed; SLM must be upgraded in place. After upgrading to 7.6.04.01, we ran > BPCU Successfully in Prefixed Overlay Mode to change our customized > workflow to Custom, which we then disabled. Using BPCU on forms proved to > be a disaster in earlier testing (hundreds of forms were overlaid > incorrectly) so we avoided that on the final upgrade and created all of the > form/view/field overlays by hand from 7.6.04.01 objects. Otherwise you get > overlays of the much older (7.0) version of the form, which don't work > properly in 7.6.04. The same was done with workflow, since much of that > was changed significantly from 7.0.x to 7.6.04.01 and it is easier to start > with an overlay of the newest version of the object (active link, filter, > guide) and add only your changes; if you use the BPCU-created overlay it > will be missing every change from 7.0 to 7.6.04.01, and you will have to > add those as in as well! > > After all of the upgrade and overlay processes were complete, we ran the > new production server in parallel to the old production system for a month > of acceptance testing, during which time updates to data in dozens of > tables on production were synced to the new server nightly using batches of > RRR|Chive scripts (including SLM transactions!!). This was done safely by > setting the NextID on all of those tables to the next 10,000, 100,000, or > whatever level so that all new records in Incident, SLM, Email, etc., on > the new server never conflicted with data coming in from production each > night. That also meant that any work on the new production server by our > early-adopting departments was real, live data, and would remain live after > the cutover. Cutover involved setting the old production server to > Administrator-Only Mode, and changing the web page links to the new > mid-tiers and iframes to point at the newer Kinetic Request console, which > we also upgraded from 4.0.3 to 5.0.2. > > The patch level to patch level jumps were recommended by BMC based upon > what they were seeing actually work - other patch levels and larger jumps > were failing miserably for us and for other customers. I cannot tell you > what to use for the jump from 7.0.01.006 to 7.1.00.002, and only ONE BMC > support tech was savvy enough to be able to recommend the sequence we > finally used. They have a good reason to want you to jump from ITSM > 7.0.01.006 to 009 first; we started there, and there were a LOT of changes > in 008 and 009. > > On operating systems, we remained on Windows 2003 servers (from 2003 to > 2003 R2) due to lane java requirements for AlarmPoint - a complete waste > since that product turned out to be a disastrous failure against ITSM > 7.6.04. The db went from SQL Server 2005 to 2008 with that hosted on > Windows 2008 R2. > > You must go through all of the db cleanup steps every time you move the db > and restore it under a different server; that has been discussed on the > list recently, as well as in the archives. In our case that was once on the > staging server before all of the upgrades (restored from old production), > and again on the new production server when restored from the staging > server. > > One last warning; when you upgrade a server that many levels, some tables > and views are never upgraded the way that the BMC developers think they > should be, and when we tested the 7.6.04.02 installers for Atrium and ITSM > they choked on a number of tables/views left over in the system upgraded to > 7.6.04.01, which were not as they would be in a NEW 7.6.04.01 install. > After fighting with BMC support (they never seemed to fully understand > this), we abandoned 7.6.04.02 for the apps (ARS went to Sp3 correctly, but > not Sp2) and are still on SP1. We will have to fight this again to get to > 8.0.x, unless we switch to a different vendor's product. > > I cannot speak for SRM - we did not use it and still don't, but installed > it on the new 7.6.04.01 server and left it alone. Also RKM 7.6.04.01 - > installed it and left it alone. We are still live on RKM 7.2 due to the > MYRIAD problems we found in RKM 7.6.04.01, some of which still have not > been fixed in 8.0.00! Since it appears that you do not have either one in > production now, that is two less headaches for the upgrade. > > As to upgrading to 8.0.00, I have not tried that yet and won't until SP1 > comes out. I put a Preconfigured Stack Install on a couple of Windows 2008 > R2 VMs easily enough, but had trouble with all of the Patch installers (now > on ARS Patch 002, apps Patch 001). It turns out that they must be run as > administrator in order to work in our setup, which was not true of the > stack installer. I would not rate 8.0.00 as ready for production yet, and > if you have customizations you will want to get them moved to overlays at > the point where you have upgraded to 7.6.04.01. > > If all this scares the heck out of you, and you are not required to > upgrade (I don't see SLM on your list of implemented apps), the new install > - customize - migrate data option may be a lot less trouble. Many of our > customizations were eliminated in the jump from 7.0 apps to 7.6.04, and > another major one (adding Login Name back in as the key field for people > searches) has FINALLY been restored in 8.0 and I will be able to drop it in > that upgrade if we decide to move up. As William pointed out, you have to > read and re-read a lot of upgrade documentation, most of which was > incomplete or incorrect for 7.6.03 and 7.6.04.00. > > Christopher Strauss, Ph.D. > Call Tracking Administration Manager > University of North Texas Computing & IT Center > http://itsm.unt.edu/ > > -----Original Message----- > From: Action Request System discussion list(ARSList) [mailto: > arslist@ARSLIST.ORG] On Behalf Of Mary C. > Sent: Tuesday, November 20, 2012 8:05 PM > To: arslist@ARSLIST.ORG > Subject: AR System & ITSM Upgrades (we are WAY behind) > > Hi, > > We are on AR System 7.0.01 Patch 006, CMDB 2.0.1, ITSM 7.0.3 Patch 006 and > SLM 7.0.1 Patch 4. We were unable to consider upgrading until now, and of > course this is going to be a major effort from what I can see. We have > some customizations, but I think I could rebuild them from scratch if I had > to. We are in a Windows/SQL server setup and are running a server group. > We want to upgrade everything to 8.0 > > Here is a high-level upgrade path that Support recommended. > A) Upgrade ITSM 7.0.3 patch 6 to ITSM 7.0.3 patch 9. > B) Run ARserver 7.6.04 patch 4 in upgrade mode. > C) Run the difference report to find the customization. > D) Create Overlay to retain customization. > E) Then upgrade CMDB 7.6.04 patch 4 > F) Then upgrade ITSM 7.6.04 patch 4. > G) Once everything is working fine upgrade ARS, CMDB and ITSM to 8.0 > > Do you all agree with this upgrade path? Would you recommend another > approach? > Any advice you can give me would be appreciated. Many of you have listed > lots of gotchas, so I am semi-planning for those pitfalls. > > Thank! > > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 > www.wwrug12.com ARSList: "Where the Answers Are" > > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are" > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
