Installing SentryOne Monitoring Service on Windows Server Core Using Enhanced Platform Installer (EPI)

In this blog, I’d first like to provide an overview of the SentryOne Enhanced Platform Installer (EPI). Then I’ll walk you through how to install a SentryOne monitoring service on a Windows Core machine, as there are several benefits of running a Windows Server Core machine as opposed to a standard GUI Windows Server.

For a demonstration, I’ll set up the SentryOne database on a Windows Server 2016 machine along with the SentryOne client. Below is a diagram showing you which SentryOne components are installed across the environment.

SentryOne Enhanced Platform Installer Overview

The Enhanced Platform Installer is an upgrade application that automates SentryOne software updates, saving you time and resources while ensuring your SentryOne solutions remain up to date. The EPI still comprises the same components as the standard SentryOne installer, but it provides a solution to upgrade automatically across your environments. Users can install future updates by downloading the latest upgrade packages, which in turn will disperse to all the SentryOne components, including the SentryOne Database, Client, and monitoring service. This process provides an easy solution for customers that have large or complex environments.

Now that we understand the SentryOne Platform Installer, let’s move onto looking at the differences between Windows Core and Windows Server machines.

Windows Core vs. Windows Server

Windows Server Core is completely headless, which means it has no GUI and is command line driven. Also, it is lightweight and ideally used for large data centers and cloud environments, both physical and virtual. Windows Core leaves a smaller footprint, which means less disk space and utilizes less network bandwidth. With Windows Core, you can install, uninstall, and upgrade applications on demand. Windows Server involves interactions from the users, but with Windows Core, we can pass in commands either manually or through an orchestration tool of your choice.

Windows Server machines are going to have a larger footprint and going to require more resources. Since Windows Servers have a GUI, it’s going to require that all the Windows GUI components are installed on the machine. This, in turn, will require more disk space and more resources allocated to the Windows Server machine. If you need a development workspace, then ‘Yes’ a Windows Server machine makes sense. However, if the sole purpose of the machine is to run an application, I recommend a Windows Core machine. That said, let’s move onto the EPI installation on our environment.

SentryOne EPI Installation

First, we need to grab the EPI installer from the SentryOne website. Login to SentryOne and go to the downloads section and download the ‘SentryOne Unified Setup.’

$isoFolder = "SentryOneEPI.iso"
if (test-path $isoFolder){
remove-item $isoFolder -Force -Recurse
}
if (test-path C:\Users\jclark\Desktop\ISO\ISOFile\SentryOneEPI.iso){
remove-item C:\Users\jclark\Desktop\ISO\ISOFile\SentryOneEPI.iso -Force
}
mkdir $isoFolder
#Place the files you want zipped into an ISO image into this directory C:\Users\BuildSvc\Desktop\ISO\ISOContents\
Copy-Item C:\Users\jclark\Downloads\SentryOneSetup.exe $isoFolder\
#Set location to mkisofs.exe
Set-Location "C:\Program Files\mkisofs\win32"
# Enable UEFI and disable Non EUFI
$c | ForEach-Object { $_ -replace '<!-- Start Non UEFI -->','<!-- Start Non UEFI' } | ForEach-Object { $_ -replace '<!-- Finish Non UEFI -->','Finish Non UEFI -->' } | ForEach-Object { $_ -replace '<!-- Start UEFI compatible','<!-- Start UEFI compatible -->' } | ForEach-Object { $_ -replace 'Finish UEFI compatible -->','<!-- Finish UEFI compatible -->' } | Set-Content -Path $textFile
#Create a secondary.so and place it in a directory that we can over write to. C:\Users\BuildSvc\Desktop\ISO\AnswerFiles\secondary.iso
& .\mkisofs.exe -r -iso-level 4 -udf -o C:\Users\jclark\Desktop\ISO\ISOFile\SentryOneEPI.iso $isoFolder
#Clean up
if (test-path $isoFolder){
remove-item $isoFolder -Force -Recurse
}

Unzip the ‘mkisofs’ zip file to ‘C:\Program Files’ or another directory of your choice. Be sure to modify the script to point to your location. Create a directory on your desktop for the ISO file to be placed. I decided to name the ISO file directory ‘C:\Users\jclark\Desktop\ISO\ISOFile.’ Follow the directory in the script and run it, which will create the ISO file. You may encounter a few warning messages, but those are related to enabling UEFI and disabling non-UEFI properties for the ISO file. Those warnings messages can be ignored.

