Surpass - Secure Client (what a pain)

[3s-gtech]

1 minute ago, JonFromRHS said:

 

previous deployments have been via GPO and attaching the MSI to the room OU in GPO management. 
 

however since that deployment I use IMPERO to run the app and allow it auto update during start up. 

We are running 24H2 though. 
 

Can you set up a 24H2 VM to test if you still get the same errors?

 

Could be Surpass haven’t updated their MSI for use with 25H2 yet?

The board say they've tested it with 25H2.

 

In the logs I get this, no idea if it's relevant:

 

<event>

  <type>Critical</type>

  <time>16:13:13 Thu 23 Apr 2026</time>

  <text>Error occurred: {{Ok Harpy.v1.eagle {i1: [EMBEDDED] Plugin "Licensing.Core" context extra features are now &lt;null&gt; via TRUSTED configuration resource "Harpy.v1.eagle" with a change count of 0.

}} {Error {C:\Program Files (x86)\SecureClient\SecureClient_WJEC\lib\Harpy1.0\Configurations\Harpy.v1.eeagle} {not valid after 2026-01-19T00:00:00.0000000Z}}} {}


   MethodName:RunCommand, ClassName:SecureClientCore\data\DatabaseMigrationCommon.cs

   LineNumber:108</text>

</event>

 

[3s-gtech]

1 minute ago, 3s-gtech said:

The board say they've tested it with 25H2.

 

In the logs I get this, no idea if it's relevant:

 

<event>

  <type>Critical</type>

  <time>16:13:13 Thu 23 Apr 2026</time>

  <text>Error occurred: {{Ok Harpy.v1.eagle {i1: [EMBEDDED] Plugin "Licensing.Core" context extra features are now &lt;null&gt; via TRUSTED configuration resource "Harpy.v1.eagle" with a change count of 0.

}} {Error {C:\Program Files (x86)\SecureClient\SecureClient_WJEC\lib\Harpy1.0\Configurations\Harpy.v1.eeagle} {not valid after 2026-01-19T00:00:00.0000000Z}}} {}


   MethodName:RunCommand, ClassName:SecureClientCore\data\DatabaseMigrationCommon.cs

   LineNumber:108</text>

</event>

 

I'm not going to gain much with testing on 24H2, but I may have to tomorrow. No point in deploying it though even if that fixed it - the clients would re-update before the exam.

[JonFromRHS]

1 minute ago, 3s-gtech said:

I'm not going to gain much with testing on 24H2, but I may have to tomorrow. No point in deploying it though even if that fixed it - the clients would re-update before the exam.

I just meant to rule it out as being a possible cause. 
 

just run you error through Gemini and it came back with this information. 
 

 

 

The error message indicates that a security configuration file (Harpy.v1.eeagle) has an expired trust certificate. Specifically, the configuration is "not valid after 2026-01-19."

Because this file is part of the core licensing and "Trusted Configuration" resource for the WJEC SecureClient, the software is blocking the installation or launch because it views the local package as compromised or outdated.

Recommended Solutions

Since you are deploying this on 25H2 machines, there are three primary ways to resolve this:

1. Download the Updated Installer from WJEC

The most common cause for this error is using an older .msi or .exe installer that was bundled with a certificate which has now expired.

• Log in to the WJEC Secure Website or the Surpass Portal.

• Download the absolute latest version of the SecureClient installer.

• Note: If your current installer was downloaded prior to January 2026, it will likely continue to fail with this specific "Harpy" error.

2. Perform a "Clean" Reinstall

If the new installer fails, residues from the previous installation (including the expired Harpy configuration) may be interfering.

1. Uninstall the existing WJEC SecureClient.

2. Manually delete the following folders if they remain:

   • C:\Program Files (x86)\SecureClient\SecureClient_WJEC

   • C:\ProgramData\Surpass (This often contains cached configuration GUIDs).

3. Restart the machine and run the latest installer as an Administrator.

3. Check System Time and Date

While the error explicitly mentions a 2026 expiry, ensure the system clock on your 25H2 machines is synchronized. If a CMOS battery is failing or the BIOS time is incorrect, the trust validation for the Licensing.Core plugin will fail immediately.

---

Technical Context for IT Admins

The error highlights a failure in the DatabaseMigrationCommon.cs at Line 108. This suggests that during the initial setup/migration of the local database:

• The client attempts to verify its "Trusted configuration."

• It finds that the Harpy configuration (which governs the SecureClient’s locked-down environment) is no longer valid.

• The "change count of 0" indicates it hasn't been updated or patched locally to extend that validity.

If you are deploying via SCCM or Intune: Ensure you are not accidentally deploying a cached version of the app. Refresh your application package with the latest binaries provided by WJEC/BTL.

[3s-gtech]

That’s how I read it. Something has expired in the compiled program and our 25H2 setup is saying nope. Then stopping the DB from being created, which then throws the SQL error. This is on latest and previous versions.

 

Shoddy.

Edited April 23 by 3s-gtech

[JonFromRHS]

8 hours ago, 3s-gtech said:

