Forcibly disconnecting users from a remote desktop session
Following on from my last post on how to find out who is connected to a remote desktop session on particular machine, there are occasions when you’ll want to actually forcibly disconnect someone so that you can log on to the machine yourself.
Turns out that there’s a command for that …
There’s a two step process of first identifying who you want to disconnect and secondly of actually disconnecting them. So, how to identify the users connected to the remote session and also how long they’ve been idle:
quser /server:[server name] eg: quser /server:myServer
This gives back a table of information: USERNAME, SESSIONNAME, ID, STATE, IDLE TIME and LOGON TIME. Once you’ve identified who (if anyone) you want to kick off, usually based on who’s been idle the longest, you will need to note down the ID and then use that in the logoff command to actually log the user off:
logoff [id] /server:[server name] eg: logoff 2 /server:myServer
And that’s it!
Here’s a redacted screenshot of the process in action:
Find out who’s logged on to a Remote Desktop Session
It’s a problem I’ve hit multiple times: I need to remote into a server to do some work but there are only a few sessions available and they’re all in use. I could ask someone if they can log off for a while but as it’s possibly one of a number of people this requires a bulk email. What I really need is a way to identify exactly who is logged onto that server so I can ask them if they can log off for a while …
After a fair amount of googling, I tracked down the query session command for Windows which will do exactly this. Here’s an example:
query session /server:[SERVERNAME]
where [SERVERNAME] is the name of the server you are trying to remote onto. So if we were trying to connect to a server named MyServer, we’d enter:
query session /server:MyServer
Here’s redacted example of the command line query in action
There’s a lot more to this command than just the /server switch and the command is covered in detail in a good tech article form Micrsoft available here: http://technet.microsoft.com/en-us/library/bb490800.aspx
My next post covers how to forcibly disconnect users from a session when necessary.
Enjoy!
Modern Corporate R&D
I am based these days in Citi’s research lab in Dublin working on financial mobile solutions. A few weeks ago, Irving Wladawky-Berger came to the Lab to see what we are up to. I didn’t get to meet him unfortunately but he wrote a very interesting blog post on corporate R&D and how it has evolved over the years to meet accelerating change in the outside world and was very positive about Citi’s Dublin lab: http://blog.irvingwb.com/blog/2012/09/the-rise-fall-and-re-invention-of-the-corporate-research-lab.html
Personally, I like the sound of the old-style labs where we just got on with the interesting bits and left Marketing to figure it all out
Cloud Computing, a tech introduction
This is a recent tech presentation I wrote introducing Cloud Computing: what it is, how it works, why it’s important. This is very much a 101-level presentation. Hopefully it will be of some interest!
Unable to replicate from local CouchDB to Cloudant – a quick resolution for the {“error”:”shutdown”} message
Just in case anyone else hits an issue whereby you are unable to replicate a local CouchDB database to Cloudant … I was using Curl on Windows (which never helps of course
) and found that I was unable to replicate from a local instance to Cloudant even though my passwords, ca cert bundle, etc. were all correct. Naturally, it took a couple of goes to get the curl escaping on Windows right but even once I’d figured that out it was still failing with the uninformative
{"error":"shutdown"}
I eventually found some posts that pointed to my (very) out-of-date CouchDB instance being the issue: you need to be running CouchDB 1.2.0 preferably on Erlang R15 for this to work correctly.
I upgraded everything and key presto! It works!
Connecting to Cloudant from Erlang: a quick example of using HTTPS from httpc:request
Wiser heads than me will no doubt already know this but I for one struggled with working out how to do this so I thought I’d put the example up in the hope it will help others. So, what I was trying to do was get and put to a Cloudant database from Erlang. Cloudant requires both HTTPS and a username and password and I struggled to find an Erlang example online.
First, make sure that you can connect to Cloudant over curl and fetch at least the _all_dbs resource. If you can’t, Erlang isn’t going to work either. I found that to get curl working correctly, I needed to update the ca cert bundle that came with it.
Here’s how to retrive _all_dbs for your Cloudant account using curl:
curl https://username:password@username.cloudant.com/_all_dbs
where username is your Cloudant username and password is the password associated with your username. For example, if your username were ‘foo’ and your password ‘bar’, here’s the command you would use:
inets:start(),
ssl:start(),
httpc:request (get, {“https://foo:bar@foo.cloudant.com/_all_dbs”, []}, [{ssl,[{verify,0}]}], []).
It is important to remember to start inets and ssl before attempting to use httpc:request. A put to Cloudant is similar, here’s an example that assumes the existance of a database barfoo and a resource widget on your Cloudant instance and also that you have a suitably initialized variable Update which contains the data which you are writing to the widget resource:
inets:start(),
ssl:start(),
httpc:request (put, {“https://foo:bar@foo.cloudant.com/barfoo/widget”, [], [], Update}, [], []).
And there you have it
How websites work, an introductory tech presentation
I recently gave a tech intro session entitled “How websites work”, a kind of 101 session on the basics of web technology. The session references PHP specifically as that’s the development language at my current employer but most server-side languages work in a similar manner.
Readers of this blog will mostly know this stuff anyway but I was asked to make it available for download so here it is: enjoy!

