Migrating deprovision information in ActiveRoles Server

When you upgrade your ActiveRoles platform, rather than upgrade in place, you may choose to deploy the new version to new servers and switch your users over. At the same time, you may also choose to create a new set of Databases rather than re-use the old ones, perhaps due to stability or consistency, there are many reasons why you would do this. If you find yourself in this situation, you will need to migrate your deprovisioned user data from the old database to the new database in order to be able to undo the deprovision process on a user deprovisioned on the old version you were running. In my opinion, Change History data is not so important to keep because every change operation made is logged to the EDM Event Log which you should be archiving into an Event Log solution of some sort. If you are not doing this then you should be using the ARS Data Collector to collate your Management History data into an Archive Database, but that’s an article for another day. In this post, I will share how I enabled a user account that was deprovisioned in ARS 6.1 to be reanimated through ARS 6.5 which used a new set of databases. We ran this process as we decommissioned 6.1 to ensure we captured all users who had been deprovisioned in 6.1. Thank you to Roman Kalyapichev, Solutions Architect at Quest Software for putting us on the right path with the Database side. The process detailed here assumes you use a Shared Database for your ARS installation. If not, pick a server to work with and probably allow SQL replication time also. As always, please run this in a test lab first and ensure you have a valid backup of the databases you are working with!

  1. Our first step once the new 6.5 service was in and running was to make sure the Management History database contained only relevant information related to deprovisioning users. To enable this go to Configuration > Server Configuration > Change Tracking Log. Set the number of days of information to record to 1. This will ensure that all Management History older than a day is purged from the database, however, deprovisioning data is kept indefinately and exempt from this cleanup process. So the end result is you will have a database with deprovision data from the day you implemented plus only Management History data from the last 1 day, which if you are performing this on a Sunday should be very little.
  2. Navigate to Configuration > Server Configuration > Scheduled Tasks > Builtin and open the properties for Change Tracking Cleanup. Select the server name you are working on as the server to run it from and set the time to run in the next minute or so and apply the changes.
  3. Keep an eye on the EDM event log for the Scheduled Task starting and finishing, it may take some time depending on the amount of data. Once complete, you will have a nice, clean database to import from.
  4. From the new ActiveRoles Server you are moving to (in my case 6.5) run the Management History Migration Wizard, connect to your source and destination databases and import the data. Again this may take some time, save the log file at the end for examination later should you need it.
  5. You’re now in a position where you have all deprovision data from your old service in your new service.  Select a user to test with that you know was deprovisioned on your old version (in my case 6.1)  and view the change history.  Notice the data for Deprovisioning is included, however, notice you will not see the option to Undo Deprovision? We will address this now.
  6. From the old service where the user accounts were originally deprovisioned, run a search for users in the ActiveRoles console where the attribute edsvaDeprovisionStatus is set to “1“. Display the User Logon Name in your column results and save the file.
  7. Make sure this file is saved as a CSV and has a single column titled ”User’. All usernames should be prefixed with your domain name in the format of <Domain>\<UserName> so for example MyDomain\Matt.Hitchcock. You may need to do some Excel wizadry or seach and replace in Notepad to achieve this and watch out for accounts with a space value in the name, you’ll have to deal with these separately.
  8. Once you have the file saved you are ready to set the attribute in your new ARS Service. Be sure to test this on a single user first (preferably the same one as you just viewed). Launch the ActiveRoles Management Shell and type Connect-QADService -Proxy to connect to ARS.
  9. Select a user account to test with and ensure the CSV is populated with that single user account first.  The following code may not be the most efficient or elegant way to do it but it works: Import-CSV ‘c:\<csvfilename>’ | Foreach-Object {Get-QADUser $_.’User’ | Set-QADUser -ObjectAttributes @{edsvaDeprovisionStatus=1} }
  10. Search for your test user in the ActiveRoles MMC, right click the Object and ensure that Deprovision Results and Undo Deprovision are now available options on the context menu.  You can actually run the Undo Deprovision process if you’d like to prove it works.
  11. The last step is to add all the user accounts where this needs to be set to the CSV and run it.  I usually run Start-Transcript before the command and Stop-Transcript at the end as it gives me a record of the session that I can refer to for errors and so forth.

Simples 😀

Advertisements


Categories: ActiveRoles, Uncategorized

4 replies

  1. So how long did the Management History Migration Wizard take, and how much history did you migrate?

    • This is what they don’t tell you. 16 million records (all change history) was looking to take a whole week, its a slow process. After purging everything else out and just taking deprovision information, i don’t remember exactly how many records were left but it took the best part of 15 hours. We have a huge environment though.

Trackbacks

  1. ActiveRoles Migration: Deprovisioning/Undoing Deprovisions, or, The Article I Wish I’d Read Before We Started Our Migration « Ars de ARS
  2. Post-Migration Deprovision and UnDeprovision Inconsistencies – Solved! | Ars de ARS

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: