Migrate App-V Usersettings

This blog is about migrating settings from an App-V 4.x package to any other installation. Is it possible if you leave the settings location the same? I think it is.

First a little intro about my thought’s on settings. When you work as an Application administrator or Application packager you often think about application settings. The settings control the connections to a Database, fileserver, backendserver, data save locations and settings that users want to create for themselves.

You can help your enduser, and yourself, by thinking about these settings in advance. Server settings, company settings and datapath’s  should be predefined when a user fist starts the application. Most of the times these settings are saved in the Registry, ini files and configfiles. Alluser config can be found in the HKLM part of the registry or the installfolder. Usersettings wil be saved in HKCU or Appdata folder. Of course, this all depends on the application.

How to control the user settings depends on the type of package you use and what kind of environment you are packaging for. Most commonly used packaging ways are;

  • App-V, settings are recorded and sometimes controlled by prelaunch scripts
  • MSI, Settings are recorded and sometimes controlled by Custom actions
  • Local installations (setup.exe), settings can be created by using response files or can be set by install-scripts, Group Policies Preferences etc.
  • The backend server contains userprofiles with settings.

If you have an environment with Immidio Flex, RES workspace manager, Microsoft UE-V or another solution that can manage your settings you should use them. In this case you can leave you package clean and manage the settings  for you client application by your solution.

But now back to App-v , without a user environment tool. When you create an app-v package you can predefine some settings. You should turn off autoupdates, configure licensefiles, serverconnections and the default data path for the users data files if possible.  This way, the user isn’t bored by these configure actions. Currentuser settings can be done by a prelaunch script.

If the user changes settings after launching the application, like the color of the text, this is saved in the userprofile. The settings are saved in an PKG file. This file can’t be read but will contain al the changes a user makes. This file will roam with the user to any system where the same App-V package is started.

This works great. The problem starts when a major application upgrade or change occurs. Think about.

  • New software version (when update package isn’t the way)
  • Converting from App-V to a MSI (local install). Yes it happens..
  • Migrating to App-V 5

Of course you should predetermine all the common settings. But settings changed by the user, which all  will be stored in the PKG file, will be gone when changing and/or upgrading! The user will not be pleased with this result.

How can we make this easier for the user?

  • Sometimes we cannot. Maybe the new version can’t deal with the settings from the old version..
  • With tools that can manage usersettings (Microsoft UEV, Immidio Flex, RES workspace manager)
  • With scripts

I created this post for environments without a user setting management tool. My solution is creating an App-V shutdown powershell script. Of course this must be adapted to your application needs. So the idea is.

  • On application shutdown export the settings to the user homedir
  • Configure the new application to import the settings from the user homedir (once)

For example, my customer has an application that appears to run badly within App-V with a certain version. A new package/installation is created. But while testing the users did lose a lot of settings.  It appears that the user can do a lot of personal tweaking in the application. So I created the following.

-App-V 4.6

Application settings:

Managed by App-V client (PKG)

Settings that must be migrated


Step 1: Export the settings from the old package

In the OSD file from the old package add the following code


The Exportscript can be placed on any place. Maybe the best way is placing it within the package on the app-v drive.

Step 1a: The export script

Steps are:

  • Export AppData\Application1\UserFiles\
  • Export HKCU\Software\ Application1\UserFiles\UserSettings
  • Create logfile

Step 2a: Import the settings into the new package

Add the following in you new app-v package (or start up script for local installs..)


Step 2b: The import script

Steps are:

  • Import if check file doesn’t exist AppData\Application1\UserFiles\
  • Import if check file doesn’t exist HKCU\Software\ Application1\\UserFiles\\UserSettings
  • Create logfile and checkfile.

ImportSettings.ps1 content

App-V 5

In my next post I will test this solution in App-V 5. My guess is that it wil work. App-V 5 stores usersettings in:


But when you start the application the settings are translated. So, appdata will become the normal appdata location. But it will only exist if the package is started. So the trick is “Run the importscript when the package is started but BEFORE the application is launched”. So I need to figure out how the pre-launch script works in App-V 5.

To be continued…


Windows 7 and error "Could not connect to the System Event Notification Service"

