Error "Cluster File Share resource '...' has failed a status check." during defrag

################
##
## I'm sorry! I posted this first to
microsoft.public.windows.server.general, but this group should be
better
## (http://groups.google.com/group/
microsoft.public.windows.server.general/browse_thread/thread/
2709660b146dd0a1?hl=us)
##
################


I've got a Windows 2003 Cluster with 2 nodes. There are more than 15
file shares. Every night we do a defrag and during that we get some
errors in the Windows Event Log. The errors occur on different times
every night. There are always three errors about a file share.

1st error:
Event Type: Error
Event Source: ClusSvc
Event Category: File Share Resource
Event ID: 1055
Date: 06.06.2007
Time: 03:36:30
User: N/A
Computer: SERVER
Description:
Cluster File Share resource 'FILESHARENAME' has failed a status check.
The error code is 64.

For more information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.
Data:
0000: 00000040

2nd error:
Event Type: Error
Event Source: ClusSvc
Event Category: Failover Mgr
Event ID: 1069
Date: 06.06.2007
Time: 03:36:30
User: N/A
Computer: SERVER
Description:
Cluster resource 'FILESHARENAME' in Resource Group 'RESOURCEGROUP'
failed.

For more information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.

3rd error:
Event Type: Information
Event Source: ClusSvc
Event Category: Failover Mgr
Event ID: 1201
Date: 06.06.2007
Time: 03:40:09
User: N/A
Computer: SERVER
Description:
The Cluster Service brought the Resource Group "RESOURCEGROUP" online.

For more information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.

--------


I set the Pending Timeout value from 180 to 360 seconds, but it didn't
help.

the shares depend on the disk but not on the network name. if the
network name is offline the share is even available with the ip
address. is that correct or must the share depend on the network name?

the cluster log while the three error messages appear:
00000ae8.00000bd4::2007/06/06-03:36:28.058 INFO [Qfs]
GetDiskFreeSpaceEx O:\MSCS\, status 0
00000ae8.000011c8::2007/06/06-03:37:12.761 INFO [CP]
CppDepositCheckpoint checkpointing data to file O:\MSCS\06052fad-
c8ff-485d-95e7-0845d25932e9\00000004.CPT
00000ae8.000011c8::2007/06/06-03:37:12.761 INFO [Qfs]
QfsCreateDirectory O:\MSCS\06052fad-c8ff-485d-95e7-0845d25932e9,
status 183
00000ae8.000011c8::2007/06/06-03:37:12.761 INFO [Qfs] QfsOpenFile O:
\MSCS\06052fad-c8ff-485d-95e7-0845d25932e9\00000004.CPT => 2, 9b8
status 0
00000ae8.000011c8::2007/06/06-03:37:12.777 INFO [Qfs] WriteFile 9b8
(regf) 3860, status 0 (0=>0)
00000ae8.000011c8::2007/06/06-03:37:12.777 INFO [Qfs] WriteFile 9b8
(....) 4096, status 0 (0=>0)
00000ae8.000011c8::2007/06/06-03:37:12.777 INFO [Qfs] WriteFile 9b8
(VIA.) 236, status 0 (0=>0)
00000ae8.000011c8::2007/06/06-03:37:12.855 INFO [Qfs] QfsFlushBuffers
9b8, status 0
00000ae8.000011c8::2007/06/06-03:37:12.855 INFO [Qfs] QfsCloseHandle
9b8, status 0
00000ae8.000013e8::2007/06/06-03:38:17.761 INFO [CP]
CppDepositCheckpoint checkpointing data to file O:\MSCS\06052fad-
c8ff-485d-95e7-0845d25932e9\00000004.CPT
00000ae8.000013e8::2007/06/06-03:38:17.761 INFO [Qfs]
QfsCreateDirectory O:\MSCS\06052fad-c8ff-485d-95e7-0845d25932e9,
status 183
00000ae8.000013e8::2007/06/06-03:38:17.761 INFO [Qfs] QfsOpenFile O:
\MSCS\06052fad-c8ff-485d-95e7-0845d25932e9\00000004.CPT => 2, 9b8
status 0
00000ae8.000013e8::2007/06/06-03:38:17.777 INFO [Qfs] WriteFile 9b8
(regf) 3860, status 0 (0=>0)
00000ae8.000013e8::2007/06/06-03:38:17.777 INFO [Qfs] WriteFile 9b8
(....) 4096, status 0 (0=>0)
00000ae8.000013e8::2007/06/06-03:38:17.777 INFO [Qfs] WriteFile 9b8
(VIA.) 236, status 0 (0=>0)
00000ae8.000013e8::2007/06/06-03:38:17.808 INFO [Qfs] QfsFlushBuffers
9b8, status 0
00000ae8.000013e8::2007/06/06-03:38:17.808 INFO [Qfs] QfsCloseHandle
9b8, status 0
00000ae8.000013e8::2007/06/06-03:39:22.760 INFO [CP]
CppDepositCheckpoint checkpointing data to file O:\MSCS\06052fad-
c8ff-485d-95e7-0845d25932e9\00000004.CPT
00000ae8.000013e8::2007/06/06-03:39:22.760 INFO [Qfs]
QfsCreateDirectory O:\MSCS\06052fad-c8ff-485d-95e7-0845d25932e9,
status 183
00000ae8.000013e8::2007/06/06-03:39:22.760 INFO [Qfs] QfsOpenFile O:
\MSCS\06052fad-c8ff-485d-95e7-0845d25932e9\00000004.CPT => 2, 9b8
status 0
00000ae8.000013e8::2007/06/06-03:39:22.776 INFO [Qfs] WriteFile 9b8
(regf) 3860, status 0 (0=>0)
00000ae8.000013e8::2007/06/06-03:39:22.776 INFO [Qfs] WriteFile 9b8
(....) 4096, status 0 (0=>0)
00000ae8.000013e8::2007/06/06-03:39:22.776 INFO [Qfs] WriteFile 9b8
(VIA.) 236, status 0 (0=>0)
00000ae8.000013e8::2007/06/06-03:39:22.807 INFO [Qfs] QfsFlushBuffers
9b8, status 0
00000ae8.000013e8::2007/06/06-03:39:22.807 INFO [Qfs] QfsCloseHandle
9b8, status 0
00000ae8.000013e8::2007/06/06-03:40:27.760 INFO [CP]
CppDepositCheckpoint checkpointing data to file O:\MSCS\06052fad-
c8ff-485d-95e7-0845d25932e9\00000004.CPT
00000ae8.000013e8::2007/06/06-03:40:27.760 INFO [Qfs]
QfsCreateDirectory O:\MSCS\06052fad-c8ff-485d-95e7-0845d25932e9,
status 183
00000ae8.000013e8::2007/06/06-03:40:27.760 INFO [Qfs] QfsOpenFile O:
\MSCS\06052fad-c8ff-485d-95e7-0845d25932e9\00000004.CPT => 2, d00
status 0
00000ae8.000013e8::2007/06/06-03:40:27.760 INFO [Qfs] WriteFile d00
(regf) 3860, status 0 (0=>0)
00000ae8.000013e8::2007/06/06-03:40:27.776 INFO [Qfs] WriteFile d00
(....) 4096, status 0 (0=>0)
00000ae8.000013e8::2007/06/06-03:40:27.776 INFO [Qfs] WriteFile d00
(VIA.) 236, status 0 (0=>0)
00000ae8.000013e8::2007/06/06-03:40:27.807 INFO [Qfs] QfsFlushBuffers
d00, status 0
00000ae8.000013e8::2007/06/06-03:40:27.807 INFO [Qfs] QfsCloseHandle
d00, status 0

