Issue with ARS 7.4.3 upgrade from 7.3.1 after breaking replication and converting Pub to standalone. Config Manager loaded and returned instance related error

We upgraded the binaries for ARS 7.3.1 to 7.4.3 on our publisher host after breaking replication and demoting the pub.

On Launch of configuration manager - seeing the new DB names to be created, and clicking NEXT we get an error about an object not being set to a reference … or some such.

Not in the troubleshooting guide - and applying the appropriate hot fixes for 7.4.3 changed nothing.

opinions?

Parents
  • Maybe a known issue/solution … but I'm not sure how to go about renaming a built-in access template ...

    Active Roles supports selection of custom installation path only during a fresh installation. During an in-place upgrade, Active Roles does not support changing the custom installation path. 763071

    When Active Roles is uninstalled some Registry keys do not get removed.

    WORKAROUND

    Delete the old Registry keys before installing the latest Active Roles version.

    775437

    Active Roles version 7.3 upgrade fails if the Starling Access template container is already present before the upgrade.

    WORKAROUND

    • If an in-place upgrade or Import to Active Roles version 7.3 is not performed, rename the Starling Access template container before performing an in-place upgrade or Import from the previous Active Roles version.

    • If an in-place upgrade or import to Active Roles version 7.3 is performed, then perform the following:

      1. Restore the configuration and history databases of the previous version of Active Roles that was installed on the system before the upgrade.

      2. Uninstall Active Roles version 7.3 and remove related Registry keys.

      3. Install the previous version of Active Roles including the patches.

      4. Configure the previous version to use the restored databases.

      5. Rename the Starling Access template container.

      6. Restart the upgrade process.

Reply
  • Maybe a known issue/solution … but I'm not sure how to go about renaming a built-in access template ...

    Active Roles supports selection of custom installation path only during a fresh installation. During an in-place upgrade, Active Roles does not support changing the custom installation path. 763071

    When Active Roles is uninstalled some Registry keys do not get removed.

    WORKAROUND

    Delete the old Registry keys before installing the latest Active Roles version.

    775437

    Active Roles version 7.3 upgrade fails if the Starling Access template container is already present before the upgrade.

    WORKAROUND

    • If an in-place upgrade or Import to Active Roles version 7.3 is not performed, rename the Starling Access template container before performing an in-place upgrade or Import from the previous Active Roles version.

    • If an in-place upgrade or import to Active Roles version 7.3 is performed, then perform the following:

      1. Restore the configuration and history databases of the previous version of Active Roles that was installed on the system before the upgrade.

      2. Uninstall Active Roles version 7.3 and remove related Registry keys.

      3. Install the previous version of Active Roles including the patches.

      4. Configure the previous version to use the restored databases.

      5. Rename the Starling Access template container.

      6. Restart the upgrade process.

Children
  • The bold option should have been the template rename ... not possible via GUI, but given the static nature of the template, it was easy to use rename-qadobject to update the name, and CN values.  after service restart - I see the renamed template in the console, but the in place upgrade still fails with that generic 'object reference not set to an instance of an object' - and in the log - that line appears still to point to 'something Starling'  - just not the Startling access template container mentioned in the KB.

    ... back to the drawing board,  working directly with OI support.