SINT Service Monitor — Deployment
=================================

>> ALREADY INSTALLED ON THIS MACHINE? Do not follow these notes.
>> Read UPGRADE.txt instead, and run Upgrade-Service.bat.

This folder is self-contained: the .NET 8 runtime is bundled, so target machines
do NOT need any .NET runtime installed. Copy the WHOLE folder to each machine
(e.g. C:\Program Files\SINT\ServiceMonitor). Keep the UI and the Service together
in the same folder — the UI installs the service from its own directory.

BEFORE ROLLOUT (optional but recommended)
------------------------------------------
Edit smtp-defaults.json with your mail relay details. On first run these are
imported automatically so techs don't have to type SMTP settings on every machine.
Security options: None | StartTls | SslOnConnect. Delete smtp-defaults.json after
deployment if you don't want the plain-text template left on the machine.

INSTALL (run as Administrator)
------------------------------
Option A — GUI:
  1. Right-click ServiceMonitor.UI.exe -> Run as administrator.
  2. Tick the services to monitor, click "Save Monitoring Selection".
  3. Click "Settings..." to set the Site name and review SMTP, then
     "Send Test Email". The Site name identifies this machine in every
     alert email and in the Crash History window — set it to the customer
     site name. Left blank, the Windows machine name is used.
  4. Click "Install" (installs + starts the monitor service).

Option B — script:
  Right-click Install-Service.bat -> Run as administrator.
  Then run ServiceMonitor.UI.exe (as admin) to choose services and SMTP settings.

UNINSTALL (run as Administrator)
--------------------------------
Right-click Uninstall-Service.bat -> Run as administrator.

WHERE THINGS LIVE
-----------------
Config & state:  C:\ProgramData\SINT\ServiceMonitor\config.json / state.json
Logs:            C:\ProgramData\SINT\ServiceMonitor\logs\   (also Windows Event Log,
                 Application source "SINT Service Monitor")

BEHAVIOUR
---------
Crashes within 60 minutes of each other escalate up a ladder:

- 1st crash -> restarted after 10 seconds, then a "crashed and was restarted,
  no action required" email.
- 2nd crash -> left stopped for 20 minutes and then restarted. A "restart
  delayed, will be restarted at HH:mm" email goes out straight away, and a
  "restarted" email once it comes back up.
- 3rd crash -> NOT restarted + "please investigate" email. Left stopped until
  someone starts it again; the UI shows NEEDS ATTENTION.
- A restart that fails counts as that step being used up: a failed 1st restart
  moves straight to the 20-minute retry, and a failed 2nd restart means
  "please investigate".
- Starting the service again by hand clears the crash history, so the next
  crash is treated as a fresh 1st crash.
- Running cleanly for a full 60 minutes also clears the crash count.
- Service stopped manually/cleanly -> left alone (no restart, no email).

A crash is distinguished from a manual stop by Service Control Manager events
7031/7032/7034 in the System event log.

CHECKING A SITE'S HISTORY
-------------------------
In the UI, click "Crash History...". It shows, per service, how many crashes
there were in the last 24 hours / 7 days / 30 days, how many restarts worked,
how many failed, and how many times a human was needed — plus a plain-language
assessment such as "Ongoing issue this week". Underneath is the raw event trail.
"Copy Summary" puts a plain-text report on the clipboard to paste into a ticket
or an email.

The underlying file is events\service-events.log (see WHERE THINGS LIVE). It
survives restarts, upgrades and reboots.

WHICH VERSION IS THIS MACHINE RUNNING?
--------------------------------------
In the UI, click "About". It shows the version of the UI and of the monitor
service separately, when they were installed, the Site name and the folders in
use. If the UI and the service report different versions, an upgrade did not
finish — re-run Upgrade-Service.bat. "Copy Details" copies the lot for a ticket.

The 60 / 10 / 20 figures are CrashWindowMinutes, FirstRestartDelaySeconds and
SecondRestartDelayMinutes in config.json. They are optional — leave them out to
get these defaults. Pending restarts are stored in state.json, so a 20-minute
wait survives a reboot or a restart of the monitor service itself.
