Repository Configuration

Overview

There are a wide variety of Repository options that can be configured. These options can be modified at any time from the Deadline Monitor while in Super User Mode by selecting Tools -> Configure Repository Options. If you want to restore all the Repository Options to their defaults, simply click the Reset Settings button.

../_images/cro_reset_button.png

Note that long-running applications like the Launcher, Slave, and Pulse only update these settings every 10 minutes, so after making changes, it can take up to 10 minutes for all machines to recognize them. You can restart these applications to have them recognize the changes immediately.

Client Setup

These settings affect the Deadline Client installed on each machine.

  • Remote Administration: Enabling Remote Administration allows the Deadline Clients to be controlled remotely from the Monitor running on another machine. Note that this can be a security risk if you are not behind a firewall.
  • Automatic Upgrades / Downgrades: Enabling Automatic Upgrades / Downgrades allows the Deadline Clients to detect if the Repository has been changed via the running of the Deadline Repository Installer and upgrade/downgrade themselves if necessary. Note that the upgrade check is only performed when launching applications via the Launcher. Finally, this is NOT an “Automatic Update” system and does NOT automatically download and install a new version of Deadline to either your repository or clients. Instead, this system allows all your Deadline clients to automatically upgrade/downgrade themselves, based on the version of Deadline installed to the Deadline Repository via the Repository Installer executable. So, in summary, you run the Deadline repository installer on the repository machine and with this setting enabled, the next time any of the Deadline local applications are started via the ‘launcher’ application, they will be upgraded/downgraded accordingly.
../_images/cro_client_setup.png

Monitor Settings

These settings affect the Deadline Monitor application on each machine.

Monitor Layouts

Existing Monitor layouts can be added here. These layouts can be assigned to User Groups as a user’s default layout. If the Pinned option is enabled, they can also be chosen from the Pinned Layouts menu in the Monitor. The order of the layouts here will be the same in the Pinned Layouts menu.

../_images/cro_ms_monitor_layouts.png

To add a new layout, simply press the Add button, and then choose an existing Monitor layout file, or use the current Monitor’s layout. Note that Monitor layout files can be saved from the Monitor by selecting View -> Save Layout.

../_images/add_monitor_layout.png

Update Settings

Enable Manual Refreshing

If your Auto Refreshing Intervals are set to longer intervals, manual refreshing in the Monitor can be enabled to allow users to get the most up to date data immediately. To prevent users from abusing manual refreshing, a minimum interval between manual refreshes can be configured.

Sorting and Filtering

For farms that have a large number of jobs (10,000+) or slaves (1000+), disabling Automatic Sorting and Filtering in the lists in the Monitor can improve the Monitor’s overall performance. This option in the Repository Options can be used to disable Automatic Sorting and Filtering by default, and users can enable it later in their Monitors if desired.

../_images/cro_ms_update_settings.png

Slave Settings

These settings affect the Deadline Slave application on each machine.

Slave Settings

General

  • Limit the number of characters per line for standard output handling: Lines of standard output that are longer than the specified limit will be ignored by the Slave’s stdout handling.
  • Delete Offline/Stalled Slaves from the Repository after this many days: Slaves that are Offline or Stalled will be removed from the Repository after this many days.
  • Gather System Resources (CPU and RAM) When Rendering Tasks On Linux/Mac: If enabled, the Slave will collect CPU and RAM usage for a task while it is rendering. We have seen cases where this can cause the Slave to crash on Linux or Mac, so you should only disable this feature if you run into this problem.
  • Use fully qualified domain name (FQDN) for Machine Name instead of host name: If enabled, the Slave will try to use the machine’s fully qualified domain name (FQDN) when setting its Machine Name instead of using the machine’s host name. The FQDN will then be used for Remote Control, which can be useful if the remote machine name isn’t recognized in the local network. If the Slave can’t resolve the FQDN, it will just use the host name instead.
  • Use Slave’s IP Address for Remote Control: If enabled, the Slave’s IP address will be used for remote control instead of trying to resolve the Slave’s host name.

