The Windows full client is designed for use on any user's device, but it requires administrator rights to install.
The full client supports auto-update. When the user allows it, the update will be applied. To disable the auto-update feature, see the Updating Clients section.
The Windows full client also includes auto-start and remember-me functionality, so it can automatically connect the user at boot time without any user interaction required.
The Windows full client uses standard executables.
Installing the Windows full client
When the installer .exe is run normally (when a user clicks it), then the full client will be installed. The auto-start option will be enabled for the current user. To disable auto-start, install the client using the command line during which you can disable the feature.
If you try to install the full client on top of the lite client, the lite client will be uninstalled and full client installed. The settings for the lite client will be discarded.
If you experience issues installing the TUN driver when other drivers or certain security software are installed, you can check your installation with the following command:
driverquery /v | findstr wintun
Uninstalling the Windows full client
You can uninstall the Windows full client in the following ways:
Right-click on AppGate ZTNA in the start menu and click Uninstall
Run the installer from the command line using the
/zoptionUse the Add or Remove Programs option in Windows
Starting the client with the command line
Once installed, when Appgate SDP.exe is run normally (when a user clicks it), then the full client launches.
It is also possible to pre-install the profile link at this time and remove all subsequent user interactions required. By example; to pre-install a client profile (so the users will be at the sign-in form) run:
"appgate sdp.exe" --url="appgate://controller.myco.com/profilename..." --novalidate
When the .exe is run from the command line then the following options switches may be added (precede each with a space):
--help | Show help |
--url="appgate://controller.myco.com/profilename..." | Adds the new profile profile name |
--novalidate | Used with --url; this option adds the new profile and skips the profile acceptance steps and goes straight to the user sign-in form. |
--loglevel level | Levels are: Error, Warn, Info, Debug [default is: Info] |
--version | Lists the version information. |
Logs
Log Type | Location |
|---|---|
Client installer logs |
|
Client uninstaller logs |
|
Client updater logs |
|
Driver logs | In the separate, AppGate ZTNA driver:
|
Client logs |
For example:
At the end of every day, a log-date and a ui-date record is archived for 30 days.
|
Log Level
There are two ways to increase the log level and capture more detailed logs in the client:
Quit the client and from
%programfiles%\appgate sdp\ui\run:& ".\appgate sdp.exe" --loglevel <value>In the registry (regedit.exe), add a string
<value>calledLogLeveltoComputer\HKEY_LOCAL_MACHINE\SOFTWARE\Appgate
The <value> options are:
DumpTraceDebugInfoWarnErrorFatal
Info is the normal setting. Moving to the right will reduce the amount of log records saved. Moving to the left is not recommended unless instructed to do so by AppGate support.
To return to normal, quit the client and restart.
The multi-user client is designed to be installed on multi-user machines such as terminal servers.
Typically when users run their desktop or published applications on multi-user machines, such as Citrix XenDesktop or Windows Terminal Server, access from the terminal server into the trusted network must be allowed for all applications/users by any internal firewall. This means when users with different roles share the same OS (like Windows TS), it is not possible to perform network layer segmentation.

