The purpose of this document is to provide a clear set of prerequisites which must be implemented by the Customer prior to the Rimo3 environment setup.
Deploying Rimo3 Resources into your Azure Subscription
Azure Subscription Requirements
There are 3 key requirements for the Azure subscription that will be used to host the Rimo3 resources.
1. An Azure Subscription with capacity for a minimum of 54 Cores:- 1 x 2 cores for the Gateway Virtual Machine (VM)
- 13 x 4 cores for the Task Runner VMs
You can find out how to check available cores here: https://learn.microsoft.com/en-us/azure/quotas/quickstart-increase-quota-portal
ℹ️ NOTE
- The Market Place Offering (MPO) will deploy a B2s VM for the Gateway, this can be scaled up or down later if needed. Please see the Rimo3 Deployment guide for more details: https://learn.rimo3.com/knowledge-base/rimo3-workspace360-deployment-guide
- Task Runners will be built as B4ms VM’s
- More cores will be needed if the Gateway is scaled up, or more Task Runners are added in the future.
2. Rimo3 requires the subscription ID of the above Azure Subscription, so the MPO can be made available.
3. An identity which will be used to complete the MPO deployment, that has either:
- Owner rights on an existing, empty resource group in the Azure Subscription which will be used for the Rimo3 Cloud resources.
- Owner rights on the Azure Subscription, if a new resource group will be created as part of the marketplace offering.
- Network Contributor rights on an existing Virtual Network (Vnet) to attach the Gateway VM to a new or existing Subnet.
Using an existing Azure Resource Group (Optional)
An existing, empty resource group in the above Azure Subscription which will be used for the Rimo3 Cloud resources.
❕INFO
The resource group can contain previously created resources that relate to the Rimo3 service, such as the Vnet.
🔥WARNING
The resource group should never host resources that are not related to the Rimo3 service, i.e. that are not the Gateway or a Task Runner. The Gateway includes a service that removes orphaned Task Runners which could result in VM's unrelated to the Rimo3 service being automatically deleted.
Using an existing Azure Vnet & Subnet (Optional)
1. If using an existing Vnet and Subnet:
- The Subnet should have at least 14 IP addresses available, preferably more to allow additional Task Runners to be added in the future if needed.
- The Vnet should have access to any additional resources required for testing, such as the Domain Controller (DC) and System Center Configuration Manager (SCCM) server.
ℹ️ NOTE
After deploying the Gateway, the Gateway’s system assigned managed identity will need to be given Network Contributor access to the existing Vnet.
2. If using an existing Vnet
- A new Subnet will be created in the existing Vnet and should be configured to have at least 14 IP addresses available; more are recommended to allow additional Task Runners to be added in the future if needed.
- At least Network Contributor rights on an existing Vnet if a new Subnet needs to be created.
- The Vnet should have access to any additional resources required for testing, such as the domain and SCCM server.
Rimo3 Tenant
- A user account, provided by the Rimo3 Customer Solutions team, that is an Admin on the Rimo3 tenant.
Network Requirements
In the table below:
- The Web host, video server and Quarantine area are all Rimo3 resources hosted and secured in the Rimo3 Azure subscription.
- The Gateway, Task Runner and Storage account are Rimo3 resources deployed within the customer’s Azure subscription.
- All other sources/destinations are resources hosted within the customer Azure subscription or on-premises network at their discretion.
Protocol | Type | Port | Origin | Initiating Direction | Destination | Purpose / Data transferred |
---|---|---|---|---|---|---|
HTTPS | TCP | 443 | Gateway | Outbound | Web host | Agent communication Starting Sequences Returning results, pass/fail status, error codes, shortcut information, screenshots |
HTTPS | TCP | 443 | Web host | Inbound | Storage Account |
Validate connection string Check available space |
HTTP | TCP | 5000 | Gateway | Outbound | Task Runner | Internal Agent communication Starting Sequences |
HTTP | TCP | 5000 | Task Runner | Outbound | Gateway | Internal Agent communication Returning results, pass/fail status, error codes, shortcut information, screenshots |
HTTP | TCP | 5001 | Task Runner | Outbound | Gateway | Centralised logging |
RTMPS | TCP | 443 | Task Runner | Outbound | Gateway | Video Streaming |
RTMPS | TCP | 443 | Gateway | Outbound | Video Server | Video Streaming (port forwarding) |
HTTP | TCP | 8087 | Gateway | Outbound | Video Server | Video API, start/stop recording controls |
HTTPS | TCP | 443 | Subnet | Outbound | catalogartifact.azureedge.net |
Download Gateway install script from Microsoft CDN Allow for subnet as Gateway IP not known prior to deployment. |
HTTPS | TCP | 443 | Any | Outbound | Quarantine area | Upload files to be security scanned |
HTTPS | TCP | 443 |
Gateway/ |
Outbound | Quarantine area | Download packages from quarantine area to Task Runner for security scan |
HTTPS | TCP | 443 | Gateway/ Persistent Task Runner |
Outbound | Internal shared location | Download packages from Internal Azure Blob storage or OneDrive to Task Runner for security scan |
HTTPS | TCP | 443 | Gateway/ Persistent Task Runner |
Outbound | External shared location | Download packages from external shared location (e.g. Google Drive) to Task Runner for security scan |
SMB | TCP | 445 | Task Runner | Outbound | Storage account | Transfer scanned packages to Azure File Share Install apps from Azure file share for testing Transfer modernized apps to Azure File share |
SMB | TCP | 445 | Gateway/ Persistent Task Runner |
Outbound | Storage account | Transfer scanned packages to Azure File Share |
HTTPS | TCP | 443 | Task Runner | Outbound | Storage Account | Transfer modernized apps to BLOB storage (for download) |
RPC | TCP | 135 | Task Runner | Outbound | SCCM | Query SCCM for packages to import, package details (name, version, location) transferred to Web Host via GW using agent communication channels |
RPC | TCP | 49152 – 65535 |
Task Runner | Outbound | SCCM | Ephemeral ports |
SMB | TCP | 445 | Task Runner | Outbound | SCCM | Install apps from file share for testing |
HTTPS | TCP | 443 | Task Runner | Outbound | graph.microsoft.com | Access to Microsoft Graph API |
HTTPS | TCP | 443 | Task Runner | Outbound | Azure Blob Storage | Upload package for export to Intune |
HTTPS | TCP | 443 | Task Runner | Outbound | Azure Blob Storage | Upload package for export to Nerdio |
HTTPS | TCP | 443 | Task Runner | Outbound | Nerdio API | Execute Nerdio API |
HTTPS | TCP | 443 | Any | Outbound | Storage Account | Download apps from Azure Blob Storage |
-
IP Addresses used:
- Outbound (target): 40.78.134.235
- Inbound (source): 40.77.26.73, 52.165.17.161, 52.165.17.221, 52.165.177.82, 40.77.27.24, 40.77.26.223, 52.173.39.6, 4.249.138.63, 4.249.138.66, 4.249.138.69, 4.249.138.71, 4.249.138.74, 4.249.138.78, 4.249.138.81, 4.249.138.84, 4.249.138.87, 4.249.138.90, 4.249.138.93, 4.249.138.96, 13.89.172.0
-
Source: blob.dsm06prdstr04a.store.core.windows.net
IP Address: 52.239.235.100
Aliases: saquarantinearea004.blob.core.windows.net -
When accessing the Storage account from selected virtual networks and IP Addresses access should be granted to the internal IP Address range(s) to allow packages to be downloaded.
Joining Rimo3 Resources to your Domain
Azure Vnet
- Ensure the Vnet hosting the Rimo3 Gateway and Task Runners has access to the domain, this could be via Vnet peering, a site-to-site VPN or ExpressRoute.
- Ensure a DNS server is configured on the Vnet used by the Rimo3 resources so that the domain can be resolved by the Gateway and Task Runners.
Domain Accounts
Domain join Service Account - this account will be used to join the Gateway to the domain, as well as Task Runners, when they are provisioned.
- Existing service account
- An existing service account used for the purpose of joining resources to the domain can be used.
- The existing account should have permission to join resources to the OU where the Rimo3 Gateway and Task Runners will be located (see further below.)
- New service account
- If creating a new service account the account does not need interactive login rights.
- The new account should have permission to join resources to the OU when the Rimo3 Gateway and Task Runners will be located (see further below.)
Auto-login Account – this account will be used to login to the Gateway and Task Runner VM’s.
- This account needs interactive login rights.
Organizational Unit (Optional)
An OU where the Gateway and Task Runner computer accounts will be located in Active Directory.
- The Task Runner computer accounts will always be created here, but the Gateway can be moved to a different OU if necessary, after joining the domain.
- Consider using a dedicated OU for the Rimo3 Gateway and Task Runner computer accounts in case certain GPO’s need to be blocked to ensure proper operation (see Group Policies)
Group Policies
1. A Legal Notice displayed at login will prevent autologin and should be disabled for both the Gateway and Task Runners.
Computer Configuration\Policies\Windows Settings >Security Settings\Local Policies\Security Options\Interactive Logon: Message text for users attempting to log on
Computer Configuration\Policies\Windows Settings >Security Settings\Local Policies\Security Options\Interactive Logon: Message title for users attempting to log on
2. Screensavers with short timeout periods may be displayed during long running tests which will impact video and screen capture. If this is found/likely to be the case screensavers should be disabled for Task Runners.
User Configuration\Administrative Templates\Control Panel\Personalization\Screen saver timeout
3. If the desktop locks after a short period of inactivity video and screen capture periods may be displayed during long running tests.
Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\Security Options\Interactive logon: Machine inactivity limit
4. Consider disabling Power & Sleep policies that turn off the screen or put devices into sleep/hibernate mode for Task Runners as this could impact long running tests and persistent Task Runners.
You can check what policies are applied to a device by running the following from an elevated command prompt:
GPRESULT /H filename.html
SCCM
Service Account
An active Directory account that has been granted the Read-only Analyst role in SCCM. This account is used to query SCCM when importing packages and applications.
- If an account is being created specifically for this purpose it does not need interactive login rights.
- If it is preferable to not create an account specifically for this purpose, then the auto-login account can be granted the Read-only Analyst role in SCCM instead.
ℹ️ NOTE
You can control which packages and applications get imported from SCCM by assigning them to a security scope and only giving this account access to that security scope.
Auto-login Account
The auto-login account (see above) requires the following permissions:
- Read permission to any file shares where SCCM packages are hosted.
- Read NTFS permissions to all files and folders under the file shares where SCCM packages are hosted.
Something missing from this page or want to give feedback?