Deployment Solution

Hello,

I'm trying to deploy software 'Bentley View' with Run Script task in the middle of image deployment. No matter what I try, installation ends to error on console: "Error 1 during script execution"

I use Run Script task from DS and script is:

V:\Bentley_Viewer\setup.exe -s setup.iss (tried with quotes and no quotes)

This task is executed with Local System privileges

Computer is in workgroup at the moment of execution and before Run Script task, there's other task which maps V drive.

So far I've checked following:

- Permissions

- Try install command with quotes and without them

- Attempted execution with Script window: Minimized, Normal, Maximized, Hidden...nothing works

- When I remote the box and enter install command manually it works perfectly

- When install ends to error code 1, I checked that program is really not there

Please assist

Hi,

Your problem is the drive mapping -the system account won't have a V:\ Drive mapping, and in be used when  authenticating to remote computers. You have two options,

1. Run your script under a specific user context so that it can at the top of the script map the V:\ drive and run your silent install script
2. Add a Copy File task to your job, to copy the app source locally to the client machine. Your Run Script task can then change directory into that folder, and install the software. On completion, you can have the script clean up the source folder if required.

I generally opt for option (2) as this means your software deployment tasks don't rely on known local administrator credentials.

Kind Regards,
Ian./

Thanks Ian,

By using Copy File task to copy source files to local disk, my install script worked perfectly.

But this raised some questions.

I have another Run Script task, which also is executed under Local System privileges and setup.exe is started from V: drive and it works like a charm. Any idea why?

Hi,

This is odd, as this in my mind says that,

1. This V:\ drive mapping must have been made under System Logon session. For example, drive mappings made under use accounts should not be visible to the system account.
    
2. That the server hosting the V:\ must be allowing anonymous connections, or the share must have been mapped under system using named credentials

I wouldn't mind exploring this one further with you, as its counter to my understanding how how Windows account sessions interact.

V: drive is mapped in Run Script task, which is first task of my job. Run Script task is executed with Local System privileges.

This is how script looks like:

net use G: \\%DSSERVER%\eXpress /user:ad\dsservice password

G:\temp\%ID%win.bat

and %ID%win.bat has following content:

@Echo Off
Echo.
Echo  V: = \\REMOTEPXE\images
Echo.
Echo     Mapping V: To \\REMOTEPXE\images
net use V: \\REMOTEPXE\images /USER:ad\dsservice password

I need these weird scripts, because I want job to run software installations from nearest package server (our image files & softwares are distributed to NS package servers).

But thank you for helping me with this.

Why are you doing this with the System account instead of a specific domain account, like the DSService account or something?  System is severly limited in network access and things like that.  If you have a specific account you could perform this task with, 1) you wouldn't have to supply credentials to map the drive, 2) you would get a more "like" environment to the ones you test manually (system has no local profile) and 3) you'd save a lot of headaches.

Is there a reason you don't use a specific account possibly?

Hi Weedee,

Thomas makes a good point here. A good revision of your scripts would be to have them actually execute under a domain account which has the necessary local admin rights to install software on your computers.

That way, you won't need to have the net use command show the account password in plain text either.

You're both right.

I'm so confused with this system too that I've forgot why I'm running my network drive mapping scripts with local system account instead domain account.

I'll check this and revert.

No worries. My servers hold a lot of 'dirty laundry'. If only I had the time to give all my jobs a spring clean! Some of my old app install jobs are years old, and are quite simply cringeworthy...

I recreated my Run Script task this morning, which runs setup.exe from V drive with Local System account and it worked. No error 1 what so ever. I swear there was no typo! :)

Could it be that if network drive is mapped with domain account /w suitable permissions, it allows also Local System account to access resources from that network drive. I guess there's no other explanation, because all my software installations (during new OS deployment) are executed with same logic:

1. Drive is mapped with domain account credentials

2. SYSTEM account is used to run installation through network drive letter.

The key to your question actually lies in the understanding of what "System" is.  Here are a few things to remember about "System"

1) No local profile.

2) No access to network

3) Full admin rights to local

Now, put those three together with various situations and you'll get the answer to your question.  For instance, the system account may not have access to network resources, but if you supply credentials, then you can get out.  Thus, the need to supply credentials.  System may not have a local profile, but if your software only installs to HKLM and not HKCU, then you're OK, right?  HKCU is the local profile (well, part of it).  System can install software that goes to all users, but not to a specific user.

That also answers why System is able to get to the network.  It doesn't, really.  The other account you supplied opens that door for System, and then System simply executes the stuff locally.  In a way....  OK - that's over-simplified.

Anyway, the problem is making the assumption that because System works in one scenario it'll work in all of them.  Truth is, MOST software will work with System rights just fine.  But not all.  The key is not ALL.  So long as you remember that, then you're good to go.

PS>  WinPE ONLY has a System Account.  Thus, if you try to execute something in the context of a specific user...  guess what?  It wont work!  If you have something you need to run in WinPE that requires you have a local profile - too bad.  Now we know why.  :D

GL moving forward.  Glad to hear all is going well.