Running a VBS script as part of a software delivery

[Migration User]

We want to runa vbs script before the actually msi runs and have added the vbs file to the package.

Under "Command Lines" we have created a new commandline and set the "Installation File Type" to Windows Script Installation File.

The Command Type is "Install".

We have set the commandline to what we run the MSIs as:

e.g., "Symantec Endpoint Protection\11.0.6\Symantec Endpoint Protection.msi" but the VBS is failing.

I assume I have the relative path wrong.

Any idea how we can do this?

[Migration User]

Do you want to execute the .vbs or an msi? If you want to execute the msi,  you have to select that as the file type (which helps build command lines). The command line you listed will execute an msi if it's in the package, but it won't look at the .vbs.

[Migration User]

Create your software resource for the SEP11 .msi, and configure it to run as you prefer.  Exclude the .vbs from the software resource.  Then create a task, 'SEP11 Pre-Install VBS Run Script Task,' which includes and runs your .vbs.  For your software delivery, either create a Managed Software Delivery which follows the .vbs Task with the SEP11 software install, or create a Job which runs the .vbs Task followed by the SEP11 task.

Software Resources are not meant to run multiple commands (e.g. a VBS and an .MSI and a .reg and a .reg).  You should stick to one cmmand per software resource.

Regarding the relative file path, let the GUI generate the command line for you -- by doing so, it will insert the correct path to the MSI.  Even if you write it yourself, you now know you have the correct path to the MSI for that software resource.

Does this help?

[Migration User]

I'm curious as to why you would exclude the .vbs as part of the resource, if it is actually in the resource location in the software library? Or, if you are just running it as a task, then I completely agree that it doesn't need to be part of the resource.

[Migration User]

My software is software, and my scripts are scripts!  An organizational decision, I guess, to keep things straight.

[Migration User]

and that sort of organization makes sense. It just seemed in this case, he was selecting a script as the type of package, yet building the command line using the msi. So, if you did a quick delivery, and selected that command line, it would most likely just run the .msi and ignore the .vbs (which the intent was to use the .vbs right?).

[Migration User]

That's what I thought.  I could see including a .vbs as part of a software resource, and using the .vbs to execute the .msi or .exe.

[Migration User]

Hi. Thanks for the responses.

I reread my post and will clarify:

I'm running both.

I want a vbs script, stored in the resource to run and then the msi.

I want the vbs script to run before the msi to change the sylink.xml.

Problem is I cannot get the vbs to run. Any ideas?

[Migration User]

This is kind of a SEP11 thing, but why not create a custom package for each group?  If your Sylink.xml file correlates to your group settings, Export an Installation Package for each group.  You can specify to remove all previous settings.

http://service1.symantec.com/support/ent-security.nsf/docid/2009022414415348

To answer your question, if you want to the VBS to run before the .MSI, you are looking at two tasks.

First Task: Copy File w/ a Command Line

• Create a Copy File task
• The task will copy the .vbs to a local destination folder of your choosing
• Under File Execute, for Command Line, enter the command line to run the .vbs
• Include credentials with admin rights as appropriate

Second Task: Deploy the SEP11 Software Resource

• Create a Quick Delivery task
• Select your software resource and a silent install command line.  While troubleshooting/testing, you may want to use /QB in place of /QN so that you can see error messages.

[Migration User]

1. Create a client task using the Run Script task type.  Copy and paste your vbscript into the window and give it a meaningful name
2. Create a new Software Resource for SEP 11 and select the MSI as the installation file
3. Create a new Managed Delivery job and use the 'add task' option to select your vbscript.
4. Choose the Add Software Resource option now and then select your SEP 11 software resource.
5.  Select your compliance schedule and targets and this will ensure that your script always runs before executing the SEP 11 msi.

Done!

[Migration User]

They are valuable suggestions however, SEP will use whatever Sylink.xml is in the root of the install directory. If we run the vbs as suggested above, how do we figure out the GUID SEP will use to install? We don't want to hard code it.

For example, say we did what you suggets above, we now have Sylink.xml we can use - thats no problem.

We now need to install SEP using this Sylink.xml. We need to put this file in the SEP install directory before SEP gets installed.

[Migration User]

Create SEP11 install packages designed for each group.  By default, they include the policies and settings for that group -- including the Sylink.xml file.  By specifically creating a package for each group, computers start with the correct policy and communication settings right away.  If you make any significant changes to your client group policies or communication settings, recreate the install packages.  A "significant change" would be a setting that a client cannot wait 1-2 minutes to obtain after install.

In a sense, it could be considered inconvenient, because you have to create multiple software resources.  But this isn't any more inconvenient than creating multiple Sylink.xml jobs.

[Migration User]

What we do is deliver a vbscript alongside the msi, execute the vbscript.  Have the main portion of the vbscript perform the scripted function you want, then have the last part of the script kick off your msi.  We do this all the time and it works like a charm.