Integrating Windows XPe into Active Directory

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:

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.

Backup solutions

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

OCFS2 follow-up

OK, it turned out that said colleague 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: