How does the NightWatchman reporting data get generated?

NightWatchman

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 NightWatchman process are derived. I addressed the 1E WakeUp reporting process in a previous article.

Architecture

NightWatchman is a client-server architecture. It consists of a server hosting the NightWatchman Management Center. This server installation consists of a SQL server, an IIS webapp, a web reporting environment, and a management console. The client side consists of the 1E Agent deployed to all managed computers (note: this agent will not install on a server operating system). The console is where the Administrator may arrange client machines into logical groups in a hierarchal fashion, by location, organization, or both. To these groupings are applied policies that govern the desired shutdown behavior and schedules for the hierarchy in whatever way is deemed appropriate for the business. Clients periodically poll this console/server looking for new policy applicable to them (not unlike the ConfigManager polling a Management Point). When new policy exists, the client downloads and applies the new policy (i.e. shutdown behavior and scheduling). As power related events occur on the client, it generates a file in the form of *.afr, and periodically sends these files to the Management Center server in a batch fashion.

On The Client

Within the NightWatchman agent there are a number of messages (individual files in the form of *.afr) that can be created on the client as power related events occur (going into standby; monitor in standby; powered off; powered on; etc). The list of messages that can potentially be generated is quiet large. They may be seen on the server here : C:\Program Files (x86)\1E\NightWatchman Management Center\WebService\Transforms. Every file starting with NWM_ is a possible message from NightWatchman. For the purpose of this document we will only talk about NWM_Shutdown_ and NWM_State_ messages as these are the ones we care about for the purposes of this article.

File Generation

On every power state change the NightWatchman agent generates a new file and stores them locally in C:\Documents and Settings\All Users\Application Data\1E\Reporting\NightWatchman. It does the same for every Shutdown action, including those initiated by the user, and those initiated by NightWatchman. At a minimum the NightWatchman agent must create one message per day if it remains constantly on. That file is generated a midnight (local time) to indicate a 24h period of “always on” time has elapsed.

File Upload Cycle

NightWatchman by default waits until 25 messages have been created before uploading them in a batch fashion. The agent scans its outbox every 10 minutes to see if this minimum number of messages have accumulated. If after 4 hours there are still less than 25 messages, it will upload whatever number have accumulated regardless.

On the NightWatchman Management Center 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)

On IIS

As discussed above, under IIS there is a webapp running called “AFWebservice” which accepts the files uploaded by the client batch processing described in the File Upload Cycle paragraph. Receipt of these messages is written into the IIS log file called WebService.log, found in C:\ProgramData\1E\NightWatchmanManagementCenter. This IIS app will send the data to its companion SQL server database via Transform files that are found in C:\Program Files (x86)\1E\NightWatchman Management Center\WebService\Transforms. The transforms define how the data is written to SQL. You will also see the name of the SQL Stored Procedure used, and its parameters.

On SQL

The data for the various power state transitions on the clients is written into tbNWM_Load_States. The data relating to shutdown actions is written into tbNWM_Load_Shutdowns. On the SQL server database there is a SQL Agent job (1E NightWatchman, Process load) that processes these pending data insert actions. How often this Job runs depends on your configured environment size selected at install time (i.e. Very Small/Lab; Small; Medium; or Large). Normally it runs approximately once every 50 minutes. This Process Load job will prepare received raw client data relating to power states into the tbNWM_Report_Consumption table. It also prepares the tbNWM_Report_Shutdowns table for the Load Shutdowns data.

Most reports are derived from the tbNWM_Report_Consumption_Daily table data. This table is prepared by the “1E NightWatchman, Process Summaries” Job, which runs approximately once every 4 hours. This SQL Agent job summarizes the data from the tbNWM_Report_Consumption table into tbNWM_Report_Consumption_Daily table for reporting.

Speeding up the Reporting

The best way to speed things up for troubleshooting (only!) so you have reporting data faster is by changing the schedule used by the client’s 1E Agent so that it polls its outbox more frequently, and will send up data with fewer than the default number of messages in the queue.

On the test client(s) edit the registry value: HKEY_LOCAL_MACHINE\SOFTWARE\1E\NightWatchman\Reporting\MinMessagesPerBatch (REG_DWORD) from the default 25 (Dec) to the desired interval. Set this value to a low value (e.g. 3). In this fashion fewer messages are required before the polling cycle will upload them. Likewise, edit the registry key value: HKEY_LOCAL_MACHINE\SOFTWARE\1E\NightWatchman\Reporting\PollIntervalSecs (REG_DWORD) from the default 600 (Dec, or 10 minutes) to the desired interval (e.g. 300, or 5 minutes). While the client agent’s periodic polling for new policy (and related settings, including these) should return the above settings back to the default values on the next poll interval, DO NOT FORGET TO DELETE THIS KEY WHEN FINISHED TROUBLESHOOTING!

Summary

This article explains the basics of how NightWatchman reporting data is generated; how and how often the process is initiated; how power state transitions and shutdown activity 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. I also address the companion 1E WakeUp process as it relates to the success and failure of wakeup activities 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 /nightwatchman/, or follow our LinkedIn Showcase page.

Share this post

Share this post on your favourite social media platform.

Find this article useful?

If so please click here