dsccommunity/iscsidsc

DSC resources for configuring Windows iSCSI targets and initiators.

iscsidsc's Issues

Update CI Pipeline Files from Latest Pattern

Copy the latest patterns for the build.yml, build.ps1 and azure-pipelines.yml from the PR:
dsccommunity/ExchangeDsc#471

build.yml

####################################################
#      DscResource.DocGenerator Configuration      #
####################################################
DscResource.DocGenerator:
  Generate_Conceptual_Help:
    MarkdownCodeRegularExpression:
      - '\`(.+?)\`' # Match inline code-block
      - '\\(\\)' # Match escaped backslash
      - '\[[^\[]+\]\((.+?)\)' # Match markdown URL
      - '_(.+?)_' # Match Italic (underscore)
      - '\*\*(.+?)\*\*' # Match bold
      - '\*(.+?)\*' # Match Italic (asterisk)

  publish:
    - publish_module_to_gallery
    - Publish_Release_To_GitHub
    - Publish_GitHub_Wiki_Content
    - Create_ChangeLog_GitHub_PR

• Also add updated issue templates and related files:
• .github\ISSUE_TEMPLATE
• .github\CONTRIBUTING.md
• .github\PULL_REQUEST_TEMPLATE.md
• .github\ISSUE_TEMPLATE\General.md
• .github\ISSUE_TEMPLATE\Problem_with_resource.yml
• .github\ISSUE_TEMPLATE\Resource_proposal.yml
• .github\ISSUE_TEMPLATE\config.yml

Add SECURITY.md as well.

Also, update GitVersion task.

Module non-starter for most production workloads

iSCSiDsc: No MPIO support

Details: No MultiPath iSCSI initiator support (no idea on target but would presume same issue)
All DSC Configuration are affected. Support doesn't exist.

Windows 10/Server 2016 and Powershell:
Name Value

---

PSVersion 5.1.15063.1088
PSEdition Desktop
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 10.0.15063.1088
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1

Module = All, it isn't supported.

Feature Request: Ability to connect to iSCSI target when GUI status is 'Reconnecting...'

This feature will help the DSC resource bring the iSCSI connection back online (stay in Desired State) when network issues occur.

To emulate the 'Reconnecting...' status do the following:

(The idea is that the OS loads without being able to make a connection to the iSCSI target)

1.Power off the VM
2.Disconnect the Network card.
3.Power on the VM
4.Once OS had loaded, enable the Network Card

In Administrative Tools -> iSCSI Initiator you'll see the iSCSI target is 'Reconnecting...', however in Powershell can only see IsConnect True/False

PS C:> Get-iSCSISession | select *
AuthenticationType :
InitiatorInstanceName :
InitiatorNodeAddress : iqn.1991-05.com.microsoft:labserver01.pac.bvcorp.corp
InitiatorPortalAddress :
InitiatorSideIdentifier : 400001370001
IsConnected : False
IsDataDigest :
IsDiscovered : False
IsHeaderDigest :
IsPersistent :
NumberOfConnections : 0
SessionIdentifier : ffffe001ae4e4020-4000013700000001
TargetNodeAddress : iqn.2003-10.com.riverbed:labiscsitarget01.000
TargetSideIdentifier : 0000
PSComputerName :

Here is the error I get when I run Set-Target

