Good question.
I dont know yet the full structure to the json in StatusData, but from the code at the bottom part of the how to use the report server page
https://msdn.microsoft.com/en-us/powershell/dsc/reportserver
Youll see that resources that are in their desired state will be in $resources. Question is if there’s a section called ResourcesNotInDesiredState or similar. It’s one of my tests to initially cause the state to change and see what the log states.
I do think, that if you want real time status, I’d actually query the LCM directly via
https://msdn.microsoft.com/en-us/powershell/wmf/dsc_statestatus
or use Test-DscConfiguration
as for getting all the agent status, dont think it will be hard to iterate through all the agentid available. But that leads to a different question, how long does history stays in the db, and what happens to data of nodes that have been decommissioned
Thanks for all of this great information. Does anyone know a way that I can query the Report Server to find all the agent IDs that have reported their status?
@Arie, I don’t really need realtime stats, even 30 min off would be fine. The problem is the boss wants to see the status of all the servers on a single webpage and making a connection to 200+ servers to get LCM status is going to be really inefficient if all that data already sits at the report server, I mean that was what the report server was designed for. I already have a nice webpage for servers using the Compliance server. Surely the report server has a way to provide the status for all servers like the Compliance server can.
@Matt once I’ve sorted out my ConfigurationID issue I’m going to go hunting for a Odata explorer tool which will hopefully help me discover data is available. I’ll report back here with what I find.
Edit: found one, haven’t tried it yet. OData Powershell Explorer https://psodata.codeplex.com
I good starting point is a list of what functions are available. You can see them here…
https://pullserver:8080/PSDSCPullServer.svc/$metadata
Dont forget Zuldan, that you can run PS scripts on the remote node so its not going to take much time for all nodes to run it. all you have to worry about is gathering the returned data and display it nicely.
If you want to run them on your pc instead, you can always use the Wokflow commands to build your small execution engine.
I pitched in my pov on it zuldan. I tried using several tools but can’t find a decent model as they didn’t implement any Get method to return info. The only way was using the URI method as in the documentation but that forces me to either run it from the node (so I get the local AgentID) or start managing them just fir the sake of the reports, which is then bit silly seeing we moved from being dependant on GUID management for pull servers to the RegistrationKeys method, but now depends on managing the AgentID GUID…
Really hope they push in more info on this and implement a more richer report server
@Arie H, I’ve had a similar result when querying the API. The only other thing I’ve gotten to work is the following:
Invoke-RestMethod -Uri "https://dscpullserver.domain.local/PSDSCPullServer.svc/Nodes(AgentId= '9B616A2C-DB70-11F5-80C2-121DD8C7201D')" -ContentType "application/json;odata=minimalmetadata;streaming=true;charset=utf-8" -Headers @{Accept = "application/json";ProtocolVersion = "2.0"}
Invoke-RestMethod -Uri "https://dscpullserver.domain.local/PSDSCPullServer.svc/Nodes(AgentId= '9B616A2C-DB70-11F5-80C2-121DD8C7201D')/Reports" -ContentType "application/json;odata=minimalmetadata;streaming=true;charset=utf-8" -Headers @{Accept = "application/json";ProtocolVersion = "2.0"}
@Zuldan
Did you get any further with this? Like yourself I am after a status page to see if each node is in it’s desired state, much like what we get with the compliance server.
I’ve found the function works as expected, you simply HAVE to use a registration key in the reportingserver block, even if you plan to otherwise use the LCM in ConfigurationID mode.
Basically the new reportingserver does NOT have any backwards compatibility, thus must rely on AgentID (and thus requires you to setup using registration key).
Hope that helps.
EDIT: for better clarity:
[DSCLocalConfigurationManager()]
configuration PullClientConfigID
{
Node localhost
{
Settings
{
RefreshMode = 'Pull'
RefreshFrequencyMins = 30
RebootNodeIfNeeded = $true
ConfigurationID = 'e151f804-9b5f-4dc9-9620-bd087ccfab4d'
}
ConfigurationRepositoryWeb CONTOSO-PullSrv
{
ServerURL = 'https://CONTOSO-PullSrv:8080/PSDSCPullServer.svc'
# do not put a registration key in this block; it will conflict with the configurationID
}
ReportServerWeb CONTOSO-ReportSrv
{
ServerURL = 'https://CONTOSO-ReportSrv:8080/PSDSCPullServer.svc'
RegistrationKey = '30ef9bd8-9acf-4e01-8374-4dc35710fc90'
#DO put a registrationkey in this block
}
}
}
I should also state I’ve not tried it against the latest pull server (just found out they switched from a windb to ESEDB … no idea if that shakes things up).
@Andrew Palmer, Microsoft has confirmed that there is no way to retrieve all the nodes at once like we could with the Compliance Server. So you would need to keep a record of AgentID’s or ConfiurationID’s (depending what you use) and then query each node 1 by 1. Maybe PS5.1 will have this feature later this year? We can only hope. Actually we should probably start up a UserVoice for that.
@Justin King, apparently using a Report Server with just ConfigurationID’s is possible. I’m currently working with NarineM (MSFT) to get the exact code to make it work. See ReportServerWeb - Broken with ConfigurationID method · Issue #97 · dsccommunity/xPSDesiredStateConfiguration · GitHub
NarineM (MSFT) - "If the node is setup to use ConfigurationID , ConfigurationID.mof has to present on the pull/reporting server (in the DSCService\Configuration folder). This ID is used by reporting server to authorize the client for send report operation. If a file with the name .mof does not present on the reporting server, the server would reject the client request to send a report.
It is similar to registrationKey scenario where the node has to be setup with a registration key and that key is required to present on the reporting server (in DSCService\RegitrationKey.txt file) . This key is used by the reporting server to authorize the client for sending status report operations."
@Justin King, I’m really interested in your idea. Any chance you could show us code on what ConfigID + a Reg Key looks like (beginning to end + a report)? I didn’t know you could configure a node to use a ConfigID and have it use a reg key.
Here is a sample of how to create a full DSC setup which produces a report at the end using Reg keys
https:// Sample_RegistrationKeys · GitHub
and here is one for ConfigID’s https:// Sample_ConfigurationIDs · GitHub
This is totally optional and I don’t expect you do it all but if you could modify either sample so that they are using both a ConfigID and Reg key that would be awesome.