Background
1E’s industry leading power management solution, NightWatchman, consists of two core elements. They are 1E WakeUp (turns systems on using Wake-on-LAN technology); and NightWatchman (turns systems off on a predetermined schedule, while saving open, unsaved, user data in the process). Together they provide the full complement of actions needed for complete power management of the computer estate. This solution may be implemented in an integrated fashion with Microsoft Configuration Manager; or, implemented in a standalone mode independent of any systems management tool. In addition to this on/off management feature, there is a robust reporting engine that provides information suitable for a number of different organizations within the enterprise. These include at a minimum the Facilities Manager (interested in energy consumption and the cost thereof); the Corporate Social Responsibility team (interested in carbon emissions related to energy consumption and green computing); and of course the Administrator (primarily interested in tracking the success and/or failure of wakeups and shutdowns).
Our Support Engineers occasionally get calls from the Administrator asking about how the success/failure reports are derived, i.e. where the data originates, and how it is eventually rendered into the Reporting system. More often than not, this question occurs in the course of troubleshooting a problem where the expected data is not seen in the corresponding reports as expected. This article is highly detailed and intended for this Administrator. It describes how the reports related to the 1E WakeUp process are derived. I will address the NightWatchman reporting in a separate article.
Architecture
1E WakeUp is a client-server architecture. The WakeUp Server component is the means whereby a request to wake up select devices originates. The most common scenario is that of an integrated installation with ConfigManager where the WakeUp Server component is installed on the ConfigManager Primary (or primaries if more than one). Its role is to monitor all mandatory deployment schedules. At the scheduled execution time, the WakeUp Server component then identifies all the systems in the target collection, gathers up key data on each device in the collection from the ConfigManager database, and then sends a message with this data to a single companion WakeUp Agent on each subnet. This client side agent acts as a proxy for communicating with the WakeUp Server to obtain the data necessary for creating and sending the “Magic Packet” used by the industry-standard Wake-On-LAN process to power on the targeted systems. This precludes any need to configure ports and routers to allow the wakeup process. It is the reporting of the success or failure of the target machines to awaken that is core to this article
On The Client
When a new Wakeup is being processed at the ConfigManager primary server, it sends the “list” of machines to awaken, including their MAC address, IP Subnet, IP Address and so on. This is the data necessary for creating a Magic Packet. This “message” is then sent out as a command to its companion proxy WakeUp Agent on the subnet(s) to send a Magic Packet (or packets) to the targeted machines on its respective subnet.
This Agent will then create and send a Magic Packet to every machine in its list, and wait for 3 minutes (by default; this can be changed in the WakeUp Console) for results of the Magic Packet (i.e. was the request received? did the machine wake up? Was it already awake?). If it does not hear from the target machine(s) after this time it will send out one final ICMP ping to it (in case the Machine does not have the WU Agent installed, so thereby cannot send back WakeUp specific message acknowledgements). This info will be sent back to the Master Service on the WakeUp Server’s configured TCP Port.
On the NightWatchman Server
This server, known as the NightWatchman Management Center, consists of two elements: an IIS web service (receives data files from the clients); and a SQL database (fed data from IIS for storage within the database)
For Wakeup Statistics (Wakeup Success/Failure) we are generating all the received files on the WakeUp Master Server. (Note: these files use a file extension in the form *.afr) Generally speaking there will be 1 AFR file for every Server initiated WakeUp Job; one for every proxy Agent used; and 1 for every target machine. Once the Wakeup Server has generated 25 such AFR files, they will be uploaded to the NightWatchman database server via IIS.
Errors while uploading to the database will be seen in the WakeUpSvr.log. The most common error occurs when the IIS Anonymous user has been misconfigured on IIS.
On IIS
On IIS there is a webapp running called “AFWebservice” which accepts the AFR Files. This activity is written into a log file called WebService.log found in C:\ProgramData\1E\NightWatchmanManagementCenter. This IIS webapp will send the data to SQL via Transform files that are found in C:\Program Files (x86)\1E\NightWatchman Management Center\WebService\Transforms. The transform defines how the data is written to SQL.
On SQL
Most data will be inserted into the NightWatchman Management Center database via the views vwSWU_Load_Jobs and vwSWU_Load_Summary. Without going into a ton of deep SQL logic here, suffice it to say these views actually sit on top of two physical tables’ tbSWU_Load_Jobs_Left and tbSWU_Load_Jobs_Right. The WakeUp load tables are split into two partitions like this (known as “hot” and “cold” partitions) to avoid contention in the database. The view provides a logical layer on top of them. There’s also a third view and set of tables called vwSWU_Load_Status, which holds the individual, per-machine, results for each of the jobs. For our purposes just understand that there is very little processing delay here.
On SQL Server there is a SQL Agent job (1E WakeUp, Process Summaries) that processes these inserts and makes the data available to the NightWatchman Management Center reports. This SQL job runs every 20mins by default.
Speeding up the Reporting
The best way to speed things up so you have reporting faster is by changing the schedule of that SQL Agent job so that it runs on a faster schedule (Caution: doing so may use too much CPU if you have too many machines reporting in).
In addition, on the WakeUp Master server you could also create this registry value: HKEY_LOCAL_MACHINE\SOFTWARE\1E\WakeUpSvr\Reporting\MinMessagesPerBatch (REG_DWORD). Set this value to be less than 3. In this fashion even single machine targeted wakeups that generate just 3 files will get uploaded to SQL right away for processing by the accelerated SQL Agent job, without needing to wait for the default 25 files to accumulate. DO NOT FORGET TO DELETE THIS KEY WHEN FINISHED TROUBLESHOOTING!
Summary
This article explains the basics of how 1E WakeUp process is initiated; how success and failure data is generated; how that data is fed to the NightWatchman Management Center server; how its IIS and SQL server components interact to load the database; and how to speed up that process for troubleshooting and subsequent reporting. In a subsequent article I also address this process as it relates to the shutdown success and failure status information generated by the NightWatchman component in a separate, companion, blog.
Acknowledgement
The core data used in this article was developed by my colleague and former Lead Support Engineer, Reto Egeter.
Read more about NightWatchman at https://www.1e.com/nightwatchman/, or follow our LinkedIn Showcase page
