This Knowledgebase article provides information about the new features of Neverfail Heartbeat V4.3 for File Server.
Neverfail Heartbeat V4.3 for File Server includes support for Microsoft Windows 2000 and Windows 2003 File Servers. This support is provided by a dedicated Application Module, incorporating the Neverfail Heartbeat Share Tracker.
Protection for Shared Folders
The Neverfail Heartbeat Share Tracker inspects the production server for shared folders, and dynamically configures the protection of all files contained in user-level shares, including:
- All subdirectories and files within the share
- Share information
- Access control lists for shares
If a user-level share is added, Neverfail for File Server will automatically protect the share.
If a user-level share is deleted, Neverfail for File Server will automatically stop protecting it.
Administrative shares (for example C$, D$, IPC$, ADMIN$), Windows System folders, and Neverfail program files are exempt from this process, and the data in them is not replicated if they are shared. This eliminates any risk of replicating machine-specific files (such as the HAL).
Support for Distributed File System (DFS)
Neverfail for File Server can be used to protect shared folders, which are published on a network using Distributed File System (DFS) and/or Active Directory (AD), both of which are standard components of Windows 2000 / 2003 Server.
It should be noted that Neverfail for File Server cannot be installed directly on an AD server. Please refer to Knowledgebase article #297 - 'Can Neverfail Heartbeat be installed on a Domain Controller?'.
Replication of File Attributes and Security Settings
The following file and folder attributes are fully replicated by Neverfail for File Server:
- File / folder creation / amendment time stamps
- File / folder Access Control Lists
- File / folder security settings
- Standard file / folder attributes (System, Hidden, Read-Only, Archive etc.)
- Files and folder names containing multi-lingual character sets
- Files and folder name case
- NTFS Compressed Files and Folders
The following file and folder attributes are NOT replicated by Neverfail for File Server v4.3:
- Hard links
- Windows NTFS Reparse Points, including:
- Volume Mount Points
- Directory Junctions
- Remote Storage
- Single Instance Store
- Symbolic Links
- Extended Attributes
- File / Folder Encryption
- Sparse Files
- Alternative Data Streams
- Disk Quotas
Neverfail is configured to provide appropriate warnings and responses to the presence of such features. Please refer to Knowledgebase article #321 - 'Neverfail for File Server: Unprotected Features of the Windows 2000 / 2003 File System'.
File Server System Monitoring
Neverfail for File Server provides:
- Availability monitoring and protection, including configurable recovery, for critical system services on a Windows File Server.
- Performance monitoring, with configurable response thresholds for a wide variety of Windows performance counters.
New SCOPE Tools Release (V2.2)
The release of Neverfail for File Server is accompanied by a new release of the Neverfail SCOPE tools (V2.2). These have been extended to support comprehensive reporting on user-level shares and other Windows features and functions supported under Neverfail for File Server.
- In earlier versions of Neverfail Heartbeat, some Alert types were not provided with a suitable default value. Recommended default values of Red Alert or Yellow Alert are now provided for all Neverfail alert types. These are listed in the Neverfail Heartbeat Management Client, under Alerts -> Configuration . The list of alertable events has also been expanded.
- In the Neverfail Heartbeat Management Client, right-clicking on a row in Log -> View Event Log could produce an empty dialogue box, or one referring to a different log entry. Right-clicking this table no longer produces a dialogue box at all, since a normal left-click achieves this, and the right-click functionality is redundant.
- A single failed login to the Neverfail Heartbeat Management Client previously triggered two instances of the 'LoginFailedException' error message. This has been reduced to a single instance of the error message.
- In some situations, the backup script nfbackup.bks, generated during the Neverfail install, excluded some files, which should have been copied to the protected server. This could cause protected applications to operate incorrectly, or fail to start when the Secondary server became active. The logic used to generate the backup set has been amended to prevent this.
For a LAN install of Neverfail Heartbeat, where channel bandwidth is generally good, protected application data (protected by Neverfail filters) is normally excluded from the backup set to reduce the size of the file nf.bkf, which is written to the Secondary server during the install. In a WAN install, where channel bandwidth may be limited, such data is generally included in the backup and restored onto the Secondary server, to reduce synchronization time at startup. In some cases, it was found that data might be included in the backup set even in a LAN install. This might make the backup file unnecessarily large.
The behavior now is that if a file is protected by a filter pertaining to that file only (i.e. of the form ..\DIRECTORY\MYDATAFILE.EDB, rather than with wildcards, as in ..\DIRECTORY\**), then the following happens:
- For a LAN install, the file is not backed up.
- For a WAN install, the file is backed up if you choose the option to back up protected application data, and it is not backed up if you do not choose this option.
- In rare situations, it was possible for buttons in the Neverfail Heartbeat Management Client to stop responding.
- In the Neverfail Heartbeat Management Client, under Communication -> Split-Brain Avoidance Configuration , it was previously possible to enter the same target ping address for both Primary and Secondary server. In order for Split-Brain Avoidance to work successfully, each server must be able to identify the other by a unique principal (public) network address. This part of the Management Client has been modified to check for duplicate addresses in these fields, reducing the chance of configuring an incorrect split-brain check.
- In rare cases, the Apply component on the passive server could become blocked, preventing file updates from being correctly applied on the passive server and resulting in a buildup of the Neverfail on-disk queues. If this behavior persisted, the queues might grow large enough to exceed the space available to them, causing Heartbeat to stop replicating.
Neverfail Heartbeat V4.3 for File Server