On this page
This section provides an overview of the Knox Service Plugin (KSP) schema structure and general best practices.
The image below shows the high level categories of policies and common configurations. It has four main components.
- Basic elements: General operational controls for KSP. For example, turn on debug mode or input a KPE license key.
- Device-wide policies section: Device Owner (DO) policy controls. These are of global scope.
- Work profile policies section: Profile Owner (PO) policy controls. These apply to only the Knox Workspace.
- Configurations: Specific configuration properties that are used in conjunction with policy controls. For example, VPN profile settings, APN settings, or DeX customization settings. These can be used on either device-wide policies or work profile policies.
Each version of KSP includes a few common options. The features available within these options depend upon your KSP deployment mode, KPE license status (whether you have a Standard or a Premium license) and the features available in your UEM's native console.
These common options are as follows:
- Profile name: A unique nickname you provide for a set of policy configurations. You can create many different profile names for various sets of configurations. Later, you can use the name for tracking and debugging purposes. We recommend using a name less than 50 characters in length, for example,
- KPE Premium License key:This is useful for consoles that do not have Knox Premium License activation built in as a native feature. When this field is used, KSP can activate the license for you when you push the configuration. If your UEM console has already activated a Knox Premium License on you device, there is no need to activate a license using this field. An example of this field is shown below.
You only need to input a license if you are using a premium policy. If you do not provide a license key and use a premium policy (or the key provided does not have necessary privileges) the policy KSP fails and produces an error message.
- Debug modes: When you turn on debug mode, you can view policy results and errors on the device through an app menu. We recommend enabling this mode only during test phases and not during final deployment. If you run into any KSP deployment issues, check this box to enable debug mode and try to perform the action again. You can also export the message and reach out to Knox Support for help to diagnose and fix your issue.
Group policy control flag
Every group has a control that enables or disables that policy group. By default every policy group is disabled. You must enable this control before setting any policy in the group. For example, before using any policy in the device-wide policy section, turn on the Enable device-wide policies control first. Further more, to use any device restrictions within the device-wide policy section, turn on Enable device restriction controls and then activate individual policies, such as Allow microphone, Allow Wi-Fi and so on.
Control groups are mandatory. Incorrect control group settings or deleting them from input configuration causes KSP to revoke policies or not process policies in that group.
This is illustrated in the image below.
You can save a group of configurations using a Profile Name. Once you save a group of configurations, you can reuse these configurations for as many deployments as you need.
For example, in the image below, we have set the DeX profile name as
DeX profile 1. Any configurations set are saved under the name
DeX profile 1. When setting policies later, you can reference
DeX profile 1 to quickly set up devices with your saved configurations.
- Auto-install: Turn this on if it is supported by your UEM. This ensures all devices install KSP automatically when prompted.
- Auto-update: Turn this on if it is supported by your UEM . This ensures that the KSP app is up to date on deployed devices. KSP is designed to be backward compatible. For example, a newer version of the app can handle older schema data, but older app versions can't handle new schema data.
- Native console policies: Use your UEM console for any policy that is supported natively and use KSP to bridge any gaps.
- Test in small batches: Always test your KSP schema changes with a limited set of devices, debug the issues (if any) by enabling debug mode, then roll out to wider deployment.
Some fields allow you to specify more than one app to target. For example: when you select apps to whitelist for a proxy. To list out apps, use a comma-separated list of packages. For example
com.samsung.android.email.provider, com.sec.android.app.sbrowser. To find an package name, look at the Google Play store URL or contact the app vendor.
Some Knox policies, such as DeX customization, require you to provide bulk data – such as image file. However, the OEMConfig specification does not currently support file upload.
If you need to upload a file you can use one of the following methods:
- Upload the file to a cloud server and provide the web URL as an input string to KSP.
- Ensure the URL is publicly accessible.
- Some UEMs have a limitation on the number of characters you can enter to a string field –if this is the case, you can't use this approach.
- Use a provided UEM method to push the image file to the local storage on the device and provide the file path on the device as input string to KSP.
- Contact your UEM vendor to find out if they support this feature.
- Ensure that the image is pushed to the device before KSP is installed and attempts to apply the policy.