Wilco van Bragt - LinkeIn Wilco van Bragt - Twitter rssa 

Preload App-V Application Scripting options


When deploying App-V infrastructures in many cases it is useful to preload a set or all applications so the users can directly start working.

Some scenarios where you would like to preload an application

  1. In Terminal Server infrastructures almost all application are used on all servers, so why won't you preload them already.  I also know organizations where the same idea is used for workstations, where enough disk space is available.
  2. To minimize bandwidth usage when the workstations are staged on the central location, but are placed on a sublocation.
  3. I have seen some applications that function correctly when during operating additional part were streamed, while the function perfectly when the application was preloaded.
  4. To distribute the load on the network when a new application will be enrolled (and will be used by the majority of the employers).

Of course you can preload the applications manually, but in larger infrastructures you would like to automate this process. In this article I will describe how applications can be preloaded for the above mentioned scenarios.

Scenario 1

Preloading all applications when using the Full Infrastructure App-V scenario is really easy using the sfttray command with the /loadall parameter. In an earlier article I already described how you can preload all applications when using a Streaming Only infrastructure. Logically I'm not going to repeat that story again, so I refer to that article for all the details.

Scenario 2 + 3

When you would like to preload a specific set of applications you need to use the sfttray /load followed by the app name or the OSD file. The easiest way is to create a simple batch file where you specify per line the sfftray /load followed by the application you would like to preload. But I personally don't like changing scripts regularly, so I often use a file to specify the applications that should be preloaded. With a script I read out that file and the values are parsed to the sfttray command. When multiple applications need to be preloaded you should add a counter to ensure that preloading runs smoothly. 



************************************************************************************ Script       : PreloadAppV.cmd
** Author              : Wilco van Bragt
** Creation Date : 23-04-2010
** Usage               : Preload all applications based on available OSD files
** Date                          Version     Scripter                               Changes
** -------------------------------------------------------------------------------------
** 20:20 23-06-2008       0.1          WvB                      Initial version
** **********************************************************************************


:: --------------------------------------------------------------------------------------
::             Defining variables
:: --------------------------------------------------------------------------------------

setlocal enabledelayedexpansion
set /a counter=0

:: --------------------------------------------------------------------------------------
::             Read all the OSD files out of the text file and parse those to :PRELOAD
:: --------------------------------------------------------------------------------------

FOR /F "delims= tokens=1" %%i in (<<LOCATION>>\PRELOADAPPV.TXT) do call :PRELOAD %%i


:: --------------------------------------------------------------------------------------
::             Preload the OSD files in bundles of five and wait 20 seconds for the next group
:: --------------------------------------------------------------------------------------


                SET OSDPRELOAD=%1
                set /a counter+=1
                START sfttray /quiet /load "%OSDPRELOAD%"
                IF %COUNTER%==5 PING localhost -n 20&SET COUNTER==0     GOTO :EOF



Scenario 4

I have one customer where their business critical application will be updates periodically. This update is actually creating a new package, because the "hotfix" of the manufacturer is complete new MSI file. So technically an update is a new install, because the previous version will be removed and the latest version will be installed with the new MSI file. Such steps does not make it logical to update the application within the App-V Sequencer (the application does not store user settings, so users don't lose their configuration). Also this makes it possible for the application administrators to use the test of the hotfix next to production on one system. Because we don't want to stress the system at the moment the production environment is switched to this new package, we want to preload the app in advance so when the package is taken in production not all workstation start loading and caching the application. But also the start of new business application could stress the App-V infrastructure where preloading would be nice.

However when we create a "normal" preload script that probably still many systems will start streaming at the same moment, still stressing the infrastructure. Therefore we need to create something that arranges that the preload will be divided over the time. Actually this is pretty easy by using a wait moment using the ping localhost command with a random timer. The random timer is standard available within Microsoft operating system using the %random% variable.

An (simple) example is the following script.

** Script                 : PreLoadAppVPackages.CMD
** Author              : Wilco van Bragt
** Creation Date : 13-4-2010
** Usage               : Preload Defined App-V Packages
** Date                                               Version  Scripter Changes
** ------------------------------------------------------------------------
** 9:47 13-4-2010            0.1          WvB      Initial Version
::Generate a random wait time using the ping command

ping localhost -n %random%

sftmime /load app:"APPNAME NAME in App-V Client Console/OSDFile"

When using this script with Full Infrastructure scenario the application need to be "enabled" en the user running the script should be authorized. When you have configured shortcuts, those will be logically shown to the user. So in this case you should configure no shortcuts within the console till the moment the application is taken into production.



In this article I described the scenarios when you could think of preloading applications when using an App-V application virtualization. For those scenarios I showed how the preload can be accomplished with scripting and which part should be considered. You can use the scripts and adjust them to your needs, it's just provided with no warranty. I appreciate if you mention the original creator of the script and that you provide your adjustment as a comment to this article.