ServerEngine

Introduction to ServerEngine Documentation

Welcome to the ServerEngine documentation! This guide is designed to help you get the most out of ServerEngine, your go-to solution for efficient server automation, management, and monitoring. Whether you’re new to the platform or looking to explore its advanced features, this documentation provides you with everything you need to get started, configure, and optimize your ServerEngine setup.

ServerEngine simplifies server management by automating routine tasks, offering real-time insights, and providing powerful tools to streamline administrative workflows. With detailed explanations and step-by-step instructions, this documentation ensures that you can leverage the full potential of ServerEngine to enhance productivity, improve server performance, and reduce manual errors.

What You Will Find in This Documentation:

• Getting Started: A comprehensive guide on installing and configuring ServerEngine.
• Key Features: An in-depth look at essential features like remote automation, monitoring, and script management.
• User Interface Overview: A breakdown of the main UI components and how to navigate them.
• Best Practices: Recommended workflows for maintaining server health and automating administrative tasks.
• Troubleshooting & Support: Solutions to common issues and guidance on getting help if needed.

By following this documentation, you’ll be able to maximize the value of ServerEngine in managing your servers, ensuring that they are automated, secure, and performing at their best.

Install ServerEngine

# Option 1: Microsoft Store (Windows 10,11)
- Search "ServerEngine" > Install

# Option 2: Command Line (Windows 10,11)
winget install ServerEngine --silent --accept-package-agreements --accept-source-agreements

# Option 3: Download and Install (Windows Server 2019,2022,2025)
Add-AppxPackage -Path serverengine.msix -ForceApplicationShutdown

Download ServerEngine (Warning may appear due to unsecure download link)

On the first startup ServerEngine needs to configure the WinRM service.

Step 1. Click on ‘Install WinRM Service’

Step 2. Accept the promt, click on ‘Yes’

Wait for ServerEngine to complete WinRM service configuration…

Once completed click on ‘OK’ and restart ServerEngine.

Step 3. Navigate to Console Tab and check if WinRM Service is green. (This might take a few seconds to refresh)

Save Credentials

Step 1. Navigate to Credentials Tab and click on ‘Add Credentials’

Step 2. Double-Click ‘Username’ to edit and enter the username of your target host, press ‘enter’ to confirm. (User requires administrative privileges)

Step 3. Double-Click ‘Password’ to edit and enter the password for the user, press ‘enter’ to confirm.

Step 4. Double-Click ‘DNS-Name’ to edit and enter the IP-Address or DNS-Name of the target host, press ‘enter’ to confirm.

(If you choose to use the IP-Address the Domain will be empty) for ex.

(If you choose to use the DNS-Name you also have to provide the Domain) for ex.

Enable WinRM SSL

(Requirements: Windows Remoting must be enabled)
On Windows Server this is enabled by default on Windows 10 or Windows 11 remoting can be enabled using PowerShell (Run as Administrator):

# Enable Windows Remoting on Windows 10 or Windows 11
Enable-PSRemoting -Force

(Clarification: ServerEngine uses the WMI protocol to remotely configure WinRM SSL with a self-signed certificate)

Step 1. To easily configure WinRM SSL on your target host, navigate to Console Tab and click on ‘One-Click Install WinRM SSL’

Step 2. Select your target host and click on ‘Install WinRM SSL…’

Wait for ServerEngine to complete…

Once completed you should see the confirmation and click on ‘OK’

If you choose to use the IP-Address there is one more step to enable remote execution with IP-Address.
If you choose to use the DNS-Name you can skip Step 3.

Step 3. Navigate to Settings Tab and click on ‘Security’ and check ‘Allow WinRM SSL with IP-Address’

Create Your First Script and Package

Step 1. Navigate to Scripts, Package Builder and click on ‘New Package’
(Packages are used to organize and bundle one or more scripts, when adding a job to the automation the package is used for assignment)

Rename the package if you like or just click on ‘OK’

Step 2. Double-Click the ‘(Packagename)’ to rename the package, click on ‘Save’ to confirm

Step 3. Select your package and click on ‘New Script’

Select to create a PowerShell or Python script, for this example we click on the PowerShell Icon

Rename the script or just click on ‘OK’

Double-Click the ‘(scriptname)’ to rename and click on ‘Save’ to confirm

Step 4. Select script and click on ‘Edit Script’

ServerEngine will open PowerShell ISE as Editor, now you can start writing and testing your first script

Step 5. Write this code to resolve the hostname:

# We start creating a variable containing the hostname, the command hostname resolves the hostname of you pc
$myhostname = hostname
# Then we can parse the output to ServerEngine so we can see it in the ServerEngine log
# (<WRITE-LOG = ""*) tells ServerEngine to capture the output and (*"">") where it ends
Write-Host "<WRITE-LOG = ""*$myhostname*"">"

To test your code 1. Click on the save icon 2. Click on the play (run) icon

Check the output, you should now be able to see your pc’s hostname

Now that you have verified a working script you can close the editor

Run Your First Job

Step 1. Navigate to Activity Dashboard Tab, Automation and click on ‘Add’

Step 2. Click on the package icon

Step 3. Select the package you want to run and click Next

Step 4. Select a single or multiple hosts and click on ‘Assign to Automation’
(Already saved credentials are shown in this list)

ServerEngine will add it to the automation
(ServerEngine then assigns a unique Job ID)
(The Agent icon will appear when the agent starts working on a job, the agent handles connecting to the host running the script and handle reboots if needed)
(Each agent can run one job at a time, in the top right you can see how many agents you have purchased, the free license includes only 1 agent)
(You can also see the status for the job to easily identify what is happening at a given time)

