discovered an odd thing today…
in an SCCM 2012 SP1 environment we had the client installation of APP-V 5 SP2 + update 2 already running for quite a while
recently the installation Always failed initially, but on the second attempt it worked.
as the deployment was made available this is quite annoying.
there are many ways already described on the WWW how you can install the APP-V 5 client with its dependencies, so I’m not going to say which is best.
initially what we did is create an application for .net framework 4, one for WMF 3, one for KB2533623 and one for kb2758857 (which is the replacement of kb2533623). then create another application for APP-V 5 SP2 and another for hotfix 2
dependencies where setup this way: WMF3 dependent on .net framework 4, kb2533623 and 2758857 dependent on WMF3, APPV5 hotfix 2 dependent on APPV 5 SP2, this to make sure that the dependencies would be installed in the proper order
as only one of the hotfix needs to be present (2533623 OR 2758857) they are placed in the same dependency group:
create separate deployment types for X86 and x64 for the applications WMF, 2533623, 2758857, appv5 SP2 and appv 5 SP2 hf2
so if you check the dependency relationship on APPv5 SP2 HF 2 you will get something like:
OK, now back to the problem of the day…
the installation chain of the APP-V sequence was Always failing on the first attempt, why?
upon looking through the appintenteval.log I saw that somehow the chain was trying to detect .net framework 4, while in the dependencies the .net framework 4.5.1 was set
last week the customer decided that .net framework 4.5.1 was the new standard, so created a new application for it and superseded .net framework 4 by .net framework 4.5.1
ok, sounds reasonable to me, but why is the installation of APP-V streams still trying to do something with .net framework 4 ?
the key is revision history -> upon displaying the references column in the console, we could see that there were still 9 references that depended upon .net framework 4, but those references were still pointing to an old revision of the dependent applications.
after cleaning up old revisions, the installation of the APP-V stream from software center worked again as designed!