More fun with RunAsCurrentUser and HKCU

(imported topic written by SystemAdmin)

Ok, maybe someone else can see what I did wrong. As far as I can tell, this should work (but it doesn’t).

I’m trying to delete print queues from a users profile, which I know doesn’t exist. While there are a few different HKCU settings to remove for 1 printer and I also have multiple queues I’m checking for, let me simplify the relevance and action…

Let’s say that the user has a registry key as:

HKEY_CURRENT_USER\Printers\Connections,myprintserver,PRINTQUEUETODELETE

Here’s the relevance:

exists keys
whose
(
(
(
it contains "myprintserver"
and
(
it ends with “printqueuetodelete”
)
)
or
(
it contains "anotherprintserver"
and
(
it ends with “anotherprintqueuetodelete”
)
)
)
of
(
name of it as lowercase
)
)
of keys “Printers\Connections” of current user keys
(
logged on users
)
of registry

The action (I believe) to delete it should be…

if {exists current user}

prefetch RunAsCurrentUser.exe sha1:ee47505ebfb2790b9da8a20ed70e67158e9753d0 size:342528 http://software.bigfix.com/download/bes/util/RunAsCurrentUser-2.0.3.1.exe
utility __Download\RunAsCurrentUser.exe

delete __appendfile
delete remove_printers.reg

appendfile Windows Registry Editor Version 5.00
appendfile
appendfile {("%0d%0a") of keys whose (((it contains “myprintserver” and it ends with “printqueuetodelete”) or (it contains “anotherprintserver” and it ends with “anotherprintqueuetodelete”)) of (name of it as lowercase)) of key “Printers\Connections” of current user keys (logged on users) of registry}

copy __appendfile remove_printers.reg

waithidden __Download\RunAsCurrentUser.exe --w --q reg.exe IMPORT remove_printers.reg

So for this PC, remove_printers.reg looks like:

Windows Registry Editor Version 5.00

-HKEY_CURRENT_USER\Printers\Connections,myprintserver,PRINTQUEUETODELETE

The result of the action looks like it worked…