Wait Times

  • Number of Minutes Before An Unresponsive Slave is Marked as Stalled: If a slave has not provided a status update in this amount of time, it will be marked as stalled.
  • Number of Seconds To Wait Fora Response When Connecting to Pulse: The number of seconds a salve that is connected to plus will wait for pulse to respond when querying for a job.
  • Number of Seconds Between Thermal Shutdown Checks if Pulse is Offline: The number of seconds between thermal shutdown checks. The Slave only does this check if Pulse is not running.
../_images/cro_slave_settings.png

Extra Properties

Extra arbitrary properties can be set for slaves, and these properties can be given user friendly names so that they can easily be identified and used to filter and sort slaves in the Monitor.

../_images/cro_slave_settings_ep.png

Performance Settings

These settings are used to influence the performance of Deadline by modifying update intervals.

Auto Adjust

The auto adjust option will try to choose the best interval settings based on the number of slaves in your farm. These should act as a good base that you can modify later as necessary. Press the Auto Adjust button to bring up the interval settings. Note that this will show you what your current settings are, and what they’ll be changed to based on the number of slaves you entered.

../_images/cro_performance_auto_adjust.png

Monitor Referesh Intervals

  • Number of Seconds Between Job Updates: This controls how often the Monitor reads in new job updates.
  • Number of Seconds Between Slave Updates: This controls how often the Monitor reads in new slave updates.
  • Number of Seconds Between Pulse Updates: This controls how often the Monitor reads in new pulse updates.
  • Number of Seconds Between Limit Updates: This controls how often the Monitor reads in new limit updates.
  • Number of Seconds Between Settings Updates: This controls how often the Settings such as groups, pools and users are updated.
  • Number of Seconds Between Cloud Updates: This controls how often the Monitor updates the Cloud Panel.
  • Number of Seconds Between Balancer Updates: This controls how often the Monitor reads in new Balancer updates.

Slave Intervals

  • Number of Seconds Between Slave Information Updates: This controls how often the Slave updates the information that’s shown in the Slave list in the Monitor.
  • Number of Seconds Between Queries For New Tasks While the Slave is Rendering: The number of seconds a Slave will wait after it finishes a task before moving on to another. This delay is not applied when the Slave is idle.
  • Multiplier to determine seconds between queries while the Slave is Idle: The multiplier to be applied to the number of slaves that will determine how long a slave will wait between polls to the Repository for tasks when it is idle.
  • Maximum number of seconds between Job queries while the Slave is Idle: The maximum number of seconds a slave will wait between polls to the Repository for tasks when it is idle.
  • Minimum number of seconds between Job queries when the Slave is Idle: The minimum number of seconds a slave will wait between polls to the Repository for tasks when it is idle.
../_images/cro_performance.png

Pulse Settings

These settings control how the Slaves connect to Pulse for Throttling, and are also used by the Slave to determine if Pulse is running.

General

  • Maximum Incoming Connections: The maximum number of Slaves that can connect to Pulse at any given time.
  • Connection Timeout (in milliseconds): The number of milliseconds messages to and from Pulse have to complete before they timeout.
  • Maximum Connection Attempts: The maximum number of times a Slave will attempt to connect to Pulse before giving up.
  • Stalled Pulse Threshold (in minutes): Deadline determines if a Pulse has stalled by checking the last time that the Pulse has provided a status update. If a Pulse has not updated its state in the specified amount of time, it will be marked as Stalled.
  • Use Pulse’s IP Address When Slaves Connect To Pulse and For Remote Control: If enabled, the Pulse’s IP address will be used when the slaves connect to pulse, and for remote control, instead of trying to resolve the Pulse’s host name.
../_images/cro_pulse_general.png

Power Management

  • Power Management Check Interval: How often Pulse performs Power Management operations.
../_images/cro_pulse_power.png

Throttling

