Adobe repackaging problems

[CChong]

From all the posts I have read, obviously many people have been able to repackage both Adobe Acrobat 5 and Photoshop 7 without difficulty. Can anyone throw some suggestions my way on how to accomplish this without 600 errors. I am working on a clean Windows 2000 machine with Service Pack 3, Office XP, and IE 6. I have run ISRepackager locally as well as across the network to the development machine, both to no avail. :confused:

[nicholas_ong]

First of all you may want to work with just the OS and Service Pack. I wouldn't consider having Office XP installed as a Clean machine. Ensure that you log on as local admin while repackaging. If possible, do not add the workstation to the domain.

[CChong]

Thanks for the tips. The only reason that I need to have Office installed is for Acrobat. It places plug-ins for the PDF maker in the Office folder. Without it, the install will skip right past them and not install the plug-ins. I do add the computer to the domain, but always use the local admin account. I will try not adding it to the domain to see if that helps. Any other thoughts are appreciated.

Thanks again.

[nicholas_ong]

Here are certain things to watch out for when repackaging Photoshop 7. There are several files with % in the filename and Installshield tends to Add % to it thinking it's a variable. When compiling, it then complains that it can't find the **%%.ado file. Do a search for these files and change them to ***%.ado. You can do a search and replace but record the ones you do not want to replace and change them back after.

The shortcut icons also poses problems, they have to be modified manually.

As for Acrobat plug ins, I wonder if you installed Acrobat prior to installing office xp if that would work. And if it does, the assumption is that the plug ins are installed. I'm sure that a large number of people may have installed Acrobat prior to installing Office xp. How did they get the plug ins to work?

[AlaksSevugan]

Issues with % sign in the filenames has been fixed in AdminStudio 3.5 and this release will be available soon.

[CChong]

I hope there is a simple answer to this problem but:

I'm trying to repackage Photoshop 7 and I've created the MSI file. Installation for the most part works fine but it seems to be only installing for the current user.

For instance, if I install via group policy computer assignment, any time I log on with a user and launch the app it goes through the reinstallation procedure.

If I install it from a logged on user using msiexec /i photoshop.msi /q, it launches without reinstallation for that user. But as soon as I logon to the machine with another ID it wants to reinstall the app as soon as I launch it.


It seems to behaving in a way that indicates that is installing for the currently logged on user but is only advertised for any other user that logs on and hence has to go through the installation again.

How can I tell it that I want it installed for all users and not to reinstall for each user who attempts to launch it?

Thanks

[AlaksSevugan]

You can try and use the MsiSPY tool that is available in the MSI 1.2 SDK. This is available in the Microsoft Web Site.

This tool will tell you why a certain product is trying to repair itself for a given user. Once you have identified the components, you can use the author tool to fix the problems.

[nicholas_ong]

If an installation package contain current user settings, it will only install those settings for the user who launches the installation. When you use the GPO to assign a package to a computer, those settings are applied through self healing when a new user of the application attempts to launch it. The key file/path determines the requirements for self healing.

You can set the installation to make a copy of all current user settings to the default user profile however this will only apply if your users do not have roaming profile. With this method, you can assign to the computer and when the new user logs on, their profiles are copied from the default user profile which already contains those registry or file settings.

With roaming users, there is no panic as the self healing will provide them with the current user settings once and when they log on to other workstations, it will recognize those settings in their profile and will not self heal a second time.

If the self healing re-occurs for the same user on the same workstation, you have a problem with your package. In this case, check the application log in the event viewer for more information.

[CChong]

Thanks,

Can anyone tell me the difference between how the install should work if the application is assigned versus published?

I've repackaged Photosop and Paint Shop Pro and both work fine when I assign them through policy.

Unfortunately when I publish them and install them through Add/Remove Programs -> Add new programs they don't function.

The icons in the start menu appear as the generic DOS type icons and when I execute the shortcuts it goes through the process of installing but doesn't actually do so.

I get a event log like such:

Event Type: Warning
Event Source: MsiInstaller
Event Category: None
Event ID: 1001
Date: 2/4/2003
Time: 12:05:29 PM
User: N/A
Computer: JSCOVILLVMXP
Description:
Detection of product '{8AD4691D-00F9-4A84-9DE8-AD29C36192FD}', feature 'PaintShopProNewFeature' failed during request for component '{8EA58816-D67B-483A-A69D-06EB97C2A2D8}'

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.


Any ideas on why this is working fine for assigned apps but not for published?

Thanks

[nicholas_ong]

It depends if you are assigning to the users or the computer. Assigning to the user should have the same result as publishing to the user, both provides current user settings to the user who launched the installation.

I did not have any problems repackaging Photoshop 7 and it is published to users. Did not have an opportunity to work on Paint Shop Pro though.

[CChong]

Hi, I'm new here.

I have repackaged Adobe Acrobat Reader 5.0 quite succesfully, only there is one problem. The installation takes really short, and I think there is something wrong with registering files.

When I log on as a different user then the administrator (from which I've installed the msi file) Adobe Acrobat setup will configure the system, and I think that all files are copied again from the source.

When the pc is in our domain it is not such a problem, but on external locations, the msi file is not available.

Also, when logged on as that different user, the setup will nog only start when starting Acrobat itself, but also when starting windows explorer for example.

I have no idea what I should change in the project to let the setup work without errors or complete for all users...

[nicholas_ong]

I suppose that the users logging on to the external workstations are logging on with local user accounts. You can set the installer to make a copy of the current user settings to the default user profile. By doing so, every user that logs on after will obtain those settings.

[CChong]

How can you set the installer to make a copy of the current user settings to the default user profile ?

Sorry new to this.

[nicholas_ong]

Modify this in the options.ini file

UseHKCUProxy Set this option to "Y" to copy all
registry entries in HKEY_CURRENT_USER to
HKEY_USERS\.default. This will make the
entries (and the application) available to
all user accounts created after the
Windows Installer package is installed.
This option is set to "N" by default.

[CChong]

cheers I'll give it a go.

Marcus

[nicholas_ong]

Just keep in mind the default users registry entry is only valid for users you create locally. Their profiles are copied directly from the default profile. And will inherit those entries only the first time they log on.

You can also make use of the self healing feature to insert current user entries for each user who logs on. The key path for the current user registry component will be checked for each user who launches the application. If not found, the msi will self heal inserting the current user registry entry. The users will require access to the MSi in order for this to work.