Well, what a waste of valuable disk space. So, after I got my new MacBook Pro, equipped with an SSD, I decided to go for it and share the Boot Camp partition between Windows 7 running natively and VirtualBox.

Actually, there exist a lot of posts on this topic already. So here’s a few I came across:

• Windows 7 on Mac OS X through Virtual Box
• Windows 7 Bootcamp Installation mit Virtual Box nutzen (in german)
• Windows7 in OSX with Bootcamp and Virtualbox
• How to run Windows 7 under Mac OS X 10.6 for free

The best and most complete one is IMHO luckypiplav’s howto, as it already covers most of the issues and caveats.

So my today’s post will be sort of an aggregate of all these posts before. I’m not trying to duplicate, my focus is to show what I had to do to get my setup working for me.

To begin with, here’s a short summary of my specs:

• Apple MacBook Pro 15″, February 2011 model, equipped with an 120 GiB SSD instead of a 500 GiB hard drive
• OS X 10.6.6 on HFS partition (80 GiB)
• Windows 7 SP 1 on Boot Camp partition (40 GiB)

Install Windows 7 through Boot Camp

I’m not going to loose big words on this. I used the Boot Camp assistant to prepare the hard drive for installation.
My hard drive was split into a 80 GiB partition for OS X and a 40 GiB partition for Windows 7.
The process is straight forward. For those not so familiar with it, here’s a howto.

After completing Windows 7 setup I first installed SP1 and all additional updates. I also activated the Windows 7 license. Then I booted right back into OS X.

Setup RAW partition access

Oh well, here’s some tech stuff to go through. This is also one of the things I dislike about all the other posts on this topic (sorry guys, I’m just honest): Everyone tells you to do some shell magic trickery, like write access to the partition device files. However, if your setup is only slightly different, you’re most likely doomed

So, let’s start on looking up the partition information first. For this you need to launch Disk Utility first.
My screen shots are from a german language OS X, but for the sake of demonstration purpose, this will be sufficient.

On the main window, click your Boot Camp partition first and the “Information” icon second.

This will reveal the partition information. The most important thing for us to work with, is the partition ID, which in my case reads “disk0s3″ (first disk, 3rd slice). In most cases this will be identical for you, but chances are, that it’s not. If it reads something different for you, then use this instead.

Now open up Terminal. Your starting directory in Terminal is usually your home directory, which evaluates to /Users/USERNAME. In my case it’s /Users/Gianpaolo. You can always verify your current location using the “pwd” (Print Working Directory) command.
I store all my VM related stuff in my home directory in a folder called “VirtualBox VMs”, so I change to this directory and create a new folder for the new Windows 7 VM.


cd "VirtualBox VMs"
mkdir Win7onMBP
cd Win7onMBP


Now, we need to grant permissions to the partition we inspected before. Rembember, mine was “disk0s3″? Don’t forget to use the one, that correctly applies to your system.
Note: You’ll be asked to enter your password to run this command:


sudo chmod 777 /dev/disk0s3


You will also need to eject the Boot Camp volume, in case it’s mounted.
Note: If you decided to format your Boot Camp partition with NTFS, then it won’t be accessible from OS X. In this case, it won’t be mounted as well. This is the case for me, so I effectively left this step out.


diskutil umount /Volumes/BOOTCAMP


To have this settings parmenently applied to the system, you will need to add them to the local boot script. For this purpose, we use the “nano” command, a simple text editor which is simpler to use then “vi”. Just type and quit using the “CTRL-X” key stroke.
Chances are that this file does not yet exist, but never mind, it’ll be created automatically.


sudo nano /etc/rc.local


Add the following text to your rc.local file:


# grant VirtualBox permissions to Boot Camp partition
#
chmod 777 /dev/disk0s3
diskutil umount /Volumes/BOOTCAMP


Again, if the Boot Camp volume is NTFS formatted, it won’t be mounted anyway, so the “diskutil” line can be omitted in this case.
Type “CTRL-X” to save and exit.

Now it’s time to create the RAW disk file for use with VirtualBox. For this, you should be inside the VM directory we created previously. If in doubt, check this using the “pwd” command. From here, run the following command:


