For example does LCM notify use SMTP (email) ? or SNMP (trap) or Syslog, etc... ?
Also when I think of Notify above, I am thinking of notifying an Admin is the configuration of the server has drifted and therefore DSE needs to bring it back inline and will notify the admin of this fact.
However, what happens if for any reason the LCM is not able to pull down updated MOF files or modules from the DSE distribution point, will DSE also Notify the admin of this issue ?
Also, what is the reason the LCM cannot get is latest MOFs (or at least check-in to see if there are any updates) is due to network or WAN issue (temporary loss of connectivity to remote site), the LCM notify the Admin next time the network link is up there was an issue (even if it then established connectivity OK there after), for example lets say the LCM on the node checks in every 4 hours with its pull server, but misses a check-in due to WAN issue but next time it check in OK, will the Admin be notified of this missed check-in ?
I would be very grateful if someone can help me with the above questions please, as we are looking at how to deal with keeping out Windows boxes in check (e.g. enforce and maintain a known config) for server across may remote (some very remote) sites where WANs can and do go down from time to time, and I want to know if DSE can handle this and alert the Admin if it cannot pull down a MOF or missed a check-in etc.
So, it's DSC, not "DSE." Desired State Configuration.
Notify is designed to use a Reporting Server, which is a function of the Pull Server code. The native Pull Server saves information into a database and nothing more. Azure Automation's DSC functionality provides reporting. In Notify mode, the LCM doesn't attempt to enforce a configuration at all – it simply gets the current configuration.
In the event of a loss of connectivity, the only indication would be log entries on the node's LCM log. A loss of connectivity is considered a "bigger" issue that's beyond what DSC deals with; you should already have monitoring systems in place to inform you of a loss of connectivity, since that affects numerous services, not just the LCM.
You may want to consider reading "The DSC Book," which covers all of this in pretty lurid detail. But if you're thinking "Notify" is based on email or alerts or something, then you're overthinking it [grin]. It's none of that.
Thanks for taking the time to reply, much appreciated
So this database server on the pull server is that an instance of SQL Express or WID ?
So if the Notification events end up in the database on the Pull server is it up to the Admin to setup SSRS or use PowerShell to query the database to make their own reports from the raw data stored about the notifications ?
In other words has MS not layered on a nice WEB portable to the pull database to report on number of nodes, which are in compliance and which are not etc... so it is up to the admin to ferret this out by either querying each node in turn or getting the data from the database ?
Thanks again, I would be very grateful if you could just summaries to answer my questions above, in the mean time I will look for that book.
No, you're overthinking it again :).
The database is an EDB by default, but can also be SQL Server. In terms of making that highly available, that's a SQL Server question. Making the pull server available is an IIS question. This is covered in “The DSC Book.”
There aren't “Notification events.” There are no events. The LCM simply reports its state, as a giant JSON object, to the pull server; the pull server dumps that into a column in its table. Period. Anything else you want to do with it is up to you. The native pull server is EXTREMELY simplistic (and also deprecated). You might explore OSS options like “Tug,” which is a GitHub project that you can customize to your liking.
The native pull server was only ever intended as an “example.” Aside from Azure Automation, MS does not provide an enterprise-class pull server. Tug was intended to address that, but it is not a plug-and-play option; you're intended to code your own handler layer to do whatever you want. The new option to use SQL Server may make the native pul server palatable for you, but it is an extremely minimalistic implementation. There is ZERO reporting. The “Reporting Server” option is simply the ability to accept data dumps from nodes and store those in a database – that it ALL. There are no reports, no web interface, no alerts, no events. If you want an of that, you build it yourself or find a third-party or open-source project that does it (I'm not aware of any).
Thanks again that is very useful information, things are starting to become clearer now, I will buy that book and give it a read too.
I found this https://octopus.com/blog/octopus-and-powershell-dsc
One last question please (honest),
I have an .ios image of a gold build for my Server. I use what ever method to build my server from this iso
'before' the network card is enabled (disabled or not configured in the gold build by design), I want to make sure my AV agent is running, certain reg keys are how I want them and my certain items are set for auditing etc.... In other words before it joins the network my server needs to pass several checks, can I use DSE as part of this process so when it boots up and the OS starts (and therefore the LCM) can I prepopulate the System32\configuration directory with MOFs and Resources (as part of the gold build image) so LCM picks this up and checks/enforces the state I am looking for, the last part of the DSE could be to enable the NIC for example via WMI call. Is this possible, a scenario for DSE ?
the when it is on the network it connect to the pull sever to any new configs
You must be logged in to reply to this topic.