Skip to main content

Deploying with distribution software

  • Updated

Deploying with Microsoft Configuration Manager

Deploying with SentinelOne RemoteOps

Deploy EchoMark Screen with Microsoft Configuration Manager

This section describes a device-based deployment of EchoMark Screen with Microsoft Configuration Manager (SCCM), current branch. It uses the settings implemented by the current EchoMark MSI; older deployment notes or screenshots may use different names.

1. Plan the deployment

EchoMark Screen is a per-machine, 64-bit application for managed Windows 11 or later devices. Before creating the application, obtain:

  • The signed echomark.msi release - this can be found at https://static.echomark.com/screen/echomark.msi
  • The EchoMark Account Key for each deployment group.
  • The key-server URL, if your organization does not use the default:
    Non EU customers: <https://screen.app.echomark.com/v2/tile>, EU Customers: <https://screen.app.eu.echomark.com/v2/tile>
  • An optional Marking Policy ID supplied by the EchoMark app.
  • A Configuration Manager content-source folder accessible to the site server.
  • Device collections for a small pilot and each production deployment group.

Use a separate application configuration when collections require different Account Keys, key-server URLs, or Marking Policy IDs. Give applications and collections descriptive names such as EchoMark Screen 1.4.2 - Retail rather than letter or number placeholders.

Protect the Account Key. It is stored on clients under
HKEY_LOCAL_MACHINE\Software\EchoMark\EchoMark Screen. Limit access to the
Configuration Manager application, deployment commands, logs, and collections
that expose it.

2. Stage the content

Create a versioned source folder, for example:

\\SCCMSource\Applications\EchoMark Screen\1.4.2\

Copy the MSI into that folder without modifying it after distribution. The MSI contains the optional create-scheduled-task.ps1 helper and installs it beside the executable.

3. Create the application

  1. In the Configuration Manager console, open Software Library > Application Management > Applications.
  2. Select Create Application.
  3. Choose Windows Installer (.msi file) and browse to echomark.msi in the content source.
  4. Allow Configuration Manager to import the MSI metadata and create the Windows Installer deployment type.
  5. Name the application with its EchoMark release and deployment group.

Configuration Manager can import the MSI ProductCode as its initial detection method. The ProductCode changes between EchoMark releases, so also record the release number shown in the application metadata.

4. Configure the deployment type

Open the application's deployment type and review the following settings.

Programs

Use a silent, non-restarting installation command:

msiexec.exe /i "echomark.msi" /qn /norestart ACCOUNTID="<account-key>"

Add only the properties required by the deployment group:

KEYSERVERURL="screen.app.echomark.com"
FOR EU CUSTOMERS:"screen.app.eu.echomark.com" 
MARKINGPOLICYGUID="<policy-guid>"

ACCOUNTID is required for a silent installation. Do not deploy the default DEMO value to production. KEYSERVERURL is optional because the MSI already supplies the EchoMark service URL. Omit MARKINGPOLICYGUID unless EchoMark provided one.

Use the standard uninstall command imported from the MSI, or:

msiexec.exe /x {PRODUCT-CODE-FOR-THIS-RELEASE} /qn /norestart

Detection method

For a single configuration, the MSI ProductCode imported by Configuration Manager is an appropriate release-specific detection rule.

When separate collections receive different Account Keys, ProductCode detection alone is insufficient: the same MSI has the same ProductCode in every group, so moving a device between groups could leave the old configuration in place. Add 64-bit registry detection clauses under:

HKEY_LOCAL_MACHINE\Software\EchoMark\EchoMark Screen

Require these values:

Registry value Detection rule
Version Equals the release being deployed, such as 1.4.2.
AccountSecret Equals the Account Key assigned to this collection.
EchomarkKeyServerURL Equals the configured server URL, when customized.
MarkingPolicyId Equals the assigned policy ID, when used.

Do not select the option that treats the registry key as a 32-bit application on 64-bit systems. All detection clauses should be combined with AND.

User Experience and Requirements

Configure:

  • Installation behavior: Install for system.
  • Logon requirement: Whether or not a user is logged on.
  • Installation program visibility: Hidden.
  • Estimated and maximum run time: Use values appropriate to your environment; the MSI does not normally require a restart.
  • Requirements: 64-bit Windows 11 or later.

