Welcome to the Inedo Forums! Check out the Forums Guide for help getting started.
If you are experiencing any issues with the forum software, please visit the Contact Form on our website and let us know!
Otter role issue after upgrading to 22.0.2
-
Hello
After upgrading from version 3.0.24 to 22.0.2, we still have some problems.
We have a role called SetupFirefoxexe2, with the following code:call SetupFirefoxExe2();
This role depends on the role DSCR_Application with the following code:
call DSCR_Application();
The code of the otter module SetupFirefoxExe2 is:
module SetupFirefoxExe2 { Ensure-DSCResource ( Name: cApplication, Module: DSCR_Application, ConfigurationKey: InstallerPath, Properties: %( Name: 'Mozilla Firefox (x64 es-ES)', InstallerPath: C:\Tmp\firefox.exe, Arguments: '-ms -ma' ) ); } and code of the module Otter DSCR_Application is: module DSCR_Application { Ensure-PsModule ( Module: DSCR_Application ); }
When we associate the role setupFirefoxexe2 to a server gives us unknow status.
If we do "Remediate Drift" it gives us the following error:
On the server the Firefox is installed and the state of the server from the console show error.
Thanks
-
Hi @jramon-ortega_2700 ,
Another strange error! I chatted with the engineers here, and can summarize this a bit.
In Otter 2022, we went to .NET6, which has those annoying bugs with modules in a "hosted powershell" environment. So, we switched to using something called "local remoting" - which basically allows us to communicate with the PowerShell process using PowerShell's remoting functionality. So basically, PowerShell is now executing using "PSRemoting" - so it kind of makes sense that a remoting error is happening.
After researching the "serialized xml is nested to deeply" message, this seems to be a powershell bug -- it's an error displaying an error message over remoting, maybe. It happens with PSRemoting and DSC it seems, but who knows
Are you able to try to run this via PSRemoting, to see if you can reproduce the error? Any errors logged in the event log.
A few posts mentioned that this has something to do with security?
If you search "serialized xml is nested too deeply" you should find a handful of things to try... mind giving those a shot, and see if it makes any difference?
Thanks,
Alana
-
Hello
We will look for information about "serialized xml is nested too deeply", if we progress we communicate it to you,
as this can help other users with the same problem.To run the script through PSRemoting, at the moment we do not know how to do it, since we had done DSC tests with the commands
typical powershell start-DSCConfiguration and set-DSCLocalConfigurationManager, but we believe it does not involve PSRemoting.Thanks
-
I'm not a PowerShell expert myself, but I looked at the code for the operation.
We use the
Invoke-DscResource
CmdLet to run the configuration...Not sure if that helps, just wanted to point you in the rightd irection
Cheers,
Alana
-
Hello
Thanks to your help we were able to execute the script, I explain:
1.- We run the script locallyInvoke-DscResource -Name cApplication -ModuleName DSCR_Application -Method set -Property @{ Name="Mozilla Firefox (x64 es-ES)"; InstallerPath="C:\Tmp\firefox.exe"; Arguments="-ms -ma" }
works properly !!!
2.- We run the script remotelly
$cred = Get-Credential enter-pssession -ComputerName PC670 -credential $cred Invoke-DscResource -Name cApplication -ModuleName DSCR_Application -Method set -Property @{ Name="Mozilla Firefox (x64 es-ES)"; InstallerPath="C:\Tmp\firefox.exe"; Arguments="-ms -ma" }
works properly !!!
3.- We run the script remotelly
Invoke-Command -ComputerName PC670 -ScriptBlock { Invoke-DscResource -Name cApplication -ModuleName DSCR_Application -Method set -Property @{ Name="Mozilla Firefox (x64 es-ES)"; InstallerPath="C:\Tmp\firefox.exe"; Arguments="-ms -ma" } }
It has the same behavior as when running in otter, that is, the firefox is installed but in the end it generates the error "Serialized XML is nested too deeply"
We have tried different things to fix this error but it always returns the same error
- We have executed with powershell 7
- We have configured wsman to allow delegating credentials
- We have tried to run the script on a PC that is not in our domain
we continue to search, but you do not think it could be a Powershell error that Microsoft has not yet solved?
Thanks
-
@jramon-ortega_2700 thanks so much for testing this, and verifying the issue is occurring outside of Otter. This is what we were afraid of, but it shows where the problem is.
This is definitely a bug/issue with PowerShell, and likely the way that the DSCR_Application module is designed? We don't really know.
I doubt Microsoft will fix this... but it doesn't hurt to ask. You have a very good reproduction case now.
It might be possible for us to work-around this, but unfortunately it's not a trivial matter. We'd need to find an alternative to "local remoting" to handle process communication.
What would be good to know, how widespread is this?
Is it only this
DSCR_Application
resource? Maybe the creator of DSCR_Application can work-around the issue?Using Chocolatey Packages, I guess, could be a good replacement? Maybe there's a way to do it with your own Ensure-based PowerShell script instead of a DSC resource?
We like the ability to use DSC resources, but if it's only one or two, then maybe it's not worth the effort to work-around?
-
Hello
First of all thank you very much for the great work you do solving our doubts and guiding us.
At the moment we are in the testing stage and we do not have many scripts, we have looked at the examples we have with DSC that are:
- Registry of the DSC PSDesiredStateConfiguration to create a value in registry.
- xRobocopy of the DSC xRobocopy to syncronize a folder structure
- Searching the internet we found in a powershell forum an example of a man who used the Group of the DSC PSDscResources to create a Group users.
In all cases it generates the same error, so we think that this error occurs in all DSCs, but we do not know.
In our case we think that we can adapt our scripts using for example . AHEXECMODE, but we think that being able to use DSC simplifies and speeds up programming a lot.
Thanks a lot
-
Thanks so much for verifying all of this. I talked to the team about this, and wanted to share an update, and further the conversation. We'd love to get your opinion.
Is PowerShell DSC dying/dead?
This is very clearly a "pretty big bug" that Microsoft hasn't fixed after very many years, which is surprising to see. It doesn't seem to be reported or discussed much.
At this point, we're really unclear on the future of PowerShell DSC. From our research, it never got widespread usage in the community because of the complexity of Pull servers, MOF, etc. Ultimately, most Windows admins just chose to use regular PowerShell scripts to set-up servers because it's simpler to understand and use.
Microsoft seems to have demoted it to a "community" project as well. It looks like they have some effort they plan to invest in it (based on a 2021 blog post), but there hasn't been recent updates or activity.
It seems that the PowerShell team is really focused on PowerShell Core now, and DSC isn't so much a fit? Maybe they will fix the remoting bug in Core? But who knows
PowerShell DSC Alternatives?
There are several alternatives:
- Otter's native operations, like Ensure-RegistryKey and Transfer-Files; these are more performant than the DSC resources and have a UI that make them easier to use
- PowerShell Scripts (using AHEXECMODE, etc)
- Executing powershell scripts using powershell.exe; this isn't great, because we can't easily parse output or read variables, etc.
How can Inedo help/invest in automation?
Ultimately, you (and our users) want to use automation to solve problems, and PowerShell DSC is just one tool to get there. It's convenient because there's many resources.
We can invest in working-around this bug, but it's not trivial. In the same time, we could improve a lot of Otter operations and write/document a lot of PowerShell scripts.
from a marketing/user standpoint, we don't know how many people are using PowerShell DSC , and if they would even find Otter to add value.
So getting your ideas/opinoins would be appreciated :)
Cheers,
Alana
-
Hello
We are not experts in Powershell and we discovered DSC at the same time and thanks to Otter and we thought it was great and that they integrated perfectly. Knowing that DSC may not have continuity we will be attentive to the news, especially with Powershell Core.
Thanks to the alternatives you have given us to DSC, we will modify our scripts and continue testing and studying Otter, because it seems a very good tool for us.
Thank you and greetings