Once the job is completed ServerEngine will automatically clean the Dashboard, you can disable this in the Settings Tab under System Maintenance if you like. Just uncheck ‘Enable automated resource cleanup’

Step 5. Check Logs, navigate to Logs Tab and click ‘Scroll’

• You can see the user that assigned to job
• You can see the target host and package
• You can also see the parsed output from the script which we parsed to ServerEngine which was the host name of the target host
• ServerEngine will automatically cleanup the dashboard if all jobs are completed and no agent is currently working

That’s it! If you have any questions feel free to reach out, we are happy to help! ❤️
Mail: contact@cforce-it.com

WinRM over HTTPS with a Self-Signed Certificate

What this script does:

• Checks if script was executed as Administrator
• Configures the network adapters default profile to Private (This is required)
• Enables Windows PowerShell Remoting
• Starts WinRM Service and enable autostart
• Prepares WinRM for communication over HTTPS
• Gets the current hostname of the machine
• Checks if certificate with the hostname already exists
• If the certificate does not exist or is expired, a new one is created
• It removes any existing HTTPS listeners in the WinRM Service
• It creates a new HTTPS listener with the generated certificate allowing all IP-Addresses
• Binds the HTTPS listener to all network interfaces (all IP addresses) on this machine
• Checks firewall rule and creates missing Windows Remote Management (HTTPS-In)
• Outputs certificate information and expiation date

# Configures Windows PowerShell Remoting and WinRM for ServerEngine management
# With Self-Signed Certificate works with IP-Address and DNS Name
#----------------------------------------------------------------
# Requires Administrator previlegues

