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

Question

Question

Laserfiche Account Migration Tool

asked on June 5

Hello,

 

I am starting the process of planning a migration of 100 Forms Participants to LFDS. These users will be switched to use LFDS authentication through Forms and will be using Authenticated Participant licenses. Currently there are over 250 forms with users assigned to multiple tasks. I wanted to know if anyone has had success using the Account Migration Tool. The last two times it was used it caused major forms database issues. Have there been improvements to this tool? Running the tool and hoping for the best is not an option for this scenario.

 

I also see the link to the Account Migration Tool does not work. Is that because it is no longer suggested to use that tool? If so, how do we move 100 participant users from LDAP to LFDS and keep their assigned task and history in Forms?

https://support.laserfiche.com/kb/1014036/laserfiche-account-migration-tool

 

Regards,

0 0

Replies

replied on June 5 Show version history

Hi Drew,

As you noted, the migration tool had a major bug  in how it handled Forms --- which is why it is has been temporarily taken down. 

We are working on getting a new version of the utility released and we have addressed the issue you mentioned.

 

However, this utility not needed for LDAP users and in fact does not touch LDAP users at all. Migrating LDAP users is a matter of 

  1. Adding the users to LFDS*  (you can use AD group sync)
  2. Switching to LFDS authentication

 

Important notes on adding the users to LFDS:

In older versions of Forms (before 10.4) the users have a "derived SID", which is to say that their unique identifier in Forms is not the same as their Windows SID. However, LFDS also supports users with derived SIDs.

To create the users in LFDS such that they can be properly migrated, start by creating an LDAP identity provider without the option to "preserve Windows SIDs"

 

If you would like to switch to using Windows Authentication (as opposed to LDAP) in LFDS, you must be on Forms 10.4+.

On Forms 10.4, the AD as LDAP participants are created by default with the Windows SID, and if you have existing users, you can perform a one-way conversion of their SIDs. This conversion is an option in Forms user management page.

After converting the users, you then do the following:

  1. Create an Active Directory identity provider
  2. Add the same users
  3. Switch to LFDS authentication

This allows them to both retain their tasks and switch to using regular windows authentication

2 0
replied on June 6

Thank You for this information Brianna. It was never confirmed to me that the migration tool utility had a specific issue. Also, I really appreciate your response. This will be very helpful with the Forms user move to LFDS we will be initiating soon. 

0 0
replied on July 3

As an update, the migration utility is back online with the Forms migration issues resolved. It sounds like you don't need the utility for this case, but I wanted to let you know in case it comes up in future migrations.

To make sure you have the correct version, check that the modified date on the .EXE is June 27th, 2019.

Remember to back up all relevant databases (Forms, LFDS, LF Server repository database) before running the utility.

0 0
replied on July 16

Hey Brianna,

 

I was working on this today. I had to open a case due to an issue with the LFDS group not showing in the Forms config. I was reviewing the documentation on this and I wanted to confirm I have the process understood.

 

- Add the LFDS LDAP Identity Provider(per your screenshot)

- Add the participants from that Identity Provider to LFDS

- Assign those users the Forms group

- Do I give them a participant license? We only have 100 and I will have to remove the license block in LFDS from that Forms server.

- Configure Forms to use LFDS authentication.

- Run the migration tool under User Authentication in the Forms config.

 

Please let me know if I am missing anything

0 0
replied on July 16 Show version history

Since I didn't mention it above, I want to clarify that there are two kinds of participant users: LDAP participants which are from your active directory, and participants that only exist within Forms.

The second type of users are migrated after you switch to LFDS authentication within Forms.

To address your list:

 

- Add the LFDS LDAP Identity Provider(per your screenshot)

Do you want to keep the users as LDAP users rather than using a regular Active Directory identity provider? Active directory users can still login using the username@domain.com + windows password.

The most important part is that the SID needs to match between LFDS and Forms. If you are on Forms 10.4 or higher, and you do not see the option to convert the users to regular AD SIDs, then they probably already are using the regular AD SIDs. As such, you should check the box to retain AD SIDS for your LDAP provider.

 

- Add the participants from that Identity Provider to LFDS

- Assign those users the Forms group

Correct

 

- Do I give them a participant license? We only have 100 and I will have to remove the license block in LFDS from that Forms server.

You are correct that you will need to remove the licenses from the Forms server so that they are available within LFDS.

 