thank you for your help!

You should make your Share resource dependent on Disk and Network Name
resources.

As your error code is 64 decimal (0x40 hex) that relates to
ERROR_NETNAME_DELETED

I would try to make this FileShare dependent on your network name, and see
if the error persist.

Can you also explain to us how and with what program you are running your
defrag ?
(and why, as I have never seen a systems which *really* needed a defrag that
often)

The sniplet of cluster.log file does not give us any more clues, are you
sure it is from the right node ?
As I would have expected to see something relating to the share in the
cluster log.

Ok, I'll make the shares dependent on Disk and Network Name.

The erorrs occur on both nodes and the cluster.log is from the node on
which the share failed.

Yeah, maybe we don't need to defrag the system every night.. A
Scheduled Task starts starts defrag with the command: defrag e: /f

Thank you!
Christian

FYI, the cluster.log is based in GMT time and not the local system time. I
would guess that you copied the wrong section of the cluster log as these
events are not related to the errors in from the event log that you've
referenced.

Regards,
John

Visit my blog: http://msmvps.com/blogs/jtoner

"Christian Fässler" <faechri@gmail.com> wrote in message
news:1181215588.940034.171300@n4g2000hsb.googlegroups.com...
> Ok, I'll make the shares dependent on Disk and Network Name.
>
> The erorrs occur on both nodes and the cluster.log is from the node on
> which the share failed.
>
> Yeah, maybe we don't need to defrag the system every night.. A
> Scheduled Task starts starts defrag with the command: defrag e: /f
>
> Thank you!
> Christian
>

9 times out of 10, the file share failing with a 64 is a system resource
issue. Since you are running a resource intensive process during that time,
that's probably where we are headed. Basically what's happening is that the
server service is too busy for the cluster to get a response when we check
whether or not the network name is still bound to the server, so the cluster
assumes it's failed. One of our first steps is to make the changes to the
lanmanserverkey. Those changes are detailed in:

317249 How to troubleshoot Event ID 2021 and Event ID 2022
http://support.microsoft.com/default...b;EN-US;317249

Specifially, these 3 changes:

MaxFreeConnections, MinFreeConnections, and MaxWorkItems.

--
Jeff Hughes, MCSE
Support Escalation Engineer
Microsoft Enterprise Platforms Support (Server Core/Cluster)

"Christian Fässler" <faechri@gmail.com> wrote in message
news:1181215588.940034.171300@n4g2000hsb.googlegroups.com...
> Ok, I'll make the shares dependent on Disk and Network Name.
>
> The erorrs occur on both nodes and the cluster.log is from the node on
> which the share failed.
>
> Yeah, maybe we don't need to defrag the system every night.. A
> Scheduled Task starts starts defrag with the command: defrag e: /f
>
> Thank you!
> Christian
>