A few days ago at work, I went to connect to a headless server at work, and it indicated that I couldn’t connect because all the Terminal Services connections were in use. What now?

There are graceful ways around the issue. You can (a) Reset one of the connections remotely, freeing up room for you, or (b) Connect to the computer’s console session and then reset the sessions from a GUI interface.

Resetting connections remotely. This method is more graceful, but requires a bit more work. As Scott Forsyth described in Managing Terminal Services Sessions Remotely, the qwinsta (query windows station) and rwinsta (reset windows station) commands can help you accomplish this.

Use qwinsta to find a session to clear, or reset:

C:>qwinsta /server:MyServerName
SESSIONNAME USERNAME ID STATE TYPE DEVICE
0 Disc rdpwd
rdp-tcp 65536 Listen rdpwd
console 5 Conn wdcon
rdp-tcp#59 MyUserName 2 Active rdpwd

In this example, “MyUserName” has a session, and I could clear that session to take it’s place. To do that, I would use rwinsta to clear the session, which has an ID of 2:

C:>rwinsta 2 /server:MyServerName /V
Resetting session ID 2
Session ID 2 has been reset

With the session being reset, I could now successfully login with Remote Desktop.

Connecting to a console session. Windows will always have a console session, which is the session that represents the session outputting to the physical monitor, if one were plugged in. If a user were logged into the machine and physically using the mouse, keyboard, and monitor that are plugged into the machine, and you then connected remotely to the console session, their session would be disconnected and you would connect to that console session. Obviously, this is not the typical approach you would want to take, but it is an option when you need to force yourself onto the computer.

Basically, this is accomplished by running Remote Desktop from the command line (mstsc) and invoking the command line argument to connect to the console session.

mstsc -v:MyServerName -console

That’s all there is to it! At that point, you can either proceed with your work or use the console session to clear any other Terminal Services sessions in the Terminal Services control panel.

This is pretty funny. Apple contracts various companies to manufacture their iPods, and apparently one company mistakenly allowed a situation where the iPods were being manufactured and released with the RavMonE.exe virus, effectively serving as Typhoid Mary devices for any Windows customers.

Apple is taking steps to correct the matter, and apparently it is an extremely small percentage (less than 1%) of affected iPods.

In the Information Week article “Apple Says Shipped iPods Carrying Computer Virus“, statements from both Apple and Microsoft are quoted. Allow me to translate and paraphrase.

Apple: “We’re sorry for shipping our iPod with a Windows virus. Gee, it’s too bad Windows is so bad with viruses.”

Microsoft: “Yeah, but you’re stupid for letting the virus get on your product, even if, erm, it doesn’t affect your own OS. Just watch it in the future, will ya?”

During the same week that Microsoft announces that they would be removing support for UEFI from Windows Vista, some hackers finally establish a method to install Windows XP on Intel Macs (legally, I might add!).

That is exciting, and the timing is of course very comforting.

I was naturally livid when I read about Microsoft pulling UEFI support from Windows Vista on March 14. For many users who highly prefer Mac OS X but want the flexibility to use Windows when necessary, the Intel transition was an excitement followed by frustration when we realized that Windows XP was not cognizant of UEFI. For us, Windows Vista seemed the best, cleanest solution. eWeek’s David Morgenstern holds that Microsoft’s EFI pullback is Apple’s gain, which is a positive attitude but I don’t feel there is much realistic validity to his opinion; Vista’s EFI-lessness gives Mac users one more bullet on their bragging rights list. That helps us dual-boot Windows on our Macs how? And it makes Windows users wish they were running OS X for what major benefits?

Furthermore, Microsoft is not expressing any interest in expediting the development of a Universal, Intel native version of Virtual PC.

Although there have been understandable and reasonable explanations for both of these scenarios that are unrelated to Microsoft’s interest in the success of the new Macs, the zeal in us loyalists moves us to irritation and suspicion that Microsoft may be making a passive/aggressive move to frustrate the Intel transition.

Alas, another day, another innovation in this incredibly busy year in the Apple universe. Some hackers have finally been able to answer the challenge on OnMac.net to successfully get Windows XP installed on an Intel Mac! He has posted photos and even a video as proof of accomplishment, in addition to the required patched files and instructions. At this point, it has been tested and verified by numerous sources and testers.

My need to purchase a new PC just vanished.. Sorry, Dell!

Article: Web Site Reports Intel Mac Dual-Boot Breakthrough.

If you’re familar with the Darwine project, then this isn’t anything new. And this tidbit of news itself is already a couple weeks old, but I never got around to posting it, and I wanted to bring it up.

Darwine is an open source project for Macs (via OS X’s open source Darwin) that piggy-backs on the WINE open source project for Linux. Basically, it is a project to allow Windows applications to run on your computer without the Windows operating system. It does this by emulating the Windows APIs.

So a Red Hat box could run a Windows application side-by-side its X11 apps. This is obviously a bit easier on an x86 build of Linux; thus the separate project–Darwine–for running Windows apps on Mac OS X on a non-Intel processor. Well, with the advent of Mac OS X going Intel native, this task just got a whole lot easier. Which is a relative statement, of course, because in general the premise of the project is very challenging, and notably also very volatile. For instance, the project is limited in what applications can run, and this is after years of development during the stagnant period of Windows XP inactivity. With the release of Windows Vista, undoubtedly the project will be broken yet again for quite some time.

But my purpose isn’t pessimism. My featured article today (MacSlash: Darwine Not Functional On Intel Macs) reports the great progress they’ve made in getting Darwine to work on Intel Macs, and ponders the possibilities of future progress. It is exciting to see this development; it is very sad that this project will probably never have the time or development energy to mature into something that can be used on a wide scale.

Nevertheless, it is worth keeping an eye on!