The Settings Tab provides various options that control the service's runtime profile.

The following table describes the fields provided on the Settings tab.

Interact with DesktopWhen checked, this allows the service to interact with the desktop. The interactive components of the service are always displayed on the desktop of Session 0. You will need to switch desktop to Session 0 in order to view the interactive components. Interactive services can be run as the default service account (i.e. Localsystem) or can be run as a user with local or domain administrative user privileges. Interactive services will not work with any lower privileged account type (e.g. domain user). If you intend to run your services using non-privileged credentials, ensure you uncheck Interact With Desktop.

Access to Session 0 is heavily restricted and may not be available on your Microsoft Windows Operating System. Please review in detail our various Session 0 Isolation knowledge base articles.
Show WindowThe display mode of the interactive service.

The following are options available:
  • Normal
  • Hidden (silently causes the Interact with Desktop setting to have no effect)
  • Minimized
  • Maximized (some applications may not respond to this setting)
Service SID TypeThe Windows security identifier (SID) type setting for the service. The purpose of the SID type is to isolate the objects a service has access to (e.g. files or registry keys). When the SID type is set, this instructs the Windows Service Control Manager to add the service SID type to service's process token, allowing the service to gain to access to specific objects without having to run under a highly privileged account. Changes to the SID Type do not take effect until the system is restarted. For more information see Microsoft's documentation.

The following options are available:
  • None. Use this type to reduce application compatibility issues
  • Unrestricted. When the process is created the service SID is added to the service process token with the following attributes: SE_GROUP_ENABLED_BY_DEFAULT | SE_GROUP_OWNER
  • Restricted. This type includes Unrestricted. The service SID is also added to the restricted SID list of the process token. Three additional SIDs are added to the restricted SID list: World SID, Service Logon SID and Write-restricted-SID. Once ACE that allows GENERIC_ALL access for the service logon SID is also added to the process token object.
Job TypeDetermines whether the service is to be placed in a Job Group at runtime.

By placing the service in a Local or Global group, note that
  • Any child processes that the service spawns will be terminated when the service is stopped.
  • All processes in the job group must terminate for lifecycle options to take effect.
  • The service's scheduling priority is propagated to all processes in the job group.

Note: The actual scope of the Job Type is relevant only when the Windows Terminal Services server component is installed.

A Terminal Services server has multiple namespaces for a variety of named kernel objects including job objects. By default, all services are created in the Global scope.

Local Jobs exist only in the current client session namespace so as to not interfere with other instances of the same program in other sessions.

Job Type settings are as follows:
  • No Job - select this setting if the service runs a single program instance
  • Global Job - select this setting if the service spawns multiple program instances or if Windows Terminal Services is running on the system.
  • Local Job - this scope is of dubious use and it has been included only for the sake of completeness.
Load Order GroupThe name of the Load Order Group in which to place the service (if any). See Dependencies Tab for details about how Load Order Groups are used.

Note: The naming conventions for the Load Order Group field are the same as the Short Name field.
Logon AccountThe name of the Windows user account that will own the service when that service is run.

The account can be any of the following:
  • A local account: .\<account> or <computer name>\<account>
  • One of three special system accounts:
    • LocalSystem
    • NT AUTHORITY\LocalService
    • NT AUTHORITY\NetworkService
  • A domain account: <DOMAIN>\<account>
  • A domain account: <>\<account>
  • A domain account: <>
  • A domain Managed Service Account: <>\<account>$
  • A domain Group Managed Service Account: <>\<account>$
  • A virtual service account: NT SERVICE\<serviceName>
  • A network virtual service account: <DOMAIN>\<hostname>$

If no account is specified, the service will run under the LocalSystem account.

A service may run as a user other than LocalSystem and interact with the desktop only if that user is a member of the local or domain Administrators group.

If an account other than LocalSystem is used to run the service, the account will be automatically granted the SeServiceLogonRight privilege (Log On as a Service).

If a service is to be started or restarted in session, then the user account must be left blank or set to LocalSystem. This is because the only user account that permits the grabbing of a session token is LocalSystem as it has the SeTcbPrivilege set (i.e. assume the identity of another user and gain access to the resources that the user is authorized to access). Hence, when a FireDaemon Pro service runs as another user account (e.g. domain\UserA) it is impossible to obtain the session token for another user (e.g. domain\UserB). For more information please see this Microsoft User Rights document.
PasswordThe password for the local or domain user account.

If the password of the user account is changed locally or on the Domain Controller, you will need to update this field and reinstall the service to reflect the change. If the password is not updated, the service will fail to start due to incorrect authorization credentials.

Note: No password is required for Managed Service Accounts, Group Managed Service Accounts or virtual service accounts.
Confirm PasswordThe password must be re-entered to confirm the value in the Password field.

Note: If the passwords do not match, FireDaemon Pro will not install the service.
Processor Scheduling
PriorityThe runtime scheduling priority of the service, its threads, and all child processes.

Note: Avoid using the Real-Time (preempts all other processes) option as it actually pre-empts the kernel scheduler.
Processor GroupA static set of processors as defined by Windows. For more information, see Processor Groups.
NUMA NodesThis field shows on which NUMA node(s) the service will execute. It will be filled if a Processor Group and a CPU Binding other than 0 is selected. For more information, see NUMA Support.
CPU BindingsBinds the service to specific core(s) on multi-CPU, multi-core machines.

You can enter the Affinity Mask as a binary, decimal or hexadecimal value. The displayed and expected number format depends on the CPU Bindings Radix specified in the Options dialog.

If no CPUs are selected, or all CPUs are selected, then the service can potentially run on any CPU and the actual CPU in use will be decided by the Windows scheduler from one moment to the next.
Statistics MonitoringThe time interval (in milliseconds) for FireDaemon Pro to refresh the service's memory and CPU usage statistics in the user interface. To disable statistics refreshes, set the time interval to zero.

Note: This also sets the length of time after a service start in which Flap Detection is active.