Discussion:
An interesting registry fix
Add Reply
T
2017-06-02 17:34:37 UTC
Reply
Permalink
Raw Message
Hi All,

Yesterday when trying to activate a new piece of software
for a customer. It had an interesting hiccup that I though
you guys would find interesting.

One of the machines popped a corrupted key on

[HKEY_LOCAL_MACHINE\SOFTWARE\xxxxx\yyyyy\Licensing\11.0]

"Permissions Denied but you can change its security permissions".
(Probably not the exact quote).

Its security properties were all blank. All attempts to add
users to the security dialog were ignored. I couldn't rename
or erase it either.

RegKeyFixer popped "permission denied" the same error when
I tried to erase the key.

Didn't matter if I was Administrator or not.

So I booted into Fedora Core 25 (Linux) from a flash drive,
ran "chntpw", and removed the key. Rebooted into
Windows, this time the activation dialog worked.

Linux rescues Windows again! It pays to know more than
one operating system.

:-)

-T

chntpw is a little weird at first, but realizing all you
have to do is enter "?" and it gives you a set of
commands makes it a lot easier.

And do not quote out keys with spaces in them. It sees
the quote mark as part of the name.
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Serious error.
All shortcuts have disappeared.
Screen. Mind. Both are blank.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Fokke Nauta
2017-06-02 17:44:20 UTC
Reply
Permalink
Raw Message
Post by T
Hi All,
Yesterday when trying to activate a new piece of software
for a customer. It had an interesting hiccup that I though
you guys would find interesting.
One of the machines popped a corrupted key on
[HKEY_LOCAL_MACHINE\SOFTWARE\xxxxx\yyyyy\Licensing\11.0]
"Permissions Denied but you can change its security permissions".
(Probably not the exact quote).
Its security properties were all blank. All attempts to add
users to the security dialog were ignored. I couldn't rename
or erase it either.
RegKeyFixer popped "permission denied" the same error when
I tried to erase the key.
Didn't matter if I was Administrator or not.
So I booted into Fedora Core 25 (Linux) from a flash drive,
ran "chntpw", and removed the key. Rebooted into
Windows, this time the activation dialog worked.
Linux rescues Windows again! It pays to know more than
one operating system.
:-)
-T
chntpw is a little weird at first, but realizing all you
have to do is enter "?" and it gives you a set of
commands makes it a lot easier.
And do not quote out keys with spaces in them. It sees
the quote mark as part of the name.
Good info.

Linux is not too bad, as a matter of fact it's better than Windows.
It is that I purchased a hell of a lot of software for Windows that is
not available on Linux, otherwise I would have used Linux already for a
long time.
I have a lot of rescue cd's that run on Linux. Very useful in case
something gets wrong with Windows.

Fokke
Auric__
2017-06-02 17:47:11 UTC
Reply
Permalink
Raw Message
Post by Fokke Nauta
Linux is not too bad, as a matter of fact it's better than Windows.
It is that I purchased a hell of a lot of software for Windows that is
not available on Linux, otherwise I would have used Linux already for a
long time.
That's the same reason I'm still on Windows.

Wine runs a lot of Windows software with varying degrees of completeness, but
it just isn't... quite... there yet.
--
How odd. To know everyone's heart but my own.
T
2017-06-02 18:59:30 UTC
Reply
Permalink
Raw Message
Post by Auric__
Post by Fokke Nauta
Linux is not too bad, as a matter of fact it's better than Windows.
It is that I purchased a hell of a lot of software for Windows that is
not available on Linux, otherwise I would have used Linux already for a
long time.
That's the same reason I'm still on Windows.
Wine runs a lot of Windows software with varying degrees of completeness, but
it just isn't... quite... there yet.
I run Lotus Approach under Wine, plus a few minor other
programs. You have to have a stiff constitution to
use Wine. I do believe some of the swear words
astronauts noticed in the upper atmosphere while
re-entering might have been mine (not an admission
that I cuss).

Tip: Wine Staging is much better than Wine. It is like
pulling teeth to get Wine to fix anything because they
are part of Code Weavers and want you to pay them.

Wine Staging got tired of that and formed a group and
started to fix things in short order. Wine Staging
then gets migrated into Wine. Staging is about 10 times
more stable than Wine. They fixed a ton of crap
wrong with Approach under Wine for me.

https://wine-staging.com/
T
2017-06-02 18:53:14 UTC
Reply
Permalink
Raw Message
Post by Fokke Nauta
Post by T
Hi All,
Yesterday when trying to activate a new piece of software
for a customer. It had an interesting hiccup that I though
you guys would find interesting.
One of the machines popped a corrupted key on
[HKEY_LOCAL_MACHINE\SOFTWARE\xxxxx\yyyyy\Licensing\11.0]
"Permissions Denied but you can change its security permissions".
(Probably not the exact quote).
Its security properties were all blank. All attempts to add
users to the security dialog were ignored. I couldn't rename
or erase it either.
RegKeyFixer popped "permission denied" the same error when
I tried to erase the key.
Didn't matter if I was Administrator or not.
So I booted into Fedora Core 25 (Linux) from a flash drive,
ran "chntpw", and removed the key. Rebooted into
Windows, this time the activation dialog worked.
Linux rescues Windows again! It pays to know more than
one operating system.
:-)
-T
chntpw is a little weird at first, but realizing all you
have to do is enter "?" and it gives you a set of
commands makes it a lot easier.
And do not quote out keys with spaces in them. It sees
the quote mark as part of the name.
Good info.
Linux is not too bad, as a matter of fact it's better than Windows.
It is that I purchased a hell of a lot of software for Windows that is
not available on Linux, otherwise I would have used Linux already for a
long time.
That is the only reason Windows is where it is today. They
have won the applications war. It is a tragic, well, maybe not
tragic, but rather poor operating system. But you have your
choice of five different ways (software) to do everything.
Post by Fokke Nauta
I have a lot of rescue cd's that run on Linux. Very useful in case
something gets wrong with Windows.
Fokke
Paul
2017-06-02 19:31:59 UTC
Reply
Permalink
Raw Message
Post by Fokke Nauta
I have a lot of rescue cd's that run on Linux. Very useful in case
something gets wrong with Windows.
Fokke
Until you need to work on a reparse point.

There are three standard constructions of reparse points,
for which a Linux developer could write filters in support.

And Windows 10 has at least one *custom* reparse
point, which spells "doom" for a home user. The
idea being, that only Windows will have the filter
for it. The Linux guys simply cannot keep up with
such "non-standard" extensions. This provides a
mechanism for Microsoft to throw a wrench in the
works.

