Reason for Access Denied error in PowerShell using Get-WMIObject calls to a remote Windows Server 2008 Failover Cluster node

What we will be covering in this blog, is a reason for an Access Denied error message in PowerShell and the options for resolving them. The particular Windows PowerShell cmdlet we will be referencing, is Get-WmiObject for accessing WMI object calls against a remote Windows Server 2008 Failover Cluster node.

Before continuing, we want you to note some differences of Windows PowerShell between Windows Server 2008 and Windows Server 2008 R2 operating systems.

1. In Windows Server 2008 by default, Windows PowerShell v1.0 is not installed. It needs to be installed from the Features Wizard in Server Manager.


2. In Windows Server 2008 R2 by default, Windows PowerShell v2.0 is already installed.



NOTE: When you go to the Feature Wizard in Server Manager as shown, don’t confuse Windows PowerShell Integrated Scripting Environment (ISE) with Windows PowerShell v2.0. This new ISE is an add-on host application for Windows PowerShell that enables you to write, run, and test scripts and modules in a friendly environment. Key features such as syntax-coloring, tab completion, visual debugging, Unicode-compliance, and context-sensitive Help provide a rich scripting experience.

Now that we have the operating system differences out of the way, let’s move on to the Get-WMIObject calls made between the two versions of Windows PowerShell. This cmdlet has a convenient alias, gwmi, which I’ll use for most of my examples. The local node name we will be referring to in these examples will be W2K8-CLUSNODE1 and the remote node name will be W2K8-CLUSNODE2.

Whenever you try executing the following syntax from Windows PowerShell v1.0 on Windows Server 2008 Failover Cluster, you will experience an Access denied error message when calling the the specific Get-WMIObject query to a remote Failover Cluster node:

      gmwi mscluster_resourcegroup -computer W2K8-CLUSNODE2 -namespace ROOT\MSCluster



    gwmi mscluster_resourcegroup -computer W2K8-CLUSNODE1 -namespace ROOT\MSCluster

    gwmi mscluster_resourcegroup -namespace ROOT\MSCluster


There are also other Get-WMIObject queries (non Failover Cluster specific) that work just fine when executing them against a remote node providing the proper credentials, such as the following syntax used below:

qwmi win32_service -credential domain\user_name -computer W2K8-CLUSNODE2

Then a dialog box will appear, so that credentials can be passed along with enough elevated privileges to query the Get-WMIObject calls. Such as the example provided below, which displays a list of services running on the remote node.




Now you may ask yourself, why are we getting Access Denied with some Get-WMIObject queries and not with others? The specific reason Get-WMIObject queries fail against a remote node of the Failover Cluster using Windows PowerShell v1.0, is because it requires Authentication of Packet Privacy that cannot be passed along in version 1.0.

This Authentication of Packet Privacy is part of a well-defined set of common API calls of the Microsoft® Security Support Provider Interface (SSPI), which is used for obtaining integrated security services for authentication, message integrity, message privacy, and security quality of service for any distributed application protocol.

This was built in to Windows PowerShell v2.0 that ship with Windows Server 2008 R2. The switches that need to be passed, are the -Authentication and -Impersonation using the following syntax as an example:

     GWMI MSCluster_ResourceGroup -Authentication PacketPrivacy -Impersonation Impersonate -Computer W2K8-CLUSNODE2 -Namespace ROOT\MSCluster

NOTE: In order for the new switches to work and be able to connect to a remote machine, the
-Impersonation must be set to Impersonate (or higher) and the -Authentication level must be set to PacketPrivacy (or higher). 

These same levels are the same ones used in WBEMTest tool. For more information on using WBEMTest tool, go reference the Using WBEMTest user interface link.





A simple get-help get-wmiobject will provide you the exact syntax and options you need as listed below.


Get-WmiObject [-List] [-EnableAllPrivileges] [-Locale [<string>]] [-Authority [<string>]] [-Amended] [-Authentication {Default | None | Connect | Call | Packet | PacketIntegrity | PacketPrivacy | Unchanged}] [-ComputerName [<string[]>]] [-Namespace [<string>]] [-Impersonation {Default | Anonymous | Identify | Impersonate | Delegate}] [-Credential [<PSCredential>]] [<CommonParameters>]

Get-WmiObject [-Filter [<string>]] [-Class] [<string>] [[-Property] [<string[]>]] [-EnableAllPrivileges] [-Locale [<string>]] [-Authority [<string>]] [-Amended] [-Authentication {Default | None | Connect | Call | Packet | PacketIntegrity | PacketPrivacy | Unchanged}] [-ComputerName [<string[]>]] [-Namespace [<string>]] [-Impersonation {Default | Anonymous | Identify | Impersonate | Delegate}] [-Credential [<PSCredential>]] [<CommonParameters>]

Get-WmiObject [-DirectRead] -Query [<string>] [-EnableAllPrivileges] [-Locale [<string>]] [-Authority [<string>]] [-Amended] [-Authentication {Default | None | Connect | Call | Packet | PacketIntegrity | PacketPrivacy | Unchanged}] [-ComputerName [<string[]>]] [-Namespace [<string>]] [-Impersonation {Default | Anonymous | Identify | Impersonate | Delegate}] [-Credential [<PSCredential>]] [<CommonParameters>]

There are a couple of options to get around the Access Denied error message when using Get-WMIObject in Windows PowerShell:

1. Our strongest recommendation would be, upgrade the operating system to Windows Server 2008 R2 for a lot of reasons. But to name a few, read the following references “Top 10 Reasons to Upgrade to Windows Server 2008 R2” and “What’s New in Windows Server 2008 R2”.

2. An alternative option if you have a compelling reason not to upgrade to Windows Server 2008 R2, would be to download and install the latest Windows Management Framework as outline in article: 968930.
968930 Windows Management Framework package (Windows PowerShell 2.0 and WinRM 2.0)
NOTE: You need to first uninstall Windows PowerShell v1.0 before installing Windows Management Framework.

3. Another alternative you can try, would be using the WBEMTEST tool to the particular namespace. Then provide the level accesses and entering the credentials.


Mike Rosado
Senior Support Escalation Engineer
Microsoft Enterprise Platforms Support