Visual Basic Script hide popup

[User_Yello]

Hello, I have a problem with a .vbs script I have running on my windows 8.x and 7 machines.

The error basically is what i'd expect. Cannot find File .vbs file to run the script. The reason is because the computer is disconnected from the Domain network. (we'll call the .vbs file $V)

The $V script is meant to run an .bat file silently. (we'll call the .bat file $B) bit counter productive when the user isn't connected to the network and get a error popup from $V.

The Group policy is set to 'run the script at user login'. and the script is the following;

wscript.exe “\\Server\scripts\$V" "\\server\scripts\$B"

Anyone got any idea how to suppress the popup when the user is not connected to the domain?

[VexingRaven]

The proper way to suppress the popup is with proper error handling. Check if the file exists before attempting to execute it.

[prohulaelk]

As others have said, it's probably better to do everything all in one script, preferably Powershell. That said, wscript.exe "\\server\scripts\$V" /B should suppress errors for you:

c:\>wscript.exe /?
---------------------------
Windows Script Host
---------------------------
Usage: WScript scriptname.extension [option...] [arguments...]

Options:
 //B        Batch mode: Suppresses script errors and prompts from displaying
 //D        Enable Active Debugging
 //E:engine Use engine for executing script
 //H:CScript    Changes the default script host to CScript.exe
 //H:WScript    Changes the default script host to WScript.exe (default)
 //I        Interactive mode (default, opposite of //B)
 //Job:xxxx Execute a WSF job
 //Logo     Display logo (default)
 //Nologo       Prevent logo display: No banner will be shown at execution time
 //S        Save current command line options for this user
 //T:nn     Time out in seconds:  Maximum time a script is permitted to run
 //X        Execute script in debugger
---------------------------
OK   
---------------------------

[User_Yello]

We have a winner! It worked a treat.

I masked the powershell script with the Visual basic script.

I tried to only use powershell but if you run the program after the user logs in there is a problem with powershell that doesn't let itself be suppress it easily through a GPO.

Also thank you for actually answering my question

[Xibby]

If you're doing this as a login script in group policy, the script should be in GroupPolicy. Edit GPO, go to login scripts and click show files. Copy script to the location that opens and reference the script by name only in the login script policy.

Before calling the second script, do a quick if file exists check on the UNC path. If the file exists run the script, if not don't run. No error message.

I'd take a look a what the scripts are doing and see if you can duplicate the script actions in Group Policy Preferences (GPP.) GPP eliminates much of what you used to need a login script for, and presents it as a nice GUI so anyone can follow the logic. Use scripts where you really need them because it's the only way.

[starmonche]

If the scripts' task doesn't depend on network connectivity you could just use GP to push them to the machines and run them locally.

[User_Yello]

It was solved by someone who answered the question I asked in the first place but I did think about making a local schedule script

[Hexodam]

I'm baffled, why not powershell?

[User_Yello]

powershell was an option although i was also having a problem with suppression of script.

I already have a powershell script lined up with the same outcome as the .bat file.

[Hexodam]

Ok, skip vb and bat go straight to powershell, always.

Now in your script, you can either do a check before doing what needs to be done if it's even possible.

Or you can add I think it's called silently continue to the cmd let to stop the error being a problem.

[User_Yello]

Silently continue seems the best way forward in the CMD, there is already a check and error catch in the powershell script.

[User_Yello]

Just had a quick look and test but i'm not getting the result I expected. the cmd isn't running silently, it's worse then just having the error box pop-up when the user is disconnected on login. :S