In PowerShell v.2, remote access is available only to users who hold local administrator privileges. So, even if you do have appropriate remote access to a machine, , you cannot remotely access the system if you are not an Admin. This is not a technical limitation, though, just a safe default. You should use this line to change it :

Set-PSSessionConfiguration -Name Microsoft.PowerShell -showSecurityDescriptorUI

One easy way of creating lists of PC names or IP address ranges etc is a simple pipeline like this:

1..40 | Foreach-Object { ‘PC-W7-A{0:000}’ -f $_ }

Use the -f operator to format the number. In this example, it will always be three-digit.

‘Tom’, ‘Chris’, ‘Judy’, ‘Alan’ | Sort-Object

Input can come from a different command. If you’d like to get seven random lottery numbers, you should try this:

1..49 | Get-Random -Count 7 | Sort-Object

You’ll find that when you feed complex objects into Sort-Object, you should specify the object property you want to sort on (or else Sort-Object will pick one by itself):

Get-ChildItem $env:windir | Sort-Object Length

Here are some more examples:

Get-HotFix | Sort-Object InstalledOn

Get-ComputerRestorePoint | Sort-Object Description

Let’s start with some easy stuff..

Get the number of Public Folders

Get-PublicFolder -Recurse | Measure-Object

Get the sum / number of Mails / Object in all Public Folders

Get-PublicFolderStatistics | Measure-Object -Property ItemCount -Sum

Get the number of Mailboxes

Get-Mailbox | Measure-Object

Get the number of sent messages / emails within a date range

Get-MessageTrackingLog -Start "29.11.2009" -End "30.12.2009" -ResultSize Unlimited | Measure-Object

Ok, the goal is to have a 1gb large dummy file ..

first we declare a string variable called file:

PS C:\> $file = "$env:temp\dummyFile.txt"

no we create on object of type Io.File
PS C:\> $objFile = [io.file]::Create($file)

on the object, we call the void SetLength parameterized with 1gb 
PS C:\> $objFile.SetLength(1gb)

no we call the close method and the file is written
PS C:\> $objFile.Close()

using get-item $file we list the file we just created:

PS C:\> Get-Item $file Directory: C:\Users\<removed>\AppData\Local\Temp

Mode                LastWriteTime     Length Name
----                -------------     ------ ----
-a---        13.03.2010     14:07 1073741824 dummyFile.txt

PS C:\>

Ok, finally we can call an ii (Invoke-Item) to open the Path where the dummyFile resides in Windows Explorer.

To get the Path from a File, we can use Get-ChildItem (Get-ChildItems returns a FileInfo Object/Class). This object has a DirectoryName Property.

We declare an Object $path

$path = Get-ChildItem $file

Finally we call the mentioned ii (Invoke-Item) to open the path in Windows Explorer.

ii $path.DirectoryName

The complete Script

$file = "$env:temp\dummyFile.txt"
$objFile = [io.file]::Create($file)
$objFile.SetLength(1gb)
$objFile.Close()
$path = Get-ChildItem $file
ii $path.DirectoryName

If you have jobs that need to execute regularly, you can manage them with a PowerShell script and make it a scheduled task:

To create a scheduled task do.

schtasks /CREATE /TN CheckHealthScript /TR "powershell.exe -noprofile -executionpolicy Unrestricted -file %public%\checkhealth.ps1" /IT /RL HIGHEST /SC DAILY

To get a list of scheduled tasks / enumerate scheduled tasks do:

schtasks /query

Links

Running PowerShell Scripts as Scheduled Task

About Scheduled Tasks on MSDN

About Scheduled Tasks on Technet

Script to enumerate / list scheduled tasks on a list of servers..

$Version="v8.4.28 Aaron Dodd"
$Description="Generate CSV of scheduled tasks in the environment"

#------------------------------------------------------------------------------
# Process tasks
#------------------------------------------------------------------------------
ForEach ($Server in $ServerList) {
schtasks /QUERY /S $Server.Name /FO CSV /V > $TempReport
$TempCsv += Import-Csv $TempReport
}
Remove-Item $TempReport
$TempCsv | Export-Csv $FinalReport -notype
#----------------------------------------------------------------

found here => http://blog.geekpoet.net/2008/04/powershell-script-to-report-on-all.html

Now, we don’t need all the file, but all the files with a specific extension. We’ll use the Where-Object to achieve this. Well if you do Get-ChildItem you’ll get something like:

