Powershell Wiki

Read each line from a file and execute

The example is for reading the names of the servers and returning the date and time for each into another file

foreach($line in Get-Content .\servers.txt)
{
    $line | Add-Content "U:\servers-time.txt"
    $srv_time = Invoke-Command -ComputerName $line -ScriptBlock {get-date} 
    $srv_time | Add-content "U:\servers-time.txt"
}

the "Get-Content command reads the whole file into memory, therefore is slow.
Instead this one is to be used

foreach($line in [System.IO.File]::ReadLines("U:\servers.txt"))
{
    $line | Add-Content "U:\servers-time.txt"
    $srv_time = Invoke-Command -ComputerName $line -ScriptBlock {get-date} 
    $srv_time | Add-content "U:\servers-time.txt"

}

Check the PS version

 $PSVersionTable.PSVersion

Get the OS Version

[environment]::OSVersion.Version


Enable Powershell remoting via Group Policy

From : http://www.briantist.com/how-to/powershell-remoting-group-policy/
And here: http://blogs.technet.com/b/heyscriptingguy/archive/2010/11/16/enable-powershell-remoting-to-enable-running-commands.aspx

Powershell really is a game changer when it comes management and scripting on Windows, but one of the areas where it really shines is in its remoting capability. Powershell remoting lets you connect to a remote system and run commands locally, then returns the results to the calling machine. This can be done as an automated block or as an interactive session.
Remoting requires Powershell 2.0 which comes built-in on Windows 7 and Windows 2008 R2, but it needs to be installed on Windows Vista / Server 2008 and below. The WinRM service will also have to be configured and enabled.
I’ll show you how to accomplish this with group policy for the range of operating systems that can run it.
Update 2013/02/20: I have confirmed that this method is working on Server 2012 (core and GUI) as well.
Update 2013/05/07: With the help of Jacob in the comments below, I was able to fix a problem in the VB Script. Since Powershell requires the .NET framework, this whole process will fail on Windows 2003 / XP if .NET is not installed. The VB Script now installs .NET as part of the process. The GitHub Gist has been updated. Thanks Jacob!
Update 2013/10/09: Updated the name of the WinRM policy setting based on user comments. Thanks to Micahel M. of Miller Computers and Giorgi Gordeziani.
The Policy Split
We basically have three operating system “classes” to deal with here:
• Windows 7 / Windows 2008 R2
• Windows Vista / Windows 2008
• Windows XP / Windows 2003
The requirements for each are as follows:
Windows 7 / 2008 R2
• Needs WinRM enabled / configured.
• Needs firewall rules.
• Needs service configuration.
Windows Vista / 2008
• Needs everything above.
• Needs Powershell 2.0 installed.
Windows XP / 2003
• Needs everything above.
• Needs .NET framework.
• Cannot directly configure WinRM with Group Policy.
What does that last bolded bullet mean? There are already administrative templates for enabling and managing WinRM, but they only work on Vista clients and later, so our XP and 2003 machines are out of luck there. Vista and 2008 are covered by that, but they don’t have Powershell 2.0 installed by default. Windows XP and 2003 don’t have .NET framework by default either.
In my environments I’ve chosen to do this with two policies. The first policy uses the administrative templates to enable WinRM, and it sets a few additional policies for Windows firewall rules and WinRM service parameters which will apply to all of the OS classes. The second policy is filtered with WMI to only apply to Vista / 2008 machines and lower, and it consists solely of a startup script which installs Powershell 2.0 and .NET framework (as needed) and enables WinRM.

The ‘Enable Powershell Remoting’ Policy

This is the first policy described above. If you are lucky enough to have no machines in your environment below Windows 7 / 2008 R2 (where do you work?!) then this is the only one you need. All of the settings we are using will be in Computer Configuration so if you want to disable User Configuration as I have go ahead.
1. Create your GPO, name it what you want, place it where you want, etc.
2. Edit your policy.

Enabling WinRM

1. Browse to:
Policies > Administrative Templates > Windows Components > Windows Remote Management (WinRM) > WinRM Service
1. Open the “Allow Remote Server management through WinRM” policy setting (Server 2008 R2 and later).
2. Open the “Allow automatic configuration of listeners” policy setting (Server 2008 and earlier).
2. Set the Policy to Enabled.
3. Set the IPv4 and IPv6 filters to * unless you need something specific there (check out the help on the right).

