About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not lab validation. Check the stated versions and your own requirements before making changes.
A common step when a small business moves to a hosted server is to stop relying on someone being signed in. On the old office server, an integration program, a bank-file importer or a nightly export tool ran on the desktop of a signed-in account, sometimes for years. On the new server, someone turns it into a Windows service so it starts by itself. Then it stops working: it hangs, cannot find its files, or reports that a drive does not exist.
The reason is that a Windows service runs in a different world from a signed-in user. Since Windows Vista and Windows Server 2008, services run in their own session, separated from the sessions people sign in to; administrators usually call this session 0 isolation. A program written for the desktop expects things that are simply not there.
Why it matters
When a desktop program fails as a service, it usually fails silently. Nobody sees its error dialog, because nobody can see it at all. A nightly import can stop for days before someone notices that orders or payments are missing.
The fix is rarely difficult, but it depends on understanding which of four differences is the cause: the screen, the drives, the profile or the credentials.
How it works
1. A service has no screen anyone can see
Microsoft's service documentation is blunt: Services cannot directly interact with a user as of Windows Vista. A desktop program running as a service can still draw a window, but no signed-in user will see it.
That matters most when the program shows a dialog box and waits. A licence reminder, a confirmation prompt, an update notice or an error message will sit on an invisible screen, and the program will wait for a click that never comes. To everyone else, the service just looks hung.
Microsoft also warns against the old workaround of letting powerful services show windows on the user's desktop: Services running in an elevated security context, such as the LocalSystem account, should not create a window on the interactive desktop because any other application that is running on the interactive desktop can interact with this window.
2. Mapped drive letters belong to a sign-in, not to the server
Many older programs are configured with paths such as S:\Imports. That drive letter was mapped when a user signed in. Microsoft explains why a service cannot see it: Drive letters are not global to the system. Each logon session receives its own set of drive letters from A to Z. And further: a service (or any process running within its own logon session) cannot access the drive letters that were established within a different logon session.
The answer is to use the full network path instead. Microsoft's guidance is that a service that needs a remote resource should use the Universal Naming Convention (UNC) name to access the resource. So S:\Imports becomes something like \\fileserver\shared\Imports. Microsoft also advises against mapping drives from inside a service at run time, noting that a service should not directly access local or network resources through mapped drive letters, nor should it call the net use command to map drive letters at run time.
3. The user profile depends on the configured account
Desktop programs often keep settings in the signed-in user's part of the registry or profile folder: the last import path, a database connection, a licence key. As a service, it uses the configured service account, which may be the same named user or a different identity. Check that identity first; the profile may differ, but a different account is not an inevitable consequence of running as a service.
For a service running as a named user account, Microsoft notes that The service control manager (SCM) automatically loads the user profile. That is the configured account's profile; it can be the same named account used during setup. Even then, the service gets a separate logon session, so it does not inherit drive mappings from that user's interactive sign-in. For the built-in LocalSystem account, Microsoft says The registry key HKEY_CURRENT_USER is associated with the default user, not the current user. Do not assume settings saved in an administrator's profile will exist for LocalSystem; verify where the application reads its configuration in the final service context.
4. Network access uses the service account's identity
A program running on someone's desktop reaches file shares and databases with that person's credentials. As a service it uses the configured service account's identity, which may or may not be that same user. For LocalSystem, Microsoft says The service presents the computer's credentials to remote servers. Virtual accounts, the default for many Microsoft services, work the same way: Services that run as virtual accounts access network resources by using the credentials of the computer account.
So a share that the user could open may refuse the service, unless the share grants access to the server's computer account or to a service account created for the purpose.
What to choose and why
First, ask whether the program supports running as a service
Check the vendor's documentation. Many business applications ship their own service or a scheduled-task mode for exactly this reason. If the vendor says the program must run in a signed-in session, believe them, and choose a supported option rather than wrapping it in a service.
Choose an account deliberately
| Account type | Network identity | Password handling | Good for |
|---|---|---|---|
| LocalSystem | Computer account | None | Rarely the right choice for business programs; Microsoft describes its privileges on the local computer as extensive |
| LocalService / NetworkService | Anonymous / computer account | None | Services that need little local access |
| Virtual account | Computer account | Automatic | Single-server services that need only the computer's network identity |
| Group Managed Service Account | Its own domain identity | Automatic, managed by the domain | Services that need their own permissions on shares or databases, or run on several servers |
| Ordinary domain user | That user | Manual; must be rotated | Only when the program cannot use a managed account |
Microsoft's LocalSystem page notes that it has extensive privileges on the local computer, and acts as the computer on the network. It also advises: If your service does not need these privileges, and it is not an interactive service, consider using the LocalService account or the NetworkService account
Group Managed Service Accounts reduce the risk of outages caused by manually managed passwords expiring or changing without the service configuration being updated. Microsoft describes them as managed domain accounts that provide automatic password management and simplified SPN management. On Windows Server 2025 there is also a newer type, the delegated Managed Service Account. Not every desktop program works with managed accounts; test first.
Remove every interactive step
Where the vendor supports it and local policy permits, a desktop rehearsal under an ordinary test account can reveal first-run wizards, licence reminders, update prompts and error dialogs. Remove those prompts through supported settings, without bypassing licensing. That rehearsal only discovers prompts; it does not validate service operation, and interactive RunAs is not the test method for virtual accounts or group Managed Service Accounts, whose credentials Windows manages.
For the decisive test, install the vendor-supported service in an isolated lab under the final supported account type and permissions. Block live business integrations, use synthetic or sanitised test inputs and dedicated test output locations, sign users out, then start or restart the test server/service through its supported management path. Verify logs and completed import/export results, not merely a Running status. Check behaviour when a dependency is unavailable through a controlled lab scenario. No such lab test was performed for this article. If unattended operation still requires a prompt, use a supported alternative rather than deploying the wrapper.
Replace drive letters and per-user settings
- Replace every mapped drive letter with a UNC path.
- Move settings from the user's profile to a configuration file or machine-wide setting, if the program allows it.
- Grant the service account, or the computer account, only the share and database permissions the program needs.
Make failures visible
A program that used to show an error on someone's screen now needs another way to report problems. Check whether it writes a log file or Windows event log entries, and make sure someone is alerted when the job does not complete. A missing import is a business problem long before it is an IT problem.
When a scheduled task is the better fit
For a job that runs at set times rather than continuously, Task Scheduler is often simpler than a service. When configured to run whether the user is signed in or not, it must work unattended. A task can use the same user identity as a desktop run, but its configured security context and logon type control how it runs. Do not assume it inherits the interactive session's drive mappings or environment. Test the actual task configuration, permissions, profile-dependent settings and network access with users signed out, using isolated test inputs and destinations.
Risks and limits
- "Session 0" is the common name for the services session, not a setting. Nothing can be switched off to give services a visible desktop on current Windows versions.
- Running a program as LocalSystem to "fix" access problems gives it, and anyone who can influence it, very wide control of the server. Microsoft warns, for example, that if such a service opens a command window and runs a batch file, a user could press Ctrl+C and gain a command window with LocalSystem permissions.
- Some third-party tools wrap any program as a service. They do not remove session isolation; the program still cannot show dialogs or see mapped drives.
- Managed service account support depends on the program and on Active Directory. Group Managed Service Accounts need a domain; delegated Managed Service Accounts need Windows Server 2025.
- No commands are given. Service accounts are set in the service's properties or by the vendor's installer. Test on a non-production server first.
Sources
Opened 14 November 2026.
- Microsoft Learn: Interactive Services, updated 2025-04-15.
- Microsoft Learn: Services and Redirected Drives, updated 2025-03-11.
- Microsoft Learn: Service User Accounts, updated 2025-04-15.
- Microsoft Learn: LocalSystem Account, updated 2025-04-15.
- Microsoft Learn: Security Contexts for Tasks, configured task identity and logon type, displayed date 2020-02-20.
- Microsoft Learn: Service Accounts in Windows Server, dated 2026-09-14 (applies to Windows Server 2016 to 2025).
Related service: Managed support.
Related future topics
- Group Managed Service Accounts for business application services.
- Monitoring scheduled imports and exports so a missed run is noticed.
- Moving a program's settings from the user profile to machine-wide configuration.
Learning notes
- Services run separately from signed-in users and cannot show anyone a window.
- A dialog box waiting for a click makes a service look hung.
- Mapped drive letters belong to one sign-in; services should use full network paths.
- A service sees its own account's profile and uses that account's network identity.
- Prefer a managed service account over LocalSystem or an ordinary user with a password.
This article was originally published on .