The normal release is self-contained, so it does not require a separate .NET installation. Only a special MinRelease build needs the 64-bit .NET 8 Desktop Runtime.

5. Decide how the client starts

The MSI installs Alphamark.exe and its configuration for the whole device, but a silent install does not automatically launch it or create a persistent startup entry. EchoMark must run in each user's interactive session to draw the watermark.

Before the first limited-user launch, register the application's Windows Event Log source from an elevated or system-context deployment step:

if (-not [System.Diagnostics.EventLog]::SourceExists("Alphamark")) {
    New-EventLog -LogName Application -Source "Alphamark"
}

Creating an event source changes machine-wide Event Log configuration and requires administrator privileges. The client can write subsequent events without being elevated. This step is unnecessary when the source was already created by a previous EchoMark launch or deployment.

The package includes create-scheduled-task.ps1, which an administrator can run after installation:

& "C:\Program Files\EchoMark Screen\create-scheduled-task.ps1"

The script creates \EchoMark\EchoMark Screen Watchdog, starting the client at user logon and checking every five minutes that it is running. Deploy this step with a Configuration Manager script, task sequence, or other organization-approved startup mechanism if the watchdog is part of your design.

The scheduled task launches the client at limited user privilege. It can keep the watermark running in the interactive session, but Windows does not grant that launch the special UI-access token needed to draw above elevated windows. A signed executable launched through Windows ShellExecute from a trusted location such as Program Files can receive that capability. Choose and test the startup method according to your watermark coverage requirements.

6. Distribute and pilot

  1. Distribute the application content to the distribution points or distribution-point groups serving the pilot collection.
  2. Confirm successful content distribution before deployment.
  3. Deploy the application to a small device collection.
  4. For an administrator-driven pilot, choose Available. For automatic installation, choose Required and set an appropriate deadline and maintenance-window behavior.
  5. Keep user notifications visible during the pilot unless your testing specifically requires a hidden experience.

Configuration Manager supports simulated and phased deployments for controlled rollouts. A required deployment can be simulated to validate applicability and detection without installing it; a phased deployment can advance from pilot to production based on configured success criteria.

7. Validate the pilot

On representative pilot devices, verify:

  1. Configuration Manager reports the application as installed.

  2. The installed release and paths are correct:

    Get-ItemProperty "HKLM:\Software\EchoMark\EchoMark Screen"
  3. Version matches the intended release, AlphamarkExePath exists, and the Account Key, server URL, and optional policy ID match the device collection.
  4. Alphamark.exe runs in the signed-in user's session and only one instance is present.
  5. The watermark appears on every connected display and responds to monitor changes.
  6. The device can reach the configured key server and continues with its cached policy during a temporary outage.
  7. EchoMark events appear in Event Viewer > Windows Logs > Application.
  8. If used, the \EchoMark\EchoMark Screen Watchdog task exists and restarts a stopped client.

For Configuration Manager troubleshooting, review:

C:\Windows\CCM\Logs\AppDiscovery.log
C:\Windows\CCM\Logs\AppEnforce.log
C:\Windows\CCM\Logs\AppIntentEval.log

AppDiscovery.log covers detection, AppEnforce.log covers install and uninstall enforcement, and AppIntentEval.log covers applicability and intended state.

8. Expand the rollout

After the pilot meets your installation, configuration, startup, connectivity, and watermark-coverage requirements:

  1. Deploy to progressively larger device collections.
  2. Monitor compliance in Monitoring > Deployments.
  3. Investigate failed or unknown states before broadening the deployment.
  4. Keep each Account Key aligned with its intended collection.
  5. Document collection membership, application configuration, release, and deployment deadline.

Microsoft documents the current deployment workflow in Deploy applications with Configuration Manager and the relevant client logs in its Configuration Manager log-file reference.

9. Upgrade or remove EchoMark Screen

EchoMark uses Windows Installer major-upgrade behavior. Any higher major.minor.build release replaces an older release; downgrades are blocked, reinstalling the same version is not a reliable update strategy, and Windows Installer ignores a fourth version field during comparison.