Setting the Firewall Rules

1. Browse to:
Policies > Administrative Templates > Network > Network Connections > Windows Firewall > Domain Profile
2. Open the “Windows Firewall: Define inbound port exceptions” policy setting.
3. Set it to Enabled if it isn’t already.
4. Click the “Show…” button and add the port exception. We’re going to be opening TCP port 5985, so the exception string will look something like this:
5985:TCP:*:enabled:WSMan
If Windows XP and 2003 are not a concern:
You can use the new Firewall with Advanced Features policy to configure the rule instead, but this will only work on Vista and above. Additionally, you should configure this from a Windows 7 / 2008 R2 machine because of a difference in the pre-defined rule.
1. Browse to:
Policies > Windows Settings > Security Settings > Windows Firewall with Advanced Security > Windows Firewall… > Inbound Rules
2. Right click and choose “New Rule…”
3. Choose the “Windows Remote Management” pre-defined rule.
4. When you click next you should see the two rules that will be added.
5. Click next, choose to Allow the connection, and then Finish.

Service Configuration

At this point we have enough in place to get this working, but I like to do a few more things to ensure that the WinRM service is configured to start automatically and to restart on failure.
1. Browse to:
Policies > Windows Settings > Security Settings > System Services
2. Find the “Windows Remote Management (WS-Management)” service.
3. Define the policy and give it a startup mode of Automatic.
4. Browse to:
Preferences > Control Panel Settings > Services
5. Create a new Service preference item with the following parameters:
1. General Tab
1. Startup: No Change (the policy we set above will take precedence over this anyway)
2. Service name: WinRM
3. Service action (optional): Start service
2. Recovery Tab
1. First, Second, and Subsequent Failures: Restart the Service

The ‘Install Powershell 2.0 and WinRM’ Policy

Now we’ll create the second policy that I described. This one will install theWindows Management Framework Core package and .NET framework via a startup script. This policy will use a WMI filter so that we aren’t trying to do these steps on Windows 7 / 2008 R2 where it’s unnecessary.
Since these are distributed as a Windows updates and not as an MSI, we can’t use software distribution to install them. That also means that if you’re using WSUS you’ll have to make sure that these updates are approved:
• KB968930
• KB951847

Create The WMI Filter

First, let’s create the WMI filter that we’re going to use so that this policy will only apply to Windows Vista / 2008 and below.
1. In the Group Policy Management console, scroll down to “WMI Filters.”
2. Create a new WMI Filter, and give it a name and description.
3. In the Queries box, click the Add button.
4. Keep the namespace as “root\CIMv2″ and then click into the Query box.
5. The following WQL query will match Windows Vista, Windows 2008, and lower operating systems:
1 SELECT * FROM Win32_OperatingSystem WHERE Version LIKE "6.0%" ORVersion LIKE "5.%"

Create the GPO

1. Create the GPO and link it to the same places as the first one.
2. Make sure that the WMI filter we created above is applied to the GPO.

Set up the Startup Script

1. Browse to:
Policies > Windows Settings > Scripts
2. Open the Startup item, and make sure you’re on the Scripts tab (not Powershell scripts).
3. Click the Show Files… button below. This location is where you must put the script. You can download the script from this GitHub Gist.
4. Once the file is in place, click the Add… button in the Startup Properties window.
5. Type or paste the name of the VBScript file (just the name, not the full path).
6. Leave Script Parameters blank.

Wrapping Up

With this in place, you’re ready to go! As with any group policy changes, test, test, and test again. I usually remove Authenticated Users from the Security Filtering and add in individual computers to test out policies on several machines before I let them loose on the domain (virtual machines with snapshots are great for this).
Windows XP / 2003 machines probably need to be rebooted, maybe twice, for it all to work (especially if the script installs .NET). If you’ve got any other remote administration in place and working (psexec, WMI, third-party tools) you could use that to kickstart the execution of the VBScript that installs the management framework.
Don’t forget about domain controllers! They’re usually in a different OU than the other computers in your domain, so don’t forget to link the policies to all of the appropriate containers.
Happy remoting!


Powershell + VMWare PowerCLI

1. Install PowerCLI from vmware.com
2. In Powershell add PowerCLI module
Add-PSSnapin vmware.VIMAutomation.core
3. Check the registred snap-ins
Get-PSSnapin -Registred
4. Check vmware commands
Get-Command -PSSnapin vmware*
5. Connect to the vCenter
Connect-Viserver servername -User username -Password password

