powershell / dscresource.template

DscResource.Template

The DscResource.Template module contains a template with example code and best practices for DSC resource modules in DSC Resource Kit.

NOTE! This is not meant to be a fully functioning resource module. The resource in this repository is just to make sure common code works, and used as a practical example.

This project has adopted this code of conduct.

Branches

master

This is the branch containing the latest release - no contributions should be made directly to this branch.

dev

This is the development branch to which contributions should be proposed by contributors as pull requests. This development branch will periodically be merged to the master branch, and be released to PowerShell Gallery.

Contributing

Please see our contributing guidelines.

Installation

GitHub

To manually install the module, download the source code and unzip the contents to the directory '$env:ProgramFiles\WindowsPowerShell\Modules' folder.

PowerShell Gallery

To install from the PowerShell gallery using PowerShellGet (in PowerShell 5.0) run the following command:

Find-Module -Name DscResource.Template -Repository PSGallery | Install-Module

To confirm installation, run the below command and ensure you see the DSC resources available:

Get-DscResource -Module DscResource.Template

Requirements

The minimum Windows Management Framework (PowerShell) version required is 4.0 or higher.

Examples

You can review the Examples directory for some general use scenarios for all of the resources that are in the module.

Change log

A full list of changes in each version can be found in the change log.

Resources

• Folder example resource to manage a folder on Windows.
• {Resource2 One line description of resource 1}

Folder

Example resource to manage a folder on Windows.

Requirements

• Target machine must be running Windows Server 2008 R2 or later.

Parameters

• [String] Path (Key): The path to the folder to create.
• [Boolean] ReadOnly (Required): If the files in the folder should be read only.
• [Boolean] Hidden (Write): If the folder should be hidden. Default value is $false.
• [String] Ensure (Write): Specifies the desired state of the folder. When set to 'Present', the folder will be created. When set to 'Absent', the folder will be removed. Default value is 'Present'.

Read-Only Properties from Get-TargetResource

• [Boolean] Shared (Write): If sharing is be enabled or disabled.
• [String] ShareName (Read): The name of the shared resource.

Examples

• Create folder as SYSTEM
• Create folder as user
• Remove folder

Known issues

All issues are not listed here, see here for all open issues.

{ResourceName}

{ Detailed description of ResourceName. }

Requirements

{ Please include any requirements for running this resource (e.g. Must run on Windows Server OS, must have Exchange already installed). }

• Target machine must be running Windows Server 2008 R2 or later.

Parameters

• {[String] Property1 (Key): Description of ResourceName property 1}
• {[Boolean] Property2 (Required): Description of ResourceName property 2}

Read-Only Properties from Get-TargetResource

• {[Boolean] Property3 (Write): Description of ResourceName property 2}

Examples

• { Add links to the examples for the resource ResourceName }

Known issues

All issues are not listed here, see here for all open issues.

dscresource.template's Issues

How TargetResource functions should be used discussion

I feel like there should be a helper function for test or something may need to change. I see a lot of resources checking parameters that are invalid and only setting those, instead of just setting all parameters.

I think this is ok, but this can cause a lot of duplicate code I noticed. If you were to go this direction, there should be a best practice or guidelines to suggest a certain way to structure your code.

Something I was thinking is:

Get-TargetResource - Nothing changes
Test-TargetResource - Wrapper function to a helper function that returns a boolean
Test-TargetResourceHelper - helper function that returns a hashtable maybe? This should also call Get-TargetResource for comparison. Something like:

@{
   'Ensure' = @{ 'expected' = 'Absent'; 'actual' = 'Present' }
   'invalidParameter' = @{ 'expected' = 'parameter passed in'; 'actual' = 'actual value set' }
}

or

@(
     @{'parameter'='Ensure'; 'expected' = 'Absent'; 'actual' = 'Present' },
     @{'parameter'='InvalidParam'; 'expected' = 'parameter passed in'; 'actual' = 'actual value set' }
 )

This is why we should do something like this.
Set-TargetResource can now call Test-TargetResourceHelper and get back an array or hashtable. You can now simply iterate over this and set only these values, but now you only need one code source for testing and you're not duplicating code.

This would not be required, but at least it can defined and thought of in case someone does want to use it. Seems like it would make maintenance a bit easier.

