\fR.\fIdomain\fR to automatically detect KMS servers via DNS for \fIdomain\fR (example: vlmcs .example.com). Please note the dot before \fIdomain\fR.
.br
\fI-\fR (a single dash) to detect KMS servers in your own domain.
.RE
If you use \fIipaddress\fR:\fIport\fR as the \fItarget\fR, the \fIipaddress\fR must be enclosed in brackets
if it contains colons, e.g. [2001:db8:dead:beef::1]:1688. If you use a link-local IPv6 address on Unix systems, you must append a percent sign and the
interface identifier of the source interface, for example fe80::dead:beef%eth0.
.PP
If you omit the \fItarget\fR, 127.0.0.1:1688 will be used except if you use \fB-i6\fR. In this case the default target is [::1]:1688.
.SHDESCRIPTION
\fBvlmcs\fR is a program that can be used to test a KMS server that provides activation for
several Microsoft products. The KMS server may also be an emulator. It supports
KMS protocol versions 4, 5 and 6.
.PP
.Bvlmcs
generates one or more activation requests for a Microsoft KMS product and sends
it to a KMS server. It then analyzes and displays the responses of the KMS server.
.PP
.Bvlcms
checks both the DCE-RPC protocol and the activation message for correctness and
reports any errors that it finds.
.PP
.Bvlmcs
can also be used to "charge" a KMS server. A Microsoft KMS server sends correct activation messages only if it detects a certain minimum of clients (25 for Windows client OSses, 5 otherwise) on the network. This is Microsoft's futile attempt to prevent running a KMS server in a home environment.
Displays extended version information. This includes the compiler used to build vlmcs, the intended platform and flags (compile time options) to build vlmcs. If you have the source code of vlmcsd, you can type \fBmake help\fR (or \fBgmake help\fR on systems that do not use the GNU version of \fBmake\fR(1) by default) to see the meaning of those flags.
Force a specific version of the KMS protocol. Valid versions are 4.0, 5.0 and 6.0. The default is to select a suitable version according to the \fIapplication\fR selected. You may use \fB-K\fR to send an incorrect protocol version to the KMS server and see how it behaves. Genuine KMS servers return HRESULT 0x8007000D if the KMS protocol is not 4.0, 5.0 or 6.0. Emulators should do the same. When sending a request with an incorrect protocol number, vlmcs ignores the minor protocol number (e.g. sends a v4 request for version 4.1). If the major version number is less then 4, it sends a v4 request. If the major version is greater then 6, it sends a v6 request. In any case the \fIprotocol-version\fR as specified by \fB-K\fR is put in the version fields of the request.
Use KMS data file \fIfilename\fR. By default vlmcs contains product data that is recent when vlmcs was compiled. You may use a more recent KMS data file that contains additional products.
If vlmcsd has been compiled to use a default KMS data file, you may use \fB-j-\fR to ignore the default configuration file.
A Microsoft KMS server uses these GUIDs to have seperate counters for the
already activated clients. A client that does not contact the KMS server
within 30 days will be deleted from the database. Emulated KMS servers
are always fully charged.
.IP"\fB-k\fR \fIkms-guid\fR"
Send requests with a specific
.IR"kms-guid""."
A Microsoft KMS server uses these GUIDs as a product id to decide whether to
grant activation or not. A list of current \fIkms-guid\fRs can be found in
kms.c (table KmsIdList). Emulated KMS servers grant activation unconditionally
and do not check the \fIkms-guid\fR.
.IP"\fB-s\fR \fIactivation-guid\fR"
The \fIactivation-guid\fR defines the actual product, e.g. "Windows 8.1 Professional WMC KMSCLIENT edition". A \fIactivation-guid\fR maps 1:1 to a product key.
However, neither a Microsoft KMS server nor emulated servers check this id.
The \fIactivation-guid\fR is useful in logging to get a specific product description like
"Windows 8.1 Professional WMC". A list of current \fIactivation-guid\fRs can be found in
kms.c (table ExtendedProductList).
.IP"\fB-n\fR \fIrequests"
Send
.Irequests
requests to the server. The default is to send at least one request and enough
subsequent requests that the server is fully charged afterwards for
the \fIapplication\-guid\fR you selected (explicitly with
.BR"-a"" or implicitly by using ""-l"")."
.IP"\fB-T"
Causes to use a new TCP connection for each request if multiple requests
are sent with vlmcsd. This is useful when you want to test an emulated KMS
server whether it suffers from memory leaks. To test for memory leaks use
.B-n
with a large number of requests (> 100000) and then test twice (with and
without
.BR"-T"")."
This option may become neccessary for future versions of Microsoft's KMS
server because multiple requests with different
.IRclients-guids
for the same
.Ikms-id-guid
are impossible in a real KMS szenario over the same TCP connection.
.IP"\fB-c\fR \fIclient-machine-guid\fR"
Normally vlmcs generates a random \fIclient-machine-guid\fR for each request. By using this option you can specify a fixed \fIclient-machine-guid\fR
This causes a Microsoft KMS not to increment its client count because it
receives multiple requests for the same client. Thus do not use
.BR"-c"
if you want to charge a real KMS server.
.IP"\fB-o\fR \fIprevious-client-machine-guid\fR"
If the \fIclient-machine-guid\fR changes for some reason, the real KMS client stores a \fIprevious-client-machine-guid\fR which is sent
to the KMS server. This happens rarely and usually 00000000-0000-0000-0000-000000000000 is used. You can use \fB-o\fR to specify a different
\fIprevious-client-machine-guid\fR.
.IP"\fB-G\fR \fIfilename\fR"
Grabs ePIDs and HWIDs from a KMS server and writes the information to \fIfilename\fR
in format suitable to be used as a configuration file (aka ini file) for \fBvlmcsd\fR(8).
This is especially useful if you have access to a genuine KMS server and want to use
the same data with \fBvlmcsd\fR(8).
If \fIfilename\fR does not exist, it will be created.
If you specify an existing \fIfilename\fR, it will be updated to use the information
received from the remote KMS server and a backup \fIfilename\fR~ will be created.
\fB-G\fR cannot be used with \fB-l\fR, \fB-4\fR, \fB-5\fR, \fB-6\fR, \fB-a\fR, \fB-s\fR, \fB-k\fR, \fB-r\fR and \fB-n\fR
.IP"\fB-w\fR \fIworkstation-name"
Send requests with a specific
.IR"workstation-name""."
This disables the random generator for the workstation name. Since it is
a comment only, this option does not have much effect.
.IP"\fB-r\fR \fIrequired-client-count"
Also known as the "N count policy". Tells the KMS server that successful activation requires
\fIrequired-client-count\fR clients. The default is the
\fIrequired-client-count\fR that the product would need if the request
was a real activation. A Microsoft KMS server counts clients
up to the double amount what was specified with \fB-r\fR. This option
can be used to "overcharge" a Microsoft KMS server.
.IP"\fB\-t\ \fIstatus\fR"
Reports a specific license status to the KMS server. \fIstatus\fR is a number
that can be from 0 to 6. 0=unlicensed, 1=licensed, 2=OOB grace, 3=OOT grace,
4=Non-genuinue grace, 5=notification, 6=extended grace. Refer to
for more information. A Microsoft KMS server collects this information for
statistics only.
.IP"\fB-g\fR \fIbinding-expiration\fR"
This tells the KMS server how long a client will stay in its current license
status. This can be the remaining OOB time (the grace peroid that is granted between installation of a product and when activation is actuall required) or
the remaining time when KMS activation must be renewed.
\fIbinding-expiration\fR is specified in minutes. A Microsoft KMS server
apparantly does not use this information.
.IP"\fB-i \fIprotocol-version\fR"
Force the use of Internet protocol \fIprotocol-version\fR. Allowed values are 4 (IPv4) and 6 (IPv6). This option is useful only if you specfiy a \fIhostname\fR and not an
\fIip-address\fR on the command line.
.IP"\fB-p\fR"
Do not set the RPC_PF_MULTIPLEX flag in the RPC bind request. This can be used to test if the KMS server uses the same setting of this flag in the RPC bind respone. Some KMS
emulators don't set this correctly.
.IP"\fB-N0\fR and \fB-N1\fR"
Disables (\fB-N0\fR) or enables (\fB-N1\fR) the NDR64 transfer syntax in the RPC protocol. Disable NDR64 only in case of problems. If NDR64 is not used, vlmcs cannot detect many RPC protocol errors in KMS emulators. If you want to test whether a KMS emulator fully supports NDR64, you must use the \fB-n\fR option to send at least two requests. This is because Microsoft's client always sends the first request using NDR32 syntax and subsequent requests using NDR64 syntax.
.IP"\fB-B0\fR and \fB-B1\fR"
Disables (\fB-B0\fR) or enables (\fB-B1\fR) bind time feature negotiation (BTFN) in the RPC protocol. Disable BTFN only in case of problems. If BTFN is not used, vlmcs cannot detect many RPC protocol errors in KMS emulators.
.PP
Options that do not require an argument can be specified together with a single
dash, e.g. vlmcs -6mvT. If you specify an option more than once, the last occurence
will be in effect.
.SHFILES
.IP"\fBvlmcsd.ini\fR(5)"
.SHEXAMPLES
.IP"\fBvlmcs kms.example.com"
Request activation for Windows Vista using v4 protocol from kms.example.com.
Repeat activation requests until server is charged for all Windows products.
.IP"\fBvlmcs -"
Request activation for Windows Vista using v4 protocol from a KMS server that is published via DNS for the current domain.
.IP"\fBvlmcs .example.com"
Request activation for Windows Vista using v4 protocol from a KMS server that is published via DNS for domain example.com.
.IP"\fBvlmcs -6 -l Office2013 -v -n 1"
Request exactly one activation for Office2013 using v6 protocol from
Get ePIDs and HWIDs from kms.bigcompany.com and create/update /etc/vlmcsd.ini accordingly.
.SHBUGS
Some platforms (e.g. Solaris) may have a \fBman\fR(7) system that does not handle URLs. URLs may be omitted in the documentation on those platforms. Cygwin, Linux, FreeBSD and Mac OS X are known to work correctly.
