App-V 5: Collect icons for XenApp 6 publishing.
Quick script you can run on a machine that will look at any app-v app cached on that machine and collect the icon file for it and spit it out into a structured directory.
Click here for the script.
Quick script you can run on a machine that will look at any app-v app cached on that machine and collect the icon file for it and spit it out into a structured directory.
Click here for the script.
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:
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.
A script to connect to the App-V DB and find what all software is assigned to a particular user or group.
All the instructions you should need are in the script itself.
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") } }
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.
Along with this and the bug that is STILL in 4.6 SP1 where it reverts to "generate MSI" being checked everytime I can only say I hope they abandoned (there is no other word for it) 4.6 in the hopes of making 5.0 something that is actually ethical to charge people for.
That being said, IF you have version 1 of your package you may have reasonable success with attempting the following:
Add Version 1 to the App-V server, then add the newly created _2.sft package, then remove the version 3, or 4 or whatever version you are up to.
Past that though, you can't delete Version 1 or you will have the problem again, you can't delete it in your backup repo because, again, you will have the problem.
You will need one copy of ever _sft generated or risk running into a problem where you can no longer update the chain.
One more quick follow up.
I found a fairly consistent way of getting them back on track seems to be opening them in AVE (which can be found over at Gridmetric) saving them, and then opening them in the sequencer, if I had more time (or when I get more time) I would go through the XML and SPRJ and figure out which field isn't set correctly and manually "fix" it. For now, if you have AVE, it seems to work for the couple of us who have tried.
This is what happens when you don't bother to use your own software.
Maybe they used Windows 8 and thought "hey, we better start switching to Linux."
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...
If you are looking for a log file for the App-V 5.0 beta you have probably gone through the Admin Guide to no avail. Thankfully they are using event logging now. For some reason this is listed under the sequencer section of the Admin Guide but not the client.
Simple PS script to add a publishing server.
Import-Module AppVClient Add-AppvPublishingServer -Name <name> -Url http://<hostname>:<port>
MUCH better so far microsoft, MUCH better. Now it just needs to be reliable (something you can't really judge with a beta).
In case you haven't seen it the 5.0 beta is live.
An interesting change...does this mean since they plan to EOL XP soon they are officially dropping support for it in App-V? Wouldn't be surprising. Also like that "any OS" is now the default.
And quite possibly the nicest addition to the sequencer so far...
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.).
Pretty straightforward on this one. But a couple steps you need to take beforehand. First, download the following:
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.
First update: The oddness WAS caused by my impatience with it's initial load. :sheepish:
Second: This same thing applies to the new 2012 batch of all these apps, just install the redists first, select custom blah blah blah.
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.
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...
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.
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.
Little birdie mentioned that there will supposedly be a completely re-written App-V Server coming maybe around Summer 2012.
Can't really say who or what, and I may have missed the memo that made this obvious, but here's hoping for a PROPER server, with actual admin features.
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.
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.
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>"
Ok, so I sadly do not have nearly enough time to really get to the bottom of this so the following is pure speculation.
I THINK the difference in this case between Excel and, say, Word is that Excel seems to be tripping a MSI self-repair check, it's blink-and-you'll-miss-it fast but I THINK the MSIDDELaunchComand not being fixed was why just changing DDELaunchCommand didn't solve the problem.
Something doesn't set right with me about that but the net result is, setting both keys correctly, works.
REALLY love to hear the excuse for why this happens.