Software Deployment

The two major packaging tools, Wise package Studio and InstallShield AdminStudio, have tools for conflict management.

Nowadays, it’s a big challenge to migrate to the new operating systems without risking the Quality Assurance level. Most of the tool available in market, work to provide a solution for simple applications. But for mission or business critical applications, they don't provide a satisfactory answer to it.

By using QtestBASE, you can ensure 100% QA for all kind of applications independent of their installation art (MSI, Non-MSI). It works for both. Its done by creating a high definition Fingerprint of the Application.
You can test our free fingerprint service to check your application - it' easy and let you know how it works.

http://www.qtestbase.com/free-fingerprint/

If you require further information, please visit the website or let me know.
http://www.qtestbase.com

you could also look at App-DNA's Aptitude and ChangeBase AOK

concept is good in both tools not sure if the implementation works all that well but worth a look at.

Before going into the discussion to compare the strengths and weakness of any tool, it’s important to have a bit understanding of the methods currently used for Software Quality Assurance. In Quality assurance context, two methods are widely used namely Static and Dynamic analysis. In Static Analysis one is going to analyze the MSI File.

App-DNA's Aptitude and ChangeBASE AOK work according to Static Analysis principle. It's not possible for such tools to identify exactly the effect and behaviour of custom actions and binary calls. Because these tool only analyse the MSI file and doesn't execute the Installation Medium. Furthermore these tools are limited to MSI File format. In case of Non-MSI file, they try to convert it into MSI but in most cases it a MSI file which is only extra cover or wrapper round the original Non-MSI Installer. Furthermore they do actually on Application compatibility against a specific platform, e.g. Win-7, App-V etc. But the Application Interoperability topic is not addressed in detail by such tools.

To answer or overcome the shortcomings of Static Analysis ( Tools like Aptitude, AOK), you need another method namely Dynamic Analysis. In this approach, the application or installation medium is installed on a test client to capture the Application Fingerprint. Taking such consideration, we have developed a product QtestBASE. By using QtestBASE, you can ensure 100% QA for all kind of applications independent of their installation art (MSI, Non-MSI). It works for both.

You can test our free fingerprint service to check your application - it' easy and let you know how it works.

http://www.qtestbase.com/free-fingerprint/

If you require further information, please visit the website or let me know.

http://www.qtestbase.com

Abdus Salam

QtestBASE Product Manager

Abdus Salam,

I actually have a good hands-on experience with ChangeBase and App-dna tools.

the application or installation medium is installed on a test client to capture the Application Fingerprint
In reality you're doing rough repackaging and importing the .msi into the database?

How much TOTAL (setup+works+reports analysis) time does it take to automatically analyse about 700 applications located on one centralized network share?
vs
How much VALUE will it bring?


Thank you for the link, will probably write a report based on when I have the time to grab a look at it. ;)

Femke_NL,
Mainly as VBScab has already mentioned, there are two competitors on the market that offer what you're looking for from a perspective of a person responsible for packaging process. I'm mainly using AS, but their products are not very suitable for teams of over 15 people (and yes, I'm talking about Enterprise version, that I'm not very happy with :>).
1) I really hate the annoying import bug when your media gets corrupted and you spend more time just for "managing" their solution then you get value out of it.
2) Their support is not keeping up promises and not fixing something they promised ~2 years ago.

I did not have that much time working with Wise solution, but I do know it's getting a bit more popular judging by the customer interest.

Abdus Salam is talking about the process phase before you actually get to work with the source media files.

Hi,
In reality you're doing rough repackaging and importing the .msi into the database?
Wrong. Thats what others are doing to convert a Non-MSI file into so a called MSI file and then analyzing it. Our focus is on Physical Test to provide high level QA.

I can mention you shortly the limitations of AOK and Aptitude:

* ) Cannot identify the effect and behavior of custom actions and binary calls.
* ) Cannot identify what application is going to do in first startup after installation
* ) Only support MSI. They believe to also provide QA for Non-MSI but in most of the cases it’s simply a MSI wrapper around the original Non-MSI Installer
* ) Due to the limitation mentioned above, they have fragmented information about an application and hence the App2App Conflict Analysis is not reliable.