$isadm = ([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator)
if (-not $isadm) {
    Write-Host "<WRITE-LOG = ""*Please run this script as Administrator.*"">"
    Write-Host "<WRITE-LOG = ""*If this was a remote execution please provide Administrator credentials.*"">"
    Write-Error "Warning: Not running as Administrator."
}

# Step 1 - Prepare Network Adapters
Get-NetConnectionProfile | Set-NetConnectionProfile -NetworkCategory Private 2>$null

# Step 2 - Enable Windows PowerShell Remoting
Enable-PSRemoting -Force

# Step 3 - Configure WinRM SSL with Self-Signed Certificate

# Start WinRM service if not running
if ((Get-Service WinRM).Status -ne 'Running') {
    Start-Service WinRM -ErrorAction Stop
    Set-Service WinRM -StartupType Automatic -ErrorAction Stop
}

# Configure HTTPS listener
winrm quickconfig -transport:https -force 2>$null

# Check for existing certificate
$hostname = hostname
$existingCert = Get-ChildItem "Cert:\LocalMachine\My" | 
    Where-Object { 
        $_.Subject -eq "CN=$hostname" -and 
        $_.Issuer -eq "CN=$hostname" -and
        $_.HasPrivateKey -eq $true
    } | Sort-Object NotAfter -Descending | Select-Object -First 1

# Create new certificate only if needed
if ($existingCert) {
    # Check if certificate is expired or expiring soon (within 30 days)
    $daysUntilExpiry = ($existingCert.NotAfter - (Get-Date)).Days
    
    if ($daysUntilExpiry -le 0) {
        Write-Host "Existing certificate expired $([Math]::Abs($daysUntilExpiry)) days ago. Creating new certificate..."
        $cert = New-SelfSignedCertificate -DnsName $hostname -CertStoreLocation "Cert:\LocalMachine\My" -KeySpec KeyExchange -ErrorAction Stop
    }
    elseif ($daysUntilExpiry -le 30) {
        Write-Host "Existing certificate expires in $daysUntilExpiry days. Creating new certificate..."
        $cert = New-SelfSignedCertificate -DnsName $hostname -CertStoreLocation "Cert:\LocalMachine\My" -KeySpec KeyExchange -ErrorAction Stop
    }
    else {
        Write-Host "Using existing valid certificate (expires in $daysUntilExpiry days)"
        $cert = $existingCert
    }
} else {
    Write-Output "No existing certificate found. Creating new certificate..."
    $cert = New-SelfSignedCertificate -DnsName $hostname -CertStoreLocation "Cert:\LocalMachine\My" -KeySpec KeyExchange -ErrorAction Stop
}

# Remove any existing HTTPS listeners
winrm delete winrm/config/Listener?Address=*+Transport=HTTPS 2>$null

# Create HTTPS listener with the certificate
New-Item -Path "WSMan:\localhost\Listener" -Transport HTTPS -Address * -CertificateThumbprint $cert.Thumbprint -Force -ErrorAction Stop

# Configure firewall (skip if rule already exists)
if (-not (Get-NetFirewallRule -Name "WINRM-HTTPS-In-TCP" -ErrorAction SilentlyContinue)) {
    New-NetFirewallRule -Name "WINRM-HTTPS-In-TCP" -DisplayName "Windows Remote Management (HTTPS-In)" -Enabled True -Direction Inbound -Protocol TCP -LocalPort 5986 -Action Allow -ErrorAction Stop
}

Write-Host "WinRM HTTPS successfully configured"
Write-Host "Certificate Thumbprint: $($cert.Thumbprint)"
Write-Host "Certificate Expires: $($cert.NotAfter.ToString('yyyy-MM-dd'))"
Write-Host "<WRITE-LOG = ""*PowerShell Remoting successfully configured.*"">"

Important: Check your ServerEngine Security Setting

• Enable: Enable WinRM encryption for automation
• Enable: Allow WinRM SSL with self-signed certificate
• Enable: Allow WinRM SSL with IP-Address
• Disable: Allow WinRM SSL with expired certificates

This is a secure method for remotely executing PowerShell scripts using Windows Remote Management (WinRM), with the flexibility to use both IP addresses and DNS names.

WinRM over HTTPS with a Custom Domain Certificate

What this script does:

• Checks if script was executed as Administrator
• Configures the network adapters default profile to Private (This is required)
• Enables Windows PowerShell Remoting
• Starts WinRM Service and enable autostart
• Prepares WinRM for communication over HTTPS
• Gets the current hostname of the machine
• Loads existing domain certificate
• If the certificate does not exist or is expired, a new one is created
• It removes any existing HTTPS listeners in the WinRM Service
• It creates a new HTTPS listener with the generated certificate allowing all IP-Addresses
• Binds the HTTPS listener to all network interfaces (all IP addresses) on this machine
• Checks firewall rule and creates missing Windows Remote Management (HTTPS-In)
• Outputs certificate information and expiation date

Important Note: Make sure you already have deployed your wildcard domain certificate to this host! You must deploy to “Local Machine\Personal” Store
It’s better to do this manually for security reasons no one wants password floating around in scripts or in the console.

If you choose not to perform it manually, you may use the following script:

# Deploy-Cert.ps1
# This script imports a PFX certificate into the Local Machine's Personal store.

# --- CONFIGURE THESE VARIABLES ---
$CertPath = "\\yourdomain.com\SYSVOL\yourdomain.com\scripts\certs\yourcert.pfx"
$CertPassword = ConvertTo-SecureString -String "YourStrongPassword" -Force -AsPlainText
# --- END CONFIGURATION ---

# Check if certificate already exists (optional, prevents re-importing on every boot)
$ExistingCert = Get-ChildItem -Path Cert:\LocalMachine\My | Where-Object { $_.Subject -like "*.CForce-IT.network*" }
if (-not $ExistingCert) {
    try {
        Write-Host "Importing certificate to Local Machine\Personal store..."
        Import-PfxCertificate -FilePath $CertPath -CertStoreLocation Cert:\LocalMachine\My -Password $CertPassword -Exportable
        Write-Host "Certificate imported successfully."
    }
    catch {
        Write-Error "Failed to import certificate: $_"
    }
} else {
    Write-Host "Certificate already exists. Skipping import."
}

Make also sure to replace the ($hostname = “*.yourcompany.com”) with your company’s wildcard domain certificate

# Configures Windows PowerShell Remoting and WinRM for ServerEngine management
# With Custom Domain Certificate works only with DNS Name and valid Certificate Authority (CA) association
#----------------------------------------------------------------
# Requires Administrator previlegues

$isadm = ([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator)
if (-not $isadm) {
    Write-Host "<WRITE-LOG = ""*Please run this script as Administrator.*"">"
    Write-Host "<WRITE-LOG = ""*If this was a remote execution please provide Administrator credentials.*"">"
    Write-Error "Warning: Not running as Administrator."
}

# Step 1 - Prepare Network Adapters
Get-NetConnectionProfile | Set-NetConnectionProfile -NetworkCategory Private 2>$null

# Step 2 - Enable Windows PowerShell Remoting
Enable-PSRemoting -Force

# Step 3 - Configure WinRM SSL with Self-Signed Certificate

# Start WinRM service if not running
if ((Get-Service WinRM).Status -ne 'Running') {
    Start-Service WinRM -ErrorAction Stop
    Set-Service WinRM -StartupType Automatic -ErrorAction Stop
}

# Configure HTTPS listener
winrm quickconfig -transport:https -force 2>$null

# Load existing domain certificate
$hostname = "*.yourcompany.com" #REPLACE THIS WITH YOUR WILDCARD DOMAIN CERTIFICATE

$existingCert = Get-ChildItem "Cert:\LocalMachine\My" | 
    Where-Object { 
        $_.Subject -like "CN=$hostname*" -and  # Notice the * AFTER, not before
        $_.HasPrivateKey -eq $true
    } | Sort-Object NotBefore -Descending | Select-Object -First 1


# Create new certificate only if needed
if ($existingCert) {
    # Check if certificate is expired or expiring soon (within 30 days)
    $daysUntilExpiry = ($existingCert.NotAfter - (Get-Date)).Days
    
    if ($daysUntilExpiry -le 0) {
        Write-Warning "Existing certificate expired $([Math]::Abs($daysUntilExpiry)) days ago. Creating new certificate..."
    }
    elseif ($daysUntilExpiry -le 30) {
        Write-Warning "Existing certificate expires in $daysUntilExpiry days. Creating new certificate..."
    }
    else {
        Write-Host "Certificate found! (expires in $daysUntilExpiry days)"
        $cert = $existingCert
    }
} else {
    Write-Error "No existing certificate found. $hostname does not exist!"

}

# Remove any existing HTTPS listeners
winrm delete winrm/config/Listener?Address=*+Transport=HTTPS 2>$null

# Create HTTPS listener with the certificate
New-Item -Path "WSMan:\localhost\Listener" -Transport HTTPS -Address * -CertificateThumbprint $cert.Thumbprint -Force -ErrorAction Stop

# Configure firewall (skip if rule already exists)
if (-not (Get-NetFirewallRule -Name "WINRM-HTTPS-In-TCP" -ErrorAction SilentlyContinue)) {
    New-NetFirewallRule -Name "WINRM-HTTPS-In-TCP" -DisplayName "Windows Remote Management (HTTPS-In)" -Enabled True -Direction Inbound -Protocol TCP -LocalPort 5986 -Action Allow -ErrorAction Stop
}

Write-Host "WinRM HTTPS successfully configured"
Write-Host "Certificate Thumbprint: $($cert.Thumbprint)"
Write-Host "Certificate Expires: $($cert.NotAfter.ToString('yyyy-MM-dd'))"
Write-Host "<WRITE-LOG = ""*PowerShell Remoting successfully configured.*"">"

Your expected output should look something like this:

WinRM service is already running on this machine.
Certificate found! (expires in 352 days)


   WSManConfig: Microsoft.WSMan.Management\WSMan::localhost\Listener

Type            Keys                                Name                        
----            ----                                ----                        
Container       {Transport=HTTPS, Address=*}        Listener_1305953032         
WinRM HTTPS successfully configured
Certificate Thumbprint: 108E6F2946496C85386925B5B652588ABD3D06CB
Certificate Expires: 2027-02-05
<WRITE-LOG = "*PowerShell Remoting successfully configured.*">

Important: Check your ServerEngine Security Setting

• Enable: Enable WinRM encryption for automation
• Disable: Allow WinRM SSL with self-signed certificate
• Disable: Allow WinRM SSL with IP-Address
• Disable: Allow WinRM SSL with expired certificates

This the most secure way to remotely execute PowerShell scripts using Windows Remote Management (WinRM)

Now you should be able to run automated scripts remotely, fully encrypted and secure, using WinRM over HTTPS within your company’s domain infrastructure.

Hosts: Add a host to the Credentials Store

In order for ServerEngine to use automate you need to save a host with the credentials allowd to access the host via WinRM, RDP or VNC.
We recommend using a administrator account. As many features will not be working unless a administrator is provided.

Step 1: Create a new credential

Click on “Add Credentials”

Double-click on “DNS-Name” you can use the DNS-Name or a IP

• Option 1: if you use a IP the domain will be empty
• Option 2: if you use a DNS-Name you also have to provide a domain, do not use FQDN as this will not work

For ex. Host1.Domain.net

• IP or Host: Host1
• Domain: Domain.net

If you use the IP for automation go to Settings ➡️ Security and check: “Allow WinRM SSL with IP-Address”

Also double-click “Username” and Password to change it. The very left Credentials Tab is auto generated.
Your credential should look somethink like these:

Groups: Add a group to the Credentials Store

ServerEngine can also create host groups to deploy the same package or bundle on multiple hosts at the same time.

Step 1: Create a new group

Click on “Add Credentials”

Enter a name for the group, for this ex. we use “Test Group”:

Step 2: Add hosts to a group

Now select “Test Group” in groups:

Select the hosts you want to deploy the same package or bundle to:
In this ex. i just selected a mix of Windows Clients and Servers.

Once added you can see them in the group:

Auto Sync: Active Directory Integration

ServerEngine also supports to sync hosts from Active Directory DNS, well there is one caviat.
You must run ServerEngine as Domainadministrator in order to access “Domain DNS Records” which is used to search for hosts.

Step 1: Provide a username and password

If you want the synced hosts to have credentials auto generated you can provide them before starting the sync.
Meaning you wont have to enter a username and password for every host that was sync to the Credentials Store.
Is is also recommended to select a Domainuser that is Admin the that host or just use a Domainadmin for simplicity.

Now before we start to sync there is a few things to note:

• Sync only works in a Domain Envirement
• Sync only works if ServerEngine was started with a Domainadministrator
• Sync also works if ServerEngine was started directly on a Domaincontroller (Logged in as Administrator)

Step 2: Sync hosts from AD to ServerEngine

Now we let ServerEngine do the magic, click on “Sync from Active Directory” this might take a minute…

Click on “Start Sync”

You should see the loading animation…

Once finished it will disappear and should be able to see the synced host,
if not you do not have the permission required to access Active Directory DNS Record.

We can see a few hosts where found and the username and password has been set automaticly by the username and password provided:
In the very right description tab we can see it was set to “AD-Sync”, also important to note if a host with the same name already exists it will not be overwritten bit skiped instead. Nothing to loose here ;).

Any improvements are very welcome! Let me know 😉
Mail: contact@cforce-it.com

Step 1: Download UltraVNC 1.6.4

Go to the official site: https://uvnc.com/downloads/ultravnc.html

Testet with UltraVNC 1.6.4 (Setup) EXE or MSI (make sure to pick the 64-bit installer).

Step 2: Run the Installer on the target host

1. Run the downloaded .exe or .msi file.
2. When prompted, only choose UltraVNC Server.
3. Select Register UltraVNC Server as a system service if you want it to start automatically with Windows.

Step 3: Configure UltraVNC Server Authentication

1. After installation, open UltraVNC Server from the Start Menu or system tray.
2. Under Authentication, keep “MS Logon” enabled if you want seemles authentication.

Step 4: Enable Encryption (Required)

1. In the Server settings → DSM Plugin, select SecureVNCPlugin64.dsm.
   (Unencrypted VNC is not supported by ServerEngine)

Step 5: Open Firewall Ports

• By default, UltraVNC uses:
  • TCP 5900 → VNC connections
• Make sure these ports are allowed in Windows Firewall or your network firewall.

Step 6: Start & Connect

1. Start UltraVNC Server (if not already running).
2. Enable Use VNC (Remote Support) from ServerEngine.
3. Your target host should be highlited green, click on the host to connect

Note: VNC also support to connect to existing RDP session. You may not be able to connect if the User is not logged in.

If you are lazy just run this PowerShell script: 🙂
(Allows all Domain Admins to connect)

# ===== CONFIGURATION =====
$DownloadURL = "https://uvnc.eu/download/1640/UltraVNC_1640_x64_Setup.exe"
$InstallerPath = "$env:TEMP\UltraVNC_1640_x64_Setup.exe"

$ConfigContent = @"
[ultravnc]
passwd=FB0B44D3653641D2CB
passwd2=FB0B44D3653641D2CB
[admin]
AllowUserSettingsWithPassword=0
FileTransferEnabled=1
FTUserImpersonation=0
BlankMonitorEnabled=1
BlankInputsOnly=0
DefaultScale=1
UseDSMPlugin=1
DSMPlugin=SecureVNCPlugin64.dsm
DSMPluginConfig=SecureVNC;0;0x00104001;
AuthHosts=
primary=1
secondary=0
SocketConnect=1
HTTPConnect=0
AutoPortSelect=0
PortNumber=5900
HTTPPortNumber=5800
InputsEnabled=1
LocalInputsDisabled=0
IdleTimeout=0
EnableJapInput=0
EnableUnicodeInput=1
EnableWin8Helper=0
QuerySetting=2
QueryTimeout=10
QueryDisableTime=1
QueryAccept=0
MaxViewerSetting=0
MaxViewers=128
Collabo=0
Frame=1
Notification=0
OSD=0
NotificationSelection=0
QueryIfNoLogon=1
LockSetting=0
RemoveWallpaper=1
RemoveEffects=0
RemoveFontSmoothing=0
DebugMode=0
Avilog=0
path=C:\Program Files\uvnc bvba\UltraVNC
DebugLevel=0
AllowLoopback=1
UseIpv6=0
LoopbackOnly=0
AllowShutdown=1
AllowProperties=1
AllowInjection=0
AllowEditClients=1
FileTransferTimeout=30
KeepAliveInterval=5
IdleInputTimeout=0
DisableTrayIcon=0
rdpmode=1
noscreensaver=0
Secure=1
MSLogonRequired=1
NewMSLogon=1
ReverseAuthRequired=1
ConnectPriority=1
AuthRequired=1
service_commandline=
accept_reject_mesg=Allow access to your computer?
cloudServer=
cloudEnabled=0
[poll]
TurboMode=1
PollUnderCursor=0
PollForeground=0
PollFullScreen=1
OnlyPollConsole=0
OnlyPollOnEvent=0
MaxCpu2=100
MaxFPS=25
EnableDriver=1
EnableHook=1
EnableVirtual=0
autocapt=1
[admin_auth]
group1=
group2=
group3=
locdom1=0
locdom2=0
locdom3=0
"@
$ACL = @'
allow 0x3 "..\Domain Admins"
'@

# ===== INSTALLATION =====
# 1. Download installer
Invoke-WebRequest -Uri $DownloadURL -OutFile $InstallerPath

# 2. Silent install (Service + Viewer)
Start-Process -FilePath "$env:TEMP\.\UltraVNC_1640_x64_Setup.exe" -ArgumentList "/VERYSILENT /NORESTART /Type=custom /Components=ultravnc_server /Tasks=installservice,startservice " -Wait

New-Item -Path "$env:ProgramData\UltraVNC" -ItemType Directory -Force

# 4. Deploy ultravnc.ini
$ConfigContent | Out-File -FilePath "$env:ProgramData\UltraVNC\ultravnc.ini" -Encoding ASCII -Force

# 5. Allow Grousp NEW-MsLogon
$ACL | Out-File -FilePath "$env:ProgramData\UltraVNC\allow_groups.acl" -Encoding ASCII -Force 2>&1
& "C:\Program Files\uvnc bvba\UltraVNC\MSLogonACL.exe" /i /o $env:ProgramData\UltraVNC\allow_groups.acl *>$null

# 6. Set firewall rule
New-NetFirewallRule -DisplayName "UltraVNC" -Direction Inbound -LocalPort 5900 -Protocol TCP -Action Allow

# ===== VERIFICATION =====
Write-Host "UltraVNC installed to: $InstallDir"
Write-Host "Config file deployed to: $env:ProgramData\UltraVNC\ultravnc.ini"

# Path to winvnc.exe
$winvnc = "C:\Program Files\uvnc bvba\UltraVNC\winvnc.exe"

# Path to Startup folder
$startup = [System.Environment]::GetFolderPath('Startup')

# Create shortcut
$WshShell = New-Object -ComObject WScript.Shell
$Shortcut = $WshShell.CreateShortcut("$startup\UltraVNC.lnk")
$Shortcut.TargetPath = $winvnc
$Shortcut.WorkingDirectory = (Split-Path $winvnc)
$Shortcut.Save()

Start-Process $winvnc

You’re welcome 😎👍

1. WINGET (RECOMMENDED)

• Requirements: WinGet Evirement installed
  • Windows 10 (Install with provided example)
  • Windows 11 (Build-In)
• Advantages:
  • Automatically downloads the latest version
  • Handles updates seamlessly
  • No manual file handling required

Step 1: Browse the WinGet Library

Go to the TAB: App Deployment ➡️ Search App Library

Search for ex. “office” and press ENTER or click on the search icon.
We need the App Id for the deployment with WinGet, in this case it would be “Microsoft.Office” we also
see the Name , Version and Source which can be winget (WinGet Library) or msstore (Microsoft Store).

Select and copy the App Id “Microsoft.Office”

Step 2: Create a new App

Go to the TAB: App Deployment ➡️ Apps

Click on “New App” and then double click on “Please select…” on the Resource TAB

Select “Microsoft Store / WinGet” and click OK

Now double-click on “App ID”

Now paste the App ID and click on OK

Almost ready, for the installation to complete and verify the installation we have to set the “Name” that Windows saves.
ServerEngine uses 2 commands to check if the installation was completed:

1. Get-AppxPackage (Apps)
2. Get-Package (Programs)

Get-AppxPackage -Name "*$appName*" -ErrorAction SilentlyContinue

Get-Package -Name "*$appName*" -ErrorAction SilentlyContinue

Meaning the App Name must match the name that is shown when installed.
On the first deployment we can just try to use “Office” we can adjust it later to make it a better match

Double-click (App Name) and enter “Office” and click OK

Step 3: Create a Bundle and add Apps to it

In order for the deployment to work we have to add the App to a Bundle.
The Bundle is used to deploy multiple Apps at once but you can also just add a single App.

Go to the TAB: App Deployment ➡️ App Bundles

Click on “Create Bundle”

Select a Name for the Bundle, for our test we just use “Office Test”

Now select “Office Test” in Bundles and click on “Add Apps”

Select one or multiple Apps, in this ex. we just select “Office”

Step 4: Deploy your App Bundle

Go to the TAB: App Deployment ➡️ Start Deployment

Click on the Bundle you want to deploy, in this ex. we use “Bundle: Office Test”

Select the host you want to deploy the Bundle to and click on “Assign to Automation”:

Go to the TAB: Activity Dashboard ➡️ Automation

The job will disappear as soon as it is completed unless there was a problem it stays in the Dashboard.
(You can disable automatic cleanup in settings if you like, uncheck “Enable automated resource cleanup”)

Now that the job disappeared, the App/Software should be installed.
We can check what happened in the Logs.

Step 5: Verify Installation

Go to the TAB: Logs

Click on Scoll (Newest logs are always at the bottom):

Now we can finally see the wierd name Office uses 😀

We can verify that by manually running this command on the target host:

(Get-Package -Name "*Office*" -ErrorAction SilentlyContinue).Name

Now you can use a more fitting name like “Office 16 Click-to-Run” as there may be other apps/programs containing “Office”.

2. Download from the Internet

• Requirements: Online resource / Download link
• Advantages:
  • Download from the internet
  • Install .exe, .msi, .msix
  • Unpack .zip and install (Requires .zip in download link url)

Step 1: Create a new App

Go to the TAB: App Deployment ➡️ Apps

Click on “New App” and then double click on “Please select…” on the Resource TAB

Select “Download from the Internet” and click OK

Step 2: Select to download a file or a archive

Now you have 2 options:

• Download File (.exe, .msi, .msix)
• Download Archive (.zip) (Only .zip archives are supported)

1. Download File

Double click on “https://” in the URL TAB

For ex.

Then double-click “<Filename> <ARG>”

ServerEngine requires the filename with suffix: (.exe, .msi or .msix)
In this ex. it would be myfile.exe and then any argument needed for installation for ex. /silent would then be:

myfile.exe /silent

In the case of a archive which we give a exact example for clear understanding

2. Download Archive

Double click on “https://” in the URL TAB

Important to note: If you want to download a archive (.zip) must be in the URL/Download link.
It also must be a direct download link:

Teams is a good ex. as it requires 2 files:

• teamsbootstrapper.exe
• MSTeams-x64.msix

Then double-click “<Filename> <ARG>”

ServerEngine will take care of unpacking and navigating inside the folder, but in this case teamsbootstrapper.exe requires the full path.

Now you need to know where its download and how the folder is named after unpacking.

1. All files are download to $env:temp
2. Archived are unpacked with the same name: MSTeams-x64.zip -> Folder name : MSTeams-x64

the command we would look like this:

.\teamsbootstrapper.exe -p -o "$env:temp\MSTeams-x64\MSTeams-x64.msix"

Think of it as you already are in the Folder where your .zip was unpacked in 😉

Note: .exe dont need any extra but for .msi you would use:

msiexec.exe /i appname.msi /qn /norestart

and for .msix you would use:

Add-AppxPackage -Path appname.msix -ForceApplicationShutdown -ForceUpdateFromAnyVersion

Now we name the App, “Teams” should be fine

Step 3: Create a Bundle and add Apps to it

In order for the deployment to work we have to add the App to a Bundle.
The Bundle is used to deploy multiple Apps at once but you can also just add a single App.

Go to the TAB: App Deployment ➡️ App Bundles

Click on “Create Bundle”

Select a Name for the Bundle, for our test we just use “Teams Test”

Now select “Teams Test” in Bundles and click on “Add Apps”

Select one or multiple Apps, in this ex. we just select “Teams”

Step 4: Deploy your App Bundle

Go to the TAB: App Deployment ➡️ Start Deployment

Click on the Bundle you want to deploy, in this ex. we use “Bundle: Teams Test”

Select the host you want to deploy the Bundle to and click on “Assign to Automation”:

Go to the TAB: Activity Dashboard ➡️ Automation

Step 5: Verify Installation

Go to the TAB: Logs

Click on Scoll (Newest logs are always at the bottom):

Now we can see the app name which now we can use to properly verify the installation

3. Share

What if i have to deploy many hosts and the files are to large to deploy everything over the internet?
That’s what this option is for: Deploy App/Software using a SMB/NFS Share or Local location

• Requirements: A localy accessible share (Read permission are required)
• Advantages:
  • Completly offline no internet required
  • Install .exe, .msi, .msix

Step 1: Create a new App

Go to the TAB: App Deployment ➡️ Apps

Click on “New App” and then double click on “Please select…” on the Resource TAB

Step 2: Deploy from a network share

Select “Network Share (SMB/NFS)” and click OK

Double-click “\\server\share”

Now enter your the full path of your App where the target host has read access it can also be a network drive

If the host does not have the network drive mapped it will fail so its just better to use the full path to the share, it’s your choice 😉

• Option 1: “X:\IT\putty-64bit-0.78-installer.msi”
• Option 2 (Recommended): “\\ad-ca-fs\apps\IT\putty-64bit-0.78-installer.msi”

Then double-click “<Filename> <ARG>”

Note: .exe dont need any extra but for .msi you would use:

msiexec.exe /i .\appname.msi /qn /norestart

and for .msix you would use:

Add-AppxPackage -Path .\appname.msix -ForceApplicationShutdown -ForceUpdateFromAnyVersion

Meaning in our ex. it would then be:

msiexec.exe /i putty-64bit-0.78-installer.msi /qn /norestart

Let’ use “putty” for the name detection

Step 3: Create a Bundle and add Apps to it

In order for the deployment to work we have to add the App to a Bundle.
The Bundle is used to deploy multiple Apps at once but you can also just add a single App.

Go to the TAB: App Deployment ➡️ App Bundles

Click on “Create Bundle”

Select a Name for the Bundle, for our test we just use “Putty Test”

Now select “Putty Test” in Bundles and click on “Add Apps”

Select one or multiple Apps, in this ex. we just select “Putty”

Step 4: Deploy your App Bundle

Go to the TAB: App Deployment ➡️ Start Deployment

Click on the Bundle you want to deploy, in this ex. we use “Bundle: Teams Test”

Select the host you want to deploy the Bundle to and click on “Assign to Automation”:

Go to the TAB: Activity Dashboard ➡️ Automation

Step 5: Verify Installation

Go to the TAB: Logs

Click on Scoll (Newest logs are always at the bottom):

Now we can see the app name which now we can use to properly verify the installation

Thats it! If anything is still unclear, feel free to reach out!
Mail: contact@cforce-it.com

Prepare Windows for API Calls

Allow your selected port and IP trough your Windows firewall
Note: This is auto-configured since ServerEngine v.3.2.2 and up.

Call API from Windows

Prepare PowerShell Script

Username is always admin, replace $password with your own ServerEngine credentials.

$username = “admin”
$password = “cforce-it.com”

Replace with a existing PKG you want to assign to the automation.

Time = “17:28” (Format 24h)
Date = “2024/11/04”
RepeatInterval = “One time”
Host = “AD-CA-FS.CForce-IT.network”
Package = “Showcase_Monitoring”
Status = “Enabled”

Intervals

Replace “http://localhost:5000/” with your own ServerEngine IP-Address and port.
or https://server-name:5555/ using Reverse Proxy -> https://serverengine.co/docs/api-https-reverse-proxy/

Call using PowerShell

# Define the username and password
$username = "admin"
$password = "cforce-it.com"

# Encode the credentials
$pair = $username+":"+$password
$encodedCredentials = [Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes($pair))

# Create the headers
$headers = @{
    "Content-Type"  = "application/json"
    "Authorization" = "Basic $encodedCredentials"
}

# Create the body
$body = @{
    Time           = "17:28"
    Date           = "2024/11/04"
    RepeatInterval = "One time"
    Host           = "AD-CA-FS.CForce-IT.network"
    Package        = "Showcase_Monitoring"
    Status         = "Enabled"
} | ConvertTo-Json

# Make the POST request
$response = Invoke-WebRequest -Uri http://localhost:5000/ -Method POST -Headers $headers -Body $body

# Output the response content
$response.Content

Call API from Linux

Prepare Bash Script

Replace user -u with your own ServerEngine credentials if changed.

-u admin:cforce-it.com (username:password)

Replace “http://localhost:5000/” with your own ServerEngine IP-Address and port.

Replace with a existing PKG you want to assign to the automation.

“Time”: “12:01”, (Format 24h)
“Date”: “2024/08/05”,
“RepeatInterval”: “Repeat: never”,
“Host”: “WIN-SRV-AUS.CForce-IT.network”,
“Package”: “Server Deployment”,
“Status”: “Enabled”

Intervals

Check CURL

CURL is usually already on most Linux Destributions if not install it with:

Ubuntu/Debian-based systems:

sudo apt install curl -y

Red Hat-based systems (RHEL/CentOS/AlmaLinux)

sudo yum install curl -y

Call using CURL

curl -u admin:cforce-it.com -X POST http://localhost:5000/ \
     -H "Content-Type: application/json" \
     -d '{
           "Time": "12:01",
           "Date": "2024/08/05",
           "RepeatInterval": "One time",
           "Host": "WIN-SRV-AUS.CForce-IT.network",
           "Package": "Server Deployment",
           "Status": "Enabled"
         }'

