Software Deployment

http://www.macrovision.com/products/installation/adminstudio.htm

Whether or not it supports 64 bit I dont know but a quick phone call to them would tell you, it does support Vista, so it says.

P

I,ve tried adminstudio 8.6 but it has the same problem with de initial snapshot of a vista x64 client.

Deleting HKLM\Software\Wow6432Node\Wow6432Node from your workstation will solve the problem. The only key that resides here in a clean vista x64 installation is a key for the app path of the 32 bit iexplore.

ORIGINAL: red_willie

Deleting HKLM\Software\Wow6432Node\Wow6432Node from your workstation will solve the problem. The only key that resides here in a clean vista x64 installation is a key for the app path of the 32 bit iexplore.


Thx for this solution red_willie!! (ps. ART rulez![;)])

A late follow-up to my own question:

I have had the opportunity to test repackaging on Windows Vista 64-bit with three different MSI repackagers now:

Wise Package Studio 7.0 SP3
InstallShield AdminStudio 8.6
Advanced Installer 6.3.1

None of these repackagers seems to have support for repackaging 64-bit installations on Windows 64-bit.

The problem is that on Windows 64-bit there is an emulation layer for 32-bit applications called WOW64 (Windows 32-bit on Windows 64-bit). It acts as a filter between the real 64-bit OS and the 32-bit application for compatibility reasons.

Among other features, WOW64 redirects accesses to both the registry and the filesystem for 32-bit applications in order to maintain compatibility and co-existence with 64-bit applications. These subfeatures are called "Registry Redirector" and "Filesystem Redirector". For example, when a 32-bit application running under WOW64 accesses items in HKLM\Software, it will actually access registry keys below HKLM\Software\Wow6432Node on the 64-bit OS. The same is true for the C:\Windows\System32 directory where all accesses will be redirected for 32-bit applications to C:\Windows\Syswow64.

All the repackagers above only seem to exist as 32-bit applications. Because of this and the fact that they don't turn off any of the WOW64 redirections for themselves (which is possible in a 32-bit application), the repackagers are unable to see changes made to keys and values in HKLM\Software and to files and directories below C:\Windows\System32. They will only see changes introduced below HKLM\Software\Wow6432Node and C:\Windows\Syswow64.

Repackaging 64-bit installations which do not use MSI is therefore a problem since the repackagers will be unable to see many of the potential changes introduced outside the WOW64 environment. At best you will see parts of the installation and capture it to an MSI package.

References:

WOW64 Implementation Details
http://msdn.microsoft.com/en-us/library/aa384274.aspx

WOW64 Registry Redirector (list of redirected keys)
http://msdn.microsoft.com/en-us/library/aa384232.aspx

WOW64 Filesystem Redirector
http://msdn.microsoft.com/en-us/library/aa384187.aspx

ORIGINAL: Jonas Olsson

I am currently involved in a project concerning deploying numerous 64-bit applications on Windows Vista x64. Since our deployment method, which uses Microsoft SMS, is required to be completely automated both for installs and uninstalls of application packages we may need to repackage some applications to MSI if they aren't already in that format.

Our favourite tool for repackaging for Windows XP has so far been Wise Package Studio, using SetupCapture for legacy installations. Unfortunately, there is no 64-bit version of SetupCapture available which leads to several problems when attempting to repackage 64-bit applications. According to Altiris's knowledge base, no support for 64-bit repackaging is available from them currently.

Does anyone know if there are any repackaging tools out there that can handle repackaging 64-bit applications on Windows Vista x64?




Jonas, if I were you I'd take it as an opportunity to build the MSI packages from scratch rather than repackaging them, as repackaging presents problems of its own (google this if you're interested).

Much better to get the files from the developer/vendor and create a fresh 64-bit project in Wise, adding all the files, shortcuts, customizations etc. that you want.

Have you inquired about this?

ORIGINAL: aogilmor

Jonas, if I were you I'd take it as an opportunity to build the MSI packages from scratch rather than repackaging them, as repackaging presents problems of its own (google this if you're interested).

Much better to get the files from the developer/vendor and create a fresh 64-bit project in Wise, adding all the files, shortcuts, customizations etc. that you want.

Have you inquired about this?



The preferred option would of course be to receive all applications in 64-bit MSI packages from the vendors or to receive information directly from the vendors on how to convert their installations to MSI packages. In my experience not all vendors are cooperative in this regard because they don't see the need for MSI packages or repackaging to MSI. They are in many cases not aware of the challenges facing enterprise organizations when managing a multitude of different applications on locked-down client platforms.

