Naerwen
asked on
WSP 7 - Visio
All,
I am attempting to repackage Visio 2K7 for deployment (Using Wise Packaging Studio 7). What we are looking for is a very basic installation.
While attempting to get a usable MSI or Wise Script I keep getting a Wise32.exe error when completing the capture process. Please see the attachement. While messaging the data for the completion process I have remove all the *.\installer\* entries from the registry. Is this wrong?
Also, we have attempted to use Altiris RapidInstall.exe to capture the image. While this process compeletes and deploys without error...Visio 2007 is not usable ... that is we get "The application failed to initialize properly 0xc0150002" ... which points to VISLIB.DLL not getting loaded.
In any case, any help or pointers towards getting an MSI or WiseScript to successfully capture would be helpful.
Thank you,
Naerwen
Wise32Error.png
I am attempting to repackage Visio 2K7 for deployment (Using Wise Packaging Studio 7). What we are looking for is a very basic installation.
While attempting to get a usable MSI or Wise Script I keep getting a Wise32.exe error when completing the capture process. Please see the attachement. While messaging the data for the completion process I have remove all the *.\installer\* entries from the registry. Is this wrong?
Also, we have attempted to use Altiris RapidInstall.exe to capture the image. While this process compeletes and deploys without error...Visio 2007 is not usable ... that is we get "The application failed to initialize properly 0xc0150002" ... which points to VISLIB.DLL not getting loaded.
In any case, any help or pointers towards getting an MSI or WiseScript to successfully capture would be helpful.
Thank you,
Naerwen
Wise32Error.png
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Not for points, just for clarification. Vadimrapp1 is right, don't repackage an MSI - expecially Office. When your repackage it, it's going to get a new GUID, which means that when patches are released, they're not going to work. When a new version of Office comes out, you wont be able to (easily) upgrade.
You wont be able to create MSTs for Office, use the OCT that the previous poster linked to.
You wont be able to create MSTs for Office, use the OCT that the previous poster linked to.
ASKER
Vadimrapp1, usachrisk1983,
doing a dry run with the OCT. I had looked at it before but didn't try it.
Thanks for the direction. Will let you know asap how it went.
TTS,
Naerwen
doing a dry run with the OCT. I had looked at it before but didn't try it.
Thanks for the direction. Will let you know asap how it went.
TTS,
Naerwen
some comments - not really to argue, just observations.
"don't repackage an MSI"
some MSI's are so badly authored that repackaging them actually improves. Adobe Reader is great example.
Usually this is the reason of the original installation authors' trying to be "smarter than Installer". They think their application is oh so special that usual rules and standards of course don't apply, so they begin writing ton of custom actions, write registry values directly instead of regular COM registration, destroying resiliency and advertising along the route, and so forth. Another reason is being simply unfamiliar with MSI authoring to begin with - it's known effect that when you are beginner in the area, you immediately discover that this is not implemented, and that is stupid; later, once you become more proficient, you realize that of course it's all taken care of, only not as you expected at once. But I'd imagine, installations are often made by developers for whom installations are not their main speciality, so they grab Installshield, run the wizard, then write custom actions for everything the wizard has missed.
The main problem with all this is that Installer naively handles big number of various scenarios of deployment - roaming, per-user, per-machine, advertising, managed, and so forth - while these authors only consider one-two most usual scenarios of the straightforward installation. As the result, the installation becomes uninstallable and so forth, and soon the original vendor is creating his own "cleanup utility" that is supposed to clean the mess left after the installation. There's Nero cleanup utility, and NVidia cleanup utility, and of course Microsoft who writes big articles in their KB "How to uninstall (yet another product)". In fact, every such article and every such utility is a sign of badly authored original installation.
And when we are dealing with such an installation, repackaging it actually improves - provided of course that in the resulting installation the standards are observed, and the ICE validation passes.
> You wont be able to create MSTs for Office
With the right authoring tool, MST can be created for any MSI. Though, because of the above-said considerations, it's possible that it won't work as expected if standard actions (handled by the MST) in the original MSI were then overridden by custom actions (not handled by the MST).
"don't repackage an MSI"
some MSI's are so badly authored that repackaging them actually improves. Adobe Reader is great example.
Usually this is the reason of the original installation authors' trying to be "smarter than Installer". They think their application is oh so special that usual rules and standards of course don't apply, so they begin writing ton of custom actions, write registry values directly instead of regular COM registration, destroying resiliency and advertising along the route, and so forth. Another reason is being simply unfamiliar with MSI authoring to begin with - it's known effect that when you are beginner in the area, you immediately discover that this is not implemented, and that is stupid; later, once you become more proficient, you realize that of course it's all taken care of, only not as you expected at once. But I'd imagine, installations are often made by developers for whom installations are not their main speciality, so they grab Installshield, run the wizard, then write custom actions for everything the wizard has missed.
The main problem with all this is that Installer naively handles big number of various scenarios of deployment - roaming, per-user, per-machine, advertising, managed, and so forth - while these authors only consider one-two most usual scenarios of the straightforward installation. As the result, the installation becomes uninstallable and so forth, and soon the original vendor is creating his own "cleanup utility" that is supposed to clean the mess left after the installation. There's Nero cleanup utility, and NVidia cleanup utility, and of course Microsoft who writes big articles in their KB "How to uninstall (yet another product)". In fact, every such article and every such utility is a sign of badly authored original installation.
And when we are dealing with such an installation, repackaging it actually improves - provided of course that in the resulting installation the standards are observed, and the ICE validation passes.
> You wont be able to create MSTs for Office
With the right authoring tool, MST can be created for any MSI. Though, because of the above-said considerations, it's possible that it won't work as expected if standard actions (handled by the MST) in the original MSI were then overridden by custom actions (not handled by the MST).
ASKER
Vadimrapp1,
Your suggestion of using the OCT was correct. I was able to use it and create a custome installation for my end users. However, there was one last thing that I could not get rid of and that was the prompts to use "Microsoft Updates for Office" and one other I cannot think of at the moment. So....kudos to for that. However, that was not satisfactory for the administration and as such I was pressured to make either WPS 7 or RapidInstall Rip work. I had to go with the latter because WPS 7 simply fails to execute a capture(Likely due to me being a novice to repackaging technologies). That said, I was successful in capturing a solid install with RapidInstall from Altiris.
I would like to point out one thing regarding OCT vs. a RIP. The OCT was better in that it has less overhead interms of the need for drive space during deployment. The OCT solution consumed @ 280MB on the server. Said 280mb MUST be copied to the client machine for deployment ... using Altiris, that is. The RapidInstall RIP is a 550mb .exe that also must be copied to the client to complete the install. I would prefer the former simply because it reduces a few factors in terms of overhead ... space and bandwidth.
I am awarding you the points.
Thank you for your help. I truly appreciate it.
Naerwen
Your suggestion of using the OCT was correct. I was able to use it and create a custome installation for my end users. However, there was one last thing that I could not get rid of and that was the prompts to use "Microsoft Updates for Office" and one other I cannot think of at the moment. So....kudos to for that. However, that was not satisfactory for the administration and as such I was pressured to make either WPS 7 or RapidInstall Rip work. I had to go with the latter because WPS 7 simply fails to execute a capture(Likely due to me being a novice to repackaging technologies). That said, I was successful in capturing a solid install with RapidInstall from Altiris.
I would like to point out one thing regarding OCT vs. a RIP. The OCT was better in that it has less overhead interms of the need for drive space during deployment. The OCT solution consumed @ 280MB on the server. Said 280mb MUST be copied to the client machine for deployment ... using Altiris, that is. The RapidInstall RIP is a 550mb .exe that also must be copied to the client to complete the install. I would prefer the former simply because it reduces a few factors in terms of overhead ... space and bandwidth.
I am awarding you the points.
Thank you for your help. I truly appreciate it.
Naerwen
ASKER
Please let me know if you will need any other information regarding the PC.