Incorporate API Calls into PKG

Example: VM Deployment with ESXI and Windows Server 2025 configuration after VM creation.

# Define the username and password
$username = "admin"
$password = "cforce-it.com"

# Encode the credentials
$pair = $username+":"+$password
$encodedCredentials = [Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes($pair))

# Create the headers
$headers = @{
    "Content-Type"  = "application/json"
    "Authorization" = "Basic $encodedCredentials"
}

# Create the body
$body = @{
    Time           = "18:00"
    Date           = "2024/12/01"
    RepeatInterval = "One time"
    Host           = "WINSRV2025_TEMP.CForce-IT.network"
    Package        = "Configure_WINSRV2025"
    Status         = "Enabled"
} | ConvertTo-Json

# Make the POST request
$response = Invoke-WebRequest -Uri http://localhost:5000/ -Method POST -Headers $headers -Body $body

# Output the response content
$response.Content

Advanced: List jobs from API

Step 1: Close ServerEngine

If ServerEngine is running job tasks may disappear before requesting the list.

Step 2: Call API with GET

Note: ServerEngine checks every 15 seconds for new job tasks and retrieves them.
After retrieval, the tasks are assigned to the “Job Planner” and deleted from the API using the Job Task ID.
If ServerEngine is not running jobs stay in the API untill retrieval.