PS C:> BMD_ciSCSIInitiator\Set-TargetResource @iSCSIParams -Verbose
VERBOSE: Set-TargetResource: Setting iSCSI Initiator 'iqn.2003-10.com.riverbed:labiscsitarget01.000', 'labiscsitarget01' from ''.
VERBOSE: Set-TargetResource: Ensuring iSCSI Target Portal 'labiscsitarget01' from '' exists.
VERBOSE: Set-TargetResource: Ensuring iSCSI Target 'iqn.2003-10.com.riverbed:labiscsitarget01.000' is connected.
Connect-IscsiTarget : The target name is not found or is marked as hidden from login.
At C:\Program Files\WindowsPowerShell\Modules\ciSCSI\DSCResources\BMD_ciSCSIInitiator\BMD_ciSCSIInitiator.psm1:479 char:24
• $Session = Connect-IscsiTarget `
• ~~~~~~~~~~~~~~~~~~~~~ ◦CategoryInfo : NotSpecified: (MSFT_iSCSITarget:ROOT/Microsoft/...SFT_iSCSITarget) [Connect-IscsiTarget], CimException
◦FullyQualifiedErrorId : HRESULT 0xefff0029,Connect-IscsiTarget

Opt-In to Additional Common Tests

"Common Tests - Validated Localization"

Opt-In to the PublishWikiContent in Invoke-AppVeyorDeployTask

Opt-In to the PublishWikiContent in Invoke-AppVeyorDeployTask

Enable Automated Documentation Publish to Wiki in Deployment

Add - Publish_GitHub_Wiki_Content to the publish: section of Build.yml.

Bugs found when testing this resource

1. Initiator ID's must be prefixed by IQN:
   https://github.com/PlagueHO/iSCSIDsc/blob/dev/Examples/Sample_iSCSIServerTarget.ps1#L42
   Also the example in the README needs updating (or removed an pointed to the one in Example folder)

InitiatorIds = 'IQN:iqn.2017-01.local.company:cluster01.company.local'

2. Example for 'iSCSIVirtualDisk iSCSIClusterVDisk02' uses 'UseFixed = $false' which does not exist.
   https://github.com/PlagueHO/iSCSIDsc#examples
   The example in the example folder is correct.

Not working on nano server

This DSC Resource is not working on nano server cause it uses get-wmiobject which is not available on nano. You should instead use CIM

https://docs.microsoft.com/en-us/windows-server/get-started/powershell-on-nano-server

Add Support for iSNS

This includes the following tasks:

• BMD_ciSCSIServerTarget: Enable iSCSI Target to be registered with an iSNS Server using:

set-wmiinstance -Namespace root\wmi -Class WT_iSNSServer -Arguments @{ServerName = 'ISNSSERVER.CONTOSO.COM'}

Use to check:

Get-WmiObject -Class WT_iSNSServer -Namespace root\wmi

Suggest adding a new string parameter "iSNSServer". If set, will cause the Target to be registered (if not already). If empty will cause it to be unregistered. If not provided will leave setting alone.

• BMD_ciSCSIInitiator: Enable iSCSI Initiator to be registered with an iSNS Server using:

Set-WmiInstance `
  -Namespace root\wmi `
  -Class MSiSCSIInitiator_iSNSServerClass `
  -Arguments @{iSNSServerAddress="ISNSSERVER.CONTOSO.COM"}

Use to check:

Get-WmiObject `
  -Class MSiSCSIInitiator_iSNSServerClass `
  -Namespace root\wmi

Suggest adding a new string parameter "iSNSServer". If set, will cause the Target to be registered (if not already). If empty will cause it to be unregistered. If not provided will leave setting alone.

Samples Incorrect

There is a problem with the iSCSI samples:
For the initiator it doesn't include the ID specifier

Complete Transfer of Ownership

Update the files in the repository to complete the transfer of ownership to dsccommunity.

Convert Module to use DSCResource.Common

See this PR for example: dsccommunity/NetworkingDsc#453

Depends on new CI Process

iSCSITargetPortal: make it possible to stage the setup

Resource proposal

while it is great to grab all inactive targets and connect them the process to actually get there is missing.
Situation:
We deploy a new cluster node and configure the necessary things for it on the iscsi server side.
Now we switch to the node-to-be and add the target portal. -> stage one
after that we log into it and see every target there is to have. -> stage two
With that setup we are able to connect every single target with the proper iqn and chap secret and what else you need to place. -> stage three

currently we can only setup these things if we already KNOW the nodeaddress.
This is a very static thing. with the staged process we are able to keep a minimum of configuration and make it work.
I am not fluent in iSCSI but that way it works just fine with Nutanix Volumes (Server) and Windows Server 2016-2022 (Client)
The server side here is non-windows so I do not need any dsc thingy on that part.

Proposed properties

Property	Type qualifier	Data type	Description	Default value	Allowed values
PropertyName	Key	String	Detailed description	None	None

We do not need any new properties related to iSCSIinitiator, we just need to drop the nodeaddress requirement to actually discover the targets before looping through them and use iSCSIInitiator after that.
That way we can error out early on and make sure to have the targetportal setup before the targets.
the current iSCSIinitiator does everything to setup a target but it is very repetitive to configure.

Special considerations or limitations

