I set up a load balancer in one of my test environments to better understand how load balancers work and to document any interesting issues that might come up when using one with Recast Management Server and Recast Agent.
Here’s what I found. I hope this helps anyone setting up a similar configuration. In my environment, I used a free load balancer called LoadMaster, but these notes should also apply to other options.
Key things I learned (in no order)
- WebSockets must be enabled: For Recast Agent to work correctly, WebSockets must be allowed through your load balancer. In the Recast Agent logs, you will typically see the connection succeed until the WebSocket request is made. At that point, the connection may drop, and the agent will not appear in RMS. Once WebSockets are enabled, the connection should complete successfully, and your agents should be able to communicate through the load balancer.
- Sessions need to be persistent (sticky): When configuring your connections, make sure your load balancer is set to keep sessions persistent, or “sticky.” If the load balancer tries to reuse or drop the connection, the agent may disconnect and devices may appear offline even though they’re online and the agent believes they’re connected. In my environment, I set the persistence mode to Active Cookie with a timeout of one day. This allows the load balancer to keep the client connected to the same real server for up to 24 hours.
- Certificate concerns: At a previous job, my colleagues and I used to joke that if something was broken in the environment, it was probably one of two things, and one of them was certificates. Certificates play an important role in a load-balanced setup.
- Certificate authority (CA): Here is a major tip: Having a certificate authority in your environment makes certificate configuration much easier. Seriously, avoid doing this with self-signed certificates if you can. With a CA, you usually don’t need to worry about manually copying self-signed certificates into the Trusted Root store on your endpoints. As long as the computer with Recast Agent installed trusts the CA root certificate, the certificates issued by that CA should also be trusted.
- Device names: You need to pay close attention to device names and the DNS name used for your load balancer address. Even if the certificate itself is trusted, Recast Agent still checks that it’s connecting to the correct server name. If the name doesn’t match, the connection will fail.
- Which names matter most: In an on-premises environment, there are two important connections to consider when creating certificates. The first is the connection from the agent to the Agent Gateway, and that certificate will be installed in IIS on the Agent Gateway server. The second is the connection from the agent to Recast Management Server for enrollment, and that certificate will be installed in IIS on the RMS server. Both connections need a valid certificate to work correctly. You may also need or want to add a certificate to the load balancer itself, depending on its configuration.
- DNS: Here’s the other issue we used to blame at my previous organization. After all, if there is a problem, it’s always DNS, right?
- Load balancer interface: DNS needs to be configured for the load balancer interface so you can point the agent to a single address while the load balancer routes traffic as needed.
- DNS record for the address: In my test environment, I created a DNS host (A) record named LoadBalancedAG that pointed to the IP address of my load balancer. This makes it easier to add or remove Agent Gateways because the changes can be handled behind the load balancer without requiring DNS updates.
Put certificates and DNS together
- Subject Alternative Name and DNS name: When you create the certificate for the load balancer interface, the certificate must include the name you chose, such as LoadBalancedAG.yourenvironment.com as the SAN and DNS name, for the certificate to be valid.
- Separate Agent Gateway from RMS: This is something we have seen in customer environments. It can be tempting to use the Agent Gateway installed on the Recast Management Server as one of the Agent Gateways in your load-balanced setup. However, this can cause issues if the load balancer sends requests to the wrong interface, resulting in refused connections. The simplest approach is to keep RMS out of the load-balanced Agent Gateway setup.
Where to look for errors
If you’re having trouble getting agents to connect to the Agent Gateway and then to Recast Management Server, there are three main Recast log locations to check, plus your load balancer logs.
- Recast Agent logs located at c:\ProgramData\Recast Software\Logs: These logs show what the Recast Agent is experiencing when it tries to connect to the Recast Agent Gateway and Recast Management Server.
- Recast Agent Gateway logs located at c:\ProgramData\Recast Software\Logs on the Recast Agent Gateway server: This is a good place to confirm that the agent can connect to the Agent Gateway behind the load balancer and to identify any errors.
- Recast Management Server logs located at c:\ProgramData\Recast Software\Logs on the Recast Management Server: These logs may show what RMS sees when an agent attempts to connect.
- Load balancer logs: If your load balancer has logging available, it may help you see which connections are being created or attempted through its interfaces.
Let us know if you have questions
If you run into issues, you can always reach out to our support team, and we can walk through the recommended configuration with you.
Related posts
How to Configure the Recast Agent Gateway with Microsoft Windows Server Network Load Balancing
How to Set Up a Load Balancer using Microsoft Windows Server NLB
