Upgrade from Adobe Reader 9.4.1 to Adobe Reader X

I would advise that you try it on a single PC first whilst Acrobat is already open...

MSI installations can take place while an application is open.  Any files it needs to change that are currently in use are noted in the registry as pending file actions/reboot actions.  When the user reboots the machine, these actions are then applied and the application will be upgraded.

I have tried already with no /quiet and the installation and I get a message from the installer requesting for Adobe Reader to be closed in order to finish the installation.

I have tried doing the same with the /quiet and the msi installer sits on the process explorer and doesn't seem to do anything.

In both cases if I close the current Adobe Reader the installation doesn't seem to make any progress.

 

The VM that I was using for testing was low on disk...

I have launched the installation while leaving AR 9.4 open and I have seen that at some point the application gets closed I assume in order to finish the upgrade.

Is there any way to prevent this from happening?

I'm afraid, with this command line nothing will happen at all. Since you are using /j, which means advertising only, the actual installation (and removing the old version) won't happen unless install-on-demand triggers it. However, since extension .pdf is not adversised (for certain special Adobe reason, unlike other file extensions supported by Reader), this won't happen at all.

For regular installation, preventing restart of the computer is achieved by switch /norestart in the command lime. However, for that to work, the installation must have at least minimal interface, such as /qb- .

My band typing the /j

The commandline that I have used is

MSIEXEC /i AcroRead.msi ALLUSERS=TRUE TRANSFORMS=acroread.mst /quiet

This works great and I will take care of the /norestart through SCCM. The problem that I have is that if Adobe 9.4 is open it gets closed for the upgrade to take place.

I don't know if there is any way to prevent this from happening?

Any thoughts?

MSIEXEC /i AcroRead.msi ALLUSERS=TRUE REBOOT=ReallySuppress TRANSFORMS=acroread.mst /qn /l*v c:\windows\temp\AdobeReaderX_install.log

That wil install the application silently requiring no user input, suppressing the reboot and creating a verbose log in the temp directory for you to examine any errors/reasons for not completing.

This is probably Restart Manager in action, i.e. the installation is trying to close conflicting application, but after the installation it's suppsoed to be restarted. Restart Manager can be suppressed by
MSIRESTARTMANAGERCONTROL = Disable. http://msdn.microsoft.com/en-us/library/aa372466%28v=vs.85%29.aspx has more details.

Disabling is not an option at this point since it will introduce a change for everyone and all the applications, etc...it will not be approve here....

I wonder if there is a way to pass this option somehow for this particular installation.

Maybe you misunderstood. MSIRESTARTMANAGERCONTROL=Disable is another command line switch to put in this installation, it's not anything system-wide.

MSIEXEC /qb- /norestart /i AcroRead.msi ALLUSERS=TRUE TRANSFORMS=acroread.mst  MSIRESTARTMANAGERCONTROL=Disable

Sorry I did.

I have tried the command but AR9.4 gets closed at some point by Adobe Reader X.

It must be a way to avoid this otherwise you are going to be hitting hard your users while the deployment is taking place.

Maybe Adobe have implemented something to do that on their own. Not the first time.

Produce details log (/l*v c:\install.log) and post here.

Or if you can wait, I was going to repackage their installation of 10 anyways, like I always did with all previous versions, so by the end of next week I will probably have fully compliant MSI of it.

How do you manage the repackaging process for Adobe? Perhaps I am doing something wrong howecver I have checked with other and they have seen the same behaviour when they were deploying 9.4. so this is not something that happens only with the X version.

>  How do you manage the repackaging process for Adobe?

well, just like everything else... wise package studio captures system state before and after the installation, then puts things together, then I polish it.

Initially I started repackaging Reader because of two things: one was their error when brand icon does not show up when it's per-user installation, because Adobe hardcoded the path in the registry, a big no-no; On Adobe forum many complained, and I posted a workaround; but all attempts to point their attention to that, up to their higher-ups, were scoffed at. Another was what I mentioned - non-advertising of the flagship extension PDF, so there's no install-on demand, upgrade-on-demand, etc. - they did it because they detect if the user also has "big" Acrobat and give the choice of what should open on double-click. Plus of course once you look inside and run ICE validation, there are pages of red. So I repackage it for my users, and all is dandy, install by demand, uninstall, upgrade, etc.

I have used ORCA to double check that everything was fine on the MSI that I am deploying and I haven't seen any problems with it I have also look at the forums but I haven't seen anything that I have to be aware of.

So with previous AR versions how did you manage to upgrade/install it while the users are Adobe Reader while you are trying to deploy the new version?

> I have used ORCA to double check that everything was fine on the MSI that I am deploying and I haven't seen any problems with it

Use menu Tools/Validate, select Full MSI Validation Suite.

> So with previous AR versions how did you manage to upgrade/install it while the users are Adobe Reader while you are trying to deploy the new version?