To get the list of job tasks you can manually call Method “GET” (replace Uri with own server and port).
Note: In this example we are using HTTPS with the revery proxy on port 5555

$response = $null
$username = "admin" #user must be admin
$password = "cforce-it.com" #default password
$pair = $username+":"+$password
$encodedCredentials = [Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes($pair))
$headers = @{ Authorization = "Basic $encodedCredentials" }
$response = Invoke-WebRequest -Uri "https://servername.domain.network:5555/" -Method GET -Headers $headers
$response.Content

Advanced: Delete jobs from API with ID

If ServerEngine crashes duo to malformed API job task, you can manually delete the task using the job task ID.

Step 1: Get job task list

Use methode GET above.

Copy the ID:

{
    "id":  "2285fe93-e7f6-4fe4-8cf8-bdcedf0de424",
    "Time":  "07:42",
    "RepeatInterval":  "One time",
    "Host":  "(This Computer)",
    "Status":  "Enabled",
    "Package":  "Example_01_WRITE-LOG",
    "Date":  "2025/09/06",
    "jobParams":  {
                      "custom1":  "TextValueExample1",
                      "custom2":  "TextValueExample2",
                      "custom3":  "TextValueExample3"
                  }
}

Step 2: Delete job task

To delete a job we can use the methode DELETE

