
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎10-26-2015 03:33 PM
I'm trying deploy a vbscript to a group of machines and for some reason, for the windows 2008R2 targets the package is timing out.
The package is running as the scanning account (domain admin)
I can see on the target server event logs that the scanning account has triggered a logon event
I can see on the target server that the remotedeployment exe file is running
I can see on the target server that the scheduled task is running
If I run the script manually it works without issue.
The deployment works on other OS's, e.g Windows 7, Windows 2012
It looks like it's hanging after calling the remotedeployment executable as I never see a wscript.exe running on the server (its a vbscript i'm deploying).
Any suggestions?
The package is running as the scanning account (domain admin)
I can see on the target server event logs that the scanning account has triggered a logon event
I can see on the target server that the remotedeployment exe file is running
I can see on the target server that the scheduled task is running
If I run the script manually it works without issue.
The deployment works on other OS's, e.g Windows 7, Windows 2012
It looks like it's hanging after calling the remotedeployment executable as I never see a wscript.exe running on the server (its a vbscript i'm deploying).
Any suggestions?
Solved! Go to Solution.
Labels:
- Labels:
-
General Discussion
1 ACCEPTED SOLUTION

Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎10-27-2015 03:23 PM
A possible cause of the issue is that a security file warning pops up which asks for confirmation to execute the script, as it is from a network location. You can test it by deploying the package under the currently logged on user and having a look at the screen while the deployment is running.
A workaround is adding a command step which copies the VBS to the local hard-disk first. Then call the script locally instead of using the {PackageShare} in your Script step.
A workaround is adding a command step which copies the VBS to the local hard-disk first. Then call the script locally instead of using the {PackageShare} in your Script step.
2 REPLIES 2

Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎10-27-2015 03:23 PM
A possible cause of the issue is that a security file warning pops up which asks for confirmation to execute the script, as it is from a network location. You can test it by deploying the package under the currently logged on user and having a look at the screen while the deployment is running.
A workaround is adding a command step which copies the VBS to the local hard-disk first. Then call the script locally instead of using the {PackageShare} in your Script step.
A workaround is adding a command step which copies the VBS to the local hard-disk first. Then call the script locally instead of using the {PackageShare} in your Script step.

Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎10-26-2015 03:42 PM
Just to add to this. I've just come up with a work around by configuring the deployment as a command rather than a script. And setting the command as 'wscript.exe "location\of\vbsfile"
This works.
Why would it not work deploying the vbs script directly?
This works.
Why would it not work deploying the vbs script directly?
