At the core of Pulseway is a reimagined policy management engine designed to provide technicians with an effective balance of predictability and flexibility. The simple yet powerful way policies work helps arm Pulseway customers with the tools necessary to build and maintain absolute compliance of their configuration settings.
Pulseway is in the process of rolling out a less monolithic policy structure and adding quality-of-life improvements to the overall policy management design. As of version 9.5, Device Configuration policies and Monitoring policies will be converted to the new policy structure, and the remaining policy types will be converted in subsequent releases.
What are policies?
Policies are the method in which collections of one or more Pulseway settings are applied to a specific set of objects, such as devices. Pulseway is responsible for ensuring a policy's targeted devices receive and remain compliant with the policy’s settings. Policies are distinguished by the type of service each is responsible for.
Policies apply the correct settings to the correct devices. As of version 10.6, policies are non-cumulative, which means only one policy of a given type can be assigned to a given entity.
EXAMPLE Only one Device Configuration policy can be assigned to a specific organization. You could create additional Device Configuration policies, but only one at a time can be assigned to that organization.
Policies support a downward inheritance model in several places, including context.
EXAMPLE When you assign a policy to an organization, the sites and groups of that organization will automatically inherit the organization’s policy since sites and groups are child objects of an organization. However, you can break the inheritance by directly assigning a different policy at each site and/or group level.
Policy types
The following types of policies are available to configure in Pulseway:
Device Configuration
Monitoring
Endpoint Protection (Ransomware Detection and Webroot)
Patch Management
Components of a policy
A policy is the vehicle for delivering and managing settings on devices. Policies have three key components:
Profiles: Containers of settings that serve as the building blocks of policies. Profiles control which settings a policy will deliver. For details, refer to Profiles.
Targeting criteria: Attributes used for automatic assignment of policies. Targeting criteria control which devices will receive the policy. For details, refer to Targeting criteria.
Extensions: Used to change policy settings based on device exceptions. Extensions provide a way to make changes to a policy for a specific subset of devices without requiring creation of an entirely new and separate policy. For details, refer to Extensions.
Profiles
The concept of profiles simplifies the configuration and management of policy settings.
A profile is a small, distinct container of Pulseway settings grouped by a specific category type (for example, Event Log profiles are a type of Monitoring profile).
Profiles allow for specific combinations of settings to be configured once and reused in more than one policy. This concept also allows the profile to act as a template so that any future changes to it are automatically reflected everywhere the profile is used.
Profiles are designated as either cumulative or non-cumulative, which means that a profile of a given type can either be applied multiple times to a device or applied only once.
Cumulative profiles versus non-cumulative profiles
Cumulative profiles are specific types of profiles that can be applied to a device more than once because their settings are considered safe for layering, which means their settings do not exactly conflict if applied more than once. Examples of cumulative profile types can be found in Monitoring profiles. For instance, you might want to have a base set of event logs that apply to all of your Windows devices, so you would create a specific Monitoring: Event Log profile with those settings. Additionally, you may have a more advanced set of event logs that you apply to a subset of Windows devices, so you would create a second Monitoring: Event Log profile with the advanced settings. By leveraging the capabilities within policies, both Event Log profiles can be applied to the devices that require the base and advanced set of event log settings, and the settings will be aggregated. This eliminates the need to duplicate the common event log settings of the first profile into the advanced profile.
Non-cumulative profiles are specific types of profiles that can be applied to a device only once because their settings are considered problematic for layering, which means their settings directly conflict if applied more than once. Examples of non-cumulative profile types can be found in Device Configuration profiles. For instance, you might want to enable Remote Desktop session confirmation for all your devices, so you would create a specific Device Configuration: Remote Desktop profile with that setting. Additionally, you may want to disable Remote Desktop session confirmation for a subset of devices, so you would create a second Device Configuration: Remote Desktop profile with that setting. However, each device can receive only one of these profiles, not both. In this case, when working within policies, intelligence is built in to prevent you from applying a second type of non-cumulative profile to the same targets that already have one assigned, and Pulseway will present options to correct the conflict.
The following diagram shows how a profile works using Monitoring policies as an example.
EXAMPLE Two separate Monitoring policies require the same set of event log settings, which means you can create a single Event Log profile with the required settings and assign the profile to both policies. An additional benefit of this structure is change management. If the event log settings need to be changed, they only need to be changed within the single profile, not within each policy.
Targeting criteria
As the name implies, targeting criteria expose various attributes that can be selected within each policy and its extensions so you can explicitly and implicitly control where a policy should be applied. This means you can set up your policies once and know they will automatically be applied to any device that matches the targeting criteria, including existing devices and newly provisioned devices.
As follows are examples of targeting criteria:
Context: Refers to the organizational structure of devices.
Device Type: Refers to the primary type of device.
OS Type: Refers to the operating system of a device and includes major versions.
Manufacturer: Refers to the manufacturer of a device.
Extensions
An extension allows you to adjust a policy’s settings for a subset of the policy’s targeted devices.
Use case
You have a specific combination of settings that apply to a set of devices, but for a subset of those devices, a slight adjustment of the settings is required.
In typical policy implementations, you may be required to do either of the following:
Create a second policy with the specific settings for the subset of devices and all the same settings as the first policy that are also required for those devices. The result is two policies with potential overlap in the settings. If a change is needed among those shared settings, both policies would need to be updated individually.
Create an override for each of the devices, which is typically done directly within each device. The result is a decentralized manual deviation from your centralized configuration, often with no association or visibility outside each device level.
Both of the preceding examples create unnecessary complexity, incomplete visibility, and a lack of control. Also, you typically need to perform manual work when reconciling for compliance.
The concept of extensions solves these problems and more by creating what is effectively a child policy that remains associated with its parent. The extension automatically inherits the settings and targeting criteria from its parent; however, you can adjust the targeting criteria to refine your device selections and you can add, change, and remove profiles while leaving any relevant profiles from the parent intact.
Referring to the original use case referenced, you would solve this by performing the following steps in Pulseway:
Create an initial policy and assign the relevant profiles for the broader set of devices.
Create an extension to the policy, configuring the relevant profile changes (add, change, remove) and refining the targeting to apply only to the smaller subset of devices.
The result will be that the subset of devices targeted by the extension receives the profiles within the extension, while the remainder of the devices targeted by the parent policy will receive the profiles within that policy.
Pulseway policies support multiple extensions at the same level and the ability to extend an extension.
EXAMPLE You may want to create an extension that changes some parent settings for Linux devices and, at that same level, create a different extension that changes some parent settings for macOS devices. Further, you may want to create an extension of the macOS extension to refine some settings for macOS 12 devices.
The following diagram shows how the policy extension concept works.
EXAMPLE You can think of each extension as a higher priority policy, as each extension refines its targets with more granularity than the extension’s parent. For example, the Windows 11 devices will receive only Extension 1.1 because they are more specifically targeted versus the criteria used within Policy 1 and Extension 1. However, if you were to delete Extension 1.1, all Windows 11 devices would automatically adopt the settings of Extension 1 since that extension is targeting all Windows devices.
The policy extension model helps you to build your policies more broadly at the root levels, covering more devices with common settings while allowing you to use extensions to granularly refine the targeting criteria and setting adjustments to deal with exceptions, special situations, and advanced service levels.
Effective settings
Even the best policy management implementation can fail if the solution does not provide comprehensive visibility of the impact it will have, does have, or is going to have across your environment. Pulseway provides visibility of impact on the front end while you are building and configuring your policies as well as on the back end once policies are set.
While you are configuring policies, the editor will show you what Pulseway objects will receive that policy before you save it. Once the policies have been configured, effective settings provide visibility of the policies, their profiles, and the settings that have been assigned and applied at all levels of your Pulseway environment. This includes organizations, sites, groups, and devices. For example, when you are working on a device and need to quickly see what settings might be impacting a certain service area, effective settings will help you understand this information while allowing you to maintain the context of your operational workflow.
Basic profiles and policies package
To provide you with a jump-start and to help you understand the policy concepts explained in this topic, Pulseway includes a basic set of profiles and policies preconfigured with a few extensions.
Profiles
Various profiles with common configurations are available in Pulseway. These can be found by navigating to Administration > Configuration > Profiles and are grouped by folders or content tags.
EXAMPLE The built-in Device Configuration and Monitoring profiles are grouped as Basic Device Profiles.
Policies
The built-in policies are named similarly to the profile grouping name.
EXAMPLE The Device Configuration and Monitoring policies are named Basic Device Configuration Policy and Basic Device Monitoring Policy, respectively.
The built-in policies include several of the built-in profiles, and each policy contains two extensions: one for Windows servers and one for Windows workstations.
For new customers, each root policy is already configured to target All Organizations, which means that it is active and will automatically apply to any devices with an Agent you onboard.
NOTE If you were an existing customer when the package was introduced with Pulseway version 10.6, the root policies are not configured with a context target, which means the policies will not be automatically assigned to any devices. To use the policies, simply assign the root policy to any context (that is, organization, site, group).