phaqphaq

Darn it!
Imagine what happens when a Windows box, which is configured for remote administrative terminal mode only, is left with two zombie terminal sessions.

Maybe you are lucky, and Terminal Services Manager does the job for you. In theory, one might connect another host for management purposes.
In case your administrative credentials are different from the ones on the destination host, Terminal Services Manager might throw an insufficient permissions error at you.

So it was in my case, which I worked around like this:

First I opened up a command shell (Start – Run – cmd + OK), from which I ran this command:

C:\\Documents and Settings\\Administrator>net use o: \\\\192.168.13.205\\c$ /user:Administrator

The password or user name is invalid for \\\\192.168.13.205c$.

Enter the password for 'Administrator' to connect to '192.168.13.205':

The command completed successfully.

This asked me for the credential of the remote system’s Administrator
and connected it’s shared C: drive to my system.
In fact, connecting the share isn’t required, everything else works too, as long as you’re prompted to enter the credentials for the remote systems.
In my experience, connecting a share proved to work out properly in most cases.

So afterwards, I ran this command to list the remote server’s terminal sessions:

C:\\Documents and Settings\\Administrator>qwinsta /server:192.168.13.205
 SESSIONNAME       USERNAME                 ID  STATE   TYPE        DEVICE
 console                                     0  Conn    wdcon
 rdp-tcp                                 65536  Listen  rdpwd
 rdp-tcp#10        Administrator             2  Active  rdpwd
 rdp-tcp#16        Administrator             3  Active  rdpwd

So, to kill any or all of these sessions, run this command:

C:\\Documents and Settings\\Administrator>rwinsta rdp-tcp#10 /server:192.168.13.205

It’s also possible to kill a session by it’s ID, which works like this:

C:\\Documents and Settings\\Administrator>rwinsta 3 /server:192.168.13.205

Let’s check out if our zombie sessions are gone now:

C:\\Documents and Settings\\Administrator>qwinsta /server:192.168.13.205
 SESSIONNAME       USERNAME                 ID  STATE   TYPE        DEVICE
 console                                     0  Conn    wdcon
 rdp-tcp                                 65536  Listen  rdpwd

So it looks good after all, the sessions are gone and I can reconnect the server using rdpclient as usual.

So let’s disconnect the share now, as in fact it wasn’t used for anything except to store the credential.

C:\\Documents and Settings\\Administrator>net use o: /delete
o: was deleted successfully.

By the way, if you don’t want to encounter these hassles over and over again, terminal server can be configured to automatically terminatate stale/inactive sessions.
Find more about this in the Microsoft Knowledge Base.

I just trapped myself while hacking up a batch file.
Used to shell scripting I wanted to add a delay to the batch using “sleep”.

Dough! Bad Idea! Bad command or filename. Smash your head here to continue {(x)}!

So I winded up my memories from stoneage. Wasn’t there the choice command!?

Yeah, after some lurking around with the ‘/?’ feature I had stuck it together:

choice /c 1 /d 1 /t 1 > nul

While

• “/c 1″ sets the choice values (1 is my value)
• “/d 1″ sets the default choice value (which is 1 from above)
• “/t 1″ sets the timeout to 1 second (or whatever is appropriate)
• “> nul” means the same as “>/dev/null”: send output to nirvana (notice there being only one ‘l’ however)

Of course this may be bothersome to type if you use it often, so a “batch function” may be better, especially when you need other batch tricks to get around DOS command limitations (lazy man’s approach: create a second batch file for it).

@echo off

rem *******************
rem check args
rem *******************

:checkargs

if "%1/" == "func/" goto callfunc
goto main

:_checkargs

rem *******************
rem call functions
rem *******************

:callfunc
 shift

 rem we could do "goto %1" instead
 rem if there is a lot of functions
 if "%1/" == "sleep/" goto sleep

 goto exit

:_callfunc

rem *******************
rem function sleep
rem *******************

:sleep
 shift

 choice /c 1 /d 1 /t %1 > nul

 goto exit

:_sleep

rem *******************
rem main body
rem *******************

:main
 echo hello, going to sleep now
 call %0 func sleep 1

 echo sleep is over, good bye

 goto exit

:_main

rem *******************
rem exit handler
rem *******************

:exit
 rem if there is anything left to do, do it now.

