Probably several times, and usually, you had to log in using either VNC or RDP (Remote Desktop Protocol – Microsoft Terminal Services). If you’re used to SSH, you may wonder why the overhead of a complete desktop is needed just to start a few text commands.
Of course, there are free and commercial SSH servers for Windows, but one problem with them is that they have to be installed separately. Which may be too much work for a one-off task now and then. Are there any other methods of accessing a remote Window text console from your Linux station?

But hey, here comes winexe to the rescue! Below, accessing Windows CLI from Linux remotely (using a Windows domain account):

From the project’s page, “winexe remotely executes commands on WindowsNT/2000/XP/2003 systems from GNU/Linux (probably also other Unices capable to compile Samba4)“.

Some notes:

• note that winexe doesn’t offer encryption of any kind – you may want to use VPN to make sure your connection is secure,
• if your distribution doesn’t offer a packaged version of winexe (most distributions don’t), winexe homepage offers a static binary; on the other hand if you have a recent Linux distribution, the static binary will most probably not work for you – in that case, just build the tool from source,
• you can use winexe in your Linux scripts – this way, you may execute certain tasks on your Linux machines, other tasks on your Windows machines – all that as a part of one bigger task / script,
• winexe can be seen as a Linux equivalent of psexec (a similar tool available for Windows).

Useful examples:

• See the list of processes / logged in users. Useful if you want to log in via RDP but don’t want to interrupt user session. Useful in a script, to check more workstations.

winexe --system -U 'DOMAIN\Administrator%password' //192.168.10.21 "tasklist /V"

• Start cmd.exe console:

winexe --system -U 'DOMAIN\Administrator%password' //192.168.10.21 cmd.exe

Normally one configures Samba to use a CUPS server running on the same host. When a user wants to print anything, Samba uses a username/password to access the CUPS server. After authorization checks are successful, Samba connects to CUPS as root, and thus, bypasses all security checks (they were done just a while ago with username/password).

So, if a CUPS server requires authentication, including for jobs scheduled from a localhost, printing from Windows clients will most likely fail. This is because Samba, as a CUPS client, runs on a localhost.
Of course, a change to allow printing from a localhost is trivial – just add or uncomment Allow localhost in <Location /> section of /etc/cups/cupsd.conf. Some distros will have this as a default setting (Debian seems to be more restrictive though).

What if we want to allow everyone to print from the localhost, but require credentials from all other hosts? Well, here it is:


# Restrict access to the server...
<Location />
AuthType Basic
Require valid-user


Order deny,allow
Deny all
Allow localhost


Satisfy any
</Location>


Why not run a full blown Windows domain controller for a group of small office branches?

In fact, we deployed such a setup in a company I work for. Each branch office has a FSG-3, which runs the following:

• Samba as a Windows domain controller,
• OpenLDAP to sync users between the branches,
• CUPS for printing,
• OpenVPN to secure communication between the branches,
• WPKG for software deployment,
• Unattended for initial Windows deployment,
• ISDN dialin – in case a remote DSL dies, we can always log in using a ISDN telephone line,
• of course, other Linux goodies offered by Debian.

Works great – the solution is really flexible, there is no need to place a traditional PC-server anymore, and moreover, we didn’t have to pay a dime for a Windows Server license.