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?

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.

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.

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).

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?

@████████

I was wondering if you had an update to the issue you mentioned above about in some cases repository group membership is not preserved?

The issue I referred to turned out to be different than what you experienced, and was resolved by a customer-specific patch.

I'm sorry for the long delay here; we will return to investigating this issue.

The area we will be investigating is windows users and groups that belong to repository groups sometimes not being added to the replacement groups in LFDS.

A workaround:

1. Prior to running the utility, export your repository groups as XML

2. Modify the XML to change the group name so it's not identical to the Laserfiche group 

2. After running the utility, if your windows users and windows groups were not properly added to the new LFDS groups, re-import the repository groups:

This isn't ideal, since now you still have repo groups, but you can then add the LFDS groups to the repo groups and continue to use the repo groups in the future.

Alternatively, you could also use the exported list to either script adding the AD trustees to the LFDS groups using the LFDS SDK, or for smaller systems as a reference for manually fixing the membership through the LFDS admin console.

Since we don't see this issue all the time, it is hard to troubleshoot. If you do run across this again, please let us know so we can gather more information.