Hi all, We are trying to run a vbscript to copy PST files off of each user profile to a network share. We have developed a VBScript to carry out the task and it all works find and well when the the target machine user had local admin priv’s. We have since removed local admin and now the VBS is stepped on and is denied access to run the script. We’ve tried things like moving the vbs to the temp folder, but to no avail. I’ve looked around for example scripts or ideas on how to tackle this, but I am not finding much. So, I’m looking for assistance on how simple things like this are handled in a locked down windows environment? Thanks for your time! - Drew
If these are mailbox actions then the mailbox is an admin privileged directory so have you tried moving the script to another directory before running it?
The script scans the users profile for *.pst. The script itself work(ed) in testing. However, the issue is just firing off the VBS. I moved it to C:\Temp, but our AV config is stepping on that folder. Is there a general method or approach to running tasks on machines where the user is logged in as a standard user?
Thanks for the reply Alan …
// Example script //
delete __Download\PST_Move.vbs
delete "C:\Temp\PST_Move.vbs"
prefetch RunAsCurrentUser.exe sha1:ee47505ebfb2790b9da8a20ed70e67158e9753d0 size:342528 http://software.bigfix.com/download/bes/util/RunAsCurrentUser-2.0.3.1.exe
prefetch 0d8173478713b82fa6fa1aff239e261bf5d90965 sha1:0d8173478713b82fa6fa1aff239e261bf5d90965 size:462 http://site.com:52311/Uploads/0d8173478713b82fa6fa1aff239e261bf5d90965/PST_Move.tmp sha256:ed76b17cf5d108830dad2264738ed18785ad9810d2e327577aeef67989611493
extract 0d8173478713b82fa6fa1aff239e261bf5d90965
move __Download\PST_Move.vbs C:\Temp\PST_Move.vbs
waithidden __Download\RunAsCurrentUser.exe wscript C:\Temp\PST_Move.vbs
If you are using 8.2+ you don’t need RunAsCurrentUser so that would turn the actionscript into the below. But you say that your AV is interfering? Also this looks a bit like it was generated by the SWD dashboard?
prefetch 0d8173478713b82fa6fa1aff239e261bf5d90965 sha1:0d8173478713b82fa6fa1aff239e261bf5d90965 size:462 http://site.com:52311/Uploads/0d8173478713b82fa6fa1aff239e261bf5d90965/PST_Move.tmp sha256:ed76b17cf5d108830dad2264738ed18785ad9810d2e327577aeef67989611493
extract 0d8173478713b82fa6fa1aff239e261bf5d90965
delete "C:\Temp\PST_Move.vbs"
move _Download\PSTMove.vbs C:\Temp\PST_Move.vbs
override wait
hidden=true
runas=currentuser
wait wscript C:\Temp\PSTMove.vbs
Hi Alan, the script is being denied the ability to run no matter where I place the file on the users workstation. The logged on user does not have admin access to the machine, so even placing the file within the users profile under appdata, he is still denied access to run it. So, the mechanics of the script work with ID the user, it copies the file into the proper location, but when executed, it’s denied access. Any idea on how to execute a VBS via Bigifix? Here is the action script and it works fine, and interestingly, the BF status on the job comes back as complete. So it thinks that it ran.
//script below
delete __Download\PST_Move.vbs
prefetch 0d8173478713b82fa6fa1aff239e261bf5d90965 sha1:0d8173478713b82fa6fa1aff239e261bf5d90965 size:462 http://IEM.SITE.COM:52311/Uploads/0d8173478713b82fa6fa1aff239e261bf5d90965/PST_Move.vbs.tmp sha256:ed76b17cf5d108830dad2264738ed18785ad9810d2e327577aeef67989611493
extract 0d8173478713b82fa6fa1aff239e261bf5d90965
parameter “CurrentUserName” = “{name of logged on user}”
delete C:\users{parameter “CurrentUserName”}\appdata\local\PST_Move.vbs
move __Download\PST_Move.vbs C:\users{parameter “CurrentUserName”}\appdata\local\PST_Move.vbs
override wait
hidden=true
runas=currentuser
wait wscript C:\users{parameter “CurrentUserName”}\appdata\local\PST_Move.vbs
If you give the script to a “user” can they run it manually from their profile folder?
Hi Tim,
Yes, the if the user has the file locally and they double-click on it, it will run. It just will not run successfully when IEM delivers it. So, the project is at a halt now that local admin privs have been removed. BF wont fire off. Is there a method that I can leverage to get this to work? How are endpoints managed that dont have local admin rights?
Thanks!
The user must have admin rights to do this action? Are you checking to see if the current user has admin privileges on the relevance of the action?
The client will just pass the execution over to the user with whatever privileges it has. Remember though it can’t show anything (there is no UI available). The client doesn’t grant or remove privileges from the user execution.
From examples I can see of running VBS they do this:
wait "{pathname of system folder}\cscript.exe" "{pathname of client folder of current site}\__Download\Script.vbs"
Hi Alan,
Thanks for the response. The agent is installed and operating as LocalSystem. The logged on user is NOT a local admin. That is the crux of the issue. I am seeking a method to copy PST files that live under the users profile using bigfix. The thought was, since the agent has local admin rights to the box, and since the BF agent is executing the command, it should be able to carry out the process. I’m guessing I’m incorrect.
That would be the crux of the issue if the task you are doing requires admin rights. We do not elevate any user to admin when we run as them. The user will use its own privileges to run something.
Does the action require being run as the user or does the action just need to get files from the user?
The BF agent is operating as a local admin. So even though the agent is firing off the command, it cant access any files under the user profile?
Were trying to run a script that will scan the users profile for any PST files from Outlook and move them to a network location for archive. The user can save PST’s just about anywhere. The script scans for *.pst and when it finds it, it moves it. So, we have tried a variety of ways to fire off either a batch file process or a VBS to carry out the task. I don’t think that it needs to run AS the user, however these files will be under the users profile. Do you have a suggestion?
The client can access anything anywhere. Running a process as a user… it can only do what that user can do
Its a bit more complex but you could write your VBS to work on a specific directory
q: home directory of user "testuser"
A: C:\Users\testuser
You can do
user of current user
to get to the “user” part. This would give you a directory to scan in.
The home directory
inspector did have some issues in the past but you should easily be able to get the directory in other ways if the version you are running is broken
This is what I was about to test…
delete __Download\PST_Move.vbs
prefetch 0d8173478713b82fa6fa1aff239e261bf5d90965 sha1:0d8173478713b82fa6fa1aff239e261bf5d90965 size:462 http://IEM.SITE.COM:52311/Uploads/0d8173478713b82fa6fa1aff239e261bf5d90965/PST_Move.vbs.tmp sha256:ed76b17cf5d108830dad2264738ed18785ad9810d2e327577aeef67989611493
extract 0d8173478713b82fa6fa1aff239e261bf5d90965
parameter “CurrentUserName” = “{name of logged on user}”
delete C:\users{parameter “CurrentUserName”}\appdata\local\PST_Move.vbs
move __Download\PST_Move.vbs C:\users{parameter “CurrentUserName”}\appdata\local\PST_Move.vbs
wait wscript C:\users{parameter “CurrentUserName”}\appdata\local\PST_Move.vbs
We may be making this harder than it needs to be.
How are you getting the VBScript file to the client? If you’re using a prefetch, download, appendfile, or writefile, the resulting .vbs (under either __BESData\site or __BESData\site__Download) has permissions only for the Administrators group and the LocalSystem account.
The ActionScript “move” command behaves the same way as Windows’ “move” - when a file is moved from one location to another on the same filesystem, the resulting target file retains the same permission as the source file originally had - normal Users still do not have any permission to access the new file.
If you use the ActionScript “copy” command instead, it works the same way as Windows’ Copy. The target is a new file, that gets new permissions based on the directory in which it’s created. If you use the ‘copy’ command to copy your vbscript file to any folder to which the user has access - c:, c:\temp, c:\windows\temp, whatever - then the user should be able to access the new file from there.
Thank you Alan and Jason for your assistance. Jason - very observant! I TOTALLY MISSED that fact with regards to the permissions on the Move vs. Copy command. The Copy instead of the Move seems to have done the trick. It was a permissions issue with the Move command. It fired off on the test machine and its running. Once again THANK YOU both for your help with this! … - Phil