Paul
T
2017-06-02 20:47:47 UTC
Reply
Permalink
Raw Message
Post by Paul
Post by Fokke Nauta
I have a lot of rescue cd's that run on Linux. Very useful in case
something gets wrong with Windows.
Fokke
Until you need to work on a reparse point.
There are three standard constructions of reparse points,
for which a Linux developer could write filters in support.
And Windows 10 has at least one *custom* reparse
point, which spells "doom" for a home user. The
idea being, that only Windows will have the filter
for it. The Linux guys simply cannot keep up with
such "non-standard" extensions. This provides a
mechanism for Microsoft to throw a wrench in the
works.
Paul
If anyone is wondering what a "reparse point" is:

https://msdn.microsoft.com/en-us/library/windows/desktop/aa365503(v=vs.85).aspx
J. P. Gilliver (John)
2017-06-02 21:17:07 UTC
Reply
Permalink
Raw Message
In message <ogsin1$p57$***@dont-email.me>, T <***@invalid.invalid> writes:
[]
Post by T
https://msdn.microsoft.com/en-us/library/windows/desktop/aa365503(v=vs.85).aspx
"A file or directory can contain a reparse point, which is a collection
of user-defined data. The format of this data is understood by the
application which stores the data, and a file system filter, which you
install to interpret the data and process the file."

Now, how about this:

A file or directory can contain a file, which is a collection of data.
The format of this data is understood by the application which writes
that file, and the OS file-association system knows how to select the
right application to interpret the date and process the file."

Now, despite the slip in the first quote (where the last word is "file"
rather than "reparse point"), I'm sure a reparse point _is_ not a file;
however, I don't find the quote explains to _me_ how they differ. (It
does proceed, soon getting well over my head - but, when the _beginning_
of the explanation _doesn't_ immediately explain to me how the two
concepts differ, I tend to think it isn't entirely me that's at fault,
but the quality of the explanation, at least partly.)
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)***@T+H+Sh0!:`)DNAf

Old soldiers never die - only young ones
Paul
2017-06-02 22:05:47 UTC
Reply
Permalink
Raw Message
Post by J. P. Gilliver (John)
[]
Post by T
https://msdn.microsoft.com/en-us/library/windows/desktop/aa365503(v=vs.85).aspx
"A file or directory can contain a reparse point, which is a collection
of user-defined data. The format of this data is understood by the
application which stores the data, and a file system filter, which you
install to interpret the data and process the file."
A file or directory can contain a file, which is a collection of data.
The format of this data is understood by the application which writes
that file, and the OS file-association system knows how to select the
right application to interpret the date and process the file."
Now, despite the slip in the first quote (where the last word is "file"
rather than "reparse point"), I'm sure a reparse point _is_ not a file;
however, I don't find the quote explains to _me_ how they differ. (It
does proceed, soon getting well over my head - but, when the _beginning_
of the explanation _doesn't_ immediately explain to me how the two
concepts differ, I tend to think it isn't entirely me that's at fault,
but the quality of the explanation, at least partly.)
Directories are files.

Use NFI.exe for example, and dump your C: drive. A directory
is a file with a $I30 entry.

A reparse point likely stores information in two places.
There's a $REPARSE or something, for the metadata. And the
filter software reading those, has to interpret any custom
ones. So if you add "VFS" to your C: NFS, then a VFS
filter driver of some sort must be present to read the
VFS-specific data from $REPARSE.

That's without me looking up all the proper terms. That's
how I understand the concept.

It's intended as an extension mechanism, for adding features
to the file system. Which is of course, a bad idea (from a standardized
behavior perspective). For example, imagine mounting a disk
with a VFS on it, on your old Win2K machine. What happens then ?

"Reparse Point" is the general escape mechanism.
"Junction Point" is a specific flavor of Reparse Point, standard
and available in more than one OS. Junction Points can be
manipulated with the "Junction.exe" program on Sysinternals.com .

Paul
J. P. Gilliver (John)
2017-06-03 10:08:08 UTC
Reply
Permalink
Raw Message
Post by Paul
Post by J. P. Gilliver (John)
[]
Post by T
https://msdn.microsoft.com/en-us/library/windows/desktop/aa365503(v=vs
.85).aspx
"A file or directory can contain a reparse point, which is a
collection of user-defined data. The format of this data is
understood by the application which stores the data, and a file
system filter, which you install to interpret the data and process
the file."
A file or directory can contain a file, which is a collection of
data. The format of this data is understood by the application which
writes that file, and the OS file-association system knows how to
select the right application to interpret the date and process the file."
Now, despite the slip in the first quote (where the last word is
"file" rather than "reparse point"), I'm sure a reparse point _is_
not a file; however, I don't find the quote explains to _me_ how they
differ. (It does proceed, soon getting well over my head - but, when
the _beginning_ of the explanation _doesn't_ immediately explain to
me how the two concepts differ, I tend to think it isn't entirely me
that's at fault, but the quality of the explanation, at least partly.)
Directories are files.
Use NFI.exe for example, and dump your C: drive. A directory
is a file with a $I30 entry.
Yes, I'd forgotten that, but very true: I think of a directory as a list
of filenames (with a clever [?] workaround to allow for ones longer than
11 characters - IIRR, uses further 11-character ones with a continuation
bit, in effect) and pointers to start positions on the disc. Plus, these
days, odd extra bits of information such as icons, preferred filetypes,
etc., though those are often in a file _in_ the directory called
desktop.ini, at least under Windows.

So, in one way, _everything_ is a file - but ...
Post by Paul
A reparse point likely stores information in two places.
There's a $REPARSE or something, for the metadata. And the
filter software reading those, has to interpret any custom
ones. So if you add "VFS" to your C: NFS, then a VFS
filter driver of some sort must be present to read the
VFS-specific data from $REPARSE.
That's without me looking up all the proper terms. That's
how I understand the concept.
... which is almost infinitely better than I do. I _hope_ I can get by
for the rest of my computing life without needing to (-:!
Post by Paul
It's intended as an extension mechanism, for adding features
to the file system. Which is of course, a bad idea (from a standardized
behavior perspective). For example, imagine mounting a disk
with a VFS on it, on your old Win2K machine. What happens then ?
"Reparse Point" is the general escape mechanism.
"Junction Point" is a specific flavor of Reparse Point, standard
and available in more than one OS. Junction Points can be
manipulated with the "Junction.exe" program on Sysinternals.com .
Paul
I've looked at that in the past, but not _really_ grasped what I'd be
doing with it. I have great respect for most things on Sysinternals,
especially if the name R..ovitch is associated with them; and the fact
that I don't understand much about what this one does does not diminish
my respect for it.
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)***@T+H+Sh0!:`)DNAf

If it ain't broke, don't download updates.
- Al Drake in alt.windows7.general, 2015-4-4
Stan Brown
2017-06-03 13:06:59 UTC
Reply
Permalink
Raw Message
Post by Paul
Use NFI.exe for example, and dump your C: drive. A directory
is a file with a $I30 entry.
I kept trying to understand how "a hundred-and-thirty-dollar entry"
could create a directory from a file. Finally I realized it must be
dollar sign (not used as currency) and then I (eye) thirty.

