Community Tip - Your Friends List is a way to easily have access to the community members that you interact with the most! X
Normally, when we move to a new PDMLink release, we build a new target server(usually so that we could move to a newer/faster server, but our VM has made that somewhat moot) and upgrade from the existing production server. Our customer would like to keep the same server name for the URL, so has anyone done this upgrade to the existing server? We thought we would backup the Ldap and Oracle tables, install the 10.2 software, and run the UpgradeManager against the existing data. One thought I had was do you install the 10.2 Direstory Server or use the one in place. Pros and cons?
Send lawyers, guns, and money...the sh!t has hit the fan!
Bill,
Although I haven't done a 10.x update yet, this task should be classified as an update not upgrade. I'm pretty sure that PTC would consider this a point release update with the main difference being that you will not run the upgrademanager. Without going into much detail, the plan to update would look something like this:
Disclaimer: You should test this in a dev environment first and foremost. Download any update\upgrade guides from PTC. This will be most helpful.
1. Make backups (LDAP and oracle\sql db,Windchill solution install directory, Java, Global Registry, etc).
2.Install Windchill Solution (The solution installer should recognize that 10.x already exists). You may need to select the instance to update.
3. Follow any PTC guidance on running update tools.
Hope this helps!!!
Thanks Brian. That is good to know. No worries, however. In place upgrades are very possible as we just performed one from 9.1 m070to 10.2 m020. It would not be very practical on PTC's part to require companies to use new hardware for an upgrade(excluding compatibility issues). They understand this as well. I assure you it is very possible. You could just install the new windchill 10.2 install to a new folder x:\ptc\Windchill_10_2 for example. I've attached a generic outline of tasks to proceed with. It is broken in to 5 different phases. 1)Getting Upgrade Help 2) Pre-Upgrade Activities 3) Installing 10.2 on Target 4) Upgrade Target activities 5) Post Upgrade Activities.
Maybe this will helpget you started with your In Place Upgrade.
Hi Jason,
Are you sure that your step 4b in your document is needed (modifying the db connections in the 10.2 loadpoint using xconfmanager) before running upgrademanager.
My understanding is that you enter the source db connection details into the gather database page of upgrademanager and this then updates the target application loadpoint to connect to the source database?
Rgds
Gary
Good point Gary,
That is probably an unnecesary step. It is true that theUpgradeManager adds several properties to the site.xconf, etc. I'm just a creature of habit from the old 8.0 to 9.0 migration days.
Jason’s comments and the article (CS187109) are technically correct. What it really means is the upgrade process is much, much, much better than it used to be and we aren’t required to have three sets of hardware like we were told in the Windchill 8.0/9.0 time frame. We still need two sets of hardware (test and production).
Maybe Windchill migration, upgrade and update experience has made me overly risk adverse but I would not recommend upgrading production directly. I prefer to upgrade in the test environment and rehost it to production when successful.
Bill,
You can take a dump of oracle and export the ldap ldif file
shut down all windchill components (not db)
remove the oracle instance (default is WIND)
Install windchill 10.2 (do not use the same DB user name)
import Ldap (append), create SOURCE oracle user from script, you can drop the OOTB user created on install
import the source DB, fix errors
I have used this technique many times, as the others say it is classed as an upgrade.
-=D