Server with Cisco OS (Win 2003) problem with VB Script execution

[ian-heath]

Hi,
I have a server running Cisco's Windows Server 2003 OS.

My customer requires that this server is a member server of their corporate domain and whilst the add to the domain has been sucessful we are experiencing issues relating to the execution of some of their VB scripts.

To be clear the issue is nothing to do with the actual contents of the scripts but rather the type of scripts, whilst .VBS suffix files run OK, .SVB ones do not. (The cutomer has both types of scripts and cannot easily change them).

For testing I have a very simple script [msgbox ("Hello World")], if I save this as a Hello.VBS file it runs fine, if I save it as a Hello.SVB file it runs and gives this error:

There is no script engine for file extension ".svb"

There is seemingly nothing wrong with the file association for .svb files and I have also reinstalled Windows Script 5.7 which hasn't helped.

Any help appreciated.

Cheers Ian

[Aaron Harrison]

Hi Ian

Where to start with this one?  :-)

1) If the server is running the CIsco OS, chances quite good it's running a product that isn't supported as a member server of a domain. Principally this is so that GPOs, scripts etc are not run on the box as these may generate support issues.

2) VBS is the correct extension for VB Scripts. SVB is not, so the error you are getting is normal. The files are either not named appropriately, or the customer is using a custom script engine (e.g. kixstart or a similar product) which will probably involve installing a third party script package.

Regards

Aaron

Please rate helpful posts...

[ian-heath]

Hi Aaron,

Firstly thank you for your prompt reply.

For your information the product being installed is MeetingPlace 6.0(MR5) and the domain membership is required to facilitate the single sign-on functionality using WIA (which means that the server must be in the customers corporate domain to facilitate this).

I absolutely agree that putting a Cisco OS server in a corporate domain is not ideal but I don't have any choice here unfortunatley.

I will go-back to the customer to gain clarity on the .SVB files but to my untrained eye they look like VBscripts (dated back to 2001 looking at the comments), not sure if .SVB files used to be called .SVB?

Kind regards,

Ian

[Aaron Harrison]

Hi Ian

If you're sure they are VB Script, then grab a copy of them and rename them to vbs, then run them. If you get lots of errors, it's probaby not a vbscript. They've always had the vbs extension since day one.

Maybe someone saved it with the wrong name and it's never run on any PC; stranger things have happened.

Incidentally, what's WIA in this context? I presume it's not Windows Image Acquisition (or the Women's Institute of Australia)?

Aaron

[ian-heath]

Hi,

I have checked with the customer and also looked at the file associations.

Both .VBS & .SVB files are associated the same, i.e. both hitting the wscript.exe application.

So there must me some specific configuration within the customers build to enable wscript.exe to run .SVB files I guess.

Regarding WIA it's Windows Integrated Authentication (also called Integrated Windows Authentication).

http://en.wikipedia.org/wiki/Integrated_Windows_Authentication

Not Women's Institute of Australia lol :-)

Cheers Ian

[Aaron Harrison]

Hi Ian

Well - the bottom line is that if it's not VBScript or JavaScript, it will need a custom script engine.

If it is VBScript, it should have the .vbs suffix. A spade is a spade, so may as well be labelled one.

It's really up to the customer to tell you what is required to run that script; you shouldn't have to reverse engineer whatever they have done - after all, if this script works on their other servers, they should know what they do to make it so.

It's possible to force a script to run in a given engine by putting in a switch, so you could test it like so:

cscript scriptname.svb //E:VBScript

Regards

Aaron