I think I need to choose a better font for my news client!
--
Stan Brown, Oak Road Systems, Tompkins County, New York, USA
http://BrownMath.com/
http://OakRoadSystems.com/
Shikata ga nai...
PeterC
2017-06-02 20:27:01 UTC
Reply
Permalink
Raw Message
Post by T
Hi All,
Yesterday when trying to activate a new piece of software
for a customer. It had an interesting hiccup that I though
you guys would find interesting.
One of the machines popped a corrupted key on
[HKEY_LOCAL_MACHINE\SOFTWARE\xxxxx\yyyyy\Licensing\11.0]
"Permissions Denied but you can change its security permissions".
(Probably not the exact quote).
Its security properties were all blank. All attempts to add
users to the security dialog were ignored. I couldn't rename
or erase it either.
RegKeyFixer popped "permission denied" the same error when
I tried to erase the key.
Didn't matter if I was Administrator or not.
I don't know if it would work with your problem, but I've found that the
free version of Registrar will delete Legacy keys that other reg. editors
won't.
Post by T
So I booted into Fedora Core 25 (Linux) from a flash drive,
ran "chntpw", and removed the key. Rebooted into
Windows, this time the activation dialog worked.
Linux rescues Windows again! It pays to know more than
one operating system.
:-)
-T
chntpw is a little weird at first, but realizing all you
have to do is enter "?" and it gives you a set of
commands makes it a lot easier.
And do not quote out keys with spaces in them. It sees
the quote mark as part of the name.
--
Peter.
The gods will stay away
whilst religions hold sway
T
2017-06-02 20:49:50 UTC
Reply
Permalink
Raw Message
Post by PeterC
I don't know if it would work with your problem, but I've found that the
free version of Registrar will delete Legacy keys that other reg. editors
won't.
I delete legacy keys by going in and changing the
permissions on the key. It is a pain in the butt.
I will check out Registrar. Thank you!

This one ignored all attempts to change permissions
and ownerships.
VanguardLH
2017-06-03 00:10:27 UTC
Reply
Permalink
Raw Message
Post by T
Hi All,
Yesterday when trying to activate a new piece of software
for a customer. It had an interesting hiccup that I though
you guys would find interesting.
One of the machines popped a corrupted key on
[HKEY_LOCAL_MACHINE\SOFTWARE\xxxxx\yyyyy\Licensing\11.0]
"Permissions Denied but you can change its security permissions".
(Probably not the exact quote).
Its security properties were all blank. All attempts to add
users to the security dialog were ignored. I couldn't rename
or erase it either.
RegKeyFixer popped "permission denied" the same error when
I tried to erase the key.
Didn't matter if I was Administrator or not.
So I booted into Fedora Core 25 (Linux) from a flash drive,
ran "chntpw", and removed the key. Rebooted into
Windows, this time the activation dialog worked.
Linux rescues Windows again! It pays to know more than
one operating system.
:-)
-T
chntpw is a little weird at first, but realizing all you
have to do is enter "?" and it gives you a set of
commands makes it a lot easier.
And do not quote out keys with spaces in them. It sees
the quote mark as part of the name.
The problem is usually you are logged into an account that isn't listed
or doesn't have permissions to change the key, even when logged in under
an admin-level account. If propagation isn't enabled on the subkeys,
you cannot change the parent and have it propagate.

Deleting USB enumeration keys will run into this problem. I have to
select the parent key, sometimes close a popup telling me I don't have
permissions, and change owner on the key to my account (which I can do
since my Windows account is under the Administrators security group). I
have to click Apply (to stay in the dialog for the next change). Only
after I take ownership does the Owner pseudo security group give me
permission to add other users to the permissions on that key. So I add
my own account and give it full permissions. After okaying my way out
of all the dialogs can I then either delete the key or hit F5 to refresh
the list to see what new subkeys appear under that key. If subkeys
appear, I have to repeat the process on each subkey all the way down the
tree, one subkey at a time. That's because I cannot propagate ownership
or a newly added account with full permissions onto subkeys that are
configured to NOT inherit permissions from their parent or I otherwise
don't have permissions to propagate my account into those subkeys.

If I could take ownership on the parent key, Apply, add an account with
full permissions, and force propagation into the branches all the way
down to the leaves under the parent and okay my way out of the dialog, I
could delete the entire tree with one delete. That would take under a
minute. Since I cannot force a recursion of parent changes onto the
children of the ownership and permission changes, I have to:

1. Pick a key.
2. Right-click to change permissions.
3. Close a dialog telling me that I don't have permissions.
4. Click the Advanced button.
5. Close the dialog telling me that I don't have permissions.
6. Click the Owner tab.
7. Change ownership to my account.
8. Click Apply (so I can do the next action).
9. Add my account with full permissions.
10. Click Okay until the dialogs all close.
11. Hit F5 to refresh so I can see any hidden branches under that key.
12. If new branches show up, pick a key for an unhidden branch and go
back to step 2; else, hit Delete.

I have to repeat that process (written from memory so there might be
some steps missing) until I can get all the way down from the parent key
through all branches and sub-branches until I reach a leaf (no more
children whether hidden or not). That could take an hour to delete just
one USB enumeration for a device. If the device were ever plugged into
another USB port, repeat it all again for that parent key. All because
I cannot force recursion of changes on the parent into the children.
You can't push or recurse permissions onto subkeys unless the account
you use to change the parent also has permissions for the children.
Using an admin account to take ownership of a key is how you can then
add your account (or the Administrators security group) with full
permissions on the key so you have control over it -- but Microsoft
won't let you force ownership or permissions onto children if your
account isn't already on those children (or the security group your
account is within).

Too bad there isn't something for pushing (recursing) changes made on
the parent onto all its children for registry entries like there is
icacls for changing ACLs on files. Maybe there's a registry tool that
will perform the same steps as I outlined, like you pick a key and it
runs through a script or macro to do those steps to automate having to
inch its way down from parent through branches down to the leaves.
Luckily it is rare that I have to delete USB enumerations plus other
parent keys usually don't have as many branches with so many leaves as
do USB enumerations.
T
2017-06-03 00:49:46 UTC
Reply
Permalink
Raw Message
Post by VanguardLH
Post by T
Hi All,
Yesterday when trying to activate a new piece of software
for a customer. It had an interesting hiccup that I though
you guys would find interesting.
One of the machines popped a corrupted key on
[HKEY_LOCAL_MACHINE\SOFTWARE\xxxxx\yyyyy\Licensing\11.0]
"Permissions Denied but you can change its security permissions".
(Probably not the exact quote).
Its security properties were all blank. All attempts to add
users to the security dialog were ignored. I couldn't rename
or erase it either.
RegKeyFixer popped "permission denied" the same error when
I tried to erase the key.
Didn't matter if I was Administrator or not.
So I booted into Fedora Core 25 (Linux) from a flash drive,
ran "chntpw", and removed the key. Rebooted into
Windows, this time the activation dialog worked.
Linux rescues Windows again! It pays to know more than
one operating system.
:-)
-T
chntpw is a little weird at first, but realizing all you
have to do is enter "?" and it gives you a set of
commands makes it a lot easier.
And do not quote out keys with spaces in them. It sees
the quote mark as part of the name.
The problem is usually you are logged into an account that isn't listed
or doesn't have permissions to change the key, even when logged in under
an admin-level account. If propagation isn't enabled on the subkeys,
you cannot change the parent and have it propagate.
The key will always show who the owner it. It will not come up blank.