PS D:\DEMO> Get-ChildItem

    Directory: D:\DEMO

Mode                LastWriteTime     Length Name
—-                ————-     —— —-
d—-        19.02.2010     13:16            DEMO Folder
-a—        19.02.2010     13:17         18 someFile.ext

PS D:\DEMO>

So, how to get only files with a specific extension? Easy, using Get-Member we can list all properties of Get-ChildItem.

PS D:\DEMO> Get-ChildItem | Get-Member

   TypeName: System.IO.DirectoryInfo

Name                      MemberType     Definition
—-                      ———-     ———-
Mode                      CodeProperty   System.String Mode{get=Mode;}
Create                    Method         System.Void Create(System.Security.AccessControl.DirectorySecurity director…
…
…
Extension                 Property       System.String Extension {get;}
FullName                  Property       System.String FullName {get;}
…
…

PS D:\DEMO>

When we want to search for a specific File Type, the Extension Property comes in very handy.

So, to get a list of all, let’s say *.tmp files recursively, we’ll write:

PS D:\DEMO> Get-ChildItem -Rec | Where {$_.Extension -match "tmp"}

    Directory: D:\DEMO

Mode                LastWriteTime     Length Name
—-                ————-     —— —-
-a—        19.02.2010     13:22         12 demo.tmp

    Directory: D:\DEMO\DEMO Folder

Mode                LastWriteTime     Length Name
—-                ————-     —— —-
-a—        19.02.2010     13:22         12 dem32.tmp
-a—        19.02.2010     13:22         12 demo2.tmp

PS D:\DEMO>

Now, let’s delete all of these *.tmp files using Remove-Item

PS D:\DEMO> Get-ChildItem -Rec | Where {$_.Extension -match "tmp"} | Remove-Item

and they are all gone!

You should use this line to change it :

Set-PSSessionConfiguration -Name Microsoft.PowerShell -showSecurityDescriptorUI

This command sets the required configuration to enable remote management of the local computer. By default, this command creates a WS-Management listener on HTTP.

Setting up the brand new PowerShell v.2 remotely in a domain environment is easy: simply run

Set-WSManQuickConfig

As long as you have proper privileges to run this command, it does everything automatically: it runs the WinRM service, sets up a PowerShell listener and a firewall exception. To play with remotely, run this on every computer you want to connect to as it is required on both ends. Then, run any command remotely like this:

Invoke-Command { Stop-Process Spooler -force -whatif } -computername test123

You should note  that remote by default requires Kerberos authentication, so it will only work in a domain environment. You learn how to configure WSMan appropriately to make it work in simple peer-to-peer environments, in another tip.

Here’s another Blog Post from Tobias @powershell.com

Test-Driving Remoting In Windows 7

Remoting is among one of the most popular and powerful new PowerShell V2 features. What this means is that starting with PowerShell V2 (and starting with Windows 7 only because downlevel OS will support V2 remoting only in a future update), you can connect to other PowerShell V2 machines and run commands, scripts and jobs remotely. Very cool.

Unless you work in a configured AD-Environment, setting up and test-driving remoting isn’t that easy, though. By default, in a peer-to-peer environment,  remoting is dead. I’d like to show you today in three easy steps how to set up a test peer-to-peer environment that you can use to play, show off and demo V2 remoting.

    * This will show you how to set up the "new" V2 remoting using WinRM which requires PowerShell V2 on both ends.
    * Yes, there are other remoting techniques such as the old DCOM which will continue to work and neither require WinRM nor PS V2 (for example, use Get-WMIObject -computerName 10.10.10.10 to connect to that machine using classic DCOM)

What you need to make it happen…

To play with V2 remoting in a peer-to-peer scenario, this is what you need:

Ingredients:

    * 2x Windows 7 (one of which can be running inside Windows Virtual PC if you like)
    * both machines may not be joined to a domain(!)

Things are turned off out-of-the-box…

First of all, figure out the IP addresses assigned to both machines and make sure they can reach each other via network. In this example, I will be using machine A with 192.168.2.105 and machine B with 192.168.2.107, so make sure you replace the IP addresses with yours.

If you’d like to establish a remote connection from machine A to machine B, you would use Enter-PSSession, but if you try like this:

Enter-PSSession 192.168.2.107

the cmdlet will bark at you and come up with all kinds of reasons in red letters stating why what you are trying to do is absolutely ridiculous.

The simple fact is: the mechanism behind remoting which is called WinRM has not yet been set up to accept a remoting connection nor is it likely that the WinRM service is running at all yet. WinRM is secure by default, so you need to start it and open doors manually. What it also means is that you and only you will be liable if things go wrong and you trash your corporate infrastructure. So to prevent this from becoming a career-limiting move, you should set up a separate test environment to play with.

Step 1: Enable WinRM on both machines

The first thing you want to do is call Set-WSManQuickConfig. This is actually your door-opener, and to successfully launch this command, you will need to (a) have admin privs and (b) be sure you do want to open the doors. Specifically, the command does the following:

    * It makes sure the WinRM service is running and sets the startmode to Automatic so WinRM will be started automatically in the future. This enabled the computer to be connected via WinRM
    * It sets up a WinRM "listener" which is listening to incoming WinRM requests via http: from any IP address
    * It sets up a firewall exception so incoming WinRM requests aren’t rejected by your firewall any longer and make it to the WinRM service

As you can see, these really are door-openers, and unless you are working with a test system  in your closet, you may want to find out more about the possible security implications. Note also that Set-WSManQuickConfig might return an Access Denied if you try and run it on a machine that is domain-joined. Everything you read here applies to a simple peer-to-peer scenario only. Domain-joined machines are a different ballgame because they use Kerberos to securely authenticate requests and chances are in a domain-based environment you do not need all of this anyway because your IT department has decided for you.

Once you ran Set-WSManQuickConfig on both machines, your Enter-PSSession command still fails because again, for security reasons, WinRM rejects requests unless they are guarded by Kerberos or an equally safe mechanism. However, if you did everything right, both machines can now at least use WinRM to talk to each other:

Test-WSMan 192.168.2.107

This should return some protocol information.

Step 2: Add Computers to TrustedHosts list

Next, since you are working in a basic peer-to-peer environment, you need to convince WinRM that it is actually safe to accept requests from the other machine. You do this by adding the machine IPs to the list of so called "trusted hosts" – or, if you want to open the door even more, simply add a "*" to that list and allow any IP to talk to the machine. So on both machines, execute this:

Set-Item WSMan:\localhost\client\trustedhosts * –force

Step 3: Enjoy!

Once you did this last step, you are up and running. When you now enter

Enter-PSSession 192.168.2.107

after a couple of seconds of finger crossing (while WinRM sets up the remote PS session), you see the PS prompt of the remote system and now can work remotely on  that machine. Everything is working fine now, and you can also explore all the other fine remoting features. Dunno which remoting features there are? Hang in, we’ll be back shortly with more examples!

Oh, by the way, this will only work if you have created the same user account with the same password on both machines (remember, we are in a peer-to-peer environment here). Of course, the user on machine A initiating the connection needs to have admin privs on the target machine. To authenticate as someone else, use -credential (Get-Credential) as parameter.

ff you are wondering how to leave the remoting session you just opened, simply type:

exit-pssession

Links

Set-WSManQuickConfig on Microsoft Technet

Test Driving Remoting in Windows 7

Did you know, accessing individual WMI Instances and their Namespaces is pretty easy as 1-2-3..

You always get back all instances of a given WMI class when using Get-WMIObject. However, what if you just wanted to get a specific instance? Or you just wanted to find out how much space is left on drive C:? The next line gives you all drives:

Get-WMIObject Win32_LogicalDisk | Format-Table Name, FreeSpace

The trick is to use casting and WMI paths. The following line will provide specifically the C: drive:

[wmi]'Win32_LogicalDisk="C:"' | Format-Table Name, Freespace -autosize

To simply get the free bytes, use this:

([wmi]'Win32_LogicalDisk="C:"').FreeSpace

What happens here is a simple conversion. You specify text, then you ask PowerShell to convert it to a WMI object using [wmi], which is actually is a type accelerator, a shortcut. This is a way to find out the real .NET type it refers to:

[wmi].FullName

Of course, PowerShell cannot convert any string to a WMI object. You will need to specify the exact WMI object path, which is unique for each WMI object and contains the class name and so called key properties. Here is how you find out the object path for a Service:

Get-WmiObject Win32_Service | Format-Table Name, __Path -wrap

You can omit the PC name and WMI namespace for local objects in the standard WMI namespace. So to access a given Service directly, do this:

[wmi]'Win32_Service="WSearch"' | Format-List *

Why not use Get-Service? You could, but WMI is returning a lot more information about a service:

Get-Service WSearch | Format-List *