Just to clarify things a bit:
While TUG’s implementation of the MS-DSCPM protocol is written in C#, the provider model allows you to implement the ‘processing’ (handlers) in C#, PowerShell, or other tech with minimal C#. That does not mean you won’t have to write any C# for a production-ready solution that fits your need, but it would hopefully be minimal. (And iirc there’s an example provider for PS)
The AA DSC issue you mention is not a Pull server bug but a WMF v5.0 LCM bug. That bug in particular had very obvious consequences ($$$) because it was using metered cloud resources. In an on-prem infrastructure, the cost is hidden but not inexistent (i.e. over-provision, reduced vm density…). So you’ll need monitoring, alerts and notification anyway. LCM in v5.1 I think has problems such as not cleaning up the status despite setting the ‘StatusRetentionTimeInDays’ settings (so you may be using loads of GBs over time).
An element of your approach is key, and should be emphasised: “I need to focus on getting this going for now”. This is very true and before you can benefit of all the bells and whistles, you need to start transforming somewhere. There’s much more to it than just installing a tool, and the design of a pipeline that works for your business context takes more time and effort than the technology part. In the current transformation effort I’m working on, we’re actually going a long way with a simple SMB-based pull server (we already had a way to pull DSC Configuration Status and logs for reporting).
We’ll certainly look at investing into TUG when it’s right for us, as that’s probably the most flexible implementation that suits our context.
As a first step to get started with a PULL server I’d recommend the following process:
- If you’ve got a very simple infrastructure, and you’d rather not deal with adding a web server to try it out, consider a SMB pull server (but you don’t get the Report server and you need to use ConfigurationID)
- if SMB does not cut it, start with the default Pull Server or the AA DSC one. Keep an eye on their limitations and experiment (i.e. SQL backend) but don’t try to optimise prematurely.
- I’ve heard that Ben Gelens is working on an interesting proof of concept for his PSConfEU talk: “The DSC Pull Server is dead, long live the DSC Pull Server - by Ben Gelens”. Watch this space, and bear in mind it’s always changing.
- Longer term, as you have a better understanding of your needs, you might want to invest in a more custom solution, based on TUG, TRAEK or other solution…
Also remember that DSC is not a fully-fledged Solution but a platform. AADSC is MSFT’s solution, and the main area of investment in the Configuration Management Solution space, with a strong opinion on Multi-Cloud SaaS Solution. Other CM solutions are Chef, Puppet, Ansible, Salt and so on… They can all leverage the DSC platform, and each their own characteristics, and are all relevant to some contexts, don’t discard them too early, and experiment if you can (Ben has some nice resources here)!
Good luck, and I hope you’ll share your journey!