- Configure Forms to use LFDS authentication.

Make sure that when you do this, you select the group you mentioned earlier

 

- Run the migration tool under User Authentication in the Forms config.

You only need to run the migration tool if you have none LDAP users. 

1 0
replied on July 18

Hey Brianna,

 

I have one more question:

 

"Do you want to keep the users as LDAP users rather than using a regular Active Directory identity provider? Active directory users can still login using the username@domain.com + windows password."

 

We want to move all Forms LDAP participant users to use LFDS Active Directory Forms Participant users. We want to retain their SID so the tasks assignments are not cleared out. Am I going through the right process according to your instructions?

 

Thank You! 

0 0
replied on July 23

Hey Brianna,

 

Any suggestions regarding my previous response?

 

Regards,

0 0
replied on July 24

You should determine whether your LDAP participant users have retained their AD SIDs or not.

  • If you are on a version prior to 10.4, the users do not have AD SIDs
    • To convert to regular Windows users in LFDS, you must first upgrade to Forms 10.4
  • If you are on version 10.4+, see pictures below

 

If you see this box and it is UNchecked, then the users do not have AD SIDs:

If you check the box and save, you will be prompted to migrate the SIDS to AD SIDs:

 

Once all users have AD SIDs, then you can proceed according to the steps in my earlier reply

0 0
replied on July 25

Perfect! I upgraded them to 10.4 specifically so that we could retain the SID.

1 0
replied on August 22

@████████, you mention that the Account Migration Tool is not needed for LDAP accounts. I would like to get clarification on that statement.

I have a client that has 138 Authenticated Participant Licenses in Forms that are configured using LDAP. We will be upgrading them from Avante 10.4.0 to Rio 10.4.0. If I want to migrate them to LFDS as Windows Accounts, I need to do the following:

  1. Create the AD users in Directory Server and assign Participant Licenses to them.
  2. Check the 'Retain Active Directory SIDs' checkbox in the LDAP Configuration window in Forms and wait for it to migrate the users.
  3. Then change the authentication method for Forms to Directory Server.

 

That's it? No need to run the Account Migration Tool?

The reason I am asking is because in the PDF that comes with that utility it has a section labeled 'To migrate Forms participants to Active Directory users in Directory Server with participant licenses' and it states that after adding the AD users to LFDS and assigning them a participant license to run the migration tool.

0 0
replied on August 23

Hi Blake, 

I'll look into making the numbers steps clearer in the paper --- I can see why that's confusing. The step "Run the migration tool described in this paper" is really "Run the migration tool described in this paper if you also have full named repository users that you need to migrate to LFDS"

If you look at the intro before the steps, it says the following (emphasis mine):

If you have Forms participants who were registered as participants in Forms 10.3 or earlier, you may want to migrate them to become Directory Server users with participant licenses. This can be done separately within Forms and the Directory Server, without running the migration tool described in this paper. However, if you are planning to migrate participant users (from Forms 10.3 or earlier) to Directory Server as part of a general Laserfiche Server to Directory Server migration process, we recommend the following order of operations

 

Basically, you do not need to run the Account Migration tool if you are only migrating forms authenticated participants. But if you also need to migrate full named repository users from LFS to LFDS, the order matters, so we needed to make that clear.

Do you think adding info the steps you called out would be sufficient, or should I also have our writers take a look at the paragraph I quoted?

0 0
replied on August 23

Yes, I believe updating the wording in the steps as you mention above would help a lot. The clearer the better because most of the time these steps are being done on production systems and not test. One mistake and you are either restoring from a backup or trying to fix a big mistake.

As I mentioned in the comment below, it would be nice if the documents specified more clearly Participant Licenses or Forms Authenticated Participant Licenses.

1 0
replied on August 22

Also, is it a requirement when using Rio to have the Authenticated Participant Licenses in LFDS or is it still possible to setup Forms for repository authentication and have them assigned directly in Forms?

0 0
replied on August 23

To make sure we're using the same terminology:

  • Forms authenticated participants = users that can submit forms but not access the repository. They have been around for quite some time
  • Participants users = users that can submit forms and have read-only access to the repository, granted with a single license. These have come out in the past couple of years and are only very recently available for perpetual systems

 

If you have the forms-only type (Forms Authenticated Participants), LFDS allows you to allocate licenses to Forms just like you can allocate full named user licenses to a Laserfiche Server. In this scenario, you can use repository authentication rather than LFDS authentication.

