Jun 21, 2016 - 22 Comments - Virtual Vibes -

Driving Down App-V Publishing Times in Non Persistent VDI Environments

I recently had a the chance to sit down for a few days with a financial firm in London with the aim of driving down publishing times in their stateless non-persistent VDI environment. Over the engagement we implemented a range of techniques to drive down publishing times and consequently drive up the quality of user experience using the environment.

Many of these techniques are well established and known however putting them into practice in real world scenarios can be a different proposition all together. In this blog I share with you my rough recipe for success and like all recipes, you can always look to tweak it accordingly. Also just to mention everything below is my opinion based on my own experiences so if you see things differently feel free to use the comments section to voice your views!

The Ingredients

Hypervisor

VMware, Hyper-V, XenServer or other

VDI Broker

VMware Horizon/View, Citrix XenDesktop, Microsoft RDS or other

App-V Delivery Mechanism

App-V Server

User Profile Management Solution

AppSense, UE-V, RES, Citrix UPM or other

Client Operating System

Windows 7 SP1 or later

App-V Client

5.0 SP2 HF04 or later

appvvdi

Objectives

Before throwing App-V in the mix with any environment you need first understand your goals. Anybody who understands the value propositions of App-V will understand that it is highly desirable in stateless environments, especially when compared to traditional alternatives for software delivery. One of the main benefits is the speed to deliver an App-V package, this speed can vary depending on many factors but more importantly before any of this comes into play we must understand what acceptable speed in an environment actually is.

User Experience vs Expectations

Across all the different environments I have seen, from huge enterprises to smaller organisations, I have seen such a massive variance of opinion on what is an acceptable user experience. In most cases user experience needs to equal user expectations. The issue with this is in most cases is users moving from a traditional desktop to a VDI environment will already have their expectations that the new environment will be as good, if not better than what they have already. In the end of the day users don’t care how easy your new shiny VDI infrastructure is to administer, the touted cost benefits or anything else. Most end users will measure its success based on speed and usability.

First Logon vs Subsequent Logon

This is probably the biggest point of leverage when negotiating expectations concerning App-V package delivery times. The fact is many organisations will be happy to compromise on the first time a user logons onto the VDI environment aslong as you can ensure all future logons are less painful. In my opinion this approach is justified. Imagine even in non VDI scenarios where a user might be given a new machine, all their applications are unlikely to instantly be there until they logon and receive them.

In my experience expectations can range from unreasonable to too reasonable and everything in-between with the highlighted green being the ‘sweet spot’.

VDIexpectations

Please note the above assumes that first logon is when the new packages are delivered and subsequent logon carries little to no new package delivery. Also I appreciate words like ‘noticeable’ and ‘significant’ are pretty subjective timings and down to individual perception, but hey, that’s the nature of technology.

Measurements

Before you begin it is very important to understand what are your measurements for timing a package delivery. From an App-V perspective these can be separated into three main tasks, add, publish and mount.

The operational App-V event logs will help you measure the time of these events and understand what is taking place:

Capture

I can also highly recommend my friend Ryan Bijkerk’s tool called GAP-IT which will give you a graphical way to visualise how long packages are taking to publish.

data-gap-it

Add

This task is encapsulated by the Add-AppVClientPackage command. During this phase package assets will be requested and populated into the Package Store (cache). However only feature block 0 will be fully fat on disk at this point with the remaining files being held in a sparse format until a mount takes place (naturally at launch or explicitly).  The registry hive for the package will also get staged and a range of other registry keys such as CoW mappings and streaming properties will get written.

Publish

This task is executed with the Publish-AppVClientPackage command. During this phase the package will get integrated for either user or machine by creating the relevant hardlinks to the Package Store. User based extension points such as shortcuts and FTAs will also be delivered at this point along with the generation of the catalog.

Mount

This operation naturally occurs when a user launches a package that has not yet been committed into the Package Store, the extent to which this happens will be dependant on caching decisions made. When a mount occurs the App-V streaming driver will populate the Package Store assets for the package so they are no longer sparse and held locally. A mount operation can also be triggered manually using the Mount-AppVClientPackage commands.

For further information about where and when the App-V Client puts stuff on your machine read this post here.

Method

Pre-Add

Pre-adding packages into your image, can have a really positive impact on the time it will take your users to receive their packages after logon. Typically the add operation tends to take longer than a publish for a package so by doing this upfront you can save a lot of time to get your app delivered after logon. Please note in some occasions, if your package has lots of integrations then the publish will take just as long if not longer than the add, however even in these cases a pre-add is desirable.

