Microsoft Application Virtualization

Welcome to the Microsoft Application Virtualization customer feedback site! Please submit your ideas or vote for one of the current features suggested below. The engineering team is actively monitoring the site and we want to hear from you!

I suggest you ...

You've used all your votes and won't be able to post a new idea, but you can still search and comment on existing ideas.

There are two ways to get more votes:

When an admin closes an idea you've voted on, you'll get your votes back from that idea.

You can remove your votes from an open idea you support.

To see ideas you have already voted on, select the "My feedback" filter and select "My open ideas".

Enter your idea

(thinking…)

Enter your idea and we'll search to see if someone has already suggested it.

If a similar idea already exists, you can support and comment on it.

If it doesn't exist, you can post your idea so others can support it.

Enter your idea and we'll search to see if someone has already suggested it.

Bring back Office 2016 volume license version support like there was for Office 2013. We need to support Office 2016 VL and O365 in App-V on desktop and RDS for the foreseeable future. We are moving from Office 2010 & 2013 this summer and our Citrix environment is going to be stuck on 2013 unless we decide to use some sort of unsupported method to get Office 2016 VL to work in App-V. Sadly even O365 2016 Viso does not work on RDS in App-V. All this stuff needs to get sorted out ASAP!

We request to change the way the App-V Publishing Refresh UI notifications are presented to end-users and also mitigate a number of user experience errors generated by the fact that applications can be clicked and opened while the Sync is in progress, causing multiple errors that are confusing the user.

The improvements we propose are the following:

A. Move the App-V Publishing Refresh UI (Sync) prior loading the user session / prior loading Windows shells (e.g. preferably to something similar to GPO update at logon time)
OR/AND
B. Change the wording of this sync popup or allow organizations to change/customize this wording. We believe a more suitable wording for users to wait until the sync is finished would be:

“Please do not attempt to launch applications or files until advised that your desktop is ready for use
Your desktop is starting….
(2/2) Preparing App2 24%”

Additionally to this wording, the following customizations/changes should be accompanied by

• Change the size of this sync popup to be larger and more visible to users
• Change the position of this sync popup to be more visible to users
• Change the branding of this sync popup (nice to have)

We request to change the way the App-V Publishing Refresh UI notifications are presented to end-users and also mitigate a number of user experience errors generated by the fact that applications can be clicked and opened while the Sync is in progress, causing multiple errors that are confusing the user.

- Currently SCCM doesnt unpublish an AppV application when it is in an uninstall collection
- SCCM client doesnt perform any AppV action as soon as it encounters for example a MSI installation that requires a reboot

The Registry functionality in the config xml should work more like it did in App-V 4.6, where the code is executed at launch every time in the users context no matter if it was HKLM or HKCU. If I want the registry setting applied in user, then user config.xml; if I want the registry setting applied using system context then put it in the machine config xml etc.

I recently had a need to make a change to an existing package that I was upgrading, and attempted to use the new Registry functionality in the config xml for my published (and updated) package and discovered this does not work anything like the old App-V 4.x way. Why is that? why couldn't it work the same way or similar?

This feature from appv 4.x was great for quickly changing something in an existing package, or over-riding a user cached preference, i.e. an ODBC DSN or License server name etc. We should do a quick change without having to re-package or update an existing package and go through all the steps and testing that involves.

There are many ways to skin a cat, of course. But this Registry feature/setting that exists in the config XML does not make any sense to me. Why would someone need to use it the way it is today, if it does not work like the Registry tag from AppV 4.x did?

p.s. I could be wrong in how this works but I tried and tried, and it just does not work the way I expect. I asked a question on the TechNet forums and was basically told it does not work the way it used to in App-v 4. and was given the advice to not even bother trying to use this feature to solve my problem.

The Registry functionality in the config xml should work more like it did in App-V 4.6, where the code is executed at launch every time in the users context no matter if it was HKLM or HKCU. If I want the registry setting applied in user, then user config.xml; if I want the registry setting applied using system context then put it in the machine config xml etc.

We package all our apps to load 100% before launching, and deploy them using full infrastructure. We have either configured by design or by default the fact that users load their apps on first use, not at logon.
Every package we have displays a 'loading' type progress bar then on the first use, and gets to 100% before the program launches for the user.

