it's not the HKCU thing thats the problem tbh, it's just that each time the user logs off and back on, their local profile is replaced by the mandatory profile on the server.  somewhere in their old profile is something (pretty sure it's just reg keys) gets deleted causing the application to stop working.

I thought I'd fixed it, but turns out that I didn't.

so, i just need to know if it's possible to move these keys to somewhere else in the registry so they aren't deleted each time they log off, and if the application will still work with the keys in a different part of the registry.

I packaged up the FileNet suite for distribution via ZENworks 1.1 a while back and it really was a nightmare. The best way I found was to package up the entire suite and deliver it as one big application, this worked fine. If I remember rightly the FileNet apps write a database label to HKEY_USERS\.Default\Software\FileNet\IDM\neighrbourhood; without this the application would work once then fail. The ZEnworks Snapshot tool didn't scan that part of the Registry so this problem took a while to find.

If you need to grant access to keys and files or folders, and your install tool doesn't allow this, check out (free) RegDacle (for reg keys) and XCacls (for files and folders).

If the error you are getting is concerning the Filenet System Manager which starts up as the user logs in then the answer is a simple one but not pretty.

Filenet is trying to OPEN the HKCR key. Under the default user permissions it will fail because of the way its trying to open the key. FNSYSMGR expects to be able to write even tho it doesnt write at all.

You have to repermission the key to allow users/filenet app WRITE access to it.

Told you it wasnt pretty.

the software consists of FileNet IDM, FileNet Panagon Capture Pro, linked to a huge database of user correspondance which is accessed by a front end written in house.

the users have the first 2 apps installed locally, with a shortcut to the front end (think it was done in powerbuilder) pointing to that which sits on the server where the DB is.

funnily enough, they do have a Citrix farm (25 servers if memory serves) running about 20 or so apps for about 300 users, but even though they tried setting it up in citrix, it just wouldn't work properly.  it's a hefty app even when run locally, gobbling up up to 100+mb of memory before you ever even see the front end.

bringing up the app to a point where you can use it to browse scanned or faxed documents can take 5 minutes even on a P4 2.6 with 256mb of ram, so it's not exaclty MS Word we're talking about. [;)]

I don't know if the reason for not sticking it in citrix was down to the size of the thing, or for other reasons, but it just doesn't work.

they have a wide range of apps that do work fine, but that's not oen of them unfortunately.

The last time I packaged this monster I swore I had it just about working, but apparently not, as it stopped working correctly the next morning.

I'd packaged it logged on as local administrator using WinInstall 2003 LE, to minimise any unwanted user specific crap that might get into the thing, and it seemed to be working OK for a while, but then the next morning the server was down (unrelated to anything I did thankfully[:D]) and ever since it didn't work.

I'd made a copy of the registry file that WinInstall makes, and removed all but the [HKEY_CURRENT_USER] stuff and even though the app was not working after  alogoff, adding that back into the registry seemed to fix it.  I figured we could find a way of adding it silently to the users login script, and that would be it, but for some reason before I even got that far it stopped working.

shame really.

they're trying to get a packaging guru in to do a proper job of streamlining the MSI now, so it's out of my hands thankfully, but I'd still like to know if there's a way to do it properly.

vendor is no help either by the way cos it's an old version of the software, and apparently they looking into upgrading, but it was going to be too much of a job, so they kept putting it off. [&:]

I think your FIRST question needs to be, will the software you've repackaged WORK with values not in locations where that software expects to find them...

You might find a perfect solution for moving all your settings information to the ALL USERS folder or the HKLM hive, BUT, if software HAS to have that info in HKCU or in a specific profile, you're out of luck.

One thing a few of my clients have done for software which needs to work from a variety of locations and for a variety of account/profile types is use a Citrix Server solution.  Just a suggestion (and not a cheap one, unfortunately).

- Sean Roberts