For more information, you may visit the http://www.qtestbase.com/features/

How much VALUE will it bring?

It depends on customer’s requirements. Taking into account the above mentioned limitations, there is always a rest risk. The official statement from both of the tool is about 5% (Actually between 5-20%). Is customer ready to accept this rest risk or he demands 100% QA?
The equation of Return on Investment or Cost-Benefit becomes much important when some business critical applications are not operational for only a short period of time. It results into countable penalty and uncountable damage to image. Is he ready to ignore it??? Only our product is going to provide 100% QA Requirements.
Furthermore our product offers Automation Solution to automate the application testing. I think it’s better to interrogate the potential conflicts at the first stage of the process as compared to the scenario when it’s not going to work in production environment.

Abdus Salam is talking about the process phase before you actually get to work with the source media files.?

Once again a misunderstanding!!!

It’s not a repacking solution. Its a tool to analyze the compatibility and interoperability issues.

* ) Cannot identify the effect and behavior of custom actions and binary calls.
They do, if you look carefully at app-dna site they even have examples of that.
* ) Cannot identify what application is going to do in first startup after installation
Yes, they can, they're doing a rough repackaging capture.
* ) Only support MSI. They believe to also provide QA for Non-MSI but in most of the cases it’s simply a MSI wrapper around the original Non-MSI Installer
Not true, both vendors now support all types of installations. ;) Check their websites.

It’s not a repacking solution. Its a tool to analyze the compatibility and interoperability issues.
I'm not stating that it is, but application packaging process is somewhat of an application compat solution itself.

Because you have a person responsible to make an application work and he will investigate all the applications he's assigned regardless of any additional tools. ;)

so is the total cost of the compatibility tool less, than time it will take for an experienced packager to go through the content of the application? ;)

To answer it in simple words - the mentioned limitation belongs to the approach namely static analysis. It doesn’t matter one is going to use Aptitude or AOK. It‘s simply not possible. They claim but they can’t.

It has been occurred in near past, that an application marked by such tool green resulted into the malfunctioning of the whole system after rollout. That’s a why I have written an article in German weekly Magazine “Computerwoche”. You may visit the English Version of this article under the following URL

http://www.qtestbase.com/uploads/media/Software_Rollout_02.pdf

Here is an important stuff / example from this article

“e.g. let’s look at a fortune 500 corporation
planning to install a relatively small new
application that automatically generates a
mail-footer - usually a quite trivial case. But
nobody considered that an ordering component
used by the distribution divisions
was also used by the mail system as a communication
component.

Fatal conflicts
Even this new combination was analyzed
prior installation, but it was unknown that
the ordering component uses a certain Dynamic
Link Library (DLL) of the MAPI
Interface that was modified by the Mail
Footer application. It had to happen what
happened: The ordering component failed
to function a week-long. In fact it was possible
to calculate the financial damage, the
image damage it caused wasn’t quantifiable.”

Can one find such issues mit AOK or Aptitude or someother tools????

so I registered and downloaded your fingerprint tool.

It has been running for over an hour on an application that is 1.5mb and it is 4% complete on a x64 i7 with 4mb of ram. If this is an expected timeframe of a reasonably high spec box I can't see this product gaining any traction in the packaging markets.

On another note, although the tool appears to check the differences between install / uninstall this is a relatively good concept. But it falls well short of any conflict management capabilities offered by a product such as Wise. Protecting uninstall is a valid cause but doing it a single application at a time completely misses the point of MSI based behaviour which is what your toolset appears to target as its core application set.

The uninstall behaviour of an application changes based on the MSI product set that is installed on the target platform. As such the analysis your tool appears to be doing against a single installer is likely to be invalidated.

I will however reserve judgement until this scan finishes whatever it may be doing. There could be more to things that I have not yet seen.

I am interested to hear from you why it takes so long though.

ok so this finally finished. As it turns out the initial timeframe was due to the base snapshot not the individual application.

