Software Deployment

Some information on repackaging Dreamweaver MS 2004 is here in the Package Knowledge base.

I, too, am having difficulty repackaging Dreamweaver MX 2004. I am using InstallShield AdminStudio. The link pointed to by bkelly is informative, but I believe it does not apply to my situation, as there are no SQL merge modules in my installation. When I test the .MSI produced by AdminStudio Developer, Dreamweaver causes an error upon starting up and creates a log file, which shows that Dreamweaver caused an access violation.

Can anyone offer more advice? Google is turning up nothing, and I'll acknowledge right off that I'm relatively new at system administration. Thanks in advance.

I havent packaged DreamWeaver yet.....oh the joy to come.

Your problem sounds like its environmental though.

What OS are you deploying too?
What sort of lockdowns are in place?
How are you deploying it....AD with Group Policy or other?

Perhaps DW is overwriting some important system files that is causing the GPF access error?

I can't wait, i have the Studio MX 2004 package arriving in the next couple weeks, then I can see how much i really hate my job... :)

Is it a native msi?

It's funny I am checking this. I am putting the finishing touches on the msi for each app in the suite, it uninstalls the old version and then installs this one. For Dreamweaver It takes a LONG time unfortunately though.... Just try an get the volume licensing edition if you can. and then run this patch regardless http://www.macromedia.com/support/service/ts/documents/serial_prompt.htm. After that I removed all the useless files/registry entries/ini (they all put a ton of junk everywhere). I took me about 3-4 hours to create all of them. For Reference I have xp with WPS 5.0

So how are you going to handle all of the shared Macromedia files.

Dreamweaver, Studio and Fireworks all have the same dll's, so if you package all the dll's and registry entries and then remove one app....its going to break and prompt a self repair of the other apps if they are installed?

Well, I guess he won't be removing just one app... I am going to try and make this one big install for myself and see what happens.

What OS are you deploying too?
What sort of lockdowns are in place?
How are you deploying it....AD with Group Policy or other?

Perhaps DW is overwriting some important system files that is causing the GPF access error?

Deploying to Win2000 at the moment, but eventually we'll deploy it to XP. To the best of my knowledge, there are no lockdowns in place, though I am not sure. It will be deployed through Group Policy, but not until I can at least get it to install properly on my test machine :)

If getting the volume licensing edition is the easiest way to go about this, that's what I'll try and do. But if there's a way to get the version I have to work, and it won't take weeks of hair-pulling to get it to work, I'd like to do it, if only as a learning exercise.

If you are gettting an access violation from the app installing then that means you maybe dropping something into the system as part of the install that it just doesnt like and either changing a reg key or causeing the app to step on some memory space that it shouldnt.

If you want to.....open the msi and save it as a wsi and then email it to me and I'll have a look and see if there is anything glaring back at me as a possible cause for the GPF.

I wouldn't make one big msi, it will take forever to install. They all play nice for me even if I uninstall one of them....What packaging suite are you using? Wise makes it with no problems...

I am going to be using AdminStudio 5.5. I will play with it. let me see what happens, maybe even create a new feature for each app nested within the same msi, then i could use a transform file to install them seperatly if needed.

Hey guys

I was the one who started the thread and am still having no luck with the updates. It keeps falling over on the actlib file. Only for dreamweaver and Flash. All the other apps work fine with there updates. Any help would be appreciated.

scrimpy,

Once you have it installed, make it fail on the actlib.dll file and then close Dreamweaver.

Open Explorer and find actlib.dll and then register it with regsvr32 in a cmd window.

Open DW and see it that fixed it.

If it did then open your msi package and find the file in the files window and set the registration to Ordered and compile and test. If you get the same error then set the registration to none and create a custom action to call regsvr32 and register it that way.

Some dll files do not register correctly using the msiexec /x method.

Has anyone come up with a resolution for Dreamweaver MX 2004, I am experiencing the same symptoms as Scrimpys original posting. I am able to build and install without error - yet when you launch - nothing happens. I have run PackageCleaner against it - no help. I have tried running FileMon and Regmon - nothing unusual in the logs. I have checked the event logs - it reports nothing. I am running both W2k and XP - I am using AdminStudio. I repackaged Flash MX 2004 with no problems. Any assistance would be greatly appreciated.

Well, I finally got my Educational copy of Studio MX 2004. Using Admin Studio 5.5 I ran repackager and did a standard snapshot repackage. I did the entire install, opened one of the apps, entered my Studio MX 2004 serial number, applied the serial hotfix for dreamweaver, then changed the HKLM\Software\Macromedia\{appname}\registration\ and changed the register key's value to -1 as per the Appdeploy.com knowledgebase entry. Ran the after snapshot and after 45 minutes I had a 217MB single MSI file. The only issue I have found so far is that when it is deployed via GPO, the machine must rebooted after or the machine will blue screen when you try to log in. Not that big of a deal as once it reboots from blue screening it is fine. I just set my package to reboot the machine after the install and all is well so far. I am still testing it, i will let you know if i come across any other problems.

I found one issue with my package, Because i set it to reboot, any time it self heals it asks to be rebooted. That sux. Any ideas?

cdupuis - You were able to repackage "DREAMWEAVER MX 2004" individually, and it launched without problems??? We have already repackaged Studio MX 2004, as well as "Flash MX 2004" and they are performing fine. The problem is "Dreamweaver". Again - any assistance would be greatly appreciated.

Well then... :) Let me give it a shot when i have a chance, unfourtunately i have over 500 new workstations and 20 or so apps to deploy this summer, so I am a busy boy.

I was finally able to get Dreamweaver MX 2004 to install correctly. Using AdminStudio - I ran the Dreamweaver MX install and the update (7.01_Update) using "Installation Monitoring" on my clean workstation. After setups were complete - I DID NOT Register. I repackaged the installations. After the installtions were repackaged - I launched Dreamweaver and registered the product, I then exported the Registration key from - "HKLM\Software\Macromedia\Dreamweaver\7\Registration - and imported it into my repackaged installer - Under "Components" - "RegistryData_Machine". It appears to be working fine - I have tested on several machines, as well as with different accounts.

BanditB,

I am running into the same problem repackaging DWMX 2004 limited license version for Win2K using Wise Package Studio.

Specifically, DW will run successfully under the admin login under which the .msi was installed, and for a "test" power user.

If I try to execute DW under a "test" user account that has no rights, the self repair on the HKCU begins, stops, and then nothing happens. If I look at the event log, it shows an msi install error. It refers to accessing a license .dat file at:

C:\winnt\documents and settings\admintestuser\application data\Macrovision - "the file is not accessible".

I tested a straight-away intall of DW without repackaging, logged in as a "test" user with no extra rights, and DW works just fine. So, it is not an inherent lockdown in DW. It is something unusual happening during the capture and compile process, since I did not - to the best of my knowledge - leave anything in my package that was specific to any particular user login.

Let me know if this is along the lines of what you are seeing. I will report back when I find my way around this.

Craig --<>>