Apple launches Intel Macs (and new iPod accessories)

So, Apple finally launched the new Intel-based iMacs yesterday. These use Intel Core Duo processors (formerly codenamed Yonah), which I think means they are still 32-bit, at a time when the rest of the PC world is finally starting to wake up to 64-bit technologies. Still, at least it’s a step in the right direction (and dual core should whip up performance nicely, although I do doubt Apple’s claims of a doubling in performance simply by going dual core, unless each core is also much faster than the old PowerPC processor).

Of more interest to me are new iPod accessories – like the iPod Radio Remote. Shame it needs an iPod Nano or Video and I’ve only got a Mini.

Telnet issues on Windows Server 2003

I’ve spent a good chunk of this morning trying to get the Telnet service working on Windows Server 2003. By default, this service is disabled and configuring the Telnet service to start automatically and then starting the service is straightforward enough, but when I tried to connect, after supplying username and password details, my clients received the following message:

Failure in initializing the telnet session. Shell process may not have been launched.

Telnet Server has closed the connection

Although the troubleshooting advice for Telnet at the Microsoft Windows Server 2003 TechCenter appears reasonably comprehensive, it didn’t detail this message at all; however Microsoft knowledge base article 309523 does – but only for 64-bit versions of Windows. My telnet server is also a domain controller, and as the advice involves demoting and promoting the server, I chose not to try it on a 32-bit version of Windows (a Google search revealed plenty of anecdotal evidence that it doesn’t work).

I had been trying to establish the connection from a Unix client, so thinking that was the issue, I tried telnet locahost from the server itself but received the same result and checking the application event log revealed various entries similar to the following:

Event Type: Error
Event Source: TlntSvr
Event Category: None
Event ID: 4049
Date: 11/01/2006
Time: 10:00:40
User: N/A
Computer:
servername
Description: Error in creating CMD process. System Error: A required privilege is not held by the client.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Following the link in this event led me to check for the presence of %windir%\system32\login.cmd

One post on the microsoft.public.windows.server.general newsgroup looked hopeful, suggesting that the Secondary Logon service also needs to be started; however, when I checked, the Secondary Logon service was already running on my server. I restarted the Secondary Logon and Telnet services just in case (that made no difference) but the newsgroup post had got me thinking about the credentials used by the Telnet service (by default, this was NT AUTHORITY\LocalService). I changed the service to start using the Local System account, restarted the Telnet service and it started accepting connections. Just to be sure, I changed the credentials back to NT AUTHORITY\LocalService (which does not need a password) and restarted the service, breaking Telnet again. That confirmed that it was related to the service’s logon credentials and I went back to using the Local System account.

I’m not sure what the security implications of this hack are. Pretty severe I imagine, as membership of the TelnetClients security group doesn’t seem to make any difference to whether my users can logon to the server using Telnet or not, but at least I can get a console connection to my server from a Unix client now (my Windows clients can use RDP).