however after the single application install / uninstall it created a file which was not hyperlinked so you couldn't open the file after execution.

after finding the file it was empty, the file extension was not associated to anything in particular as such it requested what application to open the file with.

so all up a pretty disappointing first attempt. Is this fingerprint tool part of a bigger toolset perhaps I am not getting the full picture here?

jmcfadyen, as I understood - the file is sent to vendor for analysis.

It's sort of a test out version. ;)

the file is sent to vendor for analysis. Without asking?!? Nice!

ORIGINAL: VBScab

the file is sent to vendor for analysis. Without asking?!? Nice!

No, you submit it yourself if you want. If you do not - they can arrange some sort of demo or conference.

ORIGINAL: jmcfadyen
after finding the file it was empty


ORIGINAL: GrGrGr
No, you submit it yourself if you want. If you do not - they can arrange some sort of demo or conference.


I think they would need to arrange a demo or conference - the empty results file won't be much use .... [;)]

Spartacus

ORIGINAL: jmcfadyen
after finding the file it was empty


The uploaded file isn’t empty and contains all the information about install or uninstalls process. Perhaps you were unable to open the file because it was encrypted. You will get till tomorrow the complete fingerprint of the application (Not mentioning the name of the installed application right at the moment [;)]).

I think they would need to arrange a demo or conference - the empty results file won't be much use ....



For Demo or Conference, of courses you can send me a mail and we can arrange it for you.

Is this fingerprint tool part of a bigger toolset perhaps I am not getting the full picture here?

Yes, you are right; QtestBASE is a product Suite and contains further modules. An important part is QtestSTUDIO. In this GUI you can see, analyse and evaluate the fingerprint. Furthermore the App2App conflict, App2All (Conflict between one selected and all other applications), App2OS(Between Application and OS) and further dimensions of the conflicts can be easily identified and solved with power of this tool.

For further info, please visit the following URL:
http://www.qtestbase.com/product/

One more note regarding it, packaging tools like WISE, Flexera, etc. do also provide conflict identification. But their target is to support packaging - means the foundation of this analysis is based on raw data collected either by MSI-Analysis or by Quick-Snapshot method. And we differentiate at this point and our focus is to capture all the changes and resulting into the generation of High Definition Fingerprint. This is the basis of all further conflict, compatibility, and interoperability analysis. It means the results are more reliable and intensive. This should not be understand as a negative argument against packaging tool but should be viewed in context of the given requirement and process.
i.e. Packaging tool main job it to support packaging and the QtestBASE aim is to provide and fulfil the high level QA requirements in any phase of the overall QA Process. And surely to fulfil it, its required intensively interrogated input to have a reliable output.

i think perhaps you don't have the full picture of the how MSI conflict management works.

You are correct in your understanding how things should be done. But as I see it the underlying windows installer technology is providing that capability already.

I am quite interested to understand exactly what your products are doing, however initial uninformed stance is that it appears to be trying to solve something that was solved years ago.

as for the application I am somewhat surprised that you know the application name (this would indicate as Ian previously stated you are getting information without prompting the user), but I am unsure why you think it is a secret. A password safe is hardly something I would be offended over.

i think perhaps you don't have the full picture of the how MSI conflict management works.


May I say that your argument itself describes the limitation ... MSI

What about Non-MSI ? Of course one can repackage it but the question is how intensive one can analyze such repackaged software with other MSI-Based analysis tool to identify the impact of custom actions or binary calls. It’s not always possible to convert each complex business application into MSI file. In such cases mostly at the end a so called MSI is created which is only a wrapper around the original native installer.
How can one analyze MSI file to identify the conflict caused by first application startup or application runtime. Further limitations have been posted earlier from me. If you like you can answer them. [;)]

The answer to those may be on marketing level “yes we can”. But we tested in our Lab and then we have this concrete statement that “Static Analysis has of course some advantages but for business critical applications where high availability is in focus, you have to turn to Dynamic Analysis approach.” Means for standard applications like Adobe, 7-Zip etc one can use further Static Analysis tool but where it is going to be complicated - you need QtestBASE.