I made PDF an advertised extension, so it was install-on-demand. Whoever clicks a pdf file, gets it installed automatically. Or upgraded. So I don't even hit this issue. There's also an interesting little known trick in this article

If I did hit it, I would simply assign the installation in group policy, so it would get installed on welcome screen, no conflicts.

Thanks for the article. In the past I have done installations via GPOs and logon scripts in both cases the problem was that the users will experice an error message if they needed to open the application. Or in some instances the logon process was slow and the users were complaining.

However I didn't know that you could do installations through GPO using extensions. So basically if I am understanding this correctly once the GPO is assigned the user will open a PDF and it will install/upgrade the application prior to open the file?

I assume it will only install the application per computer once the user opens the PDF file?  

> So basically if I am understanding this correctly once the GPO is assigned the user will open a PDF and it will install/upgrade the application prior to open the file?

Right, this is called "install-on-demand". You can configure various applications handling various extensions, so those users who never open a particular file, won't ever have the application installed; those who do open, will have it installed. It can be even more detailed, down to so called "features" of the larger packages, such as Microsoft Office, for instance. The user clicks .doc, and has Office installed, but only with Word feature (plus necessary common components). Then next day he clicks an .xls file, and Excel gets installed.

> I assume it will only install the application per computer once the user opens the PDF file?  

It depends on how you publish it in group policy. If under Computer Configuration, then per computer; if under User Configuration, then per user. If it's per user, and if another user on the same computer has already installed the same package, then the installation is very fast, since all files are already in place, and it only creates registry entries under HKCU and such.

Regarding errors and slowdown - no, everything works just fine, you probably had some issues that could be fixed if looked at seriously. When everything is already installed, winlogon only verifies that everything is there, does not install anything, no slowdown. No errors either. In fact we have numerous group policies anyways, such as controlling behavior of Office, restricting what activex controls can run in Internet Explorer, and much more, so these installations are only a part of it.

The only drawback of deployment by group policy is absence of the reporting, so we developed a custom method - you already saw the website, it's in another article "How to report result of installation in active directory deployment".

A mere look at their installation file shows that I was right by saying "Maybe Adobe have implemented something to do that on their own. Not the first time."

Capture-02-25-00001.png

Is there any way to modify this behaviour? I would like to deploy the app through SCCM since it is the way we do things here and it will take me a long time to switch to the GPO method.

Thank you for your help.

Looks like only by modifying their msi, which can be made by transform.Since you have orca, you can do it - find that custom action and delete, then save transform.

...actually, in sccm you also can schedule it during logon, rather than "as soon as possible".

Another way to remove this from the sequence is by using the same customization wizard -> direct editor -> installexecutesequence.

Hi,

I the past I tried the SCCM install at logon but it didn't worked as expected however it was an early release. Since we upgraded to SP2 and the new clients were deployed I haven't tried.

I have checked the Adobe Customization Tool  direct editor -> installexecutesequence but I have not been able to identify the function that close the application.

Am I on the right spot?

It's only my guess based on the name of this function, but that's where it is - see the picture.

Meanwhile, the repackaged installation is ready, and you, as the inspirational force, can become its first beta tester, if you want - let me know.
Capture-02-26-00001.png

I will give it a try. Let me know how do I get the package.

Meanwhile I will try to repackage my own changing the setting.

Have you done anything else to the MSI?

Sorry I am drilling you with all these questions but I just want to learn how to make this work rather than get it done.

Thank you.

One more note that I realized: regarding the problem of auto-closing an open application: this may happen anyways even with repackaged or modified package. The reason is that this can be done by the old version when it's being removed by the upgrade. The way upgrade works is, it installs new package and removes the old one. Removing the old one is controlled by the installation of that old package, cached on the computer, so if it decides to close applications, it will, and new package can't do much about that. Modified or repackaged installation won't close them when it's installed, nor when it will be uninstalled by upgrade to some future version.

**Removing the old one is controlled by the installation of that old package, cached on the computer, so if it decides to close applications, it will, and new package can't do much about that.**

So basically the new package will not be able to stop AR 9.4 to be closed if it is open when the new package gets installed since this behaviour happens because the settings that were defined on the AR 9.4.

That being said once you install/upgrade with the new package the one for which the value that was indicated on post ID:34988041 in future installation or upgrades the application will remain open during the new deployment.

Am I understanding the previous post correctly?

Yes, all correct.

My repackaged installation looks like fully ready to go, by the way, with upgrade. And I should note, since the previous one was also repackaged, during the upgrade in XP it correctly shows dialog "files in use, please close the following application, or else restart will be required". In Vista and 7 probably would correctly invoke restart manager, unless prohibited by the setting mentioned previously.

You might find this interesting....
http://kb2.adobe.com/cps/837/cpsid_83709.html

With the release of Adobe X, you can now import the SCUP catalogues into SCCM to update reader via Software Updates.

Btw, in case you are using DFS/NFS, don't install X. http://kb2.adobe.com/cps/860/cpsid_86063.html . There's already an upgrade 10.0.1 where this is fixed.