To start with I'll say I've read the post here and I'm still having trouble.
I'm trying to create a CE6 image with a hive-based registry that actually stores results through a reboot.
I've ticked the hive settings in the catalog items.
In common.reg, I've set the location of the hive ([HKEY_LOCAL_MACHINE\init\BootVars] "SystemHive") to "Hard Drive\Registry" (Note: the flash shows up as a device called "Hard Drive")
In common.reg, I've set "Flags"=dword:3 in the same place to get the device manager loaded along with the storage manager
I've verified that these settings are wrapped in "; HIVE BOOT SECTION"
This is where it starts to fall over. It all compiles fine, but on the target system, when it boots, I get:
A directory, called "Hard Disk" where a registry is put
A device, name called "Hard Disk2" where the permanent flash is
Any changes made to the registry are lost on a reboot
What am I still missing?
Why is the registry not being stored on the flash?
Strangly, if I create a random file/directory in the registry directory, it is still there after a reboot, so even though this directory isn't on the other partition (where I tried to put it), it does appear to be permanent. If it is permanent, why don't registry settings save (ie Ethernet adapter IP addresses?)
I'm not using any specific profiles, so I'm at a loss as to what the last step is to make this hive registry a permanent store.
First, I hope you are not changing common.reg directly. You should never change public code. If you want to change public registry keys you need set them in your project.reg or platform.reg and they will override the public settings.
SystemHive should be set to the name of the directory to which you want to store the hive files without the name of the device.
In your case:
"SystemHive"="Registry\\system.hv"
Quote from the MSDN source:
Do not include the name of the file system on which the file is stored. The system will determine which file system to use based on other registry settings.
Update regarding your second comment (source):
If this value is present under HKEY_LOCAL_MACHINE, it indicates that the system hive has been restored successfully. If it is present under HKEY_CURRENT_USER, it indicates that the user hive was successfully restored.
Are you flushing the changes you make?
Check that you don't have a wierd implementation of IOCTL_HAL_GET_HIVE_CLEAN_FLAG (source) - your system might be returning a true value to clean the system registry every boot.
You can add a thread that will periodically flush your registry (though I'd recommend excluding it and let each application flush its own changes) - PRJ_ENABLE_REGFLUSH_THREAD
Related
I have an issue related to reading from the registry of Windows. I need to retrieve information about USB devices connected and removed before. The most important info for me is date/time of connecting and removing.
One of the paths I can get is this:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USBSTOR\Disk&xxx&xxx&xxx\xxxxxxxxxxxxx\Properties\{83da6326-97a6-4088-9453-a1923f573b29}\0065
In default mode I don't have an access to the branch Properties even when I try to open the key of registry via aGUI. I can change the settings of this particular key Properties to get an access, but another similar key Properties in another branches will still be closed. So the question is, why there is no access to them?
But when the key is opened there is no information about USB I can read using script based on the winreg Python library.
This data looks this way:
I found a module for processing the registry keys, https://github.com/woanware/usbdeviceforensics. Using this module, I have to pass the path to the hives of the registry and then to invoke the method process(path). I pass this path C:\Windows\System32\config where such hives like SYSTEM, SOFTWARE and others are located. But the module just skips reading some files because an error "Permission denied" appears. BTW I run the script with an administrator rights.
Why there is "Permission denied"? I can't use this useful module just because of this error.
I am trying to show and configure Quick Launch toolbar on Win 10 taskbar from command line / batch file / registry patch / PowerShell script / VBS / C# / C++. After searching the Internet, I was able to accomplish two steps out of three:
Pre-fill the "%USERPROFILE%\AppData\Roaming\Microsoft\Internet Explorer\Quick Launch" folder with the .lnk files that I want to appear in the Quick Launch toolbar - this is easy.
Force the Quick Launch to show on the taskbar by adding a specific blob into HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Streams\Desktop key, TaskbarWinXP value and restarting Explorer so that the changes take effect. The format of the blob is not documented, but this is of no concern to me - I simply need to ensure that the taskbar contains only Quick Launch toolbar and no other toolbars, so I can afford to just prepare the taskbar on a test machine, export the blob and then import it into the registry on target machine. And the Quick Launch toolbar does show up on the taskbar and shows all the links corresponding to .lnk files. Not the most elegant way, but it works.
Update 0: actually it does not really work - the account name is hard-coded in the blob as part of the path to the Quick Launch folder, so when moving from a test machine to the target machine the blob will not work if the username is different of the target machine. I guess I will need to reverse-engineer the blob format anyway in order to generate a correct one.
But, and this is where I am stuck, the Quick Launch toolbar needs further configuration programmatically, specifically:
Hide the toolbar title
Hide individual text for the link icons
Move the toolbar all the way to the left so that it is next to the Start button
I can't find any recipes for that.
These settings are not stored in the HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Streams\Desktop key, TaskbarWinXP value blob, I did binary comparisons of different versions of this blob before and after manual change, they are identical. They must be stored somewhere else.
Update 1: I was wrong, these values are stored in the blob, but they are not committed to the registry right away by Windows Explorer. It seems like Explorer holds these values in RAM and only commits them to registry when it terminates normally, e.g. during logout or reboot. If you terminate Explorer by killtask, it won't commit these changes.
I also tried spying on the system using SysInternals procmon64 while I perform these three actions manually with a mouse. Process monitor does not detect any meaningful and relevant activities with either registry or files during such manual manipulations, only a bunch of background noise. But Explorer has to store these changing settings somewhere... What am I missing?
Update 2: As I have mentioned in the update 1, the reason I don't see any registry traffic when I am manually creating the toolbar is because Explorer postpones registry commit until normal shutdown.
So, after all updates, I have quite opposite situation: I no longer have issues with item 3, but I do need to know the format of the blob stored in registry HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Streams\Desktop key, TaskbarWinXP value. Or a proper API to create such blob. Anyone has any pointers?
OK, I have solved my problems. And I did not have to reverse-engineer the blob format for that (although I have started that fun process and managed to learn a few things about its internal structure). Anyway, my solution was this:
On a clean test machine manually create a Quick Launch toolbar using the mouse, but, when asked to specify the path to the toolbar folder, instead of navigating step-by-step to C:\Users\<insert_your_fixed_username_here>\AppData\Roaming\Microsoft\Internet Explorer\Quick Launch, which would commit a fixed username into the blob as part of the path, you need to specify "%USERPROFILE%\AppData\Roaming\Microsoft\Internet Explorer\Quick Launch" in Select Folder dialog as one line (the starting location for the Select Folder dialog is not important in this case). When you do that, Explorer will create a blob where the current user name is not hard-coded, and instead the environment variable %USERPROFILE% name is placed in the blob. This makes the blob re-usable for any user I want to deploy the Quick Launch toolbar to.
Adjust the Quick Launch the way you desire (title, text, position, width, icon order).
Log out from your account on test machine and log right back in. This is critically important - if you do not log out or if you kill Explorer, it will not commit your new toolbar settings to the registry.
Export HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Streams\Desktop key from the registry into the .reg file for future use.
The rest is easy, write a batch file that does the following:
For each given user on the target machine prepares the "C:\Users\<insert_your_fixed_username_here>\AppData\Roaming\Microsoft\Internet Explorer\Quick Launch" folder and places necessary .lnk files there and deletes unnecessary ones.
Imports .reg file into the target machine registry (reg import command).
Kills and restarts Explorer: taskkill /f /IM explorer.exe & start explorer.exe
Now any desired user on your target machine will have exactly one Quick Launch toolbar and no other nonsense toolbars! And the toolbar will have the look and feel you want.
Tested on both real and virtual machines, works equally well.
Caveat: did not test on non-English version of Win10, and I expect localization issues because some folder names are hard-coded now.
We have app data folder redirection group policy in place. We are moving back to local appdata which is currently redirected to network share. Also, the option to move the contents to new location in gpo is enabled. On many occasions the policy is failing due to content move with several reasons (256 character limit, permission issues, etc).
My question is lets say hypothetically disabling the move content to new location in GPO is not an option here. I am changing the registry HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders AppData to %userprofile%\AppData\Roaming on user’s laptop, getting the user to reboot the machine. After that, when user logs in, the GPO will now check the registry which is already set to local, it will not move the contents and successfully complete the policy. I have tested and it works.
This may not be right way of doing it, will there be any issues using this method going forward in terms of user’s app data location ?
In our LINUX box, due to some security reasons we need to test out a Database connectivity using an alternative tnsnames.ora file, instead of making changes directly in the default file under /network/admin. For this reason, after setting $ORACLE_HOME, we are also setting TNS_ADMIN, which points to a dummy tnsnames which we need to use.
For example : export TNS_ADMIN=/psapps/admin/tnsnames.ora
However, even after setting this file, when tried to tnsping, Oracle still uses the default tnsnames.ora
Any suggestions in this matter ?
TNS_ADMIN should point onto a directory, not onto a particular file.
There can be other files in this directory, for example sqlnet.ora.
Recently our development team received new pc's. In an effort to make this transition smoother, I would like to be able to explain to my co-workers how to continue using the client they already have set up to pull files to and from the new pc while eventually ignoring the old pc workspace altogether.
I know about adjusting the attributes of the client itself and allowing the client to be accessed by different hosts. What I'm looking to do now is update the perforce have list for the given client to reflect the files (or lack thereof) that are on the new pc's file system (in the correctly mapped location, obviously).
I'm not sure if it is possible with the p4 flush command for perforce to know which revision of an existing workspace file i have without explicitly telling perforce which revision it is...? (this seems like its asking a lot)
Apart from files that Do exist in the workspace, is there a command that will update the have list to #0 for files that don't exist in the workspace?
OR
Is the sledgehammer approach:
submit any pending changes in the old and/or new workspace
remove any files that may have already been forced into the (new) workspace
$:p4 flush [workspace root]/...#0
appropriate in this situation?
If using the existing workspaces is an option, then this should be pretty easy. It sounds like you already know how to make a workspace accessible from a different host (you can leave it blank to make it accessible by any host). If you copy the workspace folder to the new PC, and update the root of the workspace as necessary, it should "just work" without any additional changes.
If I'm understanding your question correctly, I believe that using a workspace name as your revision modifier will do what you want. For example p4 flush //depot/path/some/file#workspacename. For new machines, we often go through these basic steps to avoid having to resync files.
Copy the files in the workspace from machine 1 to machine 2
Create a client that matches the old client's mappings
In the new client, run:
p4 flush //depot/...#oldclientname