Software Deployment

Well I don't think I can add much. The last two client sites I was on we used Manifest isolation quite sucessfully when needed. I guess it was a result that at both sites the client decided that all their NT systems would go straight to Windows XP.

What are you using for Isolation? Arguments for or against each? (besides the obvious "Manifest isn't supported on W2K")

From a standards perspective, I'm currently not using isolation unless its confirmed that there is a requirement to do so (in the sense of .local). In the sense of using manifests, I like the angle, though I find it intriguing how much development goes full circle....

Here's the thing, I have not introduced this into standards, as yes it is available in the OS (XP), but did not equate this to mean available for all applications, and that it would work fine assuming the application adhered to the rules for non-shared resources, followed .NET standards, and contained no hard-coded .DLL calls or calls via full path that wouldn't redirected.

The question became -- how can I determine this? And I became gun shy to introduce it in standards and procedures knowing that there are many dated applications that must still be used, applications from subsidiaries and parent companies that must be used, and other applications you wish wouldn't exist. With this in the application population, I felt that potential benefit would be negated by junior level packages not knowing how to properly identify what is/isn't supported, and translate into a longer packaging process. Packaging is filled with plenty of standards, all filled with exceptions...this scenario just seemed to have too many exceptions, at least in the environment I have to work with....even knowing I will shortly only have to be concerned with XP. The simple fact that registration is pulled out the registry is reason enough to peak my interest.

From a development perspective, I would probably embrace the concept.

If there are people out there that have embraced the technology and find that in a large environment, my fears are unfounded the majority rather than the minority of the time, please speak up! I'd love to reevaluate now rather than later.

Hi cjr888,

You said:

I felt that potential benefit would be negated by junior level packages not knowing how to properly identify what is/isn't supported

How do you determine what is/isnt supported other than by testing?

Rgds

Paul

I felt that potential benefit would be negated by junior level packages not knowing how to properly identify what is/isn't supported

How do you determine what is/isnt supported other than by testing?

Not sure if you're asking or that was meant as rhetorical, but you determine what is/isn't supported by a combination of what a vendor (ie. Microsoft) tells you, and through testing. So if a base statement by a vendor implies that the majority of the time, based on your scope, that it won't be supported, then that means that the majority of the time, there's an additional step in the mix for any packager in making that determination.

An additional step means additional time in the process, which may not meant your needs in keeping to a certain SLA with tight deadlines. Any item such as this needs to take into account both your SLAs and staffing whether you like it or not.

If the statement from vendor implied the opposite -- that in general, the majority of applications should be without issue, I would probably embrace immediately.

Again, I haven't delved into a deep evaluation myself to fully assess impact and determine if an easy manner exists to determine application support from a surveying perspective, and thus something that can be automated. For example, in regard to hard coded, fully pathed .DLL calls, if I can rely purely on header information, I can automate checks for support/non-support. But I'd need to take the time to properly understand every other requirement to see how much of the other requirements can be identified in an automated manner.

Because it can be done, and because _someone_ can eyeball/analyze an install to determine support or lack there of, isn't the only requirement when including it in standards, especially if other methods support your end goals. Staff knowledge, learning curves, horrid timelines, and SLAs play just as strong a part.

If when time permits, a proper evaluation shows that my concerns are unfounded, or through feedback in this thread by others shows the same, my tune will change, but if its to be incorporated into standards, testing does need to occur to determine things...just prior to allowing its usage. If I can't provide a well documented manner to confirm/test support outside of "looks like the app works", I don't want to touch it.

My curiosity in what others are doing (and why or why not) mirrors VikingLoki's original question -- if you have feedback, please chime in! Whether it sheds light on something I haven't had the time to evaluate, or proves all of my assumptions unfounded, either way its a major help.

Hi cjr888,

Thanks! My questions wasn't rhetorical, I was curious if there were other ways of determining the success of application isolation (either through .local or .manifest) other than testing - I never throught of vendor feedback before.

I have used .manifest application isolation, though our testing usually goes:

- Packager tests the application to determine if it "looks like its working okay"

- Gets representative from the user group to verify in a test environment

- Rollout in production to a small group to test

- Sign off from the client that the application is functioning to their requirements.

Of course thats in an ideal world where SLA's don't mean you have to package and deliver in one day :)

Hope that helps somewhat

Thanks! My questions wasn't rhetorical, I was curious if there were other ways of determining the success of application isolation (either through .local or .manifest) other than testing - I never throught of vendor feedback before.

Heh, my apologies -- its not the easiest to gauge tone in writing, and you sort of get used to the pokes and prods on message boards. :-) So short story is that you somewhat have the same inquiry as the others in the thread.

When I mentioned 'vendor' I was speaking specifically in regard to Microsoft, and in regards to Windows Installer more so than specific applications. Meant to say that based on Microsoft's blurb on what's required for .NET isolation, it implied to me that less applications rather than more would meet the support guidelines.

In short, my initial reaction was -- glad its available, probably not ready to standardize from a REpackaging perspective, but certainly hope that a lot of development, who are authoring original installs embrace the concept. Frankly though, I'd be 100% satisfied if third party authored installations and applications followed general rules and guidelines established years ago.