At the moment I work at a company with about 8000 to 9000 workstations. A couple of users called in an issue that they had trouble logging in into Windows 7. Once in a while they got the following error message during the logon process.

“Windows could not connect to the Event Notification Service service. Please consult your System Administrator”


Only one or more reboot(s) seemed to bypass the error. This was not an acceptable situation and I was asked to look into this problem.

Environment description:

  • Windows 2008 R2
  • Window 7
  • SCCM 2007 R2
  • RES Workspace Manager 2011
  • App-V 4.6 SP1

Underneath a screenshot of the error message:


After checking the event viewer I noticed that not only the “System Event Notification Service” was failing but also several other services failed to start. Underneath a list of services that are involved.

  • Certificate Propagation
  • Extensible Authentication Protocol
  • Group Policy Client
  • IKE and AuthIP IPsec Keying Modules
  • IP Helper
  • Server
  • Multimedia Class Scheduler
  • User Profile Service
  • Task Scheduler
  • System Event Notification Service
  • Shell Hardware Detection
  • Themes
  • Windows Management Instrumentation

With the knowledge that not only the “System Event Notification Service” service was failing to start I searched the web for a solution. I found several articles but they didn’t solve my problem. Than I stumbled onto the following Hotfix:


This hotfix solved my problem. But in the meanwhile several users were still experiencing this problem. Due a backlog on the change management side, it would take a while to get this hotfix in production. I decided to look for a workaround for the customers who were experiencing this problem more frequently.  It seemed, like described in the article, that the “Microsoft Virtualization client” had something to do with it. I quote:

Cause: This issue occurs when a new drive is added to the system while background services are still starting.  The most common example of this is with Microsoft Application Virtualization Client.  When this service starts, it creates a virtual drive.  When this drive is created during system startup, the Server service may crash the shared service host process.  This process contains other services which are important for completing user logins.  When these services fail at startup, a blue or black background image is displayed instead of the user’s desktop.

When trying to find a workaround I found that delaying the startup of the “Microsoft Virtualization Client” service seemed to work. This should give the other services time to start-up. It’s a quick and dirty method but it did solve the problem for the users who were experiencing this problem on a frequent base. We decided to use it as a temporally workaround until the hotfix was applied.

The hotfix is also applicable for Windows Server 2008 R2 in case you are experiencing the same issues on a server.


How to Launch Vapplauncher with Parameters using powershell

Hello everybody,

At the moment I am working in an environment where App-V is integrated in SCCM 2007. To launch an App-V application the “Vapplauncher” is used. This week I have been asked to package an application with the following requirements.



The application must be able to start from a Scheduled Task and External Application.

  • The application must start with different parameters.
  • The parameters can change every month and this should be done by the “Super user” (Which has no access to App-V / SCCM)

Starting the App-V application from a schedule or external application is just pasting the Vapplauncher command line into it. However, the Vapplauncher doesn’t accept any parameters. This is why you have to create a extra OSD with the parameters in it. This means that the “Super user” has to change this OSD each month and deploy it through SCCM. Of course this was not an option because of the rights.

The challenge:

  • Start the application with the parameters through: C:\WINDOWS\system32\CCM\VAppLauncher.exe /launch “MyApp”
  • The user must be able to change the parameters each month without having to change the OSD or having special rights.


  • Create a networkshare where the user has enough rights to change/write files
  • Place a *.txt file in the share containing the parameters
  • Create a PowerShell script (or more if needed) in the share which can do the following:
  1. Get the content of the *.txt file
  2. Start the application with the parameters found in the *.txt file which is edited by the user
  • Create an OSD to start the PowerShell script
  • Give the user the command line to start the OSD so it can be used in a schedule or External application

Components of the solution:

Networkshare: G:\MyApp\Test\
*.txt file for user: G:\MyApp\Test\MyApp_parameters.txt
PowerShell script: G:\Myapp\test\Script\Start_Myapp.ps1
App-V package: With at least one OSD that starts the application with the powershell script

The powershell script:

These are the basics of the script. Of course you should adept it to your needs with logging and checking on existing files etc. But now you will have a start.

This is the starting line you should use in the OSD:

The command line to start the application is:

Thank you for reading. I hope it will be useful for you. If you have any comments or questions you can use the comments underneath or the PM system to ask questions.


Joey Steenstra