-
Notifications
You must be signed in to change notification settings - Fork 224
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Undefined DSC resource 'xSQLServerSetup' when compiling in Azure Automation #716
Comments
This is the same issue as #713 i think? |
I'm not sure but might be connected somehow. |
@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. |
I think I have already posted it?
|
@johlju, now I have published in gist: |
@shurick81 Sorry man, I thought it was gonna be a ARM template or something 😉 Let me try compiling the same configuration. |
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.
|
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.
|
Any updates on this? |
@ld0614 Thanks for finding that and reporting it here! Updated the workarounds with that information. Thank you! |
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). 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. |
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. |
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. |
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). |
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. |
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. @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. |
I'm suffering from the same problem so just adding feedback to get this fixed. |
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? |
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. |
Closing this issue since SqlServerDsc v.10.0.0.0 was released to PowerShell Gallery that solves this. |
Details of the scenario you tried and the problem that is occurring:
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?
The text was updated successfully, but these errors were encountered: