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.
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.
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.
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.
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
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 use Office Communicator 2007 you are bound to find something useful in that list.