Ben Dunlap's questions

One of our less-critical servers seems to have lost the use of its onboard SATA controller -- which was managing the software-mirrored boot volume.

The simplest and cheapest fix was to buy a 2-port SATA controller at the local Fry's -- or so it seemed when I was standing in the controller aisle there.

Turns out I bought a 64-bit card, though (a 3Ware 8006-2LP to be precise) -- and the only relevant slots that are free on the server are old-school 32-bit PCI slots.

Am I in for trouble? Just to be clear, I know this will work -- in fact, I've already got it up and running -- and I know it's not a theoretically optimal configuration. What I'm asking is: Will it work well enough for my needs, as outlined below, or will it cause me misery in the long run?

The card will simply be managing 2 mirrored SATA drives, which together act as the server's boot volume. The server itself provides backup and archive storage, acts as a secondary DC, and does a few other things that are important but not day-to-day critical. All of the storage that it exposes to the network is on a separate controller card that's in a PCIe slot.

We have three MacOS machines, all running 10.4.x, bound to our Active Directory network. The domain has two DCs on a single subnet (192.168.1.0/24). One of the DCs (the secondary one, which does not hold any of the 5 FSMO roles) is currently off-line. It's physically shut-down because its boot volume is hosed.

Since the secondary DC went off-line, two of the three Macs have been unable to do standard Active-Directory authentication. I can't log in to either of them as an AD user, I can't use AD credentials in a UAC prompt, and I can't even run "Directory Access" -- it starts up but then becomes unresponsive and I need to force quit to close it.

I can, however, get a Kerberos ticket for an AD user, with the "Kerberos" GUI utility. And when I run 'dsconfig ad -show' on one of the offending Macs, I see the primary DC (the one that's actually running right now) in the "Preferred domain controller" line.

And all of our Windows machines (running XP Pro) are authenticating just fine against AD -- which would rule out any replication problem, I think.

Just wondering what I can do next to troubleshoot this.

Update on Friday afternoon, August 7
Both machines just stopped having AD trouble. I did restart them both, but I had done that twice before with one of them, to no avail. So I guess the question has become academic at this point. Still interested in hearing how anyone else would troubleshoot this.

A while back my Windows Server 2003 machine hung up and I needed to force-reboot by power-cycling it. When it was restarting it ran chkdsk, and chkdsk reported some problems.

Since then IISAdmin has not been able to start (which means that IIS doesn't work at all):

C:\WINDOWS\system32>sc query iisadmin

    SERVICE_NAME: iisadmin
    TYPE               : 20  WIN32_SHARE_PROCESS
    STATE              : 1  STOPPED
                            (NOT_STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN))
    WIN32_EXIT_CODE    : 1066  (0x42a)
    SERVICE_EXIT_CODE  : -2146893818  (0x80090006)
    CHECKPOINT         : 0x0
    WAIT_HINT          : 0x0

I suspected a corrupt Metabase so I tried restoring from a Metabase History file dated earlier than the crash -- but no luck.

Not really sure how to troubleshoot this further. There's one apparently-related error in the SYSTEM log that comes up regularly, event ID 10010 from DCOM:

The server {A9E69610-B80D-11D0-B9B9-00A0C922E750} did not register with DCOM
within the required timeout.

But I'm not sure if this actually sheds additional light or if it's just another warning that IISAdmin can't start.

Otherwise the Event logs are pretty empty of help. What's the next step to isolate this problem and fix it? I should point out that I don't have the luxury of rebooting this server very often -- it's an app server, and the users who depend on the app work until late at night, and I would need to be on-site to reboot it because it doesn't always restart reliably -- but I normally work off-site.

So if there's any way to keep investigating this without needing to reboot, I'm eager to hear it.