And the key, which was new, was created by the program installed
under the same user account I was reading the bad key with.
I also tried the administrator.

Five other w7-pro sp1 workstations had no such problem.
Post by VanguardLH
Deleting USB enumeration keys will run into this problem. I have to
select the parent key, sometimes close a popup telling me I don't have
permissions, and change owner on the key to my account (which I can do
since my Windows account is under the Administrators security group). I
have to click Apply (to stay in the dialog for the next change). Only
after I take ownership does the Owner pseudo security group give me
permission to add other users to the permissions on that key. So I add
my own account and give it full permissions. After okaying my way out
of all the dialogs can I then either delete the key or hit F5 to refresh
the list to see what new subkeys appear under that key. If subkeys
appear, I have to repeat the process on each subkey all the way down the
tree, one subkey at a time. That's because I cannot propagate ownership
or a newly added account with full permissions onto subkeys that are
configured to NOT inherit permissions from their parent or I otherwise
don't have permissions to propagate my account into those subkeys.
If I could take ownership on the parent key, Apply, add an account with
full permissions, and force propagation into the branches all the way
down to the leaves under the parent and okay my way out of the dialog, I
could delete the entire tree with one delete. That would take under a
minute. Since I cannot force a recursion of parent changes onto the
1. Pick a key.
2. Right-click to change permissions.
3. Close a dialog telling me that I don't have permissions.
4. Click the Advanced button.
5. Close the dialog telling me that I don't have permissions.
6. Click the Owner tab.
7. Change ownership to my account.
8. Click Apply (so I can do the next action).
9. Add my account with full permissions.
10. Click Okay until the dialogs all close.
11. Hit F5 to refresh so I can see any hidden branches under that key.
12. If new branches show up, pick a key for an unhidden branch and go
back to step 2; else, hit Delete.
I do this a lot. This time is did not work. It would not
take new permissions. It would go right back to being blank
after pressing okay. I even went into advanced and changed the
owner from blank to everyone. Did not take.
Post by VanguardLH
I have to repeat that process (written from memory so there might be
some steps missing) until I can get all the way down from the parent key
through all branches and sub-branches until I reach a leaf (no more
children whether hidden or not). That could take an hour to delete just
one USB enumeration for a device. If the device were ever plugged into
another USB port, repeat it all again for that parent key. All because
I cannot force recursion of changes on the parent into the children.
You can't push or recurse permissions onto subkeys unless the account
you use to change the parent also has permissions for the children.
Using an admin account to take ownership of a key is how you can then
add your account (or the Administrators security group) with full
permissions on the key so you have control over it -- but Microsoft
won't let you force ownership or permissions onto children if your
account isn't already on those children (or the security group your
account is within).
Too bad there isn't something for pushing (recursing) changes made on
the parent onto all its children for registry entries like there is
icacls for changing ACLs on files. Maybe there's a registry tool that
will perform the same steps as I outlined, like you pick a key and it
runs through a script or macro to do those steps to automate having to
inch its way down from parent through branches down to the leaves.
Luckily it is rare that I have to delete USB enumerations plus other
parent keys usually don't have as many branches with so many leaves as
do USB enumerations.
When dire measures are required, there is always "chntpw". Permissions?
I don't need no stinkin' permissions!
VanguardLH
2017-06-03 07:16:22 UTC
Reply
Permalink
Raw Message
Post by T
The key will always show who the owner it. It will not come up blank.
Nope. I'll go to a subkey, right-click to go to permissions, close the
popup prompt saying I don't have permissions, click on the Advanced
button, again have to close a popup saying I don't have permissions, and
under the Owner tab it will say the owner is unknown. Even with an
admin account, I don't *yet* have permissions to see them on this key.
I have to take ownership to only then get the permissions for the pseudo
OWNER RIGHTS account. I've done this tons of times to know that you
won't always see who is the currently assigned owner until you take
ownership but then obviously now you know who is the owner.

In fact, on those stubborn keys, I could NOT see which Windows accounts
were assigned to the key which also meant I could not see their
permissions. Only after taking ownership of the key (and clicking
Apply) could I then OK that dialog to bounce back to the parent dialog
which then was populated with the SYSTEM, OWNER RIGHTS, and other
accounts that were assigned to that key. So, yeah, it was all blank for
me, too, until I took ownership.
Post by T
And the key, which was new, was created by the program installed
under the same user account I was reading the bad key with.
I also tried the administrator.
I gave an example (in deleting USB enumerations) of how difficult it can
be to get the needed permissions to delete a registry key. I don't have
whatever software you installed to have that key and obviously you hid
its path in the registry, anyway.
Post by T
Five other w7-pro sp1 workstations had no such problem.
Was the software part of a sysprep image, installed on a host while
logged under the Administrator account or another Windows account that
is included under the Administrators security group? You said you tried
to activate the software's license. You did not say you installed that
software.

Was the license used for all installs or did one come out of a different
license pack?
Post by T
Post by VanguardLH
Deleting USB enumeration keys will run into this problem. I have to
select the parent key, sometimes close a popup telling me I don't have
permissions, and change owner on the key to my account (which I can do
since my Windows account is under the Administrators security group). I
have to click Apply (to stay in the dialog for the next change). Only
after I take ownership does the Owner pseudo security group give me
permission to add other users to the permissions on that key. So I add
my own account and give it full permissions. After okaying my way out
of all the dialogs can I then either delete the key or hit F5 to refresh
the list to see what new subkeys appear under that key. If subkeys
appear, I have to repeat the process on each subkey all the way down the
tree, one subkey at a time. That's because I cannot propagate ownership
or a newly added account with full permissions onto subkeys that are
configured to NOT inherit permissions from their parent or I otherwise
don't have permissions to propagate my account into those subkeys.
If I could take ownership on the parent key, Apply, add an account with
full permissions, and force propagation into the branches all the way
down to the leaves under the parent and okay my way out of the dialog, I
could delete the entire tree with one delete. That would take under a
minute. Since I cannot force a recursion of parent changes onto the
1. Pick a key.
2. Right-click to change permissions.
3. Close a dialog telling me that I don't have permissions.
4. Click the Advanced button.
5. Close the dialog telling me that I don't have permissions.
6. Click the Owner tab.
7. Change ownership to my account.
8. Click Apply (so I can do the next action).
9. Add my account with full permissions.
10. Click Okay until the dialogs all close.
11. Hit F5 to refresh so I can see any hidden branches under that key.
12. If new branches show up, pick a key for an unhidden branch and go
back to step 2; else, hit Delete.
I do this a lot. This time is did not work. It would not
take new permissions. It would go right back to being blank
after pressing okay. I even went into advanced and changed the
owner from blank to everyone. Did not take.
Everyone is a security group, not a Windows account. Easy to see by
going to a key, right-click to select Permissions, click on Advanced
button, Permissions tab, click Add button, click Advanced button, and
click the Find Now button. Security groups ha a double bobble-head icon
to represent more than one account may be in that security group.
Windows accounts are represented by a single bobble-head icon.

