• State Suggested Answer
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 2 replies
  • Answers 1 answer
  • Subscribers 63 subscribers
  • Views 3958 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

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

  • +1 over 6 years ago
    you are correct.
    #1. In-parallel upgrade is recommended for (a) to have legacy ARS untouched for roll back, (b) move to a new Windows Server OS version, SQL version.
    #2. DG groups is overlap area between legacy and new ARS. The membership rules based on *AD attribute* will be the same visible top both legacy and new ARS. the one comes last will though ARS Event Log Error: cannot ad user into the DG group because the user is already a member of the group. If DG rules is based on ARS VA - it is a very dangerous (!!!) situation and to be talked (designed) separately.
    #3. In general it is not recommended to have tow independent ARS Workflows hitting the same AD. During upgrade (a) HelpDesk keeps using legacy ARS01 while testing "hidden from HelpDesk"" new ARS02 - it provide time to do appropriate testing. Then (b) you switch to new AR02 and shutdown legacy ARS01. (c) rollback is needed.
    #4. VA is a very tricky part and to be considered for "smooth" upgrade with roll back.