SMT system requirements and how to set up high-availability


As we’ve covered in previous posts, Server management tools (SMT) is a hosted service in Microsoft Azure which allows you to manage your Windows Servers from anywhere, from any platform, for free!

This post will dig into system requirements in more detail and explain how to set up your SMT gateway for high-availability.

Basic Requirements

  • Microsoft Azure subscription
    • If you don’t have a subscription already, you can start with a free trial, or activate a pay-as-you-go subscription.
    • In either case, SMT is a free service, and you won’t be billed for any usage of SMT.
  • Internet-connect Web browser

Connectivity Requirements

  • The server that you designate as an SMT gateway must have outbound internet connectivity.
  • The servers that you connect to for management must be on the same network as the gateway, and the gateway must be able to connect to those targets via WinRM.
  • Workgroup environments: One common gotcha to remember is that if your servers are not domain-joined, make sure that the TrustedHosts entry on the gateway allows it to connect to the target servers you want via WinRM. Run the following command in PowerShell or CMD as Administrator.  TargetMachineNameOrAddress should be the NetBIOS name, FQDN or IP address (IPv4 or IPv6) used by the gateway to connect to the target server. You can add multiple targets by separating them with commas:
    winrm set winrm/config/client @{ TrustedHosts="TargetMachineNameOrAddress" }
    

    NOTE: The command above will replace any previous list of registered trusted hosts with the host(s) you specify in the command. You can also run this in PowerShell with the Concatenate parameter to add a computer name to an existing list of trusted hosts:

    Set-Item wsman:\localhost\Client\TrustedHosts TargetMachineNameOrAddress -Concatenate

    In addition, if you wish to connect to a workgroup machine that is not on the same subnet as the gateway, you must enable a firewall rule on the target machine to allow inbound WinRM calls from the gateway. Run the following in an administrator session on the target machine:

    NETSH advfirewall firewall add rule name="WinRM 5985" protocol=TCP dir=in localport=5985 action=allow

Windows Version Requirements

  • The following table explains which Windows Server versions you can install the SMT gateway on, and which Windows Server versions you can target for management using SMT:
SMT Gateway SMT Connection
Nano Server Net Yet Supported* Supported
Windows Server 2016 Supported Supported
Windows Server 2012 R2 Supported** Supported***
Windows Server 2012 Not Supported** Supported***
Windows Server 2008 R2 (and older) Not Supported Not Supported


Notes:

* The SMT Gateway software cannot currently be installed on Nano Server due to some missing dependencies, but we hope to support this in the future.

** For a WS 2012 R2 server, you will need to install WMF 5 before the SMT Gateway can be installed.

*** When connecting to a WS 2012 or 2012 R2 target, SMT will ask to automatically install WMF 5 and the SMT WMI provider as needed.

  • Server Core: A Windows Server machine running a Server Core configuration is fully supported as both a gateway and a connection target.
    • To install the SMT Gateway software on a Server Core machine, you just need to run the MSI using the quiet mode parameters in an elevated command window.
    • To have the installer generate a self-signed certificate, use the following command options:
      GatewayService.msi /qn GATEWAYPROFILEJSON=.\profile.json ACCEPTEULA=true ACCEPTPRIVACYPOLICY=true
    • To use an existing certificate installed on the machine, use the following command options. Replace EnterThumbprintHere with your own certificate encryption thumbprint:
      GatewayService.msi /qn GATEWAYPROFILEJSON=.\profile.json ACCEPTEULA=true ACCEPTPRIVACYPOLICY=true ENCRYPTION_CERTIFICATE_OPTION=root ENCRYPTION_THUMBPRINT=EnterThumbprintHere

Gateway Hardware Requirements

  • The server on which you install the SMT Gateway software should meet the minimum system requirements for WS 2012 R2 or WS 2016.
  • The SMT Gateway service is fairly lightweight, using ~20 MB of memory at idle and ~150-200 MB when processing requests.
    • Therefore, the hardware requirements for the SMT Gateway service depends on the peak number of simultaneous management requests you expect the gateway to be able to handle.
    • g. If you are the only administrator using a particular gateway, a VM with 2 virtual processors and 2 GB of memory would more than suffice.
    • g. If you expect up to 5 simultaneous administrators performing management operations through that gateway, a VM with 4 virtual processors and 4 GB of memory would be more appropriate.
    • In all cases, the number of SMT Connections that a particular SMT Gateway is connected to when idle does not affect the hardware requirements on the gateway machine. You can have 1, 10, or 100+ connections for any given gateway.

