Chapter 5
Managing Storage

Since the dawn of IT, computer systems have supported a variety of mechanisms to store and retrieve data. Today, Windows supports a variety of physical storage and storage devices, including spinning disks, USB memory sticks, and SSD storage including Non‐Volatile Memory Express (NVMe).

Before you can use a disk to store data, you need to first create a partition on the device. You want each physical storage device to contain one or more partitions or volumes. Once these are created, you format each volume with a filesystem that enables you to store and retrieve data.

Windows supports two different partitioning mechanisms: Master Boot Record (MBR) and GUID Partition Table (GPT). See www.howtogeek.com/193669/whats-the-difference-between-gptand-mbr-when-partitioning-a-drive/ for more information about the differences between these partitioning schemes. Disks formatted with MBR disks are limited to 2TB, which can be an issue in some cases.

You can use a number of different filesystems for a given volume or partition. The filesystems Windows supports include NTFS, exFAT, UDF, FAT32, and ReFS. In most cases the volumes you use are likely to be formatted with NTFS, but you have options. For details of the filesystems, see docs.microsoft.com/windows/win32/fileio/filesystem-functionality-comparison .

Note in particular that Windows Server supports the ReFS filesystem. Based on NFTS, this filesystem provides additional resiliency features, although it lacks some features you might need for certain roles. For example, it does not support file encryption by the filesystem. For a comparison between the ReFS and NTFS filesystems, see www.iperiusbackup.net/en/refs-vs-ntfs-differences-and-performance-comparison-when-to-use/.

Systems Used in This Chapter

This chapter demonstrates using PowerShell 7 to manage storage. Its example makes use of the following systems:

DC1.Reskit.Org: This is a domain controller in the domain Reskit.Org.
SRV1.Reskit.Org: This is a domain‐joined server that you use for storage management.
SRV2.Reskit.Org: This is another domain‐joined server that you use for storage management.

Figure 5.1 shows the systems you use in this chapter.

**Figure 5.1:** Systems used in this chapter

Note that all systems need PowerShell 7 loaded before starting. You can do that using the scripts from Chapter 1, “Setting Up a PowerShell 7 Environment.”

Managing Disks and Volumes

A disk device on Windows needs to be partitioned into one or more individual volumes or drives. You also need to format each partition to add the appropriate filesystem.

You manage storage on Windows using the commands in the Storage module, whose 166 commands help you to manage disks, volumes, and partitions.

When creating new disk volumes (such as an NTFS‐based F: drive from a newly added disk), you can create the volumes two ways, using either New‐Partition or New‐Volume. The latter command is also used for managing the Storage Spaces and Storage Spaces Direct technologies. For more details on Storage Spaces, see docs.microsoft.com/en-us/windows-server/storage/storage-spaces/overview, and for more information on Storage Spaces Direct, see docs.microsoft.com/en-us/windows-server/storage/storage-spaces/storage-spaces-direct-overview.

An important distinction between these commands is that New‐Volume both creates a disk partition and formats the partition, whereas New‐Partition just creates the partition, which you then need to format separately.

In this section, you use a server, SRV1, to which you have added two new disk devices. You then use the storage‐related commands to bring these disks online, partition, and format them. You use these two disks on SRV1 in later sections of this chapter.

Before You Start

In this section you use a Window Server 2019 host, SRV1, a domain‐joined system on which you have installed PowerShell 7, and, optionally, VS Code. You can use the scripts in Chapter 1 to do this.

After creating the server, you need to add two disks to this host. If you are using Hyper‐V to implement SRV1, you can add these two drives by running the following:

# 0. Add 2 VHDs to SRV1 VM
#    Run this on the Hyper-V VM Host
 
# Stop the VM
Stop-VM -VMName SRV1
 
# Get File location for the disk in this VM
$VM = Get-VM -VMName SRV1
$Par = Split-Path -Path $VM.HardDrives[0].Path
 
# Create two VHDx for F and G
$NewPath1 = Join-Path -Path $par -ChildPath FDrive.VHDX
$NewPath2 = Join-Path -Path $par -ChildPath GDrive.VHDX
$D1 = New-VHD -Path $NewPath1 -SizeBytes 128GB -Dynamic
$D2 = New-VHD -Path $NewPath2 -SizeBytes 128GB -Dynamic
 
# Add a new SCSI Controller to SRV1
$C = (Get-VMScsiController -VMName SRV1)
Add-VMScsiController -VMName SRV1
 
# Add first disk to VM
$HDHT = @{ 
  Path               = $NewPath1
  VMName             = 'SRV1'
  ControllerType     = 'SCSI'
  ControllerNumber   = $C.count
  ControllerLocation = 0 
}
Add-VMHardDiskDrive @HDHT
# Add second disk to VM
$HDHT.Path = $NewPath2
$HDHT.ControllerLocation = 1
Add-VMHardDiskDrive @HDHT
 
# Start the VM
Start-VM -VMName SRV1

This snippet creates a new SCSI controller, along with two VHDX hard disk files on the VM host, and then it adds these VHDXs as SCSI disks to the SRV1 host. The two disks are attached to the net SCSI adapter in the VM and occupy the first two LUN values (0 and 1).

Getting Information about Physical Disks in SRV1

After you add the new disks to the SRV1 host and restart the host, log in to it as Reskit\Administrator. Use Get‐Disk to examine the disk devices contained in SRV1, as follows:

# 1. Get physical disks on this system:
Get-Disk |
  Format-Table -AutoSize

Figure 5.2 shows the output from this snippet.

You can see that SRV1 has three disk drives. The VM sees the drive that you created when you built the VM either as an IDE drive by default, or, if the VM is created as a Generation 2 VM in Hyper‐V, as a SCSI drive. You also see the two newly created disks, which are presented to Windows as SCSI drives. Because these two disk drives were just added to the host, Windows shows them as being offline.

**Figure 5.2:** Examining physical disks in `SRV1`

Initializing the New Disks

Before you can use these disks, which Windows shows as offline, you need to initialize them using Initialize‐Disk. You can do this as follows:

# 2. Initialize the disks
Get-Disk | 
  Where-Object PartitionStyle -eq Raw |
    Initialize-Disk -PartitionStyle GPT

This step gets the two new disks and initializes them. Each disk is now set up to use the GPT partitioning method noted earlier. Initializing the disks brings them online.

Viewing the Initialized Disks

Now that you have initialized the new disks, you can view their disk status again as follows:

# 3. Re-display disks
Get-Disk |
  Format-Table -AutoSize

Figure 5.3 shows the output from this snippet.

**Figure 5.3:** Examining the initialized disks in `SRV1`

As you see in the output, these two new disks are now healthy and online. Also note the disk number property of each disk. You use this disk number to perform disk‐related activities.

Creating an F: Volume in Disk 1

One way you can create a new disk volume is to use the New‐Volume command, which both creates the necessary partition and then formats the partition in a single operation. You create a new disk volume on the first of the two added disks, as follows:

