Hi John, I had a really hard time completing the upgrades from 7604. Everything had to be patched to 7604 SP4 first. That wasn't really hard. The main trouble was that we also ran into an issue because the system that I was upgrading had a failed RKM installation in 7604 that I didn't know about. That failed install caused problems in the upgrade, we manually redid the ITSM installation about 3 times, fixing problems as we went and then resetting the installer and temp folder, etc. Ultimately it installed successfully; however, once we really started reviewing the apps, we had more problems with RKM than we could deal with and ultimately opted to build a new 8.1 environment and port the customizations and data.
My experience with installing 8.1 was on Windows 2012/SQL 2012 with a Windows administrator account. Both are VMs on the same physical host and SQL was a local account. To be honest, the clean installs were super easy and fast. I made sure any hardware pre-req that I could think of was met. There was plenty of disk space and memory for the servers. One thing I have noticed is that the Core and ITSM installers need quite a large amount of disk space to unpack everything. While the ultimate product isn't insane for disk space, the installation temporarily uses a lot of disk space. Another item I've noticed with the installers also prior to 8.1 is that SQL databases that have transaction logging on will take longer for the installer to run because it's of course logging all of those changes. I would lean towards looking at where that DB is running, if it's in a shared SQL environment and there isn't enough juice to run, the install will just dog. I had that happen once, turns out that SQL admin had something like 2GB ram allocated to the db, I talked them into jumping it up to 12gb (since it was shared) and the install completed. The other thing to investigate is network latency as I'm sure you know. Oh, and are you doing any of the installs with the installers on shared drives? The installers on shared drives tend to be a problem. HTH Janie On Thu, Oct 31, 2013 at 2:56 PM, Reiser, John J <[email protected]>wrote: > ** > Hello Listers, > ARS 8.1.00 > MS SQL Server 2008 R2 (remote) > OS Windows Enterprise 2003 > > I am having the worst time trying to get a bare bones Remedy ARSystem > server installed. > I have admin rights for the user running the setup.exe file. That windows > user also is the db_owner of the ARSystem_test database which was created > during the installation process. > It takes forever to complete, the starting services time is the longest. > When it does complete the install is flagged as failed because the ARSystem > would not start in a “timely fashion”. > I have a ticket open with BMC Support and they have given me some things > to check that was pulled out of the installation logs. > The settings that they questioned were supposedly confirmed by the DBA but > all I can tell is that the MS SQL Server DB is “owned” by the windows > account. > > Because of all of these oddities I dare not touch my production system > (7.6.03) or my sandbox (7.6.04 SP3) for fear of breaking them too. They > were upgraded from earlier versions and have a legacy sql account as the > owner but the services run on the ARS machine with the same domain account > as the one I’m using for the test. > > System policy does not allow for giving the sa account out and local SQL > accounts are discouraged so I am using a windows domain account to run the > install, own the DB and run the services on the ARSystem server machine. > > Has anyone seen any gotchas like file system permission restrictions on a > windows server or some other idiosyncrasy that could prevent the > installation from completing successfully? > > > Thank you, > --- > John J. Reiser > Remedy Developer/Administrator > Senior Software Development Analyst > Lockheed Martin - MS2 > The star that burns twice as bright burns half as long. > Pay close attention and be illuminated by its brilliance. - paraphrased by > me > > > > _ARSlist: "Where the Answers Are" and have been for 20 years_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
