• State Suggested Answer
  • Locked Locked
  • Replies 11 replies
  • Answers 2 answers
  • Subscribers 62 subscribers
  • Views 8567 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

ARS Upgrade from 6.9 to 7.2

BojanNS
over 6 years ago

Hi, I was given a task to upgrade ARS 6.9 to 7.2 - newest version will be on the different server. I need a detailed step-by-step guide since this is on the production environment.

  • 0 over 6 years ago
    In-parallel upgrade side-by-side is strongly recommended for reasons:
    (a) RollBack: legacy ARS69 stays untouched and "insuarance" for RollBack if needed
    (b) Testing: allows time/room to "breath" to test in Production new ARS72, with no impact on HelpDesk and ADAdmin and no heavy cut-over date
    (c) (a-b) is very strong points to support the point: ARS is Enterprise Front-End Compliance sensitive Application and to be treated this way.

    AR Quick Start Guide covers some topics from Install/Devs standpoint, not from Solution/Consultant.

    If needed, customer may reach OneIdentity, Quest PSO to design and execute AR Upgrade in Production solid, smooth and with risks leverage.

    similar question was raised here on the forum
    www.quest.com/.../
  • 0 over 6 years ago

    And what about tasks done automatically/manually from helpdesk staff perspective on current ARS 6.9 during parallel existence of both ARSs - these will be stored in DB of current ARS but not in DB of new one containing configuration/history at the moment of import?

  • 0 over 6 years ago
    Indeed - and pls also keep in mind that when Deprovisioned accounts are present during the upgrade to the newer version, and an "Undo Deprov" is done in 1 environment, the accounts might still get purged/deleted by the other environment. We've run into that scenario when running 2 envs in parallel (can easily be mitigated by suspending the scheduled task that locates & deletes the deprovisioned users).

    This of course only applies if you use the "Delete after X days" policy as part of your deprovisioning process.
  • 0 over 6 years ago
    This is a planning issue.

    Hopefully, you have a separate Management History database. It is here where all user activity is stored. As part of the setup of your new version of AR, you will create a new database and copy over the contents of the old database to it.

    Then, once you are ready to cutover all of your users to your new AR version (and its new databases), you will have to ask for an "outage window" to give yourself an opportunity to copy over any records of user activity that occurred between the time you initially setup your new Management History database and the cutover time.

    'Hope that makes sense to you.
  • 0 over 6 years ago

    So everything that does not have anything with ARS configuration itself i.e. automatic task or task run by helpdesk staff is stored in Management History DB meaning I can import ARS 6.9 Configuration DB right after installing new ARS 7.2 Administration Service instance and then during planned outage import Management History DB too - that would be the moment when helpdesk has to start using new ARS 7.2? I hate this situation where there is no step-by-step guide from scratch and you deal with production environment ... Each product has its own logic and guides for these scenarios have to be at client's disposal.

  • 0 over 6 years ago
    As noted by Aidar above, most customers choose to hire some type of Professional Services (whether from OneIdentity or a qualified Partner) to do the upgrade work. The market reality is that many AR environments have not been touched for years and could use some review (and often, staff Knowledge Transfer) anyway to make sure that the customer is really getting the most from this excellent tool.
  • 0 over 6 years ago

    According to all said above there will always be inconsistency between two Management History DBs with common configuration in place. ARS 6.9 will not be aware of testing tasks done on ARS 7.3 and vice versa. Only merging of these DBs would allow both instances to be aware of all tasks. I assume ARS 6.9 and ARS 7.2 can not share same Configuration and Management History databases - concept of shared databases is mentioned in QuickStart Guide.

  • 0 over 6 years ago

    Correct.  However, IMO you only want to merger FROM 6.9 TO 7.2.  

  • 0 over 6 years ago
    If so I do not know how to preserve all tasks run on current/new instance. If I decide to move to ARS 7.2 import Management History DB from ARS 6.9 would override all testing tasks run on ARS 7.2 prior to importing ...