Jason Yoder, MCT

This is one that is sure to upset a few users.  This project came from one of my PowerShell classes. The client had a strict policy that only company issued USB storage devices may be used on company computers. Group Policy can help keep that requirement enforced.  They also had a policy that described the files types that can be stored on these USB drivers. The problem is that users were storing files that were not of the approved type.  So, what can PowerShell do in this situation? The code below allows the administrator to provide a list of computer names and a list of  file name patterns to look for.  They were particularly concerned about .exe files.  So the pattern for this would be “*.exe”.  Just be fore warned that code like this can be particularly upsetting to users.  Make sure that a well known acceptable usage policy is in place in your organization before unleashing this code on your people. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 2

As you continue to develop your skills in PowerShell, you will need to master the art of creating objects.  Objects are the result of your cmdlets efforts, packaged in a way that other cmdlets can use them.  A new feature to PowerShell V3 is the ability to create an object from a hash table.   This method may help with reducing the amount of typing required. 1 2 3 4 $Obj = [ PSCustomObject ] @{ 'Prop1' = "hello" ; 'prop2' = 'World' ; 'Prop3' =[ double ] 5 ; "Prop4" = $True }   Line 1 creates the variable $Obj that will store our object.   We set it equal to a hash table of type PSCustomeObject. The PSCustomeObject class is designed for this purpose.   We also add our first property called Prop1 with a value of hello .   The semicolon is used to separate properties.   We could have continued to type the remaining lines on line 1, but the use of the semicolon allows us to break up this single line into multiple line

This was a good question that came up in my Windows Server 2008 Fundamentals course.  The student needed to list all of the server roles on the local server and the services that each role utilizes for a collage class she was taking.  This was actually an easy one to resolve. Import-Module ServerManager Get-WindowsFeature -ErrorAction Stop |   Where-Object {( $_ . installed -eq $true ) -and ( $_ . SystemService -ne $Null )} |   Select-Object -Property Name , SystemService   This code requires the ServerManager module.  Since it was being executed on the local Windows 2008 R2 server, there was not an issue.  What about executing this code against remote clients? At this point, the code is only somewhat reusable.  One of my students worked in an environment of over 3000 servers. How could it be usable for him? The help file for Get-WindowsFeature does not show any built in remoting technology.  For this reason, we need to enable PowerShell Remoting.   PowerShell rem