Normally you don't change permissions of a security group. You assign a
Windows account to the security group whose permissions you want
inherited by that Windows account. However, on a per-key basis, you can
alter the Everyone security group to change that security group's
permissions on that key.

I never try to assign a security group or one of the pseudo ones (e.g.,
Authenticated Users) as the owner. I'm not sure what permissions you
will get. Instead of pick an actual Windows *account* that is in the
Administrators security group.

With a policy editor to look at what privileges each security group has,
I don't know if Everyone has more or less default privileges than Owner.
Seems whichever has the reduced privileges set will be the effected
owner permissions on that key.

Every article I've read about taking ownership has you select a Windows
account, not a security group except maybe for the Administrators
security group *if* your Windows account is in there.

http://www.thewindowsclub.com/how-to-take-full-control-of-windows-7-registry-keys
https://www.howtogeek.com/262464/how-to-gain-full-permissions-to-edit-protected-registry-keys/
Those have you pick a Windows account, not a Windows security group.

http://www.askvg.com/guide-how-to-take-ownership-permission-of-a-registry-key-in-windows/
Note this article mentions use the "Replace owner on subcontainers and
objects". That won't work if the subkeys are not configured to inherit
from their parent. However, even if it doesn't work all the way down
the branches to the leaf node, sometimes it will work on some of the
branch keys.

While the dialog lets you pick and assign a security group as the owner,
there is a question of whether you get the lowest common denominator of
permissions between the OWNER RIGHTS pseudo group or that of the
security group. I don't bother taking that unknown and instead assign
my account (which is in the Administrators security group) as owner. If
you're not deleting the key but want to just edit it, probably a good
safety net to record who was the original owner and which accounts or
security groups were listed as with what specific permissions on the key
so you can restore them after you modify owner and permissions to do
your editing.

In my case, I am the only user of that host. If there are multiple user
accounts, not only do you have to be careful which Windows account or
security group to take ownership of a key but you'll have to figure out
which of those need to have permissions and which ones on that key.
Post by T
When dire measures are required, there is always "chntpw". Permissions?
I don't need no stinkin' permissions!
The description of chntpw is to change the NT passwords in the SAM
(Security Account Manager) database. It has to run offline so the
registry isn't protected by an instance of Windows using those registry
files.

https://en.wikipedia.org/wiki/Chntpw
http://www.chntpw.com/

Since its purpose was designed to reset passwords to thwart lockouts,
I'm not sure how accurate it is at assigning the correct permissions,
inheritance, and propation to children of permissions.

If it does alter permissions in the registry files, it seems a
sledgehammer approach and one not specifically geared toward the goal
you mentioned here.

I have to wonder if regedit.exe wouldn't also be usable to bypass all
the permissions in the registry if you imported the registry from
another host. That is, you can right-click on a hive in the currently
loaded instance of Windows and import the same hive from the exported
registry of another host. The only account SIDs (security identifiers)
that are constant across Windows hosts (that I know of) are the system
account and the Administrators security group. Other Windows account
will have a different randomly assigned SID, so the johndoe in one
instance of Windows is not the same johndoe account in another instance
of Windows.

The imported registry will have Windows accounts that do not exist under
the current instance of Windows in which you are using regedit to look
at those imported keys. That means the current instance of Windows
cannot enforce any privileges of the unknown Windows account or security
groups. Because they are unknown, I suspect regedit will let you do
whatever you want on those keys. Maybe that's how chntpw works, too,
since you do NOT run it under the same instance of Windows in which the
accounts and security groups are defined. The registry being edited is
not live in the instance of Windows where you are doing the editing.

