I tried running 3ds Max 2024 with AWS Deadline Cloud's CMF

Introduction

In render farm operations using DCC (Digital Content Creation) applications for 3DCG / VFX production, how you supply licenses to Workers is a foundational design decision. AWS Deadline Cloud offers a mechanism called UBL (Usage-Based Licensing) that allows pay-per-use licensing based on job execution time, and the official documentation states it can be used with both SMF (Service-Managed Fleet) and CMF (Customer-Managed Fleet) for supported DCC applications and versions.

However, UBL supported versions are limited per product. For 3ds Max, only versions 2025 and 2026 are eligible for UBL at the time of writing, meaning 3ds Max 2024, the subject of this article, is not supported. Therefore, to run 3ds Max 2024, you need to supply a bring-your-own license (BYOL) to the Worker. This article covers a configuration where users activate 3ds Max on Workers using their own contracted Autodesk subscription. We share the verification results along with three insights gained during the process.

What is AWS Deadline Cloud

AWS Deadline Cloud is a managed service for building render farms in the cloud for 3DCG / VFX production. It provides the functionality needed for render farm operations, including Worker auto-scaling, job management, and license provisioning.

Target Audience

• Those building or considering building CMF on AWS Deadline Cloud
• Those wanting to build a render farm for Autodesk 3ds Max 2024 on AWS
• Those comparing Worker configurations when using versions not covered by UBL

References

• AWS Deadline Cloud Developer Guide: Using software licenses
• AWS Deadline Cloud Developer Guide: Connect customer-managed fleets to a license endpoint
• AWS Deadline Cloud User Guide: Autodesk 3ds Max
• aws-deadline/deadline-cloud-for-3ds-max

Verification Goals and Configuration

The verification aimed to satisfy all four of the following criteria:

1. A job submitted from the Submitter runs to SUCCEEDED on the Worker EC2
2. During job execution, 3ds Max launches on the Worker, references the bring-your-own license activation information, and proceeds with headless rendering (without showing a sign-in dialog)
3. The rendered PNG file can be retrieved via S3
4. The Worker Agent service continues to participate in the Fleet in IDLE state

The verification configuration is as follows. Both the Submitter host and Worker host are Windows Server 2022 EC2 instances. The structural difference from the CMF + UBL configuration is the absence of a License Endpoint and that 3ds Max 2024 is activated on the Worker EC2 with your own Autodesk account.

Install Deadline Cloud Monitor on the Submitter and sign in via Identity Center. The 3ds Max Submitter plugin uses AWS credentials obtained from Monitor sign-in to submit jobs. The Worker EC2 was configured as c5.4xlarge / EBS 200 GB to accommodate 3ds Max itself, Worker Agent, and Adaptor.

Verification Results

We prepared a minimal test scene with just a single teapot placed in 3ds Max and submitted a job from the Submitter plugin. The Default Scanline Renderer was used.

The job status transitioned from READY through STARTING and RUNNING to SUCCEEDED, with 1 task completing in 44 seconds. The output was retrieved from S3 as a 1280 x 720 PNG.

For this verification, we rendered an image of a teapot.

We confirmed on actual hardware that 3ds Max on the CMF Fleet referenced the bring-your-own license activation information and completed rendering without showing a sign-in dialog.

Insights from the Verification

Autodesk licenses are stored per user, so run the Worker service as the user who performed the activation

At the start of verification, we assumed it would work by activating 3ds Max as the Administrator on the Worker EC2 while running the DeadlineWorker service as the deadline-worker user created by install-deadline-worker by default. We thought license information would be shared within the same Windows host.

However, headless 3ds Max launched by the Adaptor exits with License Error: login requires GUI mode. Autodesk license information is stored separately per user under %LOCALAPPDATA%\Autodesk\AdskLicensingAgent, and the deadline-worker user has no activation token. In GUI mode, recovery is possible by showing a sign-in dialog, but headless execution via the Adaptor cannot display UI, so it fails outright.

The correct approach was to switch the DeadlineWorker service logon user to the user who activated 3ds Max (Administrator in this verification). At the same time, since Administrator does not have Log on as a service rights by default, you need to explicitly grant SeServiceLogonRight via secedit.

$pw = '<Administrator password>'
Stop-Service DeadlineWorker -Force
sc.exe config DeadlineWorker obj= '.\Administrator' password= $pw

$lines = @(
  '[Unicode]', 'Unicode=yes',
  '[Version]', 'signature="$CHICAGO$"', 'Revision=1',
  '[Privilege Rights]',
  'SeServiceLogonRight = Administrator,deadline-worker,*S-1-5-80-0'
)
$lines | Set-Content -Path C:\Windows\Temp\grant-svc.inf -Encoding Unicode
secedit /configure /db C:\Windows\Temp\grant-svc.sdb /cfg C:\Windows\Temp\grant-svc.inf /areas USER_RIGHTS
Start-Service DeadlineWorker

