What else happened. Well, I solved the problem I described some days ago, regarding the Windows XP Sysprep stuff. Unfortunately, it didn’t work out the way I actually planned it:

The scheduled task seemed not to be ran, because (at least this is what I guess) Sysprep changes the system’s/system-user’s SIDs within the Mini-Setup. So when a scheduled task is being added to the scheduler while running the Sysprep procedure, it adds the task using the Administrator’s current SID – which won’t be the same after the reboot. Because of that, the scheduler then reports the miss of the actual user, under which this task should be ran.

However, I’ve solved it by adding the AutoLogon=Yes and the AutoLogonCount=1 parameters to the sysprep.inf. The first one generally activates the AutoLogon feature, so that the Administrator will be automatically logged on after system boot and the second option defines, how many times the Administrator should be automatically logged in after boot. By setting it to 1 the Administrator will be automatically logged on only after the machine’s first boot – on the following boots no more AutoLogon will be used.

Then, I added a RunOnce key into the system’s registry (within the mini-setup, using the “reg” command), which executes a batch-script. Within this batch script then I was able to do everything I want – unlock the firewall’s port, enable RDP and add the Domain-Group to the RDP-Users. Yay.

It’s quite an ugly hack, but at least it does the job. And it’s the only method I found out to work.

What other things occurred this week… hm… ah yeah. My car. It smells. No, not a joke. Let me go into greater detail: Last Thursday, I went to the gas station and filled up my car with gasoline. The day after, I drove to work and left it there on the parking space, since I had a company car for the weekend. When I returned on monday and sat into my CRX, intending to drive home, the whole car smelled extremely of gasoline. I thought, that it might be, because I left it fully refueled there over the weekend, so I just drove off. The smell didn’t disappear when I reached my home, so I left the sunroof open. When I entered the car again later that evening, it still smelled. The next day I brought it to the garage and had it checked. On Wednesday morning I went there to pick it up, and they told me that nothing could be found: No leaking tube, no holes, nothing. They couldn’t even tell me if this is actually dangerous.

Now I kept the car driving until today, because I wanted to see whether the strength of smell decreases proportional to the fuel-amount in my tank – and of course it does. Unfortunately it only decreases, but does not completely disappear. So now I’m thinking of brining my car in to the official Honda garage hear here and let it checked up again there. Maybe they could tell me more, since they use to have more experience with these kind of cars.

It’s not only that I don’t know how dangerous this situation actually is, but besides it’s really annoying since the smell uses to makes me pretty dizzy after a while – what’s kinda disadvantageous while driving. So I definitely need to get this fixed until my car burns out – either because of some leakage or because I drove it into a tree, due to the dizziness. Hmpf. :-/

And now I guess I should finally go to bed. I’m still a bit sick and I didn’t sleep that much the past few days. Good night everybody.

The first two things weren’t that hard to realize. Sysprep actually runs every command contained in the Cmdlines.txt in \%sysprep%\i386\$oem$\ directory. Enabling RDP is possible using a simple reg-commandline which changes the value of the fDenyTSConnection key. Also opening the firewall’s port is trivial by using the netsh command. There seems to be some way by using a winnt.sif-file containing some parameters that should modify the firewall setup, unfortunately I didn’t manage to get that working in an reasonable amount of time. So I’ve just used the mentioned command to open the port in the firewall, for all profiles. The profile-argument is important, for me it did not work out without setting it to ALL.

Anyhow, the third ToDo was (and still is) tricky. The problem when using the net localgroup command to add the group to the local Remotedesktopusers-group is the following: While the mini-setup is running, the computer hasn’t got its future hostname and because of that it’s not yet joined to the domain. When trying to execute the net command for adding the domain-group to the local group it will of course fail. I searched for many different ways to do that, but each method I’ve found didn’t really work out for me:

autoexec.bat: Hacking the command to the autoexec.bat, so that it gets executed on the next reboot would be a way, unfortunately this file is ignore by every not-DOS-based Windows, like Windows XP is, for example.