This might not be the correct process for every iSCSI setup so it might need to be tested for other configurations besides Nutanix Volumes.

Enable Code Coverage Reporting

Enable code coverage reporting as per this blog post: https://dsccommunity.org/blog/add-codecov-support-to-repository/

xiSCSI resources available that might add more functionality, but need community assistance

Details of the scenario you tried and the problem that is occurring:
Two new modules for Windows iSCSI are available but need assistance from the community. Review, tests, and docs.
https://github.com/robwi/xiSCSIServer
https://github.com/robwi/xiSCSIInitiator

HELP WANTED

This was initially submitted in the issue PowerShell/DscResources#216, but if there are any functionality that can be gained by these resource, they should be added here. If there are no functionality that can be reused, then please close this issue.

The DSC configuration that is using the resource (as detailed as possible):
n/a

Version of the Operating System and PowerShell the DSC Target Node is running:
n/a

Version of the DSC module you're using, or 'dev' if you're using current dev branch:
n/a

Set Optional Failure Flags for all PSSA Tests

Add the following opt-in settings to enable CI failure on violation of these PSSA rule types:

• Common Tests - Required Script Analyzer Rules

This will require conversion from WMI to CIM cmdlets

Correct Build.YML to Support ModuleBuilder 1.7.0

The ModuleBuilder 1.7.0 release renamed the CopyDirectories attribute to CopyPaths. Update the Build.yml to fix this issue.

Update module to new CI and release process

Since being migrated to the DSC Community, this module must be updated to use the new CI process and repository structure.

Deprecate iSNS Feature on Windows Server 2022

iSNS is no longer able to be installed on Windows Server 2022. Therefore, ISNS needs to be disabled in this resource for Windows Server 2022 installations. See https://docs.microsoft.com/en-us/windows-server/get-started/removed-features-1709

This means the resource is not working on Windows Server 2022 and will need significant changes before it can work on that OS.

Update Pull Request and Issue Templates Copied from xPSDesiredStateConfiguration

Copy the files:

.github/ISSUE_TEMPLATE/General.md
.github/ISSUE_TEMPLATE/Problem_with_resource.md
.github/PULL_REQUEST_TEMPLATE.md

From:
dsccommunity/xPSDesiredStateConfiguration#438

ResourceName: iscsiinitiator

applied configuration extremely similar to the example given for the iSCSIInitiator resource. however, tests show the following even though it is connected and working fine:

Service iSCSIService {
Name = 'MSiSCSI'
StartupType = 'Automatic'
State = 'Running'
}

iSCSIInitiator iSCSIInitiator {
Ensure = 'Present'
NodeAddress = 'iqn.2000-01.com.longiscsiname'
TargetPortalAddress = 'x.x.x.x'
InitiatorPortalAddress = 'x.x.x.x'
IsPersistent = $true
DependsOn = "[Service]iSCSIService"
}

VERBOSE: [mycomputer]: LCM: [ Start Resource ] [[iSCSIInitiator]iSCSIInitiator]
VERBOSE: [mycomputer]: LCM: [ Start Test ] [[iSCSIInitiator]iSCSIInitiator]
VERBOSE: [mycomputer]: [[iSCSIInitiator]iSCSIInitiator] Test-TargetResource: Testing iSCSI Initiator 'iqn.2000-01.com.longiscsiname', 'x.x.x.x' from ''.
VERBOSE: [mycomputer]: [[iSCSIInitiator]iSCSIInitiator] Test-TargetResource: iSCSI Connection 'iqn.2000-01.com.longiscsiname' does not exist but should. Change required.
VERBOSE: [mycomputer]: LCM: [ End Test ] [[iSCSIInitiator]iSCSIInitiator] False in 0.2500 seconds.
VERBOSE: [mycomputer]: LCM: [ End Resource ] [[iSCSIInitiator]iSCSIInitiator]

because it works correctly in applying, my temporary solution is to apply it, then comment it out, and apply my configuration again, so the testing doesn't keep alerting me on a false configuration.

Rename master branch to main

As per this statement.

Fix Build Failures due to Pester 5.x

Pester 5.x has been released and both Sampler and DSCResource.Test has been updated to support it, however, Code Coverage support is not available. To solve this, pin Pester to 4.10.1.

Add .GitAttributes File so that Example Publish Always Works