sudo VBoxManage internalcommands createrawvmdk -rawdisk /dev/disk0 -filename win7raw.vmdk -partitions 3


Please note that this time, you won’t need to give the whole “disk0s3″ string to the command above. Instead leave the last two characters away, just stating the physical disk name, which is “disk0″. You will need however to supply the partition number “3″ taken from the “disk0s3″ string to the “-partitions” argument as seen above.

Create the VM

Simply follow the instructions of luckyviplav’s howto.

Important to note however: As of VirtualBox 4.x, the disk drives are always attached to a SATA controlled, as shown on the screenshot below.
It is effectively required to remove the disk from the SATA controller and attach it to the IDE controller as primary master instead. Also do not forget to set the IDE controller type to “ICH6″, otherwise you’ll get a “STOP: 0x0000007B” BSOD (Inaccessible Boot Device)”.

I strongly recommend to keep the SATA controller in the VM profile. This will have the SATA drivers automatically installed during your first boot.

First Boot and driver installation

So you’re now ready to boot your VM off the Boot Camp partition.
This will cetainly take a while as all the drivers need to be installed. Please take the chance to also install the VirtualBox guest additions.

Note: If you want 3D acceleration, you’ll need to install the VirtualBox drivers from safe mode (press F8 during boot to get into safe mode).

Optional: Re-attach boot drive to SATA controller

One of the most dramatic performance improvements for VirtualBox is the use of the virtual SATA controller in favor of the IDE controller.
So after you successfully installed all the drivers including the VirtualBox guest additions to your VM shut it down first. Then open your VM settings in VirtualBox and navigate to the storage controller section. Remove the hard drive from the IDE controller and re-attach it to the SATA controller. I asked you to keep it there in the first place so the drivers could be installed, remember?

During the next boot, Windows will automatically pick up the disk from the SATA controller and use this for booting.

As a result overall performance in VirtualBox will be a little snappier as with the IDE controller, which also used a bit more CPU power than the SATA controller.

So here’s finally our Windows 7 VM bootet off the Boot Camp partition. And yet, it’s still possible to run the very same Windows 7 natively by booting directly into Boot Camp.

Im Rahmen eines Freundschaftsdienstes habe ich CEYA Beaty & Wellnes SPA bei der Installation der greenCube Business Software in einer Client-Server-Umgebung unterstützt.

Eigentlich würde ich auch mal eine kurze Anleitung für die Client-Server-Installation verfassen, da die offizielle Anleitung in meinen Augen doch etwas dürftig ausgefallen ist. Aber da “man” wohl auch seine Support-Dienstleistungen an den Mann bringen möchte, wäre das wohl ein wenig zu sehr im fremden Revier gewildert, oder?

Hier geht’s nun allerdings erstmal um einen recht spezifischen Fehler, der bei der Client-Installation unter Windows Vista aufgetreten ist.

Zum einen will ich kurz anmerken, dass der Hinweis im Installations-FAQ, dass die Benutzerkontensteuerung unter Windows Vista bzw. Windows 7 tunlichts abzuschalten ist, nicht von ungefähr kommt.

Das geht zurück auf den Umstand, dass gewisse Setup-Programme Komponentenregistrierungen nicht sauber durchführen können.
Einen Fehler in der Installation von Office 2003 liegt im selben Verhalten begründet, worüber ich bereits in einem anderen Beitrag berichtet hatte.

Also UAC (Benutzerkontensteuerung) für die Installation auf jeden Fall ausschalten.

Allerdings muss ich auch ehrlich anmerken: Im Jahr 2010, also fast vier Jahre nach dem Release von Windows Vista und ein Jahr nach dem Release von Windows 7 finde ich es eine Zumutung, dass einer “neuen Software” mit so einem Murks auf die Beine geholfen werden muss.
Es gibt zuhauf aktueller Software am Markt, die auch ohne diesen Behelf installiert werden kann.

Nun denn, wenn die Installationshürde erstmal geschaft ist, dürfte greenCube in 99 % aller sauber installiert sein und auch funktionieren.