# 4. Create an F: volume in Disk 1
$NVHT1 = @{
  DiskNumber   = 1 
  FriendlyName = 'Storage(F)' 
  FileSystem   = 'NTFS' 
  DriveLetter  = 'F'
}
New-Volume @NVHT1

Figure 5.4 shows the output of this snippet.

As you can see, you have created a new F: volume, formatted as NTFS, with 127.88GB of space remaining.

Creating a Partition in Disk 2

Whereas New‐Volume both creates the disk partition and formats it, you can also perform these operations separately. To create a first small volume on disk 2 (the second of the two disks added to SRV1), you create a G: volume using the New‐Partition command, as follows:

# 5. Now create a partition on Disk 2
New-Partition -DiskNumber 2  -DriveLetter G -Size 42gb

Figure 5.5 shows the output of this command. As you can see, the G: drive now exists and has 42GB of space available out of the 128GB total disk size.

You may see a pop‐up window saying “You need to format the disk in drive G: before you can use it. Do you want to format it? Format disk/Cancel.” Since you format it later in this example, you can ignore this pop‐up (and just click Cancel).

Creating a Second Partition

If a disk has unallocated free space, you can create a new partition and use whatever space is available, with the New‐Partition command.

# 6. Create a second partition H:
New-Partition -DiskNumber 2  -DriveLetter H -UseMaximumSize

Figure 5.6 shows the output of this command.

As you can see, the command with these options creates an H: drive on disk 2 with 85.98GB of available space, using all the remaining free space on disk 2.

Viewing Volumes on SRV1

After creating several volumes, you can view them using the Get‐Volume command, as follows:

# 7. View Volumes on SRV1
Get-Volume

The output from this command, shown in Figure 5.7, lists drives available to SRV1.

As you can see, the volumes on SRV1 include an A: drive for a floppy disk—rarely used in real or virtual machines but available.

There is also the C: system drive, a CD/DVD drive (currently empty), and three drives created in the two prior sections (the F:, G:, and H: drives). Also, the F: drive (created with the New‐Volume command) has been formatted with an NTFS filesystem, whereas you still need to format the G: and H: volumes before Windows can make use of them.

Formatting G: and H:

As noted in the previous section, the drives you created using New‐Partition are not formatted. You can create and then format separate partitions as follows:

# 8. Format G: and H:
# Format G:
$NVHT1 = @{
  DriveLetter        = 'G'
  FileSystem         = 'NTFS' 
  NewFileSystemLabel = 'Logs'
}
Format-Volume @NVHT1
# Format H:
$NVHT2 = @{
  DriveLetter        = 'H'
  FileSystem         = 'NTFS' 
  NewFileSystemLabel = 'Music'
}
Format-Volume @NVHT2

The output in Figure 5.8 shows that these two partitions are now formatted using NTFS and have a friendly name. As you can see, the two partitions have different (maximum) size remaining and size values.

**Figure 5.8:** Formatting volumes `G:` and `H:`

Getting Partitions on SRV1

Now that you have partitioned and formatted both new disk drives, you can review the partitions, as follows:

# 9. Get partitions on SRV1
Get-Partition | 
  Sort-Object -Property DriveLetter |
    Format-Table -Property DriveLetter, Size, Type

Figure 5.9 shows the output from this command.

**Figure 5.9:** Viewing partitions on SRV1

As you can see, after running the snippets in this section, SRV1 now has six partitions across three disk drives. Of those, four contain usable filesystems.

Getting Volumes on SRV1

Another way to look at the disk volumes available on SRV1 is to use the Get‐Volume command, as follows:

# 10. Get Volumes on SRV1
Get-Volume | 
  Sort-Object -Property DriveLetter

Figure 5.10 shows the output from this command.

**Figure 5.10:** Viewing partitions on SRV1

You have the option of using the Get‐Partition and Get‐Volume commands—either singly or together—to view the disk volumes available to you on SRV1. Each command produces somewhat different output. As ever with PowerShell, you have choices.

In this section you have seen how to manage disks, volumes, and partitions.

Managing NTFS Permissions

One prevalent issue with any filesystem and any operating system is ensuring that people see only what they are supposed to see and nothing else. Doing that requires a permissions mechanism to grant permissions to groups or users as your business requirements dictate.

The NTFS filesystem supports access control lists (ACLs) on files and folders. For each file or folder, the ACL describes who can have access to the resource and what kind of access is allowed. Each ACL contains one or more access control entries (ACEs) that define that a specific account (for example, a user or group) has a specific permission (such as Read‐Only) to the resource. Permissions can include Deny, which explicitly denies a user access to the file/folder. If a user has no relevant ACEs in an ACL, they have no access to the resource implicitly.

Access control can also be inherited. If you have an ACE on, say, C:\Foo that allows a group full control of that folder, by default, that permission is inherited by lower‐level folders (for example, C:\Foo\Test). Inheritance is provided by default, but you can turn it off.

With PowerShell, you can view the ACL of a file by using the Get‐ACL cmdlet. You can also set an ACL (using Set‐ACL). But there is no cmdlet available to create a new ACE; you would have to dip down into the .NET Framework to create the ACE that you could then set using Set‐ACL. Managing inheritance is also not supported directly using the built‐in commands.

As an alternative to managing ACLs using native .NET calls, you can leverage the NTFSSecurity module. This module works natively within PowerShell 7, and to use it, you download it from the PowerShell Gallery. This module makes it easier to manage ACLs and ACL inheritance with NTFS files and folders.

Before You Start

This section makes use of SRV1, a domain‐joined server in the Reskit.Org domain. This server requires Internet access, and you should log on using the Reskit\Administrator credentials. You also need to have the domain controller ( DC1.Reskit.Org) online.

Downloading and Installing the NTFSSecurity Module

The NTFSSecurity module is a third‐party module, and Windows (and PowerShell) does not install it by default. For managing NTFS permissions on a server ( SRV1), you might also need to update AD users/groups; and thus, the AD RSAT tools might be handy. You can add these modules as follows:

# 1. Download NTFSSecurity module from PSGallery
Install-Module -Name NTFSSecurity -Force 
Import-Module ServerManager -WarningAction SilentlyContinue
Install-WindowsFeature -Name RSAT-AD-Tools -IncludeAllSubFeature |
  Out-Null

The NTFSSecurity module is community‐developed, and you install it from the PowerShell Gallery. You can also obtain it directly from the GitHub page related to the module, here: github.com/raandree/NTFSSecurity.

The module and the source code are available for you to view, although downloading from the PS Gallery is simpler. The GitHub pages also provide two NTFSSecurity tutorials: one on basic permission management and the second on NTFS inheritance and privileges. These are worth exploring to learn more about the module's capabilities and usage.

This snippet also imports the Server Manager module and uses it to install the RSAT‐AD tools. You use these tools to create a new AD in “Creating the Sales Group” shortly.

