You are viewing limited content. For full access, please sign in.

Question

Question

Does Redirects in Workflow also redirects Trustee Directories?

Workflow Version 10 Installation and Upgrades
Updated November 11, 2016
asked on November 11, 2016 • Show version history

Little background, we moved and upgraded Laserfiche 9.2 from server named LFSERVER to new server named LF1. (Edit: the move includes Laserfiche Server and Workflow)There was an issue with Workflow service that was not able to start which required us to change the LF1's host file to route any references going to LFSERVER FQDN to IP address of LF1. All services were up and running after that.  

We noticed that the Workflow was not monitoring the repositories, so we went in the monitored repositories and deleted all these entries (all were being referenced through LFSERVER name) and added them back using the LF1 reference which then got the workflows to kick off. We also had the Redirects set for each repository. 

Now we are having an issue with workflows that uses any activities that needs to look up against Trustee Directories. Activities like Find User or Find Groups are throwing warnings such as: There are only Laserfiche Trustee users. Since we moved from LFSERVER to LF1, applying the redirects and having to change system host file doesn't seem to have any effect on this. It only works if we go ahead and republish this workflow with the new Trustee Directory. This adds lot of time since there's over hundreds of workflows to go through and was hoping the redirects should have taken care of that. 

This is what I see before making any changes to individual workflows: 

(Might not be related but Oddly enough, switching them to the new Trustee Directory changes the token name "E-mail" to "Email")

This is after I made the change:

Just to wrap up here, my concern is the functionality of redirects in Workflow. After adding the redirects, I am seeing these errors. Is this expected behavior? I have to go to each workflow and individually update the Trustee Directory on each activity? Please advise.

0 0

Answer

SELECTED ANSWER
replied on November 11, 2016

I would still recommend moving them separately. If that's not possible, then:

  1. Add redirects to WFServer pointing it to where the new LFServer will be
  2. Stop the Workflow services
  3. Stop the Laserfiche Server
  4. Backup SQL databases
  5. Move SQL DBs
  6. Move WF volume and LFS volumes
  7. Move WF registry key for each monitored repository
  8. Register the repository on the new LF Server
  9. Confirm the repository is fully functional
  10. Configure WF Server on the new server with the moved SQL DB
  11. Configure the Subscriber
  12. Confirm the Subscriber connected to the repository by checking either the Subscriber Trace or the All Sessions node in the LF Admin Console
  13. Confirm workflows start correctly
  14. Republish the Workflow rules with updated connection profiles pointing at the new LF Server.
  15. Confirm new workflows start correctly
  16. Remove the redirects (there's a bit of a performance hit associated with the redirects, so while steps 14-16 don't have to be done immediately after the move, they should be done)

 

1 0

Replies

replied on November 11, 2016

Find User uses WFUser$ to connect. From the error message and your description, I'm guessing it's getting to the LF Server based on the hosts file redirect, not from the Workflow redirects. 

By removing and re-adding the repository, the password for that user was reset. So even though Workflow gets to the right server, the password it has registered for the original repository no longer works. And because the repository was re-registered, it won't attempt to use the new password because that's considered a different repository.

The redirects were intended for the case where the repository is moved or renamed. Re-registering the repository renders them inactive. By themselves, the redirects would've worked, but there are now various changes that it's hard to say what actually happened.

The Workflow server starts without a connection to the repository, so it's not clear to me what the issue was that required you to add a hosts file on LF1 to get the Workflow Server on a different machine to start. It's my understanding that the hosts file redirects connections going out of the machine, so again, not sure why you needed one on the LF Server for Workflow to connect in.

1 0
View 5 previous replies
replied on November 11, 2016 • Show version history

I opened a ticket with Laserfiche for the issue when we tried to start configure the Workflow Service through Workflow Configuration manager. We were getting following error: " Connection to the Workflow Server 'localhost' could not be created. " LF Support told us to perform this change to host file to make it work. Otherwise the service was not turning on.

As for the re-registering the repository, initially when we got the workflow service and subscriber up and running, all items in Workflow Configuration Manager are set to configured , all services looked good. However, workflows were not kicking off. The only way to get them working was to re-register the repository with the new machine name.

 

0 0
replied on November 11, 2016

Right, I talked to Tech Support, they indicated that the Workflow Server was moved as well, which makes a lot of difference to this conversation. The redirects should be put in place before moving the repository.

As far as why workflows were not starting, it's hard to guess without looking at the logs. If they're attached to the support cases, I'll look them over to see if there was a bug there.

1 0
replied on November 11, 2016 • Show version history

Thanks. The logs are attached in the support cases. Can you clarify what you mean by before moving the repository?

Just to confirm the order of steps in Workflow Configuration Manager you are suggesting:

1. Configure Workflow Server

2. Once running, set the redirects

3. Configure the Workflow Subscriber

4. Configure Monitor Repositories

     4a. At this point we do not need to re-register the repository? the redirects  should be able to resolve the address and won't have issues with detecting activities in repository?

 

 

0 0
replied on November 11, 2016

No, I mean, the redirects should've been configured in Workflow on the original server before either WF or LFS were moved.

The redirects are used as a fallback mechanism if the original paths/passwords fail. If you put them in after the fact, you may lose instances because the new server would start processing workflows on startup, possibly before you create the redirects.

More information on moving Workflow servers can be found in this thread.

1 0
replied on November 11, 2016 • Show version history

I see. So if we put the redirects in, those redirects wont' kick in the existing workflows in the old server unless any connection were to fail?

EDIT: Also, the link you pointed to suggest to move the database first and get the Workflow server to connect to the moved database and new Laserfiche server first and then set in the redirect. Is that correct?

0 0
replied on November 11, 2016

Correct. They're backups for when the original server goes down.

1 0
replied on November 11, 2016 • Show version history

Just to make sure I follow the correct steps for my configuration where Laserfiche Server 10.1 and Workflow 10 is already installed.

  1. Add Redirects in the old server
  2. Stop LFS on the older server
  3. Stop WF on the older server
  4. Move the SQL DB for LFS and WF to the new server
  5. Move the WF volumes & registeries
  6. Register the repository through Admin Console of new server
  7. Configure WF in new server to use the moved SQL DB
  8. Configure Subscriber
  9. Do not re-register the repository in Workflow Configuration (redirect should take care of it)
  10. Confirm workflows start correctly
0 0
SELECTED ANSWER
replied on November 11, 2016

I would still recommend moving them separately. If that's not possible, then:

  1. Add redirects to WFServer pointing it to where the new LFServer will be
  2. Stop the Workflow services
  3. Stop the Laserfiche Server
  4. Backup SQL databases
  5. Move SQL DBs
  6. Move WF volume and LFS volumes
  7. Move WF registry key for each monitored repository
  8. Register the repository on the new LF Server
  9. Confirm the repository is fully functional
  10. Configure WF Server on the new server with the moved SQL DB
  11. Configure the Subscriber
  12. Confirm the Subscriber connected to the repository by checking either the Subscriber Trace or the All Sessions node in the LF Admin Console
  13. Confirm workflows start correctly
  14. Republish the Workflow rules with updated connection profiles pointing at the new LF Server.
  15. Confirm new workflows start correctly
  16. Remove the redirects (there's a bit of a performance hit associated with the redirects, so while steps 14-16 don't have to be done immediately after the move, they should be done)

 

1 0
You are not allowed to follow up in this post.

Sign in to reply to this post.

Details
Related Posts
Loading ...