Per-user services in Windows 10 and Windows Server

Applies to: Windows 10, Windows Server

Per-user services are services that are created when a user signs into Windows or Windows Server and are stopped and deleted when that user signs out. These services run in the security context of the user account — this provides better resource management than the previous approach of running these kinds of services in Explorer, associated with a preconfigured account, or as tasks.

Per-user services are only in available in Windows Server if you have installed the Desktop Experience. If you are running a Server Core or Nano Server installation, you won’t see these services.

You can set the template service’s Startup Type to Disabled to create per-user services in a stopped and disabled state.

Carefully test any changes to the template service’s Startup Type before deploying to a production environment.

Use the following information to understand per-user services, change the template service Startup Type, and manage per-user services through Group Policy and security templates. For more information about disabling system services for Windows Server, see Guidance on disabling system services on Windows Server with Desktop Experience.

Per-user services

The following table lists per-user services and when they were added to Windows 10 and Windows Server with the Desktop Experience. The template services are located in the registry at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services.

Before you disable any of these services, review the Description column in this table to understand the implications, including dependent apps that will no longer work correctly.

Windows version	Key name	Display name	Default start type	Dependencies	Description
1803	BcastDVRUserService	GameDVR and Broadcast User Service	Manual	Used for Game Recordings and Live Broadcasts
1803	BluetoothUserService	Bluetooth User Support Service	Manual	Supports proper functionality of Bluetooth features relevant to each user session
1803	CaptureService	CaptureService	Manual	OneCore Capture Service
1607	CDPUserSvc	CDPUserSvc	Auto	— Network Connection Broker — Remote Procedure Call (RPC) — TCP/IP Protocol Driver	Used for Connected Devices Platform scenarios
1803	DevicePickerUserSvc	DevicePicker	Manual	Device Picker
1703	DevicesFlowUserSvc	DevicesFlow	Manual	Device Discovery and Connecting
1703	MessagingService	MessagingService	Manual	Service supporting text messaging and related functionality
1607	OneSyncSvc	Sync Host	Auto (delayed)	Synchronizes mail, contacts, calendar, and other user data. Mail and other applications dependent on this service don’t work correctly when this service is not running.
1607	PimIndexMaintenanceSvc	Contact Data	Manual	UnistoreSvc	Indexes contact data for fast contact searching. If you stop or disable this service, search results might not display all contacts.
1709	PrintWorkflowUserSvc	PrintWorkflow	Manual	Print Workflow
1607	UnistoreSvc	User Data Storage	Manual	Handles storage of structured user data, including contact info, calendars, and messages. If you stop or disable this service, apps that use this data might not work correctly.
1607	UserDataSvc	User Data Access	Manual	UnistoreSvc	Provides apps access to structured user data, including contact info, calendars, and messages. If you stop or disable this service, apps that use this data might not work correctly.
1607	WpnUserService	Windows Push Notifications User Service	Manual	Hosts Windows notification platform, which provides support for local and push notifications. Supported notifications are tile, toast, and raw.

Disable per-user services

The template service isn’t displayed in the Services console (services.msc) so you need to edit the registry directly, either with Group Policy or a scripted solution, to disable a per-user service.

Disabling a per-user service simply means that it is created in a stopped and disabled state. When the user signs out, the per-user service is removed.

You can’t manage all of the per-user service templates services using normal Group Policy management methods. Because the per-user services aren’t displayed in the Services management console, they’re also not displayed in the Group Policy Services policy editor UI.

Additionally, there are four template services that can’t be managed with a security template:

• PimIndexMaintenanceSvc
• UnistoreSvc
• UserDataSvc
• WpnUserService

In light of these restrictions, you can use the following methods to manage per-user services template services:

• A combination of a security template and a script or Group Policy preferences registry policy
• Group Policy preferences for all of the services
• A script for all of the services

Manage template services using a security template

You can manage the CDPUserSvc and OneSyncSvc per-user services with a security template. See Administer security policy settings for more information.

Manage template services using Group Policy preferences

If a per-user service can’t be disabled using a the security template, you can disable it by using Group Policy preferences.

On a Windows Server domain controller or Windows 10 PC that has the Remote Server Administration Tools (RSAT) installed, click Start, type GPMC.MSC, and then press Enter to open the Group Policy Management Console.

