AWS Portal license issue


Hello guys,

we are currently exploring the Deadline10 AWS Portal Setup.

After I create infrastructure, I am able to start a Spot fleet. Unfortunately after the slaves spawn they are unable to obtain a deadline license.


All I can see in the slave log is this:

[attachment=0]slave log.JPG[/attachment]

We want to use our on premise license server. This is the configuration in the AWS portal settings:


Any help is much appreciated!




Actually, I think you may have hit a bug. I’m not sure what causes it yet, but try setting this up in the Automatic Configuration window: (all enabled options here are required)

[attachment=0]2018-04-16 12_28_14-Configure Repository Options.png[/attachment]

The problem seems to be that the deadline.ini file loses track that it should use the Gateway instance to forward its license traffic. The second option to disable automatic upgrades is just a safeguard. I enabled the license re-write yesterday and it allowed an automatic upgrade to happen, so better be safe than sorry there (takes awhile to pull the upgrade files over the Portal Link.


There is another angle here as well. If using the instances on AWS, there is an option to choose dynamic licensing that you’ll need to enable:

[attachment=0]2018-04-16 12_49_42-Deadline Monitor - C__DeadlineRepository10.png[/attachment]

I would only use this after 10.0 SP13 however as there was a socket leak that was corrected recently.


Hello Edwin,

thanks for your quick answer! I’ve tried to implement the solutions you’ve described but unfortunately no luck yet.

Some screenshots:



Also there is something which might be out of the ordinary. When I start the remote connection server I get the following message which keeps repeating:

Deadline Remote Connection Server 10.0 [v10.0.13.6 Release (60bd5de8a)]
Connected to “\cache\Deadline10RepoTest”
Listening for TLS connections on…
Legacy bypass backend started. Listening on port 51685.
Listening for HTTP requests on port 8080…
[] GET [Forbidden]
[] GET [Forbidden]
[] GET [Forbidden]
[] GET [Forbidden]
[] GET [Forbidden]
[] GET [Forbidden]
[] GET [Forbidden]
[] GET [Forbidden]
[] GET [Forbidden]

best regards,


Ah, okay. The problem might be here that you’re using dynamic licensing without dynamic licenses. Turn off all of that and the Slaves should try and use the licenses that are being forwarded through Portal Link.

Also, change your “license server” to be as that’s the private IP of the Gateway machine that’ll forward your requests over Portal Link.

The forbidden messages are actually normal, and I’ve opened an issue here to see if we can silence it.

Something to be mindful of here that can catch people off guard (and is unrelated to what we’re working on here) is that the infrastructure costs money to have running. If you’re not already, I would stop the infrastructure between tests. The settings we’re applying here will persist across infrastructures. This page on the AWS side is great for seeing where the dollars and cents are going:


I suspect the issue here is that in the auto configuration you are setting The syntax needs to be 27008@ 27008 is the default port of the license server, if you manually specified otherwise you would need to change that value to what you set.



the problem is that when I use 27008@ instead of just the slaves won’t appear on the deadline monitor anymore.




Hi guys,

today I did a fresh installation of the remote server and the AWSPortalLink. I’ve used the 27008@ as a license gateway and it seems to be working this time! The license server indicates that the slaves are obtaining licenses. However, when I spawn two slaves with the premade 3ds Max + V-ray image provided by Deadline I m unable to render.

Going to attach a slave log file for you to review.

Thanks a lot for your assistance!




Hello guys,

this issue was resolved. Apparently 3ds Max needed Usage Based Licensing in order to rend.

Thanks a lot for your help!




Ah! Yes, that’ll do it. I’m somewhat surprised that the Slaves went into license-free mode though…

Is there something we can do to make that error more obvious in the future?