NightWatchman Enterprise

When Clients is selected, the right-hand side shows the Location and Organization groups that are used for organizing computers with NightWatchman clients installed. When the NightWatchman Console is started, these groups are populated from the data held in the Agility Framework database. As you make changes to the Location and Organization groups, these are saved back to the Agility Framework database.

Initially, before either of the group hierarchies have been modified, the Location and Organization groups each contain a single node – the UNASSIGNED BUILDING and UNASSIGNED DEPARTMENT nodes, that always exist and contain computers with NightWatchman clients installed that have sent information back to the Agility Framework.

To learn how to add, rename and delete groups or to add remove computers from specific departments or buildings, see modifying NightWatchman hierarchies.

Location and Organization hierarchies are each constructed of 5 tiers, always with buildings and departments at the lowest tier, with the exception of UNASSIGNED BUILDING and UNASSIGNED DEPARTMENT.

Organization groups, in contrast, enables you to model your company according to organizational units. This structure lets you apply specific power settings to computers according to where they sit in the organization. For example, if you are aware of a specific departmental off-site team building exercise, you can apply a one-off policy that sets power setting for that particular department only.

The Organization group hierarchy is constructed of 5 tiers which use the following names in NightWatchman reports: Company, Subsidiary, Division, Business Unit and Departments, with clients assigned to Departments.

Queries enables you to display a set of computers that match your selection criteria. This allows you to explore the computers in your estate. You can copy, sort and export the results of a query, and wake up one or more computers from the list. Administrators can define custom actions which can be run against the results.

Power Schemes let you define named groups of settings that control NightWatchman clients to set the power management properties of the computer it is running on. Power schemes are not directly applied to computers but are part of the definition of the power policies. In the Power Schemes section, you can view summaries of the power schemes, add new ones or edit, copy and delete the existing ones.

Power Policies let you define a combination of NightWatchman and WakeUp settings to power off and wake up machines together with a specific Power Scheme. These can be applied at any level of the location or organization hierarchies. The behavior of a power policy is inherited by all the computers associated with that hierarchy. In the Power Policies section, you can view summaries of the power policies, add new ones or edit, copy and delete the existing ones.

NightWatchman Console lets you define power consumption figures for the various types of hardware encountered and reported back by the NightWatchman clients. In the Power Consumption section you can view the power consumption table and edit the power consumption values for the different power states for each type of hardware found. To learn about editing these values, see modifying NightWatchman power consumption data.

The Tariffs section lets you define power costs that are applied to particular locations so that reports can more accurately show the actual costs for an organization. The Tariffs section lets you create a combined set of localized CO2 emissions per unit of power used and the cost per unit of power. To learn how to modify tariffs, see tariffs. Tariffs can only be applied to the Location group hierarchy, not to the Organization group hierarchy.

NightWatchman Management Center can communicate with multiple WakeUp Servers to enable scalable wake up support across large and geographically diverse networks. These WakeUp Servers automatically register themselves with the NightWatchman Management Center. The WakeUp Servers section shows a list of registered servers where you can configure which subnets are managed by each server.

The Settings section lets you define default parameters for NightWatchman Client Policies along with units used by the NightWatchman reports. To learn more about these, see NightWatchman settings.

NightWatchman Console lets you modify computer power states across your entire network, so you need to control who has access. In the Security section, you can view currently assigned users and groups, add new ones or edit, copy and delete the existing ones. Users and groups have security roles assigned to them.

Before running the Import Wizard in a production environment, we recommend that you perform the following steps:

You can run the Import Wizard interactively from the Start Menu\NightWatchman Management Center\ImportWizard.exe menu item or from a command prompt.

Click here for a tutorial.

The import Wizard comes with a number of sample scripts that use information from a number of sources to modify NightWatchman Management Center data to associate computers with their respective departments and buildings. These scripts are found in <installdir>\ConsoleService\ImportScripts.

For example, copy NWM_StagingTable_With_StoredProcedure.vbs .template and rename it to NWM_StagingTable_With_StoredProcedure.vbs.