Finding Commands in the NTFSSecurity Module

With the NTFSSecurity module downloaded and installed, you can use Get‐Command to discover the commands contained in the module, as follows:

# 2. Get commands in the module
Get-Command -Module NTFSSecurity

As shown in Figure 5.11, this command displays the cmdlets contained in the module. In the NTFSSecurity module (the latest version at the time of writing being 4.2.6), there were a total of 36 cmdlets that help you manage NTFS security.

**Figure 5.11:** Viewing cmdlets in the NTFSSecurity module

Some of the commands in this module improve on the cmdlets built into PowerShell 7. For example, the module includes the Get‐Item2 cmdlet, which shows whether a file's ACL includes inherited ACEs.

Creating a New Folder and File

To demonstrate the use of the NFTSSecurity module, you create first a folder and then a file, as follows:

# 3. Create a new folder, and a file in the folder
New-Item -Path C:\Secure1 -ItemType Directory |
    Out-Null
'Secure' | Out-File -FilePath C:\Secure1\Secure.Txt
Get-ChildItem -Path C:\Secure1

Figure 5.12 shows the output of this snippet.

**Figure 5.12:** Creating a folder and file

Using this snippet, you created a new folder ( C:\Secure1) and a new file within that folder ( C:\Secure1\Secure.Txt). Since the C:\ drive is formatted as NTFS, both the folder and the file have ACLs, and by default the ACEs in the ACL for both contain inherited permissions.

Viewing the Default Folder ACL

When you created the folder, Windows assigned a default ACL. To see the specific permissions of the folder's default ACL, you can run the Get‐NTFSAccess command as shown here:

# 4. View ACL of the folder
Get-NTFSAccess -Path C:\Secure1 |
  Format-Table -AutoSize

Figure 5.13 shows the output from this snippet.

**Figure 5.13:** Viewing the ACL of the folder

The folder's ACL consists of six ACEs, all of which were inherited. The default ACL also gives wide permissions to the Builtin\Users group, which may not be appropriate. Naturally, you can refine the ACL for the folder as needed.

Viewing the Default ACL on File

When you created the file, Windows created a default ACL for the file as well, which you can view as follows:

# 5. View ACL of file
Get-NTFSAccess -Path C:\Secure1\Secure.Txt  |
  Format-Table -AutoSize

As you can see in the output, shown in Figure 5.14, the file has an ACL consisting of inherited permissions .

**Figure 5.14:** Viewing the ACL of the file

In Windows, a folder and a file within that folder are separate objects. You control access to these objects by setting ACLs that match their underlying business need; for example, to define a Sales group that might contain Sales Team members from across your organization. You need to assign folder permissions to define what users can do in the folder (Can they create files? Can they create subfolders?) and what they can do to an individual file. Some files may be more “secure” than others and may need their ACLs adjusted as well.

Creating the Sales Group

To demonstrate using the NTFSSecurity module, you create an AD Universal group to hold the members of the organization‐wide Sales group. To ensure that the group is created, you can do the following:

# 6. Create Sales group if it does not exist
try {
  Get-ADGroup -Identity 'Sales' -ErrorAction Stop
}
catch {
  New-ADGroup -Name Sales -GroupScope Universal |
    Out-Null
}

This snippet first checks to see whether the group already exists. If the group does not exist yet, the snippet creates it. The AD cmdlets run on SRV1 but access the domain database on DC1.Reskit.Org.

At first sight, this method of creating a new group looks long‐winded. However, this is a good method of creating a group if the group does not exist. The Get‐ADGroup cmdlet either returns the AD group or generates a nonterminating error (by default). You use the ‐ ErrorAction parameter to turn the non‐terminating error into a terminating error that is caught by the catch block.

This step creates a Universal group. Depending on your requirements, there are other group membership schemes you could adopt that are just variations on the steps shown here. In many larger organizations, an approach known as AGDLP (account, global, domain local permission) is used. See en.wikipedia.org/wiki/AGDLP for more details on this approach.

Displaying the Sales Group

To verify that the Sales group exists, you can do the following:

# 7. Displaying the Sales Group
Get-ADGroup -Identity Sales

Figure 5.15 shows the output from this command.

**Figure 5.15:** Checking the sales group

In this case, having previously loaded the RSAT‐AD tools, you can use Get‐ADGroup. Had you not loaded these tools, you could have used remoting to run that command on a DC or a host with the AD tools loaded.

Adding Full Control for Domain Admins

The folder and file you created is intended for use only by the Sales group. To achieve that, you need to remove the inherited permissions and add permissions for the Sales group. You begin this by first giving the domain administrators full control over the folder (and the files within) using the Add‐NTFSAccess command, as follows:

# 8. Adding explicit full control for Domain Admins
$AHT1 = @{
  Path         = 'C:\Secure1'
  Account      = 'Reskit\Domain Admins' 
  AccessRights = 'FullControl'
}
Add-NTFSAccess @AHT1

This snippet adds an explicit and non‐inherited ACE onto the folder, providing full control for domain admins. This explicit ACE is, by default, inherited by files in the folders and any other subfolders in the C:\Secure1 folder. Depending on your requirements, you may choose not to do this and instead simply restrict the files to members of the Sales group. Should admin access be required at some later date, a domain or enterprise could always take control of the folder or file and give itself access.

Removing the Default File ACE

When you created Secure.Txt, Windows assigned a default (inherited) ACE allowing all users to read and execute all files. Because this is not desirable in most cases, you need to remove this ACE from the file's ACL, using the Remove‐NTFSAccess command.

# 9. Remove Builtin\Users access from Secure.Txt file
$AHT2 = @{
  Path         = 'C:\Secure1\Secure.Txt'
  Account      = 'Builtin\Users' 
  AccessRights = 'FullControl'
}
Remove-NTFSAccess @AHT2

Removing a Folder's Inherited Rights

The next step in securing the folder is to remove all inherited rights so that the folder has only those permissions explicitly set, with no inherited permissions. You do this using Disable‐NTFSAccessInheritance, as follows:

# 10. Remove inherited rights for the folder
$IRHT1 = @{
  Path                       = 'C:\Secure1'
  RemoveInheritedAccessRules = $True
}
Disable-NTFSAccessInheritance @IRHT1

Adding Sales Group Access to the Folder

The final step in securing the folder is to add an explicit permission on the folder to the appropriate users. In this case, that means giving the domain's Sales group access to the files and any subfolders below C:\Secure1.

You do this again using Add‐NTFSAccess, as follows:

# 11. Add Sales group access to the folder
$AHT3 = @{
  Path         = 'C:\Secure1\'
  Account      = 'Reskit\Sales' 
  AccessRights = 'FullControl'
}
Add-NTFSAccess @AHT3

Because the Sales group has full control over the folder, this permission is inherited.

Depending on the nature of the information being held, alternate permission schemes may be needed. Achieving the desired scheme may require some additional folders and more complex permission sets. You may also need some additional groups so as to segregate users based on the desired level of security. And rather than giving users Full Control access (which enables them to change permissions), granting them Modify permissions may be adequate for their business needs.