Pre-add is normally achieved by scripting. You can use something similar to below to list out your available packages from the management server and pre-add them onto the client.

Pre-Publish Globally

This is a generally well understood technique, by pre-publishing globally into the build you are essentially pushing the overhead out of the post login process. The pre-add, publish and mount can be done at composition of the image and new packages can be rolled into the master image periodically. Common techniques to add, publish and mount is to either script the operations or create a staging user which can logon and trigger a publishing refresh into the build which will trigger the add and publish followed by a manually scripted mount.

The positive side to this approach is that any packages that have undergone a pre-publish globally will be ready and waiting for your users as soon as they logon to the VDI platform. By also mounting the package you can also ensure packages run straight from the package cache with no streaming taking place, of course unless you are using share content store mode.

The downside of this approach is there are probably quite a few reasons you won’t be able to publish all your apps globally which are resolved by a user targeted model such as:

  • Licensing and compliance restrictions preventing you from having apps available to everyone
  • Extension point conflicts between similar apps i.e. shortcuts overwriting one another

For the reasons above you may find that pre-publishing globally is only suitable for your core line of business apps or apps that are common amongst all users.

Remove Runtimes in Package

So for applications you cannot publish globally you will have to take a pre-add approach. For the publish itself, one option to speed it up on user login is to remove any VC runtime captured by the package. While this will not be a popular suggestion with everyone as some people really like this feature, there is no getting away from the impact it has on the time to publish packages.

run5342_detected

VC Runtimes being incorporated as part of your package will not only impact the add operation due to the increased size. They will most notably have a large impact on the time to publish, this is because it is at publish when the runtimes are copied down to the native system. The event logs will expose this delay.

runtimesintegration

My fellow MVP Tim Mangan has written a great research paper on the effects on VS Runtimes which you view here.

Review Integrations

Another approach you might take to address time to publish is take a look at the integration’s your packages have.  If you have packages that take particularly long to publish there might be scope to reduce some of the integration points. You can review these by browsing the AppxManifest.xml and checking to see if your package has unnecessary integrations such at FTAs, AppPaths, Fonts etc. By reducing these you will reduce the amount of work needed to publish and integrate your package to a given user and hence speed up the delivery. This being said there are some packages which are inherently complex and won’t have much room for trimming down so only get rid of integrations you are confident to remove.

Roam User Publishing State

When you have done your best to reduce the impact on the initial publish of a package, your attention can move to subsequent logons. Out the box, assuming a stateless environment, every subsequent logon your user will need to have all the packages published to themselves again from scratch.

By choosing to roam publishing state for the user we can capture much of the information that is laid down and make this available at next logon, this will speed up the time for the publish operation of the same packages there forward.

If you choose to use UE-V to roam state in your environment then Microsoft have provided a template which you can use here.

If you want to use a non Microsoft solution then you can still use the template mentioned above as reference of what to roam or use the list below:

Registry

HKEY_CURRENT_USER\SOFTWARE\Classes

Excluding: Local Settings, ActivatableClasses and AppX*

HKEY_CURRENT_USER\SOFTWARE\Microsoft\AppV

File

%APPDATA%\Microsoft\AppV

%APPDATA%\Microsoft\Windows\Start Menu\Programs

Optional: %LOCALAPPDATA%\Microsoft\AppV\VFS (To roam global state – I advise not to)

By roaming these locations you will capture key publishing information such as the user catalog and package integrations. By having these present at logon, your publish operation for the given packages will be significantly quicker. UE-V works by capturing changes a process makes, Microsoft aided this by wrapping the publishing refresh operation in SyncAppvPublishingServer.exe, this allows for only App-V related integrations to be captured.

If you are using are not using UE-V and your UM solution doesn’t support only capturing changes from a given process then be aware that you might be roaming non App-V related integrations too, for example normal MSI delivered start menu items.

Perserve User Integrations On Login

By default the App-V client seeks to de-integrate and essentially clean-up packages that appear orphaned or deprecated. This is normally a good thing but if you chose to roam your user publish state the client will wipe away anything your UPM solution puts down before it initiates the publishing refresh. To stop this happening you will need to create a DWORD called PreserveUserIntegrationsOnLogin with a value of 1 in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AppV\Client\Integration.

Enable Publishing Refresh UI

While this technique will not improve the actual speed to deliver applications to your user it will improve the user experience. You can enable this setting via PowerShell using:

Set-AppvClientConfiguration -EnablePublishingRefreshUI

You can also set this during installation or using Group Policy. Once set it will give active feedback to your users as packages are being published after logon as a notification above the system tray.

