Configuring the Platform for Windows Services in Guest Applications

To better support legacy architecture patterns in guest applications, the Platform allows for the deployment of Windows Services as guest application components. By default this functionality is disabled upon initial Platform installation, but you can configure your Platform to enable it.

Windows Services Configurations

Windows Service hosting can be enabled through the Platform Registry page in the System Operations Center (SOC) by setting Hosting.WindowsServices.Enabled to “True.”  Instructions for modifying a registry setting (or for adding the setting, should it not appear in the list of Registry Settings) can be found on the Platform Registry page. Once the setting is enabled, Development Teams will be able to upload archives that include Windows Service components. 

The behavior and appearance of Platform-hosted Windows Services can be configured through other settings in the Platform Registry:

Name Explanation Values


Format for Descriptions for Windows Services. String value; defaults to
Service Name={5},  Lifecycle Stage={3},  Executable={4},  Application Id = {0},  Version Id = {1},  Developer Id={2}


Format for Display Names for Windows Services. String value; defaults to
Apprenda Guest (AppAlias='{0}'; Id={1})
Hosting.WindowsServices.Enabled Enable Developer ability to include Windows Services in guest apps True, False
Hosting.WindowsServices.MaxPortsPerComponent Maximum allowable number of ports per  Windows Service component for guest apps. Any positive integer
Hosting.WindowsServices.NameFormat Format for  Names for Windows Services. String value; defaults to
Hosting.WindowsServices.PortRangeHighLimit Highest port number allowable for Windows Service components for guest apps. Any valid port number.
Hosting.WindowsServices.PortRangeLowLimit Lowest port number allowable for Windows Service components for guest apps. Any valid port number.

The manner in which deployed Windows Services appear in the Services display on the machines where they are hosted can be customized using the Hosting.WindowsServices.DescriptionFormat (corresponds to the “Description” field below), Hosting.WindowsServices.DisplayFormat (corresponds to the “Name” field below), and Hosting.WindowsServices.NameFormat settings (corresponds to the Name field that appears in the Properties dialog for the service). 

Any guest application that uses Windows Services that require specific ports must specify the ports required for each service in the application’s Deployment Manifest.  When the service is deployed, the Platform will then reserve the specified ports on the host server for use by the deployed Windows Service component (and will also select a host for component deployment based on port availability). The port range available for use by guest application Windows Services across the Platform can be configured using the Hosting.WindowsServices.PortRangeHighLimit and Hosting.WindowsServices.PortRangeLowLimit settings.  The number of ports that can be designated for each Windows Service component can be configured by the Hosting.WindowsServices.MaxPortsPerComponent setting.

It is strongly suggested that Platform Administrators convey port usage expectations to Developers in order to avoid port usage conflicts.

Special Considerations for Windows Services

The Apprenda Platform does not support autodeployment of Windows Services, which means that all instances of a Windows Service component must be deployed manually. This can be done by Developers through the Scale Components section of the Developer Portal or the SetInstanceCount command in the Apprenda Cloud Shell.  Platform Administrators can deploy Windows Service instances through the Applications page in the SOC.

The Windows Service Account under which Windows Services are run must have “Log on as service” rights for the servers to which Windows Services are deployed.  By default, all guest services on the Platform will use the Account credentials configured through the SaaSGridDefaultServiceAccountUsername, SaaSGridDefaultServiceAccountDomain, and SaaSGridDefaultServiceAccountPassword settings in the Platform Registry.  To designate a different Service Account for a specific Windows Service component, a Platform Administrator can edit the Service Level Options for that component in the Applications page in the SOC.  Please note that the Service Account must be designated for each version of each Windows Service component for every guest application on the Platform if the Default Service Account does not have “Log on as service” rights.

Managing Windows Services in Guest Applications

Platform Administrators are able to define Application Deployment Policies, or specific rules governing how guest applications are deployed on the Apprenda Platform.  These can be used in conjunction with Custom Properties, which can be used to tag Platform infrastructure and application components.  Both can be applied to Windows Service components. The Platform’s Resource Throttling and Allocation capabilities are also applicable to Windows Services, which can be managed in the same way as Web Services.

Information for Developers on how to package and deploy guest applications that use Windows Services can be found here.