However you choose to implement permissions for folders like this, setting the necessary permissions is made much easier by the NTFSSecurity module.

Viewing Permissions on the Folder

With the folder and file ACLs configured, you can verify the ACLs that result from these configuration steps. You can check the ACL on the folder using Get‐NTFSAccess, as follows:

# 12. Get ACL of folder 
 
Get-NTFSAccess -Path C:\Secure1 |
  Format-Table -AutoSize

Figure 5.16 shows the output. As you can see, the folder now has no inherited permissions—only the permissions you have set explicitly.

**Figure 5.16:** Viewing the ACL of the folder

Viewing Permissions on the File

As a final step, you can view the ACL on the file itself, as follows:

# 13. Get ACL of the file
Get-NTFSAccess -Path C:\Secure1\Secure.Txt |
  Format-Table -AutoSize

Figure 5.17 shows the output of this snippet.

**Figure 5.17:** Viewing the ACL of the file

This output shows the ACLs you have configured in this section. These ACLs give the necessary permissions to both the Domain Admins and members of the Sales Universal group.

In this section, you created a file folder on SRV1 and a file in that folder on which you set explicit ACLs. To achieve this, you ensured that you had the relevant modules loaded on SRV1, and you created a Universal group that holds the members of the Sales group. The steps shown did not add any users to the Sales group; that is easy enough to do, as shown in Chapter 3, “Managing Active Directory.”

Also, this section created a Universal user group. If you are to have multiple domains and especially if you are creating groups that utilize a cross‐forest trust, you might consider using a Domain Local group.

The commands in the NTFSSecurity module make it easier to manage ACLs on NTFS files and folders.

Managing Storage Replica

Storage Replica (SR) is a feature of Windows Server that replicates storage volumes between servers to support disaster recovery. Both the Standard and Data Center editions of Windows Server 2019 support SR. However, with Windows Server 2019 Standard Edition, SR can replicate only a single volume of 2TB (or less). Data Center edition has no specific limitations.

SR can replicate from any storage type to any other storage type. You can replicate spinning disks, SSDs, and iSCSI and Fiber Channel LUNs. For an overview of Storage Replica, see docs.microsoft.com/en-us/windows-server/storage/storage-replica/storage-replica-overview.

Before You Start

In this example you use three hosts. SRV1 and SRV2 are domain‐joined hosts. In “Managing Disk and Volumes,” you added two disk drives to SRV1 and made them available for use. You also make use of DC1, the domain controller for the Reskit.Org domain.

To demonstrate SR, both SRV1 and SRV2 require extra disks. You added two disks and created the necessary volumes for SRV1 in “Managing Disks and Volumes.” For SRV2, you can create the necessary disks, add them to the SRV2 virtual machine, and then format them as follows:

# 0. Add VHDs to SRV2 VM
#    Run this on the Hyper-V VM Host
# Stop the vm
Stop-VM -Name SRV2
# Get File location for the disk in this VM
$VM = Get-VM -VMName SRV2
$Par = Split-Path -Path $VM.HardDrives[0].Path
 
# Create two VHDx for G and H on SRV2
$NewPath1 = Join-Path -Path $par -ChildPath FDrive.VHDX
$NewPath2 = Join-Path -Path $Par -ChildPath GDrive.VHDX
$D1 = New-VHD -Path $NewPath1 -SizeBytes 128GB -Dynamic
$D2 = New-VHD -Path $NewPath2 -SizeBytes 128GB -Dynamic
 
# Add a new SCSI Controller to SRV2
$C = (Get-VMScsiController -VMName SRV2).count
Add-VMScsiController -VMname SRV2
 
# Add first disk to SRV2 VM
$HDHT = @{ 
  Path               = $NewPath1
  VMName             = 'SRV2'
  ControllerType     = 'SCSI'
  ControllerNumber   = $C
  ControllerLocation = 0 
}
Add-VMHardDiskDrive @HDHT   # Add 1st disk to vm
# Add Seconf disk to VM
$HDHT.Path               = $NewPath2
$HDHT.ControllerLocation = 1
Add-VMHardDiskDrive @HDHT   # Add 2nd disk to VM
Start-VM -VMName SRV2 
 
# After restart, run this on SRV2 as reskit\administrator
 
Get-Disk | 
  Where-Object PartitionStyle -eq Raw |
    Initialize-Disk -PartitionStyle GPT 
$NVHT = @{
  DiskNumber   = 1 
  FriendlyName = 'Storage(F)' 
  FileSystem   = 'NTFS' 
  DriveLetter  = 'F'
}
New-Volume @NVHT  # Add 1st new disk
$NVHT.DiskNumber   = 2
$NVHT.FriendlyName = 'Log'
$NVHT.DriveLetter  = 'G'
New-Volume @NVHT  # Add 2nd new disk
 
###

With this snippet, you add two new disks to SRV2 and format the disks. With this and the configuration you set in “Managing Disks and Volumes,” you now have two VMs with two additional disk drives that you have formatted using the NTFS filesystem.

Creating Content on F:

You start this exploration of SR by logging on to SRV1 as a domain administrator. Then you create some content on SRV1, as follows:

# 1. Create Content on F:
1..100 | ForEach-Object -Parallel {
  $NF = "F:\CoolFolder$_"
  New-Item -Path $NF -ItemType Directory | Out-Null
  1..100 | ForEach-Object {
    $NF2 = "$NF\CoolFile$_"
    "Cool File" | Out-File -PSPath $NF2
  }
}

This snippet creates 100 folders within the recently created F: drive and inside each folder creates 100 files, each with a tiny bit of content. This creates some data to be replicated using Storage Replica—not a large amount of data but enough for basic testing. If you are considering deploying Storage Replica, you may want to do performance testing; in that case, you would create a source volume of the size appropriate for your environment.

This snippet uses a new PowerShell 7 feature, Foreach‐Object's new parameter ‐Parallel. In testing, using this switch reduces the run time of this snippet from around 17 seconds to less than 10 seconds. By default, PowerShell 7 runs five parallel operations at once, but you can adjust that by using the ‐Throttlelimit parameter. On most modern multicore systems, the default throttle limit is probably a good starting point. Depending on your hardware, you might choose to increase the throttle limit for improved performance. On a dual processor (each with six cores), setting the throttle limit to 12 improves performance.

Measuring the New Content

Having created content on F:, you measure the files/folders contained in the created content, as follows:

# 2. Measuring New Content on F:
Get-ChildItem -Path F:\ -Recurse | Measure-Object

Figure 5.18 shows the output of this cmdlet.

This is useful to verify the created content. As you can see, there are 10,100 items on F:. This consists of 100 folders plus 10,000 files, or 100 files in each folder.

Checking Content on the Target