Throttling can be used to limit the number of slave applications that are copying over the job files at the same time. This can help network performance if large scene files are being submitted with the jobs. Note that a Slave only copies over the job files when it starts up a new job. When it goes to render subsequent tasks for the same job, it will not be affected by the throttling feature.

  • Enable Throttling: Allow throttling to occur.
  • Maximum Number of Slaves That Can Copy Job Files at The Same Time: The maximum number of Slaves that can copy a scene file at the same time.
  • The Interval a Slave Waits Between Updates To See If It Can Start Copying Job Files: The amount of time(in seconds) a Salve will wait to send throttle checks and updates to Pulse.
  • Throttle Update Timeout Multiplier (based on the Slave Interval): The interval a slave waits between updates is multiplied by this value to determine the timeout value.
../_images/cro_pulse_throttling.png

Web Service

Enable the Web Service

The Web Service allows you to execute commands and scripts from a browser, and must be enabled to use the Mobile applications and the Pulse RESTful API (see REST Overview). While there is a standalone web service application, it can also be enabled in Pulse if you are running it. All other Web Service settings can be set in the Web Service page, which is covered further down this page.

  • Enable the Web Service: Makes the Pulse Web Service Available. Note that if you enable or disable the Web Service feature while Pulse is running, it must be restarted for the changes to take effect.
../_images/cro_pulse_web_service.png

Balancer Settings

These settings control general settings for the Balancer.

  • Balancer Update Interval: How often the Balancer performs a balancing cycle.
  • Current Algorithm Logic: The Balancer Plugin to use for determining balancing targets.
  • Use Balancer’s IP Address for Remote Control: If enabled, the Balancer’s IP address will be used for remote control instead of trying to resolve the Balancer’s host name.
  • Stalled Balancer Threshold (in minutes): Deadline determines if a Balancer has stalled by checking the last time that the Balancer has provided a status update. If a Balancer has not updated its state in the specified amount of time, it will be marked as Stalled.
  • Error Tolerance: How many times we try to connect to the primary Balancer before it fails and we make another Balancer the new primary.
  • Enable Group Switching: If there are group mappings that have the same image and hardware types instances will move between groups as needed. If it’s not enabled instances will shutdown and startup like normal.

The settings for the currently selected Algorithm Logic will be shown here as well (if there are any settings).

../_images/cro_balancer.png

Region Settings

This is where you can set up Regions in Deadline. Regions are logical groupings for slaves and users. Cross Platform Rendering and Balancer Settings can be unique to each region. For example a slave that’s in the ‘thinkbox_west’ Region will use the path mapping settings for that Region. The list on the right shows the Cloud Regions and the list on the left shows the general Regions. Regions must have a unique name.’all’ and ‘none’ are reserved names that cannot be used. See Regions for more information.

../_images/cro_region_settings.png

Email Notification

This section handles all email related settings within the repository.

Primary and Secondary Server

Set up a primary SMTP server to send email notifications. You can set up an optional secondary SMTP server for Deadline to use if the primary server is unavailable.

  • SMTP Server: The SMTP server used by Deadline to send emails.
  • Sender Account: The email account that Deadline will use to send emails from.
  • Port: The SMTP port to use.
  • Use SSL: The email account from which the notifications will be sent.
  • SMTP Server Requires Authentication: Enable if the SMTP server requires a user name and password to authenticate.
  • Testing: Send a test email to the specified email address.
  • Automatically Generate Email Addresses for New Users: Generates new email address for new users in the form username@postfix, where ‘postfix’ is the value entered in the Email Address Postfix field.
../_images/cro_en_primary.png

Note that if you have SSL enabled, you may need to configure your Linux and OSX machines for SSL to work. The process for doing this is explained in Mono’s Security Documentation.

If you using Google Mail to send emails (smtp.gmail.com), you will typically use port 25 if SSL is disabled, and port 465 if SSL is enabled. See Google’s documentation on Sending Emails for more information.