At 10:27:42 -0400 - opsite4 (http://bigfix.my.domain:52311/cgi-bin/bfgather.exe/opsite4)
Relevant - Remove nonexistant printers (fixlet:33586559)
At 10:27:43 -0400 -
ActionLogMessage: (action 33586559 ) Action signature verified
ActionLogMessage: (action 33586559 ) Non-Distributed - DownloadsAvailable
ActionLogMessage: (action 33586559 ) starting action
At 10:27:43 -0400 - actionsite (http://bigfix.my.domain:52311/cgi-bin/bfgather.exe/actionsite)
Command succeeded (Prefetch download manager collected file) prefetch RunAsCurrentUser.exe sha1:9fd47b14aee681a6bad6579d30d6fb3fa4cc3ae3 size:131072 http://support.bigfix.com/download/bes/util/RunAsCurrentUser.exe (fixlet 33586559)
Command succeeded delete __appendfile (fixlet 33586559)
Command succeeded delete No ‘remove_printers.reg’ exists to delete, no failure reported (fixlet 33586559)
Command succeeded appendfile Windows Registry Editor Version 5.00 (fixlet 33586559)
Command succeeded (file created) appendfile Windows Registry Editor Version 5.00 (fixlet 33586559)
Command succeeded appendfile Windows Registry Editor Version 5.00 (fixlet 33586559)
Command succeeded appendfile (fixlet 33586559)
Command succeeded appendfile -HKEY_CURRENT_USER\Printers\Connections,myprintserver,PRINTQUEUETODELETE
(fixlet 33586559)
At 10:27:44 -0400 - actionsite (http://bigfix.my.domain:52311/cgi-bin/bfgather.exe/actionsite)
Command succeeded copy __appendfile remove_printers.reg (fixlet 33586559)
At 10:28:50 -0400 -
Report posted successfully.
At 10:28:50 -0400 - actionsite (http://bigfix.my.domain:52311/cgi-bin/bfgather.exe/actionsite)
Command succeeded (Exit Code=0) waithidden __Download\RunAsCurrentUser.exe --w --q reg.exe import remove_printers.reg (fixlet 33586559)
At 10:28:55 -0400 -
ActionLogMessage: (action 33586559 ) ending action
At 10:28:55 -0400 - opsite4 (http://bigfix.my.domain:52311/cgi-bin/bfgather.exe/opsite4)
Not Relevant - Remove nonexistant printers (fixlet:33586559)

However, looking back at the PC I targeted, the registry key still exists.

I tried running a CMD prompt as local system (using psexec -i -s cmd.exe) and running the same thing. However, that works fine.

Can anyone see anything I missed? Yes, I did try launching RACU using regedit for WinXP, but that didn’t work either. Yes, I also tried using RACU 1.1.0.0 for XP.

-Paul

(imported comment written by SystemAdmin)

Ok, Daryl and I figured out what the problem is.

It’s the last 2 lines in my action:

copy __appendfile remove_printers.reg

waithidden __Download\RunAsCurrentUser.exe --w --q reg.exe IMPORT remove_printers.reg

I’m copying __appendfile as a file called remove_printers, which I’m trying to have the user’s account import. Normally this would be fine, but it turns out that the file is being created under “actionsite” and that folder is only accessible by an administrator or the system account.

So when I try to have reg.exe import as the user, it fails to import because the user doesn’t have access to that folder.

As a test to confirm, I tried…

if {exists current user}

prefetch RunAsCurrentUser.exe sha1:ee47505ebfb2790b9da8a20ed70e67158e9753d0 size:342528 http://software.bigfix.com/download/bes … .0.3.1.exe
utility __Download\RunAsCurrentUser.exe

delete __appendfile
delete remove_printers.reg
delete C:\remove_printers.reg

appendfile Windows Registry Editor Version 5.00
appendfile
appendfile {("%0d%0a") of keys whose (((it contains “myprintserver” and it ends with “printqueuetodelete”) or (it contains “anotherprintserver” and it ends with “anotherprintqueuetodelete”)) of (name of it as lowercase)) of key “Printers\Connections” of current user keys (logged on users) of registry}

copy __appendfile remove_printers.reg
copy __appendfile C:\remove_printers.reg

waithidden __Download\RunAsCurrentUser.exe --w --q reg.exe IMPORT C:\remove_printers.reg

delete C:\remove_printers.reg

So I’m leaving a copy of remove_printers.reg under “actionsite” so I can look at it later. But the importing comes from C:, which the user has access.

Now…

Question…

Is there a better place to stage the .reg for the user’s account to access it? Should I try some relevance to locate the user’s personal temp folder, or should I leave this as-is.

Paul

(imported comment written by BenKus)

Very good investigative work… Depending on your permissions for the agent folders, you will need to move the .reg file somewhere outside to program files folder where the user has permission… You might try the user’s temp folder or a temp folder that you create yourself?

Ben

(imported comment written by SystemAdmin)

Ideally, I think I’d prefer the user’s temp folder (which seems like a cleaner place to put it)

Ben, any tricks for getting the path to the logged on user’s temp folder that would work from XP to Win7?

Hmm…

Under HKCU\Volatile Environment, USERPROFILE is listed for Vista, Win2008 and Win7. I suppose I could cheat for Win2003, XP and earlier using APPDATA in this key and cut off the “\Application Data” at the end

Under HKCU\Environment, “temp” is listed, using %USERPROFILE% in the path

Maybe there’s a better way for the logged on user’s temp folder…

-Paul

(imported comment written by BenKus)

Maybe just use the cmd’s idea of what the temp folder is? Maybe something like this:

waithidden cmd.exe /C copy __appendfile "%TEMP%\remove_printers.reg"
waithidden __Download\RunAsCurrentUser.exe --w --q cmd.exe /C reg.exe IMPORT “%TEMP%\remove_printers.reg”

Ben

(imported comment written by SystemAdmin)

Hi Ben

I don’t think that will work.

The first one runs under the local system account, whose %temp% resolves to the Windows temp folder (e.g. C:\Windows\temp)

The second one runs as the current user, whose %temp% is redirected under their profile (e.g. C:\users(username)\Appdata\local\temp)

Here’s what I’m thinking now to get the logged on user’s temp folder. See what you think…

(
if
it contains “%25USERPROFILE%25” of it
then
(
if
(
it = "WinXP"
or
it = "Win2000"
or
it = “Win2003”
)
of name of operating system
then
preceding text of last “” of value “APPDATA” of key “Volatile Environment” of current user keys (logged on users) of registry as string
else
value “USERPROFILE” of key “Volatile Environment” of current user keys (logged on users) of registry as string
)
&
(
following text of first “%25USERPROFILE%25” of preceding text of first “%00” of it
)
else
it
)
of
(
value “TEMP” of key “Environment” of current user keys (logged on users) of registry as string
)

Btw, for those reading this who were thinking of using “expand environment string of…”, that also won’t work in this case because it would expand on what the local system account believes that environent variable to be.

Now if we had an inspector that would work like “expand environment string of “%25TEMP%25” of logged on users”, that would be a different story.

-Paul

(imported comment written by MattBoyd)

Users should be able to read\write to C:\Windows\Temp . Maybe give that a try?

(imported comment written by SystemAdmin)

On my PCs, only Administrators have access to C:\Windows\temp.

Even so, under the user’s context, it has no idea if “C:\Windows\temp” is actually correct. Remember, %temp% is re-located for the user. Unless you blindly assume that’s the system temp folder is under %SYSTEMROOT% & “\temp”

Paul

(imported comment written by JackCoates91)

I never like to assume anything about path names, that’s what variables are for. %TEMP% will resolve to a writable directory no matter what version of Windows or account you’re running as, unless someone’s done something to specifically break it.

(imported comment written by SystemAdmin)

Hmm… There’s an old saying of what happens when you “assume”. :wink:

Yes, I agree that %temp% will always resolve to a writable area, but only for the account making the determination for itself. %temp%=C:\Windows\temp for the local system and %temp% is under the profile folder for the user.

However, in my case I’m trying to create a .reg file from the system account where it will be imported by the user’s account. Thus my dilema of having the local system account locate where the logged on user’s temp folder resides - as a cleaner method than dumping the .reg on the root of C:\

(imported comment written by JackCoates91)

so, the read needs to happen as the user, but the write and the delete can still happen as local system, right? I’d create a .bat file, writing out the system’s %temp% as a full path so the user account doesn’t have to resolve it, then run the .bat with RACU.

(imported comment written by SystemAdmin)

Yes, but on our PCs, the system’s temp folder is not accessible by a regular user (our users are not local admins of their PCs). They may create/edit their own files (because they’re the owner), but they do not have list/read to c:\windows\temp for files they did not create. They cannot list the contents of c:\windows\temp without getting an “access denied” message.

If your PC is a domain PC, try checking the effective permissions for the local “users” group on C:\Windows\temp. I’d be curious if what I’m seeing is the default.

(imported comment written by JackCoates91)

nice catch, just checked on a domain PC and regular users have Create and Execute, but not Read. I stand corrected, I guess the heinous path of calculating the user’s temp directory really is the best option you’ve got.