Integration features
Your choice of 1E Client version, and therefore the version of 1E Client Deployment Assistant (CDA), depends on which integration features you need, and if you need any other features of Tachyon Platform.
WakeUp 7.3 client is included in each of the supported versions of 1E Client, with later versions containing hotfixes. You can deploy hotfixes separately. You only need to enable WakeUp client if you are using WakeUp features with NightWatchman.
NightWatchman Agent 7.3 is available as a separate installer. Please refer to Installing the 1E NightWatchman Agent for Windows.
1E Client and NightWatchman Agent 7.3 can be deployed on their own, or with the aid of any supported version of CDA.
| 1E Client | Integration features | Client Deployment Assistant (CDA) |
|---|---|---|
1E Client Deployment Assistant 8.0 This version of CDA can be used independently of Microsoft Endpoint Configuration Manager. | ||
1E Client 5.2 - WakeUp client requirements 1E Client 5.2 - Deploying 1E Client on Windows Do not use 1E Client 5.2 if you require Nomad integration with WakeUp. | NightWatchman Online Status (Tachyon Platform 5.2) Do not use Tachyon Platform 5.2 if you require Nomad integration with WakeUp. | 1E Client Deployment Assistant 1.6 |
| 1E Client Deployment Assistant 1.5 |
NightWatchman Online Status
| Anchor | ||||
|---|---|---|---|---|
|
The NightWatchman Online Status feature is described in Enabling Online Status using Tachyon integration. In addition to having a NightWatchman and WakeUp infrastructure, you must have:
- Tachyon Platform 5.1 or later - latest version is 8.0
- 1E Client 5.1 or later, with Tachyon client enabled - latest version is 8.0
Please refer to Tachyon 8.0 - Implementing Tachyon Platform for how to install Tachyon Server, and 1E Client 8.0 - Implementing 1E Client for how to install the 1E Client with Tachyon and other client features enabled.
Nomad integration with WakeUp
| Multiexcerpt | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||
The feature Integrating Nomad with WakeUp is available with the following versions of Nomad:
Integration with Tachyon to support Nomad integration with WakeUpIn addition to having a NightWatchman and WakeUp infrastructure, you must have:
Integration with ActiveEfficiency to support Nomad integration with WakeUp
In addition to having a NightWatchman and WakeUp infrastructure, you must have:
|
Accounts needed to install NightWatchman Management Center
| Multiexcerpt | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||
To install NightWatchman Management Center, you need the following accounts and groups. Installation account
Console service account
User accounts or AD GroupsUser account or AD Security Groups are required for use as administrators in the NightWatchman Management Center Console.
|
Additional steps when installing NightWatchman Management Center on a distributed environment
| Multiexcerpt | ||
|---|---|---|
| ||
If you are installing NightWatchman Management Center across multiple servers, install the database component first – it can be done remotely from a server where one or more of the other components are installed. If you are performing a clean NightWatchman Management Center installation or are upgrading NightWatchman Management Center and all the WakeUp Server components, permissions for the service account are set automatically as part of the installation process. The NightWatchman Console administrator account (used to define primary NightWatchman Console administrators) can be a domain user or group account.
To set permissions:
|
Accounts needed to install the WakeUp server
| Multiexcerpt | ||
|---|---|---|
| ||
To install the WakeUp server, you will need: Installation account
If you are installing the WakeUp server in a distributed Configuration manager environment, WakeUp Server must be installed on each Configuration Manager site server. The installation account requires:
WakeUp Server service account
If you are installing the WakeUp server in a distributed Configuration manager environment, WakeUp Server must be installed on each Configuration Manager site server. The service account requires the following rights on each site server:
The service account requires the following Administration rights in Configuration Manager before installing WakeUp Server. We recommend creating a new security role and adding the permissions. Doing this causes the specified account/group to be added to the SMS Admins local group on the provider server.
NightWatchman Management Center Console service accountThe service account for the NightWatchman Management Center Console service connects to the WMI namespace on the WakeUp server when requesting wake-ups (alarm clocks, maintenance windows and on demand wake-ups from the NightWatchman Management Center Console including Web WakeUp if installed). Therefore, to have the necessary WMI permissions, this service account must be one or more of the following:
Administrators using remote WakeUp server Admin Consoles require remote access rights to the WMI namespace and DCOM Security, as a result administrators require one or more of the following:
The service account for the NWM Console service connects to the WMI namespace on the WakeUp server when requesting wake-ups. Therefore, the service account requires one or more of the following:
NWM Console service account will be added by the NightWatchman Management Center Installer to the N1E and WakeUp namespaces with the following permissions:
|
Accounts needed to install Web WakeUp
| Multiexcerpt | ||
|---|---|---|
| ||
To install Web WakeUp, you will need the follwing accounts.
Installation account
Application pool account
|
Accounts needed to install the NightWatchman Agent and 1E Client
Installation account
| Multiexcerpt | |||||
|---|---|---|---|---|---|
| |||||
To install the 1E NightWatchman Agent and 1E Client, you will need an Installation account which must be a domain user account with local admin rights on the targeted client computers. For details on installing the 1E NightWatchman Agent, please refer to Installing the 1E NightWatchman Agent for Windows. For details on installing the 1E Client with the WakeUp client module enabled, please refer to 1E Client 8.0 - Deploying 1E Client on Windows: WakeUp.
|
Accounts needed to install Enterprise View
| Multiexcerpt | ||
|---|---|---|
| ||
To install Enterprise View, you will need the following accounts. Installation account
|
Networking
| Include Page | ||||
|---|---|---|---|---|
|
Preparing a server for web applications
NightWatchman Management Center deploys Web applications which are built on .NET (Report console and Web service). We recommend preparing the Web server by installing the runtime libraries for these applications as follows:
- Web server (IIS) role with default role services (which should include Windows authentication and ASP.NET role services).
- Application server role with .NET 4.5 and HTTP Activation role services.
- .NET 4.5 or later, ensuring that the OS specific ASP.NET is installed and enabled, refer to Configuring ASP.NET for Windows Server 2012 R2 for details.
If these runtime libraries are installed in a different order, or other applications hosted on the same Web server have modified the default IIS ASP.NET settings, it may be necessary to re-register the ASP.NET 4.5 runtime with IIS prior to running the NightWatchman Management Center installer.
You can do this with (we assume you are using the default paths):
- On 32-bit systems:
C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_regiis.exe -iru - On 64-bit systems:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet_regiis.exe -iru
| Note | ||
|---|---|---|
| ||
It is important to specify the -iru switch to avoid causing problems with other web applications which are running under .NET 2.0. |
General security measures
To comply with security certification criteria, we recommend the following measures for our products on your production environment:
- Folders and user data – restrict the
\Program Files\1Efolder to administrators to prevent unauthorised modification to configuration files. Secure 1E product communications – when using products that make use of a centralized web component, restrict access to the configuration files and XML transforms as well as any spooler directories running on the clients. Additionally, use HTTPS communications between the centralized web component and its local agents. The NightWatchman Management Center and associated components can be configured for FIPS compliance, refer to NightWatchman Management Center installer properties for more information.
Note icon false This property must be the same value for the NightWatchman Management Center, WakeUp server and the 1E Agents. - Secure operational environments – secure networks running our products by preventing magic packets from outside the enterprise network boundary from being routed to machines inside the network by configuring network routers/firewalls boundary devices to prevent magic packets routing.
- Restrict physical access to servers – restrict access to these devices to authorised administrators only.
- Secure 1E administration consoles – install 1E administration consoles on a secure environment and follow best practices such as changing administrative passwords on a regular basis.
Guidelines for large environments
NightWatchman deployments range from 500 to 300,000 seats and are supported by a single management service and is highly scalable. For customers at the upper end of this range (100,000+), these guidelines ensure optimal performance.
Performance is difficult to predict and is affected by many factors such as server hardware, disk configuration, network bandwidth, etc. Customers with similar numbers of clients can experience different performance. Our scalability testing is run against simulated activity from 300,000 computers over two years and is executed on mid-range enterprise hardware.
| Note |
|---|
Server specifications are typically: 8 core machine, 12-16 GB RAM, 5-6 SAS disks in 2-3 sets of RAID 0, gigabit Ethernet. |
Data retention
If you have particular requirements or concerns about your deployment, contact 1E for further information and assistance. When you install NightWatchman Management Center, you will be asked the approximate size of your environment (number of clients). This figure is used to configure how often agents report power data and request policies, as well as the frequency and workload size of the batch jobs. Make sure you select the most appropriate option for your environment.
As a general guideline, assuming all features are being used with their default configuration, the database storage required after a year is approximately 1MB per client. For each computer being managed, NightWatchman stores detailed power consumption data, as well as aggregated data (for reporting purposes). Data is aggregated by day, month and year. To help keep the database size down, each of these data stores is periodically trimmed. For large (100,000+ seats) deployments, we recommend changing the default retention values to:
| Table and Configuration Setting (in tbNWM_Settings) | Setting name | Default | Suggested |
|---|---|---|---|
| Detailed consumption (tbNWM_Report_Consumption) | ReportConsumption_KeepDays | 90 | 15 |
| Aggregated daily (tbNWM_Report_Consumption_Daily) | DailySummary_KeepDays | 90 | 30 |
| Aggregated monthly (tbNWM_Report_Consumption_Monthly) | MonthlySummary_KeepDays | 731 | 366 (1 year) |
| Aggregated yearly (tbNWM_Report_Consumption_Yearly) | YearlySummary_KeepDays | 3653 | 1826 (5 years) |
| Note | ||
|---|---|---|
| ||
Increase A power behavior is a snapshot of how a specific group of machines behaved over a specific period of time. Typically, you create a power behavior to act as a baseline in order to calculate ongoing savings for that group of computers. Increasing the number of days kept allows you to delay the choice of which groups to analyze. However, it is good practice to decide early on how many days are kept and use this as a deadline for the baseline of your power savings project. For more information about power savings projects, see Using a NightWatchman baseline to identify power savings. Tariffs and hardware power consumption values do not affect power behaviors but do affect energy, cost and emission reports, and aspects of the reports produced by the NightWatchman analysis reports wizard, refer to Piloting NightWatchman Enterprise: Running the NightWatchman analysis reports wizard. It can take time for these variables to be finalized, at which point reports can be produced for different periods and compared. |
Reporting
Almost all NightWatchman Management Center reports (particularly those related to energy, cost and emissions) are run against aggregated data tables (see data retention). Where possible, we recommend running reports which use monthly/yearly data (rather than daily data) – this will not provide as much detail in the report itself, but will give better performance and should be sufficient for most data analysis.
Batch jobs
Be aware that system performance is impacted while the batch jobs are running, so allow for this. Batch jobs can be monitored using Operations reports from NightWatchman Report Console. If they are significantly impairing performance, they can be reconfigured to run less frequently and at more convenient times.
SQL Server
SQL Server offers enormous scope for configuration. We pre-configure our database based on the type of environment you select during installation; other configuration options are better suited to per-installation tuning. Specifically, you may wish to monitor database growth rates and adjust them accordingly. There is also potential to use file groups to improve performance.
Hardware configuration
| Component | Notes |
|---|---|
| Processor | NightWatchman server-based components have greater I/O than CPU needs; that is to say that a server's disks are more likely to become a performance-limiting factor than its processors. Configuration options such as HTTPS and SQL Server processor affinity can affect this, so for large-scale deployments, we recommend a quad-core server. However, an eight core server is preferable. |
| Disks | Disks are a very important consideration in achieving consistently high system performance. Where possible, we recommend the use of enterprise-class disks (SAS, 10-15k RPM) supported by a hardware RAID controller. To make the best use of disk resources, it is common to place SQL Server data, log and temporary files on different disks to maximize throughput. Contact 1E for more information. It is also worth mentioning that disk space can be consumed very quickly in a large deployment. A database supporting 100,000 clients will grow to several hundreds of gigabytes of disk space, therefore proactive monitoring and adjustments to data retention settings is advised. |
| RAM | For large-scale deployments, we strongly recommend use of 64-bit operating and SQL Server systems, preferably using the most recent Microsoft OS and SQL versions. 32-bit architectures have inherent memory limitations, and later Microsoft platform versions continue to be optimized for performance. We recommend a minimum of 16GB of RAM for hosting SQL Server in a large NightWatchman deployment – typically, most of this memory will be required for the SQL Server caching subsystems. |
| Network | Even with hundreds of thousands of computers reporting, a NightWatchman deployment typically uses very little network bandwidth. During intensive scalability testing, we see send/receive peaks of no more than 2-3 megabytes per second (20mbps). This kind of throughput can be handled comfortably by gigabit-enabled networking hardware. |
| Virtualized Hardware | For large-scale deployments, we recommend physical, rather than virtualized hardware where possible, especially for the database server. If you have a specific requirement to support a large-scale virtualized deployment, we would recommend use of a bare-metal or native type hypervisor. |
Scaling-up versus scaling-out
NightWatchman Management Center Web and database components can be deployed across multiple servers to help distribute workload. Although this can increase administrative complexity, using separate database and web-servers (scaling-out) can dramatically improve performance.
However, consider this option only if you are unable to achieve acceptable performance with a single server. Additional hardware, especially disk resources, can help improve the performance of a single server (scaling-up).
Client hardware requirements
| Multiexcerpt | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||
To utilize Wake-On-LAN (WoL) technology, you need the following hardware configurations:
A quick way to tell if a system is Wake-On-LAN ready, is to power down the system then look at the network adapter display LED's. If the lights are still on, then chances are that the system is OK. Windows must have been powered down gracefully (either off or sleep) in order for it to prepare the network card for WOL. 1E also provides a diagnostic tool called Magic Test that determines if a machine can react to a magic packet wake up. Download Magic Test and other free tools from 1E’s Free Tools page.
|
Sizing and deployment considerations
| Include Page | ||||
|---|---|---|---|---|
|
| Footnotes Display |
|---|