Rehost issues

[BenLoosli]

I am trying to get a successful rehost or Windchill/PDMLink 10.0 m040 to another set of identical computers for a trial upgrade to Windchill 11.0 m030. I am uisng the Rehost Utility 3.0 m010. After a lot of work and retries, I have finally been able to get Windchill to start, but not without issues.

Let me start by giving a quick over view of my rehost process.

Install Oracle 11g on the test server, run PTC Setup to build the DB

Install Windchill on its test server

OOTB Windchill 10.0 m040 runs fine. I have installed the same modules as on the production serevr, so a Windchill Version report looks idnetical with the exception that I did not install the WinDU/WinRU patches on the test server

Export the Oracle and WindchillDS databases

Copy the vaults using RoboCopy

Copy the cachevaults

Copy the database dumps to the new servers

Copy the db/sql folder over to the new Oracle server

In WindchillDS, create a new base Dn for my company organization

Import the LDIF file into WindchillDS

Put the cachevault file folders back in place

Make sure the main data vaults are in the same location as on the production machine

Copy site.xconf to the new Windchill server

On the oracle server, use SQLPlus to drop user PDM and create a new PDM user

Import the Oracle dump file into the DB

Rehost utility run with setings for clone=InfoEngine, Database, Apache

Rehost utility run with setings for rehost=InfoEngine, Database, Apache

Now for the problems.......

Even with all of this, the Rehost utility is leaving traces and pointers to the original Windchill server in the LDAP.

When I open the LDAP with o=ptc and expand Windchill_10.0, configuration, com, <company name>, I see the next node and its children all reference the original server.

I can open each node and change the entries to the new server and save those changes and then I restart eevrything and Windchill will now start.

However, there are still problems...

I can only use the wcadmn account to log in.

I can open the Partcipant tab and see my username, but it is not valid for logging in

When looking at a detail page of an item in the system, the version fields has:

???versionInfo.identifier.versinId???

Likewise the State field has: ???state.state???

The action drop down should have a Set State menu option, it is missing.

Detail page of a drawing and click the picture to launch Creo View and I get an Action failed message.

Maybe this hsould be an open helpdesk ticket to PTC, and it will be tomorrow, but I wanted to get a feeling from teh community about your experiences with the Rehost Utility and see if anyone has encountered these issues with a simple fix. I know Mike Lockwood has had his frustrations with the utility in the past and has provide me some hints to allow me to get this far.

My complaint with opening a PTC helpdesk call is they want to see my system with a WebEx session. That will not happen as my Windchill system is not even connected to the internet because of data sensitivity. Ant files they want to see, have to be printed and rescanned into my unclassified computer and sent to PTC as PDF files, not original text files.

This whole rehost process is just a nightmare and PTC needs to fix their utility and documentation to make it all easier to do. Not all system administrators are computer science majors!

[TomU]

A couple of problems:

---

In WindchillDS, create a new base Dn for my company organization

Import the LDIF file into WindchillDS

---

You do not need to create a new base Dn.  The LDIF file from your original system needs to completely overwrite anything that was there previously.  You do not want to merge the files.

---

Copy site.xconf to the new Windchill server

---

I'm not 100% sure on this, but I don't think copying the site.xconf is sufficient.  You need to copy everything from the source system to the target system.  This includes all properties and other configuration files.  I don't think just copying the site.xconf will somehow automatically "fix" all of the other configuration files during the rehost.

By the way, if you physically copy the Windchill loadpoint from one system to another, you don't actually have to update the LDAP since it will already be an exact mirror of the source system.

What you seem to be doing is mixing the rehost process with the upgrade process.  These are not the same.  With upgrade you install fresh, merge certain pieces, and then run the upgrade manager.  With rehost you copy everything from one system to another and then run the rehost utility to change certain bits of information.  The only real reason to install Windchill (one time) before running a rehost is just to get the shortcuts and services pre-created.  Everything else should be overwritten before running the utility.

[BenLoosli]

The LDIF import does seem to replace the WindchillDS database, so creating the base dn is a wasted step.

So if I change my procedure to:

Install Windchill 10 on server