As for speaking with vendors (applications), it never hurts to try. Some vendors have gigantic walls around support and development and good luck talking to anyone useful, others are more than willing to explain, chat, and take advise. Always best to check out every possible resource you have though....

Your testing is functional testing and pretty much all I'd have as an option at this point as well. My concern with short SLAs would be simply that people hit the 'looks like its working OK' and its not working OK or small test run, and they are back to 'do over' stage under a different philosophy. This becomes part a time concern, part a concern that they may not be in the position to troubleshoot it properly, but more than anything, if I can't say that a majority of applications will support .NET isolation and I introduce it as a standard process, it makes me look a bit silly. :-)

I honestly need to reread those requirements several times, as I'd like to see if I could write something, even partially functional to gauge support for it. Again, not sure if header information and scans of an initial .MSI for certain table information will cut it, but something to look into if that elusive free time stuff comes along.

It seems to me that the "only isolate if needed" approach may come back to haunt you. It's very true that many applications do not follow standards and cannot be isolated, but what keeps you from the following scenario?

Application A is packaged and deployed in January. Lets say it could be isolated with either .local or manifests, but there was no need for it so you didn't isolate it.

Application B is packaged in March. Turns out that it conflicts with Application A so you attempt to isolate. Then you find out Application B cannot be isolated easily, or at all.

How do you proceed?? Repackage & Redeploy App A?

I'd think the best standard to have is if an application can be isolated, it should be isolated. Down the line it will leave you more room to maneuver with apps that don't appreciate being isolated. As for the timeframe, that should be the technical manager's call. Give it "the 'ol college try" and if it exceeds the given timeframe, have a senior packager make an assessment if it is worth it to continue with the isolation effort.

The last rollout I was on we briefly experiemented with isolating all applications. We considered that to be a make work project. Isolating when needed seemed to be the most effective approach. Yes, if application A needs to be isolated after the fact there is the redeployment issue but considering all the issues we ran into trying to isolate every application I would suggest that isolating when needed is less resource intensive.

I suppose it would depend on the environment you're packaging for. You mention redeployment as if it isn't a terribly major problem. When you're packaging for a 5000+ machine environment, redeploying isn't taken lightly. You're pretty much guaranteed problems from murphy's law alone. Combine that with an environment where downtime is a problem, and having 1 person spend an extra day or two to isolate is a drop in the bucket.

Plus you don't have the problem of that person making big waves because their working application was redeployed broken. Try explaining that one to the department manager.

Well I think it has alot to do with the applications, environment size and application mix. Isolation caused more problems than it solved when we had a Wise developer suggest doing it as a part of our daily scripting operations. The environment we tried it in was a 6000 machine environment with over 450 applications. We had about six applications that actually needed isolation. The isolation broke over 10 application before we decided to do it on a as needed basis.

In contrast to that I did work for a company with 21,000 desktops and laptops with an application count just shy of 400 and we never had a situation that required application isolation. Currently I am in the middle of another rollout with an environment of just over 6000 PCs and about 350 applications. We are at about the half way point and we still have yet to find a situation where isolation is required.

I think unless you have a developers level of understanding the application's architecture there is little need to head down that road right away. I mean proper pre-piloting of your application mixes should be able to uncover 75% of your applications that require isolation. I think that is the key for a smooth application rollout is proper pre-pilot practices before you do the production rollout. I know you won't have all the resources in the world to do pilot testing but that is what the IT department is for. Let the application support professionals pilot the code before the general user community. They will be more likely to uncover the application issues and still remain productive as they uncover them. Then you don't have to deal with the overhead of fixing the entire user community. It still will happen but that is one of the evils when it comes to centralized application manegement.

over 450 applications. We had about six applications that actually needed isolation.

Wow. 450 apps and all but 6 played well with others? Count your blessings, you're in a utopia over there! That's not the case in my environment (health industry), with apps that work with only particular DLL versions and utter disrespect for anything under the windows dir. How many apps do you have that have 20 page install instructions that involve manual file copys and manually registering DLLs?

Again, it's all about the environement. Mine is large amount of horrendous apps slapped together and rushed out the door to meet FDA deadlines. Isolation is absolutely essential. I suppose if you only have 6 conflicting apps among 450, then I wouldn't bother either. Then again, I do find that hard to believe. Are you SURE they don't conflict? Is there someplace where apps actually DO follow Windows application standards?

Is there someplace where apps actually DO follow Windows application standards?

I'm only aware of three environments:
1. Whitepapers.
2. Marketing.
3. La La Land.
4. The environment you don't work in.

I'm only aware of a couple applications and situations that follow standards:
1. The release of the application that comes out three days after you retire the application.
2. Actually most applications follow Windows standards. In my environment, its just that the Window standards they follow are closer to Windows 3.1 or Windows 95 than the standards of Windows NT, 2000, or XP.

Its a bleeding-edge environment.
The only issue is that its usually me who is bleeding.

Mine is large amount of horrendous apps slapped together and rushed out the door to meet FDA deadlines.

Ouch! I've never done healthcare and maybe I should be glad. I could say that apps in telecomunications companies I have dealt with tend to play well together. Some of the worst written applications I've seen have been in oil and gas.