<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p>Andy,</p>
    <p>returning to your situation: I have replicated it in my TIER
      setup and got the same behavior as you did.</p>
    <p>I suggest the following:</p>
    <ol>
      <li>If you just want to create shadows without linking them to
        their respective owners (users), then dryRun import task is the
        way to go. It will evaluate situation of each shadow (unmatched,
        unlinked, linked) and update its status. However, it will not
        apply the synchronization reaction(s), so e.g. even if you
        define "link" action for unlinked shadows, the dry import will
        not execute it. The shadow will not be linked with their
        potential owner.<br>
      </li>
      <li>If you want to create shadows and to link them (and not lose
        auxiliary object class information), then use Brad suggestion.
        It works in my case (with roles inducing auxiliary OCs) and I
        think it will also in yours.</li>
    </ol>
    <p>I have tried e.g. setting
      <synchronize>false</synchronize> on the unlinked
      reaction, i.e.</p>
    <p>                <reaction><br>
                          <situation>unlinked</situation><br>
                          <synchronize>false</synchronize><br>
                          <action><br>
                             
<handlerUri><a class="moz-txt-link-freetext" href="http://midpoint.evolveum.com/xml/ns/public/model/action-3#link">http://midpoint.evolveum.com/xml/ns/public/model/action-3#link</a></handlerUri><br>
                          </action><br>
                      </reaction><br>
    </p>
    <p>but it does not work: synchronize=false causes the link action to
      be skipped as well.</p>
    <p>Maybe we could implement a reaction like "link but do not
      synchronize" but I am not sure how complex would that be. <br>
    </p>
    <p>Thinking about assignment policy enforcement, it should not make
      a difference here. It deals with the mere existence of projections
      (accounts), not with their synchronization.</p>
    <p>Best regards,<br>
    </p>
    <pre class="moz-signature" cols="72">Pavol Mederly
Software developer
evolveum.com
</pre>
    <div class="moz-cite-prefix">On 28.08.2018 8:44, Pavol Mederly
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:4e4a5d89-07da-3282-5f45-1e91a166c1ad@evolveum.com">
      <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
      <p>...though, I think you need those accounts to be linked to the
        users. Dry run will probably not do that. <br>
      </p>
      <pre class="moz-signature" cols="72">Pavol Mederly
Software developer
evolveum.com
</pre>
      <div class="moz-cite-prefix">On 28.08.2018 8:33, Pavol Mederly
        wrote:<br>
      </div>
      <blockquote type="cite"
        cite="mid:7ec69838-1e55-74c6-a27c-24d354f34ceb@evolveum.com">
        <meta http-equiv="Content-Type" content="text/html;
          charset=utf-8">
        <p>Andy,</p>
        <p>just a quick shot as I have to go away just now:</p>
        <p> </p>
        <blockquote type="cite">SECOND METHOD TRIED: <br>
          <br>
          Instead of importing accounts, I tried assigning the roles to
          the midPoint users to induce the correct resources,
          objectclasses, and roles.  That actually worked great, but I
          don't know how to get 80,000 shadows into midPoint's
          repository without importing.  I can get 20 shadows created at
          a time by browsing the Accounts in the LDAP resource, but I
          don't know how to get all of them.  If midPoint doesn't have a
          shadow when I assign the roles, it tries (and fails) to create
          a new account.  Then, it makes a bunch of modifications to the
          existing account because it thinks it has changes to process. 
          No good. <br>
        </blockquote>
        A quick method of account creation is to run import from that
        resource with <b>dryRun</b> option set. It should do nothing
        except for creating the shadows. :)
        <pre class="moz-signature" cols="72">Pavol Mederly
Software developer
evolveum.com
 </pre>
        <div class="moz-cite-prefix">On 25.08.2018 2:42, Andrew Morgan
          wrote:<br>
        </div>
        <blockquote type="cite"
          cite="mid:alpine.DEB.2.11.1808241707020.839@shell.onid.oregonstate.edu">I'm
          looking for advice on standing up midPoint with resources that
          already have accounts present.  I have 1 resource with inbound
          mappings (a database table) and 2 resources with outbound
          mappings (AD and LDAP). There are approximately 80,000
          accounts in AD and LDAP. <br>
          <br>
          <br>
          FIRST METHOD TRIED: <br>
          <br>
          I attempted to import accounts from LDAP in order to link to
          existing midPoint users and then assign the appropriate roles
          to match the existing state of the LDAP account. <br>
          <br>
          When I import an LDAP account, it is linked to the correct
          midPoint user. However, midPoint strips off the extra
          objectclasses and attributes that are defined in my roles (not
          in the LDAP resource).  I have tried setting the
          assignmentPolicyEnforcement to "positive" or "none", but it
          still happens.  No good. <br>
          <br>
          <br>
          SECOND METHOD TRIED: <br>
          <br>
          Instead of importing accounts, I tried assigning the roles to
          the midPoint users to induce the correct resources,
          objectclasses, and roles.  That actually worked great, but I
          don't know how to get 80,000 shadows into midPoint's
          repository without importing.  I can get 20 shadows created at
          a time by browsing the Accounts in the LDAP resource, but I
          don't know how to get all of them.  If midPoint doesn't have a
          shadow when I assign the roles, it tries (and fails) to create
          a new account.  Then, it makes a bunch of modifications to the
          existing account because it thinks it has changes to process. 
          No good. <br>
          <br>
          <br>
          NEXT???: <br>
          <br>
          Maybe I can define the LDAP resource with no outbound
          mappings, import all the accounts in order to link them to
          users, assign the correct roles, and then update the LDAP
          resource to have the outbound mappings... <br>
          <br>
          <br>
          Is there a wiki page that covers this?  I'm running out of
          ideas...  Help! <br>
          <br>
          Thanks, <br>
          <br>
          Andy Morgan <br>
          Systems Administrator, Identity & Access Management <br>
          Information Services | Oregon State University <br>
          541-737-8877 | is.oregonstate.edu <br>
          _______________________________________________ <br>
          midPoint mailing list <br>
          <a class="moz-txt-link-abbreviated"
            href="mailto:midPoint@lists.evolveum.com"
            moz-do-not-send="true">midPoint@lists.evolveum.com</a> <br>
          <a class="moz-txt-link-freetext"
            href="http://lists.evolveum.com/mailman/listinfo/midpoint"
            moz-do-not-send="true">http://lists.evolveum.com/mailman/listinfo/midpoint</a>
          <br>
        </blockquote>
        <br>
      </blockquote>
      <br>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
midPoint mailing list
<a class="moz-txt-link-abbreviated" href="mailto:midPoint@lists.evolveum.com">midPoint@lists.evolveum.com</a>
<a class="moz-txt-link-freetext" href="http://lists.evolveum.com/mailman/listinfo/midpoint">http://lists.evolveum.com/mailman/listinfo/midpoint</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>