Now that the ISO file has been created, we can mount the ISO to the Windows Core machine. I’ll use Hyper-V for this.

CMD: SentryOneSetup.exe -install /quiet

Navigate to “C:\Program Files\SentryOne Framework” and begin the registration of the SentryOne Database. Before we begin the registration process, we should talk about the CLI parameters. Additionally, we need to be sure we are running the CLI command from inside the directory where we installed the SentryOne tools. By default, that location is “C:\Program Files\SentryOne Framework.” With each CLI command that we run, we’ll prefix the command with the ‘so’ keyword. For Example:

CLI: so listreg – Lists all registrations

Below is a list of parameters that we will be using and their descriptions.

Parameters

1. connectionName: The friendly name for this connection which appears on the Repository Connection Management screen. The name itself is arbitrary, but once you pick one, you must stick with it for all EPI commands associated with this connection.
2. conenctionServer: The server that will be hosting the SentryOne database.
3. connectionDatabase: The name of the SentryOne database.
4. serverName: The name of the server hosting the SentryOne database, or where you’ll install the SentryOne database.  
   Notes:
   1. You may use localhost, if applicable.
   2. When working with a named instance, the parameter format is serverName\instanceName.
   3. When the SentryOne database is part of an availability group, it is recommended to use the availability group listener name instead o the SQL Server name.
5. databaseName: The name of the SentryOne database that will be created or updated. 
6. SQLServerUserName: The SQL Server authentication username.
   Note: This is only needed when using SQL Server authentication.
7. SQLServerUserPassword: The SQL Server authentication password associated with the SQL Server user name. Note: This is only needed when using SQL Server authentication.
8. SQLServerConnectionPort: The SQL Server connection port. The default port is 1433.
   Note: This is only needed when specifying a different parameter value for the port number. 
9. serviceAccount: The account used to run the SentryOne monitoring service.
10. servicePassword: The password associated with the service account.

We can run the following command to register the SentryOne database on the Windows Server GUI machine.

CLI: so addreg -n SentryOneDatabase –connectionServer ServerName –connectionDatabase SentryOne

CLI: so createdb -n SentryOneDatabase

After the SentryOne database is created, we can switch over to the Windows Core machine and add the registration for the monitoring service. We’ll need to find which drive has the mounted ISO file that contains the EPI executable. The command below will list the drive attached to the Windows Core machine.

CMD: wmic logicaldisk get name

CMD: SentryOneSetup.exe -install /quiet

Switch back to the C:\ drive and change directories to ‘C:\Program Files.’ Run the ‘dir’ command to verify the ‘SentryOne Framework’ directory was created and CD into it. Let’s register the monitoring service on the Windows Core machine. Since we are already CD’ed into the ‘SentryOne Framework’ directory, we can run the following command to register out monitoring service.

CLI: so addreg -n SentryOneService -connectionServer ServerName –connectionDatabase SentryOne

CLI: so install -n SentryOneService -u serviceUsername -p servicePassword

Now that we added the registry for the monitoring service and installed, we can check to see if the service is running by running the following command.

CMD: sc queryex type=service state=all

This command will list all running services, but we want to verify that both “SentryOneController” and “SQLSentryServer” services are running. Given that the services are running, we can log onto the VM that will be running the SentryOne client. In our case, we’re going to run the SentryOne client from the same machine that is hosting the SentryOne database.

If you’ve chosen to install the SentryOne client on another machine, you’ll need to run the EPI installer again. In our case, we can navigate to the “C:\Program Files\SentryOne Framework” directory on the machine that is hosting the SentryOne database and open “SentryOne.App.ClientBootstrapper” application. Feel free to rename and copy that file to the desktop for easy access.

When you open the client application, you should see the repository connection management screen without SentryOneDatabase registration. Click and connect to the SentryOneDatabase registration. Now that you can connected to the new SentryOneDatabase registration, you can add targets and monitor.

Summary

We walked through the SentryOne EPI components and discussed the difference between Windows Server and Windows Server Core machines. Running the monitoring service on a Windows Server Core machine should help conserve resources across your environment since it has a smaller footprint than Windows Server machines. Also, using the EPI CLI will help you better manage your SentryOne environment.

Jared Clark

Jared works as a DevOps Engineer at SentryOne. Jared focuses on optimizing the process and tooling used by our delivery teams and evangelizes DevOps practices. He originally joined the SentryOne team in 2017 as a Technical Support Specialist. He moved from the support team and joined the engineering team in 2018.