In meinem Fall war dem leider nicht so. So wurde bereits unmittelbar nach dem Programmstart eine Reihe von Fehlermeldungen angezeigt, welche auf typische Registrierungsfehler von OCX-Komponenten (COMDLG32.OCX und MXCOMCT2.OCX) hinwiesen.
Anschliessend wurde die Anwendung mit einer vielsagenden Meldungen geschlossen:

“Automatisierungsfehler. Der aufgerufene (Server, nicht die Serveranwendung) ist nicht verfügbar und kann nicht gefunden werden. Alle Verbindungen sind ungültig. Eventuell wurde der Aufruf ausgeführt.”

Ganz abgesehen davon, dass die Fehlermeldung für den Laien absolut nichtssagend ist, empfinde ich als besonders amüsant, dass da trotz des offenkundigen Fehlers die Möglichkeit einer “eventuellen Ausführung von irgendwas” einbehalten wird. Tja, Windows-Fehlermeldungen eben

Typischerweise haben Anwendungsfehler in Bezug auf OCX- oder DLL-Registrierungsfehler damit zu tun, dass entweder eine ältere Version der geforderten Datei vorhanden ist, oder dass sie gar nicht vorhanden ist oder selbige auch nicht richtig registriert wurde.

Normalerweise lässt sich das recht einfach beheben, indem man überprüft, ob die gewünschten Dateien überhaupt vorhanden sind (zu finden unter C:\Windows\System32), diese andernfalls nachinstalliert und manuell mit folgendem Befehl registriert:


regsvr32 %SystemRoot%\system32\DATEINAME.ocx


So geschehen auch bei unserem Problemkind-PC…

Zwar waren die gewünschten Dateien vorhanden – und auch im System registriert. Doch trotz ein Reinstallation und einer manuellen Neuregistrierung blieb der Fehler bestehen.

Zu guter Letzt und paradoxerweise genau die gegenteilige Aktion zur üblichen Verfahrensweise hat den Fehler dann zum Verschwinden gebracht, indem ich nämlich die beiden OCX-Dateien schlicht mit folgendem Befehl de-registriert habe:


regsvr32 %SystemRoot%\system32\DATEINAME.ocx /u


Fazit zum Schluss: Die OCX-Kabbelei kann man sicher _nicht_ als Fehler seitens greenCube ansehen. Dies war eindeutig irgendein lokales Phänomen, hervorgerufen durch jede Menge installierter Software. Das kann man getrost unter DLL-Hell (oder OCX-Hell) fallen lassen.

Dass das greenCube Installationsprogramm hingegen vom Anwender erfordert, die UAC-Funktion für die Installationa abzuschalten, sehe ich angesichts der mehrjährigen Verfügbarkeit von Windows Vista und auch dem Vista-Nachfolger als hakelig und nicht sehr benutzerfreundlich.

It all started with a very simple task: One of my engineers had to renew an SSL certificate for an IIS-hosted website.
After receiving the renewed SSL certificate and importing it into the certificate store, he tried to bind the SSL port on the IIS website with the new certificate.

What a bummer when he discovered, that this would always result in the following error, no matter what and how often he tried:

All investigation about this issue were dead ends.
Sure, there is a lot of information about this issue available on the net.

• some suggest exporting and reimporting the certificate
• An msdn article suggests, that the certificate does not support digital signature use (hmmm … well … an officially signed certificate intended for HTTPS use!?!? especially one, where Certificate Manager SAID that is was intended for that particular purpose!?)
• Another one cares about the private key settings while importing the key/cert pair

To make this short: A lot of posts, a lot of people having the same issue, a lot of suggestions, neither of which worked for us

There’s even the official KB981506 at Microsoft which tries to fix this for IIS 7 through a hotfix.

As with other possible solutions out there, there’s people for whom this worked, while it didn’t for others. Neither did it for us.

To make this even more worse: Using the very same private key/certificate pair on another server worked perfectly!

So, with all that information I thought about the export/import way being well worth another try – using a slight variation.
This takes also into account that the MSDN article mentioned above states the possibility of a wrong “key usage” token.