win.ini: I’m not sure exactly why this didn’t work out, because the documentation says, that the Run-parameters configured in that INI will be run on Windows’ startup. In my case, the net command hasn’t seemed to be run. I think that the win.ini commands get executed before the connection to the domain has been established, so that the actual net command would have been run, but unsuccessful.

Run/RunOnce/RunService/RunServiceOnce-Keys: Would work out pretty good, if some user would log in. In my case, no user will log in until RDP is available to the specific domain-group.

And so on. I got pretty desperate, until I got an idea: A scheduled task! Windows supports adding scheduled tasks even from the commandline by using the schtasks command. I tried out the /sc onboot parameter, but unfortunately it seems to be working just like the win.ini, what cause the group not to be added. Then, I wrote myself a batch-script, which executes the net command for adding the domain-group, checks the command’s error code and if successful removes the scheduled task. The task itself I created using /sc minute /mo 1. By that, the task will be run every minute after the task-scheduler gets started on Windows’ boot and try to add the group. The whole schtasks /create thing works and even my script runs when I doubleclick it, but somehow the scheduler can’t run the script I passed to him while the mini-setup was running. I tried to same /create command within Windows XP and it worked out – my batch file got executed after one minute, added the group, saw that there was no error adding the group and removed the schtasks job.

Now I’m trying to understand, why the job does not work when I create it within the mini-setup. It’s really annoying, because Windows really does not provide any information below the basic output. There is no way (or at least none I would know of) to see what the schtasks daemon actually does when trying to run the script and fails. There is no strace. Nothing. Argh.

It really rankles me that the last piece doesn’t work the way it actually should, because the other implementations run pretty smooth and lasting. *beckon to Thomas*

Hmpf…

First of all: You cannot tunnel RDP directly through a proxy. RDP doesn’t speak any HTTP(S) to make the proxy connect to the RDP-Server or anything else. So you’ll need an application, that surrounds this RDP datachannel with HTTP, prefferable HTTPS. I found prtunnel for my Mac on DarwinPorts. This software allows you to tunnel anything you want through an http/socks proxy by connecting to the proxy, making it connect (by sending HTTP commands) to the preffered host and open a local port for the application (e.g. rdesktop) to connect. Good, so let’s connect using prtunnel to myrdpmachine.com:3389 and be happy! – NAH. As soon as you’ll try that you’ll see that it’s not that simple. Most http-proxies do not allow CONNECTs to other ports than 80/443. So you can either set up your RDP daemon to use that port – never found that option in Windoze – or you can use an SSH jumphost, since it’s pretty simple to change the SSH port to 443. So, you connect with prtunnel to your SSH machine on port 443, where the SSH daemon runs, open an SSH tunnel through that machine to the myrdpmachine.com port 3389 and connect with your RDP client on localhost:. Okay, let’s stop the theory and begin with the practice:

Open three terminals and execute the following command on the first one:

prtunnel -V -t http -H 'proxy address' -P 'proxy port' \
'port on local machine' 'remote host to connect to over proxy' \
'remote port, put SSHd on 443'

Then, terminal #2 gets the following command: ssh -L’local tunneling port’:'destination host’:'destination port’ -p ‘local port to connect to, the same given at prtunnel’ ‘user’@localhost
After that you can hapily run your rdesktop localhost:’local tunneling port’ and start RDPing. To make the stuff even more clear, here a concrete example:

prtunnel -V -t http -H 192.168.111.2 -P 3128 13337 192.168.111.3 443
ssh -L13338:192.168.111.24:3389 -p 13337 root@localhost
rdesktop localhost:13338

That’s all the magic. Though, you need to pay attention when selecting your ports, because of course only free ports will work and you really should try to keep them higher than 1024 unless you want to become root. Also you need to remember that running an RDP session over HTTP(S) might get the attention of a firewall or whatever monitoring application is available in that network. “Abnormal behaviour” – you’d never get such an 50:50 up- and downtraffic unless you run some peer-2-peer application or remote desktops.

But of course you can modify the commands and use it to be able to connect to let’s say Jabber from a network where only 80/443-outgoing is available – all you need is a jumphost.