AppGate ZTNA can still capture the individual user’s network traffic. This is because each user has to sign in to their own AppGate ZTNA Client within the Citrix XenApp or Windows Terminal server session.
When the first user signs in, the shared multi-tunnel virtual network adapter starts.
The first thing it does is intercept all routed traffic for destinations defined in the user's Sites/entitlements. This includes traffic from the system, all applications, and any other users.
It then tries to perform a SNAT operation on the intercepted traffic, substituting in the appropriate user's tunIP address. Because we intercept all routed traffic, when the multi-tunnel virtual network adapter encounters traffic from a source that does not have a matching tunIP address, the traffic will be dropped. This means the behavior of the multi-user host system may change when the first user signs in, as now all traffic destined for a host behind AppGate ZTNA will be intercepted by the AppGate ZTNA system and may be dropped.
The following are a couple of examples of the effect this might have:
Example 1: The first user signs in to AppGate ZTNA on the multi-user host (such as a Citrix server) and receives an entitlement for the same DNS server IPs that are assigned to the operating system of the multi-user host. AppGate ZTNA has a higher route priority than the system, so the DNS server requests are now intercepted by the multi-tunnel virtual network adapter and dropped except for the traffic originating from the signed-in user. The host operating system will no longer be able to resolve DNS queries.
Example 2: If a user signs in to AppGate ZTNA on the multi-user host (such as a Citrix server) and receives an entitlement for a webserverA1 server on 10.10.10.100, then non-AppGate ZTNA users on the same multi-user system will lose the ability to send traffic to webserverA1.
The traffic is then routed to that specific user's tunnel(s) just as in the single-user case. These tunnels will be established when the user signs in to their AppGate ZTNA Client, one to an available Gateway on each of the allowed Sites.
The user's application traffic is routed through their specific encrypted tunnel into the Gateway where firewall and application rule sets, unique to the user are dynamically applied. This means that even when users with different roles share the same OS (like Windows TS) it is now possible to enforced network layer segmentation. This would help customers that require, for example, PCI DSS certification for certain user roles.
Because the operation of the AppGate ZTNA system is essentially the same as for the single user case, there are no configuration settings required to support this mode of operation beyond installing the client with the multi-user option. However the system includes the device claim isMultiUser which will return true/false - this provides the ability to easily alter the configuration if required. This might for instance be used to remove the user's DNS entitlement as the multi-user client uses the operating system's DNS setting.
System limitations for the Windows multi-user client
When using the multi-user Client the IdP DNS settings (including Block Local DNS Requests) are not applied on Client's multi-user host device.
DNS resolution by the multi-user Client will always use the DNS settings set by the operating system of the device.
Because we are routing only user traffic, any system traffic such as ICMP (ping) or SMB (file shares) that are captured by the adapter will not have a matching user's tunnel IP address because the traffic is not seen as coming from a specific user. The packet will therefore be dropped by tun driver as it routes traffic based on matching the user's source IP address. This is a limitation of Windows and not something AppGate can do anything about.
The use of Route all traffic through tunnel is not recommended for the multi-user Client. This would effectively prevent the multi-user host operating system from sending traffic to any network destination, with the exception of the AppGate ZTNA appliances, which are automatically excluded from tunnel traffic.
AppGate ZTNA requires access to a full desktop. Because our application is interactive (user may be required to enter an OTP at any time) then it will not work correctly if the user only has access to one published application.
Standard executables used by the Windows multi-user client
The Windows multi-user client uses standard executables:
Kernel Filter. Added to tag the different users’ traffic that will run as SYSTEM.
Once installed, the client will look and behave exactly like the normal, full client.
Installing the Windows multi-user client
NOTE
The filter driver in the client cannot be installed on systems with SecureBoot enabled. If your system uses SecureBoot then disable it and reinstall the client, then re-enable SecureBoot again.
To install the client as a service, the installation needs to be run with the switch /M. It is recommended to run it using the /S (silent installation) switch. Refer to Windows client for a full explanation of all the installation switch options.
To install the Windows multi-user client in silent mode, enter:
start "" /WAIT "AppGate-SDP-x.y.z-Installer.exe" /M /S /P="appgate://url.com"
PowerShell requires slightly different syntax:
start "Appgate-SDP-x.y.z-Installer.exe" -ArgumentList ' /M /S /P="appgate://url.com" '
NOTE
The profile link included after the /P switch can be obtained from the Client Profiles UI.
Uninstalling the Windows multi-user client
You can uninstall the client in the following ways:
Run the uninstaller from start menu shortcut
Use the Add or Remove Programs option in Windows
NOTE
Any configurations of the client will not be removed on uninstall, only the headless client binaries.
.png?sv=2022-11-02&spr=https&st=2026-04-17T02%3A25%3A21Z&se=2026-04-17T02%3A42%3A21Z&sr=c&sp=r&sig=4lvQF%2FcQrLemPRxPfvweuZSRshiikA76vQGbCHJgteo%3D)