Undefined DSC resource 'xSQLServerSetup' when compiling in Azure Automation

[shurick81]

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

1. Creating new automation resource in Azure
2. Adding xSQLServer module
3. Uploading my test configuration
4. Trying to compile it

I receive this error:
Exception calling "NewScriptBlock" with "1" argument(s): "At line:9 char:9 + xSQLServerSetup SQLSetup + ~~~~~~~~~~~~~~~ Undefined DSC resource 'xSQLServerSetup'. Use Import-DSCResource to import the resource." (At line:9 char:9 + xSQLServerSetup SQLSetup + ~~~~~~~~~~~~~~~ Undefined DSC resource 'xSQLServerSetup'. Use Import-DSCResource to import the resource.)

The DSC configuration that is using the resource (as detailed as possible):
Configuration SharePointDevelopmentEnvironmentTest2
{
Import-DSCResource -ModuleName xSQLServer
Node "lab3sp1"
{
xSQLServerSetup SQLSetup
{
InstanceName = "MSSQLServer"
SourcePath = "C:\Install\SQL 2016"
Features = "SQLENGINE"
InstallSharedDir = "C:\Program Files\Microsoft SQL Server"
SQLSysAdminAccounts = "username"
DependsOn = "[Group]AdminGroup"
}
}
}
Version of the Operating System, SQL Server and PowerShell the DSC Target Node is running:
Azure Automation
PowerShell version must be 5.0 I think
Not running yet, just compiling
What module (SqlServer or SQLPS) and which version of the module the DSC Target Node is running:
xSQLServer 8.0.0.0
Version of the DSC module you're using, or 'dev' if you're using current dev branch:
Azure?

[johlju]

This is the same issue as #713 i think?

[shurick81]

I'm not sure but might be connected somehow.
I made sure that all 28 resource are imported into automation account. However I got this error as I described.

[johlju]

@shurick81 Could you post your test configuration here or in a Gist? I need to try this out for my self. if it more than one file, you could zip them, and submit the zip file here.
Please remove any sensitive information.

[shurick81]

I think I have already posted it?

Configuration SharePointDevelopmentEnvironmentTest2
{
    Import-DSCResource -ModuleName xSQLServer
    
    Node "lab3sp1"
    {
        xSQLServerSetup SQLSetup
        {
             InstanceName = "MSSQLServer"
             SourcePath = "C:\Install\SQL 2016"
             Features = "SQLENGINE"
             InstallSharedDir = "C:\Program Files\Microsoft SQL Server"
             SQLSysAdminAccounts = "username"
             DependsOn = "[Group]AdminGroup"
        }
    }
}

[shurick81]

@johlju, now I have published in gist:
https://gist.github.com/shurick81/ecc01558102fc9587edda9ce358f16cd

[johlju]

@shurick81 Sorry man, I thought it was gonna be a ARM template or something 😉 Let me try compiling the same configuration.
But it looks very similar to issue #713 - maybe even if you manged to get xSQLServerSetup to show, there is still a problem. But just guessing.

[johlju]

I have reproduced this error. No xSQLServer resources can compile in Azure Automation with version 8.0.0.0.

This problem is due to long paths. Some files in the module exceed 120 chars so the compilation fail with this error message.

Workarounds until this is fixed.

• Deploy earlier version 7.1.0.0 of the module.
• If you want to use v8.0.0.0 or higher, then compile the configuration locally first and import the .mof directly into Azure Automation either from portal or PowerShell.
• If you want to use v8.0.0.0, and don't need resource xSQLServerAlwaysOnAvailabilityGroupDatabaseMembership
  1. Download a local copy of xSQLServer module Save-Module -Name xSQLServer -Path C:\Temp.
  2. Remove the version folder ('8.0.0.0') moving the underlaying folders to the root module folder. See Azure Automation DSC Custom Modules Fail when the ZIP file has a Version folder for more information.
  3. Delete resource xSQLServerAlwaysOnAvailabilityGroupDatabaseMembership.
  4. Delete the Examples folder.
  5. Delete the Tests folder.
  6. Compress the xSQLServer folder to a zip archive
  7. Add the zip archive to Modules in Azure Automation.
