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.