Below are 2 config blocks.

Initial_DataDisk sets a volume on a disk to 200MB.
DifferentSizeVolume_DataDisk expects a volume size of 300MB.
Test-DscConfiguration inDesiredState = True although there is a mismatch in volume sizes.

Configuration Initial_DataDisk
{

    Import-DscResource -ModuleName xStorage

    Node localhost
    {
        xWaitforDisk Disk1
        {
            DiskNumber = 1
            RetryIntervalSec = 60
            RetryCount = 60
        }

        xDisk XVolume {
            DiskNumber = 1
            DriveLetter = 'Z'
            Size = 200MB
        }
    }
}

Configuration DifferentSizeVolume_DataDisk
{

    Import-DscResource -ModuleName xStorage

    Node localhost
    {
        xWaitforDisk Disk1
        {
            DiskNumber = 1
            RetryIntervalSec = 60
            RetryCount = 60
        }

        xDisk XVolume {
            DiskNumber = 1
            DriveLetter = 'Z'
            Size = 300MB
        }
    }
}


#write mofs
Initial_DataDisk -OutputPath C:\Initial_DataDisk 
DifferentSizeVolume_DataDisk -OutputPath C:\DifferentSizeVolume_DataDisk 

#DSC Volume w/Initial_DataDisk
Start-DscConfiguration -Path C:\Initial_DataDisk -Wait -Force

#Test volume with different volume size
Test-DscConfiguration -Path C:\DifferentSizeVolume_DataDisk -Verbose

<#
    Test Volume w/Different size Volume
    Expect desired state to be false because volume size does not match
    Verbose seems to identify mismatch but InDesiredState value is True 

VM Disk size = 1GB

InDesiredState             : True
ResourcesInDesiredState    : {[xWaitForDisk]Disk1, [xDisk]XVolume}
ResourcesNotInDesiredState : 
ReturnValue                : 0
PSComputerName             : localhost

VERBOSE: [WIN-HOST]:                            [[xDisk]XVolume] Test-TargetResource: Drive Z size 209715200 does not match expected size 3145
72800.

#>

I added unit tests for issues #23, in PR #21, but it still needs tests to cover existing functionality.

We have a scenario where we need to have a CD-ROM drive available for some maintenance (like automatic VMware Tools deploy). So I need to move this CD-ROM to another drive letter, just to move it out of the way for drive letter D: where it is put when provisioning a new VM.