I recently had to upgrade a package, so I did that using the sequencer. I knew what to change very specifically, so I used the 'Edit package' option when modifying the existing package. I made my file and registry change, and saved the package to a 0.0.0.2 version.

The upgrade went well, but I have noticed something since then.
New users who never launched the package before do not get the progress bar. Not only that, but according to Get-AppvClientPackage output (that I run during launch time) it seems it is actually launching before 100% gets cached.

Why is this and why wouldn't the editor let me say to still load 100% before launch? I can understand conceptually why using 'edit' mode is an issue for creating "feature block 1" if I wanted to stream it, (because I am not executing the program). Wouldn't having a "Force application(s) to be fully downloaded before launching.." make more sense to be "default" in this scenario to rather than streaming delivery by default? And regardless can this not be a choice?

So my suggestion is to change the default to load 100% before launch, or at least give us the option and either way show the progress bar regardless of the choice.

We package all our apps to load 100% before launching, and deploy them using full infrastructure. We have either configured by design or by default the fact that users load their apps on first use, not at logon.
Every package we have displays a 'loading' type progress bar then on the first use, and gets to 100% before the program launches for the user.

I recently had to upgrade a package, so I did that using the sequencer. I knew what to change very specifically, so I used the 'Edit package' option when modifying the existing package. I made my…

When you set this information in the sequencer when building the package I would like the console to pull this information when I Import the package. It would be fine if this field was editable after the fact. Just the initial import of the package to populate this field would be appreciated.

The heart of the desktop strategy in many organization turn around the different applications that need to be packaged, assigned, distributed. We are entering a world where Windows 10 is one of rapid changes and App-V seems to be the recommended approach for application isolation in the CBB pace. However as of now, it is difficult for a customer to start "as new" without an App-V background and trying to figure out the "correct way" to embrace Windows 10 in its completeless. There are just so many choices possible. Microsoft used to produce such "reference architectures" in the past, and since Windows 10 should be the last of its kind, it might be valuable from the product group to get the prescriptive, definitive architecture guidance to help organization do the right things while they invest for going out from W7-8 to W10.

The heart of the desktop strategy in many organization turn around the different applications that need to be packaged, assigned, distributed. We are entering a world where Windows 10 is one of rapid changes and App-V seems to be the recommended approach for application isolation in the CBB pace. However as of now, it is difficult for a customer to start "as new" without an App-V background and trying to figure out the "correct way" to embrace Windows 10 in its completeless. There are just so many choices possible. Microsoft used to produce such "reference architectures" in the past, and…

It would be great to have that kind of integration for user-published packages as well as currently you have to either:
- Publish globally and give up on the idea of targeting users
or
- Publish to users but make them scroll through apps on every unknown extension which is tiring

The website to download the 5.1 update for client and rds is included in the x86 platform. the x64 one automatically suggested is providing a 5.1 Mgmt server update. This is extremely confusing and annoying. It must be addressed.

One thing we've noticed is that every time a user opens the "Open With" dialog, it takes forever (3-5 minutes) to show up because it tries to populate the dialog with ALL of the currently published App-V packages. This is evident from the fact that once you expand the "More Apps" link, where you can find the names of all of the currently published packages, and from the fact that during the process, the App-V process uses up an extraordinary amount of CPU time (20-50%) and memory (several gigabytes).

This happens even though we've explicitly disabled file type associations for all of our apps by setting <FileTypeAssociations Enabled="false">.

Please either change the default behavior or provide us with some way to override it.

We have hundreds of published apps per user here.

One thing we've noticed is that every time a user opens the "Open With" dialog, it takes forever (3-5 minutes) to show up because it tries to populate the dialog with ALL of the currently published App-V packages. This is evident from the fact that once you expand the "More Apps" link, where you can find the names of all of the currently published packages, and from the fact that during the process, the App-V process uses up an extraordinary amount of CPU time (20-50%) and memory (several gigabytes).

Editing the shortcut manually to the above will result in a working shortcut.

In fact, App-V used to do this correctly before the PVAD change. Many of our older packages that used PVAD had similar shortcuts, and all of them were getting expanded correctly without any additional effort on our part. So this is almost certainly a valid bug and regression.

We have a few packages that create shortcuts that takes other files as arguments like so:

"C:\App\app.exe" -run "C:\App\app2.exe"

When we sequence a package like this and then publish it using the latest App-V client, the resulting shortcut becomes something like this: