This article is designed to provide you with a clear understanding of the tests conducted by the Rimo3 Requirements Checker, the significance of the items they evaluate, and the appropriate steps to take when a rule does not pass.
Jump to a specific rule
- Rule: Check connectivity to the Rimo3 Web Host
- Rule: Ensure the video streaming server is accessible
- Rule: Check connectivity to the video streaming API
- Rule: Ensure that system assigned identity is enabled
- Rule: Ensure the Gateway VM has the Owner role on the Rimo3 Resource Group
- Rule: Ensure the Gateway VM has the Network Contributor role on the Gateway VM's Vnet
- Rule: Check port 5000 Inbound is Allowed on the Network Security Group (NSG)
- Rule: Check port 5001 Inbound is Allowed on the Network Security Group (NSG)
- Rule: Ensure the Gateway is accessible on port 5000
- Rule: Ensure the Gateway is accessible on port 5001
- Rule: Check that the Gateway's subnet has enough unused IP Addresses
- Rule: Ensure a storage account was created
- Rule: Ensure a key vault was created
- Rule: Check that the auto login user is an administrator
- Rule: Check if any local firewall profiles are enabled
- Rule: Ensure an Inbound firewall rule for port 5000 exists (if firewall is enabled)
- Rule: Ensure an Inbound firewall rule for port 5001 exists (if firewall is enabled)
- Rule: Ensure that a legal notice is not configured
- Rule: Ensure that a screen saver is not enabled
- Rule: Ensure that the automatic lock screen is not enabled
Rule: Check connectivity to the Rimo3 Web Host
The Gateway communicates securely with the Web Host (rimo3cloud.com) over HTTPS on Port 443 therefore access to this URL and Port should not be blocked by endpoint security products, or network appliances/resources such as Network Security Groups, Firewalls or Proxy Servers.
Blocker: This rule is essential for Rimo3 to function. If it fails, the issue must be resolved before deployment can continue. After making any changes, click “Run Checks” in the Deployment Wizard to validate the updated configuration.
What to do if this rule is failing?
- Check perimeter security appliances such as firewalls and proxy servers for any blocked traffic to https://rimo3cloud.com on port 443.
- If your organization employs SSL Inspection ensure that the required certificate is installed on the Gateway.
Rule: Ensure the video streaming server is accessible
Video is securely streamed to the Video Server (wowzastag.rimo3activ.com) over RTMPS on Port 443 therefore access to this URL and Port should not be blocked by endpoint security products, or network appliances/resources such as Network Security Groups, Firewalls or Proxy Servers.
What to do if this rule is failing?
- Check perimeter security appliances such as firewalls and proxy servers for any blocked traffic to https://wowzastag.rimo3activ.com on port 443.
- If your organization employs SSL Inspection ensure that the required certificate is installed on the Gateway.
Rule: Check connectivity to the video streaming API
The Video Server API endpoints (e.g. start recording, stop recording) are accessed via wowzastag.rimo3activ.com over HTTP on Port 8087 therefore access to this URL and Port should not be blocked by endpoint security products, or network appliances/resources such as Network Security Groups, Firewalls or Proxy Servers.
What to do if this rule is failing?
- Check perimeter security appliances such as firewalls and proxy servers for any blocked traffic to http://wowzastag.rimo3activ.com on port 8087.
- From the Gateway VM browse to http://wowzastag.rimo3activ.com:8087, if you have access to the URL and port you should be prompted to login:
Click cancel and you should see the following:
<error>
If not then access to either the URL or the Port is being blocked.
<wowzaServer>4.7.7</wowzaServer>
<code>401</code>
<message>The request requires user authentication</message>
</error>
Rule: Ensure that system assigned identity is enabled
A system assigned identity is used to grant the GW VM rights to perform actions in the Rimo3 resource group. If the system assigned identity fails to get enabled it can be manually enabled in the Azure Portal.
Blocker: This rule is essential for Rimo3 to function. If it fails, the issue must be resolved before deployment can continue. After making any changes, click “Run Checks” in the Deployment Wizard to validate the updated configuration.
What to do if this rule is failing?
- Check the Gateway VM in Azure and ensure the system assigned identity under Security → Identity is set to On. For details steps click here.
Rule: Ensure the Gateway VM has the Owner role on the Rimo3 Resource Group
The Gateway's system assigned identity needs to be Owner of the Rimo3 Resource Group (<ResourceGroupName>) so that it can create and remove Task Runner VM's, as well as access the Key Vault and Storage Account. If the Owner role is not set, the Gateway system assigned identity can be manually granted Owner rights on the Rimo3 Resource Group (<ResourceGroupName>) in the Azure Portal.
Blocker: This rule is essential for Rimo3 to function. If it fails, the issue must be resolved before deployment can continue. After making any changes, click “Run Checks” in the Deployment Wizard to validate the updated configuration.
What to do if this rule is failing?
- Ensure that the Gateway's system assigned identity has been successfully created. If the system assigned identity has not been created then the required roles cannot be assigned to it.
- Manually assign the Gateway system assigned identity the Owner role on the Rimo3 resource group. For details steps click here.
Rule: Ensure the Gateway VM has the Network Contributor role on the Gateway VM's Vnet
The Gateway's system assigned identity needs Network Contributor rights on the Vnet to which Task Runner VM's will be connected so that the Task Runner VM's networking can be correctly configured. If the Network Contributor role is not set, the Gateway system assigned identity can be manually granted Network Contributor rights on the Vnet (<VnetName>) in the Azure Portal.
Blocker: This rule is essential for Rimo3 to function. If it fails, the issue must be resolved before deployment can continue. After making any changes, click “Run Checks” in the Deployment Wizard to validate the updated configuration.
What to do if this rule is failing?
- Ensure that the Gateway's system assigned identity has been successfully created. If the system assigned identity has not been created then the required roles cannot be assigned to it.
- Manually assign the Gateway system assigned identity the Network Contributor role on the virtual network (Vnet) to which the Gateway is connected. For details steps click here.
Rule: Check port 5000 Inbound is Allowed on the Network Security Group (NSG)
Task Runners communicate with the Gateway on port 5000 therefore if a Network Security Group (NSG) is present port 5000 Inbound should be Allowed. If no NSG is present this rule will pass. If this rule is failing the deployment can continue but the issue must be resolved before Task Runners can be successfully provisioned.
NOTE: A network security group is not required and this rule will Pass if there is no network security group (NSG) associated with the Gateways network card.
What to do if this rule is failing?
- If a network security group is associated with the Gateway's network card you will need to allow port 5000 Inbound on the NSG. For detailed steps click here.
Rule: Check port 5001 Inbound is Allowed on the Network Security Group (NSG)
Centralized logging information is passed from the Task Runner to the Gateway over port 5001 therefore if a Network Security Group is present port 5001 Inbound should be Allowed. If no NSG is present this rule will pass. If this rule is failing deployment can continue but the issue must be resolved before Task Runners can be successfully provisioned.
NOTE: A network security group is not required and this rule will Pass if there is no network security group (NSG) associated with the Gateways network card.
What to do if this rule is failing?
- If a network security group is associated with the Gateway's network card you will need to allow port 5001 Inbound on the NSG. For detailed steps click here.
Rule: Ensure the Gateway is accessible on port 5000
Task Runners communicate with the Gateway on port 5000 therefore access to the Gateway on this port should not be blocked by any local firewalls, endpoint protection products, network appliances or other security resources. If this rule is failing deployment can continue but the issue must be resolved before Task Runners can be successfully provisioned.
What to do if this rule is failing?
- Check if a local firewall is enabled on the Gateway VM and if one is ensure that rules exist to allow port 5000 inbound.
- Check if the Gateway's network card is associated with a network security group and if it is ensure that port 5000 inbound is allowed.
Rule: Ensure the Gateway is accessible on port 5001
Centralized logging information is sent from Task Runners to the Gateway on port 5001 therefore access to the Gateway on this port should not be blocked by any local firewalls, endpoint protection products, network appliances or other security resources. If this rule is failing deployment can continue but the issue must be resolved before Task Runners can be successfully provisioned.
What to do if this rule is failing?
- Check if a local firewall is enabled on the Gateway VM and if one is ensure that rules exist to allow port 5001 inbound.
- Check if the Gateway's network card is associated with a network security group and if it is ensure that port 5001 inbound is allowed.
Rule: Check that the Gateway's subnet has enough unused IP Addresses
Task Runners are provisioned and deprovisioned on demand and by default will consume 13 IP Addresses during times of high activity when all Task Runners are provisioned concurrently. If enough used IP addresses are not available this can result in Task Runner provisioning steps failing. If sufficient IP addresses are not available on the subnet the Gateway should be moved, or redeployed, to a different subnet with enough unused IP Addresses.
What to do if this rule is failing?
- In the Azure Portal browse to the Vnet used by the Gateway and select Subnets under Settings on the left hand menu. Check the Available IPs for the subnet to which the Gateway is attached:
If there are fewer than 13 IP addresses available you will want to consider moving the Gateway to a subnet with at least 13 available IP address, or even moving the Gateway to it's own dedicated subnet.
Rule: Ensure a storage account was created
A storage account is required to save uploaded package source files, Modernized applications created within the Rimo3 platform, store log files and cache downloadable package files. If a storage account could not be created by the MPO you many need to pre-create a storage account and rerun the MPO selecting the existing storage account
What to do if this rule is failing?
- Check if there are any policies in Azure that are preventing the storage account from being created. If so you may need the policy(ies) to be temporarily blocked for the Rimo3 resource group to allow the deployment to proceed, in most cases you can reconfigure the storage account once deployed to meet the requirements of the policy(ies). For detailed steps on how to restart a deployment click here.
Rule: Ensure a key vault was created
A key vault is required to securely store properties and credentials used by the Rimo3 service. If a key vault could not be created by the MPO then a key vault can be manually created in the Rimo3 resource group, ensuring the Gateway system assigned identity has full rights to secrets. Restart the Gateway to discover the key vault.
What to do if this rule is failing?
- xxx
Rule: Check that the auto login user is an administrator
The Rimo3 service leverages the auto login capability of Windows to automate various activities, including the automated install and uninstall of applications which requires administrative rights. The auto login user therefore needs to be granted local admin rights on devices created by the service to ensure it can carry out the necessary automated activities.
What to do if this rule is failing?
- The provisioning process automatically puts the auto-login user in the local admins group. In a domain join scenario policies can be configured to remove unknown users from the local admin group, if this is the case the policy in question should be blocked for the Rimo OU.
Rule: Check if any local firewall profiles are enabled
If any local firewall profiles are enabled then appropriate rules will need to be in place to allow communication between the Gateway and Task Runners. If any firewall profiles are enabled then additional checks will be performed to ensure that rules exist to allow communication on the required ports. If no firewall profiles are enabled this rule will return a warning and the additional port checks will be skipped.
What to do if this rule is failing?
- If a local firewall is detected then you don't need to take any specific action, you will however need to review the following rules to see if they are passing and ensure that the local firewall is not blocking inbound traffic on port 5000 or 5001
- Ensure an Inbound firewall rule for port 5000 exists (if firewall is enabled)
- Ensure an Inbound firewall rule for port 5001 exists (if firewall is enabled)
Rule: Ensure an Inbound firewall rule for port 5000 exists (if firewall is enabled)
Task Runners communicate with the Gateway on port 5000 therefore if a firewall is enabled a rule should be present to allow inbound traffic on port 5000.
What to do if this rule is failing?
- Add a local firewall rule to allow inbound TCP traffic to the Gateway virtual machine on port 5000. If needed you can limit the source to the subnet on which the Gateway virtual machine is located, because that is where the Task Runners will also be located, but be aware that the Domain Join wizard is accessed via port 5000 on the Gateway too. Limiting access may prevent the Domain Join Wizard from being access from another subnet.
Rule: Ensure an Inbound firewall rule for port 5001 exists (if firewall is enabled)
Centralized logging information is passed from the Task Runner to the Gateway over port 5001 therefore if a firewall is enabled a rule should be present to allow inbound traffic on port 5001.
What to do if this rule is failing?
- Add a local firewall rule to allow inbound TCP traffic to the Gateway virtual machine on port 5001. If needed you can limit the source to the subnet on which the Gateway virtual machine is located, because that is where the Task Runners will also be located. No other Rimo3 services use port 5001 to communicate with the Gateway.
Rule: Ensure that a legal notice is not configured
The Rimo3 service leverages the auto login capability of Windows to automate various activities, a legal notice will prevent auto login from completing successfully and therefore interrupt various automated activities. Any legal notice for interactive or RDP Login should be disabled to prevent service interruption.
What to do if this rule is failing?
- Check if the following registry keys are set on the Gateway:
- HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\LegalNoticeCaption
- HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\LegalNoticeText
- Check if the following registry keys are set on the Gateway:
- HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp\LogonMessageTitle
- HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp\LogonMessage
- The above registry keys can be set by Group policy or be part of a custom image, if you delete the values or the keys themselves but they keep coming back you will need to determine what is enforcing the configuration and block the configuration for the Rimo3 resources, both the Gateway and Task Runners.
Rule: Ensure that a screen saver is not enabled
A screen saver could potentially interrupt the video capture of smoke tests preventing useful information from being captured in screenshots and the video recording. It is recommended that any screensavers be disabled on the devices used by the Rimo3 service.
What to do if this rule is failing?
- Connect to the Gateway and check if a screensaver is configured, disable the screensaver if it is enabled.
- If the screensaver cannot be disabled it may be enforce via Group Policy in which case the policy in question will need to be blocked for the Rimo3 OU where the Gateway and Task Runner accounts are located.
Rule: Ensure that the automatic lock screen is not enabled
The lock screen could potentially interrupt the video capture of smoke tests preventing useful information from being captured in screenshots and the video recording. It is recommended that the automatic lock screen be disabled on the devices used by the Rimo3 service.
What to do if this rule is failing?
- Connect to the Gateway and check the screensaver configuration and check is "On resume, display log-on screen" is selected, unselected the option if necessary.
- Connect to the Gateway and check "If you've been away, when should Windows require you to sign in again?" under Settings → Accounts → Sign-in options: Additional settings, change it to Never if necessary
- If the above are configured but can't be edited they may be enforce via Group Policy in which case the policy in question will need to be blocked for the Rimo3 OU where the Gateway and Task Runner accounts are located.
- Check if the following registry keys are present and configured and delete them is present:
- KEY_CURRENT_USER\Control Panel\Desktop\ScreenSaverIsSecure=1
- HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\InactivityTimeoutSecs
- Ff you delete the above registry keys but they keep coming back you will need to determine what is enforcing the configuration and block the configuration for the Rimo3 resources, both the Gateway and Task Runners.