OpenSource the Pull Server
Advances to the current PullServer are, quite frankly, slow and moving in a direction questionable to most MVPs. Microsoft should follow their own lead they took with the DSC modules: opensource it and place it on GitHub so that the community can invest in making a tool that we'd actually like to use.
Example of features still missing that everyone wants:
1. certificate management (use self-signed or pki)
2. web interface for compliance reporting
Example of features added that are questionable/actually bad ideas:
1. partial configurations (multiple pull server sources, mofs, and reports all being managed by the node? who thought this was a good idea when we could do this with composite configurations more elegantly?)
2. specific LCMConfiguration class (why should I have to now maintain two configuration files when 1 used to be just fine? Is it so i can use a feature #1?)
The pullserver is a critical component when it comes to the success of DSC but it's evolving too slowly. Open it up and let the few who are dedicated to DSC succeeding develop an ecosystem that will allow that to happen.
Justin King
shared this idea
Justin,
We totally understand that a robust Pull server / central management solution is something that is critical to your success with DSC. We have invested quite heavily in Azure Automation DSC (AA DSC) to fill many of these needs. With that said, I would be very interested to understand if the AA DSC solution does not work for you (and other customers) and why? Vote and comment if this is important to you.
Also interesting feedback on our ‘bad ideas’. Thanks!
MarkG
14 comments
-
Didier
commented
What about air-gap environment without connectivity to Azure?
We need feature like certificate management -
Henri
commented
The technical issue for not adopting AA DSC is that the DSC client does not support a proxy server.
There is another Uservote regarding this already. -
Christian Stückrath
commented
I understand that your credo is "cloud first" at the moment, but with CLOUD Act in place, it has become even more difficult to use any cloud resources in an (European) enterprise environment.
The pull server in its current state is ridiculously complicated to use, and you have a well crafted tool ready (Honolulu/WAC) for giving it a descent front end interface. -
Ryan Bartram
commented
The protocol is public. Which means anyone can build their own PullServer. In fact their is already an OpenSource project https://duckduckgo.com/l/?kh=-1&uddg=https%3A%2F%2Fgithub.com%2Fpowershellorg%2Ftug that provide exactly that functionality
-
Felix Leven
commented
I would also prefer a DSCPullServer running as a docker container. This would make setting up tests a lot easier.
-
Jeromy Hensley
commented
Seems like Project Honolulu would serve as a good component for DSC reporting and interacting with the pull server for On-Prem.
-
Sylvain Martel
commented
Azure is not a solution for our environment. Not even close. So on-premise pull server development is a must. If MS is already starting to stop development of on-premise solution if should clearly state it so that we stop investing in MS products when cloud solutions is not something possible.
-
J0F3
commented
It is essential that the on-premises pull server is not letting behind. Azure Automation is not always an option as many other already wrote here.
The current state of the dsc pull server in WMF 5.1 is unfortunetaley quite bad.
In my opinion there are three thing which should be fixed urgently:
1. Reproting Server sould get a UI with the node status or at least a GET method to get the status from all nodes
2. Change database to something which can made highly availabe (e.g. SQL). So not a wohle enverionment "depends" on one single pull server
3. Bring the encryption logic from Azure Automation DSC which encrypts the whole MOF file, without manually certificate creation and exchange, into the on-premises pull server (the current solution for credential encryption is in bigger environments not practicable) -
Stefan Werner
commented
This... "4. Finally, there's the idea that AA DSC should even be in the discussion. This is about WMF5, PowerShell ... a fundamental cornerstone of the new Windows designed for a Dev-Ops world. This shouldn't be an extra add-on service. This should be part of the new windows, just like we can expect a functioning WSUS or PKI service."
-
gaelcolas
commented
I concur with the others, AA DSC is not possible for many companies and their customers (i.e. here in Europe), whether for regulation, security reasons, or because they are not Azure customer.
Whether it's on Prem, or on other cloud AA DSC is not always an option. -
Luigi Grilli
commented
I totally agree with Justin and Sebastian.
AA DSC doesn't work for us because our machines are not connected to the internet for security reasons.
There are also bugs in the v2 pull server and the feedback I received on that has been poor. Github projects (in particular the ones from Microsoft) attract more people and issues receive more attention and comments.
Also the webapi is not documented and some webapi calls has been removed from v1 and there is no way to tell what is currently working.
To be more precise, what should be opensourced in my opinion should be the entire content of the PSDesiredStateConfiguration module, in particular the .net dlls. -
Sebastian N.
commented
I'm in the same boat as Justin. Azure is not an option for us (for legal reasons) so the only other option is to use the WMF5 v2 Pull Server.
I'd have written a nice and responsive Bootstrap/Angularjs front-end for it already if we had an DSC report server API documentation. Unfortunately that is not the case and could also be handled by the community just as Justin suggested.
We're in the middle of building a PKI with DSC and steps for proper DSC certificate managament are missing from the DSC documentation (which is a topic that the MS can discuss with the community in my opinion).
In general the release of the DSC Pull Server has been a bumpy ride. The worst thing is not having the server use certificates at all in its default configuration (https and credential encryption in mofs). That's a big no-no and should be fixed asap. The internet is full with blog posts recommending to set PSDscAllowPlainTextPassword = $true.
-
Separate post on "bad ideas".
This may be possible frustration talking, but from what I can tell, the idea that a node would gather multiple MOFs from multiple sources is asking for trouble. Basically it makes test automation much more difficult, and practically relies on the various coders for the various MOFs to be in tight coordination so nothing "collides" when it hits the node .... because the node does the final compilation of the various Mofs... which seems like it's the _last_ place you should be doing that kind of testing.
It also makes certificate management much more difficult.
In contrast, I could very easily, instead of making multiple partial configurations, make a composite configuration, with multiple configuration resources in it's place. This gives me all the advantages of a partial configuration (separate files to edit/checkin/manage), but the final mof generation is complete so I get the results of any possible conflicts BEFORE I upload it to the pull server. I honestly don't see why I'd ever want to compile things on node when I can pre-compile and see problems up front before it ever gets there.
So in summary: it introduces lots of potential problems with the final config being handled at the node, adds complexity with multiple configuration points, plus complicates and multiplies the certificate story, and for what advantage? I'm guessing it makes it more compatible with some 3rd party product .... because otherwise it's a solution looking for a problem.
-
It's a fair question on AA DSC, but there are a lot of reasons it may not fit.
1. AA charges by runtime, even if a hyrbid worker is on-premise to reduce the amount of direct calls made into Azure form on-premise resources. In a proper Dev-Ops model with constant code updates and modifications, this makes a lot of clients nervous about hosting code changes in cloud as there's is basically the possibility of 100% runtime and charge.
2. Some modern AD Forest security models make internet based update engines impracticable/impossible, for example admin forests with strict security monitoring/regulation requirements.
3. AA DSC can't rotate certificates yet. When your machine cert is about to expire you have to manually renew it. On-premise, I was able to solve this in a weekend with a single custom function and DSC resource which I then uploaded to the powershellgallery. If the pullserver were open source I could fork and propose to merge this functionality. for now, download dschelperfunctions and clcmcertificatemanager... dont know if it works in AA DSC honestly.
4. Finally, there's the idea that AA DSC should even be in the discussion. This is about WMF5, PowerShell ... a fundamental cornerstone of the new Windows designed for a Dev-Ops world. This shouldn't be an extra add-on service. This should be part of the new windows, just like we can expect a functioning WSUS or PKI service.