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 Desktop
|When 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.
|The display mode of the interactive service.
The following are options available:
|Service SID Type
|The 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:
|Determines 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
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:
|Load Order Group
|The 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.
|The name of the Windows user account that will own the service when that service is run.
The account can be any of the following:
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.
|The 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.
|The 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.
|The 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.
|A static set of processors as defined by Windows. For more information, see Processor Groups.
|This 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.
|Binds 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.
|The 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.