Software Deployment

ON the VM, you're probably using an account with local admin. Come deployment time, ordinary user accounts won't have those privileges so will be unable to write to the key in question. Almost certainly this is in HKLM\Software\Classes (cunningly disguised as HKCR, of course). I'm wondering why, though, your local System account (which is used by GP deployments) doesn't have rights there. Worrying...sounds like a permissioning issue with your build.

Thanks for the response. This is weird, I've never run into this problem before and we use the same process for all our installs. I'll try to package it again but try joining the domain first on the VM, see if that helps.

The "HKCR\CLSID\{D27CDB6E-AE6D-11cf-96B8-444553540000}" regkey is part of Flash.

I don't know why Macrovision (Now Adobe) insist on setting the (permission) Deny bit on files and registry for Everyone "Group" during install, they never learn.

However; the Deny bit is the cause of the error.

Thanks, any suggestions around it?

Are you doing a capture on flash as it's already a (wrapper) "MSI" launching a legacy setup.

You could author a custom action to reset the permission prior to the WriteRegistryValue (standard) action.

I don't think the OP is installing/packaging Flash at all. The log entry identifies the product as 'KeyboardPro Deluxe'. The question probably ought to be why that product is futzing with that key at all.

Was the package for that product captured or was it a vendor-supplied MSI? If the former, I suspect that it contains elements of Flash which ought not to be there. It could also be that somehow this product and Flash are using the same class ID. To which file does the InProcServer32 entry point? If it's a Flash file, it should be 'C:\WINDOWS\system32\Macromed\Flash\Flash9b.ocx' or similar. There may also be a 'companion' entry immediately after, with the CLSID '{D27CDB70-AE6D-11cf-96B8-444553540000}'.

Good question. It ran fine in the VM but that probably would'nt have the latest ver of Flash. InProcServer32 points to 'C:\WINDOWS\system32\Macromed\Flash\Flash9f.ocx'. I just repackaged it from the CD. I'll try grabbing the msi and working with that. I went in and gave 'everyone' full permission to that key to no avail.

I just repackaged it from the CD. I'll try grabbing the msi and working with that.It sounds like you re-packaged what was already an MSI. You should NEVER do that. Remember that many apps are distributed with an EXE set-up stub which ultimately extracts an MSI and executes MSIExec against it.

Before you run any stub:
- clear out your %TEMP% folder
- run a stub
- when you see the first dialog (normally a 'Welcome to the BEST PRODUCT EVER!" type screen), check back in the %TEMP% folder. If there's an MSI there, THAT'S what you should work with.

There's another "gotcha", though. Plenty of stubs are built with InstallShield and the authors have a habit of retaining the ludicrous check in the MSI for whether or not the MSI was called from "inside" the stub. These can easily be fooled by use of the property ISSETUPDRIVEN. Search here at AppDeploy for that property as a backgrounder for your packaging journey.

ORIGINAL: jackfh

I went in and gave 'everyone' full permission to that key to no avail.

Uncheck the "Deny" checkbox first as it will not have any effect otherwise.

Thanks! two good suggestions - the Deny was aplicable to the 'Set Value' option - testing that now. I'm just learning to package so extracting the msi is a new twist, I'm going to repkg it now.

No go on either count, changing the permissions didn't help and I can't find the msi when the install starts.

Could you give us the details what you did and what did not work.

OK, I pkgd it up using AdminStudio, and the .exe file, it worked in the VM. When I deployed it via GPO, it came up with the error above. I went in and changed the permissions for 'Everyone' to allow Full control. That still didn't work. I noticed that the VM did not have Flash or MS Office 07 installed while the lab did. I tried to get the msi from the app but couldn't find it, even doing a search, it didn't turn up. Appreciate all the help.

- If you didn't find an MSI, it's likely that the package ISN'T MSI-based. Your post (#8) implied that it was.
- We could start a year's worth of posts about what a packaging box/VM should look like. Some will argue that it should be a bare OS with no apps. I prefer it to reflect the client's base build, i.e. how a workstation gets delivered to a user. So in your case, if the build includes Flash and Office 2007, install it first before beginning the capture. Even so, if the vendor's installer re-writes files and/or registry data that it ought not to, you need to remove that activity from the package. Experience will help you determine what should be included and what should be removed.
- For now, back up the MSI to give you a fall-back. Find the component containing that registry data and remove it. IMV, that software has no business writing stuff there (although, as I said, I believe you have inadvertently captured that.) Save the MSI. Re-test.

Thanks for the help and suggestions. I'm fairly new to repackaging and have alot to learn. I agree about the VM environment and normally, I would apply the same software to that as to where the pkg is going. This time I didn't do that and, sure enough, it bit me in the butt. Let me try this again and see what happens.

I had exactly this error recently. It seemed to me that the application had no business in that registry key or messing about with Flash but there were plenty of registry entries relating to Flash when the exe was captured.

I followed AngelD's advice and sure enough the Deny permission was set. Manually changing this allowed the application to progress past the 1406 error. I had to do this for 4 other registry keys to complete the MSI install on my test PC. Incidentally I also had the issue that the MSI installed initially on my packaging VM without any errors - clearly due to packaging machine not having Flash installed.

I will look into a custom action as AngelD suggested but just wanted to let you know this thread helped me out.

just wanted to let you know this thread helped me out.One of the ways to help that process along would be to use the 'Rate post' link on relevant posts.

Hi,

I have the same error when I try to install flash player 10. I had Macromedia Studio MX 2004 repackaging ages ago and it works well with other previous flash player until I try to push out flash player 10 and it has that error. I don't know where is this coming from and where will I fix it. If I think that my package for Studio MX is a problem then why it workx with other version of flash player version. But if I think it the flash player 10 causing the problem, then I really don't know what Adobe doing because I use the .msi from their website.

"Product: Macromedia Studio MX -- Error 1406. Could not write value to key \CLSID\{D27CDB6E-AE6D-11CF-96B8-444553540000}\InprocServer32. System error . Verify that you have sufficient access to that key, or contact your support personnel."

I try to open the Flash Player 10 through WSP or try to make the .mst file but can't find the related "key" in the package.

What should I do now, edit my StudioMX.msi or remake it with flash player 10 on local machine or do something with the Flash Player 10.msi

Thank you,
enzogoy

Are you installing with an account which has local admin privileges? If not, the install will fail as it needs to write values to the HKCR hive.

Equally, it could be that some rogue install has rewritten the permissions for that particular key. Check them out. If they're "broken", I would be tempted to build a separate MSI to fix them, rather than incorporate the required changes into an application's MSI.