In this exercise we plan to replicate data from SRV1 to SRV2, using SR. Before setting this up, check to see what is on the F: drive on SRV2, as follows:

# 3. Examine the same drives remotely on SRV2
$SB = {
  Get-ChildItem -Path F:\ -Recurse |
    Measure-Object
}
Invoke-Command -ComputerName SRV2 -ScriptBlock $SB

Figure 5.19 shows the output of this snippet. Since the drive on SRV2 has not been used, there are no files on the drive.

**Figure 5.19:** Viewing the content of `SRV2`

Adding the Storage Replica Feature to the Source

The SR feature is not installed by default but is easy to install, as follows:

# 4. Add Storage Replica feature to SRV1
Import-Module ServerManager
Install-WindowsFeature -Name Storage-Replica -IncludeManagementTools

You can see the output of this command in Figure 5.20.

**Figure 5.20:** The result of adding SR to `SRV1`

In the figure, you see a warning message that Import‐Module produces when it loads any module using the Windows PowerShell compatibility mechanism described in Chapter 2, “PowerShell 7 Compatibility with Windows PowerShell.” You can, as you see in other code fragments in this book, use the ‐WarningAction parameter to avoid seeing this warning.

Restarting the Source

With the installation of the SR feature completed, you need to reboot the server to finalize the installation, using Restart‐Computer as follows:

# 5. Restart SRV1 to finish the installation process
Restart-Computer

Adding Storage Replica to the Target

When you set up a Storage Replica partnership, you need to have the Storage Replica feature installed on both the source and target systems, in this case SRV1 and SRV2. You next add the feature, remotely, to SRV2 with the Install‐WindowsFeature command.

# 6. Add SR Feature to SRV2 Remotely
$SB = {
  Install-WindowsFeature -Name Storage-Replica | Out-Null
}
Invoke-Command -ComputerName SRV2 -ScriptBlock $SB

Restarting the Target

As with SRV1, you need to restart SRV2 to finalize the installation of SR on that server.

# 7. Restart SRV2 and wait for the restart
$RSHT = @{
  ComputerName = 'SRV2'
  Force        = $true
}
Restart-Computer @RSHT -Wait -For PowerShell

This snippet restarts SRV2 and waits until the reboot has completed and connectivity to the server is available (using PowerShell). In some cases, it appears that the Restart‐Computer cmdlet takes a long time to complete (even though the reboot has been completed). If you can verify that the reboot is complete (for example, by logging into SRV2), then you can stop this command (using Ctrl+C) and move on to the next step.

Testing the Configuration of SR

You now have the Storage Replica feature installed on the two servers, the necessary disk volumes established, and the source disk populated with content. With this in place, you can test the validity of an SR partnership between these two servers. You can do this from SRV1 using the Test‐SRTopology cmdlet, as follows:

# 8. Test Replica on SRV2 from SRV1
Import-WinModule -Name StorageReplica -WarningAction SilentlyContinue
$TSTHT = @{
  SourceComputerName       = 'SRV1.Reskit.Org'
  SourceVolumeName         = 'F:' 
  SourceLogVolumeName      = 'G:'
  DestinationComputerName  = 'SRV2.Reskit.Org' 
  DestinationVolumeName    = 'F:'
  DestinationLogVolumeName = 'G'
  DurationInMinutes        = 15 
  ResultPath               = 'C:\Foo'
  Verbose                  = $true
  IgnorePerfTests          = $true
}
Test-SRTopology @TSTHT

Figure 5.21 shows the output.

The Storage Replica module is among those that PowerShell 7 does not support natively. But the commands in the module work when used with the Windows PowerShell compatibility mechanism described in Chapter 2.

**Figure 5.21:** Testing the SR configuration

As you can see, Test‐SRTopology performs the topology test and creates a report showing the test results. The report is generated as an HTML file in the ResultPath specified, in this case C:\Foo. The filename is created embedding the date and time of the test.

If you are using SR in production, it may be useful to perform routine testing of your SR infrastructure.

Viewing the Topology Test Report

You can view the report as follows:

# 9. View the Report
$File = Get-ChildItem C:\Foo\testsr* | 
          Sort-Object -Property LastWriteTime -Descending |
            Select-Object -First 1
Start-Process -Filepath $File

This snippet brings up the topology test report in a browser, as shown in Figure 5.22. The report consists of two parts. At the top of the report, you see an overview of results; in this case the overall topology test was successful. Then, you see detailed test results for each of the 20 specific tests that the command ran to diagnose the potential SR partnership. This snippet also displays only the most recent report.

One test that the Test‐SRTopology command runs is to ensure you have adequate memory. If you created your SRV1 VM with low memory, you may see an error or warning. In that case, consider increasing the amount of memory allocated to the VM.

**Figure 5.22:** Viewing topology test results

The Test‐SRTopology cmdlet can also evaluate the likely performance of the partnership, although in the snippet here, this test was omitted. If you are using Storage Replica to replicate volumes across a WAN, this testing should be done to ensure performance meets your requirements.

You might also consider running these topology tests on a frequent basis if Storage Replica forms a part of your disaster recovery strategy.

Creating a Storage Replica Partnership

Given that the test in the previous section was successful, you can now set up a Storage Replica partnership with the New‐SRPartnership command as follows:

# 10. Create an SR Replica Partnership
$SRHT = @{
  SourceComputerName       = 'SRV1'
  SourceRGName             = 'SRV1RG'
  SourceVolumeName         = 'F:'
  SourceLogVolumeName      = 'G:'
  DestinationComputerName  = 'SRV2'
  DestinationRGName        = 'SRV2RG'
  DestinationVolumeName    = 'F:'
  DestinationLogVolumeName = 'G:'
  LogSizeInBytes           = 2gb
}
New-SRPartnership @SRHT -Verbose

You can see the results of running this code in Figure 5.23.

**Figure 5.23:** Creating an SR partnership

As you can see, there is not much information returned when an SR partnership is created successfully.

With the SR partnership in place, Storage Replica is now able to replicate the data from SRV1 to SRV2. The initial synchronization time is dependent on the total amount of data to be transferred. Once the drive is synchronized initially, any changes to the source volume are replicated to the target volume on the other server.

Viewing the Partnership

You can view the just‐created SR partnership using Get‐SRPartnership as follows:

# 11. View the SR partnership
Get-SRPartnership

Figure 5.24 shows the output of this command.

**Figure 5.24:** Viewing the SR partnership

We can see the source and target systems and volumes in use in the partnership. The output from this step is essentially the same output you observed when creating the SR partnership.

Examining Volumes on the Target

With the SR partnership established, you can look to see what is on the F: volume on SRV2, as follows:

# 12. Examine the same drives remotely on SRV2
$SB = {
  Get-Volume |
    Sort-Object -Property DriveLetter |
      Format-Table   
}
Invoke-Command -ComputerName SRV2 -ScriptBlock $SB

Figure 5.25 shows the output of this snippet.

**Figure 5.25:** Examining volumes on SRV2