Create a new Group Policy Object (GPO) or use an existing GPO.

Right-click the GPO and click Edit to launch the Group Policy Object Editor.

Depending on how you want to target the Group Policy, under Computer configuration or User configuration browse to Preferences\Windows Settings\Registry.

Right-click Registry > New > Registry Item.

Make sure that HKEY_Local_Machine is selected for Hive and then click . (the ellipses) next to Key Path.

Browse to System\CurrentControlSet\Services\PimIndexMaintenanceSvc. In the list of values, highlight Start and click Select.

Change Value data from 00000003 to 00000004 and click OK. Note setting the Value data to 4 = Disabled.

To add the other services that cannot be managed with a Group Policy templates, edit the policy and repeat steps 5-8.

Managing Template Services with reg.exe

If you cannot use Group Policy Preferences to manage the per-user services, you can edit the registry with reg.exe. To disable the Template Services, change the Startup Type for each service to 4 (disabled). For example:

We recommend that you do not directly edit the registry unless there is no other alternative. Modifications to the registry are not validated by the Registry Editor or by the Windows operating system before they are applied. As a result, incorrect values can be stored, and this can result in unrecoverable errors in the system. When possible, instead of editing the registry directly, use Group Policy or other Windows tools such as the Microsoft Management Console (MMC) to accomplish tasks. If you must edit the registry, use extreme caution.

Managing Template Services with regedit.exe

If you cannot use Group Policy preferences to manage the per-user services, you can edit the registry with regedit.exe. To disable the template services, change the Startup Type for each service to 4 (disabled):

We recommend that you do not directly edit the registry unless there is no other alternative. Modifications to the registry are not validated by the Registry Editor or by the Windows operating system before they are applied. As a result, incorrect values can be stored, and this can result in unrecoverable errors in the system. When possible, instead of editing the registry directly, use Group Policy or other Windows tools such as the Microsoft Management Console (MMC) to accomplish tasks. If you must edit the registry, use extreme caution.

Beginning with Windows 10, version 1709 and Windows Server, version 1709, you can prevent the per-user service from being created by setting UserServiceFlags to 0 under the same service configuration in the registry:

Manage template services by modifying the Windows image

If you’re using custom images to deploy Windows, you can modify the Startup Type for the template services as part of the normal imaging process.

Use a script to manage per-user services

You can create a script to change the Startup Type for the per-user services. Then use Group Policy or another management solution to deploy the script in your environment.

Sample script using sc.exe:

Note that the space after «=» is intentional.

View per-user services in the Services console (services.msc)

As mentioned you can’t view the template services in the Services console, but you can see the user-specific per-user services — they are displayed using the _LUID format (where LUID is the locally unique identifier).

For example, you might see the following per-user services listed in the Services console:

• CPDUserSVC_443f50
• ContactData_443f50
• Sync Host_443f50
• User Data Access_443f50
• User Data Storage_443f50

View per-user services from the command line

You can query the service configuration from the command line. The Type value indicates whether the service is a user-service template or user-service instance.

Introduction to Windows Service Applications

Microsoft Windows services, formerly known as NT services, enable you to create long-running executable applications that run in their own Windows sessions. These services can be automatically started when the computer boots, can be paused and restarted, and do not show any user interface. These features make services ideal for use on a server or whenever you need long-running functionality that does not interfere with other users who are working on the same computer. You can also run services in the security context of a specific user account that is different from the logged-on user or the default computer account. For more information about services and Windows sessions, see the Windows SDK documentation.

You can easily create services by creating an application that is installed as a service. For example, suppose you want to monitor performance counter data and react to threshold values. You could write a Windows Service application that listens to the performance counter data, deploy the application, and begin collecting and analyzing data.

You create your service as a Microsoft Visual Studio project, defining code within it that controls what commands can be sent to the service and what actions should be taken when those commands are received. Commands that can be sent to a service include starting, pausing, resuming, and stopping the service; you can also execute custom commands.

After you create and build the application, you can install it by running the command-line utility InstallUtil.exe and passing the path to the service’s executable file. You can then use the Services Control Manager to start, stop, pause, resume, and configure your service. You can also accomplish many of these same tasks in the Services node in Server Explorer or by using the ServiceController class.

