Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Try our Virtual Agent - It can help you quickly identify and fix common issues when a resource fails to come online.
This guidance is designed to get you started on troubleshooting issues where clustered resources can't be brought online in a Windows-based cluster environment.
Troubleshooting checklist
When a resource fails to come online, Event ID 1069 is logged on the server that's hosting the resource of concern:
Error 1069 Microsoft-Windows-FailoverClustering Cluster resource '<Name of the Resource>' of type '<Resource Type>' in clustered role '<Available Storage>' failed.
Check the System event log for the Event ID, and then check if other errors or warnings are logged. For example:
If a physical disk resource can't come online, check for disk-related errors or warnings. For example, Event ID 129 (bus reset) or Event ID 153 (IO retried).
If a network name resource can't come online, check for DNS-related entries.
If an IP address resource can't come online, check for NIC-related events, errors, or warnings.
If nothing except Event ID 1069 is logged, review the cluster log for further troubleshooting. Open an elevated PowerShell prompt and run the following cmdlet:
Get-ClusterLog -Destination C:\tempNote
This cmdlet will generate the cluster logs on all cluster members and copy them to the C:\temp folder on the server where the cmdlet was executed.
Search for strings in the cluster log that might correlate with Event ID 1069:
[RCM] rcm::RcmResource::HandleFailure [RHS] Online for resource OnlineThread: Error <Code> bringing resource online. [RHS] RhsCall::DeadlockMonitor: Call ONLINERESOURCENote
The placeholder <Code> represents the error code and can differ depending on the issue.
Common support scenarios
Data collection
Before contacting Microsoft Support, you can gather information about the issue.
Prerequisites
TSS must be executed in the context of an account with admin rights on the local system, and EULA must be accepted (once EULA is accepted, TSS won't prompt it again).
We recommend that the local machine uses the RemoteSigned PowerShell execution policy.
Note
In case the current PowerShell execution policy doesn't allow running TSS, the following actions could be taken:
Set RemoteSigned for the Process level and run the following cmdlet:
PS C:\> Set-ExecutionPolicy -scope Process -ExecutionPolicy RemoteSignedVerify if the change has taken effect, run the following cmdlet:
PS C:\> Get-ExecutionPolicy -List
Since the Process level permissions only apply to the current PowerShell session, once the given PowerShell window in which TSS runs is closed, the assigned permission for the Process level will also go back to the previously configured state.
Gather key information before you contact Microsoft Support
Download TSS and unzip it to the C:\tss_tool folder.
Open an elevated PowerShell prompt and change the directory to the C:\tss_tool folder.
Start the trace by running the cmdlet on the source and destination nodes.
.\Get-psSDP.ps1