As you can see, the F: partition/drive on SRV2 is not available as a volume. The partition is locked by Storage Replica, which means you cannot access it as a usable file storage volume so long as SR is using it as a replication target. Even though you can't see any files, Storage Replica continues to monitor the F: partition/drive on SRV1 and replicate it to SRV2.

Reversing the Replication

Even though the target volume in an SR partnership is not viewable or accessible, Windows Server is constantly replicating any content update.

As part of recovering from a disaster, you may need to reverse the replication and have Windows replicate from SRV2 to SRV1. If you do this, Storage Replica makes the F: volume on SRV2 viewable while making the new target volume on SRV1 unviewable. You reverse the replication as follows:

# 13. Reverse the replication
$SRHT2 = @{ 
  NewSourceComputerName   = 'SRV2'
  SourceRGName            = 'SRV2RG' 
  DestinationComputerName = 'SRV1'
  DestinationRGName       = 'SRV1RG'
  Confirm                 = $false
}
Set-SRPartnership @SRHT2

Viewing Updated Replication Group Status

With the replication reversed, you can view the status of the replication partnership, as follows:

# 14. View SR Partnership on SRV1
Get-SRPartnership

You can see the results of this command in Figure 5.26.

**Figure 5.26:** Examining updated RG status

This output shows that SR is now replicating from SRV2 to SRV1. This means the files are available on SRV2 but are not visible as files on SRV1.

Examining SRV2 Volumes

With the replication reversed, you can examine the disks and the replicated content available on SRV2, as follows:

# 15. Examine the same drives remotely on SRV2
$SB = {
  Get-Volume |
    Sort-Object -Property DriveLetter |
      Format-Table 
    Get-ChildItem -Path F:\ -Recurse | Measure-Object |
      Format-List
        
}
Invoke-Command -ComputerName SRV2 -ScriptBlock $SB

You can see the output of this snippet in Figure 5.27.

**Figure 5.27:** Examining volumes on SRV2

The F: drive is now available on SRV2 and healthy. Additionally, you can see that this drive now has the same 10,100 total items.

This section has demonstrated the ease with which you can use Storage Replica as part of a disaster‐recovery implementation. As you have seen, you cannot use the data on the SR target while the SR is replicating (or able to replicate).

Managing Filestore Quotas

The File Server Resource Manager (FSRM) is a Windows Server feature that helps you to manage file servers. FSRM allows you to implement quotas on file stores, perform a variety of file management tasks, perform file screening, and offer in‐depth reporting. For an overview of FSRM, see docs.microsoft.com/windows-server/storage/fsrm/fsrm-overview.

In this section, you install the FSRM feature and use FSRM's quota management capability to set and test these quotas.

Before You Start

This section uses three servers (VMs), SRV1, SRV2, and DC1, which you have used in other sections of this chapter. You run the snippets in this section on SRV1. This Windows Server 2019 host has PowerShell 7 loaded.

FSRM features include the ability to send email, for example when a user has exceeded a filestore quota or has attempted to store a file of a particular file type (for example, an MP3 music file) prohibited via FSRM file screening.

To test FSRM email functionality, you need an SMTP server that FSRM uses to send email. In this section, you also use SRV1 as the SMTP server (or relay).

For testing purposes in this chapter, you have alternatives with respect to the email server. If you have an internal SMTP server, then you can change the FSRM settings accordingly.

If you do not have access to an SMTP server, an option is to install IIS with the SMTP server on SRV1 and use it as an SMTP relay to an SMTP smart host. One free relay service that many IT pros have used is offered by SendGrid.com. With the free service, you can send up to 100 emails per day, which should be more than adequate to test FSRM. To assist you in setting up this service, use //tfl09.blogspot.com/2020/04/setting-up-smtp-relay-using-sendgrid.html.

The example emails shown in this section were sent via the SMTP relay on SRV1 to SendGrid.com, which then forwarded them onward. This is an excellent solution for testing. However, in production, you would configure FSRM with different settings to send mail to an internal mail server.

Installing the FS Resource Manager Feature

The FSRM feature is not deployed by default. You add it in the same way as other Windows Server features, as follows:

# 1. Install FS Resource Manager feature on SRV1
Import-Module -Name ServerManager -WarningAction 'SllentlyContinue' 
$IHT = @{
  Name                   = 'FS-Resource-Manager' 
  IncludeManagementTools = $True
  WarningActtion         = 'SilentlyContinue'
}
Install-WindowsFeature @IHT

Figure 5.28 shows the output from this step.

Setting Up SMTP Settings for FSRM

FSRM can be configured to send email when important filesystem events occur. Now that you have installed the FSRM feature, you configure the email settings as follows:

# 2. Set SMTP settings in FSRM
$MHT = @{
  SmtpServer        = 'SRV1.Reskit.Org'  
  FromEmailAddress  = 'FSRM@Reskit.Org'
  AdminEmailAddress = '
Doctordns@Gmail.Com
'
}
Set-FsrmSetting @MHT

This snippet tells FSRM to send email to an SMTP server on SRV1. You should adjust these details if you can send mail via another SMTP server. Ensure that you are able to send email via your configured server before continuing.

Also, you should change the admin email address, unless you want to send the book's author email.

Sending a Test Email

To check your SMTP settings, you can get FSRM to send a test email using the email settings you just configured, using Send‐FsrmTestEmail.

# 3. Send a test email to check the setup
$MHT = @{
  ToEmailAddress = 'DoctorDNS@gmail.com'
  Confirm        = $false
}
Send-FsrmTestEmail @MHT

This snippet sends a test email to the configured email address, using the SMTP server on SRV1.Reskit.Org. Although the snippet produces no visible output, you can see the email sent in Figure 5.29. If for some reason FSRM is not able to connect to the SMTP server, you would see an error 0x8004531c. In that case, you need to troubleshoot your SMTP server.

If you intend to utilize FSRM's email features, you need to ensure the FSRM email settings are working before proceeding. And you need to ensure that the remote SMTP server is online, is reachable, and is processing email. Some ISPs do not allow customers to use SMTP gateways such as SendGrid. Configuring and troubleshooting SMTP email is outside the scope of this book. If you get stuck, consider asking for help in the Spiceworks PowerShell forum at community.spiceworks.com/programming/powershell. Or just continue and omit using FSRM's email features.

Creating an FSRM Quota Template

FSRM implements templates for quotas that you can use to apply specific quota permissions. Several are built in, and you can create your own FSRM quota template that preconfigures some FSRM quota settings. Doing so allows you to create a filestore quota at any later time based on a template. You can create a new template as follows:

# 4. Create a new FSRM quota template for a 10MB hard limit
$QHT1 = @{
  Name        = '10 MB Reskit Quota'
  Description = 'Filestore Quota (10mb) For'
  Size        = 10MB
}
New-FsrmQuotaTemplate @QHT1

This snippet creates a new FSRM quota template.

Viewing Available FSRM Quota Templates