Notifications

  • Job Completed: When a job completes, an email will be sent to these email addresses.
  • Job Timed Out: When a job times out, an email will be sent to these email addresses.
  • Job Error Warning: When a job accumulates a certain number of errors, a warning email will be sent to these email addresses. You can configure the warning limit in the Failure Detection settings.
  • Job Failed: “When a job fails, an email will be sent to these email addresses.
  • Job Corrupted: When a corrupted job is detected, an email will be sent to these email addresses.
  • Slave License Errors: “When a slave is unable to get a license, an email will be sent to these email addresses.
  • Slave Status Errors: When a slave is unable to update its state in the Repository, an email will be sent to these email addresses.
  • Slave Error Warning: When a slave accumulates a certain number of errors in one session, a warning email will be sent to these email addresses. You can configure the warning limit in the Failure Detection settings.
  • Stalled Slave: When a stalled slave detected, an email will be sent to these email addresses.
  • System Administrator: When users use the option in the Error Report Viewer to report error messages to their system administrator, those emails will be sent to these email addresses.
  • Low Database Connections: Low Database connection notification emails will be sent to these email addresses.
  • Database Connection Thresholds: When the number of available database connections is below the set threshold a warning email will be sent.
../_images/cro_en_notifications.png

Power Management Notifications

  • Idle Shutdown: Notifications for Idle Shutdown operations will be sent to these email addresses.
  • Machine Startup: Notifications for Machine Startup operations will be sent to these email addresses.
  • Thermal Shutdown: Notifications for Thermal Shutdown operations will be sent to these email addresses.
  • Machine Restart: Notifications for Machine Restart operations will be sent to these email addresses.
../_images/cro_en_power.png

House Cleaning

Pending Job Scan

  • Pending Job Scan Interval: The maximum amount of time between Pending Job Scans in seconds.

  • Allow Slaves to Perform the Pending Job Scan If Pulse is not Running: If enabled, the Slaves will perform the pending job scan if Pulse is not running. If disabled, only Pulse can perform the pending job scan.

  • Run Pending Job Scan in a Separate Process: If enabled, the pending job scan will be run in a separate process. This can be useful when using dependency scripts to ensure that a crash caused by the script doesn’t cause the main application (Pulse, Slave, or Monitor) to crash.

    • Write Pending Job Scan Output to Seperate Log File: If enabled, all output from the pending job scan will be placed into a seperate log file.
    • Pending Job Scan Process Timeout: If running the pending job scan in a separate process, this is the maximum amount of time the process can take before it is aborted.
  • Asynchronous Job Events: If enabled, many job events will be processed asynchronously by the Pending Job Scan operation, which can help improve improve the performance of the Monitor when performing operations on batches of jobs. If this is enabled, the OnJobSubmitted event will still be processed synchronously to ensure that any updates to the job are committed before the job can be picked up by Slaves.

    • Maximum Job Events Per Session: The maximum number of pending job events that can be processed per scan.
../_images/cro_house_pending.png

House Cleaning

  • House Cleaning Interval: The maximum amount of time between House Cleaning operations in seconds.

  • Allow Slaves to Perform House Cleaning If Pulse is not Running: If enabled, the Slaves will perform house cleaning if Pulse is not running. If disabled, only Pulse can perform house cleaning.

  • Run House Cleaning in a Separate Process: If enabled, the house cleaning operation will be run in a separate process.

    • Write House Cleaning Output to Seperate Log File: If enabled, all output from the house cleaning will be placed into a seperate log file.
    • House Cleaning Process Timeout: If running the house cleaning in a separate process, this is the maximum amount of time the process can take before it is aborted.
  • House Cleaning Maximum Per Session

    • Maximum Deleted Jobs: The maximum number of deleted jobs that can be purged per session.
    • Maximum Archived Jobs: The maximum number of jobs that can be archived per session.
    • Maximum Auxiliary Folders: The maximum number of job auxiliary folders that can be deleted per session.
    • Maximum Job Reports: The maximum number of jobs report files that can be deleted per session.
../_images/cro_house_cleaning.png

