Application Streaming executes applications whose names and icons are listed in a PROFILE. The streaming system uses the contents of an execution TARGET to run the application. I have previously written about this separation of publishing data from execution data and how it lets a single profile support multiple execution environments. For example, only one set of icons are published even if the execution platforms will be for 32 and 64 bit systems; which have different execution images (targets).
As the Targets mature, their version number increments. Users who have the application up “now” keep using the old version and users who freshly launch the application get the latest version published. Lots of details on this in this post, RADE => Rapid Application DElivery. This is what allows the application to be updated HOT.
What is often glossed over is that it is a one way movement!
If your users are happily running on version “3” and your update the profile (Target) to get it to version “4”, your users will be moved up to version 4 the next time they run the application.
What if version 4 is “BAD”?
Officially, there is no way to “go back”. The original developers of Application Streaming failed to implement “rollback”. I was there, so first rule – everything is my fault. Just for the record though, I jumped up and down, screamed and held my breath to force the issue – and still lost. The idea was that even if you roll the targets back, there are other items to consider such as profile level changes that affect the targets; can you roll everything back?
Target Rollback is not implemented in the profiler GUI, but it can be manually achieved.
The profile and all of its targets are stored in a directory on the file/web server which is also known as the Application Hub. The top level file is filename.profile which is an XML formatted file, which is the keys to the kingdom for all of the other files for the profile and all of the files of each of the execution targets. The targets are stored inside of a CAB file, for easy transport and to provide an atomic test of “deployed” or “not deployed”. The naming of the targets is GUID_v.cab and the definition of which GUID goes for which Target is present in the profile XML data, which is stored inside the .profile.
This question has come up before. Here’s a forum post that talks about it.
I summarize it to these steps
- Copy filename.profile to filename.xml
- Favoriate XML editor, edit filename.xml (I use Visual SlickEdit).
- Tools menu, beautify, enter, enter (this is why edited as XML – syntax assist editing).
- Search for “<Ver>”
- Change the integer that is there to be the smaller number that you’re after
- copy filename.xml filename.profile
- Rollback is complete!
- No need to erase the “newer” CAB file – it may still be supporting users who are using the “BAD” version.
Things are mostly as they were and your life and users are now happy!
Immediately, new executions of applications from that profile will use the “older” Target.
NOW – What won’t work?
The editing that you did – which caused it to not work – is gone. That TARGET will be overwritten on the next save of that target inside the streaming profiler. So far, nothing will occur that seems bad. But, if you managed to edit the target fast enough, you could replace the already in use GUID_version.cab and this could heavily confuse your user community. For purposes of rollback, I assume that the user community are already standing in your office and will understand when you tell them close the app and launch it again. There could be some “left overs” in the users Cache which would be different than the next time they run that same version of the same target. Hey, it could happen – but it is really unlikely.
More stuff that can go wrong…
IF you edited the profile and stored SCRIPTS at the PROFILE level, then these scripts are GLOBAL to all of the Targets in the profile. IF the Target is set to “inherit profile level scripts”, then the new scripts will apply even if you rollback the target. Good news here, the scripts at profile level are stored in a directory on the network server (Application Hub) where you can replace them – don’t tell anyone I said to do this. You will also then have to force the scripts to be re-downloaded onto the execution machines after the update. More discussion on that here.
What really won’t work? DIGITAL SIGNATURES!
If your profile is “digitally signed”, then by changing the profile data, you have invalidated the signature and the streaming client will do its job and declare the end of the universe and otherwise refuse to run the application. The streaming profiler will (or at least probably will) allow you to load the invalid profile, fix it and save it back to get signatures in place again.
For people going “digital what”, the application streaming system uses SHA1 hashes of every file in the profile, every file in every target and an overall digital signature of the profile XML data to authenticate that the streaming content is from an approved source, e.g. you. This is optional, so if you’re not doing it, no worries.
It is also possible that Pre-Deploy could get confused – thinking it has the latest version when it doesn’t. The good news is that once you update it again, the later version will be “new” and will be brought to the execution machine. If you’re only using stream to server, this doesn’t really apply to you because deploy isn’t normally used unless you’re taking the application offline.
The fast majority of the time, target rollback will work just fine. The most common reason for rollback is that an application update was applied – and it made things worse, not better. So, providing a means to rollback the application image achieves what the admin wants; albeit with a few things to keep an eye on. It’s not in the profiler GUI, maybe it will be some day. Until then, the needed function can be achieved.