[Last Call] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 840
  • Last Modified:

Registry Key for All Users under Win 7

We produce a piece of software that under Win XP wrote a series of settings to HKLM at installation time. These were then used by any user on the machine.

Win 7 64 bit however moves these to some weird and complicated (surely not under MS!!!) location under the current user.

How can we write these initial settings so that all users can see them under Win 7 64 bit? The only solution we have come up with is to put them into current user, have the app write them to a .reg file on exiting then when the next user loads the app, it copies this file to the Registry - very complex and unsatisfactory.

Many thanks.
0
ChrisJonesLycos
Asked:
ChrisJonesLycos
  • 11
  • 9
  • 7
  • +1
1 Solution
 
McKnifeCommented:
Hi.
Please be more specific. What complicated path is it? It might have to do with file and registry virtualization.
0
 
che6auscCommented:
HKEY_CURRENT_USER is just HKEY_USERS for the currently logged on user.  So really you only have to create the registry entries in HKEY_USERS the first time a user logs on.  It will be transferred to HKEY_CURRENT_USER automatically.

0
 
ChrisJonesLycosAuthor Commented:
Hi che6ausc
Where exactly do I put it in HKEY_USERS?
When I look there, there are headings:
.DEFAULT
S-1-5-18
S-1-5-19
S-1-5-19_Classes
etc
Nothing particularly obvious for putting our company name and product name.
0
Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

 
che6auscCommented:
The sid number is assigned to the user in this case it is S-1-5-19.  If you open the key and look under volatile environment you will see the username.  See attached.

I am not sure exactly what you are trying to do.
Capture.jpg
0
 
che6auscCommented:
This sid number gets transferred to the HKEY_CURRENT_USER hive when the user logs in.
0
 
che6auscCommented:
There is one sid number for every user.
0
 
che6auscCommented:
The settings that you see there in the registry under HKEY_CURRENT_USER and HKEY_USERS are stored in the file ntuser.dat in the c:\users\username folder.  Whenever you logoff the registry settings are stored there until the next time you logon.

HKEY_CURRENT_USER and HKEY_USERS for a specified user don't exist until that user logs on.

0
 
ChrisJonesLycosAuthor Commented:
I still don't understand completely.

If I want it to be available to ALL USERS where exactly do I put it in HKEY_USERS?

Out of interest also, when I look in my Volatile Environment it doesn't have USERNAME.

Many thanks
registry.bmp
0
 
che6auscCommented:
If the settings are different for each user,  you will have to put them in the user hives under software key.  Otherwise they should be placed in HKLM/software for all users.

It is a function of the installer to place the setttings in the proper category.  I cannot understand why you have given up on HKLM.  It is inherent that all third party installers place the settings in the proper category. If you had them there before, it may be a case of some minor revisions.

You will have to be more specific for anyone to help you.
0
 
ChrisJonesLycosAuthor Commented:
Win 7 64-bit moved our HKLM settings to:

HKEY_CURRENT_USER\Software\Classes\VirtualStore\MACHINE\SOFTWARE\Wow6432Node
\MyCompanyName\MyProductName

when the app wrote to them and then kept this divert going throughout the session.

Since another app which didn't write to the key was still reading them from HKLM and Win 7 allowed this, total confusion prevailed.
0
 
che6auscCommented:
Create an autoexec.bat file in the all users startup folder that executes a .reg file with the registry settings.  Each time a user logs in, the registry settings will be merged into the registry.  This is an odd way to do it, but will have to do, if the proper changes are too complicated for your level of experience.


0
 
ChrisJonesLycosAuthor Commented:
We have over 2000 users using this software in various companies round the world. Most of their IT Managers would not be too happy to place an autoexec.bat in a startup folder.

You say "if the proper changes are too complicated for your level of experience". Regardless of my level of experience, what are the "proper changes". This is what I'm trying to find out.

(It does however seem to me that once again Microsoft have taken something very simple that the majority of companies need to do at some point and turned it into something monstrously complicated.)
0
 
che6auscCommented:
Microsoft has defined api's for reading and writing from application software to the registry. Thousands of companies create software whjch writes program and user settings to the registry. The problem you are encountering is not unique.   It is a matter of making the proper changes to the already existing software.

I believe your problem is related to registry virtualiztion as outlined in the following link: http://msdn.microsoft.com/en-us/library/aa965884%28v=VS.85%29.aspx

0
 
che6auscCommented:
Registry virtualization was intended to make legacy applications compatible with Vista/7.  The redirects are supposed to be transparent to the user.  From that standpoint, I cannot understand why you would be encountering any problems.  Any registry operations should automatically be redirected to the virtual store.
0
 
che6auscCommented:
You may have to run the install as an administrator to write the settings to HKLM, since with the introduction of Vista, standard users are not allowed write access to system areas of the registry.  
0
 
ChrisJonesLycosAuthor Commented:
Our software writes to and reads from the Registry using those Windows APIs :-)

