• No se han encontrado resultados

2. CAPÍTULO II MARCO TEÓRICO

2.3. Marco conceptual

Script Run Location

Select one of the following options to run the script:

„ On the client computer. This option runs the script on the managed computer

to which you assign the job.

„ Locally on the Deployment Server. This option runs a server-side script on

the Deployment Server of the managed computer. In most cases you can create a server-side script task that runs in context with other tasks. Example: You can add a task to image a computer and add a task to execute a server-side script to post the imaging return codes to a log file stored on the Deployment Server computer.

Use the -id option for running scripts on Deployment Server when using the WLogEvent and LogEvent utilities. See Using LogEvent and WLogEvent in scripts on page 186.

Note

You cannot use this feature to run scripts that require user intervention. The script runs on the Deployment Server of the managed computer, but is not visible. Example: If you run a DOS command locally on the Deployment Server, the Command Prompt window does not open on the Deployment Server computer when the script runs.

When running the script on the Deployment Server, it runs specifically for the assigned managed computer. Example: If you create a job with a script to run locally on the Deployment Server and assign the job to 500 computers, the script runs on the Deployment Server 500 times.

Client run environment

Select the environment for your client computer. You can run the script either in production mode or in automation mode.

z Production - Client-installed OS (Windows/Linux/Mac OS X)

Security Context. You can specify one of the following security options for running the scripts:

„ Default (local system account). Use the network security account established

to administrate all managed computers.

„ Specific user. If you have selected to run the task on the local Deployment

Server, enter an administrator user name and password for that Deployment Server account. In most cases Deployment Server does not have the Deployment Agent installed, which prohibits it from using a network security account.

„ Run script in console user session. For Windows 2008 and Vista, you can

purposes. The script runs in a logged-in user’s UI session. If no users are logged in, the job fails.

„ Scripts run in an elevated mode, which skips the usual consent step through a

user access control (UAC). Otherwise, someone must physically go to the remote computer and approve the action to allow the script to run.

Script Window. From the drop-down list, select how you want the script window to appear: minimized, normal, maximized, or hidden.

Note

This option is available only for Windows environment. Script Options - (Windows/Linux/Mac OS X)

„ Additional command-line switches. Enter commands to execute when the

script runs in Windows, Linux, or Mac OS X.

z Automation pre-boot environment (DOS/WinPE/Linux/Mac OS X).Select

this option to run the script in an automation environment. Select a pre-boot automation environment from the drop-down list.

If you select Linux as the operating system type, the Locally on the Deployment Server option is disabled and only the Additional command-line switches under the Production Client installed OS (Windows/Linux/Mac OS X) is enabled.

If you select DOS as the operating system type, the Locally on the Deployment Server and the Production - Client-installed OS (Windows/Linux/Mac OS X) options are disabled.

Example script

The process to convert NT4 from FAT16 to NTFS normally returns a 1 after a successful completion. The following is an example of the file that is modified to return a code of 0 (which is the success code recognized by the Symantec Management Console and utilities). You can make similar changes to your script files as needed.

CONVERT /FS:NTFS

if ERRORLEVEL 1 goto success goto failure :success set ERRORLEVEL = 0 goto end :failure echo Failed set ERRORLEVEL = 1 goto end :end

Using LogEvent and WLogEvent in scripts

The logging features, LogEvent and WLogEvent, accommodate detailed logging to help debug complex scripts. These utilities include the following features:

z Logging is stored in the database instead of a log file.

z A DOS-based tool can be called from any script file to log status and error codes. z The console displays and works with the new status messages.

LogEvent posts status sends messages to the Deployment Console, letting you view the status of the script. It is a light-weight reporting tool that can log both status strings and status codes to the history file and the console.

LogEvent — Use the LogEvent utility for DOS and Linux scripts. WLogEvent — Use the WLogEvent utility for Windows scripts.

The LogEvent and WLogEvent utilities are command-line driven only — there is no user interface. Use both utilities with the following switches.

LOGEVENT -c:code -id:%ID% -l:level -ss:“message” code is any number for a return code level.

id is used for server-side scripting only. For server-side scripts you must add the

-

id:%ID%

switch.

See the Locally on the Deployment Server option in Script Information to select a server-side script. See Script information on page 185.

level is the severity level. The following levels are used: 1 = Information message

2 =Warning message

3 = Critical failure message. Only this level can be used to set up a return code. See Setting up return codes on page 193. The response does not execute for a return code unless a level 3 is specified when using the LogEvent and WLogEvent command in a script.

message is the status string. If spaces exist in the message, the string must be contained in quotes. Specifying a severity level of 3 causes the script job to fail.

Example scripts

Documento similar