:_exit

I would have supposed that installing Office 2003 on Windows Vista would simply work.
My assumption was so terribly wrong. Not soon after starting Setup it throws this error message at me:

Error 1913: Setup cannot update file
C:\\WIndows\\system32\\mapisvc.inf.
Verify that the file exists in your system and that you have
sufficient permissions to update it.

So, oviously an issue with Outlook (mapisvc) registering itself in the system.
Running Setup without installing Outlook was just fine. So was when installing Outlook without MAPI (the “Exchange” stuff…) features.
I hoped it to be simply a file permission issue causing setup to fail on updating mapisvc.inf. Looking at the file permissions showed me this:

C:\\Windows\\System32>cacls mapisvc.inf
C:\\Windows\\System32\\mapisvc.inf NT SERVICE\\TrustedInstaller:(ID)F
                                PREDEFINED\\Administrators:(ID)R
                                NT-AUTHORITY\\SYSTEM:(ID)R
                                PREDEFINED\\USERS:(ID)R

So, my permissions are inadequate? Setup does not account to TrustedInstaller Group?
Fact is: I could not edit the permissions in the first place. It was likely to be some sort of UAC (User Account Control) magic trickery.

So I decided to turn off UAC from control panel, not without needing to reboot the machine first of course. So be it…

This finally enabled me to set the file permissions on mapisvc.inf.
First I re-assigned file ownership from ‘SYSTEM’ to ‘Administrators’. Then I added full access permissions for ‘Administrators’.

After going through all these hassles, Setup did finally not complain any more and installed Outlook 2003 with MAPI features successfully.

A late night experience, thank good I got it fixed right away…

Imagine this setup:

• A Samba file server (primary) and a Windows file server (secondary).
• A DFS root which points to the Samba server (as primary) and the Windows server (as secondary, which maintains a replica of the primary).
• An rsync client (cwrsync) is installed on the Windows server to maintain the DFS replica

Imagine the fact:

• Files/directories which contain special chars (eg. umlauts) in their name copied onto the Samba server end up there correctly (eg. hütte.doc)

Imagine the problem:

• Files/directories which contain special chars in their named copied through rsync onto the Windows server end up there mangled (eg. hütte.doc)

The reason for this behavious is simple: cwrsync is actually nothing else than traditional rsync compiled as win32-binary using cygwin. Now rsync has one major drawback: it’s not (yet) unicode aware, which means that special characters in file names are not properly converted.

Now there are two ways to fix this. Either replace the bundled cygwin library (cygwin1.dll) with another one which is unicode-aware. You find one at the UTF-8 cygwin project website.
Another possibility would be the use of an alternative tool (anything else than rsync) which is unicode-aware or the .NET based rsync port.

I choose to go the UTF-8 cygwin way, which did the trick for me.

I just downloaded the 1.5.21-1 version (I checked the bundled cygwin1.dll version through properties dialog in explorer first to make sure they match), moved the original cygwin1.dll away and replaced it by the download version instead.

By the next time I ran cwrsync my filenames would just look as supposed. Wheew, what a night…!

While I’m usually living on the Unix side of live, I sometimes happen to find myself again in the Windows world.

Some may say this is blasphemy, a decent unix admin would never bother in doing Windows, deny the open source idea, be such a scumbag, blablablabla…

But let me tell you one thing: Windows is not that bad after all. Honestly.

Why can I say: Because I’m writing code on Windows, I’m working with Windows (my personal workstation runs PC-BSD however…), I see and I feel when it makes progress. (Still, I’m a unix admin after all…)

My most recent experience was tonight. I went to setup an AD domain controller on my recently acquired Windows Server 2003 (180-day trial license).

I remember how long this took on my testing system (an ancient Celeron 733 with 1gig of RAM) with Windows 2000 just two weeks ago: almost 30 minutes only to initialize a new AD structure.

The very same process on the same machine with Windows Server 2003: not even five minutes! I could not believe this at first so I repeated this after doing a reinstall – with the same result.

Now this is definitely what I call progress, especially considering this kind of old hardware being used!

And for those who may have wondered: the whole purpose to setup the AD domain controller is to see wether an AD-driven LDAP may be merged with OpenLDAP to provide authentication services in a mixed environment. More about this shall be coming soon…