TMEdit The Ultimate App-V Package Editor
To Documentation Index
Menu: Extensions: Virtual Services
App-V categorizes aspects of an applications installation into a set of "Extensions", each of which require special processing either during app deployment or during the virtual app runtime.
Services are an internally exposed extension that does not affect the external OS during App-V Publishing, but makes them available to applications running in the virtual environment only.
The client virtual Services manager will manage the virtual services, automatically starting and stopping the services. For virtual services set to automatic start, the virtual services are started whenever and however the virtual environment containing this package is started, and shut down whenever the rest of the processes for the virtual environment exit. For virtual services set to manual start, these start when requested by the virtual application, and will be shut down whenever the rest of the processes for the virtual environment exit (assuming the app didn't do so already).
The sequencer GUI does not expose all virtual services installed, but only those that it can handle. This display goes beyond the registered extensions to include other service objects that the package analyzer detects as present. These will appear in the list with the EnablePub not checked. The reason for this is to allow you to fix services ignored due to invalid logon Account. App-V requires virtual services to run under the same account as that of the App-V client -- Local System. Although there are good reasons for services to use different accounts, most will work under Local System anyway. So we can change that setting, enable it, and test like crazy to make sure it works. The Analyzer has detection and automated fix capabilities for this.
The most common change made on this display is to disable virtual services, especially those associated with updaters. Our preferred method is to leave the publishing enabled but set the start type to disabled. Some apps freak out if the service doesn't exist, but do respect a disabled service.
Another issue we can overcome with editing is that the same user cannot have two virtual services with the same name simultaneously running in two different packages. We run into this with Flexra FlexNet licensing in some environments, for example. Our standard solution to that problem is to extract/remove the service from the packages and apply externally to the systems. In some cases, we might be able to resolve the issue by renaming the service. It isn't going to work all of the time, as the vendor may have dependencies on the service name, but when it does you can be a hero.