WinRM Java Client 2.0.00
-
Home
- Reference
Legacy API
Before the fluent WinRMClient[1], the library was used through two static one-shot helpers. They remain fully supported and unchanged — existing code keeps working — but each call opens a connection, authenticates, runs one operation, and closes everything. New code should use the fluent API[2]; see Migrating from 1.x[3] for the mapping.
WQL queries
WinRMWqlExecutor.executeWql(...)[4]:
WinRMWqlExecutor result = WinRMWqlExecutor.executeWql(
protocol, // WinRMHttpProtocolEnum.HTTP or HTTPS (null → HTTP)
hostname, // mandatory
port, // Integer, null → 5985 (HTTP) / 5986 (HTTPS)
username, // "DOMAIN\\user" or "user", mandatory
password, // char[]
namespace, // null → ROOT\CIMV2
wqlQuery, // mandatory
timeout, // long, milliseconds, > 0
ticketCache, // java.nio.file.Path, null for NTLM
authentications // List<AuthenticationEnum>, null/empty → NTLM
);
result.getHeaders(); // List<String> — column names
result.getRows(); // List<List<String>> — values in header order
result.getExecutionTime(); // long, milliseconds
Declared exceptions: WinRMException[5], WqlQuerySyntaxException[6], java.util.concurrent.TimeoutException — all checked.
Remote commands
WinRMCommandExecutor.execute(...)[7]:
WindowsRemoteCommandResult result = WinRMCommandExecutor.execute(
command, // mandatory
protocol, // null → HTTP
hostname, // mandatory
port, // null → protocol default
username, // mandatory
password, // char[]
workingDirectory, // nullable
timeout, // long, milliseconds, > 0
localFileToCopyList, // List<String> of local files to copy first, nullable
ticketCache, // nullable
authentications // null/empty → NTLM
);
result.getStdout();
result.getStderr();
result.getStatusCode(); // process exit code
result.getExecutionTime();
Files listed in localFileToCopyList are copied to the host first, and each reference to them in command is rewritten to the remote copy — the same engine as the fluent upload(...); see File Transfers[8].
Declared exceptions: java.io.IOException, java.util.concurrent.TimeoutException, WindowsRemoteException[9] — all checked.
Behavior notes
- One connection per call: every invocation performs a full authentication handshake. Code that polls the same host repeatedly pays that cost on every call — the main reason to move to the reusable
WinRMClient. - The output character set of a command is detected before each call (one extra WQL query per call; the fluent client caches it).
- TLS configuration is global only: the
org.metricshub.winrm.tls.insecuresystem property (see TLS / HTTPS[10]); there is no per-call trust store. - Authentication schemes come from
AuthenticationEnum[11] (NTLM,KERBEROS), with the same ordered-fallback semantics as the fluentAuthScheme[12]. - For advanced use, the underlying reusable executor is also public:
WinRMExecutorFactory.createInstance(...)[13] returns aWindowsRemoteExecutor[14] — but the fluentWinRMClientis the supported way to get connection reuse.
- [1] apidocs/org/metricshub/winrm/WinRMClient.html
- [2] index.html
- [3] migrating-from-1x.html
- [4] apidocs/org/metricshub/winrm/wql/WinRMWqlExecutor.html
- [5] apidocs/org/metricshub/winrm/exceptions/WinRMException.html
- [6] apidocs/org/metricshub/winrm/exceptions/WqlQuerySyntaxException.html
- [7] apidocs/org/metricshub/winrm/command/WinRMCommandExecutor.html
- [8] file-transfers.html
- [9] apidocs/org/metricshub/winrm/exceptions/WindowsRemoteException.html
- [10] tls.html
- [11] apidocs/org/metricshub/winrm/service/client/auth/AuthenticationEnum.html
- [12] apidocs/org/metricshub/winrm/AuthScheme.html
- [13] apidocs/org/metricshub/winrm/service/WinRMExecutorFactory.html
- [14] apidocs/org/metricshub/winrm/WindowsRemoteExecutor.html