The sample scripts do the following:

 Level1,Level2,Level3,Level4,Level5,OU=OUName,DC=D1,DC=D2... DC=Dn,DCFQDN

 Level1,Level2,Level3,Level4,Level5,Site

Level1,Level2,Level3,Level4,Level5,NetBIOSName,ComputerDomain

Level1, Level2, Level3, Level4, Level5, SubnetIP

Once the import script, target database and target hierarchy have been selected in the Import Wizard,the import process performs the following steps to import the information from Active Directory.

By default the Import Wizard is located in the following directory:

32Bit Machines:C:\Program Files\1E\NightWatchman Management Center\ConsoleService
64Bit Machines:C:\Program Files(x86)\1E\NightWatchman Management Center\ConsoleService

It can be run from a command-line with:

ImportWizard.exe <command-line parameters>

For example, to run the Import wizard in unattended mode on a particular SQL Server instance and using the built-in machine mapping script to assign machines to organization groups:

ImportWizard.exe 
-IsSilent 
-AfrServer SQLSERVER\INSTANCE,14333
-Provider_VBScriptFile="ImportScripts\Map_Machines_To_NWM_StagingTable.vbs"
-TierLevelType="organization"

The command-line parameters for the Import Wizard are:

The default values for these parameters are stored in the ImportWizard.exe.config file which also contains the name of the database, however the isSilent value is ignored, which means isSilent parameter must be used to run the process silently.

To retrieve a particular set of computers you can follow these general steps:

Click here for a tutorial.

After the results have been displayed you can then sort the columns Click here for a tutorial or export the data Click here for a tutorial.

Out of the box, NightWatchman Enterprise provides a set of built-in queries, criteria and display options - though these may be extended by an administrator, see Extending the Console Query interface for more details. The following headings describe the available built-in queries, criteria and display options.

The following table describes the built-in queries and associated criteria available from the Query: and Criteria: fields:

The display options control what columns of information are displayed for the results of the query. There are three columns that are shown for all display options:

The following table describes the built-in display options available from the Display: field.

NightWatchman will set a computer to obsolete if it has not been in touch with NightWatchman Enterprise for a configurable number of days. You can control the number of days (between a minimum of 7 and a maximum of 90) using the Hide obsolete clients after days setting in the The NightWatchman Settings section.

By default obsolete computers are not displayed in the returned results of a query. You can turn the display of these on by checking the Include obsolete machines in results. When the checkbox is checked an additional Obsolete column is displayed in the results that indicates whether a computer row comes from an obsolete computer or not.

Click here for a tutorial.

When the results are displayed you can select rows of computers in the results table and interact with them using a right-click context menu. There are three options that are provided, as described in the following table:

Click here for a tutorial.

Using NightWatchman Console you can:

NightWatchman Enterprise supports setting different times, actions and logoffs for each day of the week, letting you tailor NightWatchman behavior to suit your weekly business working practices. Daily scheduled actions are controlled from on the Scheduled Actions tab.

An alarm clock definition consists of a weekday and time when it takes place. For example, you may want all the machines in a development department to be available at 08:00am Monday to Friday, except Thursday when there is a team meeting, so the machines should be available at 10:00am.

Alarm clocks wake up the NightWatchman client computer for 60 minutes. If you want the computer to wake up for a different duration, use a maintenance window instead. You can set an alarm clocks from the NightWatchman command-line or from its console.

You can define an alarm clock by creating and applying a power policy. An advantage of using a power policy over the command-line for alarm clocks is that if WakeUp integration is enabled, you can bring a computer out of a power-off state. Using the command-line, you can only bring a computer out of a sleep state. Details on how to configure an alarm clock as part of a power policy can be found here.

A maintenance window definition consists of a weekday and time when it takes place, the duration and the action it takes at the end of the event. For example, you may want all the machines in a network to be available for 1 hour at 02:00h every Wednesday to receive Windows updates and shut down afterwards. You can set maintenance windows from the command-line or from its console.