FSRM ships with a number of quota templates, and you can add or modify templates to suit your needs. You can view all the available FSRM quota templates with the Get‐FsrmQuotaTemplate command.

# 5. View available FSRM quota templates
Get-FsrmQuotaTemplate |
  Format-Table -Property Name, Description, Size, SoftLimit

You can see the output of this snippet in Figure 5.30.

**Figure 5.30:** Viewing quota templates

Creating a New Folder

To test FSRM quotas, you create a new folder, as follows:

# 6. Create a new folder on which to place quotas
If (-Not (Test-Path C:\Quota)) {
  New-Item -Path C:\Quota -ItemType Directory  |
    Out-Null
}

With this folder created, you can complete the actions necessary to protect the folder with an FSRM quota.

Building an FSRM Action

An FSRM action is an in‐memory object that contains details of an action you want FSRM to take when a quota threshold is exceeded. You create an action before creating the FSRM quota, as follows:

# 7.  Build an FSRM Action
$Body = @'
User [Source Io Owner] has exceeded the [Quota Threshold]% quota 
threshold for the quota on [Quota Path] on server [Server].  
The quota limit is [Quota Limit MB] MB, and [Quota Used MB] MB 
currently is in use ([Quota Used Percent]% of limit).
'@ 
$NAHT = @{
  Type      = 'Email'
  MailTo    = 'Doctordns@gmail.Com'
  Subject   = 'FSRM Over limit [Source Io Owner]'
  Body      = $Body
}
$Action1 = New-FsrmAction @NAHT

This FSRM action is used to send email to DoctorDNS@Gmail.Com with a body containing details of the quota exceeded. The email body contains a number of variables and is customizable. For details of the variables you can use in an Email body, see docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc788122%28v%3dws.10%29#quota-notification-variables.

This action is created in memory and as such is not persisted anywhere. Also, there is no Get‐FSRMAction cmdlet.

Create an FSRM Threshold

You next build an FSRM threshold. The threshold, which is another in‐memory object, contains a threshold percentage and an action. You create the threshold object as follows:

# 8. Create an FSRM threshold 
$Thresh = New-FsrmQuotaThreshold -Percentage 85 -Action $Action1

This threshold object, when later added to an FSRM quota, instructs FSRM to do the action in $action1 when the usage exceeds 85% of the quota.

Note that the FSRM threshold and the FSRM action are in‐memory objects and do not persist across a reboot or into another PowerShell session. You use these objects as part of creating an FSRM quota.

Building an FSRM Quota

To build a persistent FSRM quota, you use the New‐FSRMQuota cmdlet, like this:

# 9.  Build a quota for the folder
$NQHT1 = @{
  Path      = 'C:\Quota'
  Template  = '10 MB Reskit Quota'
  Threshold = $Thresh
}
New-FsrmQuota @NQHT1

You can view the output of this snippet in Figure 5.31.

This code tells FSRM to impose a 10MB quota on C:\Quota. Additionally, when the usage of the folder exceeds 85% (8.5MB), FSRM sends email to the user who exceeds the threshold. In this case, the quota uses the specified template, which provides you with flexibility. You could have just specified a limit (such as 10MB).

Test the 85% Quota Threshold

Now that you have set up an FSRM quota, based on a template, you can test the quota. Here is one way to test it:

# 10. Test the 85% SOFT quota limit on C:\Quota
Get-ChildItem -Path C:\Quota -Recurse | 
  Remove-Item -Force # for testing purposes!      
$S = '+'.PadRight(8MB)
# make a first file - under the soft quota
$S | Out-File -FilePath C:\Quota\Demo1.Txt
$S2 = '+'.PadRight(.66MB)
# Now create a second file to take the user over the soft quota
$S2 | Out-File -FilePath C:\Quota\Demo2.Txt

In this snippet, you first ensure that the folder is empty and then create a file ( Demo1.Txt) that is smaller than the quota threshold. You then create a second file ( Demo2.txt) that exceeds the soft quota threshold but does not use all of the quota. Because this snippet did not exceed the full 10MB quota limit, there is no direct output. Once a user exceeds a threshold, FSRM sends an email as you previously configured.

Examining the FSRM Email

In the previous step, you created two files. The first was within the threshold, but creating the second took you over the 85% soft quota threshold. Because you exceeded the soft threshold, FSRM sends an email, which you can see in Figure 5.32.

The output tells you which user has exceeded which quota. The mail also tells you the current maximum quota limit and how much is presently in use.

Testing the Hard Quota Limit

With a soft quota, a user can exceed the quota and save extra data. You can also create hard quota limits; for example, a hard quota limit on the C:\Quota folder of 10MB. With such a hard quota, any attempt to use more than the quota fails. You can test this by creating another large file in the C:\Quota folder, as follows:

# 11. Test hard limit quota
$S | Out-File -FilePath C:\Quota\Demo3.Txt

**Figure 5.32:** Examining the FSRM email

This step does two things. First FSRM generates an error message, shown in Figure 5.33.

**Figure 5.33:** Testing the quota limit

The error message says that there is not enough space in the drive even though the actual error is that the quota has been fully used. If you are used to Windows PowerShell, the figure shows you PowerShell 7's new error reporting feature, which simplifies what you see when errors occur in your scripts or when running commands as in this case.

Note that error display in PowerShell differs from Windows PowerShell. You also get slightly different output if you run a line of code directly at the console or if you run it via a script file (or highlight the line of code with VS Code and run the selection). When run as a script, PowerShell provides details of where the error occurred.

The second thing that happens is that the Out‐File option creates a new file, Demo3.Txt. But Windows only writes away contents that do not exceed the quota—the file is truncated to ensure that the folder does not exceed the hard quota.

Viewing the Folder Contents

Although you attempted to create Demo3.Txt to be the same size as Demo1.Txt, there is insufficient quota left. You can see the total size of all three files, as follows:

# 13. View Folder
Get-ChildItem -Path C:\Quota |
   Measure-Object -Sum -Property Length

Figure 5.34 shows the output from this step.

**Figure 5.34:** Viewing the total size of the folder contents

As you can see, the total amount of space used by the three files you created in C:\Quota does not exceed the 10MB quota you assigned.

Managing File Screening

FSRM's file screening controls the types of files you allow to be stored on your file server. You could, for example, define a file screen to prohibit music files (files with the .FLAC or .MP3 extension) to be saved to your file server. If a user attempts to download and save a file such as GD71‐02‐18.T09.FLAC, FSRM stops the user from saving the file.

To configure FSRM file screening, you need to specify the folder to be screened and a file screen template that describes the file characteristics of files that FSRM should block. FSRM comes with five built‐in file screen templates. You can create further templates to suit your requirements.

A file screen template contains a set of file groups, in which each file group defines a set of file extensions to block. FSRM comes with 11 built‐in file groups that cover common content types and can be updated and extended.

