...
- The extent of the problem the change was meant to address.
- The measure by which the expected change to the systems occurred.
The operational difference between Opt-in and Opt-out
Opting-in requires TSPs to deliberately decide which computers will be acted on using central management tools, if utilized at all to meet operational needs.
Opting-out, with no TSP intervention, uses central management tools to act on every computer.
Examples we've seen so far when opt-in was not sliced-and-diced, and the problems that has caused us
Example: Automatic patching of the OS.
Then Spririon (Identity Finder) added AND had behaviors. Scanning every time a USB device put in. Running scans. These were not appropriate for lecture computers, such as in Physics.
Removing the computer from central patching was extremely non-trivial. Not simply "now opt-out".
Example: Automatic patching of the OS.
Patching for MS OS and MS applications. Also force updates for non-MS, 3rd party applications. Not desirable since we have a superior solution.
The preference for opting-in or opting-out is also driven by convenience and risk management. The more "different" the machines one has, the more critical it is we retain an opt-in infrastructure.
If instead we do opt-out, in research especially we will need to:
Put a computer into every opt-out option group there is.
| Category or concern | If opt-in to using specific central management solutions: | If requiring opting-out computers from specific central management solutions: | Real-world examples | Notes |
|---|---|---|---|---|
| Conflating the capacity to see our systems using central management tools with the obligation to use that same system to by default affect change to those same systems. | This has been the standard of practice, period. Not making changes by default makes it much safer and clearer that the client can afford to be installed. Priority has been to gain visibility of our systems and their configuration. To wit, the university is expending even more efforts to make that visibility more precises and visible within one tool (Remedy Asset Manager). | Requires a high degree of trust in the tools and processes for change. Forced changes are usually not appropriate for some research and classroom systems. | ||
| TSP's role and responsiblity | Deliberately designate systems to be changed. Opportunity and obligation to phase in the use of specific solutions as appropriate to environment. This includes selecting systems, method of verification, over what time-frames. Different solutions will each likely require different verification methodologies, different systems to use first, and timing. | Managers and ITSG can see the degree to which any central management solution is used. And can compare that tool's use with reports on the current state of the computers, bringing attention to bear on non-compliant systems. | ||
| Governance and risk | Level of process or testing is proportional to the needs expressed by the TSPs who want to pursuing using a specific solution to solve their challenges. | Deployments have historically been by by decree, with little-to-no process. And very uneven testing. To little consequence of failure for central A&S IT, and high consequence for department IT. Often solutions are sometimes inexplicably linked so opting in or opting out becomes an all-or-nothing proposition. This decreases the potential for TSPs to adopt specific solutions to solve their challenges. | ||
| Technical structure of groups required. | Specific central management solutions are made available by adding computers to specific groups. | All computers by default get specific central management solutions, . Any computer can be opted-out by adding computers to specific groups. | ||
Oliver's request to A&S IT
...
By giving primacy for clients to report inventory information, and not also by default forcing any changes to a computer, we increase the number of computers which can be characterized using central reporting tools. This importantly increases the number of systems visible within the centrally-provided inventory tool, Remedy Asset Management, all without needing new processes or tools.
Departmental Technical Support Providers (TSP) should direct their efforts to understanding the changes needed by the systems in their area, and opt-in them into using central management solutions is as they see fit.This can happen if management solutions continue to be provided in a slice-and-diced manner. If centrally provided management services are NOT opt-in, all TSPs will instead have to make efforts to understand when forced solutions are not appropriate for their systems
need to understand exactly what will or will not happen to their systems, now and in the future. This will be true even for proposed solution which an area may not have a demonstrated need or desire for. TSPs should not have to be made to make an effort to "defend" ourselves from default actions taken centrally. Instead, every TSP should be responsible to vet any proposed policy they elect to apply to their systems, and subsequently and deliberately put those systems into groups to affect those changes.
...