For each new release:

  1. Create a new, versioned Configuration Manager application for each deployment configuration.
  2. Import the new MSI and update the Version detection clause.
  3. Configure the new application to supersede the corresponding older application, or deploy the higher-version MSI as required to the same collection.
  4. Select automatic upgrade of superseded versions when appropriate.
  5. Redistribute content and repeat the pilot before production rollout.

To remove the client, deploy the application's uninstall action to the intended device collection. If the optional watchdog task was registered, remove it before uninstalling while its helper script still exists:

& "C:\Program Files\EchoMark Screen\create-scheduled-task.ps1" -Uninstall

Uninstallation removes the program and machine-wide registry values. Runtime caches are removed for the account executing the uninstall; caches in other Windows user profiles can remain.

Install EchoMark Screen with SentinelOne RemoteOps

EchoMark Screen is distributed as a per-machine, 64-bit MSI. The MSI installs both the desktop application and the AlphaMarkSvc Windows service. The service starts automatically at installation and at system startup, then launches the desktop application in each interactive user session.

SentinelOne RemoteOps can deploy the MSI by running a PowerShell script as Local System and supplying the installer in an attached ZIP file. SentinelOne agents must already be installed, online, and visible in the SentinelOne Management Console before beginning this procedure.

Console labels can vary by SentinelOne version and tenant configuration. The operator needs permission to create or upload RemoteOps scripts, run them on endpoints, and view task output.

1. Prepare the deployment files

  1. Obtain the signed EchoMark Screen MSI and rename it echomark.msi.
  2. Create a ZIP archive containing echomark.msi at the root of the archive. Do not place the MSI inside a nested folder.
  3. Obtain the EchoMark Account ID for the deployment group. Treat it as sensitive.

  4. Save the following script as Install-EchoMarkScreen.ps1 and replace <account-key> with the value supplied by EchoMark:

    <#
    EchoMark Screen installation for SentinelOne RemoteOps.

    Attach a ZIP containing echomark.msi when configuring the RemoteOps
    script. The script runs as Local System.

    Exit codes:
      0  = installation succeeded
      10 = attached MSI was not found
      12 = Windows Installer returned a failure code
#>

$ErrorActionPreference = 'Stop'

$AccountId = '<account-key>'
$MsiName = 'echomark.msi'
$MsiLog = Join-Path $env:SystemRoot (
    'Temp\EchoMark-Install-{0}.log' -f (Get-Date -Format 'yyyyMMdd-HHmmss')
)

$SearchRoots = @(
    (Get-Location).Path
    $PSScriptRoot
    "$env:ProgramData\Sentinel"
    "$env:SystemRoot\Temp"
    $env:TEMP
) | Where-Object {
    $_ -and (Test-Path -LiteralPath $_)
} | Select-Object -Unique

$MsiPath = $null
foreach ($SearchRoot in $SearchRoots) {
    $Match = Get-ChildItem `
        -LiteralPath $SearchRoot `
        -Filter $MsiName `
        -Recurse `
        -File `
        -Depth 5 `
        -ErrorAction SilentlyContinue |
        Sort-Object LastWriteTime -Descending |
        Select-Object -First 1

    if ($Match) {
        $MsiPath = $Match.FullName
        Write-Output "Found installer at: $MsiPath"
        break
    }
}

if (-not $MsiPath) {
    Write-Output "ERROR: $MsiName was not found in the RemoteOps working locations."
    Write-Output 'Searched:'
    $SearchRoots | ForEach-Object { Write-Output "  $_" }
    exit 10
}

