Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ReportServer #98

Closed
theonlyway opened this issue Mar 28, 2016 · 28 comments
Closed

ReportServer #98

theonlyway opened this issue Mar 28, 2016 · 28 comments

Comments

@theonlyway
Copy link

@theonlyway theonlyway commented Mar 28, 2016

Hi,

I deployed a new V2 Pull server using the example here: https://msdn.microsoft.com/en-us/powershell/dsc/pullserver

I then applied a configuration to a node and attempted to check the report server to see if the node was compliant much like I was able to do while using the compliance server in V1. I've configured the nodes report and pull server to be the same endpoint (Both to PSDSCPullServer.svc) like in the documentation as I don't have a requirement to separate the roles out.

Now according to the documentation here: https://msdn.microsoft.com/en-us/powershell/dsc/reportserver there should be a PSDSCReportServer.svc endpoint but I can't see one created in the PSDSCPullServer pull folder and unlike the compliance server there is no flag to tell it to deploy the report server so I assume it should be deployed by default?

Are you able to advise what I am missing?

@Zuldan

This comment has been minimized.

Copy link

@Zuldan Zuldan commented Mar 29, 2016

@theonlyway, 'PSDSCReportServer.svc' is a typo in the documentation. You're supposed to use 'PSDSCPullServer'. If you want a working example, see here https://gist.github.com/Zuldan/c679bae20de0c2dcf1aa

Note: Only registrationkey Pull/Node servers are able to performing reporting. Reporting for ConfigurationID Pull/Node servers is broken as far as I can tell. See #97

@theonlyway

This comment has been minimized.

Copy link
Author

@theonlyway theonlyway commented Mar 29, 2016

@Zuldan thanks for that your sample works. Unfortunate that a typo on the doco like that creates so much confusion! Do you know if there is anything similar to what the compliance server did where it actually said weather or not the node was compliant? It doesn't appear like it's something the report server returns from the looks of it.

@Zuldan

This comment has been minimized.

Copy link

@Zuldan Zuldan commented Mar 29, 2016

Good question, I'm trying to find out the same thing. I was hoping to use ODataExplorer to discover what information is available in the Report Server OData feed but it appears ODataExplorer is not working with it. I'm hoping Doug Finke can get it going. See dfinke/ODataExplorer#1

@NarineM

This comment has been minimized.

Copy link
Contributor

@NarineM NarineM commented Mar 29, 2016

