I'm a new to Windows Administration. Is it true that all the GPO's affect registry keys in some way? Are there any GPO settings that don't affect registry keys at all? I apologize for asking a very generic qn.
In very short: Yes, there are.
Slightly longer answer:
Group Policy Object consist of 2 parts: policy (a true GPO) and preferences (called GPP)
Policy settings are in 99,9% of cases written into a target machine registry.
Preferences on the other hand can set a lot of things:
create/ delete a folder
add a printer
add a local user
etc....
Related
I´m trying to make some changes(Wallpaper/Themes) on a windows7 enviroment, until now, I copied some files in to a directory with admin rights, so the "hard" part is over.
Trying to change the registryKey with a batch or with a Powershell file will work, as an Admin and as a normal-user.
The bad thing is, if I try to make the changes as an Admin, then the changes will be just for the adminSession. And I want to make the changes for the normalUser and every new user(with not admin rights).
I found that with a batch file, I can make some changes to my normalUser account:
HKCU:\Software\Micorsoft....\Themes\ and change the value CurrentTheme to my own Windows theme.
If I check my registry, I notice that the CurrentTheme value was accepted, and after a reboot stay so.
But Windows shows me the default theme... ¬¬
I tried to change "everything" to set my Theme as default, but nothing works..
Is there a way to make it works? Why windows is refusing to take the changes in the registry and always show me the default Theme?
Go to HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows
In the left pane, right click on Windows and click on New and Key. Type Personalization and press enter (if not already exists).
Create a New and String Value called ThemeFile and press Enter. Right click on ThemeFile and click on Modify. Type in the full path of the .theme file with file extension in "" (example: "C:\Users\UserName\AppData\Local\Microsoft\Windows\Themes\NewCustomTheme.theme") ; it will be default for new users.
Are the systems on a domain?
You should know that registry values stored within the Policies key and all the subkeys after that can be reset by domain group policy at any time. That is to say that if you make a change here and reboot or run gpupdate, you can expect the values to be erased.
If you really want to change the theme for all users, you should use Group Policy to apply the theme, as seen in this link. Group Policy Settings for Windows Personalization.. Look in the section under "Set a Specific Theme".
I've done this for clients a number of times. You can also set a specific theme as the default by logging on as the Default Profile and making changes. Keep in mind that this approach should be done when you build a system image to deploy to the environment.
I have my application written in Delphi XE that works with PDF files. Applicaiton is Win32. On start I would like to ensure that there is my item in explorer context menu for PDF files. I would like to be able to specify whether it should be added for active user only or for all users (with UAC I will need to restart with Admin privileges but thats ok).
I started with How to associate a Delphi program with a file type, but only for the current user? and How to add item to windows explorer content menu in delphi? . I tested it with manual registry editing via regedit and it worked fine for "new" extensions. But for .pdf it is more complicated as it will be most probably already present in the registry.
On my PC the .pdf key is referencing AcroExch.Document . But adding shell/something subkey to the AcroExch.Document key is not working because it has CurVer subkey referencing to AcroExch.Document.7. However another PC with another verison of Acrobat had this names a little different. It is no problem for me to follow the CurVer reference but is that a correct approach? And what about situation where no PDF reader is installed, how should I name my keys so Acrobat won't overwrite them when installed?
But more pressing matter is in which root should I put my keys? How to associate a Delphi program with a file type, but only for the current user? is mentioning HKLM (Local Machine) and HKCU (Current user). Its seems rather straightforward but I am unable to set values in HKLM from Delphi. Strangely I can create keys:
var reg:TRegistry;
key := '\Software\Classes\'+keyname+'\shell\'+name+'\command';
reg.CreateKey(key);
but I am getting Access Denied when trying to write the actual value:
reg.OpenKey(key,false);
reg.WriteString('',command);
I am getting the same Access Denied exception even on WinXP, no matter if the applicaiton is running as Admin (Win7), I even tried to set permissions (Everyone full control) for the key via regedit (I can edit the value via regedit without problems). I tried creating the registry with different access modes, all with no luck:
reg := TRegistry.Create(KEY_WRITE or KEY_WOW64_64KEY);
reg := TRegistry.Create(KEY_ALL_ACCESS or KEY_WOW64_64KEY);
reg.Access := KEY_ALL_ACCESS;
reg.Access := KEY_WRITE or KEY_WOW64_64KEY;
reg.Access := KEY_ALL_ACCESS or KEY_WOW64_64KEY;
With HKCU everything works fine.
So I tried writing into HKEY_CLASSES_ROOT and it works and actually puts the keys exactly where I want (into HKLM) if running as Admin. But according to http://msdn.microsoft.com/en-us/library/windows/desktop/ms724475.aspx
The HKEY_CLASSES_ROOT (HKCR) key contains file name extension associations and COM class registration information such as ProgIDs, CLSIDs, and IIDs. It is primarily intended for compatibility with the registry in 16-bit Windows.
I do not like the note about the primary purpose being compatibile with 16-bit Windows. And the actual conditions where the changes will be written is more complicated than I would like.
So basically I have these questions:
What is the advantage of using AcroExch.Document and CurVer instead of pointing directly to AcroExch.Document.7? And what are the "best manners" when adding my keys into this structure? What about the case when the .pdf is not yet associated with anything?
Where should I put my keys and why I am not able to write into HKLM?
Edit:
The problem with Access Denied when writing to HKLM was caused by my error. I did use in previous code openKeyReadOnly and I did not notice that it will swtich the Access property to readonly for all subsequent calls.
To answer your other question, if Adobe is not installed yet then obviously the PDF keys will likely not exist in the Registry yet so you would have to create your own .pdf and ProgID keys so that you can attach your Shell command on it. If Adobe is installed afterwards, it is likely going to wipe out your keys and replace them with its own, so you would have to recreate your Shell command within Adobe's key structure. Your app can query the Registry to check for that condition periodically, such as at startup.
You have asked two separate questions. Since I know the answer to one and not the other, I'm going to answer just one. For future reference, I do recommend that you ask a single question at a time.
Where should I put my keys?
You are correct in discerning that you should not use HKCR. The documentation for HKCR says:
Class registration and file name extension information is stored under
both the HKEY_LOCAL_MACHINE and HKEY_CURRENT_USER keys. The
HKEY_LOCAL_MACHINE\Software\Classes key contains default settings that
can apply to all users on the local computer. The
HKEY_CURRENT_USER\Software\Classes key contains settings that apply
only to the interactive user. The HKEY_CLASSES_ROOT key provides a
view of the registry that merges the information from these two
sources. HKEY_CLASSES_ROOT also provides this merged view for
applications designed for previous versions of Windows.
....
If you write keys to a key under HKEY_CLASSES_ROOT, the system stores
the information under HKEY_LOCAL_MACHINE\Software\Classes. If you
write values to a key under HKEY_CLASSES_ROOT, and the key already
exists under HKEY_CURRENT_USER\Software\Classes, the system will store
the information there instead of under
HKEY_LOCAL_MACHINE\Software\Classes.
So, it is reasonable to use HKCR for reading, but for writing you typically need to exert control over whether to write to HKLM or HKCU. And that means that you cannot write to HKCR.
So, write to HKLM\Software\Classes for machine-wide settings, and HKCU\Software\Classes for user-specific settings.
Note that in Windows 7 and later neither of these keys is redirected and so you do not need to worry about using KEY_WOW64_64KEY. However, in Vista and XP64, and the equivalent server editions, these keys are redirected and reflected. Which means that it might be prudent to use KEY_WOW64_64KEY.
I'm constructing a batch file that will auto-configure Windows 7's regional settings for all users.
So far, I've successfully been able to set (mostly) all of the regional settings for the current user, but I need to be able to apply the same settings to all new users. You can do this via the GUI, by going into Region and Language > Administrative > Copy Settings and selecting both checkboxes. I would like to do this programmatically, though. Does anyone know of a registry key I can set or something that will do this?
Failing that, I'll settle for a way to programmatically open the Region and Language > Administrative > Copy Settings window. I've been able to successfully open the Region and Language > Administrative window with start rundll32.exe shell32.dll,Control_RunDLL intl.cpl,,3, but I would like to eliminate one more step from the process, if possible.
Update
Sorry, I seem to have forgotten to mention how I'm applying these settings. I'm doing this by executing an exported .reg file, that contains the optimal settings, with regedit.exe /s "regional.reg"
How are you applying the settings now? Via the registry?
If you put the settings under HKEY_USERS\.DEFAULT instead of (or in addition to) HKEY_CURRENT_USER, they should be used during profile creation.
I know that many questions are asked about how customizing the shell context menu, but what I've tried yet doesn't work so I'm adding a new question.
I'd like to add an entry "Open with Log Viewer" in the context menu when right-clicking on files with ".log" extension, to not change the default application associated with .log files (notepad) but allow the user to choose a custom application to open them.
To do this, I opened the registry key HKEY_CLASSES_ROOT\.log, and added some keys shell\OpenWithLogViewer\command with the correct values, but the entry is not displayed when I right-click on a file with .log extension.
Would you know how to fix this?
The key HKEY_CLASSES_ROOT\.log has for default value txtfile, and contains a subkey called PersistentHandler. Can this subkey be the origin of the problem?
Add another registry key (e.g. HKEY_CLASSES_ROOT\logfile), create the shell structure below that key and change the default value of the .log key to logfile. One way to do this is by saving the following lines to a .reg file and merging that file into the registry.
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\.log]
#="logfile"
[HKEY_CLASSES_ROOT\logfile]
[HKEY_CLASSES_ROOT\logfile\shell]
#="OpenWithLogViewer"
; make OpenWithLogViewer the default action
[HKEY_CLASSES_ROOT\logfile\shell\OpenWithLogViewer]
#="Open with &Log Viewer"
; set label and access key
[HKEY_CLASSES_ROOT\logfile\shell\OpenWithLogViewer\command]
#="\"C:\\path\\to\\logviewer.exe\" %1"
This separates the type (logfile) from the extension (.log). That way you can define the possible actions for a type in one place and associate arbitrary extensions with that type.
Note that you can also define this on a per-user basis by using HKEY_CURRENT_USER\Software\Classes instead of HKEY_CLASSES_ROOT. User entries take precedence over system entries. This is useful when you want to change file associations or add custom actions for your own user, but don't have admin privileges on the system.
If you want to add a entry for a file extension you don't "own" and you never want to be the default action then you can use the SystemFileAssociations key:
[HKEY_CLASSES_ROOT\SystemFileAssociations\.log\shell\mycommand]
#="My Command"
[HKEY_CLASSES_ROOT\SystemFileAssociations\.log\shell\mycommand\command]
#="\"c:\\path\\myapp.exe\" \"%1\""
To deal proactively with the consequences of a change to default programs, you can use HKEY_CLASSES_ROOT\SystemFileAssociations to register verbs and other association information. Due to their location after the ProgID in the association array, these registrations are lower priority. These SystemFileAssociationsregistrations are stable even when users change the default programs, and provide a location to register secondary verbs that will always be available for a particular file type.
This key is available on Windows XP and higher...
I need my application installer set the program to auto-startup for all users.
Then each individual user should be able to modify this option without affecting others.
Currently I write to HKLM/../Run with installer, which acomplishes the first task.
But then I can't disable autorun for current user, because deleting th HKLM/../Run entry would disable it for everybody.
Is there a way to do that, without using shortcuts in Autostart folder?
start it for all users always but check a configuration variable in HKLU to see if it should exit immediately
Any reason not to use the HKCU Run key in the first place?
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run]