Delete job task using the ID:

# Define the username and password
$username = "admin" #user must be admin
$password = "cforce-it.com" #default password
# Encode the credentials
$pair = $username+":"+$password
$encodedCredentials = [Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes($pair))
# Create the headers
$headers = @{"Authorization" = "Basic $encodedCredentials"}
# Define the job ID to delete
$jobIdToDelete = "2285fe93-e7f6-4fe4-8cf8-bdcedf0de424"
# Make the DELETE request
$response = Invoke-WebRequest -Uri "https://servername.domain.network:5555/?id=$jobIdToDelete" -Method Delete -Headers $headers
# Output the response content
$response.Content

You should see confirmation for deletion:

{
    "status":  "Job task removed successfully"
}

Choose IIS if you want tight Windows integration or Nginx for high performance. Here’s how to set one up on Windows:

Option 1: Using IIS as Reverse Proxy (Recommended for Windows)

Step 1: Install IIS and required modules

You need 2 IIS modules: 1. URL Rewrite 2. Application Request Routing (ARR).
If you are not seeing them in IIS restart IIS or download and install the modules manually.

# Install IIS
Enable-WindowsOptionalFeature -Online -FeatureName IIS-WebServerRole
Enable-WindowsOptionalFeature -Online -FeatureName IIS-WebServer
Enable-WindowsOptionalFeature -Online -FeatureName IIS-ApplicationDevelopment