For further details, please see the QtestBASE Whitepaper on

http://www.qtestbase.com/fileadmin/media/download/application_fingerprints_en.pdf

It’s not always possible to convert each complex business application into MSI file.That's news to a lot of the folks here.

There are a small number of apps which packagers sometimes decide NOT to package (Oracle Client being a popular cop-out) but I'm racking my brains trying to think of an app which I failed to package in the years I've been doing this nonsense.

Let me quote my words once again

It’s not always possible to convert each complex business application into MSI file. In such cases mostly at the end a so called MSI is created which is only a wrapper around the original native installer.


Yes, it’s only a wrapper.

Now you have given yourself an example Oracle installer - how can one analyze it with MSI-Analyze Tool?

And what about SAP, Java....

Are you defending here a academic point of view (Static Analyse) or a commercial Tool?

trying to think of an app which I failed to packageSAP...packaged properly
Jave (presumbaly you mean JRE)...each version is stand-alone and has no impact on other apps in terms of conflicts.

Personally, I don't wrap and I've worked with only one packager who did (and described him not as a packager but as "someone who can produce an MSI")

I'm not defending anything, really, just correcting an incorrect assertion. :-) I do, though, prefer to address conflicts before they get into an environment. That seems to me to be the correct approach. Horses, stable doors and all that...

Have taken a bit time to understand this conversation to my post. Thanks for replying.

To conclude the discussion I have downloaded AOK-Lite from ChangeBASE and Free Fingerprint from QtestBASE. Unfortunately I couldn’t find any trial or demo version of Aptitude from App-DNA. Have someone any idea?

But as Abdus Salam has multiple times mentioned the limitation of Static Anaylsis in context of Non-MSI file. I am going to test a Non-MSI application with AOK-Lite and QtestBASE Free Fingerprint.

Wait and see ... how they can help me

I had a nice post typed out and then pressed some button and *poof*...

Since I have lunch I'll repeat the short version.

Let's make the distinction between MSI-technical conflicts (component GUIDs, cyclic repairs, file versoning), Middleware conflicts (JRE, Oracle versions, though these tend to live together quite well on a system) and OS conflicts (the damn app don't work on Win7)

A number of tools are out there that cover one or more of these conflict-types in greater or lesser extent (Conflict managers in Wise/IS, App-DNA, QTestBase, Microsoft ACT), so I think it's paramount to specify which type you want to investigate and then choose an appropriate tool...

As for the 'don't package some sw, just wrap' statement. Just because it might be faster to wrap, doesn't mean you cannot package something like an Oracle (I've done it a number of times, for a number of versions, and it's actually not even all that hard if you manage to distinguish between the installer and the installation...).

just my 2c

PJ

so I think it's paramount to specify which type you want to investigate and then choose an appropriate tool...

You are right.

QA has a very huge spectrum and starts before the ordering of the software for specific a client to have a special workplace with predefined configurations, restrictions etc. and goes even beyond the rollout of the software. And here one has to understand the demand of his client and then deploy the appropriate tool. If someone is interested in readymade quick solution - then it’s also an explicit demand from the client. But if he wants support through a tool in different phases of QA - then our tool QtestBASE as a pluggable module can be used to perform the given tasks.

You can visit the following URL to see the further information and importance of the deployment of QtestBASE in context of business critical applications.

http://www.qtestbase.com/quality-assurance/business-critical-applications/

One more point, AOK or Aptitude tools required to have MSI as an input. If one is going to invest the time and resources to get SW repackaged and then is in a position to analyze. Then you have invested time and money before actually to start the analyze.

In our case, it doesn’t matter the art of the installation medium. One must not convert the installation medium in MSI with the help of an experienced packaging expert.

Perhaps it provides, more info:

http://www.qtestbase.com/quality-assurance/testing-msi-non-msi/

It’s simple, you invest the time & resource in a QA-Process at the start in the form of repackaging or start with the installation medium in hands and simply test it.

Hello Femke_NL,

I just came across your discussion - i work for ChangeBASE.

