Think I've uncovered a WMI bug with Scale out file server. The issue manifests itself in the fact that SOFS utilizes a DNS name pointing to multiple nodes. The problem is that certain calls seem to rely on named pipes on the SOFS cluster object, and because that name could point at any node in the cluster, the call fails if it happens to try connecting to another node instead. To reproduce, use this powershell cmdlet (either locally from one of the SOFS nodes or remotely):
gwmi Win32_ClusterShare
And sometimes you'll get output of all of the cluster shares including SOFS shares, and other times you'll get nothing. Running procmon during a failure shows an Access Denied failure on the srvsvc named pipe of the SOFS cluster object (in my case, CLOUD-VMMLIB):
This call succeeds when WMI returns all of the SOFS shares. I can think of two workarounds for the issue. First, either modify the local hosts file on each SOFS node to point the SOFS name to the local node (this is what I implemented and confirmed works), or second, add the computer account of each node in the SOFS cluster to the local administrators group on every other node.
Regardless, this definitely seems like a bug because anything that relies on the WMI data (BITS in VMM for instance) fails because it doesn't think any shares exist in the SOFS cluster.
Jeff Graves, ORCS Web, Inc.