I remember exporting a registry on one host, using another host to
import the other host's registry, and then doing just about anything I
want on those quiescent hives (since they are not used by the current
instance of Windows under which you are running regedit). Of course,
you need another Windows host (real or virtual) to do all that so the
imported registry is quiescent.
T
2017-06-03 09:07:57 UTC
Reply
Permalink
Raw Message
Post by VanguardLH
Post by T
The key will always show who the owner it. It will not come up blank.
Nope. I'll go to a subkey, right-click to go to permissions, close the
popup prompt saying I don't have permissions, click on the Advanced
button, again have to close a popup saying I don't have permissions, and
under the Owner tab it will say the owner is unknown. Even with an
admin account, I don't *yet* have permissions to see them on this key.
I have to take ownership to only then get the permissions for the pseudo
OWNER RIGHTS account. I've done this tons of times to know that you
won't always see who is the currently assigned owner until you take
ownership but then obviously now you know who is the owner.
In fact, on those stubborn keys, I could NOT see which Windows accounts
were assigned to the key which also meant I could not see their
permissions. Only after taking ownership of the key (and clicking
Apply) could I then OK that dialog to bounce back to the parent dialog
which then was populated with the SYSTEM, OWNER RIGHTS, and other
accounts that were assigned to that key. So, yeah, it was all blank for
me, too, until I took ownership.
Post by T
And the key, which was new, was created by the program installed
under the same user account I was reading the bad key with.
I also tried the administrator.
I gave an example (in deleting USB enumerations) of how difficult it can
be to get the needed permissions to delete a registry key. I don't have
whatever software you installed to have that key and obviously you hid
its path in the registry, anyway.
Post by T
Five other w7-pro sp1 workstations had no such problem.
Was the software part of a sysprep image, installed on a host while
logged under the Administrator account or another Windows account that
is included under the Administrators security group? You said you tried
to activate the software's license. You did not say you installed that
software.
Was the license used for all installs or did one come out of a different
license pack?
Post by T
Post by VanguardLH
Deleting USB enumeration keys will run into this problem. I have to
select the parent key, sometimes close a popup telling me I don't have
permissions, and change owner on the key to my account (which I can do
since my Windows account is under the Administrators security group). I
have to click Apply (to stay in the dialog for the next change). Only
after I take ownership does the Owner pseudo security group give me
permission to add other users to the permissions on that key. So I add
my own account and give it full permissions. After okaying my way out
of all the dialogs can I then either delete the key or hit F5 to refresh
the list to see what new subkeys appear under that key. If subkeys
appear, I have to repeat the process on each subkey all the way down the
tree, one subkey at a time. That's because I cannot propagate ownership
or a newly added account with full permissions onto subkeys that are
configured to NOT inherit permissions from their parent or I otherwise
don't have permissions to propagate my account into those subkeys.
If I could take ownership on the parent key, Apply, add an account with
full permissions, and force propagation into the branches all the way
down to the leaves under the parent and okay my way out of the dialog, I
could delete the entire tree with one delete. That would take under a
minute. Since I cannot force a recursion of parent changes onto the
1. Pick a key.
2. Right-click to change permissions.
3. Close a dialog telling me that I don't have permissions.
4. Click the Advanced button.
5. Close the dialog telling me that I don't have permissions.
6. Click the Owner tab.
7. Change ownership to my account.
8. Click Apply (so I can do the next action).
9. Add my account with full permissions.
10. Click Okay until the dialogs all close.
11. Hit F5 to refresh so I can see any hidden branches under that key.
12. If new branches show up, pick a key for an unhidden branch and go
back to step 2; else, hit Delete.
I do this a lot. This time is did not work. It would not
take new permissions. It would go right back to being blank
after pressing okay. I even went into advanced and changed the
owner from blank to everyone. Did not take.
Everyone is a security group, not a Windows account. Easy to see by
going to a key, right-click to select Permissions, click on Advanced
button, Permissions tab, click Add button, click Advanced button, and
click the Find Now button. Security groups ha a double bobble-head icon
to represent more than one account may be in that security group.
Windows accounts are represented by a single bobble-head icon.
Normally you don't change permissions of a security group. You assign a
Windows account to the security group whose permissions you want
inherited by that Windows account. However, on a per-key basis, you can
alter the Everyone security group to change that security group's
permissions on that key.
I never try to assign a security group or one of the pseudo ones (e.g.,
Authenticated Users) as the owner. I'm not sure what permissions you
will get. Instead of pick an actual Windows *account* that is in the
Administrators security group.
With a policy editor to look at what privileges each security group has,
I don't know if Everyone has more or less default privileges than Owner.
Seems whichever has the reduced privileges set will be the effected
owner permissions on that key.
Every article I've read about taking ownership has you select a Windows
account, not a security group except maybe for the Administrators
security group *if* your Windows account is in there.
http://www.thewindowsclub.com/how-to-take-full-control-of-windows-7-registry-keys
https://www.howtogeek.com/262464/how-to-gain-full-permissions-to-edit-protected-registry-keys/
Those have you pick a Windows account, not a Windows security group.
http://www.askvg.com/guide-how-to-take-ownership-permission-of-a-registry-key-in-windows/
Note this article mentions use the "Replace owner on subcontainers and
objects". That won't work if the subkeys are not configured to inherit
from their parent. However, even if it doesn't work all the way down
the branches to the leaf node, sometimes it will work on some of the
branch keys.
While the dialog lets you pick and assign a security group as the owner,
there is a question of whether you get the lowest common denominator of
permissions between the OWNER RIGHTS pseudo group or that of the
security group. I don't bother taking that unknown and instead assign
my account (which is in the Administrators security group) as owner. If
you're not deleting the key but want to just edit it, probably a good
safety net to record who was the original owner and which accounts or
security groups were listed as with what specific permissions on the key
so you can restore them after you modify owner and permissions to do
your editing.
In my case, I am the only user of that host. If there are multiple user
accounts, not only do you have to be careful which Windows account or
security group to take ownership of a key but you'll have to figure out
which of those need to have permissions and which ones on that key.
Post by T
When dire measures are required, there is always "chntpw". Permissions?
I don't need no stinkin' permissions!
The description of chntpw is to change the NT passwords in the SAM
(Security Account Manager) database. It has to run offline so the
registry isn't protected by an instance of Windows using those registry
files.
https://en.wikipedia.org/wiki/Chntpw
http://www.chntpw.com/
Since its purpose was designed to reset passwords to thwart lockouts,
I'm not sure how accurate it is at assigning the correct permissions,
inheritance, and propation to children of permissions.
If it does alter permissions in the registry files, it seems a
sledgehammer approach and one not specifically geared toward the goal
you mentioned here.
I have to wonder if regedit.exe wouldn't also be usable to bypass all
the permissions in the registry if you imported the registry from
another host. That is, you can right-click on a hive in the currently
loaded instance of Windows and import the same hive from the exported
registry of another host. The only account SIDs (security identifiers)
that are constant across Windows hosts (that I know of) are the system
account and the Administrators security group. Other Windows account
will have a different randomly assigned SID, so the johndoe in one
instance of Windows is not the same johndoe account in another instance
of Windows.
Yeah, me too. It did not work this time.
Post by VanguardLH
The imported registry will have Windows accounts that do not exist under
the current instance of Windows in which you are using regedit to look
at those imported keys. That means the current instance of Windows
cannot enforce any privileges of the unknown Windows account or security
groups. Because they are unknown, I suspect regedit will let you do
whatever you want on those keys. Maybe that's how chntpw works, too,
since you do NOT run it under the same instance of Windows in which the
accounts and security groups are defined. The registry being edited is
not live in the instance of Windows where you are doing the editing.
I remember exporting a registry on one host, using another host to
import the other host's registry, and then doing just about anything I
want on those quiescent hives (since they are not used by the current
instance of Windows under which you are running regedit). Of course,
you need another Windows host (real or virtual) to do all that so the
imported registry is quiescent.
T
2017-06-03 09:08:56 UTC
Reply
Permalink
Raw Message
Post by T
Post by VanguardLH
Post by T
The key will always show who the owner it. It will not come up blank.
Nope. I'll go to a subkey, right-click to go to permissions, close the
popup prompt saying I don't have permissions, click on the Advanced
button, again have to close a popup saying I don't have permissions, and
under the Owner tab it will say the owner is unknown. Even with an
admin account, I don't *yet* have permissions to see them on this key.
I have to take ownership to only then get the permissions for the pseudo
OWNER RIGHTS account. I've done this tons of times to know that you
won't always see who is the currently assigned owner until you take
ownership but then obviously now you know who is the owner.
In fact, on those stubborn keys, I could NOT see which Windows accounts
were assigned to the key which also meant I could not see their
permissions. Only after taking ownership of the key (and clicking
Apply) could I then OK that dialog to bounce back to the parent dialog
which then was populated with the SYSTEM, OWNER RIGHTS, and other
accounts that were assigned to that key. So, yeah, it was all blank for
me, too, until I took ownership.
Post by T
And the key, which was new, was created by the program installed
under the same user account I was reading the bad key with.
I also tried the administrator.
I gave an example (in deleting USB enumerations) of how difficult it can
be to get the needed permissions to delete a registry key. I don't have
whatever software you installed to have that key and obviously you hid
its path in the registry, anyway.
Post by T
Five other w7-pro sp1 workstations had no such problem.
Was the software part of a sysprep image, installed on a host while
logged under the Administrator account or another Windows account that
is included under the Administrators security group? You said you tried
to activate the software's license. You did not say you installed that
software.
Was the license used for all installs or did one come out of a different
license pack?
Post by T
Post by VanguardLH
Deleting USB enumeration keys will run into this problem. I have to
select the parent key, sometimes close a popup telling me I don't have
permissions, and change owner on the key to my account (which I can do
since my Windows account is under the Administrators security group). I
have to click Apply (to stay in the dialog for the next change). Only
after I take ownership does the Owner pseudo security group give me
permission to add other users to the permissions on that key. So I add
my own account and give it full permissions. After okaying my way out
of all the dialogs can I then either delete the key or hit F5 to refresh
the list to see what new subkeys appear under that key. If subkeys
appear, I have to repeat the process on each subkey all the way down the
tree, one subkey at a time. That's because I cannot propagate ownership
or a newly added account with full permissions onto subkeys that are
configured to NOT inherit permissions from their parent or I otherwise
don't have permissions to propagate my account into those subkeys.
If I could take ownership on the parent key, Apply, add an account with
full permissions, and force propagation into the branches all the way
down to the leaves under the parent and okay my way out of the dialog, I
could delete the entire tree with one delete. That would take under a
minute. Since I cannot force a recursion of parent changes onto the
1. Pick a key.
2. Right-click to change permissions.
3. Close a dialog telling me that I don't have permissions.
4. Click the Advanced button.
5. Close the dialog telling me that I don't have permissions.
6. Click the Owner tab.
7. Change ownership to my account.
8. Click Apply (so I can do the next action).
9. Add my account with full permissions.
10. Click Okay until the dialogs all close.
11. Hit F5 to refresh so I can see any hidden branches under that key.
12. If new branches show up, pick a key for an unhidden branch and go
back to step 2; else, hit Delete.
I do this a lot. This time is did not work. It would not
take new permissions. It would go right back to being blank
after pressing okay. I even went into advanced and changed the
owner from blank to everyone. Did not take.
Everyone is a security group, not a Windows account. Easy to see by
going to a key, right-click to select Permissions, click on Advanced
button, Permissions tab, click Add button, click Advanced button, and
click the Find Now button. Security groups ha a double bobble-head icon
to represent more than one account may be in that security group.
Windows accounts are represented by a single bobble-head icon.
Normally you don't change permissions of a security group. You assign a
Windows account to the security group whose permissions you want
inherited by that Windows account. However, on a per-key basis, you can
alter the Everyone security group to change that security group's
permissions on that key.
I never try to assign a security group or one of the pseudo ones (e.g.,
Authenticated Users) as the owner. I'm not sure what permissions you
will get. Instead of pick an actual Windows *account* that is in the
Administrators security group.
With a policy editor to look at what privileges each security group has,
I don't know if Everyone has more or less default privileges than Owner.
Seems whichever has the reduced privileges set will be the effected
owner permissions on that key.
Every article I've read about taking ownership has you select a Windows
account, not a security group except maybe for the Administrators
security group *if* your Windows account is in there.
http://www.thewindowsclub.com/how-to-take-full-control-of-windows-7-registry-keys
https://www.howtogeek.com/262464/how-to-gain-full-permissions-to-edit-protected-registry-keys/
Those have you pick a Windows account, not a Windows security group.
http://www.askvg.com/guide-how-to-take-ownership-permission-of-a-registry-key-in-windows/
Note this article mentions use the "Replace owner on subcontainers and
objects". That won't work if the subkeys are not configured to inherit
from their parent. However, even if it doesn't work all the way down
the branches to the leaf node, sometimes it will work on some of the
branch keys.
While the dialog lets you pick and assign a security group as the owner,
there is a question of whether you get the lowest common denominator of
permissions between the OWNER RIGHTS pseudo group or that of the
security group. I don't bother taking that unknown and instead assign
my account (which is in the Administrators security group) as owner. If
you're not deleting the key but want to just edit it, probably a good
safety net to record who was the original owner and which accounts or
security groups were listed as with what specific permissions on the key
so you can restore them after you modify owner and permissions to do
your editing.
In my case, I am the only user of that host. If there are multiple user
accounts, not only do you have to be careful which Windows account or
security group to take ownership of a key but you'll have to figure out
which of those need to have permissions and which ones on that key.
Post by T
When dire measures are required, there is always "chntpw". Permissions?
I don't need no stinkin' permissions!
The description of chntpw is to change the NT passwords in the SAM
(Security Account Manager) database. It has to run offline so the
registry isn't protected by an instance of Windows using those registry
files.
https://en.wikipedia.org/wiki/Chntpw
http://www.chntpw.com/
Since its purpose was designed to reset passwords to thwart lockouts,
I'm not sure how accurate it is at assigning the correct permissions,
inheritance, and propation to children of permissions.
If it does alter permissions in the registry files, it seems a
sledgehammer approach and one not specifically geared toward the goal
you mentioned here.
I have to wonder if regedit.exe wouldn't also be usable to bypass all
the permissions in the registry if you imported the registry from
another host. That is, you can right-click on a hive in the currently
loaded instance of Windows and import the same hive from the exported
registry of another host. The only account SIDs (security identifiers)
that are constant across Windows hosts (that I know of) are the system
account and the Administrators security group. Other Windows account
will have a different randomly assigned SID, so the johndoe in one
instance of Windows is not the same johndoe account in another instance
of Windows.
Yeah, me too. It did not work this time.
RegKeyFixer wouldn't even delete the turkey. That has
always worked before.
Post by T
Post by VanguardLH
The imported registry will have Windows accounts that do not exist under
the current instance of Windows in which you are using regedit to look
at those imported keys. That means the current instance of Windows
cannot enforce any privileges of the unknown Windows account or security
groups. Because they are unknown, I suspect regedit will let you do
whatever you want on those keys. Maybe that's how chntpw works, too,
since you do NOT run it under the same instance of Windows in which the
accounts and security groups are defined. The registry being edited is
not live in the instance of Windows where you are doing the editing.
I remember exporting a registry on one host, using another host to
import the other host's registry, and then doing just about anything I
want on those quiescent hives (since they are not used by the current
instance of Windows under which you are running regedit). Of course,
you need another Windows host (real or virtual) to do all that so the
imported registry is quiescent.
Stan Brown
2017-06-03 13:11:41 UTC
Reply
Permalink
Raw Message
Post by VanguardLH
Post by T
The key will always show who the owner it. It will not come up blank.
Nope. I'll go to a subkey, right-click to go to permissions, close the
popup prompt saying I don't have permissions, click on the Advanced
button, again have to close a popup saying I don't have permissions, and
under the Owner tab it will say the owner is unknown. Even with an
admin account, I don't *yet* have permissions to see them on this key.
I have to take ownership to only then get the permissions for the pseudo
OWNER RIGHTS account. I've done this tons of times to know that you
won't always see who is the currently assigned owner until you take
ownership but then obviously now you know who is the owner.
In fact, on those stubborn keys, I could NOT see which Windows accounts
were assigned to the key which also meant I could not see their
permissions. Only after taking ownership of the key (and clicking
Apply) could I then OK that dialog to bounce back to the parent dialog
which then was populated with the SYSTEM, OWNER RIGHTS, and other
accounts that were assigned to that key. So, yeah, it was all blank for
me, too, until I took ownership.
_That_ matches my experience. Very frustrating, because (at least on
the setups I have to deal with) propagation to subkeys fails, so I
have to do a couple dozen, one by one.
--
Stan Brown, Oak Road Systems, Tompkins County, New York, USA
http://BrownMath.com/
http://OakRoadSystems.com/
Shikata ga nai...
VanguardLH
2017-06-03 17:56:57 UTC
Reply
Permalink
Raw Message
Post by Stan Brown
Post by VanguardLH
Post by T
The key will always show who the owner it. It will not come up blank.
Nope. I'll go to a subkey, right-click to go to permissions, close the
popup prompt saying I don't have permissions, click on the Advanced
button, again have to close a popup saying I don't have permissions, and
under the Owner tab it will say the owner is unknown. Even with an
admin account, I don't *yet* have permissions to see them on this key.
I have to take ownership to only then get the permissions for the pseudo
OWNER RIGHTS account. I've done this tons of times to know that you
won't always see who is the currently assigned owner until you take
ownership but then obviously now you know who is the owner.
In fact, on those stubborn keys, I could NOT see which Windows accounts
were assigned to the key which also meant I could not see their
permissions. Only after taking ownership of the key (and clicking
Apply) could I then OK that dialog to bounce back to the parent dialog
which then was populated with the SYSTEM, OWNER RIGHTS, and other
accounts that were assigned to that key. So, yeah, it was all blank for
me, too, until I took ownership.
_That_ matches my experience. Very frustrating, because (at least on
the setups I have to deal with) propagation to subkeys fails, so I
have to do a couple dozen, one by one.
What gets exascerbating is that as you get ownership and add permissions
on each key, a refresh shows you there are most subkeys to work on. The
branches keep growing and magnifying the task. As the hidden branches
get exposed, you have to do the same laborious task on each one while
drilling down to finally reach a leaf and repeat for each newly exposed
leaf just like you have to repeat for each newly exposed branch. You
start to wonder what the hell you got into.