Having a few years experience in the field of MSI packaging I am well aware of the limitations of repackaging but also of the advantages compared to using homegrown vendor installers. As we start using 64-bit Windows I see a growing need for being able to repackage 64-bit applications and to detect and analyze changes made to the 64-bit part of the OS, which a repackager excels at for 32-bit Windows.

Jonas,

For now Wise Package Studio do not support to capture on 64-bit platforms which is finally confirmed by Altiris/Symantec.
No info when this will be supported.

/Kim

Kim,

Thank you for the info. As you can see above I tried a few other repackagers with little success.

ORIGINAL: Jonas Olsson
In my experience not all vendors are cooperative in this regard Classic understatement, Jonas. I like it. In *my* experience, vendors have little clue about what their own setups actually do to a machine: the lack of documentation at most of them is a vision to behold. Even the developers (if you get to talk to them) have no clue. For me, in most cases, any call/email to the vendor is the call of last resort.

Ian,

Do you know if InCtrl5 supports to run on 64-platform?

Given that it's vintage 2000, on a scale of likelihood one to ten I'd say it's a zero.

ORIGINAL: Jonas Olsson

ORIGINAL: aogilmor

Jonas, if I were you I'd take it as an opportunity to build the MSI packages from scratch rather than repackaging them, as repackaging presents problems of its own (google this if you're interested).

Much better to get the files from the developer/vendor and create a fresh 64-bit project in Wise, adding all the files, shortcuts, customizations etc. that you want.

Have you inquired about this?



The preferred option would of course be to receive all applications in 64-bit MSI packages from the vendors or to receive information directly from the vendors on how to convert their installations to MSI packages. In my experience not all vendors are cooperative in this regard because they don't see the need for MSI packages or repackaging to MSI. They are in many cases not aware of the challenges facing enterprise organizations when managing a multitude of different applications on locked-down client platforms.

Having a few years experience in the field of MSI packaging I am well aware of the limitations of repackaging but also of the advantages compared to using homegrown vendor installers. As we start using 64-bit Windows I see a growing need for being able to repackage 64-bit applications and to detect and analyze changes made to the 64-bit part of the OS, which a repackager excels at for 32-bit Windows.



Hi Jonas,

Even if the vendor is uncooperative you can sometimes get the file names from .lst and .cab files included with legacy installations. Extract the files from the cabs if you can, or do your installation on a fresh image, save these files off somewhere (along with paths, settings shortcuts etc.) then add them to your fresh 64 bit project. Re-image, test, repeat. I would say I'm surprised that any 64 bit vendor would not "get" the benefits of Windows Installer technology; however, I recently repackaged a 64-bit server app using that method. You are a bit of a pioneer doing 64 bit packaging. Let us know how it goes!
Good luck!
OG

Owen,

I'm sure Jonas agrees that manually creating the package would be the best way but it's not applicable in all scenarios. I'm most thinking of time consuming.
I really think vendors creating these packaging tools should add support for their tools to support 64-bit as they do with 32-bits.

Kim,

Exactly the point I was coming to. When packaging several hundred applications each year it is important from a cost-effective perspective to be able to do so in the most expedient way possible. If we are forced to try and figure out what an installation does to a system with little or no input from a repackaging tool, time restraints may eventually prevent us from ever completing the package as the cost versus gain factor becomes too great.

ORIGINAL: Jonas Olsson
When packaging several hundred applications each year
So that's all you do day long, packaging?

Sounds like you're doing at least 4 packages per week [;)]

ORIGINAL: AngelD
I'm sure Jonas agrees that manually creating the package would be the best way but it's not applicable in all scenarios. I'm most thinking of time consuming.
I really think vendors creating these packaging tools should add support for their tools to support 64-bit as they do with 32-bits.


Angel, I don't know that Jonas did agree, as he kept talking about setup capture and repackaging. A fresh project is not applicable in all scenarios, but in those I named (able to extract files from the cabs, know the location and/or fresh install with a file list) it would both be applicable, and the best method. I think this method would take less time than a setup capture or repackage.

Owen

ORIGINAL: AngelD

ORIGINAL: Jonas Olsson
When packaging several hundred applications each year
So that's all you do day long, packaging?

Sounds like you're doing at least 4 packages per week [;)]


That's actually a below average number of packages for our team so it's fair to say that we produce quite a few of the little buggers. [8D]

ORIGINAL: AngelD
I really think vendors creating these packaging tools should add support for their tools to support 64-bit as they do with 32-bits.It's not like Vista crept up on vendors, is it? Besides, I'd imagine Altiris et al would have had a lot more notice than most developers, possibly even pre-release code. IMV, there is no excuse for not having 64-bit capability today, period. It's pathetic.