Gateway Certificate Requirements

When installing the SMT Gateway service, you have the option of either generating a self-signed certificate for testing purposes, or using a certificate which you provide. The self-signed certificate generated by the gateway installer will expire after 60 days. The portal will notify you when expiry occurs and how to register a new certificate. You can also refer to the “Handling Certificate Expiration” section at the bottom of this post. If you provide your own certificate, here are the requirements:

  • Required: Signature algorithm sha512RSA
  • Required: Must be imported to LocalMachine Personal certificate store
  • Required: The certificate’s private key must be installed on the machine
  • Required: SYSTEM and Local admin accounts must have full control of the private key
  • Required: Key Usage must be set to “Key Encipherment”
  • Recommended: EKU set to Server Authentication (1.3.6.1.5.5.7.3.1)
  • Recommended: RSA public key size >= 2048 bits

Optional: Set Up Gateways for High Availability, without requiring a Failover Cluster!

There are a couple of ways to ensure that you can still manage your target servers via SMT, even if your SMT Gateway goes down.

  • Option 1: Multiple resource groups, each containing a separate SMT Gateway
  • Option 2: Multiple instances of a single SMT Gateway

High Availability via Multiple Distinct Gateways (Option 1)

Overview: The diagram below illustrates two separate SMT Gateway resources, each one backed by its own separate gateway deployment. In this case, Gateway A is fully independent from Gateway B, but both gateways can manage Server X and Server Y.

HA usage: If Gateway A goes down and you can’t connect to Server X and Y via Resource Group A, just go to Resource Group B to connect to Server X and Y via Gateway B.

Setup requirements:

  • Each additional SMT Gateway you add for HA must be created in a separate resource group. This is because the connection targets will have the same name and you can’t have duplicate resource names in the same resource group.
  • Each SMT Gateway must have its own unique instance of the gateway deployment package installed on a separate server you designate for the gateway software on your network.
  • Each resource group must also contain its own set of SMT Connection resources. This is because connections are always routed through a specific SMT Gateway in the same resource group.
  • The diagram shows two resource groups, but you can scale up to n resource groups as needed.
  • The diagram shows two connection targets, but you can scale up to n target servers for any given gateway.

Pros:

  • Each gateway can have a different certificate registered and the certificates do not need to be manually synchronized.

Cons:

  • If a connection through Gateway A is down, you need to manually connect through Gateway B by trying a different connection in a separate resource group.
  • In Browse views which show all connections, you will see duplicate connection resources with the same name (differentiated only by the Gateway column in that view).
  • Requires additional effort to set up extra resource groups and separate gateway and connection resources.

Diagram of option 1:

Diagram of option 1

High Availability via a Single Gateway with Multiple Instances (Option 2)

Overview: The diagram below illustrates a single SMT Gateway resource, backed by two instances of the same gateway deployment. In this case, Instance 1 and Instance 2 both simultaneously and independently process requests for Gateway A, and both instances can manage Server X and Server Y.

HA usage: If Instance 1 goes down, Gateway A can still connect to Server X and Server Y via Instance 2. Functionally, Gateway A is still up and running.

Setup requirements:

  • For each instance of a particular gateway, you must install the same gateway deployment package. In the diagram below, Instance 1 and Instance 2 both have the same Gateway A deployment package installed.
  • Each instance of a particular gateway must have the same certificate registered, and this certificate must remain synchronized across all instances of that gateway. Details in the Synchronization section below.
  • Each instance of a particular gateway must be running the same version of the SMT Gateway service. If the gateway update mode is set to Automatic, the instances will each update to the latest version. If the gateway update mode is set to Manual, you will need to ensure that when you manually install a new version of the gateway MSI, you install it on all instances.
  • The diagram shows two instances, but you can scale up to n instances as needed.
  • The diagram shows two connection targets, but you can scale up to n target servers for any given gateway.

Pros:

  • Each instance is always processing requests for the gateway, so if one instance goes down, the gateway continues to work without interruption for the user and does not require the user to try a different connection.
  • No duplication of resources or resource groups.

Cons:

  • Need to ensure that the registered certificate is synchronized across all instances and remains synchronized for the entire lifespan of the gateway, including synchronization of a new certificate when the previous one expires.

Diagram of option 2:

Diagram of option 2

How to Synchronize a Certificate across Multiple Instances

As described above, if you have multiple instances of a gateway, each instance must have the same certificate registered. This is currently a manual process.