You define maintenance windows by creating and applying a power policy. An advantage of using power policies over the command-line for maintenance windows is that if WakeUp integration is enabled, you can bring a computer out of a power-off state. Using the command-line, you can only bring a computer out of a sleep state. Details on how to configure a maintenance window as part of a power policy in the NightWatchman Console can be found using the The Power Policy dialog.

Computer reclaim (formerly hardware utilization) aims to identify the number of computers which are actually being used in an organization – the aim is to identify hardware waste where you have 50,000 computers in your organization but it turns out that no more than 30,000 are actively used at any given time. See the Using Computer Reclaim section for best practices on this.

You can gather computer reclaim data by creating a power policy where the Monitor Computer Reclaim option is enabled and then applying it to the machines you want to monitor. Alternatively, you can enable this feature by setting the 1E Agent HARDWAREUTILIZATION installer property to ON during its installation on the machine you want to monitor.

The sample and aggregation intervals for is set in the NightWatchman Console (more details under the Computer Reclaim section in NightWatchman Settings). Reports are available in the Reports console.

Sleepless client detection helps optimize your NightWatchman client computers ability to go into a sleep state, and as a result increasing power savings and energy efficiency in your organization. There are two levels of sleepless detection – the basic level is enabled by default.

The advanced level requires explicit enabling. It is possible that some applied operating system updates may prevent the advanced sleepless detection feature from functioning correctly. For this reason it is not enabled by default. To benefit from the additional process name information provided by advanced sleepless detection you must enable it. This is done from the Sleepless Client Detection tab in the NightWatchman console.

In basic mode, it reports on faulty input devices and flags potential causes why an unattended computer is failing to enter into a sleep state.

In advanced mode, where possible, it additionally identifies specific processes that prevent the unattended computer from entering into a sleep state. These processes can be added to the sleepless exclusion list to enable the computer to enter into a sleep state where appropriate, regardless of whether the named processes are running at that time.

The process for the basic sleepless detection is :

Advanced sleepless detection adds the following information to the basic sleepless detection:

Once you have reviewed the NightWatchman reports that identify potential reasons why a particular client computer is being kept from entering into a sleep state, you can add any processes named in the report to the sleepless exclusion list for that particular NightWatchman client. This is where the extra process name resolution of the advanced sleepless detection really comes into its own. We recommend that the Power Policy with the excluded processes only gets applied to the computers reported against in the NightWatchman Busy and Sleepless Processes report.

When a NightWatchman client computer is at the point where it should enter a sleep state, NightWatchman checks any named processes on the sleepless exclusion list. If the only processes preventing sleep are in the sleepless exclusion list NightWatchman will force the computer to enter into a sleep state regardless.

NightWatchman power policies define configuration settings for both NightWatchman and WakeUp. Together, they control the availability of computers and maximize power savings while minimizing any impact on productivity. Power policies are not assigned directly to computers but they are assigned to the groups that contain the computers. This is done from the Location or Organization group hierarchies.

You can define power costs in the NightWatchman console which can be applied to particular locations so that reports can more accurately show the actual costs for an organization.

The Tariffs section lets you create a combined set of localized CO2 emissions per unit of power used and the cost per unit of power.

Tariffs can only be applied to the Location group hierarchy, not to the Organization group hierarchy.

The Tariff dialog is displayed whenever you Add, Copy or Edit Tariffs. The fields in the Tariff dialog are:

Currency and CO2 per kWh units are global and dependent on the values defined in the NightWatchman Settings.

The NightWatchman console lets you use the Location and Organization group hierarchies to apply power policies across your network. You can also interact with the hierarchies to perform immediate tasks and control how the power policies are applied.

The power policy used by a computer is set according to its position in the NightWatchman group hierarchies. You fine tune the way this works with, Inheritance, overriding and precedence. The Location and Organization group hierarchies help to model real world scenarios. In Organization versus Location, you can learn how these are mapped to known situations.

Using NightWatchman console you can:

