Adding Services to Windows Server: A Comprehensive Guide Using Command Line

Windows Server relies heavily on services to perform various functions, from managing system resources to providing network capabilities. Adding a new service is a common task for system administrators. While graphical tools exist, the command line offers a powerful and scriptable way to manage services. This guide delves into using the sc.exe create command to effectively add services to your Windows Server environment. Understanding this command is crucial for automating service deployment, troubleshooting, and customizing your server to meet specific needs.

Understanding the sc.exe create Command

The sc.exe (Service Control) command is a built-in command-line utility in Windows Server that allows you to communicate with the Service Control Manager. The create subcommand specifically registers a new service within the Windows Registry and the Service Control Manager database. This registration makes the service manageable through both command-line tools and graphical interfaces like the Services Management Console.

Syntax of sc.exe create

The basic syntax for the sc.exe create command is as follows:

sc.exe [<servername>] create [<servicename>] [options]

Let’s break down the key components:

• sc.exe: Invokes the Service Control command-line tool.
• [<servername>]: (Optional) Specifies a remote server by its UNC name (e.g., \myserver). If omitted, the command operates on the local server.
• create: The subcommand instructing sc.exe to create a new service.
• [<servicename>]: The service name (also known as the service key name). This is the internal name used by the system to identify the service. It’s returned by the getkeyname operation and is distinct from the display name.
• [options]: A series of parameters that define the service’s behavior and configuration. These are crucial for correctly setting up your new service.

Key Parameters Explained for Service Creation

The power of sc.exe create lies in its extensive options, allowing fine-grained control over service configuration. Here are the essential parameters you’ll need to understand when adding a service to Windows Server:

• type=: Defines the type of service being created. This is critical for how the service interacts with the system. Common types include:

  • own: (Default) A service that runs in its own dedicated process. Ideal for most standalone applications and services, offering better isolation and stability.
  • share: A service that shares a process with other services. Used for services designed to run within a shared service host (svchost.exe).
  • kernel: Specifies a device driver that operates at the kernel level.
  • filesys: Specifies a file system driver.
  • rec: A file system recognizer driver, identifying file systems used by the computer.
  • interact: Indicates a service that can interact with the desktop. This type must be used in conjunction with type= own or type= share (e.g., type= interact type= own). Interactive services run under the LocalSystem account.

• start=: Determines when and how the service starts. Choosing the correct start type is vital for service availability and system boot process:

  • boot: For device drivers loaded by the boot loader, starting very early in the boot process.
  • system: For device drivers that start during kernel initialization, starting after the boot drivers.
  • auto: The service starts automatically each time the server boots. It runs even if no user logs in. Suitable for services that must always be running.
  • demand: (Default) The service starts manually, either by a user or another service. Appropriate for services that are not always needed.
  • disabled: The service is prevented from starting. Useful for temporarily or permanently deactivating a service.
  • delayed-auto: The service starts automatically, but shortly after other auto-start services. This can improve boot performance by delaying less critical services.

• error=: Configures the system’s response if the service fails to start during server startup. This is important for ensuring system stability and error handling:

  • normal: (Default) Logs the error and displays a message box to the user. Startup continues.
  • severe: Logs the error. The system attempts to restart using the Last Known Good Configuration.
  • critical: Logs the error. The system attempts to restart with the Last Known Good Configuration. If that fails, startup fails, and the boot process halts with a Stop error. Use with caution.
  • ignore: Logs the error, and startup continues without user notification beyond the Event Log entry.

• binpath=: Specifies the path to the executable file of the service. This is a mandatory parameter. Ensure the path is correct and accessible by the system account under which the service will run.

• displayname=: Sets the friendly name for the service. This is the name displayed in the Services Management Console and other user interfaces, making it easier to identify the service compared to the service name.

• obj=: Defines the account under which the service will run. The default is LocalSystem, a powerful built-in account. You can also specify a user account (e.g., DomainUsername) for services requiring specific permissions. For driver services, this parameter can specify a Windows driver object name.

• password=: Required if you specify a user account (other than LocalSystem) with the obj= parameter. Provides the password for the specified user account.

• depend=: Lists services or groups that must start before this service. Dependencies are separated by forward slashes (/). This ensures proper service startup order, especially for services that rely on others.

• group=: Specifies the load ordering group to which the service belongs. Groups are defined in the registry under HKLMSystemCurrentControlSetControlServiceGroupOrder. The default is null (no group).

• tag=: Applies only to boot-start and system-start drivers. tag= yes requests a TagID from the CreateService call.

Practical Examples of Adding Services

Let’s illustrate service creation with sc.exe create through practical examples.

Example 1: Creating a Basic Service

Suppose you have an executable named MyService.exe located in C:MyServices that you want to run as a service. To create a basic service named “MyNewService” that starts automatically, you would use the following command:

sc.exe create MyNewService binpath= "C:MyServicesMyService.exe" start= auto displayname= "My New Service"

This command does the following:

• Creates a service named MyNewService.
• Sets the binary path to C:MyServicesMyService.exe.
• Configures the startup type to auto, so it starts automatically on boot.
• Sets the display name to “My New Service” for easy identification in the Services console.

.png)
Alt text: Command prompt showing the successful creation of a new service using sc.exe create.

Example 2: Creating a Shared Service with Dependencies

If you have a service that’s designed to run as a shared process and depends on the “TCP/IP NetBIOS Helper” service, you can use the following command:

sc.exe create SharedService type= share binpath= "C:SharedServicesSharedSvcHost.exe" start= demand depend= "NetBIOS" displayname= "Shared Example Service"

This command:

• Creates a service named SharedService of type= share.
• Sets the binary path to C:SharedServicesSharedSvcHost.exe.
• Sets the startup type to demand (manual start).
• Specifies a dependency on the “NetBIOS” service (Service Name, not Display Name).
• Sets the display name to “Shared Example Service”.

Example 3: Creating an Interactive Service

To create an interactive service (though generally discouraged for security reasons in server environments unless absolutely necessary), you would combine type= interact with type= own or type= share. For example:

sc.exe create InteractiveService type= interact type= own binpath= "C:InteractiveServiceInteractiveApp.exe" start= demand obj= LocalSystem displayname= "Interactive Service Example"

This command:

• Creates a service named InteractiveService that is both type= interact and type= own.
• Sets the binary path to C:InteractiveServiceInteractiveApp.exe.
• Sets the startup type to demand.
• Specifies obj= LocalSystem as interactive services must run under this account.
• Sets the display name to “Interactive Service Example”.

Conclusion

The sc.exe create command is an indispensable tool for system administrators who need to add services to Windows Server via the command line. By mastering its parameters and understanding service types and startup behaviors, you can efficiently manage and customize your server environment. This method provides a robust and scriptable way to deploy and configure services, enhancing automation and control over your Windows Server infrastructure. Remember to always test service configurations in a non-production environment before implementing them on live servers.

For further exploration of service management and the sc.exe command, refer to the official Microsoft documentation on SC commands.