Errata

This section discusses the way to copy a modifed user profile to overwrite the Default User profile. In Windows 7 this does not work as the "Copy To" button is greyed out.
If the author knows how to get around this I would love to know!

1. after the -ipk option a space is missing.

2.additionally: the command ipk retun with an error indicating that the entered code is not valid, is it is intended for upgrades, (0xC004F061)

3. -ato results in error (entered product code is not stored).

The book states: "This entire branch [HKEY_CLASSES_ROOT] is a symbolic link, or "mirror," of HKEY_LOCAL_MACHINE\SOFTWARE\Classes . . ."

The statement is not correct. HKEY_CLASSES_ROOT is a compilation of both HKLM\SOFTWARE\Classes AND HKCU\Software\Classes.

Referring to HKEY_USERS: "Because Windows only loads the profile (this portion of the registry) of the currently logged-in user, only one user branch will ever be shown here."

The statement is not correct. Windows will load the "profile" (that user's NTUSER.DAT and UsrClass.dat files) of every user then logged-in. However, only one user at a time will ever be the "current" user.

The procedure described here (backing up HKEY_CURRENT_USER), as well as the corresponding procedures on pages 160, 162 and 163, appear to have been created subject to a significant misconception: that backing up HKEY_CURRENT_USER will back up the current user's entire registry component. Such is not the case. Each user has two source files for their registry entries: NTUSER.DAT (at \Users\UserName\) AND UsrClass.dat (at \Users\UserName\AppData\Local\Microsoft\Windows\). When logged in, the user's NTUSER.DAT file becomes HKU\S-1-5-21-{SID} and the user's UsrClass.dat file becomes HKU\S-1-5-21-{SID}_Classes. HKU\S-1-5-21-{SID}_Classes is then "mirrored" at HKU\S-1-5-21-{SID}\Software\Classes\. And when that user is the currently active user, that user's HKU\S-1-5-21-{SID} is again "mirrored" as HKCU. But, backing up HKCU, either by using RegEdit to save a hive file or by the REG SAVE command, only backs up the current user's HKU\S-1-5-21-{SID} key, and that backup DOES NOT INCLUDE the "mirrored" keys under HKU\S-1-5-21-{SID}\Software\Classes\ or HKCU\Software\Classes\. To do that, you have to specifically back up (using RegEdit or REG SAVE) HKCU\S-1-5-21-{SID}\Software\Classes\ or HKU\S-1-5-21-{SID}_Classes. A helpful start in understanding the structure of the Registry is to view the values at the HKLM\SYSTEM\CurrentControlSet\Control\hivelist key (showing which registry source files are currently loaded into the Registry and their corresponding Registry branches).

The original line reads:
"REG SAVE HKLM\COMPONENTS C:\Backups\COMPONENTS"

When I executed it with administrator priviledges in command window, I received the following error message:

ERROR: The system was unable to find the specified registry key or value.

Following this example, the related code on page 162 will not work:
"REG RESTORE HKLM\COMPONENTS C:\Backups\COMPONENTS"
and on page 163:
"copy C:\Backups\COMPONENTS C:\Windows\System32\Config".

Should "COMPONENTS" be replaced by "HARDWARE"? But then the code on page 163 will not work, because in folder C:\Windows\System32\Config a file called "HARDWARE" does not exist!

Mr. David Karp, can you explain/help?
Thanks. Ben.

1. "REG SAVE HKLM\COMPONENTS C:\Backups\COMPONENTS" does not work - error message is "ERROR: The system was unable to find the specified registry key or value."

2. If "COMPONENTS" is indeed a Registry hive, then the above is a ~serious~ issue, since that means the code shown will not properly back up the Registry.

3. Or, what about "HARDWARE" (which ~is~ a Registry hive, but is not covered on the commands on page 160)?

4. I note that, among the unconfirmed errata, there are some that are now over a year old, yet the author has not responded to them.

5. Furthermore, the number of unconfirmed errata greatly exceeds the number of confirmed errata.

6. I think that the above two points do not reflect on O'Reilly and/or on David Karp very well - I am very disappointed with the usefulness of the errata pages.

7. A buggy book is as bad as buggy software, ~especially~ if the bugs are not handled.

To respond to the comments of the three previous entries, it appears that the answer is that the REG SAVE command will fail, as they indicated, if the target key/branch is not then loaded into the Registry PLUS the fact that, on my system at least, (Win 7 Pro SP-1, 32-bit), COMPONENTS (at \Windows\System32\config\) is only rarely loaded--thus resulting in the error message when REG SAVE HKLM\COMPONENTS is attempted to be executed. When not loaded into the Registry, the COMPONENTS file (as with any hive file) can be backed up with the XCOPY command. To see which registry source files are currently loaded into the Registry, view the values at the HKLM\SYSTEM\CurrentControlSet\Control\hivelist key. (I have no idea what it is that causes COMPONENTS to ever get loaded into the Registry.)

The book states: ". . . HKEY_CURRENT_USER . . . [is] backed up here, leaving . . . HKEY_USERS . . . seemingly unprotected. This is done because the data in HKEY_USERS is duplicated in . . . HKCU . . ."

That last sentence appears to be backwards. HKU is the greater and HKCU is the "mirror" of a lesser portion of HKU. See my comments at page 158, above.

REG SAVE HKCU . . . will NOT (at least in my experience) back up the current user's "user specific" Registry entries that are sourced from that user's UsrClass.dat file. See my comments at page 158, above.

For instructions on how to create a batch file which will back up (a) all Registry source files, whether or not then loaded into the Registry, (b) the Registry source files of all users, whether or not then logged in, and (c) each user's entire Registry data, sourced from both their NTUSER.DAT and UsrClass.dat files, see
http://richlang.home.pipeline.com/Reg/RegistryBackup.pdf

The book states: "To run this backup automatically every time you start Windows, create a shortcut to the back up registry.bat file in your Startup folder in your Start menu."

If one actually does this, at the point when their Registry does become corrupted, they will likely start and re-start Windows several times in their efforts to figure out and resolve the problem. In doing so, with the code on page 160, every time Windows starts, they will substitute a corrupted set of Registry backups for their previous good backups and will delete the oldest backup, the likely result being that they will, one-by-one, delete all their good backups and not have any when they finally figure out the need for them.

The book states: ". . . take this opportunity to back up the current state of the registry, as described earlier in this section."

The only possible conclusion that I can draw from that statement is that it refers to the "back up registry.bat" file, whose code appears on page 160. However, if one first executes the code in "back up registry.bat" and then attempts to execute the "reg restore" code later appearing in step 5, one will simply go around in a circle: restoring the current state of the registry that they have just backed up. And, in the process, will have deleted one potentially good set of backup files.

Instruction is to expand branches of Registry Editor to HKEY_CURRENT_USER\Control Panel\Desktop and then double-click the WaitToKillAppTimeout value.

My registry shows no such value, nor any of the other Wait* values.

I did a search for these values and the search returned no results.

This method does not work on Windows 7 and it was already not recommended on Windows XP (but did work there in a lot of cases without problems)

The recommended procedure from MS is shown here http://support.microsoft.com/?scid=kb%3Ben-us%3B973289&x=19&y=11

But this is for most users too complicated and far too much effort.

I have so far no easy solution for this annoyance, here you can find a lengthy discussion about it http://social.technet.microsoft.com/Forums/en-US/w7itprogeneral/thread/0be9b1f0-a21f-4889-9568-6ec455689aa9

From what I have found, the description of how to customize the default profile for new users applies to Windows XP but explicitly not Windows 7. The recommended procedure in Win7 is more difficult and involves Sysprep. I would very much appreciate a posting with a clear and detailed description of the steps in Windows 7.

The book states: "If the Public network caption is not clickable, then your network isn't fully functional; see Chapter 7 for troubleshooting tips." While this statement may be generally true, it is not always true. That is because Windows 7's "Unidentified network" bug may have come into play.

One may have completely and with 100% perfection set up an otherwise fully functional and operative network, and religiously followed all the troubleshooting tips in Chapter 7. However, despite all that, any attempt to connect to such network may still result in it being deemed to be an "Unidentified network", with the words "Public network" being fixed and non- clickable. The Bug manifests as the result of the following combination of factors:
(1) With some (most? all?) ethernet (other?) adapters, any attempt to set the "Default Gateway" value to the very same IP address as the computer upon which one is configuring IP addresses results in Windows (or the adapter software), fairly soon thereafter, deleting that IP address, leaving the "Default Gateway" value again blank.
(2) As a result, entering the IP address of the network gateway computer into the "Default Gateway" text box of that very same network gateway computer's ethernet adapter's TCP/IP properties is an exercise in futility, since it will fairly quickly be auto-deleted.

Combine that with the following:
(3) Windows 7 REQUIRES an IP address to be entered into the "Default Gateway" text box of its ethernet adapter's TCP/IP properties. Otherwise, during the initial network connection attempt, Windows 7 is unable to "identify" an (at least) ethernet network to which it is attempting to connect.
(4) When Windows 7 is unable to "identify" a network, it defaults to the name "Unidentified network" and it also defaults to a non-clickable (i.e. can't be changed by the user) "Public network" network location description.

Windows 7 has put the user into the following Catch-22 situation: Windows 7 requires that an IP address be filled in for the "Default Gateway" but, when the user, on the network gateway computer, enters the IP address of the network gateway computer into the "Default Gateway" textbox, Windows (or the adapter software) deletes that IP address.

The answer that worked for me was, on the Windows 7 network gateway computer, to enter into its "Default Gateway" property the IP address of another computer on the network. Everything worked properly after that. One might think that entering different "Default Gateway" IP addresses might cause some kind of conflict. But, so far, everything is working as it should. (Note: Manually inserting the IP address of another computer on the network as the "Default Gateway" value is necessary whether using fixed IP addresses or letting DHCP auto-assign the IP addresses.)

If Windows 7's "Unidentified network" bug is not the ultimate in "Windows 7 Annoyances", it certainly ranks among the top 10.

The description of sharing permissions to include the "everyone" group is not true on my machine. This observation continuing on to the next page and experiment is also not true.

Perhaps Microsoft has already patched this to operate differently than the OS version upon which the book was released?

On my system, the homegroup creation creates a "HomegroupUser" account and adds that to the share permissions. Then after leaving the homegroup, the share permissions turn to "unknownAccountxx-" but do not get removed. Yet nowhere does the "Everyone" group get used.