Our group is at a bit of a stalemate when it comes to adding OS level Zstops to all CSDB services.

We currently support over 800 applications and when a new OS comes out we can spend months testing all our applications on the new OS platform.  Unfortunately, and as an example; if the service currently has a WIN7 zstop on it we can’t quickly test the applications on WIN10. It’s a long process carefully adjusting Zstops on every application so they can even be tested. (We have to do this by exporting the .xpi files and opening them in notepad, changing the Zstop, and reimporting back into the system.) That way it doesn’t modify the date and time stamp of the service and force a reinstall of the software throughout the environment.  As another example, if the application ends up working on WIN10 we would typically add the new OS Zstop to the service and will be faced with the same problem later when WIN12 comes out. 

That means that our only other solution is to NOT add an OS Zstop at all unless the software just won’t work on a particular OS.  We’ve gone through many discussions on the pros and cons of adding the OS level Zstop to all software. The biggest pro of adding the OS Zstops is to prevent major catastrophes like blue screening every machine that has a particular software on a new OS. The major con of the OS Zstop is that it can take months of testing on the new OS. With hundreds of supported applications, it becomes a huge undertaking.   

I’m curious what other companies are doing and if they face the same pain points that we go through when a new OS enters the picture? Maybe there is some solution we aren’t even considering?