Cannot Deploy SVS layers to student/lab machines using NS or DS

LShackleton's picture

Hi,

My problem is basically that I cannot deploy any of the tested and working SVS apps to any machine in the "student" OU of our domain. The process works fine up to a point, and the stages that succeed are:

"Sending package '.\SVS Layers\test.vsa'.."
"Transferring file.."
"Importing Package: "test.vsa"

Almost immediately after this stage I get the following error:

"The system cannot find the file specified."

With a status code listed as "2".

Does anyone have any ideas on this? I'm a little stuck! I can't see how a group policy could even have an effect since the layers should be importing with system privileges?

Thanks for any suggestions,

Laurence

LShackleton's picture

I forgot to mention that I

I forgot to mention that I have tried deployments using both Deployment server and software delivery tasks in NS, and that manually importing SVS layers when at the machine if the admin tool is installed works just fine.

LShackleton's picture

Just thought I'd update my

Just thought I'd update my post in case anyone ever ran into the same problem, especially this would be useful I think to anyone in Education where huge lab images with hundreds of installed apps become a problem.

SVS layers were not importing not because of group policy or any security restrictions, which we assumed was the case anyhow since the layers should import with administrator/system rights. However there is so much software on the lab images that when the SVS agent install happens, it only appends the SVS Agent directory to the PATH variable, which is so incredibly long thatwindows is no longer paying attention to the latter items in the path. Placing the SVS agent path at the beginning has resolved our issue 100%.

matthilt's picture

How to update PATH automatically?

How did you update the PATH variable? Is there a way to do it by script without loosing the other information that's already there?

EdT's picture

The system path is stored in

The system path is stored in the registry - HKLM/System/CurrentControlSet/Control/SessionManager/Environment - look for the path value in that key. You could load the existing value, edit it and save it back, but the change will only be recognised by the operating system after a reboot.

If you are deploying an MSI, you can add to the system path, and have the choice of pre-pending or appending. In this case, prepending would be the best choice. I believe the MSI install sends an API call to open windows so that they reload the environment and thus the new path is available without a reboot.

If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.

cwitter's picture

You could try and put the

You could try and put the exact path to svscmd.exe in the SWD task. This should also solve the problem without the need to update the path variable. I assume you have the svs agent installed in the same location on each machine, otherwise you could call a variable there too. For example %programfiles%\Altiris\SVS Agent\svscmd.exe. Hope this helps.

Craig