Manual Synchronization Steps:

  1. Install the gateway MSI on the first server as you normally would. See previous blog post on this topic for a detailed walk-through.
  2. Go to the gateway blade in the portal and find the certificate thumbprint (Overview -> gateway machine name -> Primary encryption certificate thumbprint):
    Certificate Thumbprint
  3. Create an SMT connection to the server which is running the gateway (i.e. loopback connection to itself). In the case above, SL-AzTst-GW is the name of the gateway resource in Azure, and SL-AzTst-WS16-1 is the name of the server on which I installed the gateway MSI, so I can create an SMT connection to SL-AzTst-WS16-1:
    Loopback Connection
  4. Go to the connection blade in the portal, open the Certificate Manager tool, and find the certificate which has the same thumbprint as the one registered as the gateway's primary encryption certificate above. Select the one which has a private key which is present and exportable:
    Find Certificate
  5. Right-click the selected certificate and Export. Select Yes to export private key and enter a password to secure the file. Then click the Export command to generate the .PFX file and Download:
    Export Cert
  6. Similar to step 3 above, create an SMT connection to the server that you want to install the second instance of the gateway on. In my case, it's SL-AzTst-WS16-2. Open this connection and use the Certificate Manager tool to Import the .PFX file you just downloaded into the LocalMachine certificate store, My logical store:
    Import Cert
    If you get an error during Import, please enable the Firewall rule for SMB-In and try to import the cert again:
    Firewall rule SMB-In
  7. Go back to the gateway blade, click Setup, and generate a package link (since your previous link may have expired by now):
    Gateway Setup - Generate package link
  8. Use the link to download the gateway deployment package and install it on the server you want to designate as the second instance of the gateway. In my case, it's SL-AzTst-WS16-2. This is the server on which I just imported the .PFX file in step 6. This time when I run the gateway installer, I'll paste in the thumbprint of that certificate from step 2, so the gateway service will use the same certificate I imported:
    Thumbprint
  9. Go back to the portal, open the gateway blade, and confirm that the second gateway instance shows up in the list. Congratulations, your gateway is now highly-available via multiple gateway instances!
    Multi-Instance Gateway

Handling Certificate Expiration:

If your gateway certificate is already expired, any previously saved credentials will need to be re-saved after the new certificate is registered. If your gateway certificate is close to expiring but has not yet expired, any previously saved credentials will be automatically re-encrypted using the new certificate after it is registered, as long as a connection attempt is made within a 30-day cert rotation period.

On the server where you have the gateway service installed, there is a script to help with registering a new certificate:

\Program Files\ServerManagementToolsGateway\Scripts\New-GatewayEncryptionCert.ps1

To generate a new self-signed primary certificate and change the old primary to the secondary encryption cert, run the script with no parameter values:

New-GatewayEncryptionCert.ps1

To rotate certificates, using an already-installed certificate as the new primary cert:

New-GatewayEncryptionCert.ps1 -Thumbprint <EnterThumbprintHere>

For the first instance of the gateway where you register a new certificate, you can use either option above. To maintain synchronization of the other instances, you will need to export and import the .PFX as described in the previous section and then run the script above with the -Thumbprint parameter to register the same cert that you imported.

Summary

Whew, this post turned out to be a lot longer than I thought it would be. Thanks for following along, and I hope it was useful to see a consolidated list of the categorized system requirements to help with deployment planning and make it easier for you to set up SMT and start using it! Once you discover the value of SMT and decide to continue using it, go ahead and set it up for high-availability as appropriate in your environment.

As always, just a reminder to submit your ideas and suggestions for feature requests on our UserVoice forum. Thanks!

 

Comments (2)

  1. Jesper Nøhr says:

    Dear Samuel

    I have been very happy using SMT on my windows server 2016 core.
    But after moving my ressources from Norh Euope to West Europe it has stopped working.

    The Server management tools gateway - PREVIEW is status "OK"

    But I am getting this error on the Server management tools connection - PREVIEW: "Connection Error"
    Unable to connect to the server 'hostname.domain.com': 'Cannot find the feature with the name 'downlevelSupport'.'.

    I have tried to remove server managent tools completely and i have tried to download a new installer package + profile.json - no luck.

    I even tried to generate a new certificate with New-Gatewayencryptioncert.ps1

    also my user is a member of "remote management users"

    Kind regards

    1. Hi Jesper!
      Unfortunately, SMT doesn't currently support resource move. The easiest solution is to create a new gateway resource in the new location and recreate server connections for the new gateway. Let me know if you still have a problem.

Skip to main content