Services
The Services page in the Tagnet Admin Console shows the state of the Tagnet Windows service and offers Start, Stop, and Restart, so you can bounce the service without opening services.msc. Use it after editing a setting by hand, when a reader connection appears hung, or when Diagnostics reports the service as stopped.
Every other restart the console performs is a side effect of a save: Save and restart on Database Setup, App Settings, and Web Server Setup, or a backup on Database Maintenance. This page is for restarting on its own.
What the page shows
One row per Tagnet service. Today there is one, Tagnet System Service (the Windows service name is TagNet). Each row shows the current state and three buttons:
| State | Start | Stop | Restart | Meaning |
|---|---|---|---|---|
| Running | Yes | Yes | The service is up and serving. | |
| Stopped | Yes | Nothing is listening. Users cannot sign in and readers cannot deliver reads. | ||
| Starting / Stopping | A change is in progress. Wait a moment and click Refresh. | |||
| Paused / Unknown | A state this page does not manage. Check the service in services.msc. | |||
| Not installed | The service is not registered on this computer. The console can still edit configuration, but there is nothing to run it. The installer registers the service. |
The state is read when you open the page and again after every action. Refresh re-reads it without changing anything.
Starting, stopping, and restarting
- Open the Admin Console and click Services.
- Click Start, Stop, or Restart on the row.
- Stop and Restart ask you to confirm, because every signed-in user is disconnected and readers cannot deliver reads until the service is running again. Start does not ask.
- While the action runs the page shows what it is waiting on and all buttons are disabled. A stop waits up to 60 seconds for the service to reach Stopped; a start waits up to 60 seconds for Running. A restart is both in sequence.
- The result panel reports the outcome, success or failure, and the row shows the new state.
Signed-in users have to reload the page once the service is running again. What a stop does to scan events and reads is described in Reads while the service is stopped.
Reads while the service is stopped
Stopping the service interrupts RFID processing for a short time. Plan for three things, whether the stop is a restart from this page, an upgrade, or a recovery restart.
- Open scan windows are saved. A single tag or multi tag passage still open when the service stops is saved as a scan event with the closed reason Service Stop, so the pass is not lost. If it was cut off, it appears as two consecutive scan events, one before and one after the restart. See When the Service Stops.
- Workflows that did not finish are caught up. Scan events whose workflows had not run are run at the next startup if they are recent enough, or marked Skipped otherwise. The Workflows / CatchUp policy controls this.
- Readers cannot deliver while the service is down. Reads a reader sends while Tagnet is stopped are refused. Readers that buffer and retry, such as the Impinj R700, which retries batches that do not get a success response (see Impinj R700 Setup), send them after the restart, so a short restart usually loses nothing from the reader. Tagnet processes those reads as new reads and runs workflows normally. The catch-up policy does not apply to them, and Tagnet does not yet filter stale buffered reads.
If your site only acts on current reads (real-time location, a warning light), turn off retry buffering on the reader, so a restart does not replay old reads into your workflows. If every read must be acted on (receiving, a dock portal), leave buffering on and keep Workflows / CatchUp enabled. For planned maintenance at a busy portal, pick a time when no load is passing so a pass is not split across the restart.
Startup type and recovery
The installer registers the service as Automatic, so Windows starts it with the other automatic services at boot, and sets recovery actions on it. If the service exits unexpectedly, for example because a database upgrade failed, Windows restarts it after 60 seconds, and once more after another 60 seconds if that attempt fails too. A third failure leaves it stopped, so a fault that is not going to clear on its own does not loop forever. The failure count resets after a day without failures, and at every boot. Each attempt is in the service log, and the System event log records the restarts (event 7034 for the exit, 7036 for the restart).
A database that is not available when Tagnet starts does not fail the start at all. Whether the database server is stopped, rebooting, being patched or cut off by the network, a domain controller needed for Windows authentication is unavailable, or SQL Server is up but still recovering the Tagnet database (common when both start together on the same machine) or has it offline for maintenance, the service waits for it, however long that takes. It logs a warning each time it checks, backing off from every few seconds to about every 30 seconds (longer while each connection attempt runs to its timeout): Database server ... cannot be reached while the server does not answer, Could not sign in to database server ... while it answers but the sign-in cannot complete (with Windows authentication, usually because no domain controller can be reached: the message then ends Cannot generate SSPI context), and Database '...' exists but is not yet available while the server answers but the database is not open. It starts as soon as the database opens, and nobody has to sign in and start it. One exception: when the service runs as a gMSA and the whole server restarts while no domain controller answers, Windows cannot start the service at all; see If a domain controller is not available at startup.
While it waits, the service shows as Running but Tagnet does not answer yet: the web pages do not load and readers cannot deliver reads, the same as while the service is stopped (see the reader buffering note above). A stop during the wait takes effect as soon as any connection attempt in progress ends, within the connection timeout. Once the database has been unreachable for five minutes, Tagnet emails the people its Critical alerts reach; see When the database is unavailable.
This page shows only the state. The startup type is the Startup Type column in services.msc, and the restarts are on the Recovery tab of the service's properties; sc.exe qc TagNet and sc.exe qfailure TagNet show the same from a command prompt or PowerShell (type sc.exe, not sc: in Windows PowerShell sc is an alias for Set-Content and silently writes a file instead). A service that is Stopped here after the automatic restarts needs the cause fixed first (the log says why each attempt failed), then Start. A stop from this page, from services.msc, or by the installer is a normal stop and is never retried. The recovery actions are re-applied by every upgrade, so a change made on the Recovery tab does not survive one.
If your database server is slow to start
Nothing needs changing: Tagnet waits for a slow database server on its own (see above) and starts the moment the database opens. That is why it is not set to Automatic (Delayed Start), which would hold it back about two minutes on every boot, including the ones where the database was ready all along, while readers wait to deliver the reads they buffered.
If you want a quieter log on a server whose database is always slow to come up, you can still set Automatic (Delayed Start) yourself on the General tab of the service's properties in services.msc. The setting survives Tagnet upgrades, because the installer sets the service's start type but not the delayed flag, which Windows stores separately.
Administrator rights
Starting and stopping a Windows service needs administrator rights. Without them the page still shows the state, with the buttons disabled and a Restart as administrator prompt at the top. Click it, accept the User Account Control prompt, and the console reopens on this page.
What is recorded
Every attempted action appends one line to logs\admin-console.log under the Tagnet data folder (C:\ProgramData\Stratum Global\Tagnet\logs by default), whether it succeeded or not:
2026-09-15T14:30:05.0000000Z [CORP\jsmith] ServiceRestart Success: TagNet. Service started.
The line names the time (UTC), who was signed in to Windows, the action (ServiceStart, ServiceStop, or ServiceRestart), the service, the outcome, and the message the page showed. Service changes made from this page are not written to the Tagnet Security Events log: the service is usually the thing that is down at the time, and the file is the record.
Troubleshooting
"Service did not reach Stopped within 60 seconds." The service is draining connections or a request is stuck. It usually finishes on its own shortly after; click Refresh until the row shows Stopped, then start it. If it stays in Stopping, check the Tagnet log in the logs folder for what it is waiting on.
"Service did not reach Running within 60 seconds." The service started but could not finish coming up, most often because the database is unreachable (a SQL Server that is not running yet, or a connection string that works for you but not for the service account). The Tagnet log names the cause. The service may still reach Running after the console stopped waiting; Refresh shows the current state.
The service is Stopped again a few minutes after a start. Its startup failed, Windows made its automatic restarts (see Startup type and recovery), and they failed as well. The Tagnet log has one failure per attempt; fix the cause it names, then Start.
"Access denied." The console is not running as administrator. Use Restart as administrator at the top of the page.
"Service is running but refuses stop requests." The service reported that it cannot be stopped, which should not happen for Tagnet. Stop it from services.msc or with net stop TagNet from an elevated prompt, then start it here.
The row says the service is not installed. The Tagnet service is registered by the installer. Repair or re-run the Tagnet installer on this computer.