One built‐in FSRM file group is Audio and Video Files. This group, for example, includes a wide variety of audio and video file extensions, including .AAC, .MP3, .FLAC, and more. Interestingly, this built‐in file group does not block .SHN (Shorten) files. Shorten is a lossless compression algorithm that was in effect replaced by .FLAC files but is much loved in music trading circles. You could easily add this extension to the relevant file group, should you wish.

Note that file screening works solely on the basis of file extensions. FSRM would block you saving a file such as GD71‐02‐18.T09.FLAC. However, if you stored that same file as GD71‐02‐18.T09.CALF, FSRM would allow the file to be stored. The FSRM file screening does not examine the file to ascertain the actual file type. A user who attempts to get around a corporate file screen ban using this technique can be disciplined more harshly for deliberately and willfully violating company security.

Before You Start

This section uses the domain‐joined server SRV1.Reskit.Org, which has FSRM installed and configured. You set up FSRM on SRV1 in the “Managing Filestore Quotas” section.

Examining Existing FSRM File Groups

When you install FSRM (in “Managing Filestore Quotas”), the default installation creates a set of file groups you can use when you set up file screening. You can use Get‐FsrmFileGroup to view the existing file groups.

# 1. Examine the existing file groups
Get-FsrmFileGroup |
  Format-Table -Property Name, IncludePattern

Figure 5.35 shows the output of this snippet.

As you can see, there is a useful set of file groups you can use to set up file screening.

There is a lot of information being output from this snippet, so you may need to adjust the width of your PowerShell console or VS Code to see the full output (and avoid PowerShell truncation). Also, consider changing the value of the default variable $PSFormatEnumerationLimit to see more of the file patterns.

Examining the Existing File Screen Templates

The default installation of FSRM also creates a number of file screening templates, which you can view using Get‐FsrmFileScreenTemplate as follows:

# 2. Examine existing File Screen templates
Get-FsrmFileScreenTemplate |
  Format-Table -Property Name, IncludeGroup, Active

You can see the output in Figure 5.36.

**Figure 5.35:** Examining the existing file groups

**Figure 5.36:** Examining existing templates

This snippet shows you the name of each of the five built‐in templates and, for each template, what file groups are included in the template and whether the screen template represents an active file screen.

Creating a New File Folder

To test file screening, you create a new folder, C:\FileScreen, as follows:

# 3. Create a new folder
$Path = 'C:\FileScreen'
If (-Not (Test-Path -Path $Path)) { 
  New-Item -Path $Path -ItemType Directory  |
    Out-Null
}

If the folder does not exist, this snippet creates it.

Creating a New File Screen

You create a file screen that blocks executable files from being saved to the folder C:\FileScreen, as follows:

# 4. Create a new file screen
$FSHT =  @{
  Path         = $Path
  Description  = 'Block Executable Files'
  IncludeGroup = 'Executable Files'
}
New-FsrmFileScreen @FSHT

You can view the output of this snippet in Figure 5.37.

The output indicates that this file screen is active and identifies what it is screening (executable files in C:\Filescreen).

Testing File Screening

Now that you have set up the file screening, you can test it. One simple way to test the screen is to copy an executable file (such as the Windows notepad.exe program) into the protected folder. You can test this as follows:

# 5. Test file screen by copying notepad.exe
$FSTHT = @{
  Path        = "$Env:windir\notepad.exe"
  Destination = 'C:\FileScreen\notepad.exe'
}
Copy-Item  @FSTHT

You can see the error output from this command in Figure 5.38.

As you can see, FSRM found that the extension of the file to be saved is one that has been blocked. As a result, Windows displays an error message and does not complete the file copy.

Setting Up an Active File Screen

An active file screen is one that carries out an action (in addition to blocking the “wrong” files). FSRM can, for example, allow you to send an email message when the file save fails.

You set up an active file screen as follows:

# 6. Setup Active Email Notification
$Body = "You attempted to save an executable program. " +
        "This is not allowed."  
$FSRMA = @{
  Type             = 'Email'
  MailTo           = "[Admin Email];[File Owner]" 
  Subject          = "Warning: attempted to save an executable file" 
  Body             = $Body
  RunLimitInterval = 60
}
$Notification = New-FsrmAction @FSRMA
$FSFS = @{
  Path         = $Path
  Notification = $Notification
  IncludeGroup = 'Executable Files'
  Description  = 'Block any executable file'
  Active       = $true
}
Set-FsrmFileScreen @FSFS

In this snippet, you create an FSRM action to send an email message. Then you update the FSRM file screen to include the notification. The file screen now prevents executable files from being saved and sends an email message if a user attempts to save an executable file in the protected folder.

Viewing Notification Limits

Depending on how often screening or other limits are exceeded, the number of alerts and email can be an issue. On a busy FSRM file server, you could quickly generate large amounts of alerts or email. To minimize this, FSRM allows you to specify a period of time before another notification of the same type is sent. The default time is 60 minutes, but you can change that. To view the current limits, you can use the Get‐FsrmSetting command.

# 7. Get-FSRM Notification Limits
Get-FsrmSetting | 
  Format-List -Property "*NotificationLimit"

Figure 5.39 shows the output from this snippet.

**Figure 5.39:** Viewing notification limits

Changing Notification Limits

To change any of these notification limits, you use the Set‐FSRMSetting command, like this:

# 8. Changing FSRM notification limits  
$FSRMSHT = @{
  CommandNotificationLimit = 1
  EmailNotificationLimit   = 1
  EventNotificationLimit   = 1
  ReportNotificationLimit  = 1
}
Set-FsrmSetting @FSRMSHT

This limit allows you to test your file screens and perhaps refine the email messages generated. In production, such low limits may result in an excessive number of emails, which may be undesirable.

Testing the Active File Screen

To test this file screen, you can repeat the attempt to save an executable file in the screened folder, as follows:

# 9. Re-test the file screen to check the action
Copy-Item @FSTHT

As in the earlier test of this file screen, FSRM prevents you from saving the executable file, as you can see in Figure 5.40.

**Figure 5.40:** Testing the active file screen

Viewing Active File Screen Email

You can see the file screen email sent by FSRM in the previous step in Figure 5.41.

The body of the message, as you have seen in “Managing Filestore Quotas,” can be highly customized with a variety of additional FSRM variables to provide more information for both the user and the administrator.

**Figure 5.41:** Viewing the screening email

Summary

PowerShell 7 enables you to manage disks and disk volumes on a variety of physical and virtual media. There are some built‐in commands for managing NTFS permissions that can be supplemented with the community‐developed NTFSSecurity module. For disaster recovery, PowerShell 7 supports and simplifies the use of the File System Resource Manager. FSRM provides a lot of assistance to customers using Windows Server to deliver file server features to users, and these are straightforward to use via PowerShell. They enable you to implement filestore quotas and filestore screening.

Some of the modules used in this chapter are not natively supported using PowerShell 7. As this chapter demonstrates, that does not provide a significant barrier to adoption.