locked
Cannot get my package to add a registry key using the UserConfig xml configuration file RRS feed

  • Question

  • This is my scenario, in case you do not understand why it is I want to do this.

    • I want to upgrade an existing package.  Replacing it with a new package is going to upset a bunch of people and in theory be more work than it should be worth.
    • This package has scripts already - I do not want to touch the scripts - I want to phase in the upgrade so we can test it.
    • The update I want to do needs to touch a registry value in HKLM that is tattood from user usage in the user profile, under the users profile: HKEY_CURRENT_USER\Software\Classes\AppV\Client\Packages\4F512AC3-6D3A-40D1-899E-4A62872918E7\REGISTRY\MACHINE\Software\Classes\Wow6432Node\CLSID\{A86F053E-F1A8-11D2-B071-00C04F800624}\LocalServer32
    • In other words: when the user runs the app,  the app writes to a HKLM registry key, which is then virtualized into the user profile - that is how app-v works after all. 
    • The value under LocalServer32 that I need to change is the (default)
    • If I do not change it then a user who has used the product before gets an error, because their tattoo'd version of this key over rides what I put in the package.

    Now in App-v 4.6 I would add some registry code to my OSD file and that would be it.  It would stamp over the registry every single time the user launched the product, and is exactly what I want to do today in App-v 5.1.

    example:  under VIRTUALENV 

       <REGISTRY>
        <REGKEY HIVE="HKCU" KEY="Software\something" NOREDIR="FALSE">
         <REGVALUE REGTYPE="REG_SZ" NAME="Database_Server">DB-01</REGVALUE>
        </REGKEY>
       </REGISTRY> 

    Now I am trying to do something like this in App-V 5.1 HF7 and nothing I try is working.  Below is an example of a test I did, where I create a value called 'hellowhkcu' - I am AWARE that this is a HKCU path - it appears that I cannot do a HKLM path in the User configuration) - I get xml format errors on import when I try that, but not this:

        <Registry Enabled="true">
    	<Include>
    	       <Key Path="\REGISTRY\USER\[{AppVCurrentUserSID}]\Software\Classes\Wow6432Node\CLSID\{A86F053E-F1A8-11D2-B071-00C04F800624}\LocalServer32">
    		<Value Type="REG_SZ" Name="hellohkcu" Data="\\ourdomain.pvt\Applications\Network\myapp\myprogram.exe"/>
                </Key>
        </Include>

    I am importing the user config into my app-v server.

    I have tested this multiple times various ways and nothing ever works.  The app-v operation event log does not mention anything to do with this entry.

    Then on top of that, if I get the above test to just work so I can see how to do this .. I need to do it to a HKLM location that the user can write too .. because that is what got tattoo'd into their profile.  (see above)

    bonus question is .. when does this get applied (when it works)?  is it in publishing only or every time the user launches the virtual package?

    Thank you

    Bruce



    • Edited by BSpies1 Friday, February 17, 2017 11:14 PM
    Friday, February 17, 2017 11:10 PM

Answers

  • Easiest way to accomplish this is to open up old package, make changes, save as new package. You can distribute it along side the other package (keep in mind versioning to prevent conflicting shortcuts). You will only loose delta changes in the new package if you do not have something in place like Ivanti/Res/UE-V.

    Changes through the userconfig only get applied when the userconfig is published, so not every time you run the package. Because users got a tattooed value in their cache this will not override those settings. Only clean/new users will have the changed setting, or users where your perform a -userstate repair of the package. (Even if you create an upgrade of your package, the userdelte will still be there).

    If you do not want to create a new package, only way to get this fixed is through a startve script (run it in the VE), you can apply it through the userconfig.xml

    ps if you wanted to change a hklm key, you had to change the deploymentconfig (machine based).


    Roy Essers


    Saturday, February 18, 2017 3:53 PM