# Install URL Rewrite Module (required for reverse proxy)
Invoke-WebRequest -Uri "https://download.microsoft.com/download/1/2/8/128E2E22-C1B9-44A4-BE2A-5859ED1D4592/rewrite_amd64_en-US.msi" -OutFile rewrite.msi
Start-Process msiexec.exe -ArgumentList '/i rewrite.msi /quiet' -Wait
Invoke-WebRequest -Uri "https://download.microsoft.com/download/E/9/8/E9849D6A-020E-47E4-9FD0-A023E99B54EB/requestRouter_amd64.msi" -OutFile router.msi
Start-Process msiexec.exe -ArgumentList '/i router.msi /quiet' -Wait
Remove-Item rewrite.msi
Remove-Item router.msi

Step 2: Create new Website

1. In IIS, add new Website
2. Add HTTPS binding with your valid certificate

Step 3: Configure Reverse Proxy in IIS

1. Open IIS Manager (inetmgr)
2. Open ServerEngine API website
3. Open “URL Rewrite” feature
4. Add a new Reverse Proxy rule:

Run this PowerShell script to allow API Ports in your Firewall settings:

# Define all ports to check/create
$portsToConfigure = @(
    @{Port=5555; Name="Allow ServerEngine API (5555)"}
)

foreach ($portConfig in $portsToConfigure) {
    $existingRule = Get-NetFirewallRule -DisplayName $portConfig.Name -ErrorAction SilentlyContinue

    if (-not $existingRule) {
        try {
            New-NetFirewallRule -DisplayName $portConfig.Name `
                               -Direction Inbound `
                               -Protocol TCP `
                               -LocalPort $portConfig.Port `
                               -Action Allow `
                               -Profile Any `
                               -Enabled True
            
            Write-Host "Created firewall rule for port $($portConfig.Port)"
        }
        catch {
            Write-Host "Error creating rule for port $($portConfig.Port): $_" -ForegroundColor Red
        }
    }
    else {
        Write-Host "Rule '$($portConfig.Name)' already exists" -ForegroundColor Yellow
        
        # Ensure existing rule is enabled
        if ($existingRule.Enabled -ne "True") {
            Set-NetFirewallRule -DisplayName $portConfig.Name -Enabled True
            Write-Host "Enabled existing rule for port $($portConfig.Port)"
        }
    }
}

Now access your API via https://server-name.domain.network:5555/

What if you cant access your API via https?

Sometimes ARR wont enable the reverse proxy routing, so you have to enable it. In IIS go to server then double-click “Application Request Routing”:

Click on “Server Proxy Settings”

And make sure Proxy is enabled 🙂