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.).
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.
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.
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.
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.
Seen this a couple times.
The solution is very simple. Remeber to install the .Net 4.0 Full and the patch.
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.
There are a few possible problems here but I find the most common is that the OSD is not pointing to either the right location, deployment method, or both.
Check the OSD's (or go in via the Sequencer if you wish, but that will typically generate a new version of the .sft, though I haven't tried in 4.6SP1, maybe that was one of the two things they got right) to ensure the correct method and location are specified.
Remember that typically speaking it will be something like:
":<port>/<appsubfolder>/<pathtosft>"
And seldom if ever:
":<port>/<pathtosft>"