I wanted to point out that the AOK Workbench can read in any format of installer using its Convert-It module.
It can also read in the following natively:
- MSI,
- MSI wrapped in iExpress
- MST
- MSM
- MSP
- OSI
- WSI
- WSE
- REFWI
- native RADIA packages
- SFT Files
- SMS Installer files
- WinInstall Files
- Microsoft Updates/Fixes
- MSU files

The AOKLite eval doesn't include the full Convert-It functionality, but you should be able to read in the above.
I'd be interested to hear your feedback on the tool too!

Hello - I also work for ChangeBASE and am following this thread with interest. It appear that the main differentiator between tools like AOK and QtestBASE is that QtestBASE claims to do dynamic analysis. This is being discussed here:
http://www.brianmadden.com/forums/t/51200.aspx

According to the post, AOK supports some of the major installation format available. Our company is responsible for QA for the some of the big customer where high availability plays a vital role. Taking this into consideration I have following reservations to the above statement from ChangeBASE:

1) What about other formats?

2) What about the business application which have been developed over 10-years from my customer itself starting from Windows 3.x and there is no other alternative to such applications available in the market?

3) I assume that a certain Version of AOK cover some certain formats according to the current IT-Demands. But what about future? When a new technology, a new format comes. I have to purchase and test this new version for this new
format/change?

4) If I assume that AOK Converting tool can do that - then one has to accept that one doesn’t need (at least extensively) WISE or Flexera als Packaging tool.)

On the other hand, QtestBASE offers the guarantee to support current and future format by simply getting rid of it. Its simple and does make sense.

Can you look inside of a binary too? Sometimes the problem will be not inside of the msi, there are scripting standards, for that. Often with the old fashioned Software you have the real fun.

With my experience by working inside of a test environment, I see the difference between that static and dynamic testing. By leaving a gap and that´s for sure, you can not prevent everything, perhaps Software is never free of an error. That will be a given fact. But normally our topic in such a case is to minimize the possibility of an error issue. And when I get more information, then I will get a better result.

And the next part is about a business critical application. From my experiance in such a case you will allways test it, to be sure what is going on. When your company is depending on that software, then you will look after it.

Interesting comments / questions

Can you look inside of a binary too?
May I say that your question point itself to a method which can’t - if you mean by “look” just looking than it’s not the correct method to provide 100% QA.

We don’t read, or interpret any installer or binary. We analysed the impact of the applied changes. We let the application installed on a test client and scan and record all the changes it’s going to apply on the system.

With this approach, one is free from MSI, Non-MSI Installer discussion.

And the next part is about a business critical application.

That’s exactly the typical case- where a customer is ready to pay to avoid the shortfall or malfunctioning of the business applications.

Here one must have to consider the Dynamic Analysis and here we can help you with our product QtestBASE.

May I say that your argument itself describes the limitation ... MSI



MSI also caters for non MSI resolution if you dig deep enough.

reference counting extends to files as well using pre MSI technologies managed by MSI technologies.

Pretty interesting discussion. I had a few guys from App DNA (Chuck Brady and Michael Numa) tell my team that their utility reads the inside of .MSI files then will read the inside of the binaries inside the .MSI. He told us he can do up to 200 apps per hour (give or take a few depending upon the size of the apps).

Now it’s interesting how they can interpret the impact of a binary call or action inside MSI? It’s really a very adventurous approach. Because one has to reengineer the binary code and then interpret it.....

Secondly, it doesn’t matter whether one tool has improved its binary scan analyze from 80 to 99.99%. It simply doesn’t matter...... Because, Static Analysis tool limit itself to only repackaging world.
They are unable to address the QA demands in a professional environment. Packaging is only important part of complete QA-Process - but as I said, only one part. (Let’s wait & see how WISE is going to overtake this market [:D])

We address with QtestBASE not only the application compatibility topic, but also Workplace functioning and stability. Because at the end, client is going to pay its service provider for the functional workplaces. It doesn’t make much sense to say 99 applications on a system are working and then comes the bad surprise (update, a new application or version) which breaks the functioning workplace. Result -penalty

Dear all,