Delete the loadpoint and all files

Copy the source WC from loadpoint down to my target system

Run the rehost utility in rehost mode

Do I need to stop the windchill process on the source machine before doing the copy?

[BenLoosli]

Did not work!

Copied the source Windchill folders to the target machine

Ran the rehost utility with the rehost option

Didia restart on WindchillDS

Started Apache

Did a Windchill Start

The system did not start. Method server log file shows LDAP error code 53 - Rejecting the requested operation becasue the connection has not been authenticated; remaining name 'cn=configuration, cn=Windchill_10.0, o=ptc'

I did look in the LDAP and the nodes is still looking for my source computer, not the target.

I have rebooted the serevr and will see what happens if I manually rename all of those service points to the target server.

[shussaini · Accepted solution]

Hello Ben,

I would suggest to add the following line in rehost.properties file under the LDAP section and then execute the rehost utility.

source.local.domain=FQDN of the old hostname

Example:source.local.domain=oldhostname.abc.com

hope that helps.

regards
~Syed

[BenLoosli]

I did open a call with PTC and dumped 250+ pages on them of PDF log file printouts.

They came back overnight with that same reply, documented in CS221186.

https://www.ptc.com/en/support/article?n=CS221186&posno=1&q=source.local.domain&source=search

[MikeLockwood]

Interesting observing this...

My offer still stands: I'll buy anyone in PTC management a lobster dinner w/all the trimmings if any of them can actually successfully execute a rehost process using PTC documentation. 

Can be the simplest possible Windchill system:

- Oracle and Windchill on the same host

- Only PDMLink installed

- Total data consists of one document

- Total LDAP consists of one user

- No replication, no clustering, no HTTPS, no active directoryh integration, no Solr, no customizations, no other complexity

It's just impossible to dig out of the documentation what you are actually supposed to do.

[BenLoosli]

Mike,

I got the rehost to finnally work. See the comments above where PTC has left out a critical line from their base rehost.properties file. Once I added that comment, the rehost went through fine.

But......

I still agree with you that there is a lot of digging and writing of a good process flow to get teh rehost utility to work smoothly.

[shussaini]

Hello Ben,

The line needs to be added as it was a bug, which has been fixed for the latest version of the rehost utility. As regards to the documentation, not sure if you had a chance to go through the latest guide. 

Our team within PTC as end user completely relies on the rehost utility using the rename scenario for a cloud based Windows and Linux environment. R&D has done lot of improvements in the newer releases. If you still feel the guide lacks the details, I would request to put up a list of what is missing and have it translated as product idea.

Hope that helps.

regards
~Syed

[BenLoosli]

Syed,

I am using Rehost Utility 3.0 m010. I see that option listed as an option setting in the latest guide, also.

Will the Rehost Utilty 11,0 m030 also work with Windchill10.0 m040? I think PTC has caused some confusion in the user community by renaming the Rehost Utility with a Windchill release. With it being a standalone versioning, it gave us a better idea of what version of the utility we were running and also what versions of Windchill it supported.

I did look through the lates guide and I did finally find that it will work work with 10.0 and newer.

With me having now got a succesful rehost using Rehost 3.0m010, I will finish my current project with that version. Once I am on Windchill 11, I will then install the nnewer version of the Rehost Utility.

I have not downloaded the latest utility yet, but I would hope that the source.local,domain has been added to the rehost.properties file so it can be seen as an option. I also question this being an ioption. In my case of a rehost, it is a mandatory setting in order for the rehost to complete succesfully.

[BenLoosli]

Well, it looks like that solution has only partially correct. It got me through the rehost process and I can login to the rehosted system, but I do not have file vaults nor can I administer them from the browser.

I get this message when I try to open File Administration:

wt.util.WTRemoteException: Unable to invoke remote method: nested exception is:

         wt.util.WTRemoteException: Unable to locate method server, nested exception is:

         wt.util.WTRemoteException: Unable to locate method server, nested exception is: 

         wt.util.WTRemoteException: Unable to get server, nested exception is: 

         java.security.AccessControlException: access denied ("java.net.SocketPermission" "192.168.xx.xx:5002" "connect, resolve")

