ReportServer or ComplianceServer

DSC
1

According to the documentation here:

https://msdn.microsoft.com/en-us/powershell/dsc/reportserver

Powershell 5 DSC uses a report server instead of the PS4 compliance server. But it seems like that is the only place it is ever mentioned. In the xDSCWebService resource there is only a compliance server and no mention of the report server, and in fact in C:\Windows\System32\WindowsPowerShell\v1.0\Modules\PSDesiredStateConfiguration\PullServer there isn’t a PSDSCReportServer.svc at all, just PSDSCComplianceServer files.

Is this the case of the documentation referring to some new feature that isn’t out yet, or is there something I’m missing?

2

It’s just a new name for the same feature (though I believe it did receive some enhancements in PSv5.)

3

And it’s still a fairly immature feature, at that. There’s no tooling around it, so doing any kind of node status query is very much a manual thing. And it isn’t well-documented at this point.

4

Hi,

This is based on my understanding after going on the scripts and samples I did find. I did not yet test it.

It might be a new name for a the same feature as Dave suggested, but I think the way its configured has definitely changed.

In v4 the compliance server was another website that had to be installed on the SAME node as the pull server, as it queried the devices database that is installed with dsc service. To differentiate it from a normal pull server, there was the IsComplianceServer key.But there was no settings in the node LCM, so this second website was mearly a way for us to query node state and history (there are powershell team blogs about how to do so).

If you are moving to a v5 pull server, do not use the ComplianceServer as in the old dsc samples that are still present in xPSDesiredStateConfiguration module as they weren’t updated.

There is even an issue that Justin spotted that if you use RegistrationKey method and you try to use the IsComplianceServer, it will lock to only using GUIDs.

In v5, you have the option to split the pull server into three. One pull server for the actual pulling of the configuration (this is where the mofs and checksums go), one pull server just for pulling the resources (probably a result of a request MS got from users, my hunch), and one “Pull server” just for reporting. You can see in the examples how you use a RegistrationKey for each.

If you split the roles into different locations, you basically will create three distinct device databases that your node will register itself to and that’s why you now have a way to tell LCM where to get what.

On top of that two new parameters were added to the LCM, called LCMState and LCMStateDetail that you can query to get the state online, but obviously doesnt hold any history.

As Don noted wisely, although dsc has been up for sometime the documentation lacks, but the three articles published by the PowerShell team on their blog gets you started on using invoke-webrequest to use the REST api and extract and parse the data.

Microsoft has always been good at giving opportunities for third party tools to complement theirs, I just hoped they would put some more effort into documenting the basics. Then again, that’s an opportunity on its own to go to the PowerShell dsc docs repository on github and share and make it better for others :wink:

5

So even on a 2016 tp4 server, after installing DSC-Service, there is no PSDSCReportServer.svc file in c:\windows\system32\WindowsPowershell\v1.0\modules\PSDesiredStateConfiguration\PullServer folder. But there is a PSDSCComplianceServer.svc and mof and xml, etc. The documentation can say don’t use a compliance server all it wants, but if they don’t provide the bits I don’t see how a report server is supposed to work.

6

Hi Jeremy,

Hopefully my newer post about the ReportServer made today on hte forum will answer some of your questions.

Im sure it will open new ones as thats how we all learn :slight_smile:

7

Great compilation of info, definitely clears up the confusion around how it is supposed to work. However, I still maintain my position that the new Report Server is a phantom. If you run that pull server setup, or at least when I run it, I get a website named PSDSCReportServer in IIS, but it’s still using all the PSDSCPullServer files, the svc, the mof, etc. In fact if you look at the code in xPSDesiredStateConfiguration version 3.7.0.0, the only options are pull server or compliance server. The only thing that actually is set by using the EndpointName parameter is the name of the website.

By the way, how awesome is it that we can just read all the code for these resources instead of wondering how they work? This must be how programmers feel all the time. :slight_smile:

8

Because the report server IS a pull server, It uses PSDSCPullServer files. No reason of having a different set of files like in the compliance server case. The good part is that because you can name the endpoint as you wish the name of the svc file will be the name of the endpoint. No phantoms here, just not a great deal of explaining or reason relay in by MS in the documentation.

The good part about seeing the code is finding the bugs and helping the community fix them via Github. The bad part, dsc still works with a dll and isn’t opened source so some of the internal work on mostly the LCM isn’t always visible and requires some detective work.

9

Hi. Eric Slesar from Microsoft here. I own DSC documentation.

I’d like to improve the documentation for the report server feature. What I’m hearing is that people would like more explicit explanation that the report server is just a pull server. Is there anything else that you’d like to see? What is missing?

Would it be helpful if the pull service was documented as a REST API?

Arie, I’ve looked at your post in the other thread, and I’d like to explain why I didn’t cover some of what you did there. I don’t want to duplicate content, and setting up a pull server is already covered. I wanted this topic to focus on querying the report server. Looking at the topic in light of this thread, I’m thinking it definitely needs to state explicitly that the report server is the same as a normal pull server, just used for a different purpose.

As far as the difference between the v4 and v5 server, and the reasoning behind the change, the main thing is that pull service can now be split three ways–config, resource, and report. Looking at the topic, that isn’t made clear, and I will add that.

I’m sure folks here know that the documentation is open-sourced on GitHub:

Feel free to open issues there (I came to this thread via an issue that Arie responded to).

thanks,
Eric

10

Hi Eric, yeah since the current documentation focuses on the split-server scenario, it could use some more detail on how to use a single server for both pull and reporting (and resource download too I suppose). Especially since in v4 you had a second site/dscwebservice for the compliance piece.

Also, if the pull server URI is the same for the report server, then I suppose there should be something documented for the reporting code. i.e. if you’re using a single service you use http://pullserver:8080/PSDSCPullServer.svc, if you’re using 2 servers use http://reportserver:8080/PSDSCReportServer.svc.

Oh and in a single server scenario on the client LCM, do you still need a ReportServerWeb configuration block separate from the ConfigurationRepositoryWeb block or is just the single block sufficient?

11

Thank you. This is very helpful.

If you are so inclined, it would be great if you would post this as an issue on the GitHub repo:

If you’d rather, I can post it. Let me know.

Re: your question–yes, you need a ReportServerWeb block in your LCM config. The node won’t send status data to the server if it is absent.

12

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” :slight_smile:

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 :slight_smile:

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. :slight_smile:

My 0.5 cent, for now :slight_smile:

13

issue posted. I suppose an issue needs to be opened up on xPSDesiredStateConfiguration as well, as the xDSCWebservice looks to need some updating as well.

14

xDscWebService has now been updated to ensure it is much easier to setup the pull server. Take a look and please file issues in the github GitHub - dsccommunity/xPSDesiredStateConfiguration: DSC resources for configuring common operating systems features, files and settings.