Prev
Next
Forums Infor / Lawson Platforms Lawson Landmark

Updating actors and identities after federating

 2 Replies
 0 Subscribed to this topic
 32 Subscribed to this forum
Sort:
Author
Messages
Gary Padgett
Veteran Member
Posts: 90
Veteran Member
8/26/2013 4:34 PM

    Have a quick question re federating (coupling in my case) Landmark and LSF.  I have already done this in my CERT environment and we’re doing OK there.

    But I am  building a new Landmark environment on a new machine for our DEV environment, and will soon be doing this in production.  My question has to do with supplying the actors file and the services and identities file.  In CERT, I supplied these files so that they would get picked up in the initial install of Landmark.

     

    But I ran into issues with federation, and by the time I got all of it straightened out, my actors and identities files were over a month old.  In our CERT system, this is not such a big deal, because we aren’t adding and deleting new employees like we do in production.  But I wanted to try to build out my Landmark system as much as possible prior to the upgrade weekend, and this would mean refreshing my actors and services/identities files.  Have you run into this issue, and how did you handle it?
    I was thinking in terms of comparing the initial and subsequent actors file, and deleting any users who were on the first file but not on the second.  Does this sound like the right way to go?

    Gary Padgett
    Veteran Member
    Posts: 90
    Veteran Member
    8/28/2013 6:58 PM
      I have a couple of scenarios in mind for our production go-live weekend.  Does one sound especially good or especially bad?
      1 - When building my prod Landmark box, load a few users and their identities (probably my IT team and some superusers).  Then on the upgrade weekend, dump a new, complete actors file and a new, complete identities file, then federate.  That way, I should not have to worry about people who have terminated.
      2 - Dump the whole file ahead of time while building out my Landmark system, then dump it again during go-live weekend.  This will pick up any new hires since the first file, but we would have to delete any terminated employees manually during go-live process.
      3 - we currently have an automated add of new hires and automated delete of terms via a third-party tool called Courion which also sets up AD and email accounts.  This process will have to be modified to add and delete actors in landmark as well.  If it's working ahead of go-live, I can dump a full file of actors and then let Courion handle any adds and deletes that come along.

      Thanks for weighing in.
      Alex Tsekhansky
      Veteran Member
      Posts: 92
      Veteran Member
      8/31/2013 5:42 PM
        You did not indicate whether your LSF and /or Landmark is BINDed to some external LDAP, and that may affect your decision. I will assume at the moment that both LSF and Landmark are BINDed to the same LDAP (most common scenario).
        It's unlikely that service definitions would change between not a go-live, right? If they will, you will need to load modified LSF services first.
        Then you may want to create a script that dumps all identities out of LSF's primary LDAP server (or even use SSOCONFIG for that purpose). You will then need to create a second script that will generate secadm commands for actor/identity load. That somewhat matches method #2 in your post)
        Finally, you can dump a list of existing actors/identities out of Landmark (database query, I believe you can also get it from Rich Client), and match it against the identity list you got from LSF (via a script). That will give you a list of actors/identities that should be deleted. So, you can generate a set of SECADM commands to handle that.

        This method will allow you to proceed with full Landmark install and configuration early, and simply synchronize actors/identities via additions/deletions/changes during go-live. In my view that's much safer than re-migration, and probably is faster than the way #3 you described.