This article outlines the resources and corresponding configuration to run Jiwa on the Azure platform.
The SQL Azure Database-as-a-service is used, and Remote Desktop services to deliver the Jiwa application as a remoteApp. The HTML5 client can also be configured on the RDS server to allow a web browser to be used.
Subscription
An Azure subscription needs to be created. Visit https://portal.azure.com/ and sign in with an existing Microsoft account, or create one.
Azure Active Directory
The Azure Active Directory is an identity service. This is where you create users. When you create an Azure subscription, the directory is created for you. You may already have your users in this directory if you already have an Office 365 subscription - as this uses the same directory for managing users.
Login to your Azure portal via https://portal.azure.com/ and search for Active Directory and add any users if you need to.
Azure Active Directory Domain Services (ADDS)
Before we can create a virtual machine, an Azure Active Directory Domain Service needs to be created. The Windows Server machine we later will be provisioning requires a Domain to connect to before Remote Desktop Services can be deployed, and the Azure Active Directory Domain Service is what we use to establish a Domain. On-prem Domains can be used instead via VPN gateway, but that is beyond the scope of this document.
You will need to add and verify ownership of a custom domain. To verify ownership you will need to create a TXT record in your public DNS. Follow the guidance in the portal when adding the custom domain.
A network security group and virtual network will be created and associated with the AADS - all virtual machines, SQL Servers and other resources should use the Virtual Network associated associated with the AADS.
Azure Virtual Machine
An Azure virtual machine is used to deliver the Jiwa application via Remote Desktop Services. This is a Windows machine running Windows Server 2019 or later.
About Machine Sizes
Typically, we use B4ms sized VM’s for up to 30 users. For more users either create additional VM’s and load balance, or just scale up to B8ms. If you only have 1 to 12 users, or it's a test machine, you might get away with a B2ms
"B" refers to the burst size. B machines are typically cheaper because Microsoft assume you're not using them 24x7.
"2" or "4" refers to the number of cores - 2 core is 8GB, 4 cores is 16GB.
Jiwa typically runs at 512 MB per user; allow 2GB for the operating system.
Create the VM
In the Azure portal, locate Virtual Machines and select Create
In the Basics tab, choose the Create new option the the Resource group and provide a name.
Also choose a virtual machine name and select an appropriate region. Choose a region closest to where the majority of users are geographically located.
The Image to select is Windows Server 2019 Datacenter edition.
When first provisioning we need port 3389 open on the firewall, so leave that selected - this will be removed for security reasons once we configure Remote Desktop to use HTTPS instead.
On the Networking tab, we and to select the Virtual network associated with the Azure Active Directory Domain Services.
The remaining options are optional - it is recommended to enable backups for the VM - but note that no data is stored on the VM, so if the VM becomes unusable all that is needed is to provision a new VM from scratch.
All data is stored with the SQL Azure database.
Continue to the Review + Create step and choose Create.
When completed, locate the VM in the list of virtual machines and select it.
Set DNS Name
On the Overview tab, select the Not configured link next to the DNS name
Enter in a DNS name and press Save
In your public DNS, add a CNAME record to point to the azure DNS record. For example, in the above example, I have a DNS in Azure for the VM of jiwards.australiaeast.cloudapp.azure.com. I want my users to use jiwards.jiwa.com.au to reach the machine, so I enter a DNS CNAME record in my DNS provider (Cloudflare in this example) which maps jiwards.jiwa.com.au to jiwards.australiaeast.cloudapp.azure.com, and without the need for the VM to have a static IP address:
We won't be able to connect using that DNS name just yet - the *.australiaeast.cloudapp.azure.com domain will need to be used until we create the necessary SSL certificates.
Connect to the machine
Back in the Overview tab for the VM, select the Connect → RDP option
Click Download RDP File
Open the RDP file - the publisher warning appears - choose Connect
Then enter the administrator credentials you provided when creating the VM :
Click Yes to the certificate warning:
Join the Domain
We need to now join the machine to the Azure Active Directory. In Control Panel, locate the System and Security > System panel and under the Computer name, domain and workgroup settings, click Change Settings
In the System Properties dialog which appears, press the Change... button
Select the Domain option and enter the custom domain configured in the Azure Active Directory Domain Services
You'll then be prompted to enter the credentials of an account with permissions to join the domain:
You will then receive a confirmation prompt:
You'll then be prompted to restart the machine. Follow the prompts and restart it.
Reconnect as a Domain user
RDP to the machine again, but this time don't use the local Administrator account - use an account from the Active Directory
Deploy Remote Desktop Session Host Role
In the Server Manager (this will open automatically) select the Add roles and features option
Click Next to the Before you Begin page of the wizard
Choose Remote Desktop Services Installation for the Installation Type page of the wizard
Choose Quick Start for the Deployment Type
Choose Session-based desktop deployment for the Deployment Scenario
Press Next on the Server Selection page
Check the "Restart the destination server automatically if required" checkbox and then press the Deploy button
Wait for the deployment to complete
The machine will automatically restart. Reconnect whenever it does. When you reconnect the View progress dialog will be shown - press Close when it finishes.
Configure Remote Desktop Services
From within the Server Manager Dashboard, select Remote Desktop Services
In the Deployment Overview, select the green plus icon for RD Gateway
Press the right arrow button to add the server in the Server Pool list to the Selected List
Click Next.
Enter the FQDN for the machine, and press Next
Press the Add button
The Gateway role service will then be deployed.
SSL Certificates and auto-renewal
Trusted certificates need to be generated and installed on the machine.
We recommend using the Let's Encrypt service and the win-acme client to generate and auto-renew certificates every 3 months.
Visit https://www.win-acme.com/ and download the version with plugin support. Follow the documentation on https://www.win-acme.com/ to configure certificates for an RDP server.
Install Jiwa
Download and install the Jiwa application from https://support.jiwa.com.au/
If there are any service releases, be sure to download and install the latest of those also (note: service releases must be installed from an elevated command prompt).
Publish the Jiwa application as a RemoteApp
From within the Server Manager Dashboard, publish the jiwa.exe application deployed to the C:\Program Files (x86)\Jiwa Financials\Jiwa folder
RDS CAL Licenses
Note that the RDS server requires CAL licences for each user – this is a once-off purchase, and you can obtain these from various on-line retailers. Once you have your licenses, configure the license manager of remote desktop services to use them.
SQL Azure
In the Azure portal, provision a new SQL Server - it is recommended to use the Virtual networks option to allow only access from the same virtual network both the AADS and VM are in.
For Azure SQL we use Standard tier – 50 DTU’s is usually the minimum, but we have a couple of customers using less.
If the customer has multiple databases (as often is the case – NZ operation, AU operation for instance) we’ll create an elastic pool of 100 DTU’s and have all the databases in there.
SQL Database
Database size depends entirely on the nature of the customers business – for a newly provisioned customer we start at 10GB. We have customers who have 90GB+ sized databases, but not many.
To use an RDS VM it must connect to either a domain controller or Azure Active Directory Domain Services
Jiwa Connections Template
Once you have your databases established, configure Jiwa on the RDS server with the desired connections. These connection definitions are stored per user in a JiwaConnections.XML file, but the Jiwa application will seek a template JiwaConnectionsTemplate.XML in the Jiwa program files folder if the user had not previously configured any connections.
Copy the JiwaConnections.XML from the %appdata%/Jiwa Financials folder to C:\Program Files (x86)\Jiwa Financials\Jiwa 7\JiwaConnectionsTemplate.XML to give users a pre-defined list of connections when they run Jiwa.
Remote Desktop Web Client
To allow your users to easily obtain their remote app rdp file from a browser, configure Remote Desktop Services accordingly.
Once logged in, the published applications can be clicked on to download the .rdp file
And when the rdp file is opened in the users local Windows environment, the application appears as a normal Windows application to the user
HTML 5 client
Remote Desktop Services can be configured to deliver a HTML5 web client of the published applications. This may be desired over the RemoteApp solution.
hosts file
In order for the RDS VM to be able resolve DNS requests to itself using the FQDN, an entry should be added to the hosts file.
Edit the C:\Windows\System32\drivers\etc\hosts file to point the FQDN to 127.0.0.1
This will allow you to, say open a web browser and navigate to https://jiwards.jiwa.com.au and it be able to reach the locally running IIS instance for the web client.
This is not an essential configuration, but is sometimes useful.
Where this may be essential is if you are running the API self hosted service on the VM, have configured for HTTPS and wish to use the custom domain FQDN.
Secure the Remote Desktop Server
When the VM for Remote Desktop Services was provisioned, port 3389 was open and used and we used the RDP protocol to connect to it to perform the installation and configuration tasks.
Now that the Remote Desktop Gateway is configured, we only need to leave port 443 open (HTTPS) and port 80 (HTTP). The RemoteApp, Webclient and HTML5 client all require port 443 (HTTPS), and we also need port 80 open for the regular 3 monthly certificate renewal automatically performed by the win-acme client.
App Registration for Email through Office 365 (Microsoft Graph API)
Emailing from within Jiwa is a common requirement, and if the customer has Office 365 then you should use our Microsoft Graph API plugin for email transport - and this requires an App registration in the Azure Active Directory.
See the article Email - Configuration Microsoft Graph REST API for guidance on how to set this up.
Point to Site VPN
If users wish to access resources - such as the SQL database or RDS VM - from their local environment (perhaps for Excel queries or BI tooling), you will need to configure a point to site VPN connection in Azure, as resources should only be accessible from within the same Virtual Network.
Exposing the resources outside the virtual network via whitelisting of IP addresses in the Firewall rules is not recommended.
Backups and Data Security
Virtual Machine
The Azure Backup service can be used to automatically backup virtual machines if desired. The Jiwa application stores only ephemeral data on the VM, so if the VM is destroyed no data is lost - the database contains all the data.
However, it can save time to be able to restore a VM to a previous known working state if it is destroyed - see the official Microsoft documentation on how to configure virtual machine backups if desired.
Also, availability sets can be configured to provide a redundant failover if the VM is destroyed. See the Azure documentation on Availability options for Azure Virtual Machines.
Database
Azure SQL servers never need to be backed up, as this is already done for you. You may wish, however to opt-in to geo-redundant storage to replicate a copy of the database(s) to other Azure datacenter(s) in case of natural disaster or other catastrophe.
By default, the Azure SQL servers are replicated in real-time to 3 different failover nodes in different fault zones in the datacenter, and should one of those machines, or one of the components, fail - then the requests are automatically redirected to one of the failover machines and a new machine provisioned automatically to replace the failed machine. If you choose geo-redundant storage, then the same applies to the datacenters replicated to.
You may wish to extend the data retention period for the point-in-time backups beyond the standard 7 to 35 days. Up to 10 years of data retention of point-in-time restore is available.
You can also manually export the database to a storage blob or even local file system if desired.
MS Azure Calculator
If you haven’t already, you can use the Azure pricing calculator to see the pricing options - https://azure.microsoft.com/en-au/pricing/calculator
Of particular interest might be the discounts offered for paying up-front for VM’s for 1 or 3 years (41% discount for 1 year, 62% discount for 3 years).
Related articles