KACE Product Support

HKEY_USERS\S-[random string of numbers based on logged-in user]
Change these registry entries to Registry.Root=1 instead (HKEY_CURRENT_USER).

Okay, I admit it: everytime I start thinking I know something about packaging, I'm reminded that I really don't. I'm not sure what it is that I'm supposed to be changing to Registry.Root=1 (I Googled it and checked the AppDeploy forums, really), other than I know I can't actually rename the key with the string of numbers in it.

Here's the particular reg info:[HKEY_USERS\S-1-5-21-1659004503-2025429265-682003330-500\Software\WhiteCanyon\MW1]
"CO"="XMP-44"
"Dliubruc"="(Build 04.11.04)"
"UIL"="C:\\Program Files\\WhiteCanyon\\MediaWiper"
"Out"="2353523905"
"ProgGroup"="MediaWiper"
"DNS"=dword:00000000
"ROL"=dword:00000001
"Update"=dword:00000000
"UpdateTime"=dword:00093a80
"LastCheck"=dword:4995b4cc

Sorry, you should also change the Registry.Key column value to "Software\WhiteCanyon\MW1".
The current registry key points to the user's hive that made the MSI which seems to be the build-in Administrator account (RID=500).

I don't know why the AppDeploy Repackager didn't change these to the proper key value.
Lets way if Bob has any comments on this.

AngelD, I think the 500 is there because I was testing the install with both my usual username/password, and a generic administrator account I use for testing. The admin acct. was what I was logged in as when I copied the reg key, and the string of numbers in that key is what I see changing depending on who logs in. I had another user log in and install the app, and the reg key is different for her, too. So I'm still not at all clear on how to modify the registry to make the info under HKEY_USERS\[some random string] to be more generic. Specifically, I'm not sure what you're referring to by Registry.Root=1, or in the last post, changing the Registry.Key column value. Sorry if I'm being obtuse.

I'm still not at all clear on how to modify the registry
Get an MSI editor like InstEd (or ORCA) to manually change these or by a script, your choice [;)]

Sorry, I should've been more specific.
I know how to modify the registry; I'm not sure what it is you're telling me to modify.
When you say "Change these registry entries to Registry.Root=1 instead (HKEY_CURRENT_USER)", I'm not sure what it is you're telling me to do. Likewise for "you should also change the Registry.Key column value to 'Software\WhiteCanyon\MW1'. "

The clue is in "Registry.Root" where Registry is the table and Root is the column name in the Registry table. You'll see this notation in several posts, so now you know.

So that would mean; change the column (Root) value and set it to a value of 1 and change the Registry.Key column value to 'Software\WhiteCanyon\MW1'.

Either I'm not getting it or you need to be more specific then previous posts in your description.

Okay, the light bulb just went off in my widdle pea bwain: I was thinking regedit, and you've been talking MSI-type editor, like you'd mentioned earlier. So a big honkin' DUH for me.

I just edited the MSI in Orca and got the app to install properly. Got a couple minor things to fix--I broke the desktop & Start > Programs shortcuts, but otherwise I just tested w/ 2 different logins and it works correctly.

Thanks again for the help!

Nice!

I guess it's difficult to understand each other when we refer to two different things [;)]

We'll take a look at why the MSI was ending up with a user SID registry path in the first place on this side.

Great Bob!

RonW,

Could share the xml file produced by the repackager?

If not, then please tell us what the Registry.Root and Registry.Key value was for the ex. "HKEY_USERS\S-1-5-21-1659004503-2025429265-682003330-500\Software\WhiteCanyon\MW1".

AngelD/Bob, apologies, but I don't have a copy of the recipe file. I was on the 12th try or so of remaking the MSI and had got in the habit of not saving the xml file out of my VM environment, since I wasn't using it for anything.
But I know that the value of Registry.Root for the reg entries noted was 3, and the Key value in question was S-1-5-21-58594938-1643607424-60295696-16766\Software\WhiteCanyon\MW1. The S-string value would change depending on whether I created the MSI under my own account or under a generic Admin account used for testing.
Which leads me to another question. I thought I had the MSI fixed, making the registry edits noted previously in this thread, but now the app is still broken in that only the user who installs it can use it, and I'm not sure at all how to go about fixing that.

Even though the SID (user) string shouldn't be there it will in your case be the SID of the user whom you used during the capture (install) the original setup.

Regarding your "other" issue.
If the installation adds HKCU registry or file under the user's profile you need to make sure there exist entrypoints (ex. advertised shortcut) to trigger a repair which will "install" these missing resources for the user who triggered it (ex. launched the advertised shortcut).
Why it isn't working in your case may be due to the "incorrect" HKCU (current user) registry as it points to a specific user's registry hive (SID).

So, first you need to make sure to change the registry as we spoke about above and that the ex. shortcut is installed as advertised shortcut instead of a normal shortcut.

Here's an unexpected wrinkle: one of our support staff installed this application from the original exe so we could deliver it to a user. And when the user launched the app, they got the exact same error I've been seeing in trying to make the MSI I built work.

So it sounds like there's no point in Bob spending any time looking at this to see why the AppDeploy Repackager didn't work.

And so my next order of business will be to get a working exe.

I'll also be adding to my testing procedures to confirm the provided exe is a good one, before I start banging my head against my computer trying to figure out why my repackaged solution won't work...

Well, any "packaging" capture tool should change HKEY_USERS to HKEY_CURRENT_USER.

If this is hard-coded in the application I would try to shim this to redirect to a more proper location.
Have you check if the registry path is written somewhere else so you maybe could change that value instead of shiming it?

I checked the registry in the exe from the vendor, and it's not writing the data anywhere else. I've tried importing the key to different locations to no avail. Any attempt to remove the data from its HKEY_CURRENT_USER location breaks the application.