• State Suggested Answer
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 2 replies
  • Answers 1 answer
  • Subscribers 63 subscribers
  • Views 3959 views
  • Users 0 members are here
Options
Related
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Update to ARS 7.2.1 questions

nicole
over 6 years ago

We are currently running 7.0.4 on 2012 R2 with a sql 2012 DB.  We are planning to update to 7.2.1 and would prefer to setup a new environment using 2016 OS and 2016 SQL and migrate the configuration to that new environment.  I was wondering what issues having 2 separate ARS environments side by side managing the same domains may cause?  In particular, with dynamic groups.  Will both environments battle to keep the DG's up to date?  We had something similar in the past when we went from 6.9 to 7.0 and had issues with the DGs and was hoping to avoid that.  

Also, as long as we bring over the change management DB, will that keep our deprovision history for accounts and temporal group memberships? 

We expect the side by side environments would be running together for a bit of time while we test everything out in the new environment.  I plan to not let any changes occur in the new environment, other than test transactions, until we cut over and pull the Change DB over again at the time of cut over to keep all the history.

 

any advice would be appreciated.

Nicole

Parents
  • 0 over 6 years ago

    If the AR server affinity of the dynamic groups (i.e. the attribute that indicates which AR service regenerates them) comes over as-is (which I believe it will) there will be no contention for the dynamic groups. What will happen is that they will fail to get updated by the new services because they won't see the groups as being owned by them.  Ultimately, you will need to re-assign the affinity of the groups to the new servers (at which point contention could occur if the old services are still running).

    You could have problem with anything else configured in your AR services that is reacting to changes in the directory (for example, workflows triggered on some update, script policies). You will want to comb through your configuration carefully to look for these potential points of contention.

    Preservation of the Change History DB will retain everything that it normally tracks. You are correct that you will want to time this carefully - i.e. an outage window to do a final cutover.

Reply
  • 0 over 6 years ago

    If the AR server affinity of the dynamic groups (i.e. the attribute that indicates which AR service regenerates them) comes over as-is (which I believe it will) there will be no contention for the dynamic groups. What will happen is that they will fail to get updated by the new services because they won't see the groups as being owned by them.  Ultimately, you will need to re-assign the affinity of the groups to the new servers (at which point contention could occur if the old services are still running).

    You could have problem with anything else configured in your AR services that is reacting to changes in the directory (for example, workflows triggered on some update, script policies). You will want to comb through your configuration carefully to look for these potential points of contention.

    Preservation of the Change History DB will retain everything that it normally tracks. You are correct that you will want to time this carefully - i.e. an outage window to do a final cutover.

Children
No Data