The Collection

A collection of useful information.

Filtering by Category: App-V

App-V 5.0: PowerShell VE launcher.

Quick little script to enable you to launch local apps into a VE. Can be run of two ways:

Prompts the user for an App-V app and then the local executable to launch into the VE.

Accepts command line arguments to launch the specified exe into the specified VE.

Import-Module AppvClient
if($args.Count -ne 2) {
	$action = Read-Host "App-V app to launch into (type 'list' for a list of apps):"

	while($action -eq "list") {
		$apps = Get-AppvClientPackage
		foreach($i in $apps){ $i.Name }
		$action = Read-Host "App-V app to launch into (type 'list' for a list of apps):"
	}

	try {
		$apps = Get-AppvClientPackage $action
	}
	catch {
		Write-Host ("Failed to get App-V package with the following error: "+$_)
	}

	$strCmd = Read-Host "Local app to launch into VE:"

	try {
		Start-AppvVirtualProcess -AppvClientObject $app -FilePath $strCmd
	}
	catch {
		Write-Host ("Failed to launch VE with following error: "+$_)
	}
}else{
	$app = Get-AppvClientPackage $args[0]
	Start-AppvVirtualProcess -AppvClientObject $app -FilePath $args[1]
}

Usage:

  1. Prompt-mode: AppV-Launcher.ps1
  2. CMDLine Mode: AppV-Launcher.ps1 TortoiseHg C:\Windows\Notepad.exe

Note: The arguments are positional, so it must be Virtual App then Local Executable in that order otherwise it will fail. There is no try/catch on the CMDLine mode as it expects you to know what you are doing (and want as much information about what went wrong as possible) and there is no risk of damage.

App-V 5.0: Package Conversion Script

A quick PowerShell script with logging to convert a directory full of App-V packages.

$src = "<source path>\"
$dst = "<destination path>"
$logdir = "<logfile location>\ConversionLog.txt"
Import-Module AppvPkgConverter
$list = dir $src|where {$_.mode -match "d"}
If((Test-Path $logdir) -eq $false)
{
	New-Item($logdir) -Type File
}
foreach($i in $list)
{
	Write-Host $src$i
	$conv = ConvertFrom-AppvLegacyPackage -SourcePath $src$i -DestinationPath $dst
	If($conv.Error -ne $null -or $conv.Warnings -ne $null)
	{
		Add-Content -Path $logdir -Value ($conv.Source+" appears to have failed...`n")
		Add-Content -Path $logdir -Value ("Error: "+$conv.Errors+"`nWarning: "+$conv.Warnings+"`n")
	}elseif($conv.Information -ne $null){
		Add-Content $logdir $conv.Information"`n"
	}else{
		Add-Content -Path $logdir -Value ($conv.Source + " completed ok, no Errors or Warnings...`n")
	}
}

Speaking Of Things Nobody Tested...

Confirmed this with a few people now.

If you have a sequence, and you update it, and then say, you delete the _2.sft after making a _3.sft (because why have them all lying around wasting space) and you open the sequence, make another changer, then save it. You will get a _2.sft 90% of the time.

Which when put into the console will say it's not the right version lineage.

Thereby giving you the choice of keeping all your SFT's around, forever, or jumping through a bunch of hoops trying to get it back into a correct lineage (like, say, dumping the entire app out of the console and reimporting it, which will again 90% of the time give you all kinds of problems because the clients will see they aren't supposed to have it, but do have it, but it's the wrong version, so the only way to fix it is to manually runn SFTMIME commands on each machine to clear it out).

Let's call it what it is.

Really poor software. In no way, shape, or form acceptable for a paid product from one of the largest software companies on the planet.

PowerShell: Get command definition.

With 5.0 being so PowerShell friendly, if you spend a decent amount of time in the shell you probably noticed that the definition of commands tends to get truncated when you, say Get-Command Test-LegacyAppVPackage. Which returns something like this (apologies for the horrible formatting to follow):