Took me over an hour to delete just 2 USB enumeration keys for the same
printer. I didn't keep track of how many hidden branches and leaves got
exposed as I drilled down taking ownership and adding permissions but
it's always way more than I expect. Plus it's quite boring having to
redo the same actions on every newly exposed branch and leaf.

Maybe one day I'll look into getting AutoHotkey or AutoIt to create a
macro to automate the change on each key. I cannot expose a hidden
branch or leaf until the changes are effected on the parent but hitting
one hotkey per registry key would be a lot easier than manually wading
through the dialogs over and over and over and over and ad nauseum.
T
2017-06-03 23:15:47 UTC
Reply
Permalink
Raw Message
Post by VanguardLH
Took me over an hour to delete just 2 USB enumeration keys for the same
printer.
Hi Vanguard,

"chntpw" with its "rdel" would have aced that
sucker as fast as it took you to press "enter".
Now another tool in your tool box!

And, yes, it always goes through my mind
whether it would be faster to boot into Fedora
or to slug it through in Windows. I guess
wrong often.

-T
Stan Brown
2017-06-04 17:39:14 UTC
Reply
Permalink
Raw Message
Post by VanguardLH
[quoted text muted]
_That_ matches my experience. Very frustrating, because (at least on
the setups I have to deal with) propagation to subkeys fails, so I
have to do a couple dozen, one by one.
What gets exascerbating is that as you get ownership and add permissions
on each key, a refresh shows you there are most subkeys to work on. The
branches keep growing and magnifying the task.
Yup. It makes sense, if you once grant that Windows' Byzantine
permission system makes sense, and if you also grant that the owner
of a key cannot necessarily propagate permission settings to existing
subkeys of the key. (Both of those seem dubious to me, but they are
what we have to deal with.)

