locked
[AppV5.1] - Help needed in order to get a bug fixed RRS feed

  • General discussion

  • Hi,

    A few weeks ago I've installed a test environment with AppV5.1. There is a bug in the Management server though, which is shown in the video here. It manifestates when you have multiple configurations on one package. For example when you have an application that needs specific parameters for it to connect to a specific DB or something, which you then connect to specific AD groups. If you delete one of those custom configurations, all other custom configurations are reverted to default. The video quite clearly shows what the issue is.

    I've submitted a support ticket for that with MS Pro Support. They reproduced it, and found the same result. They say it's a bug, but they won't fix it for now. Maybe in an upcoming release (ie service pack). We are too small to justify a hotfix. We are a small company. In the past I've worked in a top 500 company with over 200.000 employees. We had a MS Premier contract there, and doors open when you have that. I never had this type of discussion back then.

    Basically I think this is a very urgent bug to fix. Apart from my own, I know AppV environment where applications have the most nasty custom configurations to connect to specific database instances. Having them all returned to default would severely impact production. I asked support to reconsider to still create a hotfix for it, to prevent huge problems when more companies jump at AppV5.1. They stated though no-one else has reported this yet and that's another reason it won't be fixed. I don't know, but if my product has an identified issue, I'd sure do all I could to prevent other customers from running into it. Ofcourse not much tickets for AppV5.1 are raised yet, the product is just out. I am quite frustrated by how we are treated by MS (again) but still I think this issue can have such big impact for customer that aren't aware, that it should be fixed.

    Therefore I ask for your help. Maybe there are people with better connections to the AppV team than I have. Or people that have 5.1 running already and can most surely also confirm this issue. I, but more importantly the whole AppV 5.1 community would be helped if you raise a ticket for this as well, to get MS to do something about it. My ticketnumber is 115092213187046, feel free to refer to that.

    Thanks all in advance.

    Monday, September 28, 2015 1:30 PM

All replies

  • Hi,

    You can post in your feedback in the below customer feedback site.The App-V engineering team will actively respond to your post.

    http://appv.uservoice.com/forums/280448-microsoft-application-virtualization


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

    Monday, September 28, 2015 2:02 PM
  • Monday, September 28, 2015 2:04 PM
  • Hmm. I will check this scenario in my test lab and if it persists, definitely will vote for your suggestion.

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

    Monday, September 28, 2015 2:08 PM
  • Thank you so much for that!
    Monday, September 28, 2015 2:11 PM
  • We are also experiencing this same issue when using PowerShell to manage our App-V server. Our infrastructure is still on v5. See post here: https://social.technet.microsoft.com/Forums/en-US/5ebe04a4-5315-4bc0-934e-a1214e421102/appv-powershell-grantappvserverpackage-overwrites-the-custom-configurations-of-preexisting?forum=mdopappv

    If you found this post helpful, please give it a "Helpful" vote. If it answered your question, remember to mark it as an "Answer".

    Friday, October 2, 2015 3:00 PM
  • I have tested and confirmed this is happening - 5.1 using both the GUI and PowerShell. I am assuming the GUI is using PowerShell to perform the actions so I would expect them to be the same.

    I have thrown together a PowerShell script, tested in my environment, that will capture existing entitlements, grant the new entitlement and restore previous entitlements. Dot sourcing the script, you can use Grant-AppvServerPackageFix passing it the Name of the package, Name of the group, path to store configurations and optionally if the new group should be assigned a custom configuration, the path to the user configuration XML file.
    http://1drv.ms/1GqPMLZ

    I have included comments so hopefully reviewing the script will be pretty self explanatory.

    This could be expanded to include things like, copy custom configurations to have new groups added and copy the configuration from and existing group, etc.

    #Requires -Modules AppVServer
    #Requires -RunAsAdministrator
    
    <#
    .Synopsis
       Add group to App-V 5.1 package entitlement without losing custom configurations
    .DESCRIPTION
       When adding additional entitlements to App-V 5.1 packages, custom user configurations
       appear to be lost, using Grant-AppVServerPackageFix will capture existing entitlements
       with custom configurations and replace these after adding additional entitlements.
       Customized deployment and user configurations will be saved in provided SavePath.
    .EXAMPLE
       Add group Contoso\mygroup1 to package Chrome_20 with dynamic user config c:\temp\Chrome_20_mygroup1.xml and use c:\temp to save copies of existing custom configs
       Grant-AppVServerPackageFix –Name Chrome_20 -Group Contoso\mygroup1 –UserConfig c:\temp\Chrome_20_mygroup1.xml -SavePath c:\temp
    .EXAMPLE
       Add group Contoso\mygroup1 to package Firefox_20 using default config and c:\temp to save copies of existing custom configs
       Grant-AppVServerPackageFix -Name Firefox_20 -Group Contoso\mygroup1 -SavePath c:\temp
    #>
    function Grant-AppVServerPackageFix
    {
        [CmdletBinding()]
        [OutputType([boolean])]
        Param
        (
            # Name of App-V Server package to modify
            [Parameter(Mandatory=$true,
                       ValueFromPipelineByPropertyName=$true,
                       Position=0)]
            [string]$Name,
    
            # Name of Group to add entitlement to the package
            [Parameter(Mandatory=$true,
                       ValueFromPipelineByPropertyName=$true,
                       Position=1)]
            [string]$Group,        
            # Path to save existing user configuration files
            [Parameter(Mandatory=$true,
                       ValueFromPipelineByPropertyName=$true,
                       Position=2)]
            [ValidateScript({Test-Path $_ -PathType 'Container'})]
            [string]$SavePath,
            # Path to custom user configuration file for group being added
            [Parameter(Mandatory=$false,
                       ValueFromPipelineByPropertyName=$true,
                       Position=3)]        
            [string]$UserConfig
        )

    Sunday, October 4, 2015 1:50 PM
  • Ray,

    while in essence a simple script this is genius and a real day-saver! The ticket I filed with MS got paused for now , and only after quite some discussion they told me the AppV product team is now reconsidering if this is 'important enough' for a hotfix or they'll (maybe) implement the fix in the next official release. The workaround supplied by Microsoft is 'delete the unneeded group, then manually revert all configurations to their previous setup'. They are writing a KB article for that workaround. I can't even call that a workaround.

    All kudos for you Ray! For now this makes AppV 5.1 usable in our test environment. Thank you a million. I still hope MS gets their act together and supply a fix.

    Monday, October 5, 2015 9:24 AM
  • AppV5.1 Hotfix1 should solve this issue.
    Tuesday, November 24, 2015 4:05 PM
  • It does. I'm running that in my testenvironment already and that particular issue seems to be fixed. Shame though I got confirmed from MS support that the only started building this fix after a bigger company reported the same issue. My (paid!) support call was deemed not 'big' enough... But alas, that's how it works nowadays.

    Thanks!

    Tuesday, November 24, 2015 4:09 PM
  • It appears this has been fixed in 5.1 HF1 for the web interface but not the PowerShell cmdlet.

    In testing, using the web interface the entitlements are maintained perfectly, using PowerShell there is no change in behaviour - entitlements are replaced and use default configuration.

    Saturday, November 28, 2015 3:21 PM
  • Thanks for sharing the info, at least they fixed the GUI, but strange they forgot about the cmdlets.
    Saturday, November 28, 2015 5:22 PM