Update GitHub PR template

We could add this to the GitHub PR template to help contributors to update the necessary documentation.

- [ ] This PR changes DscResource.Template
  - [ ] Updated documentation as necessary in the TEMPLATE_README.md.
  - [ ] An descriptive entry has been added to the change log
        in the TEMPLATE_README.md.
- [ ] This PR changes Tests.Template
  - [ ] The template version number has been increased appropriately.
  - [ ] An descriptive entry has been added to the CHANGELOG.md under the
        Tests.Template folder.

Suggest moving TEMPLATE_README.md to the Wiki

Change log for this template repo is in the TEMPLATE_README.md, which is hard to know about, since pull request template are also a templat, it was menat that the entire repo could just be copied. I think the CHANGLOG.md should be part of the template, and should not have real template change log entires.

I suggest moving the TEMPLATE_README.md to the Wiki. It's still wouldn't be clear were to updatr the change log, but at least anyone could do it without sending in a PR.

Connect Codecov to DscResource.Template

@kwirkykat Could you connect Codecov to this repo?

Discussion: Add Optional files for Autodocumentation Wiki Repos

Just a discussion at this point: Can we add placeholder files for repos that implement autodocumentation files? E.g. there are the following differences:

1. README.MD in each resource folder
2. Different main README.MD file with much less info an point to Wiki.
3. Different AppVeyor.yml files

DscResource.LocalizationHelper Module is misnamed

Having the Exception helper functions in the DscResource.LocalizationHelper module is misleading. These functions are not related to localization (and can be used without). I don't think users would expect to find exception functions in there.

I think this module should be renamed to something more generalized such as 'DscResource.ResourceHelper'.

This also relates to this issue: PowerShell/DscResources#476

Another alternative would be to move the exception functions into DscResource.Common.

Unit Test Template: Remove unnecessary comment

This row should be removed from the unit template. This is now set with variables, and there is another comment above that covers that.

DscResource.Template/Tests/Unit/unit_test_template.ps1

Line 37 in 8425a13

# TODO: Insert the correct <ModuleName> and <ResourceName> for your resource

Add Opt-in to Common Tests - Validate Localization

Add the Opt-in to "Common Tests - Validate Localization" meta-tests.

Keep the old change log history

Maybe we should save the change log history of the test templates from the repo DscResources?

# Test Template Change List

Any changes made to the *Tests.Template* files must be added to the appropriate
section in this document.
The version number in the *Tests.Template* header must also be updated to match.
When the templates are used to create or update tests in a DSC Resource the
version number of the template file used must be included.

## integration_template.config.ps1

### Version 1.2.0

