Modified registry keys, can't restore permissions

[Fred Ma]

I was having trouble uninstalling some drivers for my HP
printer/scanner (HP support, please note that this is
case#7312033464). I got a lot of help from tech support. There is
one difficulty I am left with, though. One of the steps needed for a
thorough uninstall was to open up permissions for the following
registry keys:

HKEY_CLASSES_ROOT (top level of the tree)
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Enum
HKEY_LOCAL_MACHINE\System\ControlSet001\Enum

The change was to give the Everyone account "Full Control". I thought
it was a temporary change. The problem is that it cannot be reverted
back to its previous permissions. If I try to take away Full Control
from the Everyone account, the nonadministrator account is not able to
launch windows explorer. I had to use the task manager to issue a
runas and launch the windows explorer as administrator.

I suspect that what is happening is that taking away Full Control in
those subtrees causes a removal of that permission for all
nonadministrators, throughout the entire subtrees. This probably not
reflect the state of the registry prior to my granting those
permissions. HP has told me that this is a standard way to get around
the problem of nonthorough uninstalls. I was advised to talk to Dell
Technical support to figure out how to fix it.

Dell was willing to help, but they said the only way to deal with it
was to reinstall windows. This is supposedly a major compromise in
security, and allows any nonadministrator to install applications on
the system. I just wondered if gurus out there can suggest a last
ditch attempt at restoring the permissions. I just reinstalled
Windows 2000 Pro for the 2nd time in a month. (The first time was on
a bad HDD). The major time sink is not the reinstallation of windows,
or SP4. It is the installation and customization of apps and
environments that I use.

Thanks for any suggestions.

Fred

P.S. Would exporting a copy of the registry have helped? I mean,
does the export include permissions information?

P.P.S. Please note that this has been sent to
- comp.sys.hp.hardware
- microsoft.public.win2000.general
- "HP OfficeJet E-mail Support" <[email protected]>
I will manually prevent the thread from fragmenting.

 

[Pegasus \(MVP\)]

I was having trouble uninstalling some drivers for my HP
printer/scanner (HP support, please note that this is
case#7312033464). I got a lot of help from tech support. There is
one difficulty I am left with, though. One of the steps needed for a
thorough uninstall was to open up permissions for the following
registry keys:

HKEY_CLASSES_ROOT (top level of the tree)
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Enum
HKEY_LOCAL_MACHINE\System\ControlSet001\Enum

The change was to give the Everyone account "Full Control". I thought
it was a temporary change. The problem is that it cannot be reverted
back to its previous permissions. If I try to take away Full Control
from the Everyone account, the nonadministrator account is not able to
launch windows explorer. I had to use the task manager to issue a
runas and launch the windows explorer as administrator.

I suspect that what is happening is that taking away Full Control in
those subtrees causes a removal of that permission for all
nonadministrators, throughout the entire subtrees. This probably not
reflect the state of the registry prior to my granting those
permissions. HP has told me that this is a standard way to get around
the problem of nonthorough uninstalls. I was advised to talk to Dell
Technical support to figure out how to fix it.

Dell was willing to help, but they said the only way to deal with it
was to reinstall windows. This is supposedly a major compromise in
security, and allows any nonadministrator to install applications on
the system. I just wondered if gurus out there can suggest a last
ditch attempt at restoring the permissions. I just reinstalled
Windows 2000 Pro for the 2nd time in a month. (The first time was on
a bad HDD). The major time sink is not the reinstallation of windows,
or SP4. It is the installation and customization of apps and
environments that I use.

Thanks for any suggestions.

Fred

P.S. Would exporting a copy of the registry have helped? I mean,
does the export include permissions information?

P.P.S. Please note that this has been sent to
- comp.sys.hp.hardware
- microsoft.public.win2000.general
- "HP OfficeJet E-mail Support"

I will manually prevent the thread from fragmenting.

I suspect that restoring the original permissions is not
a viable option, simply because of the very large number
of keys to be dealt with, each requiring just the right
attributes. You may have to treat this one as a learning
exercise, with the following two items to remember:

- Before making a registry change, back up the branch
you're modifying. This is a standard warning in all MS KB
articles.
- After getting a machine just right, spend another five
minutes and create a snapshot image of the system
drive, using an imaging product such as Acronis TrueImage.
This has saved me enormous amounts of time.

 

[George Hester]

I just looked at that key. To change permissions on such a high-level key the information you got to do that was irresponsible. I understand why you did it but they should never have suggested that without pointing out the ramifications. Since they didn't that tells me they didn't know. So now you do and as Pegasus said, you may have to chalk that up to a learning experiense

Let me point out that just saving such a key as this in regedit before surgery would do nothing for permissions. I don't even know if saving in regedt32 would matter either here. The trouble we have is what are called "volatile" keys and I believe you are smack dab in the middle of keys such as that in that area. Volatile keys can't be restored easily. The only way I know of is to reinstall the operating system.

 

[Fred Ma]

I suspect that restoring the original permissions is not
a viable option, simply because of the very large number
of keys to be dealt with, each requiring just the right
attributes. You may have to treat this one as a learning
exercise, with the following two items to remember:

- Before making a registry change, back up the branch
you're modifying. This is a standard warning in all MS KB
articles.
- After getting a machine just right, spend another five
minutes and create a snapshot image of the system
drive, using an imaging product such as Acronis TrueImage.
This has saved me enormous amounts of time.

I was remiss. I was only keeping an eye on the hp newgroup.
I shall now defragment the thread across both groups.

True image looks interesting....it must take up quite a number
of CDs, unless it works with partitions (or over the network).
I don't have my HDD partitioned, though I should have (never
thought about it cuz I never had such a big HDD before now).

I gotta watch how much I sink into the laptop, though.
Money is an issue, and the laptop is university property.
I already replaced the HDD and got Win2Kpro for it, directly
from Dell, just for the support. Thanks for pointing out
Acronis, though, for later times.

Fred

 

[Fred Ma]

I just looked at that key. To change permissions on such a high-level key the information you got to do that was irresponsible. I understand why you did it but they should never have suggested that without pointing out the ramifications. Since they didn't that tells me they didn't know. So now you do and as Pegasus said, you may have to chalk that up to a learning experiense

Let me point out that just saving such a key as this in regedit before surgery would do nothing for permissions. I don't even know if saving in regedt32 would matter either here. The trouble we have is what are called "volatile" keys and I believe you are smack dab in the middle of keys such as that in that area. Volatile keys can't be restored easily. The only way I know of is to reinstall the operating system.

Yea, I was wondering if exporting the subtree would have captured the permission information.
Ben thinks it would have, in his response.

It's one thing for the support tech to not know of the ramifications. It's quite another to
pretend to know with overwhelming certainty that there are no ramifications in the face of
adamant and detailed voicing of why it is risky, and to use impatience to bury the customer's
concerns. Unfortunately, I was not familiar enough with the registry and regedt32 to stick
to my guns. As well, I had too much faith in the benevolence and due diligence of the
support service -- since they *were* better trained than others I've dealt with. Frankly,
though, I don't think it can be explained by even ignorance. I called back to describe the
problem and confirmed that the permissions changes granted extra powers to nonadmin users;
specifically, powers to install apps, according the the person I spoke to. There didn't
seem to be any ignorance of the ramifications at that time.

Fred

 

[Torgeir Bakken \(MVP\)]

Yea, I was wondering if exporting the subtree would have captured the
permission information. Ben thinks it would have, in his response.

Hi

Using the "Save Key..." option in Regedt32 will also capture the
permission information, so by using the "Restore..." option later on
you would be able to restore the original permissions (but lose all
changes done in that registry branch since you exported it).

 

[Fred Ma]

This is not the first time, nor will it be the last, when the quality of HP
software is far, far lower than the quality of its printers and scanners, which
have gradually worsening quality, too. This newsgroup is filled with war
stories about third-rate software that comes with HP products... Ben Myers

It seems that in this case, they could have avoided that reputation by not
making overreaching claims about supporting Win2K. The software worked
resonably well under FAT32, so it only works with Win2K only under certain
conditions.

From what I can see, they tried to hide that limitation by sneaking in

devestating changes to Win2K. I really don't know how I can trust HP
products in the future. I certainly can't trust what it says on the box.
Nor can I trust their admittedly well trained support staff.

Fred

 

[Gary Smith]

It seems that in this case, they could have avoided that reputation by not
making overreaching claims about supporting Win2K. The software worked
resonably well under FAT32, so it only works with Win2K only under certain
conditions.

It has been my expereince as well that HP and HP representatives really
know very little about software, and Windows in particular. The problem
for the hapless users of their hardware is that they don't know what they
don't know -- and wouldn't be able to admit it if they did. Thus they
guess, and make careless assumptions that what works for one version of
Windows will work for all. We pay the price for that ignorance. Even the
support dsoftware for their own products is targeted at a single Windows
version. If it works on a later version, it's sheer luck.

When I buy a new printer soon, HP will not be a candidate. When I replace
the CD-RW drive in my daughter's machine, it won't say HP on the front.

 

[Fred Ma]

It has been my expereince as well that HP and HP representatives really
know very little about software, and Windows in particular. The problem
for the hapless users of their hardware is that they don't know what they
don't know -- and wouldn't be able to admit it if they did. Thus they
guess, and make careless assumptions that what works for one version of
Windows will work for all. We pay the price for that ignorance. Even the
support dsoftware for their own products is targeted at a single Windows
version. If it works on a later version, it's sheer luck.

When I buy a new printer soon, HP will not be a candidate. When I replace
the CD-RW drive in my daughter's machine, it won't say HP on the front.

Well, here I change my tune a bit and give HP support some credit. They
seem to have it together compared to another unnamed company's support
staff. But that makes them even guiltier. As I explained in an earlier
posting, the misadvice cannot be attributed to ignorance. Beyond the fact
that they recognized the problem when I called back, I mean that in the
initial call where I discussed the change with a staff member, I was very
explicit about exactly how security could be compromised. No guessing
needed there! The only problem was that I trusted them too much and
wasn't familiar enough with the registry to stick to my guns. It's
actually a very educational experience. Now, if someone asks me to
stomp on a nail, I'll question it.

I won't go as far as you in denouncing any further prospects of buying
HP. I will stick to my original comment: How can I trust anything they
say about their product, or about troubleshooting. Whether the latter
reduces to the former depends on whether alternatives are better or
worse.

Fred

 

[Gary Smith]

Well, here I change my tune a bit and give HP support some credit. They
seem to have it together compared to another unnamed company's support
staff. But that makes them even guiltier. As I explained in an earlier
posting, the misadvice cannot be attributed to ignorance. Beyond the fact
that they recognized the problem when I called back, I mean that in the
initial call where I discussed the change with a staff member, I was very
explicit about exactly how security could be compromised. No guessing
needed there! The only problem was that I trusted them too much and
wasn't familiar enough with the registry to stick to my guns. It's
actually a very educational experience. Now, if someone asks me to
stomp on a nail, I'll question it.

I believe that the real problem is that support staff are highly variable
in their level of knowledge and they do not get good training. Whether
you get good advice or bad is pretty much a matter of chance. It all
depends on who answers when you get the call. This problem is not
exclusive to HP of course; it's widespread among both hardware and
software vendors.

 

[Fred Ma]

I believe that the real problem is that support staff are highly variable
in their level of knowledge and they do not get good training. Whether
you get good advice or bad is pretty much a matter of chance. It all
depends on who answers when you get the call. This problem is not
exclusive to HP of course; it's widespread among both hardware and
software vendors.

The person who poo-poo'd the security concern knew exactly what the
registry change did (allowed all users to access those registries). I
was pretty clear about my worries, that it would let nonadmin accounts
install programs. He didn't say he didn't know. He said it doesn't
make any difference. I repeated my concern several times. He repeated
his answer several times. The reason I repeated it several times was
because I found his dismissal of the security concern very hard to
believe. Very assured dismissal, very condescending, and somewhat
impatient. It was not hesitant or unsure. In the end, I thought that
no one could be *that* confident and be lying or not know. I guess my
point is that that it cannot be attributed to ignorance, which is how
I interpret your mention of potentially low knowledge level or bad
training (and I do agree that they vary). It is more an ethical issue.
Not of the individual, probably, as the dubious procedure is probably
given as a matter of practice. The individual is, however, complacent
even though the consequences are very clear (at least in my case, I
made it very clear). This is likely to happen when such an approach
is approved from greater powers than front line support staff, either
implicitly or explicitly.

Fred

 

[Gary Smith]

The person who poo-poo'd the security concern knew exactly what the
registry change did (allowed all users to access those registries). I
was pretty clear about my worries, that it would let nonadmin accounts
install programs. He didn't say he didn't know. He said it doesn't
make any difference. I repeated my concern several times. He repeated
his answer several times. The reason I repeated it several times was
because I found his dismissal of the security concern very hard to
believe. Very assured dismissal, very condescending, and somewhat
impatient. It was not hesitant or unsure. In the end, I thought that
no one could be *that* confident and be lying or not know. I guess my
point is that that it cannot be attributed to ignorance, which is how
I interpret your mention of potentially low knowledge level or bad
training (and I do agree that they vary). It is more an ethical issue.
Not of the individual, probably, as the dubious procedure is probably
given as a matter of practice. The individual is, however, complacent
even though the consequences are very clear (at least in my case, I
made it very clear). This is likely to happen when such an approach
is approved from greater powers than front line support staff, either
implicitly or explicitly.

That just reinforces my "no HP, no way" policy.