Symantec ALTIRIS DEPLOYMENT SOLUTION 6.9 SP4 - V1.0, Руководство пользователя

Страница: 237 / 503

Deployment Solution 237
Deploying Scripts
After replacing tokens in the script itself, the server processes the next command in this
script: ReplaceTokens. Since the token replacement process already replaced the
compname token, the ReplaceTokens command works as expected and creates a unique
system.inf file for each computer, containing values unique to that computer.
The script is delivered to the client, and the Firm utility finds the correct file on the
eXpress share to copy to the production drive. A similar process can be used to deploy
configuration files to Linux computers, as a large number of Linux configuration files are
text-based.
If you perform Linux configuration often, you might want to set up an additional
database containing common configuration values you can retrieve using tokens.
Running Scripts on the Server
Scripts can optionally execute on the server on behalf of the client. This is very
important to understand, because token replacement and other commands are based on
the client assigned the job, not the server.
Example: consider the script we reviewed in the previous section:
REM ReplaceTokens .\temp\sysprep.inf .\temp\%COMPNAME%.txt
Firm Copy f:\temp\%COMPNAME%.txt PROD:\sysprep.inf
If we marked this script to execute on the server, the initial token replacement still
contains the name of the computer targeted by the scripting task. However, the
command in the second line fails because the server looks for the paths specified by
Firm on the server, not the client.
This is valuable when you want to retrieve tokens specific to a number of computers, but
the script can execute successfully on the server. This can relieve network traffic and
prevent interruptions on managed computers.
However, when a script runs server-side, the script is executed separately for each
computer assigned to the task. A task assigned to 500 computers causes any server-
side scripts in the task to execute 500 times on the server. If you have processor
intensive commands, you might want to avoid server-side execution to prevent
disruptions on your server, or perform the task during off-hours.
Also, when running scripts server-side, avoid commands that require interaction. The
DS service does not have interaction with the desktop, so there is no way to provide
even simple feedback in scripts that run server-side.
Reporting Errors
One of the biggest challenges when running scripts is implementing effective error
reporting and feedback.
In DS, every task has the ability to handle error codes returned from a job, and take
action based on this code. By default, a scripting task returns a 0 for success, and a 1 if
the script fails to execute. This might be sufficient for a simple script, but scripts can
often execute successfully yet still fail to perform the intended tasks.
Additionally, if you create a batch file with three commands, the status reported on
completion is the status of the final command in the script. The first two commands
might return errors, but if the final command is successful you receive a status of
success.