the_slycer has asked for the wisdom of the Perl Monks concerning the following question:

Hello, I am attempting to write up a script to delete a bunch (say 20 or so) registry keys on various machines. Everything seems to be working Ok, I can see all of the keys (just in testing stages and only printing them right now ;-)) that I want to delete.

The problem I am running into is the actual deletion of the keys. There are some that are located in CUser, which, a friend of mine tells me, are not accessible via an IPC$ share. Ok, so no problem, have the user's run the script. Except that some of the other keys are in LMachine and admin rights are needed to delete them.

Does anybody know of a way to get rid of the CUser keys remotely? Any ideas how I can get around this?

Replies are listed 'Best First'.
Re: Win32::TieRegistry with remote CUser?
by rchiav (Deacon) on May 25, 2001 at 22:26 UTC
    HKEY_CURRENT_USER will never be accessable to you remotely. What you can do though is go through HKEY_USERS and remove the data from there. If it's something that you're afraid that HKCU will save back to HKU, you can have your script do what it needs to remotely, then copy a script to the machine and put an entry in HKU\.Default\Software\Microsoft\Windows\CurrentVersion\RunOnce and it will be run for each user who logs on to that machine. Might be a better way of approaching it if multiple people log on to one machine, and you don't want to itterate through all the users hives yourself.

    Personally, I'd give everyone admin rights. From personal expierence, the time it takes to fix it if they break it is much less than the time it takes to do the piddly things you have to do for them.. and the time it takes to work around them not having admin rights.

    Just my .02
    Rich

      HKEY_CURRENT_USER will never be accessable to you remotely.

      I've been getting at HKEY_CURRENT_USER remotely just now while testing. With noone logged in, it was the registry of a user that a particular service runs under. When I logged in, the remote access switched to using my "user registry" (after I reopened).

              - tye (but my friends call me "Tye")
      Ah..
      Everybody Admin rights in a company with 30000 users scares me ;-)

      I admit I never thought of running it through Users, guess I'd do it for each SID in that case. That may be the way to go.
      Thanks.
        *shrug* There's 50,000 people here with admin rights. We'd need twice as many desk side support people to handle things if they didn't have admin rights. I just don't think it's cost efficient.

        addition: Each person has admin rights to only their own machine. And only administrators can log on locally. So only the user(s) of that machine can log on locally.

        Rich

(tye)Re: Win32::TieRegistry with remote CUser?
by tye (Sage) on May 25, 2001 at 22:41 UTC

    Did you try/test this? I see nothing particularly special about CUser when accessed remotely. Now it might not be there or might not be who you expected, depending on what users have "logged in" (which doesn't always involve logging into the desktop) in what order.

    You could also go the "Users" key route which requires finding SIDs, etc. (yuck) or, look up things in "LMachine/System/CurrentControlSet/Control/hivelist/" and hope the "profile" name closely matches the username.

            - tye (but my friends call me "Tye")
      I did test this, I can read the CUser keys, but I cannot change/create/delete them. Not a rights issue - I have them. Profile name will be the exact same as the username, so I may have some luck with that.
      Thanks

        Profile name will be the exact same as the username

        Be careful with that assumption there. I guess you've never had a corrupted user profile or had a user's name changed (don't your employees ever get married?). The profile name might be "SmithGE.001" instead of "JonesGE" if you run into just the two problem that I have personally run into.

                - tye (but my friends call me "Tye")

        I even tested deleting and it works for me. Not being a domain admin it wasn't convenient for me to test the case of the user with admin privs accessing remotely being different than the logged in user.

                - tye (but my friends call me "Tye")