CommandType	Name					Definition
-----------	----					----------
Cmdlet		Test-LegacyAppvPackage	Test-LegacyAppvPackage [-Source] <String[]> [-Ve...

CommandType	Name					Definition
-----------	----					----------
Cmdlet		Test-LegacyAppvPackage	Test-LegacyAppvPackage [-Source] <String[]> [-Ve...

You might find this trick handy (and for more than just this if you are clever).

$(Get-Command Test-LegacyAppVPackage).Definition

Which returns something like this:

Test-LegacyAppvPackage [-Source] <String[]> [-Verbose] [-Debug] [-ErrorAction <ActionPreference>] [-WarningAction <Acti

onPreference>] [-ErrorVariable <String>] [-WarningVariable <String>] [-OutVariable <String>] [-OutBuffer <Int32>]

Much better...

App-V 5.0 Beta, out now.

In case you haven't seen it the 5.0 beta is live.

App-V Error: 00000002

Quicky post on a common App-V error code.

If you've gotten to the point where you can view the sftlog (C:\ProgramData\Microsoft\Application Virtualization Client\sftlog.txt) and see this entry then most likely the problem is with the CODEBASE line, specifically the HREF element. Make sure it is set tot he right protocol (FILE, RTSP, RTSPS, HTTP or HTTPS), the right server (either %SFT_SOFTGRIDSERVER% or the hardcoded servername) and the correct port (80, 322, 554 etc.).

App-V: PrimalScript 2011

Pretty straightforward on this one. But a couple steps you need to take beforehand. First, download the following:

VC++ 2k8 SP1 Redist (x86)

VC++ 2k8 SP1 Redist (x64)

Install both of these on your clean Sequencer, when it comes time to install PrimalScript (you should already know how to get to this point) set the install directory to the folder on your Q: drive, choose Complete and uncheck the two VC++ 2k8 options. The rest of the install should go pretty smooth.

The only oddness I saw with the sequence (after the basic cleanup) was the first launch it PowerShell.exe hung (I may have been impatient) and I had to enter the serial # twice, which may have been residual issues from the first launch. Haven't been able to reproduce it yet.

App-V: Error Code 0000C800 (Update)

I have a previous post about this particular error here, but a recent App-V Blog entry reminded me to post the other (though not nearly AS common if your DBA's aren't asleep) solution.

Catch that over here.

Cause

This can occur if TCP/IP is disabled in SQL Server Configuration Manager under SQL Server Network Configuration on the App-V Database SQL Server.

Resolution

On the SQL Server where the App-V Database resides, launch SQL Server Configuration Manager, navigate and expand the SQL Server Network Configuration node and enable the TCP/IP protocol on the SQL instance that hosts the App-V Database.

Also, sorry for the lack of updates lately, been working on some other non-App-V, non-XenServer (though still mostly Xen) stuff.

App-V: Feature Request.

I hope in the future they restrict checking for new updates to ONLY happen when a component of an application isn't already open.

I understand how it might seem like a good idea to have it check everytime, but when it is not capable of ignoring dependencies for something already running it makes it a really bad idea.

That you EVER see an error saying two applications in the same package cannot be opened with diffierent configurations is all proof you should need of that. It means more manual management and third party solutions to update certain types of apps (namely anything with more than one app).

Now if only they made it easy to get feedback to their engineers without opening paid-support tickets...

App-V: Clearing the cache...the hard way.

Ever cleared an application only to find it didn't delete everything? Clearing something from ProgramData is no big deal as this can be done fairly easily by anything running as the system account (SCCM for example). Clearing a users profile is another story.

If you have used a command prompt much at all then 'rmdir' is nothing new to you. What you may not realize is that rmdir isn't an executable, it's a command. So in this case calling "rmdir" in an SCCM package will net an unusable package. The workaround is thus:

%COMSPEC% /c rmdir /q /s "%USERPROFILE%\AppData\Local\SoftGrid Client\<FolderName>"

Put this in SCCM, set it to run as user, and it should clear the folder just fine.

In this case, to clear an app I used something along the same lines as what I use to clear office.

 

sftmime.exe CLEAR APP:"<AppName>" /LOG "C:\InstallLogs\Clear.log"
Run %COMSPEC% package.
sftmime.exe DELETE PACKAGE:"{<PackageName}" /LOG "C:\InstallLogs\Delete.log"
sftmime.exe REFRESH SERVER:<ServerName> /LOG "C:\InstallLogs\Refresh.log"

Set the programs each to Start In: C:\Program Files (x86)\Microsoft Application Virtualization Client

Clear app can be done as admin or user, user gives the best chance of it clearing the folder you are trying to delete, but if the user doesn't have clear permissions this will fail (default permissions should be to allow a Clear if I recall).

Deleting the package is again a case of rights, most likely you will want to run this as admin so it deletes it globally and you are assured permissions to do so.

Refresh should be run as the user so the USER contacts the publishing server to retrieve their software.

In this case the reason for the refresh is because an application was updated and the update pulled down the new OSD but failed to pull down the updated SFT, which left it in a non-functional state. I still want the user to have the application and not need them to log off so I clear it, delete the folder, delete the app, then refresh the publishing server so they get their app back seamlessly.

Thanks to Justin for the tweak to make this work with SCCM.

App-V: Firefox 8

Was about to put up a whole guide on FF8 when I saw Aaron Parker put a guide up of his own. No point in re-inventing the wheel so I'll just point over in that direction.

Hasn't really changed much since the FF5 stuff I posted on the official forum and what was already out at the time, so it's largely mroe of the same.

One thing I did want to mention though which applies in general to more than just Firefox is how to handle swapping out applications like this.

For a few reasons I wont get into I decided to sequence this as a new app and not an upgrade to version 5. This causes an interesting issue. How do I remove version 5? If I just strip the permissions and delete it then anyone who tried to launch it between now and their next reboot will effectively not have Firefox.

What you want to do is slowly get rid of it. The best way I have found is to add Firefox 8 to the AVS, then goto the Firefox 5 Application Group and disable the shortcuts.

What this will do is LEAVE Firefox 5 working and intact for everyone who has it, but when they next reboot or log off/on the shortcuts will go away and the shortcut for 8 (which appears to have moved to the root of Programs btw) will come down.

After a span of time that seems to provide a reasonable likelihood that everyone who uses 5 has rebooted or relogged (3 months, 6 months, depends on the size and type of your company, if it's small enough maybe a month, if you force a reboot via something like SCCM, you can control it, but I'm trying to do this as "in the background" as possible) you can remove Firefox 5 from AVS all together.

App-V: Office 2010 w/Lync Step By Step.

This isn't the most rudimentary of guides, as you will need to have some idea what things mean (like that set LOCAL_INTERACTION_ALLOWED means to change it to true in the OSD tab for every application).

But this is about as streamlined as I can get it, without making any un-needed changes to the sequence.

Office 2010 Step-by-Step.

App-V: Clear cache on Citrix.

Ran into a problem where I could NOT get app-v to clear the cache properly on a citrix server.

Set: HKLM\Software\Wow6432Node\Microsoft\SoftGrid\4.5\AppFS\State = 0

Delete all the OSD's in: C:\ProgramData\Microsoft\Application Virtualization Client\SoftGrid Client\OSD Cache

Stop the Application Virtualization Client Agent service (this is a dependant service to say Yes when it asks to shut down the parent service). Note that if you have the client console open at the time (or any apps) you will get a connection error, this is harmless, it's just telling you that, well, you stopped the service and it cannot connect.

Open the client console, refresh the publishing server. Problem should be solved.

A pretty common indicator that an application is stuck in the cache is Error #: 00001004

If you see that error, you probably have some OSD's hung up in the cache. If this STILL doesn't resolve it, make sure that in the user profile(s, if you aren't doing mandatory profiles) the OSD caches are cleared as well. That SHOULDN'T be an issue, it's usually the machine cache that fails to be cleaned up properly.

App-V: Excel 2010, DDE, and variations on installation type.

Here is a fun one.

If you  are like me you've had some VERY sketchy results with Office and DDE. There are several bits of information floating around about this and here is my updated current understanding of the issue.

During installation of App-V 4.6 (in this case SP1, not sure if the same applies to RTM) the following keys are written with different values based on, apparently, the type of method used to deploy the client.

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\SoftGrid\4.5\Client\UserInterface\DDELaunchCommand

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\SoftGrid\4.5\Client\UserInterface\DDELaunchMSICommand

When delivered via SCCM as part of a task sequence during an SD deployment DDELaunchCommand points to sfftray.exe and not sftdde.exe, and there is a different string for the MSI launch command as well.

Strangely, taking office 2010 as an example, word used to require ADDING DDE or it would present a "problem sending command to program" error, then at some point it stopped being broken.

Then, Excel stopped working with DDE, the most common search results provided a fruitless suggestion to disable the "Ignore other applications DDE" that doesn't appear to be checked by default in 2010 anymore.

The problem with this is that stripping DDE from the FTA's for excel fixes double clicking on a file locally or on a network share, but when launching a spreadsheet via SharePoint you get an error saying '%*.xslx" could not be found.

Uninstalling and reinstalling the client WILL fix this in almost every case (just make sure to reboot after the uninstall, even if it doesn't prompt you) but the idea is to fix the client for in-production machines.

The default values for SP1 for those two keys are as follows:

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\SoftGrid\4.5\Client\UserInterface]
"DDELaunchMSICommand"="-0Ej4Sf'k=UZDv3uJ4{IRelease_Merge_Modules>OO5hSGuIH?xoVn&wQ(Ex \"<APP>\" <DDE>"
"DDELaunchCommand"="\"C:\\Program Files (x86)\\Microsoft Application Virtualization Client\\sftdde.exe\" \"<APP>\" <DDE>"
This is from a Win7x64 machine with App-V 4.6 SP1 (no HF's applied).