When designing a new file server in a Windows Server environment, you need to take into account a series of design factors in order to properly finalize your implementation. This article provides Windows file server design considerations.
There are a lot of Windows file server design considerations. The following general design factors must primarily be taken into account.
- Active Directory vs Workgroup. It is highly recommended to utilize Active Directory domain services in order to make use of the secure authentication and authorization capabilities of AD.
- File protocol(s) used. Even though the NFS protocol is supported, it is highly recommended to utilize the SMB/CIFS protocol latest version (at least SMB 3.1.1) with all security enhancements. You should disable all insecure versions of the SMB protocol. For NFS, it is always recommended to utilize a Linux or BSD-type Unix server, since this would provide the full breadth of NFS protocol features to NFS clients.
- Standalone File Server vs General Purpose File Server vs Scale Out File Server (SOFS) using Windows Failover Clustering (WFC). A standalone file server suits Proof of Concept and lab/test environments. For a production environment you should choose either a general purpose file server cluster or a scale out file server (SOFS) cluster, depending on the workloads and applications you will need to support. A summary of the differences between these two available types of file server clusters is shown in the following screenshot.
- Physical vs virtual server(s). It is highly recommended to combine at least three (3) nodes including two physical servers and one virtual for the file server cluster. This will provide maximum availability and redundance in case of total failure of even two of the three nodes (N+2) design). This assumes that the hardware specifications of each of the File Server cluster nodes will be sufficient for the total file services workload.
- Network and storage. In terms of networking it is recommended to utilize NIC teaming for the physical servers or SET (Switch Embedded Teaming) for the virtual servers. There should be a dedicated team for the storage connections and a dedicated team for the domain traffic. The network should be configured to utilize Jumbo frames at all endpoints if possible. There should be separate subnets and VLANs for storage traffic and for the file services domain traffic. Storage should ideally reside in a redundant SAN appliance. The configuration of the storage layers and LUNs should be carried out according to the application types and the workload which will be served by the file server cluster (e.g. flash storage for high IOPS operations and standard SAS or SATA HDD for lower IOPS operations).
- Backup files vs application files vs user files. Files in each SMB share should be classified appropriately. This will improve the reporting capabilities of the File Server Resource Manager tool to be able to properly classify file server reports.
- Folder structure and permissions (SMB, NTFS). Caution should be taken when applying SMB and NTFS permissions at all levels of the SMB shares in the file server cluster. First decide whether your SMB share will be public or hidden (with the usage of the $ character at the end). Also decide whether or not access based enumeration (ABE) will be used. Always ensure that the principle of least privilege is applied and that GDPR and ISO 27001 compliance is taken into account. Ensure that users are organized into nested AD groups and that NTFS permissions inheritance is taken into account. A separate article will provide more practical guidance on how to setup permissions on the SMB and NTFS level in a Windows Server file share.
- Folder redirection and user profiles options. When configuring a file server to host roaming user profiles or folder redirection, special considerations will need to be made. Consult my separate article which provides best practices for folder redirection configuration.
- Quota management. The proper quota templates must be created which will include a soft or hard quota as well as alerting capabilities. An email alert and correspoding event log should be created when the quota of any user or SMB share reaches the designated threshold.
- Backup capabilities. You should consider a dedicated external SAN/NAS appliance for backup purposes of all your production environment files. You should also consider configuring Volume Shadow Copies on the proper volumes of the file server cluster. Volume Shadow Copies are supplemented by configuration settings which are set either via Group Policy or directly in the File Server cluster nodes’ registry.
- Antimalware protection. You should definitely install antimalware softare on the file server cluster nodes. This will include protection from all common file-based threats, such as virus, spyware and ransomware. In the event of a ransomware attack, you should employ Volume Shadow copies or the external backup appliance to restore all affected files. As an additional precaution you could also employ file screening templates for executable files as well as AppLocker and Software Protection policies via Group Policy.
- File server storage reporting, alerting and monitoring. You should enable periodic email alerts regarding your SMB share quota threasholds and other events occuring in the file server cluster. An SMTP server should be defined in order for the File Server cluster to be able to send email alerts. When a malicious file is detected or when a user requests access to a folder or file inside your file server share structure for which they do not already have access, you can configure the file server to send you reports and a permissions request notification, so that you can grant access accordingly.
- Classification properties and rules. This protects the environment from malicious file types.
- File Management Tasks.
- Windows Updates. In the case of a file server cluster, you should consider Cluster Aware Updating (CAU), WSUS or choose to manually update the File server cluster nodes. This depends on the level of automation or Windows Update flexibility you wish to accomplish.
This article presented Windows file server design considerations.