All replies

  • Easiest way to accomplish this is to open up old package, make changes, save as new package. You can distribute it along side the other package (keep in mind versioning to prevent conflicting shortcuts). You will only loose delta changes in the new package if you do not have something in place like Ivanti/Res/UE-V.

    Changes through the userconfig only get applied when the userconfig is published, so not every time you run the package. Because users got a tattooed value in their cache this will not override those settings. Only clean/new users will have the changed setting, or users where your perform a -userstate repair of the package. (Even if you create an upgrade of your package, the userdelte will still be there).

    If you do not want to create a new package, only way to get this fixed is through a startve script (run it in the VE), you can apply it through the userconfig.xml

    ps if you wanted to change a hklm key, you had to change the deploymentconfig (machine based).


    Roy Essers


    Saturday, February 18, 2017 3:53 PM
  • So in summary, I think you are saying that the Registry functionality in App-v 5 just does not work the same at all as App-v 4 and I should NOT use that method to make a registry change to an existing package.  I must wonder 'out loud' what this feature is even for then.

    Again in App-v 4 this would be simple and done, and I would not have taken so much time up trying to make this work.  I will probably have to update the scripts I already have in place then.

    I am not happy to read that something that worked so well in the previous version basically does not exist or works less effectively in the new version.  So I created a UserVoice post - https://appv.uservoice.com/forums/280448-microsoft-application-virtualization/suggestions/18419539-registry-functionality-in-the-userconfig-xml  Please consider giving this a vote.

    This experience makes me wonder what the use case is for that Registry tag in the config xml.  Your description and answer combined with the MVP Cody's suggestion that your response is correct strongly suggest to me there is none.  If I knew I wanted to add a registry key at publish time then it would be in the package itself. 

    Thank You,

    Bruce

    Wednesday, February 22, 2017 5:07 PM
  • The reason I "Suggested it as an Answer" instead of just Marking it as the answer was in hopes that it would attract attention from someone that has experienced this scenario.  Had I been certain that this was the only correct response to your question, I would have surely marked it as the answer.  Sorry for the confusion. 
    Wednesday, February 22, 2017 7:58 PM
    Moderator
  • AppV 4 != AppV5... it's a new product, a change of mindset is needed. A simple change like marking an other OS tag through OSD is not impossible without an upgrade of the package. Actually I'm happy this is not possible anymore, anyone with write access to your dfs could break packages.

    The Userconfig is there to make changes afterwards, in cases you want different configs for different groups of deployment (say Group1 gets regkey1 which points to backend1, and group2 gets regkey2 which points to backend2), or in cases you forgot something and you want to fix it without touching the whole package again. It's also used to change Com-mode and enable/disable subsystem components, like fta's, shortcuts, env vars, extentions, etc etc.

    Roy Essers

    Wednesday, February 22, 2017 10:36 PM
  • This is what I am trying to do with the config. The scenario you mention is basically my situation.  I want to change a registry value after the fact. 

    The reason for 'after the fact' is this is a package upgrade, where I am moving one of the utilities we bundled in the package*. I found out afterwards that existing users have a registry value stamped into their cache from the old version that breaks my package, so I need to change it.  It works fine for brand new users.

    *in hindsight this should have been using built using diff packages and connection groups .. oops.

    Thursday, February 23, 2017 8:26 PM
  • I have thought about this some more, and ran a few more tests.

    It looks like this ability to add a registry value or key in the dynamic configuration xml file(s) applies to the package and not to the user cache.  The previous version wrote their changes via the OSD file into the user cache.

    It would be super if something could be done to allow the administrator to choose where the registry statements we put into the dynamic configuration are going to go - the package or the cache.  Similar to how we can execute user scripts as virtualized or not, for example.

    p.p.s I discovered how to set the default value for a registry key during all my mucking around.  I could not find documentation on how to do that.  If you need to do that, just leave the name="" blank, i.e.

             <Key Path="\REGISTRY\Machine\Software\Classes\Wow6432Node\CLSID\{A86F053E-F1A8-11D2-B071-00C04F800624}\LocalServer32">
              <Value Type="REG_SZ" Name="" Data="\\mydomain.com\some\thing\here.exe"/>
              </Key>

    Friday, February 24, 2017 4:19 PM
  • This is what I am trying to do with the config. The scenario you mention is basically my situation.  I want to change a registry value after the fact. 

    The reason for 'after the fact' is this is a package upgrade, where I am moving one of the utilities we bundled in the package*. I found out afterwards that existing users have a registry value stamped into their cache from the old version that breaks my package, so I need to change it.  It works fine for brand new users.

    *in hindsight this should have been using built using diff packages and connection groups .. oops.

    I encountered a very similar issue where registry keys were not being applied when I set them in the dynamicconfig.xml files.  I found the issue was the 'NoBackgroundRegistryStaging' key blocked it from working:

    https://social.technet.microsoft.com/Forums/en-US/251bae44-54d9-4295-a86b-09e2292c37e3/appv-50-sp2-hf4-registry-not-applying-when-set-via-dynamicconfigxml?forum=mdopappv

    If I removed or disabled that option than the registry keys would apply without issue.  I don't know if that has been fixed but you may want to check to see if you have that key.


    • Edited by TrententMVP Wednesday, March 8, 2017 5:23 AM Linked the link
    Wednesday, March 8, 2017 5:22 AM