Christian’s blog

As the guys over at FreeWyseMonkeys demonstrated with JoinDomain.zip, it ain’t hard to integrate a Windows XP Embedded system into Active Directory.

You basically need this:

• A system powered by Windows XP Embedded
• netdom.exe (from any Windows XP - SP2 in your MUI language)
• some know-how, on how to use netdom to integrate it into your AD

Everything else is already present on the Windows XP Embedded systems I’ve seen. Then let’s get it on !

First, copy over the netdom.exe to your XPe, and then run the following command:

netdom.exe join /d:barfoo.org \
                /OU:"OU=Thinclients,OU=Computer,DC=barfoo,DC=org" \
                %COMPUTERNAME% \
                /ud:Administrator /pd:P@ssw0rd \
                /uo:Administrator /po:P@ssw0rd \
                /verbose

Here as a note:

• ud and pd is a User/Password inside your Active Directory with the permissions to create new computer accounts
• uo and po is a User/Password with administrative rights on the Windows XP Embedded device

After that, you just need to reboot, Et Voilà! the system is present in your Active Directory. Just be aware, if you’re using a localized Windows XP Embedded by Wyse, make sure to contact your fellow Wyse Support, as the is a bug with the MUI stuff needed for the domain logon.

Also, as yet-another side note: The default Administator password is mentioned in this Knowledge Base entry.

Life Windows XP Embedded, Work, Wyse

Well some people apparently completely *don’t* understand the use of a backup client like dsmc, additionally they don’t seem to have the slightest clue on how to draw up a “clever” backup solution.

Lemme describe the situation for you. We do have two Solaris systems at work, housing our mailing system(s). Now apparently, people are unable to install the Tivoli Storage Manager Client on Solaris (or get it working properly - which people are blaming on the software not working).

Now, they draw up this insane plan … We do have about 900GiB of mail space, which is currently located on our SAN. So people decide, they don’t want the backup client on their system, as it’s slow (which I do agree to, dsmc is *slow* for large amounts of data - especially if it’s 900GiB in 15MiB parts).

So they think of something like this:

• Attach a second disk to the mail system
• The mail server then creates a tar file (at which iteration I can’t say, but from the size of the volume, I’d figure once a day) on the secondary disk
• The mail server exports said disk via NFS
• Another, semi-independent system then imports said disk via NFS, while also housing the Tivoli Storage Manager client, to backup that big tar-file …

So much for *well* planned backup solutions ………

Life Tivoli, Work

OK, it turned out that said collegue wasn’t responsible at all. Turns out, the *real* trigger was me creating a new volume on our SAN, on the same array that houses the OCFS2 volume.

Apparently, during creation of an additional SAN volume, all other SAN volumes in this array are either read-only or delayed during that time, as you can see from the following log:

kernel: (13,3):o2hb_write_timeout:242 ERROR: Heartbeat write timeout to device sdd1 after 12000 milliseconds
kernel: Heartbeat thread (13) printing last 24 blocking operations (cur = 4):
kernel: Heartbeat thread stuck at waiting for read completion, stuffing current time into that blocker (index 4)
kernel: Index 5: took 0 ms to do submit_bio for read
kernel: Index 6: took 0 ms to do waiting for read completion
kernel: Index 7: took 0 ms to do bio alloc write
kernel: Index 8: took 0 ms to do bio add page write
kernel: Index 9: took 0 ms to do submit_bio for write
kernel: Index 10: took 0 ms to do checking slots
kernel: Index 11: took 0 ms to do waiting for write completion
kernel: Index 12: took 2002 ms to do msleep
kernel: Index 13: took 0 ms to do allocating bios for read
kernel: Index 14: took 0 ms to do bio alloc read
kernel: Index 15: took 0 ms to do bio add page read
kernel: Index 16: took 0 ms to do submit_bio for read
kernel: Index 17: took 0 ms to do waiting for read completion
kernel: Index 18: took 0 ms to do bio alloc write
kernel: Index 19: took 0 ms to do bio add page write
kernel: Index 20: took 0 ms to do submit_bio for write
kernel: Index 21: took 0 ms to do checking slots
kernel: Index 22: took 0 ms to do waiting for write completion
kernel: Index 23: took 2004 ms to do msleep
kernel: Index 0: took 0 ms to do allocating bios for read
kernel: Index 1: took 0 ms to do bio alloc read
kernel: Index 2: took 0 ms to do bio add page read
kernel: Index 3: took 0 ms to do submit_bio for read
kernel: Index 4: took 9995 ms to do waiting for read completion
kernel: (13,3):o2hb_stop_all_regions:1682 ERROR: stopping heartbeat on all active regions.
kernel: Kernel panic - not syncing: *** ocfs2 is very sorry to be fencing this system by panicing ***

Life OCFS2, SLES10, TYPO3, Work