I am the Professional Services Manager of ChangeBASE and have spoken at length with Abdus Salam on this matter... we agree that any application compatibility and migration approach should include as much automation as possible. For example ChangeBASE AOK has been proven to capture over 98% of application compatibility issues when migrating to Windows 7 64-bit. We would never say that you should bypass UAT, but rather that you run UAT using an automated solution such as QTestBASE, which helps you put a workflow and reporting element around your application testing.
To answer the original question on inter-application conflict analysis – you can absolutely use AdminStudio’s Conflict Solver or Wise Package Studio’s Conflict Manager. AOK also has Conflict analysis which allows automated testing and remediation. I am not familiar with the QTestBASE solution around conflict analysis specifically, but I do know that it helps run QA tests against applications within the environment that the applications reside, so worth a look.
Just to clarify a few points on the accuracy of some of the previous statements:

1. A tool such as ChangeBASE AOK can assess the runtime behaviour of ANY type of application - whether packaged, unpackaged and in any format – it does not create a wrapper which would prevent us from assessing the application correctly.

2. When moving to Windows 7 for example, most of the security improvements and changes that were made involved deprecating the use of certain types of API calls, file types and components. When AOK loads an application, it unpacks all of the application files and it exports all of the API calls, dependencies and header information that describes what that file will do at RUNTIME and what role it plays. All of this data allows us to detect the overwhelming majority of issues when migrating to a new operating system or virtualisation technology with high levels of accuracy

FEMKE_NL– please feel free to contact me via LinkedIn or the ChangeBASE website

Hi there,

I am following this discussion for quite a while right now.

The company - I am belonging to - migrated lots of companies to windows 7 within the last month. Especially in the finance sector we have lot of customers.

So I think that I can add some value to this discussion.

First of all I have to say that both methods are useful, but within different scenarios.

For standard software (which is mainly distributed with .msi packages) it is enough to use the analytical approach.

If you are having a look at the business critical applications or very special ones (mostly self developed with wired installation routines) it is not save enough to use this analytical approach.

It is not possible to analyze binary code for example (which is often added to the above mentioned software)

The only solution is to test the entire software.

In the past we have carried out the tests with the application testers within the companies.

@Abdus: You are promising that your tool will reduce that effort to 0? Have I understood it right that you do not have to test any more?

That would change everything!

Thanks for your answer

Joe

I understand the topics of Joe Spencer, with the value of checking an msi but with the binary it will be allways difficult.

Here by the way, since i am working in a test environment for some years, we have the practical experience, that it is not only necessary to make a analysis, from my understanding we have here even a concept that can be implemented in existing workflow and processes. The testing will never come to an end, thats my opinion, but by checking software and getting results of how to prevent an incident it is a reliable system to save costs. For Business Critical Applications, nobody ever will go the way to leave that software untested. Here i see that benefit in that tool, by giving the results of issues, and it can be compared with different results, where you get a better imagination, of whats going on inside the workplace. That is my experience from my daily work too. As i saw on that homepage you can make a download of that software to make a first run and contact with it. And if it can do more then the rest, thats what i get from the hot discussion here, it will be a interesting topic.

One Question from my side, what is your understanding of a UAT User Acceptance Test?

From my experience i can say, that the UAT comes after a normal test procedure, then by giving the software to sometimes called power users we can see further functions during their tests and about the acceptance of the user itself. But this is not meaning that the software is working and free of an issue. Normally a testing means the checking of all available functions, no user will ever do this. This (UAT) is only a little help here, but from my understanding not the way to give a good concept of proven software quality to the customer.

so what is the best tool to use?; Is that what you are looking for?

maybe it would be better if someone answers who is not an employee of either that qtestbase or changebase company;
we have been using aok and apptitude for several month; i am not telling which tool is still in use; these tools are really great use for any migration; i would recommend it to anybody;
but there are limitations; if you are analyzing 95% of the application risks there are still 5% to go;

from my point of view that is what this new company is trying to fit in;
i would be very happy to implement a solution to be 100% secure in certain areas;
maybe it depends on the environment you are working in; there are high risk areas like the flight control we migrated some month back; just registered at qtestbase page to get a trial; let us give it a try;

