PowerShell for File Management (Part 5)

If you would like to read the other parts in this article series please go to:

• PowerShell for File Management (Part 1)
• PowerShell for File Management (Part 2)
• PowerShell for File Management (Part 3)
• PowerShell for File Management (Part 4)
• PowerShell for File Management (Part 6)

In my previous article in this series, I delved a little bit into the File Server Resource Manager. For those who are not familiar with the File Server Resource Manager, it is a Windows Server tool that allows for quota, file, and storage management. One of the really nice things that the File Server Resource Manager can do is to create a file screen. In this article, I will show you how it’s done.

The basic idea behind a file screen is really simple. As an administrator, there are certain types of data that you probably expect your users to save in certain places. For example, it’s really common for a user’s Documents folder to contain Microsoft Office document files and PDF files. At the same time, there are also types of files that should never exist in certain file locations. For instance, there probably isn’t a legitimate reason why a user would ever need to store an executable file in their Documents folder. This is where file screens come into play. A file screen allows you to block specific data types from being stored in specified locations.

The nice thing about creating file screens is that Microsoft does most of the work for you. I spent quite a bit of time in the previous article discussing file groups and file templates. File screens are based on these components. So let’s take a look at how file screens work.

If you were to create a file screen through the GUI by using the File Server Resource Manager, you would be required to populate the fields shown in the figure below.

This is the interface used to create file screens.

As you can see in the path, a file screen consists of a path and a template. In this particular case, audio and video files would be blocked from being stored in whatever folder was specified in the File Screen Path field. So let’s take a look at how we could accomplish the same thing using PowerShell.

The first thing that we would need to do is to use the Get-FsrmFileScreenTemplate cmdlet to retrieve a list of the templates that exist on the server. Technically this isn’t a required step, but I like to use it because when you create a file screen, you have to enter the template name exactly. Retrieving a template list helps you to avoid the frustration of typing the template name almost correctly.

The cmdlet used to create a file screen is New-FsrmFileScreen. The cmdlet’s syntax is as follows:

New-FsrmFileScreen -Path “<file screen path>” -Template “<FRRM file screen template name>”

So now that you know the basic cmdlet syntax, let’s suppose that we want to block audio and video files from a folder named C:\Demo. The command used to do so would be:

New-FsrmFileScreen -Path “C:\Demo” -Template “Block Audio and Video Files”

You can see what this process looks like in the figure below:

This is how you create a FSRM file screen.

OK, so what if we needed to inspect the FSRM file screens that exist on an unfamiliar file server? Well, that’s actually really easy to do. Entering the Get-FsrmFileScreen cmdlet without any additional parameters will cause PowerShell to display all of the FSRM file screens that exist on the server.

But what if instead, we needed to confirm the existence of a file screen for a particular path? In that type of situation, we would still use the Get-FsrmFileScreen cmdlet, but we would append the -Path parameter along with the path that we wanted to verify. For example, if you wanted to inspect the C:\Demo path, then the command for doing so would be:

Get-FsrmFileScreen -Path “C:\Demo”

You can see what this looks like in the figure below.

You can use the Get-FsrmFileScreen cmdlet to verify the existence of a file screen.

Although it is helpful to be able to check to see which (if any) file screens apply to a specific folder, you may find yourself needing to verify a file screen’s existence based on other criteria. Let’s pretend for a moment that for whatever reason you need to know every path to which the Block Audio and Video Files template has been applied.

Unfortunately, there is no built-in parameter for searching an entire file server to see where a template has been used. However, you can use the Get-FsrmFileScreen cmdlet to retrieve a list of all of the file screens that exist on a server, and then pipe the output into the Where-Object cmdlet. The Where-Object cmdlet lets you filter the output based on specific attributes.

If you look at the figure above, you will notice that the command’s output is divided into two columns. The column on the left lists the names of the various attributes that are associated with the FSRM file screen. Any of these attributes can be used as a filter. Hence, you might filter the output based on template, or maybe notification.

So let’s go back to the question of how you could locate each folder to which the Block Audio and Video Files template has been applied. To accomplish this task, you could filter the output by template. The exact command is:

Get-FsrmFileScreen | Where-Object {$_.Template -eq “Block Audio and Video Files”

You can see the output in the figure below. Incidentally, the -EQ in the command stands for equals. In essence the filter is checking to see whether each file screen’s template name is equal to Block Audio and Video Files.

You can filter the output by template.

Hopefully, you can see how this sort of command could be helpful. The only real disadvantage to this command is that it still outputs a lot of data. Remember, the goal was to see which folders were associated with a specific template. Technically we answered that question, but the command also returned a lot of data that we aren’t interested in. This isn’t a problem in this case, because there is only one filter that exists. Imagine however, if there were dozens of folders that were associated with the template. The output would contain way too much information. Fortunately, we can easily fix this problem. Just use the same command as before, but append a pipe symbol and Select-Object Path. The output displays only the file paths that are associated with the specified template. You can see what this looks like in the next figure.

We can write the command in such a way that it returns only the file paths.

Final thought

Windows makes it easy to create and query file screens through PowerShell. Even so, there are several advanced options that you can use within your file screens. I will show you how to do so in the next article.

If you would like to read the other parts in this article series please go to:

• PowerShell for File Management (Part 1)
• PowerShell for File Management (Part 2)
• PowerShell for File Management (Part 3)
• PowerShell for File Management (Part 4)
• PowerShell for File Management (Part 6)