GRAU DATA FileLock readme 
for Version 2.4.2 Build 203


1. Major Changes:

- Initial Support for MS Windows Server 2025
- Fix a problem with ReFS on MS Windows Server 2025.



2. Supported OS / Filesystem:

- MS Windows Server 2012 R2 Standard & Enterprise Edition, 64-bit, Microsoft Failover Cluster Support
- MS Windows Server 2016 (Microsoft Failover Cluster currently not supported)
- MS Windows Server 2019 with Microsoft Failover Cluster Support
- MS Windows Server 2022 with Microsoft Failover Cluster Support
- MS Windows Server 2025 (Microsoft Failover Cluster currently not supported)
- Full GUI aka Desktop Experience required
- Running on Active Directory Domain Controllers is not supported
- Itanium based systems are not supported

For Microsoft Cluster Systems see known restrictions below


3. GRAU DATA FileLock system requirements:

- minimum system requirements:

* CPU 1,4 GHz dual core
* 3GB Ram
* 32GB Harddisk for OS

- recommended system requirements:

* CPU 2,0 GHz dual core
* 4GB Ram
* 50GB Harddisk for OS
* secondary HDD for WORM volume

Please see Mircosoft Windows system requirements for details about 
additional hardware specifications.

Please note: consider mentioned system requirements as a basic starting 
point. Actual system requirements heavily depend on practical usage 
scenarios. Therefore you need a sizing based on your fileservers 
expected workload, which may require much more system ressources.


4. Installation:

Administrative rights are required to install, configure or update FileLock.
Run the FileLockSetup_<versionnumber>.exe to install it.


On some Windows OS a "windows logo testing" warning pops up. This can be ignored, press continue.


Remark:
For the installing you need to be logged in as Administrator or you need to run the installation 
program using the context menu option Run as administrator.


5. Configuration:

Please read the FileLock AdministrationGuide.


6. Replication:

Replication is only possible for FileLock WORM volumes as source and destination.


8. Backup:

In order to meet governmental compliance rules and preserve the WORM aspects of the original files 
you have to use Full Image Backup for protecting your WORM volumes.

In case of a WORM volume recovery you also have to use a full image restore to 
preserve the WORM functionality and meet the governmental compliance rules.

File based restores are not WORM compliant.


9. Compatibility Tests:

FileLock was successfully tested in combination with the following 3rd party applications:

9.1. AntiVirus Scanner

  Successfully tested in the past:
- Symantec AntiVirus
- McAfee VirusScan Enterprise
- TrendMicro ServerProtect
- Microsoft Defender

The compatibility of FileLock with the named Antivirus solutions is subject to changes.  
FileLock may or may not work in combination with recent versions.

We strongly recommend to exclude all FileLock WORM volumes from automatic AV scans.
Any attempt to quarantine WORM committed files may lead to unexpected behaviour.

9.2. MS Office 2003/2007/2010:

- MS Office applications (for reading)


9.3. NFS protocol support

- FileLock supports Microsoft Services for Network File Systems (NFS) that is shipped with Windows.


10. Known restrictions:


	FileLock is designed for NTFS and ReFS formatted volumes on basic disks with MBR (master boot record)
	or GPT (GUID Partition Table) partitioning schema. Partitions on dynamic disks are not supported.  
	Additionally FileLock can not be attached to disks which are encrypted by TrueCrypt.

	FileLock supports local disks, certified removable devices and certified removable media.
	On a Failover Cluster only (failover) Cluster Disks can be set to WORM. Cluster Shared Volumes are not supported.

	Shrinking an ESM protected volume is not supported.

	Adding a mirror to an ESM protected volume is not supported.

	Read-only volumes are not supported.

	Files, which have Extended Attributes or non-FileLock reparse points attached, can not be set to WORM.

	Volumes mounted inside a worm volume are not worm protected. 

	3rd party replication tools were not tested with FileLock.

	Some Linux commands (e.g. cp) set the last access time (beside other times). This is interpreted as retention time for snaplock configured files.
	In this case a "cp" followed by "chmod -w" would not set the default retention time (because the last access was set by the cp).
	In such situations an explicit "touch -a" followed by "chmod -w" is required.

	The Recycle Bin functionality can not be used on WORM volumes, since FileLock denies the move operation to the recycle bin, 
	when an expired WORM file is selected for deletion. 
	Therefore it is recommended to deactivate the Recycle Bin for the individual WORM volumes to avoid error messages. 

	Only empty volumes are supported for the conversion to WORM volumes. Volumes which already contain data are not supported.
	If you need to convert existing data please contact your GRAU DATA GmbH support.

	Backing up an image of a single, ESM encrypted partition on a GPT disk is not supported. 
	In this case an image backup of the entire GPT disk must be created including the backup of unused sectors.

	The replication service user account needs administrative rights including the backup, restore and take ownership privilege. 
	When replicating to a remote share the appropriate share permissions and NTFS/ReFS security rights must be granted to the service user account.

	FileLock WORM volumes may be part of a Microsoft DFS namespace, however FileLock server and volumes are not supported
	for DFS root.

	Replication of FileLock WORM volumes via DFS replication is not supported and will break FileLock volumes. 
	For the replication of WORM volumes use the FileLock built-in replication instead.

	Deduplication is not supported. 

	The "Controlled folder access" feature from built-in Windows Defender or Microsoft Defender for endpoint is not supported. This feature must
	be turned off when installing and using FileLock.

	On Microsoft Cluster Systems we strongly recommend to not use root level policy but only 1st directory level policies.


11. Known issues:

	The 'Single File Retention' (SFR) with the option 'Event Based Retention' (EBR) does not work as documented in combination with the
	Autocommit feature. Autocommit sets the retention timestamp to the default retention and does not allow to reduce the retention time span one
	single time. You have to set the files to WORM manually or with an Application using the snaplock interface to use the EBR feature.

	The FileLock tab shows for unsupported dynamic disks that the ESM module is not installed, even it is installed and running.
	When the message is displayed that the ESM is not installed, please check both, the ESM installation and if it's a dynamic disk.
        Please do not use dynamic disks for FileLock WORM volumes.

	Please note that Microsoft has redesigned the Recycle Bin behavior since Windows 7 and Windows 2008 Server. 
	The properties of the Recycle Bin are now tied to user profiles rather than the actual disk. 
	Therefore each user must explicitly switch off the Recycle Bin of the corresponding WORM volumes, when accessing them locally for 
	deleting expired WORM files.
