Hi Eric, thanks for pitching in,
Can you re-confirm that you need a ReportServerWeb block in the LCM config Script ?
Why would there be a necessity to have that as an option ? Who wouldnt want reporting built in from the first setup of the pull server and LCM ? A better usage would be to always have the LCM report to the configuration server, unless a block was specifically used. You obviouslt have to add the block if you want to send it to a different URI then the one hosting your Pull Server.
The online doc do state:
“By default, the client node gets required resources from and reports status to the configuration pull server.”
What you may consider “duplicate”, i consider “going the extra mile”. Im not a fan of spoon-feeding but i would rather see a Complete working example from the get go. without needing to go deep dive into the documentation to find that missing bit. Something i can take as is with minor modification and “Make it So”
I think the “single server” point isnt really the problem. If you understand that the separation of mini-roles is mostly for Push mode, and extremely rare occasions of Push mode (like perhaps huge amount of nodes cross domain scenario), the the fact the ReportServer is a simple Pull Server, is well documented imho.
" The server to which the node sends reports must be set up as a web pull server (you cannot send reports to an SMB share)."
The fact V4 had a component within the script that dealt with the ComplianceServer, and now its been moved outside to its own configuration script, might be also one of the reason that made Jeremy post his original question.
The problem as i see it is the flow on the documentation. and the contiued usage of v4 sample in the xPSDesiredStateConfigration resource or lack of a v5 one so the v4 is there for backward compatibility. Or allowing the usage of IsComplianceServer toggle in a v5 script like an issue Justin King found (again due to following “bad” examples that werent updated)
I can understand Jermeys’ pov as the first encounter with DSC is actually the Pull/Push Server and then the LCM. I looked at the v5 sample, and then on the sample on setting LCM with RegistrationKeys and the one on using the DSC report server and i see the “ServerURL= ‘http://CONTOSO-REPORT:8080/PSDSCReportServer.svc’” in it and i go “hmm where did that came from”. I think Jeremy as much as i was at the start were pondering if we missed something along the way,
So flow is bit awkward, consistency is also important… If you compare the “how to use the DSC Report Server” and compate it to “Setting up a pull client using configuration names” section at the bottom. And lack of v5 examples in a more complete way
Be Strict in relying in the example, that for v5, people should NOT use the old PSDSCComplianceServer block.
As for documenting the Rest API, dont think its not a bad idea. The current online docs have a sufficient info on how to use it, but not all people will feel comfortable with it, although they should, if they work with this technology.
My 0.5 cent, for now