Example publishing could fail because .GitAttributes file is not included.

Bug: ciSCSIInitiator does not work when InitiatorPortalAddress is null

In our environment the InitiatorPortalAddress is null across all our servers. However, Get-TargetPortal requires you to provide a value for InitiatorPortalAddress. When Get-iSCSITargetPortal is run with InitiatorPortalAddress as null the CIM fails (of course).

So -InitiatorPortalAddress should not be Mandatory.

PS C:>> Get-iSCSITargetPortal

InitiatorInstanceName :
InitiatorPortalAddress :
IsDataDigest : False
IsHeaderDigest : False
TargetPortalAddress : MyTargetPortalHostname
TargetPortalPortNumber : 3260
PSComputerName :

iSCSIInitiator: iSCSI initiator doesn't refresh when new target is added

Details of the scenario you tried and the problem that is occurring

I connect to get the target portal to get the target nodes. When running the DSC script the first time, it connects to the target and get's the current targets. No issues here. I now go back and add a new target and I want to initiate that new target. iSCSIInitiator resource can't find the new target because the connection hasn't been updated to reflect that.

Verbose logs showing the problem

VERBOSE: [DEV-TEST-DELETE]:                            [[iSCSIInitiator]iSCSIInitiator-tgt1] Set-TargetResource: Ensuring iSCSI Target 'iqn.2010-06.com.nutanix:dev-test-vg-delete-63dc3822-a5a1-4ad8-b8b2-db6bd27addff-
tgt1' is connected.
VERBOSE: [DEV-TEST-DELETE]: LCM:  [ End    Set      ]  [[iSCSIInitiator]iSCSIInitiator-tgt1]  in 0.0620 seconds.
PowerShell DSC resource DSR_iSCSIInitiator  failed to execute Set-TargetResource functionality with error message: The running command stopped because the preference variable "ErrorActionPreference" or common 
parameter is set to Stop: The target name is not found or is marked as hidden from login.  
    + CategoryInfo          : InvalidOperation: (:) [], CimException
    + FullyQualifiedErrorId : ProviderOperationExecutionFailure
    + PSComputerName        : DEV-TEST-DELETE

Running Update-IscsiTarget to refresh the targets and then running the config again works fine.

Suggested solution to the issue

A few possible solutions.

Add a new parameter to force refresh of target.

[Parameter()]
[System.Boolean]
$RefreshTargets = $false

if($RefreshTargets) { Update-IscsiTargetPortal $TargetPortalAddress }

Another option would be to check if target exists and if doesn't then run Update-IscsiTargetPortal . If after this it fails, then it really should be an error.

You can run Update-IscsiTarget, but it does take much longer than Update-IscsiTargetPortal and it appears to list the target as it should.

The DSC configuration that is used to reproduce the issue (as detailed as possible)

iSCSIInitiator iSCSIInitiator-tgt0 {
    Ensure                 = 'Present'
    NodeAddress            = 'iqn.2010-06.com.nutanix:dev-test-vg-delete-63dc3822-a5a1-4ad8-b8b2-db6bd27addff-tgt0'
    TargetPortalAddress    = '192.168.100.1'
    IsPersistent           = $true
}

Add .VSCode Settings for PSScriptAnalyzer Rules

See PowerShell/DscResources#424

Update Sampler Build Tasks

Update the Sampler Build tasks as per this blog post: https://dsccommunity.org/blog/updating-sampler-github-tasks/

Update Azure DevOps Pipeline Images

The Ubuntu 16.04 and Windows Server 2016 Azure DevOps pipeline hosted images will be deprecated:

https://devblogs.microsoft.com/devops/hosted-pipelines-image-deprecation/

The pipeline stages need to be migrated to newer versions.

Migrate Pester Test Syntax from v3 -> v4

Details of the scenario you tried and the problem that is occurring:
As of Pester v4 the syntax of the Should cmdlet has changed from Should Be to Should -Be.

There is a helpful script that can be used to easily perform the conversion:
https://gist.github.com/indented-automation/aeb14825e39dd8849beee44f681fbab3

This script should be used to correct the Pester syntax.

iSCSIInitiator TargetPortalAddress should be a key property

Details of the scenario you tried and the problem that is occurring