Group hierarchies provide for the inheritance and overriding of power policies. A group, at any level in the hierarchy, can have a power policy applied to it which is inherited by all the groups it contains. A locally applied group power policy overrides any inherited power policy for it and all the groups it contains.

A given computer resides in both a building and a department bringing it under the influence of both the Location and Organization group hierarchies. Power policies can be applied to both hierarchies. In this case, the power policy coming from the Organization group hierarchy takes precedence but you can override this default for a specific Location group.

The Location group hierarchy is constructed of 5 tiers which use the following names in NightWatchman reports:

The Organization group hierarchy is constructed of 5 tiers which use the following names in NightWatchman reports:

It is worthwhile taking a moment to consider how the Organization and Location group hierarchies are used and why you would want to specify a preference for one over the other.

The Organization group hierarchy is used to define policy according to business use. In this way, you set up behaviors for users in specific departments. For example, you can typify the behavior of the sales department as being different from the marketing department and define different policies for each that then get applied to the appropriate department.

The Location group hierarchy is used to define policy according to where a machine physically resides. In the previous example, the power policy is specifically designed for an office renovation. Perhaps the power policy specifies that the machines in the building are all shut down at 10PM on a Friday and not awoken until 9AM on a Monday. In this case you would want to allow the extraordinary circumstance of a particular building being renovated over a weekend to take precedence over any behaviors defined for the departments contained in that building.

NightWatchman reports report time in state, power consumption, CO2 emissions, costs and savings. Typically the location group structure is used for reporting and the organization group structure used for applying power policies, however both structures can be used for reporting and for policies.

To override the power policies in the Organization group hierarchy with those from the Location group hierarchy:

Normally NightWatchman uses subnets or Configuration Manager site boundaries to determine which WakeUp server is used to wake up a client computer with a particular IP address.

In non-Configuration Manager environments, the site boundaries for the WakeUp servers are set in the NightWatchman console. In this configuration, the first WakeUp server to register is initially given a global site boundary so that it may cover all wake up requests until the boundaries for all the registered WakeUp servers have been configured.

In a Configuration Manager environment, the site boundary for each WakeUp server corresponds to the site boundary of the Configuration Manager server where the WakeUp server is installed. In the NightWatchman console, the site boundaries are imported automatically from Configuration Manager and are read-only, though additional inclusion and exclusion lists can be added.

For both Configuration Manager and non-Configuration Manager environments, additional exclusion and inclusion lists can be defined to tailor the coverage of the WakeUp servers.

WakeUp servers have an implied order that governs which server is used when the site boundaries overlap. This Server order can be modified in the NightWatchman console. You can delete WakeUp servers from the NightWatchman console, doing this prevents the deleted server from processing any future wake up requests. If a deleted WakeUp server subsequently re-registers with NightWatchman Enterprise, it will re-appear in the NightWatchman console.

As an alternative to boundaries, NightWatchman can use Configuration Manager site codes in Configuration Manager environments. By default, NightWatchman will use check the site code first and only use the boundaries if a match is not found. This feature was introduced with 7.0.0 and was announced in the release notes as "WakeUp server mapping process able to map based on assigned Configuration Manager site". However, there is a known issue with this feature in 7.0.0, so you must also use the latest NightWatchman Accumulated hotfix for 7.0.0.

The NightWatchman console enables the network address for a particular WakeUp server to be modified. The new address is used when building the WMI namespace for connecting to the server to issue wake up requests. The validity of the namespace can be verified in the NightWatchman console.

In the NightWatchman console, the WakeUp servers section displays a list of registered servers where you can:

WakeUp servers use site boundaries that determine which server is used to wake up a client computer with a particular IP address. Site boundaries are defined using IPv4 and are represented using either subnets or IP ranges or a combination of the two. These are configured with inclusions and exclusions to allow maximum control over which IP addresses are covered by the WakeUp server.

In ConfigMgr environments, there are entries for subnets that come from the ConfigMgr server where the WakeUp server is installed. These entries cannot be removed but they can be adjusted by adding further inclusions or exclusions.