Service Applications vs. Other Visual Studio Applications

Service applications function differently from many other project types in several ways:

The compiled executable file that a service application project creates must be installed on the server before the project can function in a meaningful way. You cannot debug or run a service application by pressing F5 or F11; you cannot immediately run a service or step into its code. Instead, you must install and start your service, and then attach a debugger to the service’s process. For more information, see How to: Debug Windows Service Applications.

Unlike some types of projects, you must create installation components for service applications. The installation components install and register the service on the server and create an entry for your service with the Windows Services Control Manager. For more information, see How to: Add Installers to Your Service Application.

The Main method for your service application must issue the Run command for the services your project contains. The Run method loads the services into the Services Control Manager on the appropriate server. If you use the Windows Services project template, this method is written for you automatically. Note that loading a service is not the same thing as starting the service. See «Service Lifetime» below for more information.

Windows Service applications run in a different window station than the interactive station of the logged-on user. A window station is a secure object that contains a Clipboard, a set of global atoms, and a group of desktop objects. Because the station of the Windows service is not an interactive station, dialog boxes raised from within a Windows service application will not be seen and may cause your program to stop responding. Similarly, error messages should be logged in the Windows event log rather than raised in the user interface.

The Windows service classes supported by the .NET Framework do not support interaction with interactive stations, that is, the logged-on user. The .NET Framework also does not include classes that represent stations and desktops. If your Windows service must interact with other stations, you will need to access the unmanaged Windows API. For more information, see the Windows SDK documentation.

The interaction of the Windows service with the user or other stations must be carefully designed to include scenarios such as there being no logged on user, or the user having an unexpected set of desktop objects. In some cases, it may be more appropriate to write a Windows application that runs under the control of the user.

Windows service applications run in their own security context and are started before the user logs into the Windows computer on which they are installed. You should plan carefully what user account to run the service within; a service running under the system account has more permissions and privileges than a user account.

Service Lifetime

A service goes through several internal states in its lifetime. First, the service is installed onto the system on which it will run. This process executes the installers for the service project and loads the service into the Services Control Manager for that computer. The Services Control Manager is the central utility provided by Windows to administer services.

After the service has been loaded, it must be started. Starting the service allows it to begin functioning. You can start a service from the Services Control Manager, from Server Explorer, or from code by calling the Start method. The Start method passes processing to the application’s OnStart method and processes any code you have defined there.

A running service can exist in this state indefinitely until it is either stopped or paused or until the computer shuts down. A service can exist in one of three basic states: Running, Paused, or Stopped. The service can also report the state of a pending command: ContinuePending, PausePending, StartPending, or StopPending. These statuses indicate that a command has been issued, such as a command to pause a running service, but has not been carried out yet. You can query the Status to determine what state a service is in, or use the WaitForStatus to carry out an action when any of these states occurs.

You can pause, stop, or resume a service from the Services Control Manager, from Server Explorer, or by calling methods in code. Each of these actions can call an associated procedure in the service (OnStop, OnPause, or OnContinue), in which you can define additional processing to be performed when the service changes state.

Types of Services

There are two types of services you can create in Visual Studio using the .NET Framework. Services that are the only service in a process are assigned the type Win32OwnProcess. Services that share a process with another service are assigned the type Win32ShareProcess. You can retrieve the service type by querying the ServiceType property.

You might occasionally see other service types if you query existing services that were not created in Visual Studio. For more information on these, see the ServiceType.

Services and the ServiceController Component

The ServiceController component is used to connect to an installed service and manipulate its state; using a ServiceController component, you can start and stop a service, pause and continue its functioning, and send custom commands to a service. However, you do not need to use a ServiceController component when you create a service application. In fact, in most cases your ServiceController component should exist in a separate application from the Windows service application that defines your service.

For more information, see ServiceController.

Requirements

Services must be created in a Windows Service application project or another .NET Framework–enabled project that creates an .exe file when built and inherits from the ServiceBase class.

Projects containing Windows services must have installation components for the project and its services. This can be easily accomplished from the Properties window. For more information, see How to: Add Installers to Your Service Application.