App-V: Swapping Office 2010 Streams In a Live Production Env.
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.
App-V: SFTMIME.EXE REFRESH SERVER
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.