btw. i do not understand why you are talking about uat; that is something completly different; with an an uat you want to hand over the responsibility and do not want to blame yourself with failures;

so that means QAtest is completely missing newer issues such as session 0 isolation and uipi.

I believe both App-DNA and changebase are checking for these not sure if either tool can do anything about it other than point out flawed code.

so what we are essentially saying is none of the tools on the market cover it all.

I have a rather pragmatic opinion on the matter, it will also possibly sound a bit harsh, so don't read below unless you're up for it. ;)

Intro
The goal of all the above mentioned products is to ease migration pain and ensure compatibility of apps and save money. We have (not in any particular order):
* Changebase
* QtestBASE
* AppDna
* Changebase integration into Flexera products

The question is - Where do the products fit in?
Target audience of these products is people looking to migrate theirs apps to a newer platform.
In real life situation an outsourcing company is usually hired to migrate all apps and ensure/figure out compatibility issues.
I suspect customer will get little value from the detailed reports that all the above products offer unless they have the technical staff that will migrate everything themselves.

How did I test implementations
I've made a pool of apps that I've manually gone through myself (repackaged), a pool where each application had a number of issues that have eaten up precious time and resources to figure out.

These represented all semi-standard environments and scenarios - app-v, app-v on terminal server, win7 x64, etc.

My position is simple - the solution must save money in order for it to be any of use. Here, we have two scenarios:
1) We assign the application to be repackaged to be made compatible.
2) We throw away the app, because it has incompatible issues (16 bit on x64, kernel drivers, specific start-up boot services in app-v)

The amount of the apps we usually dismiss/request new versions from the vendor before even starting up on the app is 7% average. The final number that represents automation scale of all the above products.

After that it's all back to manually going through each application and making sure it works and in reality - this is 93% of what the reports from any of the solutions will state. Reports might (or not) be of use in ensuring highest available quality.

Product specific impressions.
Changebase
I've compiled a list of questions focusing on specific aspects that were important for me. I did not get an answer to those questions, the sales person did not understand my concerns and did not consult with the technical people. Forcing me to go through the same read I could have already done on the web page. Sorry, this did not work for me.

QtestBASE
I've downloaded their solution and sent the "fingerprint" file for analysis. The results got back and I'm not really sure how I can use them. The thing is that it does indeed provide the same functionality that the Flexera Application Manager app does (flexera version only works with .msi files).

So when we, as a consulting company, have a customer who's planning a migration, we recommend ensuring that all the applications in customer's portfolio are .msi based = repackaged.

From this point of view we can either ensure that the whole repackaging process goes through some sort of solution from either of the vendors - wise, flexera, advanced installer or use QtestBASE as an addition. Though, I currently see no benefit of that, because other vendors provide repackaging tools as well and to be competitive this has to have additional functionality over what other vendors provide.

AppDna
I've read through the test site and played around with the demo (which is awesome) a lot of times.

I've ran through my test application list and it has confirmed my initial expectations - it will automate the 7% of apps and save you time, in an additional 40% of the cases (by my estimate) you can expect the data to be useful (such as which .exe has a function that will call for elevation on win7).

Some examples:
– I can see that careful testing will be required, because application has obsolete components. Validation found hardcoded paths in xml files, but picks up a lot of trash that is not related to the application, information is moderately useful because there is a lot of junk:
2 HKEY_USERS\.Default\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\AppData
C:\Documents and Settings\LocalService\Application Data
3
HKEY_USERS\.Default\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Cache
C:\Documents and Settings\LocalService\Local Settings\Temporary Internet Files
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Discardable\PostSetup\Component Categories\{00021493-0000-0000-C000-000000000046}\Enum\\Implementing

Remediation Report for App-V – useful report, I can see not to bother with trying to virtualize this application, because it has so many issues.

When trying to make the application work under limited user I have to manually run an additional tool to determine what kind of privileges does the application need and why. Report does not contain this, so no automation here.
Final conclusion – If I would be making an app-v application - yes, I would save time not opening it and running app-v sequencer, if I would be making an .msi file – no, the report generally states that “manual testing is needed”.