Repository Repair

  • Repository Repair Interval: The maximum amount of time between Repository Repair operations in seconds.

  • Allow Slaves to Perform the Repository Repair If Pulse is not Running: If enabled, the Slaves will perform the repository repair if Pulse is not running. If disabled, only Pulse can perform the repository repair.

  • Run Repository Repair in a Separate Process: If enabled, the repository repair operation will be run in a separate process.

    • Write Repository Repair Output to Seperate Log File: If enabled, all output from the repository repair will be placed into a seperate log file.
    • Repository Repair Process Timeout: If running the repository repair in a separate process, this is the maximum amount of time the process can take before it is aborted.
  • Automatic Primary Election: If enabled, the Repository Repair operation will elect another running Pulse/Balancer instance as the Primary if the current Primary instance is no longer running.

../_images/cro_repo_repair.png

Auto Configuration

This allows you to configure your Slaves from a single location. When a Slave starts up, it will automatically pull this configuration from Pulse and apply it before fully initializing. See the Auto Configuration documentation for more information.

../_images/cro_auto_config.png

User Security

  • Super User Password: The password needed to access Super User Mode in the Monitor. Leave blank for no password.

  • Enhanced User Security: When using the System User for the Deadline User, the only way to switch Deadline users is to log off the system and log back in as someone else. This helps improve Deadlines’s user security, as it prevents users from impersonating others to modify their jobs.

    • Use The System User For The Deadline User: Enable to use enhanced user security, which prevents users from impersonating others.
  • Rendering Jobs As User: By default, the rendering process will run under the same user account that the Slave is running as. If Render Jobs As User is enabled, the rendering process will run under the user account associated with the user that submitted the job. Each Deadline user must have their Render Jobs As User settings configured properly for this to work. On Windows, the user’s Run As Name, Domain, and Password settings will be used to start the rendering process as that user. On Linux and Mac OS X, only the user’s Run As Name setting will be used with ‘su’ or ‘sudo’ to start the rendering process as that user. Note that on Linux and Mac OS X, the Slave must be running as root for this to work properly.

    • Render Jobs As User: Enable to have jobs render as the user that submitted them.
    • Use ‘su’ Instead Of ‘sudo’ On Linux and Mac OS X: If enabled, ‘su’ will be used to run the process as another user instead of ‘sudo’. This setting is ignored on Windows.
    • Preserve Environment On Linux and Mac OS X: If enabled, the user environment will be preserved when running the process as another user using ‘su’ or ‘sudo’. This setting is ignored on Windows, and is ignored on Mac OS X when using ‘su’ instead of ‘sudo’. Note that when this option is disabled, any environment variables that are set for the process by the render plugin are ignored because su or sudo will reset the environment.
../_images/cro_user_security.png

Job Settings

Job Scheduling

Scheduling Order

  • Job Scheduling Order: The order of priority that Deadline uses to schedule jobs. See the Job Scheduling documentation for more details.
  • Priority Weight: Weight given to job priority when using a Weighted scheduling order.
  • Submission Time Weight: Weight given to job submission time when using a Weighted scheduling order.
  • Error Weight: Weight given to the number of errors a job has when using a Weighted scheduling order.
  • Rendering Task Weight: Weight given to the number of rendering tasks a job has when using a Weighted scheduling order.
  • Rendering Task Buffer: A buffer that is used by slaves to give their job extra priority on the farm.
  • Enhanced Balancing Logic: If enabled, a more enhanced method of balancing slave between jobs is used, which should prevent slaves from jumping between jobs as much. This feature is still considered experimental.

Submission Limitations

  • Task Limit For Jobs: The maximum number of tasks a job can have. Note that this does not impose a frame limit so you you can always increase the number of frames per task to stay below this limit.
  • Maximum Job Priority: The maximum priority value a job can have.

Automatic Job Timeout

Configure Deadline to automatically determine a timeout for a job based on the render times of tasks that have already completed. If a task goes longer than that timeout, a timeout error will occur and the task will be requeued.

  • Minimum number of completed tasks required before calculating a timeout: The minimum number of tasks that must be completed before Auto Job Timeout Checking occurs.
  • Minimum percent of completed tasks required before calculating a timeout: The minimum percent of tasks that must be completed before Auto Job Timeout Checking occurs.
  • Enforce an automatic job timeout for all jobs: If enabled, the Auto Job Timeout will be enabled for all jobs overriding the per job specification of the value.
  • Timeout Multiplier: To calculate the Auto Job Timeout, the longest render time of the completed tasks is multiplied by this value to determine the timeout time.