I agree with you: that repeated opening out, increasing the scope of
the job like the death of a thousand cuts, is indeed exasperating.
--
Stan Brown, Oak Road Systems, Tompkins County, New York, USA
http://BrownMath.com/
http://OakRoadSystems.com/
Shikata ga nai...
Stan Brown
2017-06-03 13:09:50 UTC
Reply
Permalink
Raw Message
Post by T
The key will always show who the owner it. It will not come up blank.
Not in my experience.
--
Stan Brown, Oak Road Systems, Tompkins County, New York, USA
http://BrownMath.com/
http://OakRoadSystems.com/
Shikata ga nai...
T
2017-06-03 22:35:24 UTC
Reply
Permalink
Raw Message
Post by Stan Brown
Post by T
The key will always show who the owner it. It will not come up blank.
Not in my experience.
99.9% of the time, not my experience either
Stan Brown
2017-06-03 13:09:00 UTC
Reply
Permalink
Raw Message
Post by T
Yesterday when trying to activate a new piece of software
for a customer. It had an interesting hiccup that I though
you guys would find interesting.
One of the machines popped a corrupted key on
[HKEY_LOCAL_MACHINE\SOFTWARE\xxxxx\yyyyy\Licensing\11.0]
"Permissions Denied but you can change its security permissions".
(Probably not the exact quote).
Its security properties were all blank. All attempts to add
users to the security dialog were ignored. I couldn't rename
or erase it either.
I have had that situation on customer machines. You could have gone
into advanced permissions and changed the owner (which involves a
second "we won't show you the owner but we'll you change it"). Then
you would be able to assign the desired permissions.
--
Stan Brown, Oak Road Systems, Tompkins County, New York, USA
http://BrownMath.com/
http://OakRoadSystems.com/
Shikata ga nai...
T
2017-06-03 22:35:56 UTC
Reply
Permalink
Raw Message
Post by Stan Brown
Post by T
Yesterday when trying to activate a new piece of software
for a customer. It had an interesting hiccup that I though
you guys would find interesting.
One of the machines popped a corrupted key on
[HKEY_LOCAL_MACHINE\SOFTWARE\xxxxx\yyyyy\Licensing\11.0]
"Permissions Denied but you can change its security permissions".
(Probably not the exact quote).
Its security properties were all blank. All attempts to add
users to the security dialog were ignored. I couldn't rename
or erase it either.
I have had that situation on customer machines. You could have gone
into advanced permissions and changed the owner (which involves a
second "we won't show you the owner but we'll you change it"). Then
you would be able to assign the desired permissions.
Me too. This time I could not.
Loading...