Deploying across a fleet
There is an MSI for Intune and Group Policy. Before you plan a rollout, read the first section — the installer is unsigned, and that has consequences for deployment tooling that are better known now than halfway through.
Start here
The unsigned installer, and what it means for you
The MSI is not code-signed. Deployment tooling treats unsigned packages differently and some environments refuse them outright:
- Intune will deploy an unsigned MSI, but SmartScreen and any application-control policy may still block execution on the endpoint.
- WDAC or AppLocker policies that require a publisher signature will block it. A hash rule is the usual workaround, and it has to be updated for every release because the hash changes.
- SmartScreen reputation for unsigned software is tied to the file hash, so it resets with each release rather than accumulating.
If your environment requires signed binaries, the honest answer is to wait until signing is in place rather than to work around the policy. Current signing status.
Packaging
What the MSI does
- Scope
- Installs the application. Nothing is registered as a service and nothing is added to startup.
- Dependencies
- The Microsoft Edge WebView2 runtime is required. It is present on current Windows 11 and updated Windows 10; where it is missing, endpoints need either the WebView2 Evergreen runtime deployed separately or internet access during install.
- Npcap
- Not included and not installed. Only Port Finder and Packet Capture need it. If your users need those, deploy Npcap separately from its own installer.
- Elevation
- The application runs as a standard user. Packet capture requires elevation at runtime; nothing else does.
- Data location
- Saved connections, pinned host keys and transcripts live in the user profile, so they follow a roaming profile and are removed with the user, not with the application.
- Uninstall
- Standard MSI uninstall. User data in the profile is deliberately left in place.
Installing
Command line and Intune
msiexec /i CySecTek_0.7.1_x64_en-US.msi /qn /norestartmsiexec /i CySecTek_0.7.1_x64_en-US.msi /qn /norestart /l*v install.logmsiexec /x CySecTek_0.7.1_x64_en-US.msi /qn /norestartIntune (Win32 or MSI app)
- Upload the MSI as a Line-of-business app, or wrap it as a Win32 app.
- Verify the SHA-256 against the published value before uploading. With no signature, this is the only thing establishing provenance.
- Set the detection rule on the installed executable version rather than on a file hash, so it survives the next release.
- Pilot on a small ring first, specifically to find out how your application-control policy treats an unsigned binary.
Worth knowing
Policy questions this raises
Deploying a tool that stores credentials and can run capture and provisioning services is a decision worth making deliberately.
Credential storage
Each user sets an app password that encrypts their saved credentials. It cannot be recovered — not by them and not by you. There is no administrative reset and no escrow.
Detail →Provisioning services
Users can start TFTP and DHCP servers. A DHCP server bound to a production interface hands out addresses that conflict with the real one. Worth covering in your own guidance.
Detail →Transcripts
Session logging is off by default. When enabled it writes encrypted transcripts to the user profile, which routinely contain running-config and community strings.
Detail →Deploying this somewhere large and want to talk it through first?