publishingui

It is one thing making users wait, it is another making them wait with no indication that anything is happening. My advice is to enable this feature and improve the general user experience of your platform when receiving App-V packages.

Streaming Decision Points

There are numerous choices you may make regarding streaming optimisation of your packages. For example the use of shared content store mode (SCS) is very popular in VDI as it seeks to reduce storage used on the VM. If you are not familiar with this concept and the other options available to you please check out my blog post called Streaming Decisions Points.

In any respect my advice would always be to pre-ad where possible. If you chose to use SCS then avoid mounting your packages as this will override the setting.

Results

So to add a bit of real world context back to this discussion I have shared my results at this particular client belowtimingforVDI2

This testing was done for 11 packages per user and averaged across 3 logins per reading. As you can see the initial user experience meant waiting for over a minute before all of the packages published to the user were available for use and subsequent logons were pretty similar.

Pre-adding, configuring UPM and removing VC runtimes from the packages brought the time for deliver down as detailed above. Infact the 12 seconds we were able to achieve for subsequent logons was not even noticeable by the users as the Windows platform was taking around this amount of time to idle and become useable anyway. The delivery time for first logon stayed at around a minute but by enabling the publish UI we were able to feedback progress to the end users while this happened.

Okay but what about SCCM?

So to lets address the elephant in the room…

I completely understand that not everyone is using App-V Server to deliver to their infrastructure, infact on my travels I see much more ConfigMgr solutions than I do App-V Server, mainly due to its scalability and feature set as compared here.

The reality is App-V with SCCM to non-persistent VDI isn’t currently a great story. The SCCM client takes a longer period of time to kick in after logon to evaluate and publish packages to the platform. I have seen implementations that will take many minutes rather than seconds for users to receive their applications and while that is maybe bearable for first ever login to an environment it doesn’t tend to be acceptable for subsequent logins.

During my time at Microsoft we heard this feedback a lot from customers and I always felt like it was on the radar for the team. Infact the ConfigMgr team did make performance improvements with the SP1 release of 2012 but to be frank it wasn’t enough. So who knows, maybe this will be addressed in the future. Until then you can still leverage some of the techniques above to speed up delivery such as pre-add, however roaming publishing state will not have any real effect as you will still be waiting on the ConfigMgr client to kick in after logon.

