Import-AzureRmAutomationDscConfiguration: File name shouldn't be required to match the DSC Configuration name

[pcgeek86]

When you use the Import-AzureRmAutomationDscConfiguration command to import a PowerShell script file into an Azure Automation Account, the file name must match the DSC configuration name. If the DSC Configuration name, and the script file name that contains it, do not match, then you receive the exception below.

This is inconsistent with the Azure Portal experience, where no such naming requirement exists.

Import-AzureRmAutomationDscConfiguration : BadRequest: The configuration name in the script must match the configuration name.
At C:\Users\TrevorSullivan\Documents\Import DSC Configuration.ps1:26 char:1
+ Import-AzureRmAutomationDscConfiguration @DscConfiguration;
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : CloseError: (:) [Import-AzureRmAutomationDscConfiguration], CloudException
    + FullyQualifiedErrorId : Microsoft.Azure.Commands.Automation.Cmdlet.ImportAzureAutomationDscConfiguration

Cheers,
Trevor Sullivan
Microsoft MVP: PowerShell
http://trevorsullivan.net
http://twitter.com/pcgeek86

[markcowl]

@pcgeek86 This seems like an unnecessary restriction. Adding in the automation team.

[pcgeek86]

@markcowl Thanks Mark! This should be a fairly straightforward fix, and might even result in removing some code, instead of adding code. :)

[jodoglevy]

This is by design. Same as on the runbook side.

[pcgeek86]

@jodoglevy If it's by design, then the inconsistency with the Portal experience should be rectified. What was the reasoning behind the current PowerShell design?

[jodoglevy]

I did not know we allowed this from the portal. Given we do, maybe we should match in the cmdlets, yes. But I would say its a best practice to name your PSWF runbook / DSC Configuration file with the same name as the PSWF runbook / DSC Configuration it contains. Otherwise it will get confusing when you have many PSWF runbooks / DSC Configs in files, as to what each file contains. You shouldn't need to open a runbook / config file up to know which runbooks / config is in the file.

[pcgeek86]

You shouldn't need to open a runbook / config file up to know which runbooks / config is in the file.

That's a nice thought, but probably better for the user to make that decision, or at least be consistent between interfaces and document the requirement in detail. If you support it via the Portal, then why not via automation interfaces?

NOTE: I just ran into this bug again.

[jodoglevy]

In addition to my above reason, script runbooks don’t have a name declaration within the file like workflows / configurations do. The file name is used as the script name. I’d think we’d want to be consistent across all runbook / config types as to where the item name comes from (to be the file name).

Also, referencing a child script runbook from a runbook inline uses the file name (just like scripts locally):
.\myrunbook.ps1

[4c74356b41]

Am I losing my mind?
:\Windows\system32> Import-AzureRmAutomationDscConfiguration -SourcePath C:\whatever\setup-sql-2016.ps1
mport-AzureRmAutomationDscConfiguration : BadRequest: The configuration name in the script must match the configuration name.

In the file I have "Configuration setup-sql-2016"
I've also tried with name without hyphens, so setupsql2016.ps1 and "Configuration setupsql2016"

Okay, so this makes a bit more sense, but still doesn't give me all the answers:
"The name can only contain letters,numbers and underscores. The name must start with a letter, and it must end with a letter or number."

setupsql2016 - satisfies all the conditions and today it worked, but 2 days ago, it didn't. huh?

[DdenBraver]

This restriction still seems to be in place.
Is there any update on this? It feels a bit strange, that the ps1 name and the configuration name should be the same.

[GoEddie]

I got this, please remove the restriction - I am confident that I am capable of managing a set of files :)

[raandree]

Just ran into this as well. Are there still plans to remove this restriction?

[lfshr]

@jodoglevy Why is this designed this way? I do not recall any documentation stating that this was best practice, nor do I believe it is best practice as Azure really doesn't care about the file names after import.