I put together this Script resource and wonder if it something we could turn into a regular resource? Is this something that is needed by more people? If so I'm happy to PR a new resource for this in, when we determined the schema.mof.

        Script (New-ResourceName -Name 'RenameCDROMDriveLetter')
        {
            SetScript = {
                $cdromDrive = Get-CimInstance -Class Win32_CDROMDrive | Select-Object -First 1 
                if ($cdromDrive)
                {
                    Get-CimInstance -Class Win32_Volume -Filter "DriveLetter = '$($cdromDrive.Drive)'" |
                        Set-CimInstance -Arguments @{
                            DriveLetter='B:'
                        } | Out-Null
                }
            }

            TestScript = {
                $expectedDriveLetter = 'B'
                
                $cdromDrive = Get-CimInstance -Class Win32_CDROMDrive | Select-Object -First 1 
                if ($cdromDrive)
                {
                    $driveLetter = ($cdromDrive.Drive -replace ':','')

                    $result = $driveLetter -eq $expectedDriveLetter
                }
                else
                {
                    $result = $false
                }

                return $result
            }
            
            GetScript = {
                $driveLetter = ''

                $cdromDrive = Get-CimInstance -Class Win32_CDROMDrive | Select-Object -First 1 
                if ($cdromDrive)
                {
                    $driveLetter = $cdromDrive.Drive
                }

                return @{
                    DriveLetter = ($driveLetter -replace ':','')
                }
            }
        }`

Hi,

We found installing software, certificates etc. from network shares was unreliable, but it worked every time if we mounted an ISO containing the necessary installers/files. We even created our own ISOs with certificates and modules we wanted to install. The snag is, DSC likes to implement things and keep them there, but we want to dismount the ISO when we're done with it. Otherwise, the ISO file is locked when we want to make a change to it, for example to change a certificate or a slipstreamed cumulative update.
The ideal scenario would be to mount the ISO as part of the Set-TargetResource element of the thing that needs the ISO and have DSC ensure that it is absent at the end of the installation. That way it wont get mounted every time, only when it finds that resource is not in the desired state.

So far, the best approach we've found is to use, for example,
$result = Invoke-DscResource -Name xCertificateImport -Method Test
and so on, and later have something like
if(!($result.InDesiredState)) { xMountImage GlobalBinaryMount
and so on to mount the ISO, with other installation stuff depending on the completion of that, and then a script resource dismounting it as we can't use DSC to both mount and unmount the same ISO.

So we do the test for the resource, and if it's not in the desired state we insert the step to mount the image and then invoke the resource, but we still can't unmount it at the end using xMountImage, we have to use a script.

Is there an elegant, DSC friendly way to temporarily mount an ISO (and this principle could be applied to anything else temporary that's only needed while something is being configured)? If not, should there be? we used to be able to get around it by using different names for the mount and unmount process, but that was breaking the DSC guidelines and since that loophole was closed, we're looking for the best way to accomplish this.

Thanks in advance for your help!

Disk number seem to be unreliable to select the right disk. Or might be that I'm I doing something wrong? :)
/cc @PlagueHO

I configured a cluster successfully with the disks.

VERBOSE: [SQLTEST4]: LCM:  [ Start  Resource ]  [[xWaitForDisk]Disk1_DriveE]
VERBOSE: [SQLTEST4]: LCM:  [ Start  Test     ]  [[xWaitForDisk]Disk1_DriveE]
VERBOSE: [SQLTEST4]:                            [[xWaitForDisk]Disk1_DriveE] Test-TargetResource:
VERBOSE: [SQLTEST4]:                            [[xWaitForDisk]Disk1_DriveE] Test-TargetResource: Found disk '1' named 'MSFT Virtual HD'.
VERBOSE: [SQLTEST4]: LCM:  [ End    Test     ]  [[xWaitForDisk]Disk1_DriveE]  in 1.0310 seconds.
VERBOSE: [SQLTEST4]: LCM:  [ Skip   Set      ]  [[xWaitForDisk]Disk1_DriveE]
VERBOSE: [SQLTEST4]: LCM:  [ End    Resource ]  [[xWaitForDisk]Disk1_DriveE]
VERBOSE: [SQLTEST4]: LCM:  [ Start  Resource ]  [[xDisk]Disk1_DriveE]
VERBOSE: [SQLTEST4]: LCM:  [ Start  Test     ]  [[xDisk]Disk1_DriveE]
VERBOSE: [SQLTEST4]:                            [[xDisk]Disk1_DriveE] Test-TargetResource: Testing Disk '1' status for drive letter 'E'.
VERBOSE: [SQLTEST4]:                            [[xDisk]Disk1_DriveE] Test-TargetResource: Checking if disk number '1' is initialized.
VERBOSE: [SQLTEST4]:                            [[xDisk]Disk1_DriveE] Perform operation 'Query CimInstances' with following parameters, ''queryExpression' = SELECT BlockSize from Win32_Volume WHERE DriveLetter = 'E:','queryDialect' = WQL,'namespaceName' = ro
ot\cimv2'.
VERBOSE: [SQLTEST4]:                            [[xDisk]Disk1_DriveE] Operation 'Query CimInstances' complete.
VERBOSE: [SQLTEST4]: LCM:  [ End    Test     ]  [[xDisk]Disk1_DriveE]  in 1.6140 seconds.
VERBOSE: [SQLTEST4]: LCM:  [ Skip   Set      ]  [[xDisk]Disk1_DriveE]
VERBOSE: [SQLTEST4]: LCM:  [ End    Resource ]  [[xDisk]Disk1_DriveE]

After reboot of the server I tried to apply the configuration again. And it cannot find the disks any more.

VERBOSE: [SQLTEST4]: LCM:  [ Start  Resource ]  [[xWaitForDisk]Disk1_DriveE]
VERBOSE: [SQLTEST4]: LCM:  [ Start  Test     ]  [[xWaitForDisk]Disk1_DriveE]
VERBOSE: [SQLTEST4]:                            [[xWaitForDisk]Disk1_DriveE] Test-TargetResource:
VERBOSE: [SQLTEST4]:                            [[xWaitForDisk]Disk1_DriveE] Test-TargetResource: Disk '1' not found.
VERBOSE: [SQLTEST4]: LCM:  [ End    Test     ]  [[xWaitForDisk]Disk1_DriveE]  in 7.9280 seconds.
VERBOSE: [SQLTEST4]: LCM:  [ Start  Set      ]  [[xWaitForDisk]Disk1_DriveE]
VERBOSE: [SQLTEST4]:                            [[xWaitForDisk]Disk1_DriveE] Set-TargetResource:
VERBOSE: [SQLTEST4]:                            [[xWaitForDisk]Disk1_DriveE] Set-TargetResource: Disk '1' not found.
VERBOSE: [SQLTEST4]:                            [[xWaitForDisk]Disk1_DriveE] Set-TargetResource: Disk '1' not found.
VERBOSE: [SQLTEST4]:                            [[xWaitForDisk]Disk1_DriveE] Set-TargetResource: Disk '1' not found.
VERBOSE: [SQLTEST4]:                            [[xWaitForDisk]Disk1_DriveE] Set-TargetResource: Disk '1' not found.
...

Running diskpart shows that the disks no longer has the same disk numbers.

PS C:\Windows\system32> diskpart

Microsoft DiskPart version 10.0.14393.0

Copyright (C) 1999-2013 Microsoft Corporation.
On computer: SQLTEST4

DISKPART> list disk

  Disk ###  Status         Size     Free     Dyn  Gpt
  --------  -------------  -------  -------  ---  ---
  Disk 0    Online           80 GB      0 B        *
  Disk 6    Reserved       1024 MB      0 B        *
  Disk 7    Reserved       1024 MB      0 B        *
  Disk 8    Reserved       1024 MB      0 B        *
  Disk 9    Reserved       1024 MB      0 B        *
  Disk 10   Reserved       1024 MB      0 B        *

DISKPART>

The cluster is happy at least.

PS C:\Windows\system32> Get-ClusterGroup -Name 'Available Storage' | Get-ClusterResource

Name            State  OwnerGroup        ResourceType
----            -----  ----------        ------------
SQL2016-BACKUP  Online Available Storage Physical Disk
SQL2016-DATA    Online Available Storage Physical Disk
SQL2016-LOG     Online Available Storage Physical Disk
SQL2016-SYSDATA Online Available Storage Physical Disk
SQL2016-TEMPDB  Online Available Storage Physical Disk

Disk number 6 should be disk number 1.

PS C:\Windows\system32> Get-ClusterGroup -Name 'Available Storage' | Get-ClusterResource -Name SQL2016-DATA | fl *


Characteristics         : Quorum, BroadcastDelete, MonitorReattach
Cluster                 : TESTCLU01
DeadlockTimeout         : 300000
Description             :
Id                      : 1f6b8d9a-1ee0-4173-ac7d-99d825815614
IsCoreResource          : False
EmbeddedFailureAction   : 2
IsAlivePollInterval     : 4294967295
IsNetworkClassResource  : False
IsStorageClassResource  : True
LastOperationStatusCode : 0
LooksAlivePollInterval  : 4294967295
MaintenanceMode         : False
MonitorProcessId        : 2420
Name                    : SQL2016-DATA
OwnerGroup              : Available Storage
OwnerNode               : SQLTEST4
PendingTimeout          : 180000
PersistentState         : 1
ResourceSpecificData1   : 0
ResourceSpecificData2   : 0
ResourceSpecificStatus  :
ResourceType            : Physical Disk
RestartAction           : 2
RestartDelay            : 500
RestartPeriod           : 900000
RestartThreshold        : 1
RetryPeriodOnFailure    : 3600000
SeparateMonitor         : False
State                   : Online
StatusInformation       : 0

xDisk can use the maximum space available by not specifying a 'Size'. However if I resize the volume it does not extend into that space. It would be great if this was a feature.

Count is not a valid member. It should be RetryCount.

Sample_InitializeDataDisk.ps1

I am a bit confused here. The xDisk resource takes a DiskNumber and a DriveLetter parameter, but one never assigns a drive letter to a disk, but to a partition.

In the code it is assumed that each disk only has one partition.

If multiple partitions (volumes) exists on a disk, the configuration doesn't change the drive letter but doesn't throw an error.

Also what if I want to assign a drive letter to the second partition on disk 2, I can't do that.

Finally running the configuration, some verbose output claims:

A reboot is required to progress further. Please reboot the system.

I don't know where that comes from but it is not true.

Hi

This may be something I need advice on rather than being an issue. I wonder why xDisk needs to have a Drive Letter. A scenario I am dealing with is that I need to make sure a Disk has a volume and is formatted so I can use it later as a CSV in a Cluster. For this reason I wouldn't want to assign a Drive Letter or Access Path.

Is there a technical reason why this scenario is not handled in xStorage? Or is it that it hasn't been done yet? Are there problems that can be encountered when relying solely on the Disk number? If so, could Serial Number not be provided as the Unique key instead?

Thanks

if($BlockSize -gt 0 -and $AllocationUnitSize -ne 0)

should be..
if($BlockSize.BlockSize -gt 0 -and $AllocationUnitSize -ne 0)

Currently all MOF Classes in xStorage are set to version 0.1.0.0.

I don't believe this should be the case for a released Resource. These should all be upgraded to 1.0.0.0

I'd propose doing this as part of #53.

Any disk formatted during initialization in xDisk is formatted with NTFS.

Should add an optional parameter with FSFormat that defaults to NTFS. It could accept NTFS or ReFS.

Note: If a disk is already formatted with a different format then a warning should be shown by an error should not be thrown.

This includes converting Global to Script variables and using InModuleScope where applicable.

Create unit tests and integration tests (where possible) for all resources.

Issue: xDisk Test-Target resource fails testing FSLabel when the file system label is matches desired state

Environment: Windows Server 2016 RTM, Windows Failover Clustering, xStorage 2.8.0.0

Cause: xDisk GetTargetResource uses Get-Volume by drive letter. Get-Volume in a Windows Server 2016 Cluster returns disks off all nodes potentially resulting in multiple volumes with the same drive letter. Get-Volume maps directly to the ROOT\Microsoft\Windows\Storage\MSFT_Volume WMI class which also exhibits the same behaviour.

See MSFT_xDisk.psm1 line 85.

Possible Solution: Follow the same pattern as MSFT_xDiskAccessPath and get the volume information via the partition. This solution uses the disk number - which is already required - to get the volume information.

Verbose output from test resource:

VERBOSE: [COMPUTER1]: LCM: [ Start Resource ] [[xDisk]sqlRoot]
VERBOSE: [COMPUTER1]: LCM: [ Start Test ] [[xDisk]sqlRoot]
VERBOSE: [COMPUTER1]: [[xDisk]sqlRoot] Test-TargetResource: Testing Disk '1' status for
drive letter 'E'.
VERBOSE: [COMPUTER1]: [[xDisk]sqlRoot] Test-TargetResource: Checking if disk number '1' is
initialized.
VERBOSE: [COMPUTER1]: [[xDisk]sqlRoot] Perform operation 'Query CimInstances' with
following parameters, ''queryExpression' = SELECT BlockSize from Win32_Volume WHERE DriveLetter = 'E:','queryDialect' =
WQL,'namespaceName' = root\cimv2'.
VERBOSE: [COMPUTER1]: [[xDisk]sqlRoot] Operation 'Query CimInstances' complete.
VERBOSE: [COMPUTER1]: [[xDisk]sqlRoot] Test-TargetResource: Drive E label
'System.Object[]' does not match expected label 'COMPUTER1_root'.
VERBOSE: [COMPUTER1]: LCM: [ End Test ] [[xDisk]sqlRoot] False in 4.8800 seconds.
VERBOSE: [COMPUTER1]: LCM: [ End Resource ] [[xDisk]sqlRoot]

I can probably provide a stripped down cluster configuration if you need it for testing.

The current xDisk resource is limited to creating only simple disk/partition/volume layouts. Fixing these limitations will require the functionality of the xDisk resource to be broken into smaller "single function" resources. This has been covered in several issues over the past year.

This problem is described quite well in this article written by @rchaganti .

To resolve this I am proposing creating the following three resources that could be used in place of xDisk. The resource MOF files are proposed only (not final) - they will require refinement:

• xDiskEx:

[ClassVersion("1.0.0.0"), FriendlyName("xDiskEx")]
class MSFT_xDiskEx : OMI_BaseResource
{
    [Key, Description("Specifies the disk identifier for the disk to modify.")] String DiskId;
    [Write, Description("Specifies the identifier type the DiskId contains. Defaults to Number."), ValueMap{"Number","UniqueId"}, Values{"Number","UniqueId"}] String DiskIdType;
    [Write, Description("Specifies the partition style to of the disk. Defaults to GPT."), ValueMap{"MBR","GPT","RAW"}, Values{"MBR","GPT","RAW"}] String PartitionStyle;
    [Write, Description("Operational Status of the disk. Defaults to Online."), ValueMap{"Online","Offline"}, Values{"Online","Offline"}] String OperationalStatus;
    [Write, Description("Specifies if the disk is read only. Defaults to false.")] boolean IsReadOnly;
    [Write, Description("Allow the disk to be be destructively changed.")] boolean AllowDestructive;
};

Note: Operational Status is included to provide better support for clustered disks.

• xPartition

[ClassVersion("1.0.0.0"), FriendlyName("xPartition")]
class MSFT_xPartition : OMI_BaseResource
{
    [Key, Description("Specifies the disk identifier for the disk to modify.")] String DiskId;
    [Write, Description("Specifies the identifier type the DiskId contains. Defaults to Number."), ValueMap{"Number","UniqueId"}, Values{"Number","UniqueId"}] String DiskIdType;
    [Key, Description("Partition Number.")] UInt32 PartitionNumber;
    [Write, Description("Specifies the size of the partition. If omitted will use the entire disk.")] Uint64 Size;
    [Write, Description("Allow the partition to be destructively changed if required.")] boolean AllowDestructive;
};

• xVolume

[ClassVersion("1.0.0.0"), FriendlyName("xVolume")]
class MSFT_xVolume : OMI_BaseResource
{
    [Key, Description("Specifies the disk identifier for the disk to modify.")] String DiskId;
    [Write, Description("Specifies the identifier type the DiskId contains. Defaults to Number."), ValueMap{"Number","UniqueId"}, Values{"Number","UniqueId"}] String DiskIdType;
    [Key, Description("Partition Number.")] UInt32 PartitionNumber;
    [Key, Description("Volume Number.")] UInt32 VolumeNumber;
    [Write, Description("Specifies the size of the volume. If omitted will use the entire partition.")] Uint64 Size;
    [Write, Description("Specifies the file system format of the volume."), ValueMap{"NTFS","ReFS"}, Values{"NTFS","ReFS"}] String FSFormat;
    [Write, Description("Define volume label if required.")] String FSLabel;
    [Write, Description("Specifies the allocation unit size to use when formatting the volume.")] Uint32 AllocationUnitSize;
    [Write, Description("Specifies the disk letter to assign to the volume.")] String DriveLetter;
    [Write, Description("Specifies the access path folder to the assign the to the volume.")] String AccessPath;
    [Write, Description("Allow the volume to be destructively changed if required.")] boolean AllowDestructive;
};

All discussion welcome! I'd like to begin working on this over the next month (unless someone else volunteers 😁).

Trying to use the 2nd example in https://github.com/PowerShell/xStorage#examples, I get an error

Cannot bind argument to parameter 'InputObject' because it is null.

when trying to change the drive letter.

This appears to happen because https://github.com/PowerShell/xStorage/blob/dev/DSCResources/MSFT_xMountImage/MSFT_xMountImage.psm1#L94 returns null. When I run that manually the ObjectId of the image has extra strings in it so it doesn't match the DeviceId:

DeviceID                     : \\?\Volume{b153fdb9-87e2-11e5-80b3-005056fce5a0}\

vs $Image.ObjectId: {1}\\WIN-56OJJQTNIEP\root/Microsoft/Windows/Storage/Providers_v2\WSP_Volume.ObjectId="{4c19525a-f384-11e4-8044-806e6f6e6963}:VO:\\?\Volume{b153fdb9-87e2-11e5-80b3-005056fce5a0}\".

This is on Windows 10 with Powershell 5.1.14393.

The title should be self explanatory. The ExampleScript.ps1 does not work, as it imports what appears to be an old name for this module, xDiskImage, instead of the current name, xStorage.

Can we incorporate a disk's unique id (NAA ID) into the xDisk resource?

During a SQL Server failover cluster build with SAN attached storage, I noticed that disk numbers assigned by Windows do not necessarily follow the increasing order of NAAIDs during LUN creation.

Example:
NAAID '100A', VolumeLabel 'Data' -> WindowsAssignedDiskNum 0 (expected 0)
NAAID '100B', VolumeLabel 'Logs' -> WindowsAssignedDiskNum 3 (expected 1)
NAAID '100C', VolumeLabel 'TempDB' -> WindowsAssignedDiskNum 1 (expected 2)
NAAID '100D', VolumeLabel 'Quorum' -> WindowsAssignedDiskNum 2 (expected 3)

Since I do not reliably know which disk numbers will be associated with which volumes in advance, I cannot use the xDisk resource in a configuration unless I first manually confirm the disk number to volume label (FSLabel) mappings. This interrupts the complete automation experience.

However, the LUNs NAA ID to volume label mappings are known after creating LUNs, which is a step prior to node configuration. It would be great if the NAA ID information could be used in place of disk numbers in the xDisk resource.

Example:
xDisk 'DataDisk'
{
UniqueId = "100A"
DriveLetter = "G"
FSLabel = "Data"
AllocationUnitSize = 65536
}

I suppose the NAA ID to disk number resolution could be achieved outside the xDisk resource (Get-Disk | select number, uniqueid), in the DSC configuration script. But in my case, I'm using the xDisk resource inside a Chef recipe where native powershell code output isn't easily mixed in. I am still investigating my options there.

Thanks for entertaining my suggestion!

Additions have been made to this module in a separate repo:
https://github.com/robwi/xStorage

HELP WANTED

If someone would like to review this work and incorporate changes back to the resource kit as a new PR, that would be a great project.

Lines 10 - 34 in the readme.md are not useful and haven't been kept up-to-date. I think they should be removed.

The lines read:

This module contains the xMountImage, xDisk, and xWaitForDisk resources. The xMountImage resource can be used to mount or unmount an ISO/VHD disk image to the local file system, with simple declarative language. The xDisk and xWaitforDisk resources enable you to wait for a disk to become available and then initialize, format, and bring it online using PowerShell DSC.

NOTE: The xDisk resource follows a process to detect the existance of a RAW disk, initialize the disk, create a volume, assign a drive letter of specific size (if provided) or maximum size, then format the new volume using NTFS and assign a volume label if one is provided.
Before beginning that operation, the disk is marked 'Online' and if it is set to 'Read-Only', that property is removed.
While this is intended to be non-destructive, as with all experimental resources the scripts contained should be thoroughly evaluated and well understood before implementing in a production environment or where disk modifications could result in lost data.

All of the resources in the DSC Resource Kit are provided AS IS, and are not supported through any Microsoft standard support program or service. The "x" in xStorage stands for experimental, which means that these resources will be fix forward and monitored by the module owner(s).

Please leave comments, feature requests, and bug reports in the Q & A tab for this module.

If you would like to modify this module, feel free. When modifying, please update the module name, resource friendly name, and MOF class name (instructions below). As specified in the license, you may copy or modify this resource as long as they are used on the Windows Platform.

For more information about Windows PowerShell Desired State Configuration, check out the blog posts on the PowerShell Blog (this is a good starting point). There are also great community resources, such as PowerShell.org, or PowerShell Magazine. For more information on the DSC Resource Kit, checkout this blog post.

Installation

To install the xStorage module

• If you are using WMF4 / PowerShell Version 4: Unzip the content under $env:ProgramFilesWindowsPowerShellModules folder

• If you are using WMF5 Preview: From an elevated PowerShell session run Install-Module xStorage

To confirm installation

• Run Get-DSCResource to see that the resources listed above are among the DSC Resources displayed

This PR added shared AppVeyor deployment and Wiki generation code into DSCResource.Tests.

Update this repo to use this new code.

While working on the other issues I noticed that the following config won't work as intended:

        xDisk GVolume
        {
             DiskId = 2
             DriveLetter = 'G'
             FSLabel = 'Store'
             Size = 10GB
        }

        xDisk JVolume
        {
             DiskId = 2
             DriveLetter = 'J'
             FSLabel = 'Data'
             DependsOn = '[xDisk]GVolume'
        }

It should produce two volumes on Disk Number 2, but it doesn't. Instead it just creates one volume and then renames it from G drive to J Drive and changes the label from Store to Data.

It should have created two volumes, one consuming 10GB and the other consuming all remaining space.

PS C:\Users\GlennMate> Install-Module xNetworking -Force
PackageManagement\Install-Package : A command with name 'Get-LocalizedData' is already available on this system. This
module 'xNetworking' may override the existing commands. If you still want to install this module 'xNetworking', use
-AllowClobber parameter.
At C:\Program Files\WindowsPowerShell\Modules\PowerShellGet\1.0.0.1\PSModule.psm1:1772 char:21
+ ...          $null = PackageManagement\Install-Package @PSBoundParameters
+                      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (Microsoft.Power....InstallPackage:InstallPackage) [Install-Package],
   Exception
    + FullyQualifiedErrorId : CommandAlreadyAvailable,Validate-ModuleCommandAlreadyAvailable,Microsoft.PowerShell.Pack
   ageManagement.Cmdlets.InstallPackage

As of the 4.0.0.0 release today, this module now conflicts with the newly released 3.0.0.0 version of xStorage. The only way to install this module is to use Install-Module xNetworking -Force -AllowClobber. This should break aliases between DSC resources.

Please address ASAP, this is a big breaking change.

This issue was raised by @glennmate in xNetworking here: dsccommunity/NetworkingDsc#213

This does not necessarily require renaming this module to HQRM naming but this module should be updated to bring it inline with current HQRM standards.

I'm working on this at the moment.

I suggest we add a VS Code workspace setting file with the following settings:

// Place your settings in this file to overwrite default and user settings.
{
    "powershell.codeFormatting.openBraceOnSameLine": false,
    "powershell.codeFormatting.newLineAfterOpenBrace": false,
    "powershell.codeFormatting.newLineAfterCloseBrace": true,
    "powershell.codeFormatting.whitespaceBeforeOpenBrace": true,
    "powershell.codeFormatting.whitespaceBeforeOpenParen": true,
    "powershell.codeFormatting.whitespaceAroundOperator": true,
    "powershell.codeFormatting.whitespaceAfterSeparator": true,
    "powershell.codeFormatting.ignoreOneLineBlock": false,
    "powershell.codeFormatting.alignPropertyValuePairs": true,
    "files.trimTrailingWhitespace": true,
    "files.insertFinalNewline": true
}

This is discussed here PowerShell/DscResources#284.

That will make it possible inside VS Code to press SHIFT+ALT+F or press F1 and choose 'Format document' in the list. The PowerShell code will then be formatted according to the Style Guideline (although maybe not complete, but would help a lot).

I don't believe a warning alone is acceptable. We can add another property to say it is acceptable not to change the AllocationUnitSize if the disk is already formatted, but without that described the behavior should be to get to the desired state.

When I install the module, I get duplicate entries. This causes Publish-AzureVMDSCConfiguration to fail when attempting to resolve the module.

Below is the output of the installation showing the dup. xStorage was not previously installed on this machine, so it was not preexisting.

PS C:\Program Files\WindowsPowerShell\Modules> Install-Module xStorage

Untrusted repository
You are installing the modules from an untrusted repository. If you trust this repository, change its
InstallationPolicy value by running the Set-PSRepository cmdlet. Are you sure you want to install the modules from
'PSGallery'?
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is "N"): y
PS C:\Program Files\WindowsPowerShell\Modules> get-module -ListAvailable -FullyQualifiedName xStorage | fl

Name : xStorage
Path : C:\Program Files\WindowsPowerShell\Modules\xStorage\2.5.0.0\xStorage.psd1
Description : This module contains all resources related to the PowerShell Storage module, or pertaining to disk
management.
ModuleType : Manifest
Version : 2.5.0.0
NestedModules : {}
ExportedFunctions :
ExportedCmdlets :
ExportedVariables :
ExportedAliases :

Name : xStorage
Path : C:\Program Files\WindowsPowerShell\Modules\xStorage\2.5.0.0\xStorage.psd1
Description : This module contains all resources related to the PowerShell Storage module, or pertaining to disk
management.
ModuleType : Manifest
Version : 2.5.0.0
NestedModules : {}
ExportedFunctions :
ExportedCmdlets :
ExportedVariables :
ExportedAliases :

It refers to a parameter "Count". This parameter does not exist. It should be "RetryCount".

This is because the name of the Localization string is incorrect in these lines:
https://github.com/PowerShell/xStorage/blob/dev/Modules/xStorage/DSCResources/MSFT_xDisk/MSFT_xDisk.psm1#L375

https://github.com/PowerShell/xStorage/blob/dev/Modules/xStorage/DSCResources/MSFT_xDiskAccessPath/MSFT_xDiskAccessPath.psm1#L369

When attempting to use 2.9.0.0 I keep getting volumes left in a "raw" volumes with assigned driver letters state even when specifying FSFormat. In the logs I am getting the following errors:

VERBOSE: [localhost]: [[xDisk]Edrive_xDISK] Set-TargetResource: Creat
ing partition on disk number '2' with drive letter 'E' using all free space.
VERBOSE: [localhost]: [[xDisk]Edrive_xDISK] Set-TargetResource: Forma
tting the volume as 'NTFS'.
Cannot perform the requested operation when the drive is read only
+ CategoryInfo : NotSpecified: (StorageWMI:) [], CimException
+ FullyQualifiedErrorId : StorageWMI 43006,Format-Volume
+ PSComputerName : localhost

VERBOSE: [ocalhost]: LCM: [ End Set ] [[xDisk]Edrive_xDISK] in 2.4240 seconds.
The PowerShell DSC resource '[xDisk]Edrive_xDISK' with SourceInfo
'C:\Users\myprofile\Desktop\TestDSC\SSRSDSC.ps1::71::9::xDisk' threw one or more non-terminating
errors while running the Set-TargetResource functionality. These errors are logged to the ETW
channel called Microsoft-Windows-DSC/Operational. Refer to this channel for more details.
+ CategoryInfo : InvalidOperation: (:) [], CimException
+ FullyQualifiedErrorId : NonTerminatingErrorFromProvider
+ PSComputerName : localhost

Below is an example of the config I am using when getting this error:

    xDisk Hdrive_xDISK
    {
         DiskNumber = 5
         DriveLetter = "H"
         FSlabel = "TempDB"
         FSFormat = "NTFS"
         AllocationUnitSize = 65536
         DependsOn = "[xWaitforDisk]Disk5_xDISK"
    }

I can say that if I keep going back and deleting the volume and running the dsc config it will eventually get a correct NTFS volume, but takes about 3 to 5 times before it won't be in a broken state with a "raw" volume. I have also looked at the disk and confirm they are not in read only. Assuming something in the dsc resource is temporarily putting the disk into a read only mode, but as soon as the config is complete and bombs out the disk is not in read only mode.

If I drop back down to my previous version I was using successfully (2.6.0.0), this problem does not exist.

if a disk is present with a file system, but no drive letter assigned - will fail to assign drive letter with error that Null value is not allowed for parameter.

Code in module presumes a drive letter is assigned.

xNetworking was recently updated to include Wiki support, markdown validation, code coverage and additional tests (examples etc).

I'd like to update this module with the same features as it is fairly similar in structure.

The xMountImage resource is defined in a way that it can easily cause invalid configurations.

The Name parameter is the current Key and should not be required or used at all. It should be removed completely.

The DriveLetter parameter should be set as the Key for this resource. This will prevent invalid configurations (where a two different images are mounted to the same drive).

The ImagePath parameter should be a required parameter.

I'd propose the MOF:

[ClassVersion("1.0.0.0"), FriendlyName("xMountImage")]
class MSFT_xMountImage : OMI_BaseResource
{
    [Required, Description("Specifies the path of the VHD or ISO file")] String ImagePath;
    [Key, Description("Specifies the drive letter after the ISO is mounted")] String DriveLetter;
    [Write, Description("Determines whether the setting should be applied or removed"), ValueMap{"Present","Absent"}, Values{"Present","Absent"}] String Ensure;
};

I realize this is a breaking change, but I think this needs to be done because:

1. the resource is broken in it's current state
2. there are several bugs in the current resource that prevent it from being used in many cases (basic unit and integration tests would have picked these problems up).

I'm currently working on bringing this resource module up to HQRM standards but I think this needs to be fixed at the same time.

@TravisEz13 - what do you reckon?

I'm not sure why, but a number of the unit tests have broken since the last release:

https://ci.appveyor.com/project/PlagueHO/xstorage/build/2.9.59.0

It appears that a recent pester (4.0.2) change has broken these. Pester version 3.4.6 works correctly. It appears to be a pester bug that prevents Get-Volume from being mocked in two successive Context blocks. Only the first Mock works. The second Mock does not mock the call and so the underlying cmdlet is called instead.

@PlagueHO thank you for a fantastic resource. I've been using it in production and it's been working a treat. I have come across a small issue where the resource is not keeping the desired state in certain situations.

Say I have 3x disks mounted to 3x directories

C:\MountPoint\SQLDATA01 (maps to disk 2)
C:\MountPoint\SQLDATA02 (maps to disk 3)
C:\MountPoint\SQLDATA03 (maps to disk 4)

Situation 1:

I delete C:\MountPoint\SQLDATA03 then run another consistency check. The resource doesn't re-attach the disk back to C:\MountPoint\SQLDATA03. Instead the following message appears "Not enough available capacity".

VERBOSE: [S12AUMDC01TST83]: LCM:  [ Start  Resource ]  [[xDiskAccessPath]DiskAccessPathSQLDATA03]
VERBOSE: [S12AUMDC01TST83]: LCM:  [ Start  Test     ]  [[xDiskAccessPath]DiskAccessPathSQLDATA03]
VERBOSE: [S12AUMDC01TST83]:                            [[xDiskAccessPath]DiskAccessPathSQLDATA03] Test-TargetResource: Testing Disk '4' status for access path 'C:\MountPoint\SQLDATA03'.
VERBOSE: [S12AUMDC01TST83]:                            [[xDiskAccessPath]DiskAccessPathSQLDATA03] Test-TargetResource: Checking if disk number '4' is initialized.
VERBOSE: [S12AUMDC01TST83]:                            [[xDiskAccessPath]DiskAccessPathSQLDATA03] Test-TargetResource: A volume assigned to access path 'C:\MountPoint\SQLDATA03\' was not found.
VERBOSE: [S12AUMDC01TST83]: LCM:  [ End    Test     ]  [[xDiskAccessPath]DiskAccessPathSQLDATA03]  in 0.0320 seconds.
VERBOSE: [S12AUMDC01TST83]: LCM:  [ Start  Set      ]  [[xDiskAccessPath]DiskAccessPathSQLDATA03]
VERBOSE: [S12AUMDC01TST83]:                            [[xDiskAccessPath]DiskAccessPathSQLDATA03] Set-TargetResource: Setting Disk '4' status for access path 'C:\MountPoint\SQLDATA03'.
VERBOSE: [S12AUMDC01TST83]:                            [[xDiskAccessPath]DiskAccessPathSQLDATA03] Set-TargetResource: Checking disk number '4' partition style.
VERBOSE: [S12AUMDC01TST83]:                            [[xDiskAccessPath]DiskAccessPathSQLDATA03] Set-TargetResource: Disk number '4' is already initialized with GPT.
VERBOSE: [S12AUMDC01TST83]:                            [[xDiskAccessPath]DiskAccessPathSQLDATA03] Set-TargetResource: Creating partition on disk number '4' using all free space.
Invoke-CimMethod : Not enough available capacity

Situation 2:

If I change the resource config to say instead of disk 4 mapping to C:\MountPoint\SQLDATA03, it should map to C:\SQLDATA03, the same message appears, "Not enough available capacity".

If mounting a volume with pre-existing data at least set the drive letter

If you do something like:

Configuration Server
{
    Import-DSCResource -Name xWaitforDisk -Module xStorage
    Import-DSCResource -Name xDisk -Module xStorage

    Node "perftest01"
    {
        xWaitforDisk Disk2
        {
            DiskNumber = 1
            RetryIntervalSec = 60
            RetryCount = 10
        }

        xDisk DVolume
        {
            DiskNumber = 1
            DriveLetter = 'D'
            Size = 1GB
        }
    }
}

Server
Start-DscConfiguration -Force -Verbose -Wait -path .\Server

followed by

Configuration Server
{
    Import-DSCResource -Name xWaitforDisk -Module xStorage
    Import-DSCResource -Name xDisk -Module xStorage

    Node "perftest01"
    {
        xWaitforDisk Disk2
        {
            DiskNumber = 1
            RetryIntervalSec = 60
            RetryCount = 10
        }

        xDisk DVolume
        {
            DiskNumber = 1
            DriveLetter = 'D'
            Size = 10GB
        }
    }
}

Server
Start-DscConfiguration -Force -Verbose -Wait -path .\Server

(note that the only difference is the size specified for DVolume)

The DSC run will fail:

VERBOSE: Perform operation 'Invoke CimMethod' with following parameters, ''methodName' =
SendConfigurationApply,'className' = MSFT_DSCLocalConfigurationManager,'namespaceName' =
root/Microsoft/Windows/DesiredStateConfiguration'.
VERBOSE: An LCM method call arrived from computer PERFTEST01 with user sid
S-1-5-21-1778218145-2021600166-3147052739-5183.
VERBOSE: [PERFTEST01]: LCM:  [ Start  Set      ]
VERBOSE: [PERFTEST01]: LCM:  [ Start  Resource ]  [[xWaitForDisk]Disk2]
VERBOSE: [PERFTEST01]: LCM:  [ Start  Test     ]  [[xWaitForDisk]Disk2]
VERBOSE: [PERFTEST01]:                            [[xWaitForDisk]Disk2] Checking for disk '1' ...
VERBOSE: [PERFTEST01]:                            [[xWaitForDisk]Disk2] Found disk 'HP LOGICAL VOLUME SCSI Disk
Device'.
VERBOSE: [PERFTEST01]: LCM:  [ End    Test     ]  [[xWaitForDisk]Disk2]  in 1.6720 seconds.
VERBOSE: [PERFTEST01]: LCM:  [ Skip   Set      ]  [[xWaitForDisk]Disk2]
VERBOSE: [PERFTEST01]: LCM:  [ End    Resource ]  [[xWaitForDisk]Disk2]
VERBOSE: [PERFTEST01]: LCM:  [ Start  Resource ]  [[xDisk]DVolume]
VERBOSE: [PERFTEST01]: LCM:  [ Start  Test     ]  [[xDisk]DVolume]
VERBOSE: [PERFTEST01]:                            [[xDisk]DVolume] Checking if disk number '1' is initialized...
VERBOSE: [PERFTEST01]:                            [[xDisk]DVolume] Drive D size does not match expected value. Current:
 1073741824 Expected: 524288000
VERBOSE: [PERFTEST01]: LCM:  [ End    Test     ]  [[xDisk]DVolume]  in 0.2350 seconds.
VERBOSE: [PERFTEST01]: LCM:  [ Start  Set      ]  [[xDisk]DVolume]
VERBOSE: [PERFTEST01]:                            [[xDisk]DVolume] Checking existing disk partition style...
VERBOSE: [PERFTEST01]:                            [[xDisk]DVolume] Disk number '1' is already configured for 'GPT'
VERBOSE: [PERFTEST01]:                            [[xDisk]DVolume] Creating the partition...
VERBOSE: [PERFTEST01]:                            [[xDisk]DVolume] Formatting the volume...
The requested access path is already in use.
    + CategoryInfo          : InvalidArgument: (StorageWMI:) [], CimException
    + FullyQualifiedErrorId : StorageWMI 42002,New-Partition
    + PSComputerName        : perftest01

VERBOSE: [PERFTEST01]: LCM:  [ End    Set      ]  [[xDisk]DVolume]  in 5.6560 seconds.
The PowerShell DSC resource MSFT_xDisk threw one or more non-terminating errors while running the Set-TargetResource
functionality. These errors are logged to the ETW channel called Microsoft-Windows-DSC/Operational. Refer to this
channel for more details.
    + CategoryInfo          : InvalidOperation: (:) [], CimException
    + FullyQualifiedErrorId : NonTerminatingErrorFromProvider
    + PSComputerName        : perftest01

VERBOSE: [PERFTEST01]: LCM:  [ End    Set      ]
The SendConfigurationApply function did not succeed.
    + CategoryInfo          : NotSpecified: (root/Microsoft/...gurationManager:String) [], CimException
    + FullyQualifiedErrorId : MI RESULT 1
    + PSComputerName        : perftest01

VERBOSE: Operation 'Invoke CimMethod' complete.
VERBOSE: Time taken for configuration job to complete is 8.485 seconds

When I have a DSC resource mounting an ISO, the mounted image is not available straight away:

xMountImage MOUNT_ISO {
            Ensure = 'Present'
            ImagePath = 'C:\MY.iso'
            DriveLetter = 'S:'
            Name = 'ISO'
        }
Script TEST_ISO {
    GetScript  =  {
                return @{'result'=(Test-Path 'S:\')}
            }
            TestScript =  {
                Test-Path 'S:\'
            }
            SetScript  =  {
                $countdown = 1
                while (!(Test-Path 'S:\'))
                {
                    Write-Verbose "Waiting and Counting down $Countdown"
                    Get-PSDrive
                    Start-Sleep -Seconds 1
                    if($countdown++ -ge 5) {
                        Throw "The iso took more than 5 seconds to mount"
                    }
                }
            }
}

This fails, unless I refresh the PS drives by adding $null = Get-PSDrive

It'd be good to add this in the xMountImage Set-TargetResource scriptblock.

xDisk does not show the caught Exception in the catch block in the Set-TargetResource function: https://github.com/PowerShell/xStorage/blob/dev/DSCResources/MSFT_xDisk/MSFT_xDisk.psm1#L149

The code $($Error[0]) is incorrect, and does not actually show the caught exception.

https://powershell.org/forums/topic/dsc-resource-for-mount-points/

Please kindly add support for mount points. Many server admins use Mount Points instead of Driver Letters. Example SQL Server which requires database files to be split over many LUNs to deal with queue depth issues.

So instead of...

xDisk CreateSVolumeForSQL 
{
    DiskNumber          = 2
    DriveLetter         = 'S'
    AllocationUnitSize  = 64kb
}

...you could do...

xDisk CreateMointPointForSQL
{
    DiskNumber          = 2
    MountPath           = 'C:\MyMounts\SQLData01'
    AllocationUnitSize  = 64kb
}

The readme.md contains a number of MD rule violations and doesn't match the layout defined in the Readme.md template.

In 2.4 the code below would successfully split a single disk in to multiple volumes. In 2.5 it detects the disk exists, and removes any existing volumes and creates the new one, reporting ERRORS. Thus it eventually leaves you with only one volume on a partially utilized disk

Mount and inititalise disks

    xWaitforDisk Disk
    {
         DiskNumber = 2
         RetryIntervalSec = 60
         RetryCount = 2
    }
    xDisk DataDiskF
    {
        DiskNumber = 2
        DriveLetter = "F"
        FSLabel = "SQL Data"
        Size = 200GB
    }
    xDisk DataDiskL
    {
        DiskNumber = 2
        DriveLetter = "L"
        FSLabel = "SQL Logs"
        Size = 60GB
    }
    xDisk DataDiskM
    {
        DiskNumber = 2
        DriveLetter = "M"
        FSLabel = "SQL Temp"
        Size = 50GB
    }
    xDisk DataDiskK
    {
        DiskNumber = 2
        DriveLetter = "N"
        FSLabel = "SQL Backup"
        Size = 200GB
    }

Would it be possible to add a Destructive switch to the schema so that existing partitions/volumes could be destroyed with Clear-Disk.

Thanks.

There should be a way to add multiple disks to a new volume.

On the xDisk dsc resource the following happens when a disk already exists but the disk label does not match the configured value:

• Test-DscResource return false (correct because the label does not match)
• Set-DscResource doesn't set the label (incorrect, should set the label)