To edit a particular server's site boundaries, select the server from the WakeUp server list and click the Edit button to open the Edit WakeUp server Properties dialog. For example, WakeUp server kedevw2104 has 2 inclusions and no exclusions.

WakeUp servers have an implied order that governs which server is used when site boundaries overlap. This order is maintained in the NightWatchman Console. The servers at the top of the list takes precedence over those below it.

To change the order of the WakeUp servers:

You can delete WakeUp servers from the NightWatchman Console to stop it from processing wake up requests. If a deleted WakeUp server subsequently re-registers with NightWatchman Enterprise, it will re-appear in the NightWatchman Console.

To delete an existing WakeUp server:

WakeUp servers which do not report for 30 days are deregistered and no longer displayed in console.

The NightWatchman Console enables the network address for a particular WakeUp server to be modified. The new address is used when building the WMI namespace for connecting to the server to issue wakeup requests. The validity of the namespace can be verified in the console. As WakeUp only returns the NetBIOS name for the WakeUp server, you will need to change it if:

To change the network address for a particular WakeUp server:

You can view and modify the power consumption figures of the hardware found on your network in the NightWatchman console. Editing these values affects the information in NightWatchman reports. They are based on information available from your computer vendors. This information is usually available on the support pages of your vendors' web sites, where you download manuals and other documentation. The regulatory documents are most likely to contain the needed data.

The NightWatchman power consumption information is divided into three tabs: Desktops, Laptops and Monitors with information for each category shown in its own tab. Default values are used when hardware information cannot be found; these are <default chassis> for the desktop type, <default laptop> for the laptop type and <default monitor>.

In the Desktops tab, you can set power consumption values for specific types of computers in four operation states; namely, on, standby, hibernate and off.

In the Laptops tab, you can set power consumption values for specific types of laptops in five operation states; namely, on, on with screen in standby, standby, hibernate and off.

In the Monitors tab, you can set power consumption values for specific types of monitors in two operation states; namely, on and off.

As of August 2018, NightWatchman Enterprise can no longer integrate with ActiveEfficiency to enable the power consumption tables to be automatically updated via the cloud. 1E is still pleased to provide the same data to you using a slightly more manual process. Contact 1E Support for details.

Support will ask you to:

Support will e-mail you a file with SQL statements that you will execute in the same manner to populate the power consumption table.

To modify the power consumption values:

Click here for a more detailed step-through.

NightWatchman security lets you control who has access to specific NightWatchman features (it relies on the account information provided by the Active Directory). With NightWatchman, you can:

To add a new user security accounts:

Details for the account are sourced from the AD.

Click here for a tutorial.

To delete an existing user or group security account:

Click here for a tutorial.

To prevent NightWatchman from displaying the deletion warning dialog every time you delete a power scheme, power policy, tariff, security role or security account, check the Don't ask me again checkbox, located on the warning dialog itself.

To add a new security role:

After creating the new security role you will need to define the permissions for it.

Click here for a tutorial.

To change permissions for security roles:

Click here for a tutorial.

To assign security roles to users or groups:

Click here for a tutorial.

To delete an existing security role:

Click here for a tutorial.

To prevent NightWatchman from displaying the deletion warning dialog every time you delete a power scheme, power policy, tariff, security role or security account, check the Don't ask me again checkbox, located on the warning dialog itself.

To set viewing and access options for group hierarchies:

An administrator with Change Security permissions must set the security properties for the node in either the Location or Organization hierarchies in order of the user or group to view that it. To do this:

Click here for a tutorial.

To change the value for a parameter, click the value in the field – it changes to an edit field.

Specific values have constraint tests associated with them. Each time you change a value, they are evaluated and if the value does not pass the tests, the field is highlighted in red and when you hover the mouse over the value, a notification is displayed.

When changing any of the values under NightWatchman reporting, NightWatchman client power policy and Power policy headings you will see the following dialog displayed when attempting to Apply the changes.