次の方法で共有

App-V: On Virtual Services in App-V 5.0

  • [アーティクル]

On the subject of services, it is probably worth mentioning some of the changes with how App-V handles virtual services in V5. First and foremost, you may have noticed there is no separate virtual service agent service running for the V5 client. You have probably also noticed that virtual services are not managed or modified through the sequencer interface. So how do you configure a service during sequencing? Well, the same as a regular service, through the services control panel or the command line (or PowerShell) during the monitoring phase. Also, only the use of the LocalSystem account is supported. Other well-known SIDs such as Network Service are not supported. Services that are virtualized will also have read-only configuration during run-time when virtualized. You will not be able to change the state of the service when it is running in the virtual environment using traditional APIs.

Since App-V requires execution of an application in the context of a user account, it limits what kinds of services can be virtualized. Services that require execution at boot time or any time prior to a user logging on will not likely be a good candidate for virtualization. There are, however, many user-mode services that can be virtualized with App-V and actually work quite well with App-V.

. . .  and then there are those services we do not want in our virtualized application package due to functional or practical reasons. I use Google Chrome’s auto-update service feature as an example. Virtual applications work best when sequenced to a steady state and updated through the App-V update process. Services that automatically update base software binaries can cause applications not to function as expected.

The App-V sequencer will capture services during the sequencing process. In previous releases of the sequencer, there was a way to review the services detected in the Services tab. At that point, you could delete the services should you not want to keep them in the package. This has changed in the V5 version of the sequencer. If you notice, when you go to the services tab, you will notice that at this stage, you are unable to remove the virtual services from this screen.


  
 Removing Services during Sequencing

If you want to remove services that are captured in the monitoring process with the V5 version of the sequencer, you will have to use a different method now. During sequencing, you need to delete the services registrations in the registry prior to closing monitoring. This will require you to know where the service registrations are stored in advance or before you close out the monitoring process. For example, if I wanted to remove the service registrations for the Google Update Service, I would open up the Services management console and the Registry Editor after installation has completed and prior to stopping monitoring. When you view the properties of the service, the Service name field will give you the short name of the service. This will reflect the name of the subkey of the service located in HKLM\System\CurrentControlSet\Services


 

You can then delete this subkey to remove the service registration. In most cases, the sequencer will capture that removal and thus remove the service entry.

Removing Services from an Existing Package

If the package has already been saved, then you can modify this by opening up the package using the workflow “Update Application in Existing Package.”

 

Then during monitoring, you can open up a command prompt and run the registry editor to remove those service registrations.

Once you delete the keys under HKLM\System\CurrentControlSet\Services\<SERVICENAME> you will find the services are gone when you look at the Virtual Services tab.

 

In addition to the above, you can also use other registry editing utilities (such as REG.EXE) or even use the SC command if you are looking for a safer alternative for removing service registrations.

Disabling Virtual Services using Dynamic Configuration

If you do not want to open up the package to remove a service, you can simply disable the virtual services subsystem using dynamic configuration. Just set the subsystem value to “false” such as follows:

<Subsystems><Services Enabled=“false“/></Subsystems>

Comments

  • Anonymous
    January 01, 2003
    In App-V 4.6, virtual application services ran in context of LocalSystem but a service/process would run for each user. In App-V 5.0 we are seeing a single service/process run and only the originator can see the service unless elevated rights given to the prior to logging in. We have attempted to modify the service security descriptor interactively and at sequencing with no success. Is there a way to allow this single service to be shared? We know the app-V 5 package can see the already running process as it will not allow alternates to spawn.
  • Anonymous
    January 01, 2003
    Only the LocalSystem account is supported.
  • Anonymous
    January 01, 2003
    Yes, Services have changed primarily because there is no separate virtual service controller. Services start asynchronously at run-time and only read-only service functions are allowed and hooked. This was to prevent RDS issues where multiple instances of the service would be running per user and this created massive overhead.
  • Anonymous
    February 13, 2014
    How can I make the service start as the current user and no Local System?