This guide will show how to setup an Azure SQL Server & Database to migrate and store your organizations Secure Messages content from the eShare hosted Database. The following steps will be reviewed:
Requirements and Pricing
The recommended practice is to utilize Microsoft’s Azure SQL Database. It offers several deployment options while running as a hosted service and tiers that scale according to your needs.
We recommend the General Purpose tier for the needs of this feature, it offers the best price/performance ratio.
Please see https://azure.microsoft.com/en-us/pricing/details/azure-sql-database/single/ for up-to-date pricing.
Setup SQL Server in Azure
Login to the Microsoft Azure Portal (For Commerical Customers: https://portal.azure.com | For Government Customers: https://portal.azure.us).
Search for ‘SQL Servers’ and select the ‘SQL Servers’ option from the list of services.
On the next screen, select the ‘Create’ option in the top left.
Select your subscription model and define the resource group (Resource group could be named "eShareSQLdatabase" for indexing purposes and ease of reference). It is recommended to define a separate resource group to isolate our access from any other service you might be running.
Next, set a ‘Server name‘ and the ‘Region’ of the database (US East recommended for better performance / same region as eShare)
Finally, for ‘Authentication Method’ ensure a local SQL Authentication user is created, and add a username and password that will be used to access the database.
Confirm the creation of your SQL Database Server and wait for the server to be deployed. Once completed, access the resource to proceed with creating a new SQL Database for the server.
Setup SQL Database in Azure
While in the newly deployed SQL Server resource, stay within the overview page and select the ‘+ Create Database’ option
The Project details of the resource should already be selected and greyed out.
In the Database details section, give your database a name and choose your desired settings for the database.
It is suggested to not use SQL Elastic pool since there will only be one Database in the SQL server, and the default “General Purpose” option for Compute + storage is sufficient.
Determine which backup storage redundancy (up to the organization), but Locally-redundant or Geo-redundant are generally the preferred options.
For the ‘Networking’ options, eShare recommends connection via a Private endpoint, however it can support connection over public internet. The remaining sections can be left as default and the database can be created.
Once creation has completed, navigate to the SQL Server resource, go to the ‘Overview’ page, select ‘JSON View’, and send the Resource ID to your eShare Customer Success Manager so they can initiate the Private Endpoint Connection.
Approve Private Endpoint Connection
In the created newly database navigate to the ‘Security’ section and select ‘Networking’
Select the ‘Private Access’ tab, then under ‘Private endpoint connections” there will be a pending request, review the request and approve it.
Connect the Database in eShare Admin Console
From your Admin Console tab, navigate to the ‘Share messages’ tab, you will be required to point eShare to the Database you created so it can start storing your Organizations Secure Messages. Fill out the required fields with the information:
Database Type: SQL Server
Host: Endpoint name of the SQL Server
Port: 1433
Database: Name of the created SQL Database
User: local admin account username
Password: local admin account password
Enable Secure Transport: Disable (AzureSQL has this on by default so you do not need to specificy)
NOTE:
After saving you may receive an error message, ensure you have entered all information about the database correctly and the network connection has been put into place.
All Done! Now eShare will utilize your own Azure Database for all secure messages sent in Trusted Shares hosted by your organization.
Monitoring and keeping Database healthy
In our implementation the most important and common things to keep track of to make sure the Database remains healthy are CPU Percent, Memory Percent, Network In/Out and Network connections and finally Storage Metrics.
Find these in the ‘Metrics’ tab under Monitoring in your AzureSQL Database.
CPU Percent: A high CPU percent is not a bad thing if you don’t consistently reach the limit.
Memory Percent: Ideally your entire Database should be stored in memory while leaving enough for other processes. Check frequently as your Database scales in size.
Network In/Out and Connections: Unless doing backups or transferring huge amounts of data, it should not be the bottleneck
Storage Metrics: Make sure you always have free space for new data, temporary files, snapshot, or backups. You can create an alert when database, logs and temp is > 85% usage so you can scale accordingly.