An introduction to PowerShell remoting – Part 2
This is part two in a series on PowerShell remoting. You can read part one here. Today we are going to cover setting up your environment for remoting.
Setting up remoting
After you have installed the required goodies or have Windows 7 / Windows 2008 R2 installed, you can proceed to setup remoting.
The command to enable remoting is Enable-PSRemoting. You will need to run this command with an account that has admin privileges on the machine you are enabling this on. As you can see below, running the Enable-PSRemoting command lets you know what the cmdlet will change on your PC. If you work in an environment that has system baselines, you will want to update your baseline to include the information for PSRemoting.
On PC’s that are x64, you will get an additional question asking if it should register the Microsoft.PowerShell32 session configuration. The entire chain of questions is below.
According to the Technet Article on Enable-PSRemoting, the following things are done when the command is run. (Enable-PSRemoting on Technet)
The Enable-PSRemoting cmdlet performs the following operations:
- Runs the Set-WSManQuickConfig cmdlet, which performs the following tasks:
- Starts the WinRM service.
- Sets the startup type on the WinRM service to Automatic.
- Creates a listener to accept requests on any IP address.
- Enables a firewall exception for WS-Management communications.
- Enables all registered Windows PowerShell session configurations to receive instructions from a remote computer.
- Registers the "Microsoft.PowerShell" session configuration, if it is not already registered.
- Registers the "Microsoft.PowerShell32" session configuration on 64-bit computers, if it is not already registered.
- Removes the "Deny Everyone" setting from the security descriptor for all the registered session configurations.
- Restarts the WinRM service to make the preceding changes effective.
The following is a screenshot of the firewall exception for the WS-Management communications.
To view the plugins that were added two WSMan, run the following command:
Get-ChildItem wsman:\localhost\plugin
The results on a fresh Windows Server 2008 R2 machine is below. Notice the two entries for PowerShell.
Note: We will go over WSMan on a separate post in this series.
Remoting is now turned on!
What do you do now? Well you have a couple of options. First you could run commands against that machine using PowerShell on another PC or you can adjust the configuration. In the next post, we will go over the configuration and running commands against a remote host.
Until next time! Happy Scripting!
- Matt
Link: Parse NMAP XML Output
I came across this while browsing around today. The post was released in June 2009, but still a cool way to use PowerShell.
http://blogs.sans.org/windows-security/2009/06/11/powershell-script-to-parse-nmap-xml-output/
I am a frequent user of NMAP and of course PowerShell and this seems like it will be really useful.
January 2010 Technet Magazine is out
The January 2010 Technet Magazine is out. You can read it here.
The disappointing part is how much content there is. Not a lot. Frustrating, but still has good content.
- Matt
Link Clearance – 1/8/2010
Wonder what I am reading this weekend? Here is a short list of the links I will be reading this weekend. There are a ton more, but these are on the top of the to read pile.
- Windows Management Infrastructure Blog : wmic vs WMI Powershell cmdlets
- Hey, Scripting Guy! Blog : Hey, Scripting Guy! How Do I Add Help Information for Windows PowerShell Parameters?
- Group Policy Team Blog : Tales from the Community: Enforced vs. Block Inheritance
- Securosis Blog | Getting Your Mindset Straight for 2010
- Windows PowerShell Blog : How objects are sent to and from remote sessions
- Clint Huffman's Windows Troubleshooting in the Field Blog : W3C IIS Log Analysis using Log Parser
- Hey, Scripting Guy! Blog : Hey, Scripting Guy! Quick-Hits Friday: The Scripting Guys Respond to a Bunch of Questions (1/8/09)
- Ask the Directory Services Team : The importance of following ALL the authoritative restore steps
- Network Monitor : Annotated Traces for Windows System Behavior
This list may get updated throughout the day depending on how busy I get.
-Matt
An introduction to PowerShell remoting – Part 1
One of the exciting features of PowerShell v2 is remoting. In a series of posts, I am going to go through PowerShell remoting and explore its features. Some topics I will cover are:
- Getting Started
- Setting up your environment
- Commands and Cmdlets
- Security
- Random things to do with remoting
Warning: If you are a member of the SE Michigan PowerShell Users group, please close your eyes as I will be presenting on this the next two months.
In this first post we are going to go through what you need to make PowerShell remoting work on your network and some things you need to know about remoting before you start. So lets get started.
What you need
If you are lucky to be running Windows 7 or Windows Server 2008 R2, you already have the necessary software to get PowerShell remoting up and running. However, if you are running any of the following you will need the Windows Management Framework and the .NET Framework 2.0 or later.
- Windows XP Service Pack 3
- Windows Vista Service Packs 1 or 2
- Windows Server 2003 Service Pack 2
- Windows Server 2003 R2
- Windows Server 2008 Service Pack 2
The Windows Management Framework includes Windows PowerShell 2.0, Windows Remote Management (WinRM) 2.0 and Background Intelligent Transfer Service (BITS) 4.0. You can download the framework here.
To find out what version of PowerShell you are using, you can use the variable $PSVersionTable. You want $PSVersionTable.Version.Major to be 2. Here is the output from one of my lab PC’s running Windows 7.
Some things to know
As I was going through starting to configure PowerShell remoting, here are some things I found.
- Both the remote and local computers must be configured to use remoting.
- You must have PowerShell and the related bits installed on all machines.
- You can both run scripts remotely as well has have an interactive session with a remote PC.
- You must be a member of the Administrators group on the remote PC or provide valid credentials with Admin privileges.
- On current versions of windows. The network type must be work or home. Public will not work.
- Any policies, ie group policies, on the remote pc are in effect in remote PowerShell sessions. Keep that in mind if something isn’t working as expected.
Where we go from here
In the next post, I will go over enabling PowerShell remoting. If you are following along at home, you will need to have the necessary software installed to continue with the examples. If you have any questions or comments please leave them here, email feedback [at] mwjcomputing [dot] com, or contact me on Twitter at @mwjcomputing.
-Matt
Updated 1/5/2009: Updated to include service pack info for Windows OSs. Thanks to Aleksandar Nikolić for the reminder!
Couple of links
While waiting for my wife to get home on this Christmas Eve, I decided to go through some of the links I have collected while working on other projects. I figured I would share some of them with you. Enjoy!
- Cygwin 1.7 is out with Windows 7 and Windows Server 2009 R2 Support!
- NTFS: An Introduction from the SANS Forensics Blog written by Dave Hull
- NTFS: Attributes Part One is also from the SANS Forensics Blog and written by Dave Hull
- Hey, Scripting Guy! Can Windows PowerShell Functions Accept More Than One Input?
Those are the big ones I got through today. I should post more this weekend.
-Matt
PowerShell 2.0 SDK is available now.
The PowerShell 2.0 Software Development Kit (SDK) is available at the Microsoft Download site.
From the Overview: This SDK contains reference assemblies and samples that demonstrates how to use the Windows PowerShell 2.0 APIs to build a rich set of applications. In this package, you will find sample code which shows how to use the new PowerShell class, how to write cmdlets that supports eventing, transactions and jobs. In addition, there are examples of host applications that connect to remote computers using individual runspaces and runspace pools. This SDK also includes modified Windows PowerShell 1.0 samples using the modified and improved Windows PowerShell 2.0 APIs.
You can download it here.
You will need a current version of Windows and .NET Framework 2.0.
December 2009 Technet Magazine is out
If you haven’t noticed, you haven’t received your December Technet Magazine. That is because it has gone digital only. It sucks, but we have to live with it.
It has some good information regarding Exchange 2010, Windows 7 and a PowerShell column about Regular Expressions.
Check it out here: http://technet.microsoft.com/en-us/magazine/default.aspx
It looks as though it won’t be offered in HTML Help format either. Oh well.
Enjoy?
-Matt
Why users don’t get security policy
I have been thinking about this for a long time. I still may be a fledgling in the Information Security community, but feel that I have a pretty good grounding in the InfoSec concepts. So here it goes….
Users don’t get security policy because the don’t feel it directly relates to them. Users may wonder why would a removable media or email policy apply to them? I don’t really blame users for feeling this way. Most people are genuinely honest people trying to make a honest living. They are not trying to steal data or cause a data breach. I will go far as to say that the majority of data breaches were not the result of some willful action to release or steal the data.
I remember when I was just a user and I laughed at some of the of the policies thinking who would do that? It wasn’t until later I realized policies really are trying to catch the exception to the rule not the rule itself. I don’t feel that this is adequately communicated to most users. If we were to educate users that policies were there to help them do their job not to control or dominate them users may be more willing to accept policy. An analogy that I think could work is Monopoly. A normal game of Monopoly has rules and people police other players when it comes to rules. People normally are happy when it comes to playing within the rules and expect it while still enjoying the game. Why can’t this translate to security policy?
This however assumes is that everyone plays by the rules equally. If you are a user in the mail room or someone in a CXO position, everyone needs to follow the rules and help police everyone. No one, no matter who they are, is treated different. This sadly isn’t always the case.
Until the individual user experiences a negative effect of someone not playing by the rules, or policy, people don’t understand why the should care. I think if we spend more time thinking like users and educating them to why it is an advantage to them to follow the “rules” we might find our workplaces or organizations a more secure place.
Get PowerShell v2.0!
If you are using or not using PowerShell, you can get the download for PowerShell v2.0 for Windows XP, Windows Server 2003, Windows Vista and Windows Server 2008 at the following link.
http://support.microsoft.com/kb/968929
The download is for the Windows Management Framework. The framework includes PowerShell 2.0, WinRM 2.0 and BITS 4.0.
Get out there and download it today!
- Matt
PS: If you are running Windows 7 or Windows 2008 R2, you already have PowerShell 2.0 and you can go back to your normal programming.