So you’re interested in taking a peek at the global file transfer filter configuration settings used in your organization; to be a little more specific, you’d like to see all the file types (as determined by file extension) that users are not allowed to transfer to one another using Microsoft Lync. As it turns out, there’s a cmdlet – Get-CsFileTransferFilterConfiguration – designed to return that very information; all you have to do is type the following at the Windows PowerShell prompt and then press ENTER:

 

Get-CsFileTransferFilterConfiguration –Identity global

 

When you do that, you’ll see something like this:

 

Identity   : Global
Extensions : {.ade, .adp, .app, .asp...}
Enabled    : True
Action     : Block

 

Well, the command worked … we think. To be honest, though, we sort of expected to get back more than just four file extensions; after all, by default there are scores of file extensions blocked by Microsoft Lync Server 2010. And what’s the deal with the Extensions property; what’s with the curly braces and the three dots at the end?

 

Well, here’s the deal with the curly braces and the three dots at the end. First of all, the curly braces are PowerShell’s way of telling us that we’re dealing with a multi-valued property: a property that can contain more than one value. That should be fairly obvious just from looking at the Extensions property; after all, we can see that this property contains at least four values: .ade; .adp; .app; .asp. And if four values aren’t multiple values, well, we don’t know what is.

 

Ah, good catch: why did we say that the property contains “at least” four values? That’s where the three dots come into play. Any time you’re viewing PowerShell output and you see three dots like that you can bet dollars to doughnuts that there are actually more values stashed in that particular property; they just wouldn’t all fit onscreen.

 

Note. The phrase “dollars to doughnuts” means that you are 100% positive that something is true. Allegedly, the term came about from bettors who were so confident they had backed the right horse that they were willing to bet something valuable (dollars) against something totally worthless (doughnuts). To be honest, though, we don’t buy that story: who in their right mind would call a doughnut worthless?

OK, maybe those lemon-filled ones. But other than that ….

 

As it turns out, the default global file transfer filter configuration settings include more than 70 file extensions:

 

.ade
.adp
.app
.asp
.bas
.bat
.cer
.chm

 

Etc., etc. And that’s great. But how exactly do we see that complete list of file extensions?

 

Here’s one way:

 

Get-CsFileTransferFilterConfiguration –Identity global | Select-Object –ExpandProperty Extensions

 

What we’ve done here is retrieve all the file transfer filter configuration settings information and then piped that information to the Select-Object cmdlet. From there we used the –ExpandProperty parameter to “expand” the values found in the Extensions property. When you expand a property you simply show all the values stored in that property. In other words, the preceding command is going to give us output that looks like this:

 

.ade
.adp
.app
.asp
.bas
.bat
.cer
.chm

 

Which is exactly what we had in mind in the first place.

 

Now, with file transfer filter configuration settings, our multi-valued property (Extensions) stores a bunch of values (in this case, a bunch of string values). In other cases, however, a multi-valued property might store a whole bunch of objects. For example, suppose you run the cmdlet Get-CsTopology. One of the properties that gets returned is the Machines property; this property happens to store a bunch of computer objects:

 

Machines    : {Redmond:1-1, Redmond:2-1...}

 

So is this something you should worry about? Nope (well, not unless you like worrying). Instead, you should just sit back and let PowerShell worry about it for you. As it turns out, any time you have a multi-valued property that stores a bunch of objects PowerShell will automatically show all the property values of all those objects. For example, run this command from the Windows PowerShell prompt:

 

Get-CsTopology | Select-Object –ExpandProperty Machines

 

You should get back something that looks like this:

 

MachineId         : Redmond:1-1
Cluster           : Redmond:1
Fqdn              : atl-cs-001.litwareinc.com
PrimaryMacAddress : 71:43:48:99:35:ca
Topology          : Microsoft.Rtc.Management.Deploy.Internal.DefaultTopology
MachineId         : Redmond:2-1
Cluster           : Redmond:1
Fqdn              : atl-cs-001.litwareinc.com
PrimaryMacAddress :
45:29:38:41:15:ea
Topology          : Microsoft.Rtc.Management.Deploy.Internal.DefaultTopology

 

Not bad, eh?