...
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.
...
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
...