Therefore I made sure that I got a proper export from Certificate Manager into PKCS#12 (.pfx or .p12 extensions) including both the private key and the certificate for both the renewed and the previous period.
Afterwards I copied the files over to a UNIX machine and converted them from PKCS#12 file into PEM format using this openssl command:


openssl pkcs12 -in previous_cert_key.pfx -out previous_cert_key.pem -nodes
openssl pkcs12 -in renewed_cert_key.pfx -out renewed_cert_key.pem -nodes


Then I took a look at them X.509 headers of the PEM files. They looked as follows for the previous key/cert pair:


Bag Attributes
Microsoft Local Key set:
localKeyID: 01 00 00 00
friendlyName: {29F1929F-FC74-412B-ACF1-45BEEC51631A}
Microsoft CSP Name: Microsoft RSA SChannel Cryptographic Provider
Key Attributes
X509v3 Key Usage: 10


And this is what it looked like for the renewed key/cert pair:


Bag Attributes
Microsoft Local Key set:
localKeyID: 01 00 00 00
friendlyName: le-220133ff-668b-4e6a-946e-2c6581baeb86
Microsoft CSP Name: Microsoft Enhanced Cryptographic Provider v1.0
Key Attributes
X509v3 Key Usage: 80


Besides some rather to be ignored differences, the most notable and even as important one are the “X509v3 Key Usage” tokens, as they differ for the both key/cert pairs.

While the key usage 10 (should read 0×10) denotes an encipherment-elligible certificate, a key usage of 80 for the renewed certificate denotes it as valid for signing purposes only.

This however makes not much sense, as it should be encipherment-elligible, otherwise our TLS/SSL won’t work at all.

Maybe this is the root cause of the certificate, which could not be properly used for TLS/SSL port binding on IIS?

Let’s have a deeper look at the X.509 extended attributes, which can be reviewed like this:


openssl x509 -in previous_cert_key.pem -inform PEM -text
openssl x509 -in renewed_cert_key.pem -inform PEM -text


The extended key usage attributes read identically for both key/cert pairs:


X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication


So we obviously had a mismatch between the X.509 default and the respective extended attributes.

I got the feeling, that the MSDN article was indeed right about the “mismatch” reason. Especially if digging around the X.509 RFC, which stated some special considerations about when and how particular usage key tokens apply.

Basically to say is that conflicting values between the default and the extended key usage attributes may render a certificate useless in some cases, as they the flags are ignored in some cases.

So in this case I suppose that due to a somehow wrong default key usage attribute the certificate was still valid, but it was not elligible for envipherment use as the attributes mismatched each other.

To prove my assumption I then converted the PEM file of the renewed certificate back into a PKCS#12 file using this command, as already stated in a previous post:


openssl pkcs12 -export -in renewed_cert_key.pem -inkey renewed_cert_key.pem -out reconverted_cert_key.pfx


Obviously this caused the default key usage attribute to be fixed up in some way.
After importing the reconverted PKCS#12 file into Cert Manager, rebinding port 443 with the new certificate worked properly and SSL was usable from that point on.

To conclude from my experience: The root cause for this was a most-likely malformed default key usage attribute, which didn’t match up to the extended key usage attributes.
As to my understanding, it may or may not be a software bug in IIS 7 on Windows Server 2008, which messed up binding the certificate to the port because it couldn’t handle this situation properly. It is however unknown, why the hotfix didn’t work and it must be assumed, that my case does not really apply to the KB issue.
As seen from the import on a Windows Server 2008 R2 host with IIS 7.5, the renewed certificate DID work properly there, even without tampering around with openssl conversion in the first. This might be due to a proper implementation which demands that the extended attributes are preferred over the default attributes.
Additionally, the successful export+openssl-conversion+reimport seems to support this assumption, as it did work afterwards on the Windows 2008 / IIS 7 host.
Here we must also consider that openssl did remove the default key usage attribute upon reconversion to PKCS#12 format.

After all, here’s yet another possible way to work around this issue. This worked for me. Your mileage may vary, and most likely will

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.

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

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 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…!

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…