Almost exactly the same results as previous package. App-v report is useful in finding out that this application can potentially have issues, this means that we will have to manually go through the package and determine if it can be virtualized. And is it turned out in this case in real situation – app-v package could not be made.

Overall – report value is debatable. In the end it states that manual testing is required. The same thing would be done without the report present.


Remediation Report for 64 Bit – very useful (16 bit apps detected), we can say straight away that this application will fail on x64 and will not spend time looking into it.
Remediation Report for App-V - “Dynamic Suite Composition” rule is a bit shocking. ;) It doesn’t provide enough useful information. Also it has been known that this application fails when virtualized on windows 7, either on x86 or x64. Report does not say anything suspicious about that executable.
Overall – .msi validations are great, app-v only goes as far as doing testing manually.


Remediation Report for 64 Bit – good, I know for sure all program components will not work on x64.
Remediation Report for App-V - I know that kernel driver component cannot be virtualized, useful.
Remediation Report for Windows 7 – obsolete components only.

Overall – useful report.


In my opinion – it a false-positive report that suggests that application might fail with virtualization and manual testing is needed. In reality it works perfectly.
I’ve also included an incorrectly configured custom action that will fail without the .msi being run with elevation or on repair, the report did not track it down (I presume the best practices validation has been run).
The rule mentioning there is active content in the package is nice, but it provides little in terms of automation.


Mostly it’s an amber report, which will result in making sure that manual testing should be done.
From my perspective – it’s a hard package to make work with app-v, but the reports do not help you save time on it.



The only solution on the market that fits into the concept of preliminary testing and determining compatibility issues. But it is highly overpriced.

Changebase integration into Flexera products

I gave this a shot by downloading the Enterprise product version from Flexera. It failed to import 3 out of 6 .msi files. It does not support legacy installations. No comments.




Conclusion and notes.
All info in this post represents only my personal opinion.
If the topic author wants a solution for Application Interoperability - go for flexera (they have app manager, database of all .msi files and conflicts) or possibly wise (it's been a while since I've played around with their latest versions).

QtestBASE can be considered if you're not interested in looking at the whole repackaging process, but rather focus on the specific aspect. And I will mention it once again - why bother with a specific aspect if the end result that is expected is an .msi file installation that has all the compatibility issues solved. ;)

Let me explain it where the other tools and QtestBASE placed themselves (of course according to my point of view [;)])

App-DNA, AOK provides the functionality to check the applications against the certain platform like Windows 7, App-V.

It works for MSI world. Means for Non-MSI one needs the repackaging. That’s the second step which can be done with Flexera or WISE.

Now the package has been checked and (if possible) made compatible. But compatibility of any package doesn't mean automatically that it’s going to work on the client machine. There may be App2App or App2Workplace problems. If one say that the Conflict Management provided by the WISE or Flexera may address such issues. Let me make it clear here, that the mechanism used by packaging tool is merely based on parsing of the given or repackaged MSI file. What about the packages which contain after repackaging a big number of custom actions or binary calls? What about the application first start-up? What about the runtime issues caused after the installation? There are many aspects which are not covered and should not be covered by the packaging tool - they belong to the Quality Assurance sector.

One can divide the QA in two phases:

Phase-I : After packaging and serves as a bridge between packaging and rollout
Phase-II : Rollout QA

(For further info, please visit http://www.qtestbase.com/quality-assurance/ )

With these descriptions, it should be clear that QtestBASE is a solution designed for QA not for packaging. For packaging one should use further on the other tools. Now turning once again to packaging tool conflict management - it serves for the better quality for the created package not more. Because in an enterprise just an MSI file is not going to be rolled out. There are Software Distribution Systems used to rollout the applications like SCCM, Empirum, etc. Each Distribution System has its own script which installs the given MSI file. This script is going to control and influence the installation process.

How one can check and test such scripts with just a dry theory by simply reading or parsing a MSI file and relying on it that everything is going to work fine at the end?