I check the Microsoft KnowledgeBase and found two fixes. Both state that the CheckDB task can lose database context in certain circumstances.  Article #934458 is for builds 3042-3053.  Article #934459...

As I said, I ran the task with one user database selected and with all databases selected and I still recieved these messages.  I recieve these exact messages every time.

Yes, the documentation does say that about the MSDTC, but it looks like there was a hole which allowed you to use it without defining it in the resource group. ...

So, it does not have anything to do with the IP address and network name still being in the Cluster Administrator?

We are planning on coping all database file before we do the SP install, however, we don't know quite how to rebuild the cluster short of wipinh the box and...

Sorry, I meant a recent patch to the Distributed Transaction Co-ordinator.

We are not as concerned with a virtual server failure, as a hardware failure.  Plus a recent path to the Distributed Transaction Co-ordinator requires that it be defined explicitly in...

Heh, missed that one line.  I was going on what I was told by another DBA and only glanced at the BOL entry on failover clustering.

Okay.  We created a second resource group and were able to install the second virtual server.  The reasons for my perplexity were, 1. the documentation does not say that you...

The disk resourceand the resource group are created by the sysadmin before the install.  We have found that if we create a second resource group and move the second disk to...

Yes, the new disk is visible in the Cluster Administrator as a Physical Disk resource.

Thank you for the replies.  I found what I needed in Scripts.

That only lists the groups under that heading.  It does not list the servers.

This doesn't make sense to me.  It seems to me that once a file is created, the create date\timestamp should be fixed, and not changed merely because the system time...

I did check using sp_cmptlevel. The all databases are level 80.