Nested exception is: wt.util.WTRemoteException: Unable to invoke remote method

Nested exception is: wt.util.WTRemoteException: Unable to locate method server

Nested exception is: wt.util.WTRemoteException: Unable to locate method server

Nested exception is: wt.util.WTRemoteException: Unable to get server

Nested exception is:  java.security.AccessControlException: access denied ("java.net.SocketPermission" "192.168.xx.xx:5002" "connect, resolve")

[RandyJones]

Have you added your new Windchill server to the "Exception Site List" in the "Security" tab from the Java Control Panel on your local client?

[BenLoosli]

My server is listed as an exception.

[shussaini]

I hope when re-excuted the utility with the option I suggested, vault option was included in projects.properties. If yes, check there are no errors in your MS during the startup. If everything is fine, then ensure you are using the browser version which supports the Java applets. Typically, I download Firefox v51 and completely disable auto-updates for it. Most of the newer browser versions do not support the plugins. Then as Randy mentions, configure the settings in your java for Windchill url exceptions.

Hope that helps.

regards

~Syed

[BenLoosli]

Not seeing any error messages in the rehost logs or in the foreground method server logs.

The background method server is giving a repeating error of:

wt.wvs.content.FileHelper   <username> -

wt.fv.FvFileDoesNot Exist

lower in the file, I see

wt.fv <username> - Revaulting of Srtreamed object wt.fv.FvItem:<some number> to vault vault name <a vault name> Readonly = [false], Enabled = [false] failed

wt.util.WTException: Destination Vault <a vault name> is read only or not enabled

These repeat for 30MB of log file data when I shutdown WIndchill.

Why are my vaults not being seen by Windchill?

They are in the same disk location, just different server.

[TomU]

Do you have a section like this in your rehost.properties file?

############################### Vault Host Settings ################################
#   These properties are needed for the Vault module
####################################################################################
target.fv.hostname.0=<destination server name>
source.fv.hostname.0=<source server name>

Also, are you calling for the vault module in your projects.properties file?

clone.prod=InfoEngine,Database,Apache,Vault,QueueMgmt,Script:UpdateProperties

[BenLoosli]

Projects.properties file was corrcet.

rehost.properties had the entries correct, but I forgot to uncomment the lines.

Uncommented the lines and reran the rehost.bat file

Still getting the same file vault errors.

[TomU]

Have you tried running "Site - Utilities - Filer Server Administration - Vault Configuration"?  You can verify (and change if necessary) the host name and paths of the file vaults.  I'd suggest starting there...

[BenLoosli]

Tom, look up in this thread to my Thursday post.

That is the error I get when I open vault configuration and it won't let me even see the vault information.

[TomU]

Wow, you are just having all the fun.  Must be something to do with 10.0.  It isn't nearly this painful rehosting 11.0.

[BenLoosli]

If I can get GOOD rehosted data of 10.0, I will then do the upgrade to 11.0!

[BenLoosli]

I also opened a PTC help call on this issue.

Added wt.auth.trustedHosts=<Windchill server> and

wt.rmi.clientSocketFactory=wt.boot.WTRMIMasterSocketFactory

to my wt.propertis file and now I can see the Vault configuration stuff.

Don't know why these settings are not needed on my production system to run.

I also lost all of the mounts to my vaults, but that can be rebuilt and I am in the process of doing that now.

Hopefully I can get some V11 upgrade tests in this week so we can go live at the end of the month (next week!!).

[BenLoosli]

I have mounted all of the vaults but 4 which seem to be a different beast.

I have attached a PDF showing the issue. (I hope it attaches)

[BenLoosli]

After another email fromPTC, we removed wt.auth.trustedHosts from wt.properties and I can get into the Vault Confiuration without the JAVAV errors.

[Invisigoth]

I run into that when booting up images that did not originate in my domain.

Add the following to the bottom of your <java.jre>\java.policy "grant" section

permission java.net.SocketPermission "192.168.xx.xx:5002", "connect, accept";
permission java.net.SocketPermission "192.168.xx.xx:5003", "connect, accept";