$Process = Start-Process `
    -FilePath 'msiexec.exe' `
    -Wait `
    -PassThru `
    -NoNewWindow `
    -ArgumentList @(
        '/i', "`"$MsiPath`""
        "ACCOUNTID=$AccountId"
        '/qn', '/norestart'
        '/l*v', "`"$MsiLog`""
    )

Write-Output "msiexec exit code: $($Process.ExitCode)"

if ($Process.ExitCode -notin 0, 1641, 3010) {
    if (Test-Path -LiteralPath $MsiLog) {
        Write-Output '--- Windows Installer log tail ---'
        Get-Content -LiteralPath $MsiLog -Tail 40
    }
    exit 12
}

Write-Output "Installation complete. Windows Installer log: $MsiLog"
exit 0

The default key-server URL is already included in the MSI. If EchoMark directs you to use another endpoint, add the applicable variables and arguments to the script. :

$KeyServerUrl = 'https://<approved-server>/...'
$MarkingPolicyGuid = '<policy-guid>'

# Add these entries to the Start-Process -ArgumentList array:
"KEYSERVERURL=$KeyServerUrl"
"MARKINGPOLICYGUID=$MarkingPolicyGuid"

Omit MARKINGPOLICYGUID unless you wish to configure particular marking policies for device groups. The service is enabled by default; do not pass ENABLESERVICE=0 in a normal deployment.

2. Create the RemoteOps script

  1. In the SentinelOne Management Console, open the RemoteOps or script-management area and create a new Windows PowerShell script.
  2. Give the script a descriptive name, such as Install EchoMark Screen, and upload or paste Install-EchoMarkScreen.ps1.
  3. Attach the ZIP archive containing echomark.msi.
  4. Enable Delete file immediately after script runs for the attached file so SentinelOne removes its staged copy after execution.
  5. Configure the script to run in the system context. Do not run it as the signed-in user.
  6. Set a timeout long enough for Windows Installer to finish on slower endpoints.
  7. Restrict access to the script because it contains the EchoMark Account ID. Save or publish the script according to the organization's approval process.

The attachment method is the simplest deployment model because the script and installer travel together. An organization may instead download the MSI from an approved internal HTTPS location, but it must add download, signature-validation, error-handling, proxy, and cleanup logic appropriate to its environment.

3. Deploy to pilot endpoints

  1. Select a small group of representative, online Windows endpoints for the pilot.
  2. In the SentinelOne Management Console, open Sentinels, select the endpoints, and choose Actions > Response > Run Script. In consoles with different labels, use the equivalent RemoteOps run-script action.
  3. Select Install EchoMark Screen.
  4. Confirm that the MSI ZIP is attached and select the SentinelOne cloud as the output destination.
  5. Review the endpoint scope carefully, then run the task.
  6. Open the RemoteOps task or automation-task view and monitor each endpoint's status and captured output.

Do not deploy broadly until the pilot verifies installation, startup, connectivity, watermark behavior, and protection-state reporting. For a staged rollout, use Pilot, Early Production, and Broad Production endpoint groups, reviewing results between phases.

4. Validate the installation

For a successful run, RemoteOps output should report Windows Installer exit code 0, 1641, or 3010. Codes 1641 and 3010 mean the installation succeeded and Windows requires a restart; the script does not initiate one.

On pilot endpoints, confirm that:

  • C:\Program Files\EchoMark Screen\Alphamark.exe exists.
  • EchoMark Screen appears in Settings > Apps > Installed apps.
  • The AlphaMarkSvc service is installed, running as Local System, and configured to start automatically.
  • HKEY_LOCAL_MACHINE\Software\EchoMark\EchoMark Screen contains the expected version and configuration.
  • The desktop application starts for an interactive user session.
  • The endpoint reaches the configured key server and reports the expected protection state in EchoMark administration.
  • The configured visible or invisible watermark behavior operates as expected.

5. Permissions and security caveats

  • Run the MSI in the device/system context. Installation writes to C:\Program Files, creates machine-wide registry values, registers an Application event-log source, and creates and starts a Windows service.
  • Keep AlphaMarkSvc configured to run as Local System. It requires privileges used to find interactive sessions, launch Alphamark.exe with each signed-in user's token, and stop those processes when the service stops. Changing the service account can leave the service running without enforcing or launching the watermark.
  • Alphamark.exe runs as the signed-in user and is not elevated. The service runs in session 0 and does not display the watermark directly.
  • Do not grant users write access to C:\Program Files\EchoMark Screen or its service subfolder.
  • The MSI hides ACCOUNTID from verbose Windows Installer logs, but the value remains present in the RemoteOps script and in the endpoint's machine-wide EchoMark configuration. Restrict access to scripts, task definitions, output, and the applicable registry key.
  • Enable deletion of staged attachments after execution. The local MSI log remains in C:\Windows\Temp for troubleshooting and should be retained or removed according to organizational policy.

Related to

Can't find what you're looking for?

Contact us