Q:Rick noted, "The marketing fluff for SVS says that after I deploy an application, no reboot is required. But I've run into a couple cases where I push a VSP with Notification Server, and it doesn't work right until the client is rebooted. What's going on?"
A: After Beta 3, we did a detailed vulnerability analysis of SVS (both ourselves and we also contracted with an external security expert). Eight issues were identified, all of which have been resolved. One of the issues was that when an activation is done via a management agent, that management agent is typically running in the SYSTEM context. So any of the startup stuff that SVS does on activation (run and runonce keys, Startup folder items, etc.) ended up running as SYSTEM. Normally, during a Windows boot, these items get run in a variety of contexts depending on where they are and how they are set up. To eliminate the risk of inadvertently leaving the end user with some running processes with elevated privileges, we decided to add a security check to the activation logic. Now, if the activation is not being done by the interactive user, SVS doesn't execute startup items. If the activation is being done by the interactive user, we go ahead and run them, but they still may not all work as designed since some items may actually need to run in a higher-privileged context.
In Lightning, we will handle this differently, and the experience on activation will indeed be exactly the same as it would be on a regular Windows boot (which is the design goal). Startup items will be executed by a new SVS service that we have already built a prototype for. The service executes startup items in the correct user context, exactly the same as Windows would in a boot.