Community Tip - Learn all about the Community Ranking System, a fun gamification element of the PTC Community. X
We've rehosted production probably 200 times over the years, always using very manual steps. Recently I asked a person on our team to investigate the Rehosting Utillity avalable from PTC. Lots of tech support interaction and lots of hours spent but no success to date.
Main Questions: What is your experience with this utlility? Do you use it? What is your technique for populating the rehost.properties file? Do you utilize multiple rehost.properties files for various purposes?
Note: I read thru the PDF on this thoroughly - doesn't seem to help much in understanding the exact values to use in populuating the rehost.properties file.
Other Question: Since the utility causes your source system to export data, etc., your non-production system is "controlling" the production system thru the utility. We're very leery of this - would like to instead utilize exports that already exist. Is this possible? Anyone else with the same concerns?
note: we're being told by tech support to not bother with the utility that is released and wait for 2.0 due out "soon."
thx
Hi Mike
I've rehosted Windchill systemsmay be a 1000 times in my 15 years of implementing,applying service packsand upgrading since Windchill 5.0. The rehost utility was developed back in Windchill 6/7 and sort of matured in 8/9. Itwas painful backbecauseeither poor documentation or just didn't work well.Back in 2005 for a Windchill 6.2.6 to 7 upgrade, there is always a major difference betweena new install versus a rehosted forWindchill infoengine LDAP structure. The rehosted LDAP structure looked like a mess while the new install looked clean.I wish they would stop placing the Windchill versionWindchill 9, 10, 10.1 in the LDAP structurename.
I use a combination of the rehost utiltiy and my own techniques over the years. I don't always depend on this utility because it is really limited to the configurations you have implemented like clusters, replica's which can be a bit more difficult than the simple normal single application server with a separate database or even multi-server tiered.
Patrick
In Reply to Mike Lockwood:
We've rehosted production probably 200 times over the years, always using very manual steps. Recently I asked a person on our team to investigate the Rehosting Utillity avalable from PTC. Lots of tech support interaction and lots of hours spent but no success to date.
Main Questions: What is your experience with this utlility? Do you use it? What is your technique for populating the rehost.properties file? Do you utilize multiple rehost.properties files for various purposes?
Note: I read thru the PDF on this thoroughly - doesn't seem to help much in understanding the exact values to use in populuating the rehost.properties file.
Other Question: Since the utility causes your source system to export data, etc., your non-production system is "controlling" the production system thru the utility. We're very leery of this - would like to instead utilize exports that already exist. Is this possible? Anyone else with the same concerns?
note: we're being told by tech support to not bother with the utility that is released and wait for 2.0 due out "soon."
thx
I find the Rehost Utility really useful in my cloning process. It doesn’t manage the entire process but it simplifies the changes to properties and LDAP to reflect the new name.
A bit of context on our process…
We clone our systems. That means we take the entire installation and data from one environment, copy it over to the other environment, modify the configuration and run it. There is no pre-installation required.
The process starts with a PROD snapshot which we re-use for as many clones as we need :
- PROD Snapshot : Shutdown PROD, export a DB DMP file, tar the Windchill, Apache, WindchillDS directories, take a listing of current vault content, Startup PROD.
Each clone follows this process :
- Build required servers (Linux VMs). Our environments are Windchill clusters, so they have one master and at least one slave.
- Import DMP file into the target DB server (separate VM)
- Extract Windchill, Apache, WindchillDS from the snapshot onto the master node
- Copy vault as indicated in snapshot listing
- Change server name for a few properties
- Run the Rehost Utility to change the environment name in properties and in LDAP (WindchillDS)
- Copy Apache and Windchill from the master to the slave server (I use rsync all the time)
- Make a few changes to properties so that the slave acts as a slave and not as a master
- Start Windchill cluster 🙂
Although the Rehost Utility is designed so that you can script a lot of the manual tasks I have before and after the Rehost Utility, I haven’t gotten around to building those scripts. It would be nice but it would require time I don’t have to get it done. For now, I get by with the semi-manual process. I can complete a clone in 1-2 days if my VMs are ready.
My 2 cents on the Rehost Utility is that I couldn’t get my clone done without it. Hopefully 2.0 brings improvements to ease of use, documentation and support of the “cloning” scenario. I had to work with PTC to get me through my first clone.
JL
Hi Guys,
I just tested out the rehosting utility in 10.1 M030. Guess what, it has problems. I found out that you still have entries in the WindchillDS pointing to production urls for infoengine jndi and other adapters. Also, after when you fix that you might get possibly LDAP ERROR 49 which is due to encription password keysthat is tied to the previous host.
So, youhave to reset all the passwords of the database, wcadmin, and infoengine admin/WindchillDS admin/cn=Manager.
https://www.ptc.com/appserver/cs/view/solution.jsp?n=CS96619
And walla, all done. Make sure your mirrored/target system is identical to your source.
I guess I don't get a lobster dinner. You guys have fun working it with PTC at the user conference in June. I can't come again this year.
You guys take care and have a great week and weekend.
Patrick