none
Windows 10 1709 breaks App-V packages RRS feed

  • Question

  • We are currently piloting Windows 10 1709 and discovered the following issue in our environment. (App-V / SCCM integrated)

    When an app-v package is added and published the HKLM\Software registry.dat file is placed at location:
    C:\programdata\Microsoft\AppV\Client\VREG\Packages\<packageID>\<versionID>\REGISTRY\MACHINE\SOFTWARE.DAT
    So far-So good. However, when the package is fully mounted (AS SYSTEM/NON INTERACTIVE) the file is removed after the mount operation completes. Because of this, the app-v reg keys are missing inside the VE breaking the app-v app.
    This ONLY happens when the mount operation is performed as user "SYSTEM/NON INTERACTIVE" (IE SCCM Client). When mounted using a standard admin/user account, the file is not removed and the app-v app works as intended.

    Anyone else having this issue?
    Monday, October 30, 2017 7:44 AM

Answers

All replies

  • Same issue here - if the App-V package is mounted as SYSTEM, SOFTWARE.DAT is missing and the package is broken. If I mount it manually as an admin account, it seems to work fine...

    Felix

    Tuesday, October 31, 2017 10:47 AM
  • Some additional information: I use a connection group on top of an App-V package, and SOFTWARE.DAT is there after the package has been added, mounted and published (globally), but has vanished again after the connection group has been added, mounted and enabled.

    Saving SOFTWARE.DAT before installing the connection group and restoring it afterwards completely breaks the package - it won't even start anymore (error: application failed to launch, may be due to a network failure, error code 0x00003C05-800F0002).

    Felix

    Tuesday, October 31, 2017 11:20 AM
  • I have the same Issue here

    Scenario: Pc with 1 app-v-deplyment (over sccm)
    if depoyed throuh sccm the File ..\registry\machine\software.dat is completly missing (from beginning) and when i start the application the cpu-load is high and it seems to stuck in background.

    When i install the package as admin everything works fine.

    Interestingly, if i install as system (over psexec) from cmd it also works fine.

    Maybe its an problem in sccm-context?

    Friday, November 10, 2017 1:37 PM
  • Could be but I doubt it. Adding/Publishing -global/mounting packages as SYSTEM Interactive (psexec -s -i) works here also. Only as SYSTEM non-interactive (psexec.exe -s) seems to fail (reg file removed).

    We are upgrading our DP's next week so we can upgrade to the latest ConfigMgr build. (Currently 1610). Will update this post with findings after CM upgrade.

    Friday, November 10, 2017 7:45 PM
  • Only 1709 of also on 1703?

    Roy Essers

    Friday, November 10, 2017 8:38 PM
  • Only 1709. 1703 (and previous versions) do not have this issue . Tested with Win 10 Enterprise x64 build 16299 and 16299.19
    Friday, November 10, 2017 10:15 PM
  • Did you already open a ticket @MS?

    Roy Essers

    Monday, November 13, 2017 4:44 PM
  • No not yet, before I make a ticket, I'm going to do some further testing...
    Wednesday, November 15, 2017 2:16 PM
  • I can reproduce the issue too. software.dat gets removed only if the package is published global, and mounted under SYSTEM non-interactive.
    If you add the package, mount it directly, or publish it to users, it's fine too.

    In the following screenshot you can clearly see that appvclient.exe has successfully removed software.dat:

    Roy Essers

    Wednesday, November 15, 2017 11:35 PM
  • Same issue here. Any Updates on this issue?
    Friday, November 24, 2017 1:02 PM
  • Ran some more tests with latest Windows/ConfigMgr builds. Problem persists. A ticket will be created with MS next week. I will keep this post updated...
    Friday, November 24, 2017 3:20 PM
  • Hi ,

    i just experienced the same issue.

    With Kind regards,

    Tobias

    Monday, November 27, 2017 7:35 AM
  • Ticket has been raised, waiting for more info from MS...
    Monday, November 27, 2017 11:30 AM
  • Do you by chance have some sort of ticket number or something that I can reference and send to my Microsoft rep?

    We've run into the same issue once upgrading to 1709.  From what I can see though, it's not limited deploying the virtual apps as localsystem (a colleague deployed the same app using his local admin account using powershell and we get the same results).

    fyi, I've noticed that as a workaround, if you grab the file(s) from the '...registry\Machine' folder on a Windows 10 1703 computer and just copy them over to the win 10 1709 computer to the same location... the apps launch then. I haven't done much testing though so maybe 'parts' of the virtual app are still broken... don't know yet.

    Tuesday, November 28, 2017 5:46 PM
  • MS incident# 117112717220704
    Tuesday, November 28, 2017 8:49 PM
  • the problem seems to be gone with KB4051963 released yesterday(?), winver 16299.98, although it's not listed in changlogs

    software.dat exists now after installing; testet with "psexec -s" and via sccm devicebased installation


    • Edited by schelms Friday, December 1, 2017 3:27 PM
    Friday, December 1, 2017 3:22 PM
  • I'm not so sure that KB resolves the issue.... I had actually created a new base image with that KB installed. Then I used that new image to deploy a VM...I deployed a virtual app, along with a few other apps using SCCM and at that point the virtual app was working fine.  I restarted the VM multiple times and checked the virtual app and again all was fine.  This morning I installed a few more apps for testing...and went back.. and the software.dat was gone and the virtual app no longer runs.  

    So in my case, the app was fine right after deployment...but some process along the way smoked the files.

    Friday, December 1, 2017 4:12 PM
  • Just tested on a fresh install with KB4051963. (build 16299.98)

    The problem still exists, this build behaves exacly the same as all the previous builds. As soon as I receive more info from MS, I will let you know.

    Monday, December 4, 2017 9:09 AM
  • I've found that the virtual app would be there with software.dat still in place but shortly afterwards would go missing.  This is being done on test VMs where I'm deploying a bunch of apps.  So I'd deploy a virtual app, and confirm it's working, then deploy a few other apps and then notice software.dat is gone. Almost seems as though it's an issue with the installer service or something along those lines. 

    I've tried deploying the virtual app as an .msi in a task sequence and setting that step to run as an admin user rather than the default localsystem...thinking that'd work around the problem...but no... eventually when I deploy something else as localsystem the files go away.

    Monday, December 4, 2017 12:06 PM
  • any news from MS ?

    if not i would open up a case too.

    With kind regards

    Monday, December 11, 2017 8:51 AM
  • I asked for a status update last week but have not yet received more info.
    Monday, December 11, 2017 8:58 AM
  • Just checked online, status is: "open"...
    Monday, December 11, 2017 9:21 AM
  • Thank you for this information.

    I will concider to open a support case tomorrow.

    Monday, December 11, 2017 12:47 PM
  • I asked for a status update last week but have not yet received more info.

    Have you heard something from your case ?

    With kind regards

    Friday, December 15, 2017 6:13 AM
  • No, not yet...
    Friday, December 15, 2017 7:45 AM
  • I had the same problem with several packages. But I updated the sequencer from https://support.microsoft.com/en-us/help/4041137/september-2017-servicing-release-for-microsoft-desktop-optimization and resequenced 3 different packages and then deployed them with SCCM. The problem disappeared and the .dat files are not deleted anymore.
    Wednesday, December 20, 2017 3:38 PM
  • Sorry, after some testing the files are being deleted again.....
    Thursday, December 21, 2017 2:15 PM
  • Though so.. I allready tried resequencing (with sequencer from 1709 ADK) but that did not solve the problem. Well at least I got confirmation from MS that "the case was escalated internally".  So hopefully we're getting somewhere now.
    Thursday, December 21, 2017 2:21 PM
  • Just got info from MS: "Your issue is related to 1703 which is in 1709 as it has not been resolved. There is a fix which was due to be released early January but this has been put back until Feb 2017." (I assume that they mean Feb 2018)

    More troubleshooting is ongoing, will keep this post updated.

    Friday, December 22, 2017 11:55 AM
  • Hi,

    Can you try adding the below registry to the machine and then test the App-V package behaviour?

    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AppV\Client\Compatibility]
    "RegistryCompatibilityMode"=dword:00000001

    Please note that either the App-V Client service needs to be restarted or the machines needs to be restarted after implementing the registry in order for the configuration to work.

    This will reset the 1703's or 1709's registry access behaviour (CREG method) to conventional method how it to used to be before 1703 ( VREG method).

    Let us know if it worked.

    • Proposed as answer by Mohit Kapoor Thursday, January 4, 2018 6:02 PM
    • Unproposed as answer by Mohit Kapoor Thursday, January 4, 2018 6:02 PM
    • Proposed as answer by Mohit Kapoor Friday, January 5, 2018 6:48 AM
    • Marked as answer by mrToHe Friday, January 5, 2018 7:35 AM
    • Unmarked as answer by mrToHe Monday, February 26, 2018 8:11 AM
    Tuesday, December 26, 2017 2:18 PM
  • Yes, it seems to work. Have put in TS for new computer installs with 1709 and the apps work fine now.

    Is this a permanent workaround?

    Thursday, January 4, 2018 12:21 PM
  • Hi,

    This is NOT a permanent workaround.

    As per MS, a patch will be released by last week of February to reset the App-V Client behaviour from CREG to VREG.

    After the patch installation, even if the registry is present on the machine, it will be of no use and the applications will work as expected.

    Kindly mark the posts which answered your question.

    Thursday, January 4, 2018 6:06 PM
  • Microsoft has released an update today for 1709.

    https://support.microsoft.com/en-us/help/4074588/windows-10-update-kb4074588


    (Please click on Vote as Helpful and/or Mark as Answer, if it has helped you.)

    MVP - Windows and Devices for IT

    app2pack.blogspot.com: app2pack.blogspot.com

    • Proposed as answer by Newalloy Thursday, February 15, 2018 10:14 PM
    • Marked as answer by mrToHe Monday, February 26, 2018 8:10 AM
    Wednesday, February 14, 2018 4:20 AM
  • Microsoft has released an update today for 1709.

    https://support.microsoft.com/en-us/help/4074588/windows-10-update-kb4074588


    (Please click on Vote as Helpful and/or Mark as Answer, if it has helped you.)

    MVP - Windows and Devices for IT

    app2pack.blogspot.com: app2pack.blogspot.com


    Installed and tested.  This KB has resolved the issue, and the workaround is no longer needed after applying this KB.
    Thursday, February 15, 2018 10:16 PM