locked
CONFIRMED issue with 1803 + May Rollups and Connection Group merging. RRS feed

  • General discussion

  • FYI:

    Although the May Rollups fix the blocking issues created with the April rollups, it looks like we may have a new issue.  I am traveling and therefore unable to reproduce to verify the issue, but we saw this issue in our Bern training class for all students using this client (but not the student using Windows 7).

    it appears that inside a connection group the merging was not working properly.  The base package included a folder that held several dlls, and the plugin package used the same folder with additional dlls.  No amount of "merge with local" settings would help the situation and the program would only see the dlls from the higher priority package (lower priority number).


    App-V MVP & CTP Fellow. Author of AppV books: PowerShell with App-V 5, The Application Book, & Window Caching (http://www.tmurgent.com/Books)


    Saturday, June 2, 2018 6:58 AM
    Moderator

All replies

  • I've not seen the issue so far. Thanks for sharing.


    Roy Essers


    • Edited by Roy Essers Sunday, June 3, 2018 9:25 AM
    Sunday, June 3, 2018 9:25 AM
  • There is no other AppV changes other than fixing the April start-up script issue in May rollup. so should be something else.
    Monday, June 4, 2018 4:37 PM
  • I have gone back and confirmed the issue this week.  The packages work correctly on Windows 7 SP1 with HF 10, but not on Windows 10 1803 with May rollups.  It does not matter which OS it was sequenced on.  We also confirmed that the issue is with FOLDER merging (in VFS; did not look at PVAD) and the issue does not appear in Registry merging set up the same way.  All sequencing and clients were x64 in testing performed.

    There is a primary app package, and a plugin package used in a connection group. The primary app creates a base folder (under Program Files) and sub-folder that would each be marked Override Local (by default).  The subfolder of the primary includes several initial plugins.  The plugin package consists only of Merge folders plus a set of different plugins in that same subfolder.  Both packages are user published and a connection group is made enabled to the user.  Normally the plugin package is the lower priority number (i.e. "a higher priority logically") however there are no file conflicts to worry about.  In this configuration on Win10 1803+May, only the plugin dlls are seen in that subfolder (primary app plugins missing), confirmed by the app and by an explorer windows inside the virtual environment.  On Win7SP1+HF10, all plugins are seen.

    Changing the priority order within the group changes the behavior - in this scenario only the primary app plugins are now seen instead.

    We did test changing the primary package to use merge with local and this does not affect this result.

    As I'm still on the road, so I cannot test on prior Win10 versions, but this is a lab that we do in all of our all of our training courses, including a class last month that used the February rollup and the issue was not noticed (although due to construction of the lab it is possible that it occurred and none of the students noticed).  So while the issue might not have been caused by the last rollup, this is a issue at this time.

    BUT -- THANK YOU WooHoo-Appv (whoever you are) for responding to posts in the forum!

    Tim


    App-V MVP & CTP Fellow. Author of AppV books: PowerShell with App-V 5, The Application Book, & Window Caching (http://www.tmurgent.com/Books)


    Tuesday, June 5, 2018 7:54 PM
    Moderator
  • Added detail from more testing...

    More confirmation on this situation today, including a second (purpose built) application.  Affects scenario when app uses either the current working directory or the running filepath of EXE to find subfolders and files.  Even if we cause the app to be launched via an extra launcher inside the bubble so that we start the app using a VFS path, the app making such a query is told it is in a path using the App-V cache (this is expected behavior so far and not the actual bug). Then when the app uses this path to construct a path including the subfolder and uses this constructed path to enumerates files, the enumeration ONLY sees files from the highest priority package in the group (no matter which package the exe is actually in).

    A virtual file explorer process inside the bubble looking at VFS path for the subfolder sees all files from all packages merged properly, but using launcher to start actual app using VFS does not help as when it asks for CWD or Process path it receives an App-V cache location. 

    This looks to me just like the behavior before 5.0 SP3 with whatever the VFS merging hotfix was.   I believe that the VFS driver is no longer doing the proper merging of VFS paths when asked using a package path.

    Tomorrow I will have Patrick will test PVAD equivalent scenario to see if there is a workaround other than the old kludge of building the plugin using the App-V cache location including package and package version guid that worked before the original fix.

    Again, I'll mention that the same scenario absolutely works fine on Win 7 SP1 with HF10, and I believe used to work on Windows 10 in-the-box clients.  When I'm home in a couple of weeks I'll check older Win10s to verify, but cannot right now.


    App-V MVP & CTP Fellow. Author of AppV books: PowerShell with App-V 5, The Application Book, & Window Caching (http://www.tmurgent.com/Books)



    Wednesday, June 6, 2018 7:21 PM
    Moderator
  • Additional Update:  We have problems with the layering using PVAD installs as well.

    Patrick completed the testing and PVAD layering for folders also not working correctly, although the observed behavior is slightly different.

    The initial and plugin packages were created and placed in a connection group.  The behavior with PVAD is that only the plugins in the primary package (the one containing the app exe) are ever seen, regardless of package priority order within the group.

    So the regression is that we have lost both the VFS and PVAD fixes, and no reasonable workaround (other than the one that requires hard-coding the main package GUIDs for PackageID and VersionID while creating the plugin package).

    Tim


    App-V MVP & CTP Fellow. Author of AppV books: PowerShell with App-V 5, The Application Book, & Window Caching (http://www.tmurgent.com/Books)

    Thursday, June 7, 2018 12:24 PM
    Moderator
  • Tim, as you mentioned, this is not a problem in 1803+Feb rollup but a new issue started on May rollup, sounds like a regression, could you please help to attach the package and detailed repro steps to the thread or thru your support (CSS channel) to file a bug for this? we could then take a look. 

    Thanks,

    Monday, June 11, 2018 3:34 AM
  • Still traveling, so I can attach the packages once I am back home at end of week. But problem may be reproduced using Paint.Net with instructions below. For main package, VFS Install and add some plugin dlls to the "Effects" folder under the install directory. For plugin package, expand main package to local system and add more plugin dlls to same folder. Create connection group. This can also be done using PVAD install; it produces different, but incorrect, results also. Tim

    App-V MVP & CTP Fellow. Author of AppV books: PowerShell with App-V 5, The Application Book, & Window Caching (http://www.tmurgent.com/Books)

    Monday, June 11, 2018 12:35 PM
    Moderator
  • Here are a couple of packages in a zip file that reproduce the VFS laying variant of the issue. 

    You can copy/paste the location below as the forum won't let me link to a zip file.

    link to "//www.tmurgent.com/MS_AppV_LayeringBug/VFS_OverlayIssue.zip"

    The target folder showing the issue is "ProgramFilesx86\Paint.net\Effects".  Loading both packages in a connection group and running the program and using the menu "Effects/Render" should show a total of 37 plugins:

    • 3 built into the program without dlls
    • plus 33 in the original package effects folder
    • plus 1 in the plugin package folder (shape3d).

    With the plugin as group order 0 you will see 4 plugins, with the primary package as order 0 you will see 36.


    App-V MVP & CTP Fellow. Author of AppV books: PowerShell with App-V 5, The Application Book, & Window Caching (http://www.tmurgent.com/Books)




    Friday, June 15, 2018 4:17 PM
    Moderator
  • I tried the package, it turns out to be the plugin package doesn't work as expected with the plugin alone, the DLL doesn't show any virtual path in the CMD switch as :

    cmd /appvve:c856b086-02c0-4c3d-a8d8-05acdb84308a_0b92e5fb-d4c5-488f-a4a0-f1e0a3e4482b

    am I missing anything?


    Friday, June 15, 2018 8:56 PM
  • Please pull the zip file again.  The correct packages are now in there.

    Right after I posted I realized that the wrong packages were put in the zip file.  The plugin package that you looked at was actually for the PVAD scenario (it contained only the Effects folder under Root with the plugin dll under that. Although I updated the zip file quickly, I guess I wasn't fast enough.


    App-V MVP & CTP Fellow. Author of AppV books: PowerShell with App-V 5, The Application Book, & Window Caching (http://www.tmurgent.com/Books)

    Saturday, June 16, 2018 1:27 AM
    Moderator
  • Just chiming in here; experiencing a similar/same issue.  Have a Connection Group with Adobe Acrobat DC and a plugin (so DLLs).  Worked fine.  I loaded 1803 and the latest cumulative updates because of a bug causing AHV node failures on our Nutanix platform, and now the plugin doesn't work;  no other changes and it does load the files for both packages. 
    Monday, June 18, 2018 2:31 PM
  • as followed is what I got, still same, the plugin itself can't be virtualized.


    Monday, June 18, 2018 4:19 PM
  • OK.  So let's try this again.  That was the original package.  Here is a link to a zip with the correct packages. http://www.tmurgent.com/MS_AppV_LayeringBug/VFS_Overlay2.zip

    View of the main package:

    View of the plugin package:

     And here are the results with the plugin package as priority 0 in the group:

    C:\ProgramData\App-V\DA43F5D7-879B-4BD6-B4A4-C382BB7EAE60\32083FCD-E57A-4F57-A3F0-C9B02934C66C\Root>powershell
    Windows PowerShell
    Copyright (C) Microsoft Corporation. All rights reserved.
    PS C:\5dad4b9e-d8cc-48aa-9dd9-9d9e80295849> get-appvclientconnectiongroup

    GroupId            : 16160215-6e67-4f4f-af9a-36224f5f4bc0
    VersionId          : 54477983-3cd9-8948-8e41-f391d1fd2bd6
    Name               : Group
    IsEnabledToUser    : True
    UserPending        : False
    IsEnabledGlobally  : False
    GlobalPending      : False
    InUse              : True
    InUseByCurrentUser : True
    PercentLoaded      : 0
    Priority           : 100
    PS C:\5dad4b9e-d8cc-48aa-9dd9-9d9e80295849> (get-appvclientconnectiongroup).GetPackages()

    PackageId            : 12caa3af-dacd-4ac0-ad94-5ce8c387cd28
    VersionId            : 19a5fd1c-6620-449a-b6ca-ee4d390167f3
    Name                 : PTM_Paintdotnet_Plugins_Shape3D_W7x64
    Version              : 0.0.0.1
    Path                 : \\nuc2\Packages\PTM\PTM_Paintdotnet_Plugins_Shape3D_W7x64\PTM_Paintdotnet_Plugins_Shape3D_W7x6
                           4.AppV
    IsPublishedToUser    : True
    UserPending          : True
    IsPublishedGlobally  : False
    GlobalPending        : False
    InUse                : True
    InUseByCurrentUser   : True
    PackageSize          : 518972
    PercentLoaded        : 0
    IsLoading            : False
    HasAssetIntelligence : True
    PackageId            : da43f5d7-879b-4bd6-b4a4-c382bb7eae60
    VersionId            : 32083fcd-e57a-4f57-a3f0-c9b02934c66c
    Name                 : PTM_Paintdotnet_V4_CapabilitiesAddon_W7x64
    Version              : 0.0.0.1
    Path                 : \\nuc2\Packages\PTM\PTM_Paintdotnet_V4_CapabilitiesAddon_W7x64\PTM_Paintdotnet_V4_Capabilities
                           Addon_W7x64.AppV
    IsPublishedToUser    : True
    UserPending          : True
    IsPublishedGlobally  : False
    GlobalPending        : False
    InUse                : True
    InUseByCurrentUser   : True
    PackageSize          : 146250391
    PercentLoaded        : 0
    IsLoading            : False
    HasAssetIntelligence : True
    PS C:\5dad4b9e-d8cc-48aa-9dd9-9d9e80295849> cd "C:\Program Files\paint.net\Effects"
    PS C:\Program Files\paint.net\Effects> dir shap*.dll

        Directory: C:\Program Files\paint.net\Effects

    Mode                LastWriteTime         Length Name
    ----                -------------         ------ ----
    -a----        6/18/2018   5:22 PM       (253952) Shape3D.dll

    PS C:\Program Files\paint.net\Effects> dir

        Directory: C:\Program Files\paint.net\Effects

    Mode                LastWriteTime         Length Name
    ----                -------------         ------ ----
    -a---l        6/18/2018   5:22 PM       (253952) Shape3D.dll

    PS C:\Program Files\paint.net\Effects>


    App-V MVP & CTP Fellow. Author of AppV books: PowerShell with App-V 5, The Application Book, & Window Caching (http://www.tmurgent.com/Books)

    Monday, June 18, 2018 9:52 PM
    Moderator
  • Tim, I tried this one on windows 10 16299.492 (RS3 Latest update)

    the new packages worked just fine, I can see the Shape3d.dll is visible to the main app once the connection group is created, the VFS mapping is working correctly from my side.. not sure what was the difference in your setup.




    Wednesday, June 20, 2018 4:16 PM
  • We are seeing a similar problem with Win10 (x64) 1803 App-V. :(

    I noticed that even without connection groups, a package containing files in VFS "program files" and "system" folders, will have the "program files" folder correctly merged into c:\program files\ but the "system" files are not (correctly) merged into C:\Windows\System32 files. The VFS "system" files seem to be missing, causing the app-v app to fail/crash. Perhaps a (VFS) folder security issue?

    Will do more testing next week, and create MS support case if needed.

    Thursday, June 21, 2018 9:30 PM
  • FYI - we took this offline and Microsoft has now reproduced the issue described.  

    I did not open a ticket (as I don't work for an enterprise) and there is no guarantee that it will be fixed.  But I have faith!

    <Hint>Were someone to open a ticket it would become more trackable.</Hint>


    App-V MVP & CTP Fellow. Author of AppV books: PowerShell with App-V 5, The Application Book, & Window Caching (http://www.tmurgent.com/Books)

    Thursday, June 21, 2018 9:36 PM
    Moderator
  • Ticket has been raised with MS. :)
    Monday, June 25, 2018 10:27 AM
  • what is the ticket ID?
    Monday, July 2, 2018 4:06 PM
  • SR#: 118062518451876
    Tuesday, July 3, 2018 3:14 PM
  • Microsoft is working on the fix now, it will be addressed in the next.
    Wednesday, July 11, 2018 9:22 PM
  • Just confirming for everyone that the fix did not make it into 1803 + July monthly fixups that just came out.

    App-V MVP & CTP Fellow. Author of AppV books: PowerShell with App-V 5, The Application Book, & Window Caching (http://www.tmurgent.com/Books)

    Saturday, July 14, 2018 4:12 PM
    Moderator
  • Just confirming for everyone that the fix did not make it into 1803+August monthly rollups.

    App-V MVP & CTP Fellow. Author of AppV books: PowerShell with App-V 5, The Application Book, & Window Caching (http://www.tmurgent.com/Books)

    Friday, August 17, 2018 7:28 PM
    Moderator
  • BUMP

    Just confirming for everyone that the fix did not make it into 1803+September monthly rollups.


    App-V MVP & CTP Fellow. Author of AppV books: PowerShell with App-V 5, The Application Book, & Window Caching (http://www.tmurgent.com/Books)

    Tuesday, September 11, 2018 8:37 PM
    Moderator
  • I did confirm that the problem does NOT exist on 1809 (17755.1).  So at least they fixed it there.


    App-V MVP & CTP Fellow. Author of AppV books: PowerShell with App-V 5, The Application Book, & Window Caching (http://www.tmurgent.com/Books)

    Tuesday, September 11, 2018 8:58 PM
    Moderator
  • Just letting you know that fix KB4462933 has now been realeased. After installing the update and rebooting, the App-V bug should be solved.
    Sunday, October 28, 2018 9:24 PM