../_images/cro_js_job.png

Failure Detection

Job Failure Detection

Sends warnings and fail jobs or tasks if they generate too many errors.

  • Send a warning to the job’s user after it has generated this many errors: A warning will be sent to the job’s notification list once its error count has reach. By default, the submitting user is automatically added to this list.
  • Mark a job as failed after it has generated this many errors: The number of errors a job must throw before it is marked as failed.
  • Mark a task as failed after it has generated this many errors: The number of errors a task must throw before it is marked as failed.
  • Automatically delete corrupted jobs from the Repository: If enabled, if a job is found to be corrupted it will it will be automatically removed from the the Repository.
  • Maximum Number of Job Error Reports Allowed: This is the maximum number of error reports each job can generate. Once a job generate this many errors it will fail and can not be resumed until some of it’s error reports are deleted or this value is increased.

Slave Failure Detection

Sends warnings and prevent Slaves from reattempting jobs that keep generating errors.

  • Send a warning after a Slave has generated this many errors for a job in a row: The maximum number of errors that can occur before email warnings are sent to the users specified in the Email Notification section.
  • Mark a Slave as bad after it has generated this many errors for a job in a row: If a Slave hits this many errors, it will be marked as bad for its current job.
  • Frequency at which a slave will attempt a job that it has been marked bad for: The percentage of time a Slave will attempt a task it has been marked bad for if no good jobs are available.
../_images/cro_js_failure.png

Cleanup

Automatic Job Cleanup

  • Cleanup Jobs After This Many Days: If enabled, this is the number of days to wait before cleaning up un-archived jobs.
  • Cleanup Mode: Whether the cleanup should archive the jobs found or delete them.
  • You can also set the number of hours since the job was last modified before cleaning it up.

Deleted Job Purging

  • Set the number of hours after a job has been deleted before it is purged from the database.
../_images/cro_js_cleanup.png

Auxiliary Files

Many jobs have an option to submit the scene file and other auxiliary files with the job. This can be useful because it stores a copy of the scene file with the job that can be referred to later. However, if the size of these files are large and the Repository server isn’t designed to handle this load, it can seriously impact the Repository machine’s performance. This problem can be avoided by storing these files in a location on a different server that is designed to handle the load.

  • Store job auxiliary files in a different location: If enabled, job auxiliary files submitted to Deadline will be stored at a location specified and not the Repository.
../_images/cro_js_auxiliary.png

Extra Properties

Extra arbitrary properties can be submitted with a job, and these properties can be given user friendly names so that they can easily be identified and used to filter and sort jobs in the Monitor.

../_images/cro_js_extra.png

Application Logging

Application Log Cleanup

  • Delete Monitor logs after this many days: The number of days before a Monitor log will be deleted.
  • Delete Slave logs after this many days: The number of days before a Slave log will be deleted.
  • Delete Pulse logs after this many days: The number of days before a Pulse log will be deleted.
  • Delete Balancer logs after this many days: The number of days before a Balancer log will be deleted.
  • Delete Launcher logs after this many days: The number of days before a Launcher log will be deleted.

History Entries

  • Maximum Number of Repository History Entries: The maximum number of repository history entries that are stored before old entries are overwritten.
  • Maximum Number of Job History Entries: The maximum number of job history entries that are stored before old entries are overwritten.
  • Maximum Number of Slave History Entries: The maximum number of slave history entries that are stored before old entries are overwritten.
  • Maximum Number of Pulse History Entries: The maximum number of pulse history entries that are stored before old entries are overwritten.
  • Maximum Number of Balancer History Entries: The maximum number of balancer history entries that are stored before old entries are overwritten.

Logging Verbosity

  • Slave Verbose Logging: If enabled, more information will be written to the Slave log while it is running.
  • Pulse Verbose Logging: If enabled, more information will be written to the Pulse log while it is running.
  • Balancer Verbose Logging: If enabled, more information will be written to the Balancer log while it is running.
