Implementation Guide
The easiest way to deploy the SRE into your environment is to use the "Depoy to Azure" button on the main page of this repo (mirrored below for your convenience).
When you click the button, you will be prompted to log into the Azure Portal. Make sure to use an account with permission to deploy resources into the subscription you want to use.
There are six screens of information you need to fill in. The following sections walk you through each one.
This is where you provide some baseline information about the environment.
Select the subscription that you want to deploy the SRE into from the drop-down menu.
If the subscription you need is not in the list then the account you are logged in with does not have access to that subscription. Ask your IT team to verify that you are using the correct account and that the account has access to the subscription.
Choose the Azure region you want from the drop-down. There are 60+ Azure regions worldwide.
In general, the best option is to select a region that is close to your location but not all services are available in all regions.
Check with your IT team to see if there are any restrictions on which regions you can use due to your org's policy, data residency requirements, data use agreement limitations, etc.
Default: Production
This is a label which indicates whether the new SRE instance is considered Production, Test, Dev or Sandbox.
If you're not sure which to choose then just use "production". There is no functional difference in the deployment based on this selection.
It is a common practice in large IT environments to separate systems which are in active use -- described as "production" -- from systems which are experimental, in testing or are being modified to add or change features (development). This is to prevent accidental changes to production systems and to allow new features to be thoroughly tested before they are finalized and moved into production.
Default: New
It is recommended that you create a new workspace for this instead of using an existing one in order to separate the activity logging and other telemetry from this SRE from other Azure services managed by your organization.
Your IT team may require you to use an existing workspace. If they do then you can select "Existing" and choose the workspace they want you to use from the drop-down.
This is where you specify the name of the workspace and some more information about how it should be configured in your environment.
This is an identifier that you can use to identify the workspace, such as what team, department or project it is used for. This is truncated to six characters and appended to the names of the resources that are created.
For example, a workspace name of "ARLLAB" will result in resources named "ARLLAB-adf-prd-eastus-01", "ARLLAB-logic-prd-eastus-01", etc.
Default: 1
This is a number which is unique to this SRE instance. It is appended to the names of the resources that are created. If you have multiple SREs with the same name and environment identifier, each one should have a unique Instance Number.
To continue the above example, if the "ARLLAB" team has more than one SRE, then the first SRE environment would be number 1, the second would be number 2, etc.
This is to make it easier to manage environments where multiple SRE's may exist for the same group with each one being used for a different project/purpose.
If this is your first SRE then the default of "1" is fine.
Default: New
It is recommended that you use the default option "New" which will create a new isolated virtual network for the SRE. This will prevent any accidental access to the SRE from other Azure resources in your environment.
Your IT team may require you to use an existing virtual network for this, in which case choose "Existing" and select the existing virtual network and subnet that they want you to use from the drop-downs.
Default: No
Similarly to the above, your IT team may require that the SRE virtual network be linked to an existing "hub" virtual network. While this is not recommended, it is supported. If you are required to do this then select the virtual network that they require you to link to from the drop-down.
Using the default of "No" is recommended to maintain isolation of the SRE instance.
Default: New
This option allows you to create new storage accounts for this SRE instance or use existing ones. If you have an existing storage account that you want to use then select "Existing" and select the storage account from the drop-down -- but beware of unwanted interactions between the new SRE and other services in your environment.
Using the default of "New" is recommended to maintain isolation of the SRE instance.
Secure access to the SRE is a key element of the design. This screen is where you can choose to create a new Azure Virtual Desktop instance to access your environment or link to an existing one.
Default: No
Recommended: Yes (if your organization does not use AVD)
If you select "Yes" then a new Azure Virtual Desktop Host Pool and Application Group will be created and configured to provide access to the SRE. This is the recommended option in most cases
If your IT team already uses AVD then you should select "No" and ask them to work with you to make the preferred application for accessing your SRE services available to you and your team. If you select "No" and your organization does not use AVD then you can use other methods such as Azure Bastion to access virtual machines in your SRE environment.
If you choose "Yes" then provide the following information:
- Number of Instances: This is the number of virtual machines that will be available for users to connect with. The default of 1 is sufficient, but having more than one will provide redundancy and also allow more users to simultaneously use the SRE. More than one user can use an instance at the same time, however, so you don't need 1 instance per user.
-
Password: An account called
AzureUserwill be created on each instance. This is where you enter the password that SRE users will use with that account as a gateway to your SRE. Keep this secure! - Confirm Password: Enter the password again to confirm it.
- Session Host Size: The default (D2as_V4) is fine for most cases. If you have a large number of users then you may want to choose a larger size or, optionally, use more instances (see first bullet above). Consult your local IT team for guidance.
This page is where you specify the identity of the person or managed identity that will approve data movement out of the SRE. This is a key element of the design to ensure that data is not accidentally moved out of the SRE without proper approval.
Default: (blank)
Enter the email address that approval requests for data movement for the SRE will be sent to. This should be the person who is acting as the "Data Approver" for the SRE.
This allows you to specify a managed identity that will be used to access the SRE. This is relatively uncommon. If you are unsure of whether you need this then just leave this section blank.
Tags are name/value pairs that are used to identify Azure resources. Your organization may have a policy which requires that you provide certain tags for resources that you create. If so, then you can specify them here.
If you are unsure then you can safely leave this screen alone.
Reference: Use Tags to Organize your Azure Resources
This page provides a summary of what you have selected on the other screen and performs validation checks to make sure that no required elements have been left blank or misconfigured.
If you get a red X at the top of the screen then you will need to go back and correct the error. The tab with the error on it will also have a red X next to it - just click on the tab to jump back to that page and correct the error.
When you get a "Validation Passed" message with a green check mark at the top of the screen like the one below the you're good to go! Click the Create button to start the deployment.
Deploying the SRE takes ten to fifteen minutes in most cases.