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.
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.
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.