After using NS to push a virtualized app to a client machine, I sometimes have to reboot the client. How could this be?
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?"
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.
The net result is that after you activate an application that normally loads things during Windows bootup, you may need to ensure the layer is set to Start Automatically and reboot the computer for the app to work correctly. So we do emulate Windows boot at activation time, with the goal of eliminating the need to reboot after an activation, but we don't yet do it perfectly. For 2.0, we made the choice in favor of security.
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.