- Allows reading the configuration data from a JSON file,
  e.g. integration_template.config.json for real testing scenarios outside of
  the CI ([issue #89](https://github.com/PowerShell/DscResources/issues/89)).
- Removed `PSDscAllowPlainTextPassword` from the configuration and replaced it
  with `CertificateFile = $env:DscPublicCertificatePath` so the configuration
  can decrypt credentials if needed.

### Version 1.1.0

- Renamed filename of the integration test config template to use the right
  naming convention.
- Change so that 'Configuration' is written with upper 'C'. The name of the
  configuration has 'Config' as suffix, that also has upper 'C' now.
- Added a configuration data hash table to be used with the version 1.3.0 of the
  integration test template.
- Updated comments.

### Version 1.0.1

- Updated resource module name in comments to 'NetworkingDsc' and 'Firewall' to
  be consistent and use a HQRM resource module name as example.

### Version 1.0.0

- First release including version number

## integration_template.ps1

### Version 1.3.1

- When cloning DscResource.Tests, it using the same casing on the repository folder
  ([issue #431](https://github.com/PowerShell/DscResources/issues/431)).

### Version 1.3.0

- Clean up script variables according to style guideline.
- Added a $script:dscResourceFriendlyName variable.
- Wrapped It-blocks into a Context-block to differentiate each test
  configuration.
- Updated TODO comments.
- Added the use of a ConfigurationData block for variables.
- Made it easier to pass additional parameters to a configuration.
- Improved test that evaluates properties returned from
  Get-DscConfiguration ([issue #328](https://github.com/PowerShell/DscResources/issues/328)).
- Added a test that verifies that the correct value is returned from
  Test-DscConfiguration.

### Version 1.2.1

- Updated resource module name in comments to 'NetworkingDsc' and 'Firewall' to
  be consistent and use a HQRM resource module name as example.

### Version 1.2.0

- Update Pester syntax to v4
- Now `-ErrorAction Stop` is used for the cmdlet Start-DscConfiguration so
  that all errors throw an error making the tests fail.

### Version 1.1.2

- Removed backslashes from git clone command to improve compatibility with
  unusual file paths.

### Version 1.1.1

- Convert Invoke-Expression to '&' to improve readability

### Version 1.1.0

- Getting rid of git-dependency

### Version 1.0.0

- First release including version number

## unit_template.ps1

### Version 1.2.3

- When cloning DscResource.Tests, it using the same casing on the repository folder
  ([issue #431](https://github.com/PowerShell/DscResources/issues/431)).

### Version 1.2.3

- Update description in comment-based help.
- Added example of placement of mocks (issue #425).

### Version 1.2.2

- Added more Describe-blocks and updated the descriptions.
- Added more Context-blocks and updated the descriptions.
- Added a comment saying to remove any unused BeforeAll-, AfterAll-,
  BeforeEach- and AfterEach-blocks.

### Version 1.2.1

- Removed backslashes from git clone command to improve compatibility
  with unusual file paths.

### Version 1.1.0

- Getting rid of git-dependency

### Version 1.0.0

- First release including version number

Mandatory Parameters for get-targetresource

I ran into an issue working on another resource passing mandatory parameters to get-target. See here

DscResource.Template/DSCResources/MSFT_ResourceName/MSFT_ResourceName.psm1

Line 107 in 2cc2000

$getTargetResourceParameters = @{

This is fine, but the problem is when you have parameters needed for get-target, but they are not mandatory to pass in. An example may be Credential. I may not need a credential to be a mandatory parameter, but I need to pass it to get-target.

I came up with something like this:

    $getTargetResourceParameters = @{
        MandatoryParameter = $ServiceAccountName
        Credential          = $Credential
    }

    @($getTargetResourceParameters.Keys) | ForEach-Object {
        if( !$PSBoundParameters.ContainsKey($_) )
        {
            $getTargetResourceParameters.Remove($_)
        }
    }

    $getTargetResource = Get-TargetResource @getTargetResourceParameters

Using .json with Integration tests does not work

There is an option to use a .json file for the ConfigurationData-block.

DscResource.Template/Tests/Integration/integration_test_template.config.ps1

Lines 22 to 30 in 8425a13

	if (Test-Path -Path $configFile)
	{
	<#
	TODO: Allows reading the configuration data from a JSON file,
	e.g. integration_template.config.json for real testing
	scenarios outside of the CI.
	#>
	$ConfigurationData = Get-Content -Path $configFile | ConvertFrom-Json
	}

The problem is that this conversion returns a [PSCustomObject] instead of [Hashtable] which result in Start-DscConfiguration fails when it tries to convert [PSCustomObject] to [Hashtable] for the parameter ConfigurationData.

There is a solution in PowerShell 6.2 where ConvertFrom-Json has a parameter -AsHashtable. It does not help us so much. So work around this I think we need to convert the .json file to hashtable, or use a .psd1 file instead if that can be imported as a hashtable. Not looked in to any solution, just figure I submit an issue will memory is fresh. 🙂

Create dev branch and make it the default branch for PRs

@kwirkykat I don't have admin permission to do this, so can you help us with this?

• Create dev branch, and make it the default.
• Add repo description, something like "This repository contains a template for a DSC resources module", and point URL to the main DscResources repo.

Common localization messages

I didn't really see anything with common localization messages, but I noticed that a lot of resources will use the same exact message, but it may be slightly different.

Would it be a good idea to have common ones defined and then combine those with resource specific ones if needed?

Something like

ConvertFrom-StringData @'
    TestProperty = Testing '{0}' property
    GetProperty = Getting '{0}' properties value
@'

What's defined here is not relevant, just an example. This would be probably defined per repo as well. Now I can use these common ones or create a new one when needed.

This suggestion only talks about the ability to implement common messages and combine those with resource messages, but not defining the actual messages.

Connect AppVeyor to this repo

@kwirkykat Could you please connect AppVeyor to this repo? Also give us the API "key" to the repo in AppVeyor (for the badges in README.md).

Integration test 'Should return $true when Test-DscConfiguration is run' does not fail

I recently saw that the integration tests 'Should return $true when Test-DscConfiguration is run' that is part of the integration tests template does not fail as expected.

DscResource.Template/Tests/Integration/integration_test_template.ps1

Lines 108 to 110 in f91a425

	It 'Should return $true when Test-DscConfiguration is run' {
	Test-DscConfiguration -Verbose | Should -Be $true
	}

The reason is that Test-DscConfiguration returns a [System.String] and not a [System.Boolean], so this test always passes regardless of outcome.
Ii can be seen here on this line, it is reported False, but the test passes.
https://ci.appveyor.com/project/johlju/sqlserverdsc/builds/23132521/job/vkxi4xq8jqke7ahf#L1198

Verified it here too

PS > $result = Test-DscConfiguration -Verbose
VERBOSE: Perform operation 'Invoke CimMethod' with following parameters, ''methodName' = TestConfiguration,'className'
= MSFT_DSCLocalConfigurationManager,'namespaceName' = root/Microsoft/Windows/DesiredStateConfiguration'.
VERBOSE: An LCM method call arrived from computer SQLTEST with user sid S-1-5-21-2246212248-426023572-517575333-1441.
VERBOSE: [SQLTEST]: LCM:  [ Start  Test     ]
VERBOSE: [SQLTEST]: LCM:  [ Start  Resource ]  [[PSModule]InstallModule]
VERBOSE: [SQLTEST]: LCM:  [ Start  Test     ]  [[PSModule]InstallModule]
VERBOSE: [SQLTEST]:                            [[PSModule]InstallModule] Determining if the module 'posh-git' is in the
 desired state.
VERBOSE: [SQLTEST]:                            [[PSModule]InstallModule] Getting the current state of the module
'posh-git'.
VERBOSE: [SQLTEST]:                            [[PSModule]InstallModule] Begin invoking Get-Module 'posh-git'.
VERBOSE: [SQLTEST]:                            [[PSModule]InstallModule] Populating RepositorySourceLocation property
for module posh-git.
VERBOSE: [SQLTEST]:                            [[PSModule]InstallModule] Loading module from path 'C:\Program
Files\WindowsPowerShell\Modules\posh-git\0.7.3\posh-git.psm1'.
VERBOSE: [SQLTEST]:                            [[PSModule]InstallModule] Module 'posh-git 0.7.3' is found on the node.
VERBOSE: [SQLTEST]:                            [[PSModule]InstallModule] Module 'posh-git' is found on the node.
VERBOSE: [SQLTEST]:                            [[PSModule]InstallModule] Found the module path: 'C:\Program
Files\WindowsPowerShell\Modules\posh-git\0.7.3\PSGetModuleInfo.xml'.
VERBOSE: [SQLTEST]:                            [[PSModule]InstallModule] Resource 'posh-git' is in the desired state.
VERBOSE: [SQLTEST]: LCM:  [ End    Test     ]  [[PSModule]InstallModule] True in 2.6090 seconds.
VERBOSE: [SQLTEST]: LCM:  [ End    Resource ]  [[PSModule]InstallModule]
VERBOSE: [SQLTEST]: LCM:  [ End    Test     ]     Completed processing test operation. The operation returned True.
VERBOSE: [SQLTEST]: LCM:  [ End    Test     ]    in  3.2500 seconds.
VERBOSE: Operation 'Invoke CimMethod' complete.
VERBOSE: Time taken for configuration job to complete is 3.348 seconds
PS > $result
True
PS > $result.Gettype()

IsPublic IsSerial Name                                     BaseType
-------- -------- ----                                     --------
True     True     String                                   System.Object

So we should either change the line

DscResource.Template/Tests/Integration/integration_test_template.ps1

Line 109 in f91a425

Test-DscConfiguration -Verbose | Should -Be $true

to either

$result = Test-DscConfiguration -Verbose
[System.Boolean]::Parse($result) | Should -BeTrue

or

Test-DscConfiguration -Verbose | Should -Be 'True'

Common Verbose logging and standards

related to #17

I had a few ideas about logging.

1. Possibly group verbose messages together when possible (i'll show example)
2. Start each function with a verbose message saying what you are going to do
3. Verbose messages when comparing all parameters (state if parameter is in state or not)
4. On Test, verbose message if state is compliant or not (maybe redundant?)
5. Verbose message for every try/catch?

Example for 1:

ConvertFrom-StringData -StringData @'
    # Multiple (SRS{n}000) - These messages can be used for all areas in the script.
    # The 1000's decimal will say where the error came from [get (1),set (2),test (3), compare (4)]
    IssueRetrievingCIMInstance = There was an issue when trying to retrieve the CIM instance. This shouldn't have happened. For further diganostics, please ensure that the following command can run `{0}`. (SRS{1}001)
    IssueRetrievingRSInstance = There was an issue when trying to retrieve the Reporting Services instance name. This is probably due to the fact that Reporting Services may not be installed. (SRS{1}002)

    # Get-TargetResource (SRS0100)
    RetrievingRSState                = Attempting to get the current Reporting Service state. (SRS0100)
    RetrievingInstanceUrls           = Attempting to get the Reporting Service Instance Url list. (SRS0101)
    RetrievingInstanceUrlsSuccess    = Successfully retrieved the Reporting Service Instance Url list. (SRS0102)
    RetrievingModifiableUrls         = Attempting to get the Reporting Service Modifiable Url list. (SRS0103)
    RetrievingModifiableUrlsSuccess  = Successfully retrieved the Reporting Service Modifiable Url list. (SRS0104)
    RetrievingScaleOutServers        = Attempting to get a list of the Reporting Service Scale-Out servers. (SRS0104)
    RetrievingScaleOutServersSuccess = Successfully retrieved the list of Reporting Service Scale-Out servers. (SRS0105)
    RetrivedServiceAccount           = Retrieved the service account of '{0}', which is a '{1}' logon type. (SRS0106)

    # Test-TargetResource (SRS0200)
    TestingDesiredState = Testing if the Reporting Services instance of '{0}' is in desired state (SRS0200)
    RSInDesiredState    = Reporting Services '{0}' is in the desired state. (SRS0201)
    RSNotInDesiredState = Reporting Services '{0}' is NOT in the desired state. (SRS0202)

    # Set-TargetResource (SRS0300)
    SettingNonDesiredStateParameters = Attempting to set all parameters that are not in desired state for the instance '{0}'. (SRS0300)

    # Compare-TargetResourceState (SRS0400)
    ComparingSpecifiedParameters = Comparing all the parameters specified for the instance '{0}'. (SRS0400)
    CheckingParameterState       = Checking if the parameter '{0}' is in desired state. (SRS0401)
    ParameterNotInDesiredState   = The parameter '{0}' was found to NOT be in the correct desired state. Expected: '{1}', Actual '{2}'. (SRS0402)
    ParameterInDesiredState      = The parameter '{0}' was found to be the correct desired state. Expected: '{1}',        Actual '{2}'. (SRS0403)

    # (SRS9000) will be used for anything else
    # Get-RsCimInstance
    RetrievingRSInstanceNameAuto           = Attempting to retrieve the Reporting Service instance name automatically. (SRS9000)
    SetRSInstanceName                      = Reporting Service instance name was set to '{0}'. (SRS9001)
    RetrievingRSInstanceVersion            = Attempting to retrieve the Reporting Service instance version. (SRS9002)
    SetRSInstanceVersion                   = Reporting Service instance version was set to '{0}'. (SRS9003)
    RetrievingRSInstanceObject             = Attempting to retrieve the Reporting Service instance object. (SRS9004)
    RetrievingRSInstanceObjectSuccess      = The Reporting Services instance object was successfully retrieved. (SRS9005)
    RetrievingRSConfigurationObject        = Attempting to retrieve the Reporting Service configuration object. (SRS9006)
    RetrievingRSConfigurationObjectSuccess = The Reporting Services configuration object was successfully retrieved. (SRS9007)

    # MSFT_ReportServiceSkuUtils (SRS0600)
    RSSkuTypeNotInitialized       = It appears that the Reporting Services sku type hasn't been defined yet or not found. This should be set to one of the following types: {0}. (SRS0600)
    RSSkuTypeIsHigherEdition      = The Reporting services sku type: '{0}' was found to be a HIGHER edition than that of the '{1} Edition'. (SRS0601)
    RSSkuTypeIsNotHigherEdition   = The Reporting services sku type: '{0}' was found to be a LOWER edition than that of the '{1} Edition'. (SRS0602)
    RSSkuTypeFullNameNotFound     = Could not identify the reporting services edition of '{0}'. This could be that the edition is new and needs to be added to the resource. (SRS0603)
    RSandSQLEditionsNotValid      = The database installation of reporting services with the sku type of '{0}' is restricted on the SQL sku type of '{1}' (SRS0604)
    RSandSQLEditionsNotValidLocal = The database installation of reporting services with the sku type of '{0}' requires that the SQL instance be installed on the same node. It appears that you are trying to install reporting services on a remote node. (SRS0605)

'@

I'll try and explain. So it's kind of a rudimentary way to trace the code. Messages that can be used throughout start with {n}000, this gives you about 3000 messages basically. I'll explain later.

All messages that come from Get start with 0100
All messages that come from Test start with 0200
All messages that come from Set start with 0300

If it's a message that is shared, it would be whatever number each function starts with. So Get is 1, Test is 2, Set is 3. So if a shared message is called within Get, it would be 100x where x is whatever the actual message code is.

In this example, I have 9000+ has any other messages per function. so if i were to add more messaging for a new function I may want to do 9100. Giving me a possible 100 messages per function. This can really be whatever you want it to after 0300 though. And 1000-3999 would be reserved.

Few examples of what it would look like:
You can see here, It's called from Test -> Compare -> Get

VERBOSE: Testing if the Reporting Services instance of 'SSRS' is in desired state (SRS0200)
VERBOSE: Comparing all the parameters specified for the instance 'SSRS'. (SRS0400)
VERBOSE: Attempting to get the current Reporting Service state. (SRS0100)
VERBOSE: Reporting Service instance name was set to 'RS_SSRS'. (SRS9001)
VERBOSE: Attempting to retrieve the Reporting Service instance version. (SRS9002)
VERBOSE: Perform operation 'Enumerate CimInstances' with following parameters, ''namespaceName' = ROOT\Microsoft\SqlServer\ReportServer\RS_SSRS,'className' = __NameSpace'.
VERBOSE: Reporting Service instance version was set to ''. (SRS9003)
VERBOSE: Attempting to retrieve the Reporting Service instance object. (SRS9004)
VERBOSE: Perform operation 'Enumerate CimInstances' with following parameters, ''namespaceName' = ROOT\Microsoft\SqlServer\ReportServer\RS_SSRS\,'className' = MSReportServer_Instance'.
System.Exception: There was an issue when trying to retrieve the CIM instance. This shouldn't have happened. For further diganostics, please ensure that the following command can run
`Get-CimInstance -Error 'True' -Result 'Invalid namespace '`. (SRS9001) ---> Microsoft.Management.Infrastructure.CimException: Invalid namespace
   at Microsoft.Management.Infrastructure.Internal.Operations.CimAsyncObserverProxyBase`1.ProcessNativeCallback(OperationCallbackProcessingContext callbackProcessingContext, T
currentItem, Boolean moreResults, MiResult operationResult, String errorMessage, InstanceHandle errorDetailsHandle)

Another longer one with parameter comparison:

VERBOSE: Comparing all the parameters specified for the instance 'PBIRS'. (SRS0400)
VERBOSE: Attempting to get the current Reporting Service state. (SRS0100)
VERBOSE: Reporting Service instance name was set to 'RS_PBIRS'. (SRS9001)
VERBOSE: Attempting to retrieve the Reporting Service instance version. (SRS9002)
VERBOSE: Perform operation 'Enumerate CimInstances' with following parameters, ''namespaceName' = ROOT\Microsoft\SqlServer\ReportServer\RS_PBIRS,'className' = __NameSpace'.
VERBOSE: Operation 'Enumerate CimInstances' complete.
VERBOSE: Reporting Service instance version was set to 'V15'. (SRS9003)
VERBOSE: Attempting to retrieve the Reporting Service instance object. (SRS9004)
VERBOSE: Perform operation 'Enumerate CimInstances' with following parameters, ''namespaceName' = ROOT\Microsoft\SqlServer\ReportServer\RS_PBIRS\V15,'className' = MSReportServer_Instance'.
VERBOSE: Operation 'Enumerate CimInstances' complete.
VERBOSE: The Reporting Services instance object was successfully retrieved. (SRS9005)
VERBOSE: Attempting to retrieve the Reporting Service configuration object. (SRS9006)
VERBOSE: Perform operation 'Enumerate CimInstances' with following parameters, ''namespaceName' = ROOT\Microsoft\SqlServer\ReportServer\RS_PBIRS\V15\Admin,'className' =
MSReportServer_ConfigurationSetting'.
VERBOSE: Operation 'Enumerate CimInstances' complete.
VERBOSE: The Reporting Services configuration object was successfully retrieved. (SRS9007)
VERBOSE: Retrieved the service account of 'NT Service\PowerBIReportServer', which is a 'Virtual' logon type. (SRS0106)
VERBOSE: Attempting to get the Reporting Service Instance Url list. (SRS0101)
VERBOSE: Perform operation 'Invoke CimMethod' with following parameters, ''instance' = MSReportServer_Instance (InstanceName = "PBIRS"),'methodName' = GetReportServerUrls,'namespaceName' =
 ROOT/Microsoft/SqlServer/ReportServer/RS_PBIRS/V15'.
VERBOSE: Operation 'Invoke CimMethod' complete.
VERBOSE: Successfully retrieved the Reporting Service Instance Url list. (SRS0102)
VERBOSE: Attempting to get the Reporting Service Modifiable Url list. (SRS0103)
VERBOSE: Perform operation 'Invoke CimMethod' with following parameters, ''instance' = MSReportServer_ConfigurationSetting (InstanceName = "PBIRS"),'methodName' =
ListReservedURLs,'namespaceName' = ROOT/Microsoft/SqlServer/ReportServer/RS_PBIRS/V15/Admin'.
VERBOSE: Operation 'Invoke CimMethod' complete.
VERBOSE: Successfully retrieved the Reporting Service Modifiable Url list. (SRS0104)
VERBOSE: Attempting to get a list of the Reporting Service Scale-Out servers. (SRS0104)
VERBOSE: Perform operation 'Invoke CimMethod' with following parameters, ''instance' = MSReportServer_ConfigurationSetting (InstanceName = "PBIRS"),'methodName' =
ListReportServersInDatabase,'namespaceName' = ROOT/Microsoft/SqlServer/ReportServer/RS_PBIRS/V15/Admin'.
VERBOSE: Operation 'Invoke CimMethod' complete.
VERBOSE: Successfully retrieved the list of Reporting Service Scale-Out servers. (SRS0105)
VERBOSE: Checking if the parameter 'ServiceAccount' is in desired state. (SRS0401)
VERBOSE: The parameter 'ServiceAccount' was found to NOT be in the correct desired state. Expected: 'computer\user', Actual 'NT Service\PowerBIReportServer'. (SRS0402)
VERBOSE: Checking if the parameter 'ServiceAccountLogonType' is in desired state. (SRS0401)
VERBOSE: The parameter 'ServiceAccountLogonType' was found to NOT be in the correct desired state. Expected: 'Windows', Actual 'Virtual'. (SRS0402)
VERBOSE: Checking if the parameter 'ReportManagerVirtualDirectory' is in desired state. (SRS0401)
VERBOSE: The parameter 'ReportManagerVirtualDirectory' was found to NOT be in the correct desired state. Expected: 'ReportServer', Actual ''. (SRS0402)
VERBOSE: Checking if the parameter 'ReportManagerUrls' is in desired state. (SRS0401)
VERBOSE: The parameter 'ReportManagerUrls' was found to NOT be in the correct desired state. Expected: '[http://+:80]', Actual '[]'. (SRS0402)
VERBOSE: Checking if the parameter 'DatabaseServerInstance' is in desired state. (SRS0401)
VERBOSE: The parameter 'DatabaseServerInstance' was found to NOT be in the correct desired state. Expected: 'MyServer', Actual ''. (SRS0402)
VERBOSE: Checking if the parameter 'DatabaseName' is in desired state. (SRS0401)
VERBOSE: The parameter 'DatabaseName' was found to NOT be in the correct desired state. Expected: 'ReportDatabase', Actual ''. (SRS0402)
VERBOSE: Checking if the parameter 'ReportDatabaseCredential' is in desired state. (SRS0401)
VERBOSE: The parameter 'ReportDatabaseCredential' was found to NOT be in the correct desired state. Expected: 'reportuser', Actual ''. (SRS0402)
VERBOSE: Checking if the parameter 'ReportDatabaseLogonType' is in desired state. (SRS0401)
VERBOSE: The parameter 'ReportDatabaseLogonType' was found to NOT be in the correct desired state. Expected: 'Service', Actual 'Windows'. (SRS0402)
VERBOSE: Checking if the parameter 'EmailSender' is in desired state. (SRS0401)
VERBOSE: The parameter 'EmailSender' was found to NOT be in the correct desired state. Expected: '[email protected]', Actual ''. (SRS0402)
VERBOSE: Checking if the parameter 'EmailSMTP' is in desired state. (SRS0401)
VERBOSE: The parameter 'EmailSMTP' was found to NOT be in the correct desired state. Expected: 'smtp.amail.com', Actual ''. (SRS0402)
VERBOSE: Checking if the parameter 'EmailAuthentication' is in desired state. (SRS0401)
VERBOSE: The parameter 'EmailAuthentication' was found to be the correct desired state. Expected: 'None',        Actual 'None'. (SRS0403)
VERBOSE: Checking if the parameter 'EmailSMTPCredential' is in desired state. (SRS0401)
VERBOSE: The parameter 'EmailSMTPCredential' was found to NOT be in the correct desired state. Expected: 'dsasd', Actual ''. (SRS0402)
VERBOSE: Checking if the parameter 'ExecutionAccount' is in desired state. (SRS0401)
VERBOSE: The parameter 'ExecutionAccount' was found to NOT be in the correct desired state. Expected: 'execute', Actual ''. (SRS0402)
VERBOSE: Checking if the parameter 'FileShareAccount' is in desired state. (SRS0401)
VERBOSE: The parameter 'FileShareAccount' was found to NOT be in the correct desired state. Expected: 'share', Actual ''. (SRS0402)
VERBOSE: Checking if the parameter 'ReportWebPortalVirtualDirectory' is in desired state. (SRS0401)
VERBOSE: The parameter 'ReportWebPortalVirtualDirectory' was found to NOT be in the correct desired state. Expected: 'Reports', Actual ''. (SRS0402)
VERBOSE: Checking if the parameter 'ReportWebPortalUrls' is in desired state. (SRS0401)
VERBOSE: The parameter 'ReportWebPortalUrls' was found to NOT be in the correct desired state. Expected: '[https://+:80, http://]', Actual '[]'. (SRS0402)
VERBOSE: Checking if the parameter 'Verbose' is in desired state. (SRS0401)
VERBOSE: Checking if the parameter 'ReportServiceInstanceName' is in desired state. (SRS0401)
VERBOSE: The parameter 'ReportServiceInstanceName' was found to be the correct desired state. Expected: 'PBIRS',        Actual 'PBIRS'. (SRS0403)

Anyway, just some thoughts which may be helpful.

Minor typos in unit test template

When copying over the unit test template from DscResources there were a few minor typos that was forgotten to change (they are changed in the other practical unit test example).

Should we add Class resource examples to template

As per PowerShell/DscResources#467 I can imagine that's a common question that could be clarified here.

1. Do we allow/encourage Class Based resources?
2. Do we have the tooling to do so?
3. If so, shall we provide an example and associated documentation?

Opening the discussion...

Add *.exe as binary to .gitattributes in Template

This is to ensure Git knows to treat *.exe files as binaries:

* text eol=crlf
*.exe binary

Update indentation style in settings.json (VS Code formatting)

We should add this to the VSCode settings.json

"powershell.codeFormatting.pipelineIndentationStyle": "IncreaseIndentationAfterEveryPipeline"

Or

"powershell.codeFormatting.pipelineIndentationStyle": "IncreaseIndentationForFirstPipeline"

The default is no indentation.