22 Responses to Driving Down App-V Publishing Times in Non Persistent VDI Environments

  1. Philip Waller

    Hi Thamim,

    We are using Appv 5 sp3 and XenApp 7.8 leveraging the ctxappvlauncher.exe to stream applications to the end users device. We had many problems even with a fast 10GB network and 2012 SMB3.0 etc. After months of testing we decided to go down the route of publishing all apps globally to the %COMMONDESKTOP%\Start Men\Programs\NAme of Vendor and then picking the applications through Citrix Studio (this bypassed ctxappvlauncher which was alos giving us issues around the use of the /APPVE parameter (Citrix would not honourt this paramter int the command line and thus the app would not launch!). It adds more time and is not as agile as using the CTXappvlaucnher.exe, but its far quicker in terms of launch!
    Regards

    Phil Waller

    26 Jun 2016 - Reply
  2. Philip Waller

    PS
    The UPM settings which you posted in the thread
    are they all thats required to roam settings? We are using Appsense

    it would be nice to know a definitive list of exclusions and inclusions!! 🙂

    Regards (again)
    Phil

    26 Jun 2016 - Reply
    • Thamim Karim

      Hi Phil,

      I can see why this would be helpful, I have just updated the post above with a definitive list.

      27 Jun 2016 - Reply
  3. Philip Waller

    Thanks for the update! Much appreciated…:)
    Regards
    Phil

    27 Jun 2016 - Reply
  4. Philip Waller

    Hi Thamim

    its me again!

    can you let me know whether the UEM exclusions and inclusions are more pertinent when using User publishing than global publishing, i.e. speed up user publishing. Does that make sense?

    If we are only using global publishing will we see benefits from applying these changes?

    Regards

    Phil

    29 Jun 2016 - Reply
    • Thamim Karim

      Hi Phil,

      The roaming of publishing state is usually more pertinent in user targeting scenarios as this is normally when the user is waiting for something to arrive. However global publishing can also happen at logon so speeding this up can also be just as beneficial if the package hasn’t already been delivered to the platform.

      5 Jul 2016 - Reply
  5. Miah

    Hi Karim,

    I’m posting for the 1st time but have been following you for a while now and must say you are full of knowledge bhaisaab!
    I have an issue when sequencing an application in APPV 5.1 sequencer. When I launch the application after its been published using APPV 5.1 client with HF3 I get the error below, this error comes up when I tried to generate a report. But when launch it in APPV 5.0 sp2 then it works fine. I know its a crystal reports issue. Hopefully you can share some of you knowledge with me.

    Unhandled exception has occurred in your application.
    Method ‘get_ReportOptions’….

    See the end of this message for details on invoking
    just-in-time (JIT) debugging instead of this dialog box.

    ************** Exception Text **************
    System.TypeLoadException: Method ‘get_ReportOptions’ in type ‘CrystalDecisions.ReportAppServer.ReportClientDocumentWrapper’ from assembly ‘CrystalDecisions.CrystalReports.Engine, Version=11.5.3700.0, Culture=neutral, PublicKeyToken=692fbea5521e1304’ does not have an implementation.
    at CrystalDecisions.CrystalReports.Engine.ReportDocument.Initialize()
    at CrystalDecisions.CrystalReports.Engine.ReportDocument..ctor()
    at CrystalDecisions.CrystalReports.Engine.ReportClass..ctor()
    at ClassLibraryQCOnCallReporting.Summary_Data..ctor()
    at ClassLibraryQCOnCallReporting.frmReport.TestSummaryListing(DateTime dtFrom, DateTime dtTo, String localPanel, Boolean bOrderByLevel)
    at ClassLibraryQCOnCallReporting.QCOnCallReporting.TestSummaryReport(Form objParentForm, DateTime dtFrom, DateTime dtTo, String localPanel, Boolean bRiLiBAK, Boolean bOrderByLevel, String strCulture)
    at QCOnCall.QCMainForm.loadSummaryReport(Command cmd)
    at CommandManagement.Command.Execute()
    at CommandManagement.MenuCommandExecutor.menuItem_Click(Object sender, EventArgs e)
    at System.Windows.Forms.MenuItem.OnClick(EventArgs e)
    at System.Windows.Forms.MenuItem.MenuItemData.Execute()
    at System.Windows.Forms.Command.Invoke()
    at System.Windows.Forms.Command.DispatchID(Int32 id)
    at System.Windows.Forms.Control.WmCommand(Message& m)
    at System.Windows.Forms.Control.WndProc(Message& m)
    at System.Windows.Forms.ScrollableControl.WndProc(Message& m)
    at System.Windows.Forms.ContainerControl.WndProc(Message& m)
    at System.Windows.Forms.Form.WndProc(Message& m)
    at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
    at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
    at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

    ************** Loaded Assemblies **************
    mscorlib
    Assembly Version: 2.0.0.0
    Win32 Version: 2.0.50727.5485 (Win7SP1GDR.050727-5400)
    CodeBase: file:///C:/Windows/Microsoft.NET/Framework/v2.0.50727/mscorlib.dll
    —————————————-
    UnityRealTime
    Assembly Version: 2.4.3.2
    Win32 Version: 2.4.3.002
    CodeBase: file:///C:/ProgramData/App-V/D58EF3DD-160E-408B-AEB9-A61A1326FA5E/7C958B21-CA27-43AB-ACCC-5D7F2CD948FF/Root/VFS/ProgramFilesX86/Bio-Rad%20Laboratories/Unity%20Real%20Time/UnityRealTime.exe
    —————————————-
    System.Windows.Forms
    Assembly Version: 2.0.0.0
    Win32 Version: 2.0.50727.5491 (Win7SP1GDR.050727-5400)
    CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Windows.Forms/2.0.0.0__b77a5c561934e089/System.Windows.Forms.dll
    —————————————-
    System
    Assembly Version: 2.0.0.0
    Win32 Version: 2.0.50727.8686 (QFE.050727-8600)
    CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System/2.0.0.0__b77a5c561934e089/System.dll
    —————————————-
    System.Drawing
    Assembly Version: 2.0.0.0
    Win32 Version: 2.0.50727.5495 (Win7SP1GDR.050727-5400)
    CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Drawing/2.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll
    —————————————-
    QCOnCallRegistryKeys
    Assembly Version: 2.4.3.2
    Win32 Version: 2.4.3.002
    CodeBase: file:///C:/ProgramData/App-V/D58EF3DD-160E-408B-AEB9-A61A1326FA5E/7C958B21-CA27-43AB-ACCC-5D7F2CD948FF/Root/VFS/ProgramFilesX86/Bio-Rad%20Laboratories/Unity%20Real%20Time/QCOnCallRegistryKeys.DLL
    —————————————-
    SplashScreen
    Assembly Version: 2.4.3.2
    Win32 Version: 2.4.3.002
    CodeBase: file:///C:/ProgramData/App-V/D58EF3DD-160E-408B-AEB9-A61A1326FA5E/7C958B21-CA27-43AB-ACCC-5D7F2CD948FF/Root/VFS/ProgramFilesX86/Bio-Rad%20Laboratories/Unity%20Real%20Time/SplashScreen.DLL
    —————————————-
    ClassLibraryQCOncallDBHelper
    Assembly Version: 2.4.3.2
    Win32 Version: 2.4.3.002
    CodeBase: file:///C:/ProgramData/App-V/D58EF3DD-160E-408B-AEB9-A61A1326FA5E/7C958B21-CA27-43AB-ACCC-5D7F2CD948FF/Root/VFS/ProgramFilesX86/Bio-Rad%20Laboratories/Unity%20Real%20Time/ClassLibraryQCOncallDBHelper.DLL
    —————————————-
    QCOnCallUtils
    Assembly Version: 2.4.3.2
    Win32 Version: 2.4.3.002
    CodeBase: file:///C:/ProgramData/App-V/D58EF3DD-160E-408B-AEB9-A61A1326FA5E/7C958B21-CA27-43AB-ACCC-5D7F2CD948FF/Root/VFS/ProgramFilesX86/Bio-Rad%20Laboratories/Unity%20Real%20Time/QCOnCallUtils.DLL
    —————————————-
    AutoRule
    Assembly Version: 2.4.3.2
    Win32 Version: 2.4.3.002
    CodeBase: file:///C:/ProgramData/App-V/D58EF3DD-160E-408B-AEB9-A61A1326FA5E/7C958B21-CA27-43AB-ACCC-5D7F2CD948FF/Root/VFS/ProgramFilesX86/Bio-Rad%20Laboratories/Unity%20Real%20Time/AutoRule.EXE
    —————————————-
    UserProfile
    Assembly Version: 2.4.3.2
    Win32 Version: 2.4.3.002
    CodeBase: file:///C:/ProgramData/App-V/D58EF3DD-160E-408B-AEB9-A61A1326FA5E/7C958B21-CA27-43AB-ACCC-5D7F2CD948FF/Root/VFS/ProgramFilesX86/Bio-Rad%20Laboratories/Unity%20Real%20Time/UserProfile.DLL
    —————————————-
    System.Xml
    Assembly Version: 2.0.0.0
    Win32 Version: 2.0.50727.5494 (Win7SP1GDR.050727-5400)
    CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Xml/2.0.0.0__b77a5c561934e089/System.Xml.dll
    —————————————-
    System.Data
    Assembly Version: 2.0.0.0
    Win32 Version: 2.0.50727.5483 (Win7SP1GDR.050727-5400)
    CodeBase: file:///C:/WINDOWS/assembly/GAC_32/System.Data/2.0.0.0__b77a5c561934e089/System.Data.dll
    —————————————-
    System.Configuration
    Assembly Version: 2.0.0.0
    Win32 Version: 2.0.50727.5483 (Win7SP1GDR.050727-5400)
    CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Configuration/2.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll
    —————————————-
    System.Transactions
    Assembly Version: 2.0.0.0
    Win32 Version: 2.0.50727.5483 (Win7SP1GDR.050727-5400)
    CodeBase: file:///C:/WINDOWS/assembly/GAC_32/System.Transactions/2.0.0.0__b77a5c561934e089/System.Transactions.dll
    —————————————-
    System.EnterpriseServices
    Assembly Version: 2.0.0.0
    Win32 Version: 2.0.50727.5483 (Win7SP1GDR.050727-5400)
    CodeBase: file:///C:/WINDOWS/assembly/GAC_32/System.EnterpriseServices/2.0.0.0__b03f5f7f11d50a3a/System.EnterpriseServices.dll
    —————————————-
    Microsoft.ApplicationBlocks.Data
    Assembly Version: 2.4.3.2
    Win32 Version: 2.4.3.002
    CodeBase: file:///C:/ProgramData/App-V/D58EF3DD-160E-408B-AEB9-A61A1326FA5E/7C958B21-CA27-43AB-ACCC-5D7F2CD948FF/Root/VFS/ProgramFilesX86/Bio-Rad%20Laboratories/Unity%20Real%20Time/Microsoft.ApplicationBlocks.Data.DLL
    —————————————-
    System.Security
    Assembly Version: 2.0.0.0
    Win32 Version: 2.0.50727.5496 (Win7SP1GDR.050727-5400)
    CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Security/2.0.0.0__b03f5f7f11d50a3a/System.Security.dll
    —————————————-
    DropDownListComboBoxesCS
    Assembly Version: 2.4.3.2
    Win32 Version: 2.4.3.002
    CodeBase: file:///C:/ProgramData/App-V/D58EF3DD-160E-408B-AEB9-A61A1326FA5E/7C958B21-CA27-43AB-ACCC-5D7F2CD948FF/Root/VFS/ProgramFilesX86/Bio-Rad%20Laboratories/Unity%20Real%20Time/DropDownListComboBoxesCS.DLL
    —————————————-
    XmlDiffPatch
    Assembly Version: 1.0.8.28
    Win32 Version: 1.0.8.28
    CodeBase: file:///C:/ProgramData/App-V/D58EF3DD-160E-408B-AEB9-A61A1326FA5E/7C958B21-CA27-43AB-ACCC-5D7F2CD948FF/Root/VFS/ProgramFilesX86/Bio-Rad%20Laboratories/Unity%20Real%20Time/XmlDiffPatch.DLL
    —————————————-
    System.Web.Services
    Assembly Version: 2.0.0.0
    Win32 Version: 2.0.50727.5483 (Win7SP1GDR.050727-5400)
    CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Web.Services/2.0.0.0__b03f5f7f11d50a3a/System.Web.Services.dll
    —————————————-
    6zs88mbc
    Assembly Version: 2.4.3.2
    Win32 Version: 2.0.50727.8686 (QFE.050727-8600)
    CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System/2.0.0.0__b77a5c561934e089/System.dll
    —————————————-
    CommandManager
    Assembly Version: 2.4.3.2
    Win32 Version: 2.4.3.002
    CodeBase: file:///C:/ProgramData/App-V/D58EF3DD-160E-408B-AEB9-A61A1326FA5E/7C958B21-CA27-43AB-ACCC-5D7F2CD948FF/Root/VFS/ProgramFilesX86/Bio-Rad%20Laboratories/Unity%20Real%20Time/CommandManager.DLL
    —————————————-
    UnityMessages
    Assembly Version: 2.4.3.2
    Win32 Version: 2.4.3.002
    CodeBase: file:///C:/ProgramData/App-V/D58EF3DD-160E-408B-AEB9-A61A1326FA5E/7C958B21-CA27-43AB-ACCC-5D7F2CD948FF/Root/VFS/ProgramFilesX86/Bio-Rad%20Laboratories/Unity%20Real%20Time/UnityMessages.DLL
    —————————————-
    BRGraph
    Assembly Version: 2.4.3.2
    Win32 Version: 2.4.3.002
    CodeBase: file:///C:/ProgramData/App-V/D58EF3DD-160E-408B-AEB9-A61A1326FA5E/7C958B21-CA27-43AB-ACCC-5D7F2CD948FF/Root/VFS/ProgramFilesX86/Bio-Rad%20Laboratories/Unity%20Real%20Time/BRGraph.DLL
    —————————————-
    ZedGraph
    Assembly Version: 1.0.1812.29779
    Win32 Version: 1.0.1812.29779
    CodeBase: file:///C:/ProgramData/App-V/D58EF3DD-160E-408B-AEB9-A61A1326FA5E/7C958B21-CA27-43AB-ACCC-5D7F2CD948FF/Root/VFS/ProgramFilesX86/Bio-Rad%20Laboratories/Unity%20Real%20Time/ZedGraph.DLL
    —————————————-
    ClassLibraryQCOnCallReporting
    Assembly Version: 2.4.3.2
    Win32 Version: 2.4.3.002
    CodeBase: file:///C:/ProgramData/App-V/D58EF3DD-160E-408B-AEB9-A61A1326FA5E/7C958B21-CA27-43AB-ACCC-5D7F2CD948FF/Root/VFS/ProgramFilesX86/Bio-Rad%20Laboratories/Unity%20Real%20Time/ClassLibraryQCOnCallReporting.DLL
    —————————————-
    CrystalDecisions.Shared
    Assembly Version: 11.5.3700.0
    Win32 Version: 11.5.9710.1298
    CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/CrystalDecisions.Shared/11.5.3700.0__692fbea5521e1304/CrystalDecisions.Shared.dll
    —————————————-
    CrystalDecisions.Windows.Forms
    Assembly Version: 11.5.3700.0
    Win32 Version: 11.5.9710.1298
    CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/CrystalDecisions.Windows.Forms/11.5.3700.0__692fbea5521e1304/CrystalDecisions.Windows.Forms.dll
    —————————————-
    CrystalDecisions.ReportSource
    Assembly Version: 11.5.3700.0
    Win32 Version: 11.5.9710.1298
    CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/CrystalDecisions.ReportSource/11.5.3700.0__692fbea5521e1304/CrystalDecisions.ReportSource.dll
    —————————————-
    CrystalDecisions.CrystalReports.Engine
    Assembly Version: 11.5.3700.0
    Win32 Version: 11.5.9710.1298
    CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/CrystalDecisions.CrystalReports.Engine/11.5.3700.0__692fbea5521e1304/CrystalDecisions.CrystalReports.Engine.dll
    —————————————-
    System.Web
    Assembly Version: 2.0.0.0
    Win32 Version: 2.0.50727.5491 (Win7SP1GDR.050727-5400)
    CodeBase: file:///C:/WINDOWS/assembly/GAC_32/System.Web/2.0.0.0__b03f5f7f11d50a3a/System.Web.dll
    —————————————-
    CrystalDecisions.Shared.resources
    Assembly Version: 11.5.3700.0
    Win32 Version: 11.5.9710.1298
    CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/CrystalDecisions.Shared.resources/11.5.3700.0_en_692fbea5521e1304/CrystalDecisions.Shared.resources.dll
    —————————————-
    CrystalDecisions.Windows.Forms.resources
    Assembly Version: 11.5.3700.0
    Win32 Version: 11.5.9710.1298
    CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/CrystalDecisions.Windows.Forms.resources/11.5.3700.0_en_692fbea5521e1304/CrystalDecisions.Windows.Forms.resources.dll
    —————————————-
    CrystalDecisions.ReportAppServer.CommLayer
    Assembly Version: 11.5.3300.0
    Win32 Version: 11.5.9510.1298
    CodeBase: file:///C:/WINDOWS/assembly/GAC/CrystalDecisions.ReportAppServer.CommLayer/11.5.3300.0__692fbea5521e1304/CrystalDecisions.ReportAppServer.CommLayer.dll
    —————————————-
    CrystalDecisions.ReportAppServer.ClientDoc
    Assembly Version: 11.5.3300.0
    Win32 Version: 11.5.9510.1298
    CodeBase: file:///C:/WINDOWS/assembly/GAC/CrystalDecisions.ReportAppServer.ClientDoc/11.5.3300.0__692fbea5521e1304/CrystalDecisions.ReportAppServer.ClientDoc.dll
    —————————————-
    CrystalDecisions.ReportAppServer.DataSetConversion
    Assembly Version: 11.5.3700.0
    Win32 Version: 11.5.9710.1298
    CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/CrystalDecisions.ReportAppServer.DataSetConversion/11.5.3700.0__692fbea5521e1304/CrystalDecisions.ReportAppServer.DataSetConversion.dll
    —————————————-
    CrystalDecisions.ReportAppServer.DataDefModel
    Assembly Version: 11.5.3300.0
    Win32 Version: 11.5.9510.1298
    CodeBase: file:///C:/WINDOWS/assembly/GAC/CrystalDecisions.ReportAppServer.DataDefModel/11.5.3300.0__692fbea5521e1304/CrystalDecisions.ReportAppServer.DataDefModel.dll
    —————————————-
    CrystalDecisions.ReportAppServer.Controllers
    Assembly Version: 11.5.3300.0
    Win32 Version: 11.5.9510.1298
    CodeBase: file:///C:/WINDOWS/assembly/GAC/CrystalDecisions.ReportAppServer.Controllers/11.5.3300.0__692fbea5521e1304/CrystalDecisions.ReportAppServer.Controllers.dll
    —————————————-
    CrystalDecisions.ReportAppServer.CubeDefModel
    Assembly Version: 11.5.3300.0
    Win32 Version: 11.5.9510.1298
    CodeBase: file:///C:/WINDOWS/assembly/GAC/CrystalDecisions.ReportAppServer.CubeDefModel/11.5.3300.0__692fbea5521e1304/CrystalDecisions.ReportAppServer.CubeDefModel.dll
    —————————————-

    ************** JIT Debugging **************
    To enable just-in-time (JIT) debugging, the .config file for this
    application or computer (machine.config) must have the
    jitDebugging value set in the system.windows.forms section.
    The application must also be compiled with debugging
    enabled.

    For example:

    When JIT debugging is enabled, any unhandled exception
    will be sent to the JIT debugger registered on the computer
    rather than be handled by this dialog box.

    7 Jul 2016 - Reply
  6. Cody Lambert

    Also, you can check out my wiki article here that covers what we’ve done here at my company for over 3 years now in regards to Stateless (Citrix XenApp and XenDesktop) environments.

    http://social.technet.microsoft.com/wiki/contents/articles/25318.app-v-a-configuration-template-for-deploying-to-stateless-rds-clients-on-citrix-published-desktops-with-citrix-upm-for-profile-management.aspx

    18 Aug 2016 - Reply
  7. Quinton Partridge

    Hello Thamim,

    We are using App-V 5.1 Full Infrastructure (upgrading from 4.6), but it isn’t in production yet.

    We will be publishing applications to the universities’ computers labs which will have a base image with limited applications installed on them (Apps will be provided via App-V). The computers will have Faronic’s Deepfreeze software installed so every reboot will revert back to its original state (Any system changes are gone), so any apps published to the cache will be gone on reboot.

    What I am experiencing now is a long wait time after login for the applications to appear ready. App-v 4.6 only downloaded the 2KB .osd file and the system was aware the application existed almost immediately. App-V 5.1 appears to download all applications files as 192Kb – 256KB stubs. The entire process of creating all the files takes a long time (I have 13.7GBs of applications but only 285MB on disk). It takes a couple minutes after the user logs in to access the applications. Subsequent logins are fine, but because of deepfreeze the first users must wait much longer for the applications to be accessible.

    Do you have a suggestion on how I could speedup this process?

    Thanks
    Quinton

    7 Jul 2017 - Reply
    • Thamim Karim

      If you pre-add your applications into your base build, doesn’t have to be globally published you will find the time to publish at logon for a given user will be much quicker. At present the first logon means a user is having to both add and publish any applications.

      7 Jul 2017 - Reply
      • Quinton Partridge

        Hello Thamim, it is too late for that now. We are doing a hardware refresh this year and the image was uploaded to our hardware supplier. I was thinking of pushing out the .msi packages via a nightly startup script, but right now I’m running into problems with the .msi packages not deploying (APP-V client version 5.0 or above needs to b installed). I have yet to troubleshoot this issue.

        If I get the .msi packaged working, does it install the entire package or just the primary feature blocks?

        10 Jul 2017 - Reply
        • Quinton Partridge

          I got the .msi packages fixed, but it installs the entire package into the lab computer. Is there a way to populate the clients with the primary feature blocks without having a user log onto the client?

          12 Jul 2017 - Reply
          • Thamim Karim

            Hi Quinton, I would not rely on the .msi. This as you may have found still requires the App-V client and the .AppV package itself, all it does is run some wrapped up PowerShell. You are better off taking control of this by leveraging a scripting PowerShell approach to ‘pre-add’ (not publish or mount) the packages post build.

            14 Jul 2017 -
  8. Philip Waller

    Global publishing?

    7 Jul 2017 - Reply
    • Quinton Partridge

      Tried that, similar occurrence. Morning logins have to download all the file stubs. Unless i’m missing something and not doing it right.

      7 Jul 2017 - Reply
  9. Quinton Partridge

    Thamim, I never even thought of doing the pre-load via powershell (Add-AppvClientPackage -path “\\server\share\package.appv” | Publish-AppvClientPackage -Global).

    I have it scripted now and trying to push it out though GPO, but i’m getting a warning about execution policy. I just have to figure out how to get past that then I’m golden.

    Q

    17 Jul 2017 - Reply
    • Thamim Karim

      You don’t necessarily even need to do the Publish action. Only run the Publish if you are happy for every user that logs on to get that package, otherwise just run the add alone. You can also run a mount-appvclientpackage for packages you want to be fully present on disk (i.e commonly used apps).

      18 Jul 2017 - Reply
      • Quinton Partridge

        Hi Thamim, this is for our university’s computer labs so all applications need to be available to all users (The Labs are shared by all). I got my powershell scripts working this morning and it appears to be pre-loading the packages. I just have to do a bit more testing to ensure I am happy with everything.

        Thanks for you advise Thamim!

        Q

        18 Jul 2017 - Reply
        • Thamim Karim

          Your welcome, glad I could be of help!

          20 Jul 2017 - Reply
          • Quinton Partridge

            Hello Thamim, I did more testing and I found out that when I unpublish an application from the server, the app still is available on the client. I tried your suggestion about not performing the publish -global action. I was able to control the applications from the server by making them unpublished, however I noticed that the applications take a while to be available on the first logins, and because of deepfreeze there will be first time logins every morning.

            Any suggestions on how I can make them appear quicker for the user without using the -global command?

            Quinton

            21 Jul 2017 -

Leave a Reply

Your email address will not be published. Required fields are marked *