|
|
|
In practice, the only reason to run a scanning job from a command line is for security reasons when scanning a database (because this method allows you to avoid storing database logon credentials in the job definition).
Be aware that when you run a scan from a command line, the job runs under your Windows logon account. That is, unlike jobs defined using the FSA Job Definition wizard, you cannot choose the job’s Run As user. You must therefore ensure that you are logged on to Windows using an account with appropriate permissions.
To run scanning job commands
<path>\wgnfstub /job <job name> [/console] [/server <FSA server>] [/user] [/password]
where:
Is the name of an existing scanning job. You specify job names when you run the job definition wizard in the Administration console.
Note: If a job name contains spaces, it must be enclosed in quotes.
Is optional. It communicate any errors encountered during the scanning job (for example, if a job cannot be run). This command also enables you to manually stop a scanning job, ensuring first that any events still being processed are completed. To do this use the keyboard shortcut Ctrl-C or Ctrl‑Break during a scanning job.
Is optional. It identifies the name or IP address of the FSA host machine. You must use this parameter if you are running the wgnfstub command on a machine that is not hosting the FSA. For example, you must use this parameter if you run the command on a machine that has the FSA Remote Connector installed.
Are optional parameters for database scans. Their purpose is to avoid the security risk of storing database credentials in a scanning job definition. If these parameters are used, they cause the FSA to prompt you for the logon credentials that it will use to access the target database objects.
For example, this command runs the ‘My Oracle Scan’ job and prompts for the database logon account:
<path>\wgnfstub.exe /job "My Oracle Scan" /console /user /password
| Copyright © 2011 CA. All rights reserved. | Email CA Technologies about this topic |