However, we have an increasing number of features that depend on SSO, so I strongly discourage this when possible.

 

If you have the combined licenses that give you forms submission and repository read-only, then you must use LFDS authentication. These licenses cannot be allocated to LFS or Forms.

0 0
replied on August 23

I believe that is where a lot of confusion comes from when talking about the licenses. Whenever I see anything that says Participant licenses I automatically second guess it and wonder if it is talking about Forms Authenticated Participant licenses or the new Participant licenses. It would be nice if any documentation clarified which is being referred to. Maybe a something in parentheses saying (not Forms Authenticated Participant licenses) or something similar.

2 0
replied on August 27

Thanks for your specific feedback! I'll share this thread when I pass on your concerns.

0 0
replied on August 26

Another question for this process I could use some help on. I have a client that is upgrading from Avante to Rio. They do not have LFDS with Avante and are currently using Server Authentication and have Authenticated Participant users configured using LDAP.

What is the best approach when swapping their license and switching their LDAP Authenticated Participant users to LFDS?

I have LFDS ready and the Active Directory accounts created and assigned Authenticated Participant licenses in LFDS, but in what order do I create a new Forms license vs. Changing the Authentication for Forms to LFDS?

0 0
replied on August 27

Authentication via LFDS will not work if unless you have a license from that LFDS, so create and switch to the new Forms license from LFDS first.

Aside from that caveat, your steps above are sufficient if they only have LDAP users to migrate.

And just because I haven't said it in this thread yet: back up your databases! (Forms is most important here, since you don't have LFDS in full use yet).

0 0
replied on August 28

It seems like there is something missing with this process. Since the license assigned to the Forms Server is specifically being assigned the Authenticated Participant Licenses, at what point do we update the license to have that controlled by LFDS instead? And how do we do it so that currently running instances tasks are not terminated?

0 0
replied on August 28

Just wanted to say thank you Brianna for having a great conversation with me about this.

For everyone else, I am overcoming the issue I stated above by assigning extra Authenticated Participant licenses that the client has to the server so the current accounts don't become inactive. After we then switch Forms to LFDS authentication, I will reclaim the licenses so they are all in LFDS.

For those that do not have extra licenses, you can contact Laserfiche to receive a temporary license to basically do the same thing.

1 0
replied on September 12

We did just have an issue when running this tool where all of the Laserfiche Groups and Repository users were migrated to LFDS, but the Repository Users did not retain their groups and they all had to be reassigned.

0 0
replied on September 12

Hi Blake,

I think this is a matter of insufficient/unclear information and the utility is behaving as intended, so I want to explain the expected behavior in more detail.

When groups are migrated to LFDS, they are intended to replace the repository groups. As such, the new groups in LFDS should:

  1. Have the same membership as the repository groups, including child groups and LDAP or AD users. That is, if user A and group B belong to group X in the repo, there will be a user A, group B, and group X LFDS, and user A will instead belong to that group C
  2. The newly created LFDS groups will be marked as trusted for login for the repository they came from
  3. The rights, privileges, etc. assigned to the repository groups using the repository group SID will be replaced with the SID for the new LFDS group, so that all rights etc. are transferred over to the LFDS group
    1. The exception is any attribute set on the Everyone group such as Settings lockdown that involved an admin manually specifying a GUID
  4. The utility has a step to handle conflicts, so if you have the group "Admins" in repo 1 and "Admins" in repo 2, you can either merge the two or rename the later group(s) when the conflict is found.

 

The migration utility steps say

All repository group memberships will be retained. Repository groups will become new Directory Server groups. Windows and LDAP users in repository groups will appear as members of the migrated groups in Directory Server, as long as their identity providers were pre-registered in Directory Server.

And I can see how that's confusing. The users will not be members of the existing repository groups---instead their group membership/structure will be replicated in LFDS and remapped within each repository to avoid losing security settings for groups.

Does this match what you saw? If so, is there a reason why this approach is a problem, or did it just need to be clearer?

0 0
replied two days ago Show version history

Update: it appears that in some cases, repository group membership is not preserved, though both the groups and users are otherwise successfully migrated.

The current workaround is to re-create the group memberships within LFDS, so it may be helpful to export trustee information prior to migrating or reference the backup database.

We will be investigating further and will share the resolution.

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

Sign in to reply to this post.