I'm doing an upgrade from 8.10 to 9.0 right now and once again I run up against some crazy issue. It doesn't matter if the configuration is exactly the same as the last client, or if it's a slam-dunk fresh 9.0 install - something always goes wrong.
This time it was a combination of simple issues. I couldn't get the spec merge to run correctly - I kept getting the classic "Invalid Data Source Name" on the source data sources. I've fixed that more times than I can count, and it usually boils down to a typo in the data source name. Sure enough, I found the typo and re-ran the spec merge.
Unfortunately it failed again, this time on the Object Librarian - 810 data source. I went back and re-checked the data sources and the spelling was correct. I saw that there were appropriate entries in the OCMs. I went in to the ODBCs on all machines and made sure everything looked good there too. This is a 64-bit install, so I had to check the 32-bit and the 64-bit ODBC settings. It was all correct.
It was the end of the day by this time and I headed back to the hotel. I took a quick nap and got back on the case. I decided to methodically go through every setting related to Object Librarian - 810 until I found the issue. I looked again at the OCMs and realized that the OCM status column was off the right side of the screen. I scrolled over in the off-chance they were set to NA and sure enough, that was the problem. Once I set all the OL OCMs to AV, the spec merge ran through without errors.
The lesson learned from this incident is when there's an issue that clearly is a result of some simple problem, a methodical analysis of all the settings is the best bet. Leave nothing unchecked, no matter how minor. All CNCs know that even one wrong setting can bring everything to a screeching halt.
Tuesday, March 9, 2010
Wednesday, March 3, 2010
Getting the client ready for your arrival
One of the challenges I face in my job as a traveling consultant is making sure I have everything ready for me to start working when I get to a client. At my job, I often do not find out about a new installation or upgrade until a few days or a week before I have to fly out. Usually this information comes to me while I'm working full-time for another client, so there normally isn't any prep work I can do for them. Even if I had the time, companies are trying to squeeze every penny in savings out of the contract and the timeline is already compressed. I have to get the client to do some of the prep work for me before I get on-site.
Fortunately there is a lot the client can do in advance of my arrival that doesn't take any special knowledge of EnterpriseOne at all. One time-consuming thing a client can do is download all the necessary files for the upgrade/install. Oracle doesn't send out physical media anymore unless you ask, and even then the software might not be as up-to-date as you would find online.
To help out with the downloads, I maintain a current list of all the software required for an upgrade/installation along with instructions on how to log in to eDelivery and download the files. With that, the client can download virtually all the files necessary to get started.
It's a bit of a stretch to ask any client to get Change Assistant configured and start them downloading the Planner ESU, tools release files, and fix current ESUs. There are few companies - even those already using E1 - that know how to use CA. I usually don't send instructions for that unless I'm certain they can do it.
The most important thing the client can do is simply have all the systems ready. Our company sends someone on-site a few weeks before the engagement begins to tell them what kinds of servers to buy, what operating system to install, and what additional software and hardware requirements there are. By the time I find out that I'm the one that going to do the install, the client should be just about finished with all that setup.
The week before I show up on site, I have a conference call with the IT contact at the client and go over their setup with a fine-tooth comb. You have to ask them about each server, every bit of software - everything - and don't take "we're working on it" as an answer. If they can't be confident that the systems will be ready when you get there on Monday, then there's no point in traveling out there just so you can sit on your hands all day.
Of course there is no fool-proof way to determine if a client is totally ready before you show up on-site. With some clients you just have to be there to tell them what it is they need to finish. As a result you can spend a lot of time waiting for things to get ready and burning hours off the clock.
While it all pays the same in the end, the prep work saves the client money by offloading the busy work to them rather than having the expensive consultant do it. It also saves me from losing time I need to finish the installation. Often the next phase of the install begins on a certain date, with other consultants scheduled on-site and client activities scheduled for the implementation. The install has to be finished by that date regardless, so that lost time gets made up during overtime I could be spending with my family.
Just a few checklists prepared and sent to the client in advance can make the installation go smoother. A conference call before going on-site to discuss their preparation can eliminate a lot of frustration in the first week of work. Getting all that out of they way early can also let you enjoy that family BBQ three weeks from now.
Fortunately there is a lot the client can do in advance of my arrival that doesn't take any special knowledge of EnterpriseOne at all. One time-consuming thing a client can do is download all the necessary files for the upgrade/install. Oracle doesn't send out physical media anymore unless you ask, and even then the software might not be as up-to-date as you would find online.
To help out with the downloads, I maintain a current list of all the software required for an upgrade/installation along with instructions on how to log in to eDelivery and download the files. With that, the client can download virtually all the files necessary to get started.
It's a bit of a stretch to ask any client to get Change Assistant configured and start them downloading the Planner ESU, tools release files, and fix current ESUs. There are few companies - even those already using E1 - that know how to use CA. I usually don't send instructions for that unless I'm certain they can do it.
The most important thing the client can do is simply have all the systems ready. Our company sends someone on-site a few weeks before the engagement begins to tell them what kinds of servers to buy, what operating system to install, and what additional software and hardware requirements there are. By the time I find out that I'm the one that going to do the install, the client should be just about finished with all that setup.
The week before I show up on site, I have a conference call with the IT contact at the client and go over their setup with a fine-tooth comb. You have to ask them about each server, every bit of software - everything - and don't take "we're working on it" as an answer. If they can't be confident that the systems will be ready when you get there on Monday, then there's no point in traveling out there just so you can sit on your hands all day.
Of course there is no fool-proof way to determine if a client is totally ready before you show up on-site. With some clients you just have to be there to tell them what it is they need to finish. As a result you can spend a lot of time waiting for things to get ready and burning hours off the clock.
While it all pays the same in the end, the prep work saves the client money by offloading the busy work to them rather than having the expensive consultant do it. It also saves me from losing time I need to finish the installation. Often the next phase of the install begins on a certain date, with other consultants scheduled on-site and client activities scheduled for the implementation. The install has to be finished by that date regardless, so that lost time gets made up during overtime I could be spending with my family.
Just a few checklists prepared and sent to the client in advance can make the installation go smoother. A conference call before going on-site to discuss their preparation can eliminate a lot of frustration in the first week of work. Getting all that out of they way early can also let you enjoy that family BBQ three weeks from now.
Tuesday, March 2, 2010
OE Linux install part 2
Well, so much for updating the blog on a daily basis for the install. Things have been moving fast for me in the past couple weeks, but fortunately there really isn't much to the Linux/Oracle DB install.
I started getting in to the database end of the install and started finding that it took a lot of effort to get 10g patched and capable of running on Linux. After a while I decided that I would install 11g instead since that is what I would actually be installing out in the field.
Installing 11g on Linux is about as easy as it gets... well, for Linux, that is. Of course before you install 11g you'll want to patch Linux using up2date. If you don't have an up2date account, well then I can't help you. next you will extract and run the Oracle installer.
The 11g installer makes things so easy you'll be wondering what steps you skipped when you're done. The very few things you need to do are explained in detail. You'll have to run a couple of scripts of course, and 11g will attempt to download and install any rpms that it needs. There is a list that you'll have to do manually there as well.
I was installing on a 64-bit server, and interestingly enough it required three 32-bit RPMs. To get RPMs for a different architecture, just use the --arch:i386 argument when you run up2date.
After you're finished with all that, you just have to check patches and what-not, and here Oracle 11g shines again. In the new Oracle 11g EM, there is a link for patches and updates. That will go out and find anything you might need to get up to date. Chances are all that was taken care of during the installation, but it's not a bad idea to go ahead and look one more time.
That's all there is to Linux/Oracle DB - seriously. Of course the hard part would be installing E1 on that system but unfortunately I didn't get to that. If I get the chance to do the actual Linux/Oracle install at the client, you can be sure that I'll talk about it a lot!
I started getting in to the database end of the install and started finding that it took a lot of effort to get 10g patched and capable of running on Linux. After a while I decided that I would install 11g instead since that is what I would actually be installing out in the field.
Installing 11g on Linux is about as easy as it gets... well, for Linux, that is. Of course before you install 11g you'll want to patch Linux using up2date. If you don't have an up2date account, well then I can't help you. next you will extract and run the Oracle installer.
The 11g installer makes things so easy you'll be wondering what steps you skipped when you're done. The very few things you need to do are explained in detail. You'll have to run a couple of scripts of course, and 11g will attempt to download and install any rpms that it needs. There is a list that you'll have to do manually there as well.
I was installing on a 64-bit server, and interestingly enough it required three 32-bit RPMs. To get RPMs for a different architecture, just use the --arch:i386 argument when you run up2date.
After you're finished with all that, you just have to check patches and what-not, and here Oracle 11g shines again. In the new Oracle 11g EM, there is a link for patches and updates. That will go out and find anything you might need to get up to date. Chances are all that was taken care of during the installation, but it's not a bad idea to go ahead and look one more time.
That's all there is to Linux/Oracle DB - seriously. Of course the hard part would be installing E1 on that system but unfortunately I didn't get to that. If I get the chance to do the actual Linux/Oracle install at the client, you can be sure that I'll talk about it a lot!
Subscribe to:
Posts (Atom)