Big Picture User Experience
OADC should not modify the existence, contents or link order of any custom GPO policy
Detailed Description
As a SCADA administrator/installer, I need OADC to not modify any existing GPOs that I have put into place after the last time OADC was run, so that I can modify/customise the domain to my needs, and then upgrade the product at a later date without having to check and re-do any of those customisations.
However, there are times when I know better, and I will need to be able to force the tool to overwrite anything it finds that would otherwise cause it to abort.
In this case, "modify" means, in a given OU:
no deletion of custom GPOs
no unlinking of custom GPOs
no change to the relative link order of custom GPOs
Acceptance Criteria
After a vanilla install of the Enterprise SCADA, apply some GPO customisations, such as new policies, unlinking of product GPOs, linking to/from non-product OUs.
Then, run the OADC tool again, and witness that it has not changed any of the custom GPOs that were added/changed/re-linked.
The OADC tool instead report that which it wasn't able to complete so that the administrator can then determine the course of action. The tool will attempt to perform its baseline installation tasks, unless doing so would modify (see above definition) a custom GPO.
Greenfield: For outside the product OU, product GPOs should be linked below any existing custom GPOs, i.e. in lowest precedence link-order. Inside the product OU, install as per normal.
Brownfield: For inside and outside the product OU
custom GPOs should remain in the same link order,
any updated product GPOs should be installed in the link-order that the previous version was found (link the new one in the same link order as you found the old one)
any new product GPOS should be kept in the same relative order to other product GPOs, but if there is a custom GPOs in the same location then place the new GPO below the custom(s)
Business Value
The customer base is starting to apply their own security policies, and are wanting to be more in charge with the final design of their domain.
In-place upgrades of the product and the operating system are vital for the future of the product, if we hope to get customers to upgrade every year. Since customer regularly customize AD after the install, this initiative is essential to MidStream.
Customer OT groups are increasingly under pressure from the IT groups to adopt industry standard AD designs and processes, and are increasingly not in control of the OT AD infrastructure.
Live upgrade is essential. Customers will be operating live assets with systems that are operating within the domain being modified.
We must not introduce any instability into the domain while we are performing installs, upgrades or downgrades/rollbacks.
Third party software running in the same domain is out of scope insofar as we are not supporting said software or its deployment from within R&D. However, our integrators and support groups may be responsible to provide support, even if it is only best efforts. Therefore, our software must be designed with this in mind, and should not disrupt this software if at all possible, or its disruption should be known and documented to allow customers to plan ahead.
Target Version
Target version for this feature: ES2023
Version the customer is on or consuming: ES2021+
Version being targeted by project or future opportunity:
Customer, Project, and Deadline Details
Customers (names/projects) that will consume this: ENB project team was able to recover from the ES2022 install experience which modified the custom GPOs only lightly. Their expectation is that this is improved in ES2023
Deadlines and Commitments: ES2023
Commercial and/or Contractual Impacts: MVP - documentation available that describes what the tool will do to existing GPOs.
Customers System / Architecture
Size: Small, Med, Large
Topology: Single site, Multi Site, and Enterprise
Any Unique configuration to note?: Custom GPOs applied
Has this functionality been delivered before?: Project and customer regularly adjust the GPO/OU layout in AD after the OADC tool has run.
Out of Scope
Assumptions
Dependencies
This needs to be considered in the larger context of the enhancement being made to OADC.
Related: AIT may be doing things already to extract and preserve customer customisations during upgrade, so that it can restore them after the OADC tool runs
There are other features that extend this concept to make the OADC configurable as to which policies it is going to apply.
Operating System upgrade may introduce new GPOs/settings.
Upgradability
This feature is entirely focused on the upgrade experience for existing OASyS customers, and for customers whose domain is already hardened by others.
PSR - Performance, Scalability, Resilience
Important PSR aspects for this feature? Not introducing instability in AD, nor undoing security settings on a PROD domain that weakens the security, however brief. Not required to shut down any Domain Controllers.
What if there are 10,000 of these? n/a
How quickly is this expected to react/respond? n/a
Does this impact failover / mode switch? no
Is this assumed to have performance impact, or not? no
NFR - Non-Functional Requirements
Documentation: OADC reference doc, as opposed to just task-based doc for the installer persona
Operating System: Windows 2019 and 2022
Operating System upgrade may introduce new GPOs/settings.
Other AVEVA products: Yes
3rd Party products:
CPU / Memory / Disk requirements/constraints: .
Risks/Mitigations
none identified
Mock-up / Supporting Information
No
Architecture Review Required?
No
Do we need a SPIKE?
No
Links
Aha: OASYS-471
Jira: .
T-Shirt Estimate: https://dev.azure.com/AVEVA-VSTS/OASyS/_workitems/edit/1767472.
Implementation: .
