Jump to content


Config_Mgr_noob

SMSTS.log indicate Access is Denied for VBS script

Recommended Posts

Hi everyone, I'm currently experiencing an issue where my task sequence would fail when it reaches a particular task which a "Run Command Line" task. I looked into the smsts log on the client machine and found an Access is Denied. However, I have been successfully imaging PCs using the same TS and image for the past 4 months. I checked the source directory for the network access account and all looks the same and good from there. And the network access account does belong to a group where it has local admin rights to the machines. I don't see how I can resolve this. Has anyone come across this issue before?

post-22069-0-00801900-1392218533_thumb.png

Share this post


Link to post
Share on other sites

Dp is set to download content locally and all the source directories have the appropriate security for shared and NTFS. As you can see in the log the content gets downloaded to the C:\_SMSTaskSequence\Packages\FTL00032 on the client machine. After this, it receives the Access Denied error. The account im using to deploy applications is part of a security group that has modify rights to any machines being imaged. But I have notice that if I log into any machine with the NAA account and run the script locally it gets an access denied. But When I elevate the CMD to administrator and run the script, it works perfectly. Any ideas with regards to permissions or security?

Share this post


Link to post
Share on other sites

IMHO I think you're using bad form running a command from a remote directory. The correct permissions that the directory would need to read is not your Network Access Account but EVERY COMPUTER ACCOUNT accessing this share.

 

Basically, don't. Make a package and run file.vbs instead of \\really long directory structure\file.vbs. Have SCCM manage this package instead of relying on opening up shares. Make a package called "scripts" and make that part of every deployment etc...

 

The problem is that your VBScript is calling out to a remote location and it is running under the computer context which doesn't have access to that directory. Fix your VBScript to not call out to remote directories. The other thing that it could be is that you're deliberately doing a "program" that does \\server\script.vbs also a no no. You can, but it's bad practice because you run into these situations where people don't grasp how everything comes together and things break.

 

My guess is that the script is probably executing when the computer is not on the domain etc... or doesn't have access...

 

Treat all your apps as "local" they're executing out of c:\windows\ccmcache\###### folder, you should include everything in your package that you need. If you must have your vbscript call out to remote locations you would have to open up share permissions to all computer accounts, i.e. "authenticated users" in a domain, not just "domain users" because it's running under the system context.

 

Applications are run as the system account of a local machine, unless it's run in the user's credentials as an optional task sequence; Try running the vbscript in the "computer" context to get a valid representation of whether your script will run in SCCM by opening a PSEXEC window "as the computer account" by running "psexec -i -s -d cmd" and then run "cscript script.vbs" and you will see your errors.

 

These are just conjectures because your problem isn't described fully/correctly, but 3 points to remember:

 

1) all scripts need to be run in "relative" path, i.e. don't do calls to random SMB shares, it rarely works

2) They typically run in the computer account's system context, this is the share permission/ntfs permissions you would have to grant if you really want to reach out to SMB shares

 

 

3) NEVER check the box in the package "Data Access", "Copy the contents in this package share on distribtution points". Also never check "run from remote distribution point"... You're not doing these, but wanted to point out that if you do check that box, it copies it to the SMSPKGD$ share and makes it an SMB share so you could "run from remote distribution point" but then you have 2 copies (wasting space) and it often fails to run from a DP. My personal preference this one...

 

There are ways to run scripts "as another account", but then you have to make sure the account has admin rights on that box, and network share permissions. IMHO, it's bad form to try and run it that way. It's more reliable to run it as the system account on that machine, and run with all files you need to reference in your package; reaching out to shares is not reliable.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...


×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.