Been asked this a lot lately.
This error most likely means you have the wrong OS type specified. You can leave the supported OS blank and it will run on any platform. Which can be helpful if you have control over who gets the App-V client to begin with.
I think I alluded to this problem either here or on the official forums, but there is a slight hiccup when trying to swap out new streams for something that has items that run in Startup. Namely, it doesn't work.
The problem exists because, big shock here, an oversight in the way App-V works. How it SHOULD work is, if set to refresh the server On Login, it halts software launches until it's software inventory cycle is completed and then proceeds to load whatever applications are still valid. What it ACTUALLY does is goes ahead and lets the apps launch, completes its cycle, removing the old app and importing the new one, but because the application is locked it ends up leaving the client in a state where until the NEW product is cleared it wont work.
The Scenario: Rolling out Office 2010, we don't want to be in a jam if we ever need to re-sequence Office 2010, in case a req. change occurs, or, whatever reason.
The Solution: Use SCCM to run the following commands. Note that the collection needs to contain MACHINES and not users, as it needs to perform operations regardless of machine state.
SFTMIME UNPUBLISH PACKAGE:<packagename> /GLOBAL /LOG <pathname>
SCCM reboots machine
SFTMIME DELETE PACKAGE:<packagename> /GLOBAL /LOG <pathname>
SFTMIME REFRESH SERVER<servername> /LOG <pathname>
C:\Windows\System32\timeout.exe 300
SFTMIME LOAD PACKAGE:<packagename> /LOG <pathname>
Breakdown: The initial UNPUBLISH doesn't do much, it SHOULD unpublish the package but the main problem here is that if a user is logged in, it's probably in use, this is mostly to provide SCCM an entry point to reboot the machine. You could run shutdown -r -t 1 instead and set the package to "package reboots machine" instead of "SCCM reboots machine" but honestly it feels like six of one, half a dozen of the other.
The second command DELETES the package off the machine when the computer comes back up, before a user can log in and put the package into an "in use" state.
The we refresh the server, pause for 5 minutes to make sure the refresh completes, and then load the package. The reason for this is to control the deployment. I can run this at a maint. window when I know network traffic will be light instead of waiting for monday morning and praying I don't get unlucky. This way too by the time they show up monday they shouldn't see anything. In our case AppSense will carry over their account information and settings so if the package is already cached there should be no way, other than the reboot, for the user to tell something happened.
In the case of laptop users or users who don't leave their machine on, they merely have to wait the first time they power on/connect for the SCCM package to arrive and run.
None of this is anywhere NEAR as ideal as the client being intelligent enough to not step on it's own toes, but so far it's been working. I don't anticipate this being an every day affair (hopefuly it's very rare), but we were not comfortable using it until we were sure we wouldn't be locked into using the same sequence for the lifetime of Office 2010.
After a bit of testing it appears you MAY not need to use machines in the collection after all, as if it is working properly the machine will have received the entire package chain and once it is done rebooting should have the remainder of the advertised packages queued up to run.
SFTMIME.EXE is one of the two primary command line utilities you will find yourself using to programattically control App-V. SFTTRAY.EXE being the other.
SFTMIME's main purpose is controlling the client, as where SFTTRAY's main purpose is launching applications. It goes beyond that but in a nutshell those are their jobs.
One problem you may see with SFTMIME is a lack of response. In this instance REFRESH SERVER, when when used with /log provides no response unless there is an error. Most people go into the Client Console and refresh to see if the server status changes to "Ongoing", and if it doesn't change assume it didn't work. The only way to ensure it kicked off a refresh is to check C:\ProgramData\Microsoft\Application Virtualizaton Client\sftlog.txt
If you see it cycling in the log, you know it worked. This doesn't do wonder for programattically checking, as even looking at the modified date of sftlo.txt doesn't tell you anything other than SOMETHING happened. You have to actually parse the log file to get a clear result.
If you intend to run SFTMIME via scripts or something like SCCM don't forget to specify /LOG <pathname> otherwise if it fails, you are left to scratch your head and wonder why.
Since most of the old bugs are patched the most common cause I've seen for this is having a special character in the package name. For instance:
Notepad++ 4
C++ 2008 x86 SP1
etc. etc.
It is important to note that the sequencer will not save you from yourself. If it isn't a letter, number or period (.), don't use it. It will save you a lot of trouble in the long run.
Had a really fun occurence, sequencing Office 2010 I found when I put it into the staging environment that none of the FTA shortcuts existed.
Sadly due to project deadlines I cannot tell you WHY it suddenly opted not to capture those shortcuts, but I can give you a dirty fix.
If you have an old copy of Office 2010 sequenced with working shortcuts, copy them all over to the Icons folder under your new sequence, 99.9% chance they will all the named correctly, and your problem solved.
My suspiscion is that with Lync and UC and IronPort in the sequence, I really do think this is just approaching the limit of complexity that App-V can happen. I can sequence Office 2010 by itself in 25 minutes (including SP1 and the Aug. CU's) all day long, the slowest part is the LOCAL_INTERACTION_ALLOWED, but I can do it reliably.
With these four included? It gets VERY spotty. I can do it three times over and get three different results, one might work.
So if you don't have an old copy lying around try doing as vanilla a sequence as possible (don't worry about the local interaction or version syncing, you are just after the icons) and use them to fix your working, complex, version.
This post is a little different, it isn't a tip, trick or solution. This is a commentary on App-V, specifically a couple of it's more irksome qualities as regards enterprise use.
The Scenario:
You have Office 2010 deployed, it's been a year, your patches are starting to accumulate, something goes wrong or a new configuration is needed (maybe you didn't include Access and now you need to). Whatever the case you are left with one real option, re-sequencing.
In and of itself this isn't a major issue, re-sequencing office (if you've done it as many times as I have) is, monotonous but not too taxing. But know you are left with a problem. How to cleanly get Office 2010 to the masses.
The Problem(s):
The first problem is the ADK, notoriously finicky, with a flat out awful installer. If you have a background in repackaging software into MSI's you will be appalled to see how kludgy it is, and how many things are hardcoded. The fact that you cannot even use a transform tells you something, and MSI's are M-S technology, see it right there in the name? M-S-I...continuing the long, not so proud, tradition of MS being one of the worst abusers of it's own technology.
They give you very little useful information about the nuts and bolts functionality of the ADK and opt instead for a birds eye view of "understanding proxies". End of the day this part of the problem SEEMS solved easily enough by changing 8 registry keys in: HKLM\SOFTWARE\Wow6432Node\Microsoft\Office\14.0\CVH
How you change them is another story. You can try using GPO, but it is about as reliable as GPO's usually are. You can try using AppSense Env. Manager, which is only marginaly more reliable than GPO if it's in a bad mood. You can run an MSI or WiseScript or other method via SCCM, but then you are stuck waiting for it to go down to the machine and there will innevitably be issues with users who have gotten the fix and some who haven't yet, so some portion of the population will be without working proxies.
And now we get to the real problem. The pointlessness of GUID's in App-V and the lack of segregation of data.
To start with the first point, GUID's being useless, you have to understand that App-V does not store things intelligently. It relies heavily on plain text files, OSD's, SPRJ's, even SPRT's are all XML files, and that is great and fine as an open method of transfer. As a data store it's flat out awful. There is no intelligence to it, no normalization, a lot of small file parsing, they could have used the registry to better effect! And that's saying something, something bad. But the real problem lies in HOW it organizes the data, not how it transmits it.
If you've used App-V for very long at all you have undoubtedly realized that no two applications of the same name and version can be either in the App-V server or client. Why bother having this limitations when you have GUID's? You can say it's a design choice and it's subjective as to whether it was right or wrong, but the truth of the matter is, it's a needless restriction.
Take for instance Adobe applications. Oh how they love Adobe Bridge, and Extension Manager, and the oh-so-annoying Air that seems to install no matter how many boxes you tick saying not to.
If I sequence DreamWeaver, Flash Pro and Fireworks I WILL have three versions of Air, three of Extension Manager and three of Bridge. I can't sequence them seperately because a) that is a lot of added work for no reason, b) they behave horribly when attempting to make three different Adobe apps share the same suited sequence c) it adds a lot of uncharted overhead to managing App-V, someone has to write down "oh and if the user gets dreamweaver they also need Bridge, Air and ExManager" and then if one updates the others need to update.
Essentially as it is right now the datastore looks something like this:
----Root
--------Application 1
--------Application 2
--------Application 3
xxxxxxApplication 4
--------Application 4
--------Application 5
Everything is under the root, and the primary ID is the app name/version. Worse still is FTA's, where EVERY FTA controlled by any application is grouped together in one big lump. On the server it CAN be seen by application but not in an intelligent way, instead of doing it like they do in the sequencer, where it's hived out under the individual application (which is still an EPIC pain if you are trying to find out what took over a specific FTA as there is no search, you either go through the main list with thousands upon thousands of entries, or you go app by app, having the data in two places makes no sense, it's an option you use when building in a simple search ability seems, I don't know, too hard, not worth it, overlooked).
Why doesn't it look like this?
----Root
--------GUID
------------Air 1.0
----------------FTA
----------------FTA
----------------FTA
------------Bridge 1.0
----------------FTA
------------ExMgr 1.0
----------------FTA
----------------FTA
--------GUID
------------Air 1.0
----------------FTA
----------------FTA
----------------FTA
------------Bridge 1.0
----------------FTA
------------ExMgr 1.0
----------------FTA
----------------FTA
Problem solved, no conflicts, no issues...well, you didn't think we'd get off that easy did you? FTA's are the next problem. There is no way to set an applications FTA priority. For instance if I have Dreamweaver CS4 and Dreamweaver CS5 both on my machine (something App-V kindly makes doable) I have no way of telling App-V to ignore CS4's FTA's in favor of CS5's. Sure I can strip the FTA's off the machine, but unless I prevent them from refreshing (kind of a problem) the next time they refresh, back come the FTA's. I could take them off the server, but if I have some users licensed for CS4 and some for CS5 I will be leaving all the CS4 users without FTA's.
I appreciate the simplicity of App-V's console, it spares you a great many of the needlessly complicated and hidden problems of, say, SCCM, but it's a bit TOO spartan, and lacks any real sense of organization.
So lets go back to Office 2010.
Even I sequence it with a different version (say 14.0.4756.1000 instead of 14.0.4755.1000), which WILL let me have two versions of Office 2010 in App-V at the same time, I now have to change the regkeys before a person could be switched over. So if I take, say, 100 users, put them in a transition group and assign an SCCM package to run to update their registry keys, I have no way of ensuring it happens at a specific time, at best I can run it overnight and hope they all complete timely (and nobody is on a laptop off the network).
But even this doesn't work because doing this wreaks holy hell and havoc with the FTA's, the most noticeable of which are "Could not send command to program" and a lot of missing icons on Office file types.
So even if I use a pre-launch script in the OSD to change the regkeys, I'm still in a lurch.
Oh and making it worse still is that if you have any of the components in Startup (which their own prescriptive guidance and another KB tell you to put MSOCache and the Sharepoint Proxy in startup, and most users wants Communicator/Lync in startup) the odds of it CORRECTLY polling the server and swapping out the old version for the new is slim at best, on average it takes us four reboots before it will finally be timed right and discard the old version. That is ridiculous.
So now you have to write something that shuts down App-V, as you can't shut down JUST the office components because even though you CAN tell what apps are running virtual you cannot easily (at all?) tell what apps are running in what environment. So if a user manages to get IE or Explorer hooked into you have no way of knowing. Once App-V is shut down programatically delete the package using SFTMIME.EXE and THEN refresh the server toget the new package.
All because there is absolutely no collision prevention in a platform that's entire purpose is to eliminate support costs, make software conflicts a thing of the past, and more intelligently manage your software. Yet it lacks basic organization and control functionality.
It is for reasons like this that I get SO frustrated when I see things like 4.6 SP1 come out, where they make the easiest part of sequencing more convoluted but, I guess, easier to people who PROBABLY shouldn't be sequencing to begin with (I'm sorry but if it made the difference for you, you probably shouldn't be doing it professionally) and more cumbersome for the more advanced users. While introducing plenty of frankly inexcusable bugs (can't set settings without exporting them as a template because it triggers a New Project, which now means you cannot use them with accelerators because the two aren't supported together).
I was once told by one of the App-V people that they had to make choices between "released in time to be relevant" and "perfect". My sincere response to them is that App-V is not relevant, nor are any of their competitors yet, nor would fixing these problems make it perfect. And 4.6 SP1 did not go in either of those directions, it was just a pointless and tangential side trip, wasting time they could have been using to make some of these fundamental changes.
My biggest concern about App-V? Whether or not the people who use it know enough about what is wrong to have any idea how to fix it. Right now, it doesn't seem like they do.
/rant
Here is a really fun one, made ten times worse by Ciscos complete and UTTER lack of interest in helping their customers out AT ALL.
A quick opinion here: STEER CLEAR of Cisco. Their support is notorious for being a joke, if they have an excuse to tell you to take a hike, they will do exactly that. Their software is poorly written, pathetically supported, and just generally not worth much. And no matter how many millions of dollars you just handed them they wont lift a finger to help you with a problem they KNOW the solution to (or imply they do) and would have been easily solvable by any one of the developers in an INCREDIBLY short period of time.
Avoid Cisco at all cost.
Now, on to the show.
This one gets a little hairy in that when you sequence CUCIMOC (the not so short name for the atrociously long "TM" included product mentioned in the header) and try to launch it on a client machine you get an error saying an unhandled exception has occured. Dig through the poorly laid out and nearly useless PRT result log and you find it is because the listening port of 44442 cannot be accessed. The full error is in the report but the net result is...it doesn't work.
In order to solve this problem you need one key thing from the CUCIMOC installer. NewBinary24. This is a binary (and this is poor form because all it seems to do is run netsh, this just seems to obfuscate the exact tasks) that uses netsh to reserve ports and quite possibly register listening ports for the CUCIMOC plugin. Without these being setup (and the sequencer fails to capture them) you will get the, as intended by MS, error that it doesn't have rights.
In my case I used Wise Package Studio 7, clicked on Setup Editor at the bottom of the Windows Installer Editor (after loading the MSI of course), clicked Tables, then on the Binary table, found NewBinary24, double clicked on the data field (sometimes takes three clicks) and wrote the contents out to c:\cisco.dll
On the target machine you then copy the cisco.dll to wherever, in this case c:\ and open an elevated command prompt (this can all obviously be automated by either a WiseScript or MSI and deployed via the task sequence or SCCM deliverable) and type the following:
RunDLL32 c:\cisco.dll, _netshOperations@4
This will call the DLL with the "_netshOperations@4" entry point and perform the functions from the install that were not captured, as the name implies this just runs netsh commands, it's hard to tell how many but there are at least 6 (which is why simply trying to reserve the 44442 port and setup the listener on 0.0.0.0:44442 didn't solve the problem, even though doing so didn't cause the PRT to move on to the next error, which leads me to believe the specific netsh command is not the obvious).
I've verified on a VM three times now that before running this DLL I get an error, and after, it works. This is a TREMENDOUS boon as if you intend to use this software with MOC 2007 then you know that MOC2007 has poorly thought out two-way communication with Outlook, which means you need to sequence the two together, well if you need the UC plugin for cisco you are stuck either taking ALL of office out of App-V, breaking the MOC integration (which is a bigger inconvenience than the ones added by UC) or ditching the UC plugin altogether.
Hope this helps!
Oh also there is a cert in the installer too that if you've gone this far you should be able to find (you can get it and the cdpinstaller.exe in the common files\cisco systems subfolder. I haven't determined yet if it is needed but...if so, it's in there, and the command line is in the MSI. Might as well post it I guess.
certmgr.exe -add -all "CDPCert.cer" -s -r localMachine trustedpublisher
I would include some of these files but who the heck knows how annoyed that might make cisco. If you have specific problems you can post below and I'll do my best to get you through.
The app itself is pretty simple and straightforward, however the way they add the plugin (you have to launch the WebEx Settings app and login to a webex site, and THEN it adds the plugin) is goofy and I could not get the sequencer to pick it up to save my life. The solution is fairly simple.
Windows Registry Editor Version 5.00[HKEY_CURRENT_USER\Software\Microsoft\Office\Outlook\Addins\WebExOI.Addin]"CommandLineSafe"=dword:00000000"Description"="ATLCOM Outlook Addin""FriendlyName"="WebEx Productivity Tools""LoadBehavior"=dword:00000003
Seen this a couple times.
The solution is very simple. Remeber to install the .Net 4.0 Full and the patch.
Just a quick update to point out a couple things that need to be added to the VS2010 recipe.
When creating the exclusion list add the following:
%CSIDL_WINDOWS%\Installer, VFS
Also convert all teh registry operations into command line behaviors. Create a .reg file for the IEXPLORE.EXE step (encapsulate it in quotes like the guide says then export the key to a .reg file), then while monitoring use the Run button to "run" the .reg file and add the key to the registry.
Use "reg add" and "reg delete" for the other registry operations. Make sure to call these from an elevated command prompt.
And finally save the sequence to the local drive and not a network location, as doing so has created instability for several people I now who have sequenced this.
Everytime you see some variant of the following explaining some random, erroneous, or just plain silly App-V behavior...take a drink.
This behavior is by design.
Adding a script to an App-V package is all fine and good (even though it doesn't support anything beyond batch file era scripting languages) but if your script consists of multiple lines and you are adding it after the fact (especially for testing purposes) you may very well find it likes to butcher the script, condensing it all down to one long line.
The solution is very simple.
\r\n
Put that at the end of each line. It is the equivalent of a carriage return (enter...ish), and a new-line.
Is this a bit duct-tapey? Why yes, yes it is. But I suppose pointlessly "enhancing" the UI is a lot more important than making a sophisticated product, so get used to duct taping App-V together.
Along with the other information floating around I have also found that if you install the App-V server on a different server than the SQL DB is hosted you need to ensure you have delegation enabled on that machine.
Failure to do so will result in the username/password that you connect to the server with being lost on the next hop to the SQL server. The resulting Access Denied will be a result of the SQL server, not the AVS, denying access to what is essentially an anonymous NT Authority account.
Not exactly hard to find information, but there is a reason I called it The Collection...
Insert this into the OSD of the offending app, once CMD runs, execute procmon (which you will obviously need to download to the machine) and close the command prompt, the app will then proceed to load and, presumably, error as usual, while procmon watches.
<SCRIPT EVENT="LAUNCH" TIMING="PRE" PROTECT="FALSE" WAIT="TRUE" TIMEOUT="0"> <SCRIPTBODY>cmd.exe</SCRIPTBODY>
</SCRIPT>
Another question I've gotten a lot lately.
The example situation I'll give is HP Service Manager, I want to create secondary sequences to suite with the main install to lay down additional .launch files (that not everyone needs).
The files in question go to: Q:\ITSM.711\profile\ServiceManager\workspace\.metadata\.plugins\org.eclipse.debug.core\.launches
As an aside this is NOT where you want your secondary sequence to go, in this case I'm monitoring to Q:\ITSMDEV
Anyway, there are two ways to do this, if I create the folder path BEFORE I start monitoring the resulting path will show up as Merge with Local. If I create it AFTER I start monitoring it will be set to Override Local.
The difference between these two is, even though the primary package is not "local", one will BLOCK everything in Q:\ITSM.711 and the other will just add its contents on top.
Now lets say I WANT to block out the Development.launch file that may already exist in the package, but I don't want to block out the entire path. You wont be able to set JUST the file but you can create everything in the path UP TO the last folder, then create the last folder during monitoring and place the new .launches inside. Just bear in mind that it will block everything in the folder, so if you want them to still have Production.launch available you will need to include that as well, not ideal in my opinion but whatever.
Doing so will save you from being forced to click every folder in the path and set it to Merge with Local, while still picking up the Override Local on the .launches folder.
Been getting this one a lot. If you click a shortcut for a sequenced app and it appears to do nothing, you have a hung sfttray.exe process that is blocking new instances. It can be kind of a crapshoot as to which one is actually blocking, but as no other apps are technically open it should be safe to end process on all instances of sfttray.exe
Most common cause is MACHINE\Software\Microsoft\Office\14.0 is not set to Merge with local.
I know what you are saying "oh but I made sure it was before I saved my sequence.
Yeah, check it again, and once you do, BE CAREFUL, make a backup and modify the setting because it likes to each your sequence.
As always make certain you make your changes on a sequencer as close to the original as possible (i.e. 4.6 RTM, not SP1) to increase your odds of success.
If you get this error when trying to double click Word documents do the following, this was taken from the App-V Forums, can't find the original author:
In the console goto File Type Associations.
Find the .doc association and right click it, then click Properties.
Click Advanced.
Click "&Open" and then click edit on the right.
Change the parameters to: /n /dde
Check Use DDE.
Change DDE Message to: [FileOpen("%1")]
Change DDE Application to: winword
Change DDE Topic to: system
Hit OK.
This should apply the same changes to .docx but check it to make sure.
If you are using Office 2010 on Win7x64 you've pobably already seen the joys of getting it sequenced correctly. Well the headaches extend down the line. And poorly written plugins are the biggest issue I've seen so far.
In this case it is the Cisco IronPort plugin for Outlook that allows users to flag messages as spam or not in conjunction with the Cisco spam filter backend.
Nearest I can tell the problem lies in the fact that if you want FULL functionality from Office 2010 you have to use the 32-bit version, the ADK doesn't have full support for the 64-bit version. And due to...it being microsoft I guess...the only way to get it working is to sequence on Win7x86. Well when you go to sequence the IronPort plugin it does NOT translate over well AT ALL. Which is fair enough, there is a reason why they suggest sequencing on the same arch/level/os as your target machines. And sequencing it on Win7x64 doesn't work because your copy of office wasn't sequenced like that.
Making matters worse Cisco is AWFUL about error messages and logs. The error message you get when launching Outlook is literally just a message that tells you to contact your admin. The admin is instructed to run the diagnostic tool, which is fine but the registry errors I got in particular look something like this:
Trying to read registry information.
Result OK.
Failed to read registry information: Outlook.Addin.Cisco
Windows.Registry.Location does not exist.
Could they have told you exactly WHAT key they tried to read? Or exactly WHAT key they couldn't find? Of course. Do they? No.
So the fact that EVERYONE using outlook gets this plugin finally convinced me to bump it to the category I am LOATHE to bump things to..."sequenced with office"
Another app with this problem is Communicator 2007. So now my patches for Office, Communicator and IronPort are now all tied to one another...but at least it works...
The alternative it to mail a brick to Cisco and ask them to politely describe what the hell is missing, or the next one doesn't come FedEx. ;p (That's the two day old migraine talking, don't actually mail bricks...it's bad for your carbon footprint.)
If you've used App-V for very long at all chances are you've discovered that it doesn't really handle applications that need admin rights with UAC prompting very well.
There are two problems, the first is the AppCompat layer, it doesn't except arguments, so you CAN right click the shortcut for an application and set it to run as admin, thinking it will run "sfttray.exe" "Application Name 1.0" as admin, but in reality it only sees sfttray.exe, meaning you just set ALL your applications to RunAsAdmin. Which if locked down now means only administrators can run appv apps, or, if you have admin rights, you've just mooted the entire point of UAC and may as well just turn it off.
The second problem is, App-V was not built with ANY real intelligence when it comes to elevation. They say it's a "design choice" but then say a design choice is their way of saying they know it can't do it yet but they didn't have enough time to fix it. I guess they were too busy introducing bugs and useless UI fixes in SP1 to bother.
So given their two "workarounds" are, well, ones flat out not a workaround because you'd have to be an idiot to do it (and even they say only do it for testing, which...makes it not a workaround) and the other involes installing one of the WORST "powertoys" I've ever used (including over 30 files you need to push locally to the machine) I finally came up with what I would call an ACTUAL workaround.
Ready?
Copy sfttray.exe, rename it to sfttrayad.exe, point your shortcut for the App-V Console or whatever else to IT and not sfttray.exe, and set the compatability to Run As Administrator.
Now anything you know needs admin rights to run simply modify the shortcut, adding "ad" to the end of "sfttray" and tada...no more right click runas, no more shift+right click if it's on your taskbar.
Dear App-V guys. I don't even really care if you can't figure out a better solution, but surely even implementing something like this (where a flag in the admin console tells the client to point to a different copy of sfttray if you specify it as needing admin rights) is better than NOTHING.