Rimo3 Pre-requisites & Architecture

Introduction

Deploying Rimo3 Resource into an Azure Subscription

Azure Subscription

1. An Azure Subscription with capacity for a minimum of 54 Cores

   • 1 x 2 cores for the Gateway
   • 13 x 4 cores for the Task Runners

   note

   • The MPO will deploy a B2s VM for the Gateway, this can be scaled up or down later if needed.
   • 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. The Subscription ID of the above Azure Subscription, so the marketplace offering (MPO) can be made available.

3. An identity, which will be used to complete the MPO, that has either:

   • Owner rights on an existing, empty resource group in the above Azure Subscription which will be used for the Rimo3 Cloud resources.
   • Owner rights on the above Azure Subscription, if a resource group will be created as part of the marketplace offering.
   • Network Contributor rights on an existing Vnet if a new Subnet needs to be created.

Azure Resource Group (Optional)

1. 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 precreated resources that relate to the Rimo3 service, such as the Vnet.

   warning

   The resource group should never host VM's 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.

Azure Vnet & Subnet (Optional)

1. 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 and SCCM server.

     note

     After deploying the Gateway the Gateway’s system assigned managed identity must be given Network Contributor access to the existing Vnet.

2. 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.
   • 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.

     note

     After deploying the Gateway the Gateway’s system assigned managed identity must be given Network Contributor access to the existing Vnet.

Rimo3 Tenant

1. A user account that is an Admin on the Rimo3 tenant.

Joining Rimo3 Resources to your domain.

Azure Vnet

1. 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.
2. 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

1. 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.)

2. 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)

1. 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 below.)

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.

SCCM

Service Account

1. 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 preferablt 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 application get imported from SCCM by assigning them to a security scope and only giving this account access to that security scope.

Auto-login Account

1. The auto-login account (see above) will need 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.

Network considerations

In the table below:

1. The Web host, video server and Quarantine area are all Rimo3 resources hosted and secured in the Rimo3 Azure subscription.

2. The Gateway, Task Runner and Storage account are Rimo3 resources deployed within the customer’s Azure subscription.

3. All other sources/destinations are resource 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
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
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	Any	Outbound	Quarantine area	Upload files to be security scanned
HTTPS	TCP	443	Gateway/Persistent Task Runner	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	ConfigMgr	Query ConfigMgr for packages to import, package details (name, version, location) transferred to Web Host via GW using agent communication channels
SMB	TCP	445	Task Runner	Outbound	ConfigMgr	Install apps from file share for testing
HTTPS	TCP	443	Task Runner	Outbound	Graph API	Export package information to Intune
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

1. 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

2. Source:blob.dsm06prdstr04a.store.core.windows.net IP Address: 52.239.235.100 Aliases:saquarantinearea004.blob.core.windows.net

3. 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.