can't find new drive

[jrudley]

When running a dsc script that formats and brings a new drive online, cntfsaccesscontrol throws an exception that the drive is not exist. If you rerun the dsc script, it works.
xWaitforDisk Disk1
{
DiskNumber = 1
RetryIntervalSec =$RetryIntervalSec
RetryCount = $RetryCount
}

    xDisk DataDisk
    {
        DiskNumber = 1
        DriveLetter = "S"
    }

Cannot find drive. A drive with the name 'S' does not exist.
+ CategoryInfo : ObjectNotFound: (S:) [], CimException
+ FullyQualifiedErrorId : DriveNotFound,Microsoft.PowerShell.Commands.GetAclCommand
+ PSComputerName : localhost

  cNtfsPermissionEntry websitePermIUSR
{
    Ensure = 'Present'
    #Path = "$iisInstallPath\$IisFolderName\website"
    Path = 'S:\inetpub\wwwroot\prod\website'
    Principal = 'IUSR'
    AccessControlInformation = @(
        cNtfsAccessControlInformation
        {
            AccessControlType = 'Allow'
            FileSystemRights = 'Read'
            Inheritance = 'ThisFolderSubfoldersAndFiles'
            NoPropagateInherit = $false
        }
    )
    DependsOn = '[xRobocopy]website','[xWebAppPool]AppPool'
}

I have made sure the dependson is set to make sure not to run the acl until the drive is online, folders copied, etc.

[SNikalaichyk]

Hi, can you please try to add "[xDisk]DataDisk" to the DependsOn property of the cNtfsPermissionEntry websitePermIUSR? I am currently on vacation and don't have an ability to try to reproduce this issue.

[jrudley]

Hi, no rush and go enjoy your vacation :) I did add a dependency to the data disk and same error. I ended up writing a quick dsc resource around icacls to get around it. I believe it must be how powershell is handling the new psdrive at runtime.

[bryanspaulding]

@SNikalaichyk I ran into the same error @jrudley listed with a custom DSC resource I was writing. I suspect the problem I had is the same problem being described here and wanted to pass on the solution I found.

My solution was to have my custom resource in it's Test,Get, and Set section call 'Get-PSDrive | out-null' at the start or end of the section. Could probably get away with just doing it at the start of Test. I don't exactly know why this fixed the 'DriveNotFound' exception, but I suspect it's causing PowerShell to reevaluate what the valid drive letters and mount points are from the operating system.

If someone was in a bind they could probably stick 'Get-PSDrive | out-null' in a xScript, and use dependencies to have it called after an xDisk resource.

The best I was able to track it down was it looked like DSC or PowerShell itself wasn't updating it's concept of what drive letters and mount points were available during a single "run" of a DSC configuration. For example, a xDisk creates a volume (i.e, S: drive) and if anything else, like a cNtfsPermissionEntry, tries to use that volume in the same run of an Update-DSCConfiguration or Start-DSCConfiguration -UseExisting it will fail with a DriveNotFound exception. When DSC reruns, it's a new session of PowerShell that knows about the drive previously created by the xDisk resource.

I believe the real "bug", if such exists here, is probably in resources like xDisk not calling Get-PSDrive, which would seem silly to require of it, or something in PowerShell itself, not refreshing when new volumes are created using non-PowerShell commands. However, upstream bugs are usually quickly fixed downstream.

I encountered this on a Windows Server 2012 R2 running WMF 5.0 and using xStorage version 2.6.0.0 (which contains xDisk).

Thanks again for writing and maintaining a great DSC resource to manage NTFS permissions.

[SNikalaichyk]

@bryanspaulding, thanks a lot! I will release a new version with this fix/workaround.

[gmatusko]

I'm running into this same issue so I'm assuming a later version was not released to address this. Thanks @bryanspaulding for the fix, I'll stick this in my DSC and give it a go. The interesting thing is we've been using this resource for almost 8 months but this issue only crops up on single file servers after allocating a storage pool, vhd and disk. We were using clustered volumes previously which did not have this issue.

[bryanspaulding]

@gmatusko You might want to make sure you aren't running WMF 5.0. There's an issue with DSC or Powershell causing large amounts of write disk I/O and it seems to be aggravated by multiple calls to get-psdrive. https://poshsecurity.com/blog/how-an-issue-with-powershell-dsc-in-wmf-5-cost-us-552695 is the best write up on the problem. There's a workaround in WMF 5.0 and WMF 5.1 is said to resolve the problem, but I haven't validated it myself. The workaround for WMF 5.0 did resolve the problem in my environment, but it wasn't a good first showing for DSC.

Fortunately, we only got slammed with an extra 20,000 write iops on the disk array.

[SNikalaichyk]

@gmatusko,
I decided not to call Get-PSDrive in the module to avoid the issue described by @bryanspaulding.
I'd be grateful if someone can test if the following line causes abnormal I/O:

Get-PSDrive -PSProvider FileSystem | Out-Null

[gmatusko]

Apologies for the delay here, I got pulled into something else and just getting back to this. I will try to test the command above and see if it causes any abnormal I/O.

I've run into a different problem attempting to secure the C: drive of some RDS session host servers from the built in Users group. Below is my DSC resource attempting to remove the AppendData file system right:

	cNtfsPermissionEntry Remove-C-Root-Users-Append
	{
	    Ensure = "Absent"
	    Path = "C:\"
	    Principal = "BUILTIN\Users"
	    AccessControlInformation = @(
	        cNtfsAccessControlInformation
	        {
	            AccessControlType = 'Allow'
	            FileSystemRights = 'AppendData'
	            Inheritance = 'ThisFolderAndSubfolders'
	            NoPropagateInherit = $false
	        }
	    )
	}

Problem is when DSC runs the test for this resource passes and says the resource is already set which is obviously not true. I've tried many different combinations to get this to work but ended up just writing my own script resource to remove the permissions. Anything obvious that I'm doing wrong? Any help would be appreciated.

I have not tried the performance issue but I can say neither of these methods actually allow cNtfsPermissionEntry to see the drives.

[SNikalaichyk]

Sorry guys, I haven't been active on GitHub recently.
@gmatusko , I certainly need to test it. Changing the C drive's root permissions may be tricky.
@almjohn , could you please share your configuration with me so I can test it?

yep no problem. Actually it does work my sequencing was incorrect. I will test the disk io issue I think it was fixed with WMF 5.1

[adhodgson1]

Guys,

I am having this issue on a bunch of machines that used xDisk from xStorage 2.8.0.0. However have just updated to StorageDSC 5.0.0.0 and am not seeing this error on the machines that have been updated and re-provisioned. I have another issue with StorageDSC 5.0.0.0 which means I can't deploy it everywhere, but on the 3 machines I have moved to using StorageDSC to format the disks and cNTFSAccessControl to provision the perms I am not seeing this anymore.

Thanks,
Andrew.