• If you want to use v8.0.0.0, and need resource xSQLServerAlwaysOnAvailabilityGroupDatabaseMembership
  1. Download a local copy of xSQLServer module Save-Module -Name xSQLServer -Path C:\Temp.
  2. Remove the version folder ('8.0.0.0') moving the underlaying folders to the root module folder. See Azure Automation DSC Custom Modules Fail when the ZIP file has a Version folder for more information.
  3. Rename the resource MSFT_xSQLServerAlwaysOnAvailabilityGroupDatabaseMembership to MSFT_xSQLServerAGDatabaseMembership (folder and all files, and all references to 'MSFT_xSQLServerAlwaysOnAvailabilityGroupDatabaseMembership' in all files). make sure to leave the friendly name as 'xSQLServerAlwaysOnAvailabilityGroupDatabaseMembership' in the schema.mof.
  4. Delete the Examples folder.
  5. Delete the Tests folder.
  6. Compress the xSQLServer folder to a zip archive
  7. Add the zip archive to Modules in Azure Automation.

[johlju]

Azure Automation Team is tracking the long path issue, but it's probably gonna be a while before we see a resolution. With this, I don't want to do any changes to the resource module, but instead await what their resolution is first. So I will put this issue "on hold" for now.

They suggest this workaround as well.

• "As for workaround right now, customer can compile the configuration locally first and import the Mof directly into Azure Automation either from portal or PowerShell. The xSQLServer resource can still be imported into Azure Automation module asset so it should be available for pulling."

[ChrisRichner]

Any updates on this?

[ld0614]

@johlju Thanks for the workarounds. It might be worth mentioning deleting the Tests folder in your instructions as I found that that some of those also tripped the 260 limit.

Edit: I discovered that keeping the version folder in the ZIP file can break the configuration as described here

[johlju]

@ld0614 Thanks for finding that and reporting it here! Updated the workarounds with that information. Thank you!

[Matticusau]

I came across this last week as it was breaking a Composite Resource I was trying to compile (that took some digging to find this as the cause).
It doesn't affect all resources, so it's a challenging one.

I just wanted to confirm that the work around of compiling locally and manually uploading the MOF worked in my case. I think that is a more appropriate method than creating a custom copy of the module, but situational I guess.

[GamerLivingWill]

I'm actually keeping an eye on this as it's affecting me as well. Compiling and uploading MOFs doesn't work for me as sometimes for customers, I'm actually compiling MOFs at runtime for the environment build. This is actually super inconvenient in either case.

[shurick81]

By the way, just for information, I have never experienced this issue with Set-AzureRmVmDscExtension command. It compiles and applies SQL resources like a charm.

[johlju]

I talked with @mgreenegit at Ignite yesterday. When the problem with long path is resolved in Azure Automation this module should work without changing the resources (or any files). There is currently no timeline when this gets resolved, but knowing that they know what the problem is, feels like a good step forward.

In light of that, I remove the workarounds for changing this resource and the workaround, until this issue is resolved, will be the recommendation from the Azure Automation team (see above).

[ld0614]

Hi @johlju

While compiling locally may work in most contexts I'm grabbing credentials directly out of the automation account at compile time which I believe would either expose the passwords in plane text or render the credentials unreaderble if compiled locally. While I personally think renaming the affected resource is the best option I understand that its probably a lot of work and would be a breaking change. I do think that its important that the existing workarounds are kept documented to allow easy mitigation when compiling locally isn't practical.

[johlju]

The workarounds are still there, I just strike-through them since that will not be the path we should go. If there is any new development in this issue that will set a hard limit, then we can look at renaming resources again. But for now, we should not workaround a bug in Azure Automation.
If it is the consensus of the community to use a new naming standard I'm open for that, but I think that's a different issue.

@ld0614 In your case, you should submit a case to Premier support or any other support channel you have to address that issue. That could also speed up that this gets resolved quicker.

That goes for everyone, if you have this issue, then please submit an issue to any support channel you have to get this resolved.

I guess that the PowerShell team want this fixed, but there are priorities out of there control, and probably a long chain of tasks that need to happen to get a change into Azure.

[mattpound808]

I'm suffering from the same problem so just adding feedback to get this fixed.

[mgreenegit]

Version 9+ of SqlServerDsc resolve this issue. While you will not see SqlSetup listed in the extracted activities for the module (yet), configurations that use the resource will now compile successfully. I believe we can mark the issue as resolved?

[johlju]

I found an issue compiling the resources. We still have two files over the hard-limit of 129 chars. Please see issue #934. I'm working on this now.

Also please note that it will be version 10+ that will have this issue fix. The current Dev branch will be released as SqlServerDsc once all major breaking changes have been merged.

[johlju]

Closing this issue since SqlServerDsc v.10.0.0.0 was released to PowerShell Gallery that solves this.