Actions on vCenter:
New-VM
Get-VM (inventory list)
Start-VM -VM
Restart-VM -VM
Stop-VM -VM
Remove-VM -VM
Suspend-VM -VM
Example:
Get-VM -Name “vm_name” | fl * (returns all the details of the guests)
Get-VM | where {$_.PowerState -eq “PoweredOn”} (returns all the running machines)


Powershell - Reading remote servers' date and time

from: http://mikefrobbins.com/2011/11/10/check-the-time-on-remote-machines-with-powershell/

Here’s a simply Powershell script to query the time on remote machines via WMI. You could use Invoke-Command with Get-Date, but that takes too long compared to just using WMI. I chose to hard code the names I wanted to query directly into the script to eliminate having to keep up with a separate text file or trying to query Active Directory for the names since that may not be possible if the time is way off. This script is my solution to the “I have a problem and I want to eliminate the time on remote machines as a source of it”. I want the time and I want it now!

$servers = 'server1', 'server2', 'server3', 'server4', 'server5', 'server6'
ForEach ($server in $servers) {
$time = ([WMI]'').ConvertToDateTime((gwmi win32_operatingsystem -computername $server).LocalDateTime)
$server + ' ' + $time
}

My adaptation to this is:

$servers = Get-Content "C:\Powershell\servers.txt"

ForEach ($server in $servers) {
$time = ([WMI]'').ConvertToDateTime((gwmi win32_operatingsystem -computername $server).LocalDateTime)
$server + ' ' + $time
}


Exctract Folder's permissions to csv file

Get-ChildItem "X:\share" -Recurse -Exclude *.* | Get-Acl | export-csv "C:\directory\file_permissions.csv"

The -Exclude *.* part is to avoid showing the permissions on the file level


ROBOCOPY network UserName/Password

September 19, 2012 Leave a comment Go to comments

If you need to copy something using robocopy to remote host where additional authentication is required you should send username/password somehow. Robocopy.exe does not provide network authentication by itself. So to provide username and password for robocopy.exe we can use NET USE to open IPC$ share to destination host and execute our robocopy code.

Note: There is UNC path used, so keep in mind to have source and destination folders shared.

Script language: cmd / bat

NET USE \\RemoteServerName\IPC$ /u:server\user *password* 
robocopy \\Source\ \\RemoteServerName\DestinationDir\ /XD * /Z /MIR /LOG+:c:\temp\log.log
NET USE \\RemoteServerName\IPC$ /D

Code comments:

/XD * – exclude ALL sub directories
/Z – copy files in restartable mode (survive network glitch)
/D – close IPC$ share to make our script clean

Script language: PowerShell
Has parameters to customize script
Can send log file by email.

# IPC$ share options                #
$IPCHost = "host_name"              # Host name to create IPC$ share with
$IPCUser = "domain\user"            # Authentication 
$IPCPwd  = "Pa$$w0rd"               #                for IPC$ share
# Copy TO settings                  #
$DstHost = "host_name"              # Destination Host Name
$DstDir  = "root_share\folder\name" # Destination Directory Path 
# Copy FROM settings                # 
$SrcHost = "host_name"              # Source Host Name
$SrcDir  = "root_share\folder\name" # Source Directory Path
# E-Mail Settings                   #
$LogPath = "c:\full_path.log"       # Full path to log file (c:\temp.name.log)
$EmailTo = "email@domain.com"       # Recipient email address
$EmailFrom = "email@domain.com"     # Sender email address
$EmailSubj = "subject_here"         # Letter Subject
$EmailBody = "body_here"            # And body
$EmailSmtpSrv = "server_name"       # SMTP server name (FQDN)
# Parameters (robocopy keys)        #
$Params = "/XD * /Z /MIR"           # Specify needed robocopy.exe parameters here
# Action Block                      #
NET USE \\$IPCHost\IPC$ /u:$IPCUser $IPCPwd
robocopy.exe \\$SrcHost\$SrcDir\ \\$DstHost\$DstDir\ $Params /LOG:$LogPath
NET USE \\$IPCHost\IPC$ /D
Send-MailMessage -To $EmailTo -From $EmailFrom -Subject $EmailSubj -Body $EmailBody -SmtpServer $EmailSmtpSrv -Attachments $LogPath
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License