That’s how I read it. Something has expired in the compiled program and our 25H2 setup is saying nope. Then stopping the DB from being created, which then throws the SQL error. This is on latest and previous versions.

 

Shoddy.

are you performing a clean install with nothing remaining from the previous installs?

[3s-gtech]

Yes. No SecureClient folder present.

[JonFromRHS]

11 minutes ago, 3s-gtech said:

Yes. No SecureClient folder present.

Ok referred Gemini to the message it gave prior asking if the machine is clean with nothing remaining from the previous WJEC Surpass installation is it safe to assume its the HARPY CONFIGURATION causing the issues.


 

Yes, your assumption is spot on. If you are working with a clean 25H2 machine with no residual folders, and you are still seeing that specific error, the issue is almost certainly the Harpy configuration file bundled within the installer itself.

Here is a breakdown of why the Harpy configuration is the culprit in this scenario:

1. The "Hard-Coded" Expiry

The Harpy configuration (specifically Harpy.v1.eeagle) acts as a digital "seal" for the software's security environment. It isn't just a setting; it's a signed resource.

• If the certificate within that file expired on 2026-01-19, and your system clock is currently past that date, the software's internal security check (the Trusted Configuration validation) will fail immediately.

• Because the machine is "clean," you've ruled out old cached files. This means the source installer contains the expired certificate.

2. Why 25H2 Doesn't Fix It

Operating system versions (like 25H2) provide the environment, but they don't override the internal security logic of third-party apps like Surpass.

• Even on the newest OS, the software is programmed to trust its own files only if the signature is valid.

• The error at DatabaseMigrationCommon.cs confirms that the software is "self-policing"—it checks its own health before it even finishes setting up the local database.

---

The Verdict

The Harpy configuration is definitely to blame, but specifically, it is the version of that file contained within your installation media.

How to verify this:

If you have access to the installer files (e.g., if you can extract the .msi or browse the setup files), you would likely find that the version of Harpy.v1.eeagle bundled there is the one that expired in January 2026.

The Fix:

You cannot manually "fix" the Harpy file because it is a signed security resource—tampering with it would also cause a validation failure. You effectively need a new installer from WJEC/Surpass that has been re-signed with a new certificate valid beyond 2026.

Quick Tip for IT Admins: If you are in a time crunch and just need to verify this is the issue, temporarily rolling back the system clock to a date in 2025 should allow the installer to proceed. Note: This is only for testing/confirmation; do not do this for actual exams as it will likely cause sync issues with the Surpass servers.

Edited April 24 by JonFromRHS

[JonFromRHS]

17 minutes ago, 3s-gtech said:

Yes. No SecureClient folder present.

Further checking 

 

System Clock Roll back (bios and OS) check installation.

Create a 25H2 clean build or VM

 

Test WJEC Surpass on the clean Environment.

Then once and for all you have evidence of it being the Harpy configuration file that is containing an invalid security signature for the date required especially if you do a clock roll back as suggested at the end.

Edited April 24 by JonFromRHS

[JonFromRHS]

19 minutes ago, 3s-gtech said:

Yes. No SecureClient folder present.

Just running it on my own office machine now with an installer from 17-4-26

 

Successfully installed.

 

I will add this msi to my onedrive and DM you a link to it.

 

 

[JonFromRHS]

23 minutes ago, 3s-gtech said:

Yes. No SecureClient folder present.

 

 

DM'd you the onedrive link

[3s-gtech]

I've spun up a 25H2 VM clean install with the latest install MSI, which I can then test with one of our exam users which has the lockdowns set in GP.

[3s-gtech]

It's taken an age because the host is slooooow, but I have it working on a fresh 25H2 built VM. That means there's something else interacting. I'm going to try a new command line install with no existing folder on clients. Thanks for the confirmations!

[3s-gtech]

Ah, seem to have found where the issue lies. After a few restarts, if I leave the Group Policy which installs SecureClient attached to the clients (with msiexec /i), it actually removes the software and refuses to put it back. So, I robocopy the contents across and basically say no, don't do that.

 

Qualität.

[jthompson]

Recently moved to Chocolatey-based app deployment here, and I've been having fun building a working Chocolatey package for WJEC Surpass. Previously I was deploying it via Group Policy managed software, but want to move away from that to avoid having to wait for reboots, and for reboots to be slowed waiting for software deployments to complete.

 

I'm posting this in case it helps anyone out who might be installing via a script of some description.

 

I've discovered that to get this MSI to install properly from a scheduled task run by SYSTEM, the following msiexec parameters are required.

 

CMDLINE=/DEFAULT_INSTALL_DIR="C:\Surpass_WJEC" /qn ALLUSERS=1 MSIINSTALLPERUSER=""

 

The last two are both required in order to have it install machine-wide (shortcuts are missing otherwise), and not as a per-user install into the SYSTEM profile.

 

Redeploying new versions of the MSI as they become available seems best, as it reduces reliance on the self-update-on-launch, which seems to regularly present a requirement to redeploy a later version anyway, and it also means that the version shown in appwiz.cpl is more likely to be correct (self-updating doesn't update that value). Also, fresh deployments are more likely to be ready to go.

Edited April 29 by jthompson