Since secedit /configure replaces rather than appends the target privilege assignment, the existing service user (deadline-worker) and system account SID (*S-1-5-80-0) must also be explicitly listed. Be careful: specifying only Administrator will revoke the startup rights for the existing Worker service, preventing it from starting.

Opt in run_jobs_as_agent_user = true in worker.toml. Never add a BOM

When a Render Queue is created in WORKER_AGENT_USER mode (a mode that runs jobs as the same user as the Worker Agent service), it works as-is on Linux Workers. On Windows Workers, however, jobs fail immediately after session start with the following error:

Job cannot run as WORKER_AGENT_USER. Worker Agent is running with Administrator privileges.

The error message reads as if it is checking for Administrator privileges, but in reality, Worker Agent's scheduler.py hard-codes the rejection of WORKER_AGENT_USER mode on Windows environments. This is a safety-side decision stemming from Windows user-isolation mechanisms not being equivalent to Linux, and overriding it requires explicitly opting in via the [os] section of worker.toml.

[os]
run_jobs_as_agent_user = true

A common pitfall here is encoding. Using Set-Content -Encoding UTF8 in the standard PowerShell 5.1 on Windows Server 2022 adds a UTF-8 BOM to the beginning of worker.toml. Python 3.11's standard tomllib does not accept BOM, so the DeadlineWorker service exits with SystemExit: 1 immediately after starting. Since no parse error is left in worker-agent.log either, this behavior makes root cause identification tedious.

When editing worker.toml, use [System.IO.File]::WriteAllText with UTF8Encoding($false) or PowerShell 7 or later's -Encoding UTF8NoBOM to reliably avoid BOM.

$path = 'C:\ProgramData\Amazon\Deadline\Config\worker.toml'
$content = Get-Content $path -Raw
$content = $content -replace '(?m)^# run_jobs_as_agent_user = true', 'run_jobs_as_agent_user = true'
[System.IO.File]::WriteAllText($path, $content, (New-Object System.Text.UTF8Encoding($false)))
Restart-Service DeadlineWorker -Force

Install the 3ds Max Adaptor in two Python locations. Also add PATH entries

The 3ds Max Adaptor (deadline-cloud-for-3ds-max) needs to be installed in both the Worker Agent's Python and 3ds Max's built-in Python. This stems from the Adaptor's architecture.

Worker Agent (Python 3.11 in this verification) launches the 3dsmax-openjd CLI to process jobs. The built-in Python in 3ds Max launched by 3dsmax-openjd (Python 3.10 in 3ds Max 2024) separately executes import deadline.max_adaptor. If installed in only one of the two, the job will fail with either '3dsmax-openjd' is not recognized or ModuleNotFoundError: No module named 'deadline'.

# Worker Agent Python 3.11
& "C:\Program Files\Python311\python.exe" -m pip install deadline-cloud-for-3ds-max

# 3ds Max 2024 built-in Python (bootstrap with ensurepip since pip is not bundled)
$maxPy = "C:\Program Files\Autodesk\3ds Max 2024\Python\python.exe"
& $maxPy -m ensurepip --upgrade
& $maxPy -m pip install deadline-cloud-for-3ds-max

Also add C:\Program Files\Python311\Scripts (location of 3dsmax-openjd.exe) and C:\Program Files\Autodesk\3ds Max 2024 (location of 3dsmax.exe) to the Machine PATH. Since 3dsmax-openjd internally launches 3dsmax.exe using a relative reference, the 3ds Max installation directory must also be in the PATH, otherwise it fails with Could not find the specified command: 3dsmax.

When upgrading to a new major version of 3ds Max, the built-in Python version will also change, so including this redeployment in your upgrade procedure is a safe practice.

Summary

We confirmed on actual hardware that rendering with 3ds Max 2024 works on AWS Deadline Cloud CMF with a bring-your-own license. Even in situations where UBL-supported versions cannot be used, we found that a practical configuration running 3ds Max on CMF is achievable by paying attention to the Worker service user design and the Adaptor deployment targets.

Since this verification used only a single frame with the Default Scanline Renderer, verifying additional renderers such as V-Ray, multi-frame rendering, and Fleet scaling behavior are the next steps.

Note that in this article's configuration, the Worker service runs as an Administrator-equivalent user, meaning jobs in production will inherit Worker host Administrator privileges. Decide on the Worker service user design in advance, in alignment with your organization's security requirements.

We hope this article serves as a useful reference when considering CMF and bring-your-own license configurations on AWS Deadline Cloud.