Everyone knows this most likely, but the fastest way to determine which FSMO roles a domain controller holds is by typing in:

C:\Users\administrator> netdom query fsmo
Schema master               server.domain.local
Domain naming master        server.domain.local
PDC                         server.domain.local
RID pool manager            server.domain.local
Infrastructure master       server.domain.local
The command completed successfully.

I recently had an issue where a client's Microsoft Exchange 2010 server failed the best practices analyzer due to an "Database backup critical" error. I was confused at first since I had a fully functional wbadmin scripted backup that I could see backed up Exchange. Only after fiddling for a while did I discover the missing parameter I had to provide before exchange indicated a successful database backup and subsequently cleared out all the thousands of database log files it kept:

wbadmin start backup -backupTarget:\\1.2.3.4\backups -include:c: ^
   -user:msbackup -password:"password" -quiet -allCritical -vssFull -systemState

Without -systemState this never worked.

…when you look up close at about 100x magnification with polarized light:

Here they are at almost 5x life size:

…if you do not have a VERY fast internet connection, this will be a huge pain. I rebooted, started the onboard OS Reinstall process and it went ahead downloading Lion… With my connection this works:

But imagine that over a 384kbps ADSL line...

I recently had a client that needed to replace a hard drive in a Linux FakeRaid RAID5 array using dmraid. The process is very unintuitive:

1. Identify the failed drive by looking at /var/log/messages, dmesg or dmraid -r and run sudo smartctl -i /dev/sda and look at the Serial Number (change /dev/sda to the correct disk). Match this serial number to the physical disk.
2. Replace the failed drive with a new drive matching or exceeding its capacity.
3. In the BIOS for the FakeRaid controller, add the new drive back and ensure the controller is rebuilding the volume.
4. Boot into the OS.

5. run

   dmraid -a y

6. This will activate the raid set and should start the rebuild process. In my case this did not persist after reboot, hence /dev/mapper did not show the partition table. The solution was to rebuild the initrd image:

   uname -a
   mkinitrd /boot/initrd-2.6.18-128.1.6.el5.img.NEW 2.6.18-128.1.6.el5

7. uname -a was used to identify the correct kernel. Obviously you need to update grub with the new image. Reboot otherwise you will not see the partitions on the mapper device to mount.

For some reason the whole ext3 filesystem was corrupted. I had to recreate the filesystem and rebuild the data from scratch. Not sure if it is FakeRaid's fault, or whether I made a mistake. But it certainly did not boost my confidence in software based RAID.