../_images/cro_logging.png

Statistics Gathering

Configure Deadline to keep track of job and farm statistics. Note that Pulse must be running to gather Slave and Repository statistics. Job statistics will be gathered regardless if Pulse is running or not.

  • Enable Statistics Gathering: If enabled, Deadline will gather statistical information.
  • Slave Statistics Gathering Interval(in minutes): The amount of time between polling Slaves for statistical information.
  • Repository Statistics Gathering Interval(in minutes): The amount of time between polling the Repository for statistical information.
  • Delete Job Statistics After This Many Days: The number of days from generation that job statistics will be kept before they are deleted.
  • Delete Slave Statistics After This Many Days: The number of days from generation that Slave statistics will be kept before they are deleted.
  • Delete Repository Statistics After This Many Days: The number of days from generation that Repository statistics will be kept before they are deleted.
../_images/cro_stats_gathering.png

Mapped Paths

Paths to be mapped before rendering(based on Operating System). You may add, remove, or edit paths as well as modify the order in which they will be mapped. See the Cross Platform Rendering section for more details.

../_images/cro_paths.png

Mapped Drives

Drives to be mapped before rendering(Windows Only).

  • Drive: The drive to be mapped.
  • Remote Path: The remote path for the drive.
  • Only Map If Unmapped: Enable to only map the drive if it is unmapped. Disabled by default.
  • Requires Authentication: (Optional) Enable if the drive requires authentication. If unchecked, the existing logged in user account credentials will be used.
  • Username: Username. Must not be blank.
  • Password: Password. Must not be blank.

Note, drives can be mapped when running as a service. Beware that if a user is logged in and has mapped drives set up for them, the Deadline Slave service won’t see them because they run in a different environment. However, if the drives are mapped in the service’s environment (which is what the slave is doing), then they will work fine. Using the following setting can help remove this potential situation.

  • Only map drives when the Slave is running as a service: If checked, the slave will only map the drives if it’s running as a service. If unchecked, it will also do it when the slave is running as a normal application.
../_images/cro_drives.png

Script Menus

There are many scripts that ship with Deadline, and it’s more than likely that you don’t need to use them all, especially the submission scripts. Here, you can configure the contents of the individual script menus to only display what you use. You can also set icons and keyboard shortcuts for your script menu items. If a script menu item has the same shortcut as an existing menu item, the script menu item’s shortcut will take precedence.

Note though that these settings will affect all Monitors that connect to this Repository.

../_images/cro_script.png

Python Settings

A list of additional paths to be added to the Python search paths. Specify one path per line, and use the Add Path button to browse for paths.

../_images/cro_python.png

Wake On Lan Settings

Deadline’s Power Management uses Wake On Lan to wake up machines, and you can configure which port(s) the WOL packet is sent over. If no ports are listed here, Deadline will use port 9 by default.

../_images/cro_wake.png

Web Service

The Web Service allows you to execute commands and scripts from a browser, and must be enabled to use Deadline’s Mobile applications. The Web Service can be run as a console application or as part of Pulse. Note that only one instance of the Web Service can run on a machine at a time. Also note that all changes to the Web Service settings require the Web Service to be restarted before they will be implemented.

  • Listening Port: The port on which the Web Service will listen.
  • Connection Limit: The maximum number of concurrent connections allowed for the Pulse Web Service.
  • Connection Timeout(in seconds): The amount of time in between sending and receiving messages to and from the Web Service before a timeout occurs.

If the Web Service requires authentication, users would use their Deadline user name along with the password stored in their User Settings. If empty passwords are allowed, they can leave their password setting blank.

  • Require Authentication: If enabled, the Pulse Web Service will require a username and password. These are stored in the user settings.
  • Allow Empty Passwords: If enabled, the Web Service will accept empty passwords.
  • Allow Execution of Non-Script Commands: If enabled, users are allowed access to Deadline Command commands.
../_images/cro_web_service.png