My customer is trying to connect two target portals on their NetApp from one initiator address. Since the TargetPortalAddress is not a key property, this is not possible.

Verbose logs showing the problem

MOF creation already fails due to duplicate key constraints (Same NodeAddress, different TargetPortalAddress)

Test-ConflictingResources : A conflict was detected between resources '[iSCSIInitiator]i1 (::5::5::iSCSIInitiator)' and '[iSCSIInitiator]i2 (::11::5::iSCSIInitiator)' in node 'localhost'. Resources have 
identical key properties but there are differences in the following non-key properties: 'TargetPortalAddress'. Values '10.1.1.10' don't match values '10.1.129.10'. Please update these property values so 
that they are identical in both cases.
At line:289 char:9
+         Test-ConflictingResources $keywordName $canonicalizedValue $k ...
+         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (:) [Write-Error], InvalidOperationException
    + FullyQualifiedErrorId : ConflictingDuplicateResource,Test-ConflictingResources
Compilation errors occurred while processing configuration 'co'. Please review the errors reported in error stream and modify your configuration code appropriately.
At C:\Windows\system32\WindowsPowerShell\v1.0\Modules\PSDesiredStateConfiguration\PSDesiredStateConfiguration.psm1:3917 char:5
+     throw $ErrorRecord
+     ~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (co:String) [], InvalidOperationException
    + FullyQualifiedErrorId : FailToProcessConfiguration

Suggested solution to the issue

Make TargetPortalAddress a key property. I'd be happy to do it if you think it makes sense.

The DSC configuration that is used to reproduce the issue (as detailed as possible)

configuration co
{
    Import-DscResource -ModuleName iscsidsc

    iSCSIInitiator i1
    {
        NodeAddress = '192.168.2.12'
        TargetPortalAddress = '10.1.1.10'
    }

    iSCSIInitiator i2
    {
        NodeAddress = '192.168.2.12'
        TargetPortalAddress = '10.1.129.10'
    }
}
co -Verbose

The operating system the target node is running

OsName               : Microsoft Windows 10 Pro
OsOperatingSystemSKU : 48
OsArchitecture       : 64-bit
WindowsVersion       : 1909
WindowsBuildLabEx    : 18362.1.amd64fre.19h1_release.190318-1202
OsLanguage           : en-US
OsMuiLanguages       : {en-US}

Version and build of PowerShell the target node is running

Name                           Value                                                                                                                                                                        
----                           -----                                                                                                                                                                        
PSVersion                      5.1.18362.752                                                                                                                                                                
PSEdition                      Desktop                                                                                                                                                                      
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}                                                                                                                                                      
BuildVersion                   10.0.18362.752                                                                                                                                                               
CLRVersion                     4.0.30319.42000                                                                                                                                                              
WSManStackVersion              3.0                                                                                                                                                                          
PSRemotingProtocolVersion      2.3                                                                                                                                                                          
SerializationVersion           1.1.0.1 

Version of the DSC module that was used ('dev' if using current dev branch)

1.5.0.41

Convert Custom Exceptions to use Common Exception Functions

iSCSIVirtualDisk contains some old exception code that needs to be replaced with common exception code.

Refactor Repository Folder Structure so Harness not Required

See PowerShell/DscResource.Tests#225

Remove iSCSIInitiator IsPersistent parameter

I don't think this is useful when used in a DSC environment. The parameter could be removed from the MOF file but internally just default to $True.

Bug: ciSCSIInitiator does not work when hostname is used

@PlagueHO , thank you for writing this resource. I'm trying to get it installed in our environment but have come across a few issues.

If you define the TargetPortalAddress with a hostname. The check at line 790 fails.

$Connection.TargetAddress -ne $TargetPortalAddress

This is because Get-IscsiConnection returns an IP address and Get-IscsiTargetPortal returns an IP

ConnectionIdentifier : ffffe000fe0e2020-0
InitiatorAddress : 0.0.0.0
InitiatorPortNumber : 1472
TargetAddress : 192.168.0.5
TargetPortNumber : 3260
PSComputerName :

and Get-IscsiTargetPortal returns a hostname

InitiatorInstanceName :
InitiatorPortalAddress :
IsDataDigest : False
IsHeaderDigest : False
TargetPortalAddress : MyTargetPortalHostname
TargetPortalPortNumber : 3260
PSComputerName :