Within our software suite all the applications use the the same Registry settings. Some write to it and some read from it. When an app writes to it, the key is virtualised under the current user. When another app reads from it, Win7 allows it to simply read from HKLM. If the writing app has changed the values in that key then the reading app doesn't know about them in HKLM. We therefore want a location where all users can read the same key values without Win7 moving them to HKCU.

Hence my original question. You say above that you can do this in HKEY_USERS by making the "proper changes". My question therefore is, what are these proper changes?
0
 
che6auscCommented:
This is a quote from the previous link I provided: http://msdn.microsoft.com/en-us/library/aa965884%28v=VS.85%29.aspx

"Virtualization is intended only to provide compatibility for existing applications. Applications designed for Windows Vista and later versions of Windows should not write to sensitive system areas, nor should they rely on virtualization to remedy any problems. When updating existing code to run on Windows Vista and later versions of Windows, developers should ensure that applications only store data in per-user locations or in computer locations within %alluserprofile% that properly use an access control list (ACL)."

I think that the most appropriate thing to do would be to revise all existing code in all software applications so that it only stores and retrieves data in/from per-user locations.  This is not what you want to hear, but it is the proper way to approach the problem.  This would mean revising the code so that the function calls no longer store and retrieve data from HKLM but from HKEY_USERS.

You may be able to bastardize the existing code by creating intermediate files or whatever, but I do not see that as a permanent fix for upgrading from XP to Windows 7.

0
 
McKnifeCommented:
Chris,
without admin rights, no software will be able to write to HKLM. In xp, your users were admins or power users (which is almost the same). In vista and win7, power users don't exist any more (by the way @che6ausc: you wrote "since with the introduction of Vista, standard users are not allowed write access to system areas of the registry" which is wrong, standard users were never allowed to write to HKLM, nor to c:\windows or c:\program files, power users were).

Simply have your app be installed with admin rights. If the virtualized folders (which I asked you about right from the start) were used, then
-either no admin accouint is used to install
-an admin account is in fact used but UAC elevation is not triggered, the admin does simply not use his rights/privileges. In that case, your app has to be made UAC compatible.
0
 
ChrisJonesLycosAuthor Commented:
Hi McKnife. The program is always installed by an Administrator. Is this different to installing with Admin rights? How exactly do we install with admin rights?

Thanks
0
 
McKnifeCommented:
To make sure, use an admin account and rightclick the setup and select "run as administrator". Some setups need this rightclick option because they are not UAC compatible and don't use the admin token (although executed by an admin).
0
 
ChrisJonesLycosAuthor Commented:
And just to double check with you, does that mean that *any* user thereafter will be able to write to HKLM without it getting virtualised to somewhere in HKLU?
0
 
McKnifeCommented:
No, of course not. You have to point out if you are really talking about settings that aer set once, during installation. If yes, no problems are to be expected. If no, and the program for example tries to write user based settings to HKLM instead of HKCU (which is a no go), there is no way around that but to change the program.
0
 
ChrisJonesLycosAuthor Commented:
So I'm still confused here. If at installation time we set the Key that we're using in HKLM to have Full Control by all users, will Win7 then NOT virtualise that key?

I'm basically looking for a way of reading and writing data to the Registry in a way that all users can use and share it. It seems very simple but Win7 seems to offer no easy solution.
0
 
McKnifeCommented:
We don't know how your application works. If you know, tell us: does it write to HKLM only on installation or during work? Without answering this, we are stuck.
0
 
ChrisJonesLycosAuthor Commented:
Explained above but ...
All our applications use the Registry all the time
Some read & write, some only read.
For the ones that write, the keys are virtualised so the data gets written to HKLU, not HKLM
The ones that read, read successfully from HKLM.
However the apps that read only need to see the data that the apps that write have written.
Because of virtualisation in win7, these end up in two different places.
0
 
McKnifeCommented:
Ok, I was aksing again bevcause I did already answer it, I suppose.
In xp this was no problem because your users were admins (or power users) - this way the incorrect behavior of that program (to write settings to HKLM is very bad practice) was no problem. Now with win7, even admins cannot write to HKLM without elevating. Again: elevation is the process of using your full admin rights - this takes place after the admin was asked "are you sure you want to continue" by UAC. UAC gets triggered on installation of programs (at least in 99%), not while using (at least most programs don't trigger UAC).

So if your program is not compatible to UAC you can only
A change the program
B turn off UAC and make the user and admin
C grant write permissions on that specific subbranch of HKLM to the explicit user names that need it
0
 
McKnifeCommented:
B should read
B turn off UAC and make the user an admin
0
 
DansDadUKCommented:
Perhaps you could:

- move the registry read and (particularly) write functions of your various applications to a separate 'application'.

- run this 'application' as a service (of a type with the required rights) which starts automatically on boot-up.

- then your 'real' applications make calls on this service to read and write on their behalf.
0

Featured Post

VIDEO: THE CONCERTO CLOUD FOR HEALTHCARE

Modern healthcare requires a modern cloud. View this brief video to understand how the Concerto Cloud for Healthcare can help your organization.

  • 11
  • 9
  • 7
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now