@Zuldan , @theonlyway
For getting node compliance status in new V2 see the section "Getting report data" in https://msdn.microsoft.com/en-us/powershell/dsc/reportserver. When you view the "Status" field in the reporting data, it should have the value "Success" . That would mean that the node ran the dsc configuration successfully.
As for the 'PSDSCReportServer.svc' typo or not question. If you are using xWebService resource to deploy a pull or reporting endpoint by setting "EndpointName = "PSDSCPullServer"" the resource creates an endpoint with the service document name PSDSCPullServer.svc, but you can change that. This is just an example to show that you can configure two different machines one to serve as a pull endpoint only ( to download configurations from) and the other as a reporting server (server that stores node's configuration run status ) and they can be deployed to have different service documents ( svc name).

@jmcook01

This comment has been minimized.

Copy link

@jmcook01 jmcook01 commented Mar 31, 2016

@NarineM
I'd also like to know if there is further documentation on what's exposed by the web service. I'm able to get status data for individual machines using the AgentID using the examples provided on MSDN but like @Zuldan I'd like to have an overall status report like I could easily generate in previous version. I've opened up the database in Access to look at the tables and I suppose if I wanted to get a little more archaic I could query the DB directly and then iterate through the AgentID's using the webservice but I'd rather just be able to do it all via the webservice. Are there any plans to further document what's available in the webservice? If someone could point me to a method of querying the webserivce for all AgentID's that have registered, I think that would get me pointed in the right direction.

@NarineM

This comment has been minimized.

Copy link
Contributor

@NarineM NarineM commented Mar 31, 2016

@jmcook01
I am planning to post a blog about what is exposed by the web service. For now you can use examples on msdn. For your question about all AgentIDs, WMF 5 does not support get all. You will need to iterate over each agentID to get the data.

@jmcook01

This comment has been minimized.

Copy link

@jmcook01 jmcook01 commented Mar 31, 2016

I'm fine with iterating over each AgentID to get the status data, however I need a way to know what the agentID is for every machine that has registered with the pull server. Is there a way to get that via the webservice? I look forward to your blog post.

@Zuldan

This comment has been minimized.

Copy link

@Zuldan Zuldan commented Mar 31, 2016

@narine, that is fantastic news about the blog!

Will it include examples on how to report on both AgentID and ConfigurationID nodes?

@NarineM

This comment has been minimized.

Copy link
Contributor

@NarineM NarineM commented Mar 31, 2016

@jmcook01
AgentID can be retrieved from each node by running (glcm).AgentId on the node. This is the ID that the node is using to get registered to DSC pull/reporting servers and is being stored in web server's database(registration table). The web service in WMF 5 does not expose a REST API to get all AgentIDs.

@jmcook01

This comment has been minimized.

Copy link

@jmcook01 jmcook01 commented Apr 1, 2016

Are there plans to add this functionality to the API or can it be considered for a future release? It's not really practical for me to try and query every machine in my environment for their AgentID so I can generate an overall status report. Otherwise I'll have to look at collecting the AgentID via another inventory method which seems unnecessary when it's already in the DSC database.

@jmcook01

This comment has been minimized.

Copy link

@jmcook01 jmcook01 commented Apr 7, 2016

Any updates on the blog post @NarineM ?

@NarineM

This comment has been minimized.

Copy link
Contributor

@NarineM NarineM commented Apr 14, 2016

Closing this thread. Stay tuned for the blog post on web services supported APIs that will be published on powershell blog.

@kamranayub

This comment has been minimized.

Copy link

@kamranayub kamranayub commented May 10, 2016

Still no blog post yet... also there's got to be something better than querying individual servers to get their Agent ID. I understand the reason why a get all probably doesn't exist is because if an attacker had access to the endpoint they could enumerate all the agents.

However, it seems like it would be okay to allow passing in the registration key(s) for a pull server to find allow access to see the nodes.

Otherwise, in a web portal, you'd have to have a list of all the servers you care about, then remote into them individually to find their agent IDs, then do some kind of batch query or parallel query to the DSC service to pull their compliance status. That's a lot of hoops to jump through for a basic use case. We can do it, but it's not very elegant.

@theonlyway

This comment has been minimized.

Copy link
Author

@theonlyway theonlyway commented May 10, 2016

Although no ideal during my registration process of adding a new machine I write it's agent ID out to a CMDB and just get a list of all the agent ID's from my CMDB. Something I do to keep the CMDB complete but on the flipside something I technically shouldn't need to do if DSC is already keeping all this information in a DB.

My process obviously won't help if you've already deployed config to a bunch of machines but if you are still kind of fresh like I am it helps.

@ArieHein

This comment has been minimized.

Copy link

@ArieHein ArieHein commented May 13, 2016

As I said in Dougs repo, this is silly. They removed the dependency on ConfigurationID GUID but now I have to record all nodes AgentID ?
Not hard to implement the GET method to query a list of AgentID from inside the local DB

@kamranayub

This comment has been minimized.

Copy link

@kamranayub kamranayub commented May 13, 2016

Yeah it's a step backwards from before. If we could pass the registration
key to "secure" the GET call, I'm fine with that.

GET /PSDSCPullServer.svc/Nodes(RegistrationKey = ahagsgzgab755)

Or whatever else would work, if the concern is around security.

On Fri, May 13, 2016, 03:59 Arie Heinrich notifications@github.com wrote:

As I said in Dougs repo, this is silly. They removed the dependency on
ConfigurationID GUID but now I have to record all nodes AgentID ?
Not harrd to implement the GET method to query a list of AgentID from
inside the local DB


You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#98 (comment)

@ArieHein

This comment has been minimized.

Copy link

@ArieHein ArieHein commented May 13, 2016

I dont think using the RegistrationKey is a good idea, its something only used for the initial registration and is deleted afterwards.

GET /PSDSCPullServer.svc/Nodes

is enough to iterate

@rayterrill

This comment has been minimized.

Copy link

@rayterrill rayterrill commented Jun 7, 2016

Is this still an open issue? Agree with all the previous posts - not having some way to iterate registered nodes from the DSC Pull web service seems like big gap.

@kamranayub

This comment has been minimized.

Copy link

@kamranayub kamranayub commented Jun 15, 2016

Yes it's still open. I've worked around it a little by enumerating our servers nightly and getting their pull server configuration and storing in a DB, but we already had a lot of that infrastructure in place to do that. It's not ideal because it will miss servers that are not in our DB and it can be 24 hours behind the truth. I'd definitely rather query the DSC endpoint itself to get the agent list.

Also, the OData endpoint does not support $top, so it returns ALL the job runs, which, after a month I'm getting 154 results back (for one node) and the service call can take up to 3-4 seconds to return which is annoying--I just want the latest result, if I want the history I'll ask for it.

@rayterrill

This comment has been minimized.

Copy link

@rayterrill rayterrill commented Jun 17, 2016

Ugh. This is asinine to still have open. Thanks for the response, @kamranayub!

We've switched directions and are looking at Chef + DSC currently. Seems like there are too many DIY pieces needed with DSC proper.

@rosswickman

This comment has been minimized.

Copy link

@rosswickman rosswickman commented Jun 22, 2017

I understand why there is no iteration. But has anyone come up with a solution on getting the latest 'single' jobId? We have nodes pushing 1700 check ins. It is crazy to pull that much when all I want is the latest.
We are loading all the info to a db for better management but when every node hits the report server that is a heavy burden.

@kamranayub

This comment has been minimized.

Copy link

@kamranayub kamranayub commented Jun 22, 2017

@rayterrill

This comment has been minimized.

Copy link

@rayterrill rayterrill commented Jun 22, 2017

@kamranayub

This comment has been minimized.

Copy link

@kamranayub kamranayub commented Jun 22, 2017

@rayterrill

This comment has been minimized.

Copy link

@rayterrill rayterrill commented Jun 22, 2017

@rosswickman

This comment has been minimized.

Copy link

@rosswickman rosswickman commented Jun 23, 2017

Interesting. I guess we get what we pay for. And then spend weeks building custom solutions.
Anyone using AWS OpsWorks?

@ArieHein

This comment has been minimized.

Copy link

@ArieHein ArieHein commented Jun 23, 2017

@kamranayub Going with ansible would be the more 'techie' way. The other CMs like Puppet and Chef is the more 'cost effective' way in the business aspect.

Personally I started learning Ansible few months ago and I think its a better tool for my type. The lack of agents, the WinRM support (yes I know Chef has WinRM support via python library), not needing to learn a new programming language like Ruby to support it, YAML vs Json and more.

Yes, the support in Chef and Puppet for Windows is a tad better because of the bigger user base, heck MS is 'drooling' over Chef that I wouldn't be surprised if they bought them instead of massive effort and time it would take them to build their own CM (which by the way, is what Angel Calvo said in the last PSEU conf that will eventually happen - the CM part).
(they could take some parts of SSCM outside of their engine and open source it as a base but it would still require a huge effort over buying something and assimilating it).

That said, the great work of https://github.com/trondhindenes in the field and some articles from the community like Adam Bertram are great resources if you do choose to proceed this path.

Personally I'd much rather see MS adopt Ansible as base and use OpenSSH and now PowerShell.core to basically remove the only major adaptation block in Ansible, imho, and that's the requirement to run Ansible on a Linux server, even if youre a pure MS shop.

@rayterrill

This comment has been minimized.

Copy link

@rayterrill rayterrill commented Jun 23, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
8 participants
You can’t perform that action at this time.