Search results for 'app:weblogs' matching tags 'Remoting' and 'guest blogger'

Enabling Multihop Remoting

Anonymous — Thu, 04 Apr 2013 05:00:00 GMT

Summary: Microsoft PowerShell MVPs, Don Jones and Jeffery Hicks, discuss how to enable multihop remoting in Windows PowerShell 3.0.

Microsoft Scripting Guy, Ed Wilson, is here. Tonight is our Windows PowerShell User Group meeting in Charlotte, NC, I will be making a presentation about using Windows 8 to perform remote management, We will also be doing a Lync meeting with the Philadelphia User Group at the same time. Click the following link to join us online from 7:00 – 8:00 P.M. Eastern Standard Time: Charlotte Windows PowerShell User Group meeting.

This week we will not have our usual PowerTip. Instead we have excerpts from seven books from Manning Press. In addition, each blog will have a special code for 50% off the book being excerpted that day. Remember that the code is valid only for the day the excerpt is posted. The coupon code is also valid for a second book from the Manning collection.

Today, the excerpt is from Learn Windows PowerShell 3 in a Month of Lunches, Second Edition
By Don Jones and Jeffery Hicks

When you’re remoting into a computer, don’t run Enter-PSSession from that computer unless you fully understand what you’re doing. Let’s say you work on Computer A, which runs Windows 7, and you remote into Server-R2. At the Windows PowerShell prompt, you run this:

[server-r2] PS C:\>enter-pssession server-dc4

Server-R2 is maintaining an open connection to Server-DC4, which can start to create a “remoting chain” that’s hard to keep track of, and which imposes unnecessary overhead on your servers. You may have times when you might have to do this—mainly of instances where a computer like Server-DC4 sits behind a firewall and you can’t access it directly, so you use Server-R2 as a middleman to hop over to Server-DC4. But, as a general rule, try to avoid remote chaining.

Some people refer to “remote chaining” as “the second hop,” and it’s a major Windows PowerShell “gotcha.” We offer a hint: if the Windows PowerShell prompt is displaying a computer name, you’re done. You can’t issue any more remote control commands until you exit that session and “come back” to your computer.

The following drawing depicts the second hop or “multihop” problem: You start on Computer A, and you create a PSSession connection to Computer B. That’s the first hop, and it’ll probably work fine. But, then you try to ask Computer B to create a second hop (or connection) to Computer C—and the operation fails.

The problem is related to the way Windows PowerShell delegates your credentials from Computer A to Computer B. Delegation is the process of enabling Computer B to execute tasks as if it were you, thus ensuring that you can do anything you’d normally have permissions to do—but nothing more. By default, delegation can only traverse one such “hop”—Computer B doesn’t have permission to delegate your credentials to a third computer, Computer C.

In Windows Vista, Windows 7, and Windows 8, you can enable this multihop delegation. Two steps are needed:

On your computer (Computer A in the example), run Enable-WSManCredSSP –Role Client –DelegateComputer x. You’ll replace x with the name of the computer where your credentials may be delegated. You could specify an individual computer name, but you might also use wildcard characters. We don’t recommend using * because that presents some real security concerns, but you might authorize an entire domain, for example: *.company.com.
On the server that you’re connecting to first (Computer B in the example), run Enable-WSManCredSSP –Role Server.

The changes made by the command will be applied to the computers’ local security policies; you could also manually make these changes via a Group Policy Object, which might make more sense in a large domain environment. Managing this via Group Policy is beyond the scope of this blog, but you can find more information in the Help for Enable-WSManCredSSP. Don also authored a Secrets of PowerShell Remoting Guide that covers the policy-related elements in more detail.

Here is the code for the discount offer today at www.manning.com: scriptw4
Valid for 50% off Learn Windows PowerShell 3 in a Month of Lunches, Second Edition and Learn Windows IIS in a Month of Lunches
Offer valid from April 4, 2013 12:01 AM until April 5 midnight (EST)

I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Ed Wilson, Microsoft Scripting Guy

Digging into PowerShell Remote Authentication

Anonymous — Thu, 15 Nov 2012 06:00:00 GMT

Summary: Guest blogger Windows PowerShell MVP Don Jones talks about remote Windows PowerShell authentication.

Microsoft Scripting Guy, Ed Wilson, is here. Today, I have a special treat for you. Windows PowerShell MVP Don Jones just had a new book released for publication and we have a sample from that book to share.

Learn Windows PowerShell 3 in a Month of Lunches, Second Edition

By Don Jones

Folks tend to think of authentication as a one-way process: you want to access some remote machine, and you have to provide it with your credentials before it will let you in. But, Windows PowerShell remoting uses mutual authentication. In this article, based on chapter 23 of Learn Windows PowerShell 3 in a Month of Lunches, Second Edition, author Don Jones goes deeper into remoting authentication.

Digging Deeper into Remoting Authentication

Windows PowerShell remoting employs mutual authentication, which means the remote machine must also prove its identity to you. In other words, if you run Enter-PSSession -computerName DC01, the computer named DC01 has to prove it’s really DC01 before the connection will complete.

Why? Normally, your computer will resolve a computer name (like DC01) to an IP address by using the Domain Name System (DNS). DNS isn’t invulnerable to spoofing, so it’s not unthinkable that an attacker could get in and modify the entry for C01 to point to a different IP address—an IP address that the attacker controls. You could unknowingly connect to DC01, wind up on an imposter computer, and then start delegating your credential to it—bad news! Mutual authentication prevents that from happening: if the computer you connect to cannot prove it’s the one you intended to connect to, then remoting will fail. That’s a good thing—you don’t want to turn that protection off without careful planning and consideration.

Defaults for mutual authentication

Microsoft expects most Windows PowerShell usage to occur in an Active Directory domain environment. Provided you connect to computers by using their real computer names, as listed in Active Directory, the domain will handle the mutual authentication for you.

This even happens when you access computers in other, trusting domains. The trick is that you need to provide Windows PowerShell with a computer name that will accomplish both of these requirements:

The name must resolve to an IP address.
The name must match the computer’s name in the directory.

Providing a computer name from the same domain that you’re in, or a fully qualified name (computer and domain name, like DC01.COMPANY.LOC) for a trusting domain, usually accomplishes both of these tasks. But if you need to provide an IP address, or if you need to provide a different name for DNS to work (such as a CNAME alias), then the default mutual authentication won’t work. That leaves you with two choices: SSL or TrustedHosts.

Mutual authentication via SSL

For this technique, you’ll need to obtain an SSL digital certificate for the destination machine. The certificate must be issued to the same computer name that you’ll type to access the computer. That is, if you’re running Enter-PSession –computerName DC01.COMPANY.LOC -UseSSL -credential COMPANY\Administrator, then the certificate installed on DC01 must be issued to “dc01.company.loc” or the entire process will fail. Note that the -credential parameter is mandatory in this scenario.

After getting your certificate, you need to install it into the Personal certificate store for the computer account—something best accomplished with the Certificates snap-in in the Microsoft Management Console (MMC) GUI. Simply double-clicking a certificate file will usually put it in your user account’s Personal store, but that won’t work.

With the certificate installed, you’ll need to create an HTTPS listener on the computer, telling it to use the newly installed certificate. The step-by-step directions are quite extensive, and because this isn’t something a lot of people will probably do, we’re not going to cover them all here. Take a look at Don’s Secrets of PowerShell Remoting guide (it’s free), and you’ll find step-by-step instructions including screenshots.

Mutual authentication via TrustedHosts

This is a slightly easier technique than using an SSL certificate, and it requires a lot less setup. But it’s a bit more dangerous, because it basically shuts off mutual authentication for selected hosts. Before you try it, you need to be able to confidently state, “it is unthinkable that someone could impersonate one of these hosts, or hack their DNS records.” For internal computers on your intranet, for example, you might feel pretty confident of that.

Then you just need a way to identify the computers you’ll trust without mutual authentication. In a domain, for example, that might be something like “*.COMPANY.COM” for all hosts in the Company.com domain.

This is an instance where you’re likely going to want to configure the setting for your entire domain, so we’ll give you the Group Policy instructions. You can use these same instructions for a single computer’s Local Security Policy.

In any GPO or in the Local Computer Policy editor, follow these steps:

Expand Computer Configuration.
Expand Administrative Templates.
Expand Windows Components.
Expand Windows Remote Management.
Expand WinRM Client.
Double-click Trusted Hosts.
Enable the policy and add your trusted hosts lists. Multiple entries can be separated by commas, such as “*.company.com,*.sales.company.com.”

Note Older versions of Windows might not have the template needed to display these settings in the Local Computer Policy, and older domain controllers might not have them in their Group Policy Objects. For those situations, you can change the Trusted Hosts list in Windows PowerShell. Run Help about_remote_troubleshooting in the shell for instructions.

Summary

Now you’ll be able to connect to those machines without mutual authentication getting in the way. You must provide a -Credential parameter with all remoting commands used to connect to these computers—failure to do so will result in a failed connection attempt.

That's it for today. Don's book will be available later this month.

Ed Wilson, Microsoft Scripting Guy

An Introduction to PowerShell Remoting Part Five: Constrained PowerShell Endpoints

Anonymous — Fri, 27 Jul 2012 05:00:00 GMT

Summary: Guest blogger, Jason Hofferle, talks about creating constrained Windows PowerShell endpoints.

Microsoft Scripting Guy, Ed Wilson, is here. Today is the exciting conclusion to Jason Hofferle’s excellent series of articles about Windows PowerShell remoting. I think today’s article is the most important of the bunch – because it illustrates a killer security feature. Here is Jason to tell you about creating constrained Windows PowerShell endpoints.

Jason Hofferle has been an IT professional since 1997. His experience includes enterprise desktop engineering for a Fortune 500 financial institution and Active Directory design for local governments and law enforcement. Jason currently works for the Defense Contract Management Agency, where he implements new technology such as virtual desktop infrastructure. He recently has been speaking about Windows PowerShell at SQL Saturday and IT Pro Camp events in Florida, and he frequently attends the Tampa PowerShell User Group.

Blog: Force Multiplication through IT Automation
Twitter: @jhofferle

In Part Four of this series, Sessions and Implicit Remoting, I talked about PowerShell sessions and implicit remoting, which allows commands to behave like they are being run locally when they are actually being run transparently on a remote system. In the final blog in this series, I’m going to discuss constrained endpoints, which allow me to control exactly what cmdlets can be used when I am connected to a remote computer.

When I use remoting to connect to a computer, I’m connecting to an endpoint. The Get-PSSessionConfiguration cmdlet enables me to view the currently registered endpoints. When I use Set-PSSessionConfiguration with the ShowSecurityDescriptorUI parameter, I can view the permissions for an endpoint. The default Windows PowerShell endpoints only allow access to members of the local administrators group. These permissions can be modified, or entirely new endpoints can be created.

So why would I want to create a new endpoint? It’s useful for delegation, because not only can I allow others to connect to that endpoint without granting them administrative rights to the computer, but I can also control precisely what commands they are allowed to run on that endpoint. Each endpoint can have an associated startup script that runs whenever a connection is made to that endpoint. The startup script can be used to automatically run commands, load modules, or constrain the session to limit what it can be used for.

Let’s say I want to grant my Help Desk staff access to run some commands on a server. First I’m going to create a startup script that will constrain the session. I start by restricting the session to the point where it’s useless, and then expose only what’s required for the session to work properly, with the commands that I want my Help Desk to be able to view.

foreach ($command in Get-Command)

{

$command.Visibility = "private"

}

foreach ($variable in Get-Variable)

{

$variable.Visibility = "private"

}

$ExecutionContext.SessionState.Applications.Clear()

$ExecutionContext.SessionState.Scripts.Clear()

$ExecutionContext.SessionState.LanguageMode = "NoLanguage"

$InitialSessionState =

[Management.Automation.Runspaces.InitialSessionState]::CreateRestricted(

"remoteserver")

foreach ($proxy in $InitialSessionState.Commands | where { $_.Visibility -eq "Public"})

{

$cmdlet = Get-Command -Type cmdlet -ErrorAction silentlycontinue $proxy.name

if ($cmdlet)

{

$alias = Set-Alias "$($proxy.name)" "$($cmdlet.ModuleName)\$($cmdlet.Name)" -PassThru

$alias.Visibility = "Private"

}

Set-Item "function:global:$($proxy.Name)" $proxy.Definition

}

In Bruce Payette’s book, Windows PowerShell in Action 2^nd Edition, he uses the InitialSessionState .NET class as an easy way to expose the cmdlets that are required for the session to function correctly. Up to this point, his code is boilerplate that can be used to constrain any endpoint. Now I can start exposing the commands that I want my Help Desk to see. One way to expose certain cmdlets is to change their visibility back to public.

$allowedCmdlets = @("Get-Date","Format-Wide")

Get-Command | Where-Object {$allowedCmdlets -contains $_.Name} |

foreach {$_.Visibility = "Public"}

If I want to expose an executable or a script, it needs to be added to the endpoint’s list of allowed applications, by using a different method.

$ipConfig = (Get-Command ipconfig.exe).Definition

$ExecutionContext.SessionState.Applications.Add($ipConfig)

Custom functions can also be defined in the startup script. What’s interesting about this is that the staff connecting to this endpoint will have access to the function, but they won’t be able to use the cmdlets inside the function.

Function Get-ServerInfo

{

$CS = Get-WmiObject -Class Win32_ComputerSystem

$OS = Get-WmiObject -Class Win32_OperatingSystem

$Printer = Get-WmiObject -Class Win32_Printer

$MappedLogicalDisk = Get-WmiObject -Class Win32_MappedLogicalDisk

$Result = New-Object PSObject -Property @{

UserName = $CS.UserName

ComputerName = "$($CS.DNSHostName).$($CS.Domain)"

OSArchitecture = $OS.OSArchitecture

OSName = $OS.Caption

OperatingSystemVersion = $OS.Version

OperatingSystemServicePack = "$($OS.ServicePackMajorVersion).$($OS.ServicePackMinorVersion)"

DefaultPrinter = ($Printer | Where-Object {$_.Default}).Name

TypeOfBoot = $CS.BootupState

LastReboot = $OS.ConvertToDateTime($OS.LastBootUpTime).ToString()

Drive = $MappedLogicalDisk |

Select-Object @{Name='Drive Letter';Expression={$_.DeviceID}},

@{Name='Resource Path';Expression={$_.ProviderName}}

}

Write-Output $Result

}

With my startup script finished, I can use Register-PSSessionConfiguration to create a new endpoint called HelpDesk.

Now I can use Set-PSSessionConfiguration to grant access to my Active Directory group HelpDesk to allow them to use remoting commands to connect to the endpoint.

Set-PSSessionConfiguration –Name HelpDesk –ShowSecurityDescriptorUI –Force

Now that the PowerShell Remoting endpoint has been constrained with a startup script, my Help Desk staff can access the endpoint, and they’ll only see the commands that are available to them.

This is also an ideal situation to use implicit remoting because I can provide access to custom functions in a single place, without needing to distribute custom modules and scripts. I can update these commands in a single place. They can be used as if they were local, but I don’t have to worry about staff using an old version of a script.

It’s important to note that PowerShell Remoting is security neutral. My Help Desk now has access to connect to my server; however, they cannot do anything that they couldn’t already do. If they don’t have rights to delete user accounts, I couldn’t provide them access to the Remove-ADUser cmdlet and expect them to have the capability to remove user accounts. Permission-denied errors will still occur, just as if they were using the Active Directory Users and Computer MMC snap-in.

The concept of constrained endpoints is used to great effect with Microsoft Office 365 and hosted Exchange Server. I have the ability to connect to a common endpoint, which exposes only the commands available for me to manage my mailboxes. This gives me the capability to automate my hosted Exchange Server environment, even though it’s completely off my network.

Remoting is truly the killer feature of Windows PowerShell. It’s incredibly useful now, and it has lots of future potential. The WSMan framework is a secure and reliable foundation for Microsoft and non-Microsoft software developers, and hardware manufacturers to build their management tools. Remoting can be used to create solutions today, and it will only get more impressive with the release of Windows PowerShell 3.0 in Windows 8 and Windows Server 2012.

Additional Resources

Administrator’s Guide to Windows PowerShell Remoting

Layman’s Guide to PowerShell 2.0 Remoting

Secrets of PowerShell Remoting

~Jason

Thank you, Jason, for an awesome series on remoting. Join us tomorrow for guest blogger, Will Steele.

Ed Wilson, Microsoft Scripting Guy

An Introduction to PowerShell Remoting Part Four: Sessions and Implicit Remoting

Anonymous — Thu, 26 Jul 2012 05:00:00 GMT

Summary: Guest blogger, Jason Hofferle, talks about creating Windows PowerShell sessions and using implicit remoting.

Microsoft Scripting Guy, Ed Wilson, is here. Jason continues to hit home run after home run this week. Today is no exception. He talks about one of the coolest features in Windows PowerShell—that of implicit remoting. Here is Jason.

Blog: Force Multiplication through IT Automation
Twitter: @jhofferle

In Part Three of this series, Interactive and Fan-Out Remoting, I talked about using Enter-PSSession and Invoke-Command to run commands on remote computers. In this post, I’m going to get into persistent sessions and using implicit remoting.

When using the ComputerName parameter with Invoke-Command, authentication is completed, the remoting session is established, the command is run, objects are sent back, and the remoting session is torn down. This works fine if there’s only a single command that needs to be run. But what if there’s a group of computers that need to be managed throughout the day? It’s not very efficient to go through all that overhead each time a command is run if you’re going to be managing a group of servers constantly. With PowerShell Remoting, we have the concept of sessions.

A session is a persistent connection with the remote computer. The New-PSSession cmdlet is used to open a session with one or more computers. Existing sessions can be viewed with the Get-PSSession cmdlet. By using a variable to reference the sessions I’ve created, it’s easy to use the Session parameter instead of the ComputerName parameter on Invoke-Command. Now Invoke-Command will use the existing sessions and avoid the overhead of initializing and tearing down a session each time I run a command.

$session = New-PSSession –ComputerName DC1,Win7-2

Invoke-Command –Session $session –ScriptBlock {Get-Process –Name lsass}

I can store several sessions in a single variable, and add sessions to this variable later. All the sessions can be created and stored in a variable, and I can run the same command against them easily. This is useful if I need different credentials to access different computers. I can start sessions with different connection options, store them in a single variable, and run commands against them all.

If I need to work interactively with a remote computer, I can use the Session parameter of Enter-PSSession to utilize an existing session. I can use array notation to access a specific PSSession in my $session variable, or I can pipe the session object of Get-PSSession to the Enter-PSSession cmdlet.

Sessions also enable a very useful capability called implicit remoting. If I’m sitting at my workstation, there may be modules and snap-ins that I’ve installed to extend the capabilities in Windows PowerShell. But if I don’t happen to be sitting at my own computer or I’ve had to rebuild my administration workstation, I might not have those cmdlets available. Wouldn’t it be nice if I didn’t have to install the Remote Server Administrator Tools (RSAT) when I needed to run the Microsoft Active Directory cmdlets?

To use implicit remoting, I start a Windows PowerShell session with a computer that already has the modules, snap-ins, or tools I need installed. In this case I want to use the Active Directory cmdlets, so I’m connecting to a domain controller. Then I use Invoke-Command to load the Active Directory module into my Windows PowerShell session on the domain controller. Finally, I use Import-PSSession with the Module parameter to automatically generate a local proxy function for the each cmdlet in the module I specified. Now I can use these remote cmdlets as if they were installed locally.

$dcSession = New-PSSession –ComputerName DC1

Invoke-Command –Session $dcSession –ScriptBlock {Import-Module ActiveDir*}

Import-PSSession –Session $dcSession –Module ActiveDir*

When I type a local cmdlet, Windows PowerShell calls the local cmdlet. When I type one of these imported cmdlets, Windows PowerShell calls the proxy function that takes care of the remote call for me. Windows PowerShell “implicitly” uses remoting to make everything appear like it’s happening locally. I can open sessions to my domain controller or to my servers running Exchange Server or SQL Server, and I can use Windows PowerShell to manage them all without having any of the management tools installed locally.

~Jason

WooHoo. Awesome job, Jason. Thank you for sharing your insights with us. We look forward to the exciting conclusion tomorrow.

Ed Wilson, Microsoft Scripting Guy

An Introduction to PowerShell Remoting Part Three: Interactive and Fan-Out Remoting

Anonymous — Wed, 25 Jul 2012 05:00:00 GMT

Summary: Guest blogger, Jason Hofferle, talks about Windows PowerShell Interactive and fan-out remoting.

Microsoft Scripting Guy, Ed Wilson, is here. TechReady 15 in Seattle has been a great event. I am really enjoying getting to see friends. Of course, I am also really enjoying Jason’s series about PowerShell Remoting. As a refresher here is a bit about Jason:

Blog: Force Multiplication through IT Automation
Twitter: @jhofferle

In Part Two of this series, Configuring PowerShell Remoting, I discussed how to configure PowerShell Remoting in your environment. Now we’re going to take a look at how it can be used after it’s up and running.

There are two primary PowerShell Remoting usage paradigms for IT professionals: interactive and fan-out. Interactive remoting is used when I need to interact with a remote computer as if I was sitting directly in front of the system, logged into the console. Fan-out remoting is used when I have a single command or script that I want to run on a group of computers. It could be two systems, or two thousand systems. Whenever I need a command to efficiently execute on a large number of systems, fan-out is the way to go.

To use interactive remoting, or one-to-one, I utilize the Enter-PSSession cmdlet with the ComputerName parameter. When my prompt changes to reflect the remote computer’s name, I know that I’m interacting with the remote system. This is great for performing actions that don’t have built-in functionality for performing actions against remote systems, such as registering a dynamic link library (DLL) to correct an issue. When I’m finished working on the remote computer, the Exit-PSSession cmdlet closes the session, and my prompt returns to the local operating system.

Enter-PSSession –ComputerName DC1

Set-Location C:\Windows\System32

Regsvr32.exe .\capiprovider.dll /s

When I want to use fan-out remoting, or one-to-many, I turn to the Invoke-Command cmdlet. This time I use a list of computer names for the ComputerName parameter, and I provide the command that I want them to run for the ScriptBlock parameter. Because the command executes on the remote computer, tasks such as searching and filtering the event log are performed locally, and only the information I want is sent over the network. When using Invoke-Command, each returned object has a PSComputerName parameter added, which enables me to determine which remote computer each object came from.

Invoke-Command –ComputerName DC1,Win7,Win7-2 –ScriptBlock {Get-Service The*}

Typing commands into a script block can be tedious and error prone when it’s more than something simple. Invoke-Command has a FilePath parameter than can be used when an entire script needs to be executed remotely. Windows PowerShell takes the .ps1 file on the local computer, and converts it into a script block automatically.

Invoke-Command –ComputerName DC1,Win7 –FilePath C:\MyScript.ps1

PowerShell Remoting can also be used in conjunction with background jobs. The AsJob parameter of Invoke-Command allows a long-running PowerShell Remoting command to run in the background, freeing up the Windows PowerShell console for other tasks. When the job has completed, the results can be retrieved with the Receive-Job cmdlet.

Invoke-Command –ComputerName DC1,Win7 –ScriptBlock {Get-Service WinD*} –AsJob

PowerShell Remoting is extremely useful in situations where I need to quickly collect information from systems, like performing ad-hoc queries on event logs. During a recent deployment of Windows 7, we experienced frequent issues with Outlook losing connectivity with Exchange. It was determined that a specific chip set combined with a particular driver on this particular operating system enabled a power-saving feature on the network adapter. Every time the monitor went into sleep mode, the adapter renegotiated the network speed to the lowest possible value. This disconnected the network for a few seconds, which was enough to cause Outlook to complain. Users would come back from a meeting and find that Outlook wasn’t working correctly.

After the fix was deployed to the Windows 7 test group, we needed to prove that the issue had been resolved. I used PowerShell Remoting to collect network disconnection events from our Windows 7 systems, exported the results to a comma separated values file, and then used Microsoft Excel to generate a chart showing how the disconnection events significantly dropped after the fix. In a few minutes, I was able to produce hard evidence that we resolved our remaining issue and get the green light for Windows 7 deployment.

~Jason

Way cool stuff, Jason. Thank you for taking the time to share with us today. We look forward to Part Four tomorrow.

Ed Wilson, Microsoft Scripting Guy

An Introduction to PowerShell Remoting Part Two: Configuring PowerShell Remoting

Anonymous — Tue, 24 Jul 2012 05:00:00 GMT

Summary: Guest Blogger, Jason Hofferle, continues his series about PowerShell Remoting.

Microsoft Scripting Guy, Ed Wilson, is here. This week I am in Seattle, Washington speaking at Microsoft TechReady 15. Therefore, we have a series written by guest blogger, Jason Hofferle, about PowerShell Remoting. Here is a little bit about Jason:

Blog: Force Multiplication through IT Automation
Twitter: @jhofferle

In the first blog post of this series, An Introduction to PowerShell Remoting: Part One, I took a look at what PowerShell Remoting is and how it takes advantage of the Web Services for Management (WSMan) framework to provide a uniform way to manage remote computers. Maybe after seeing some of the possible performance benefits, you’ve decided to at least take a closer look at what’s required to get it up and running in your environment. In this post I’m going to discuss the requirements and configuration.

PowerShell Remoting requires that Windows PowerShell 2.0 is installed on all computers that are being remotely managed or being used to connect to those remote systems. Windows 7 and Windows Server 2008 R2 include Windows PowerShell 2.0 with the operating system. For older operating systems, the Windows Management Framework Core can be downloaded and installed on Windows Vista, Windows XP, Windows Server 2008, and Windows Server 2003. The framework includes WinRM 2.0 and Windows PowerShell 2.0, and it requires the Common Language Runtime (CLR) 2.0, which is included with the Microsoft .NET Framework 2.0 or later.

Even on operating systems that include the necessary components, PowerShell Remoting is disabled by default, so it needs some configuration before it can be utilized. The WinRM service needs to be running, and a listener has to be configured, which tells the computer to listen for incoming connections. Also, the Windows firewall needs to be configured with rules to allow incoming connections.

PowerShell Remoting is incredibly simple to configure in a domain environment by using Group Policy. On a server operating system, the Windows Remote Management service is set to start automatically, but on a client operating system, this needs to be configured. Setting services to start automatically can be done at Computer Configuration\Windows Settings\Security Settings\System Services.

To setup the listener, the Enable Automatic Configuration of Listeners setting can be configured at Computer Configuration\Administrative Templates\Windows Components\Windows Remote Management (WinRM)\WinRM Service. An IP can be specified for systems that have multiple IP addresses assigned, or asterisks can be used to listen to all addresses.

The firewall exception can be added at Computer Configuration\Administrative Templates\Network\Network Connections\Windows Firewall\Domain Profile. If there are no Windows XP or Windows Server 2003 systems that need to be configured, the firewall exceptions can also be configured through Computer Configuration\Windows Settings\Security Settings\Windows Firewall with Advanced Security\Inbound Rules by using a predefined rule for Windows Remote Management.

If Group Policy isn’t an option, or PowerShell Remoting needs to be configured on an individual basis, the Enable-PSRemoting cmdlet can be used to perform the tasks of enabling the WinRM service, configuring the listener, and putting firewall rules into place.

PowerShell Remoting is pretty straightforward to configure when all the computers are joined to the same Active Directory domain and running on the same network. Going beyond the internal corporate network scenario requires some additional configuration depending on the particular situation.

One of the first issues commonly experienced is the concept of trusted hosts. When I’m connecting to a remote computer, I want to verify that computer’s identity before passing it my user credentials. When using Kerberos authentication in a domain, Windows PowerShell knows that it can trust the other computer because the domain controller is capable of verifying that system’s identity. When not in a domain environment, Windows PowerShell has no way of knowing if the system you’re trying to connect to is a malicious system spoofing as a legitimate computer.

So I either need a way to verify that computer’s identity, or bypass the security precaution. By having a certificate installed on the computers from a trusted certification authority (CA), that certificate can be used to verify the system’s identity. The alternative is to modify the trusted hosts section of the WinRM configuration to say, “I know the identity of this system cannot be verified, but let me connect anyway.” Even in a domain environment, trusted hosts may need to be configured if using IP addresses to specify computers. Kerberos protocol will only work with computer names, so Windows PowerShell will default to NTLM authentication any time an IP address is used.

There are many WSMan configuration options, and not all of them can be managed with Group Policy. Windows PowerShell provides a WSMan: drive that can be used to view and modify the configuration.

Cd WSMan:\localhost\client

Set-Item –Path TrustedHosts –Value *.testlab.local –Force

Another option for configuring WSMan is the winrm VBScript. I like using this to view my configuration because it tells me which settings are being configured with a Group Policy Object.

There are many different ways that PowerShell Remoting can be configured, and beyond the basics, it really depends on the specifics of the environment. Fortunately, there is a wealth of information about these scenarios and more in the about_remote_requirements and about_remote_troubleshooting Help files, which provide solutions for dealing with various issues when you are trying to get PowerShell Remoting working.

~Jason

Awesome job, Jason. Thank you for sharing your insights with us. We look forward to Part Three tomorrow.

Ed Wilson, Microsoft Scripting Guy

An Introduction to PowerShell Remoting: Part One

Anonymous — Mon, 23 Jul 2012 05:00:00 GMT

Summary: Guest blogger, Jason Hofferle, talks about the basics of Windows PowerShell remoting.

Microsoft Scripting Guy, Ed Wilson, is here. This week I am in Seattle, Washington presenting at Microsoft TechReady 15. I have been talking to Jason for some time, and I thought that now would be a great chance to share some of his insights with us. This is the first in a series of five blogs by Jason.

Blog: Force Multiplication through IT Automation
Twitter: @jhofferle

As Windows PowerShell enthusiasts go, I might be considered a late adopter. I’ve kept tabs on Windows PowerShell since it was called Monad, but it wasn’t until it was included with the Windows 7 operating system that I really started using it on a consistent basis. When version 2 was released, it included some game-changing features that convinced me Windows PowerShell was the future. One of these features is PowerShell Remoting, which allows me to run commands on a remote system as if I was sitting in front of it. It provides a consistent framework for managing computers across a network.

When I start explaining PowerShell Remoting to others, sometimes the initial reaction is, “Big deal,” because there are already many techniques available for working with remote computers. We have Windows Management Instrumentation (WMI), which is commonly used with VBScript. We have executables from resource kits or non-Microsoft tools that allow remote management, for example, the Sysinternals PSExec tools. Even many of the Windows PowerShell cmdlets have a ComputerName parameter to specify remote computers. So how does PowerShell Remoting differ from the capabilities we already have? Why should someone go through the trouble of enabling this feature when so many tools are available that don’t have a dependency on PowerShell Remoting?

Many of these methods have their downsides. First of all, there’s no consistency between utilities. One command may require parameters with a slash, the next wants a slash with a colon, and many handle quotation marks differently than others. The knowledge gained from learning one tool doesn’t transfer to another, so when I need to perform a different administrative task, I need to read through documentation and deal with the quirks of a new utility.

Another issue is that many use distributed COM (DCOM) or remote procedure call (RPC) to connect to remote systems. This may work well on a single internal network, but it causes problems when these tools need to traverse firewalls or play nice with intrusion prevention or other security systems. I don’t know too many firewall administrators who want to open up RPC ports. Finally, existing tools sometimes work differently depending on if a command is being run locally or remotely. I’ve had several occasions using WMI with VBScript where something is working perfectly on my local system, but it fails miserably when I try it on a remote computer because that particular application programming interface (API) can only be used locally. Wouldn’t it be nice if we could have consistent management commands that worked no matter where they were being run?

PowerShell Remoting is a solution to some of the security and consistency issues that IT professionals currently work around. It’s built on Microsoft’s implementation of the Web Services for Management (WSMan) protocol, and it uses the Windows Remote Management (WinRM) service to manage communication and authentication. This framework was designed to be a secure and reliable method for managing computers that’s built on well-known standards like Simple Object Access Protocol (SOAP) and Hypertext Transfer Protocol (HTTP).

Unlike utilities that use various programming interfaces to talk to a remote computer, PowerShell Remoting connects my local Windows PowerShell session with another session running on the remote system. The commands that I enter are sent to the remote computer, executed locally, and then the results are sent back. Because all commands run locally, I don’t have to worry about an individual cmdlet lacking the plumbing to work across my network. Everything runs on the same framework, so I only need to learn the Windows PowerShell way of executing remote commands.

A major advantage over other methods of remote management is that a single port is used for every application that uses WSMan. Instead of poking different holes in a firewall for every application, only the port used by WSMan needs to be configured, and the WinRM service will make sure the traffic gets routed to the correct application.

There are several authentication methods, including Kerberos protocol and Windows Challenge/Response. The communication between two computers is encrypted at the protocol layer, except when basic access authentication is used, which is intended for use with Hypertext Transfer Protocol Secure (HTTPS) sessions.

Besides the simplicity of PowerShell Remoting (after it’s configured, there is very little to worry about), there are some massive performance benefits when using one-to-many or fan-out remoting. These performance benefits convinced me to start converting some of my VBScript scripts into Windows PowerShell because it saved so much time. With fan-out remoting, I provide Windows PowerShell a list of computers along with the command I want them to run. Windows PowerShell “fans-out” and sends the command to the remote computers in parallel. Each remote system runs the command locally and sends the results back. This is different from the common VBScript technique of using a foreach loop to perform operations against a list of computers, one at a time.

When talking about PowerShell Remoting at a conference or similar event, it’s difficult to demonstrate the benefits because fan-out doesn’t really reach its potential until I throw hundreds or thousands of computers at it. It sounds powerful on paper, but I needed some real-world numbers to help communicate the effectiveness. I also needed some data to convince my own organization, so I performed some tests that would help articulate how powerful this feature can be.

A scenario where I commonly use PowerShell Remoting is when I need to query a large number of computers for a specific event. For my performance testing, I decided to search the security event log for the last twenty log-on events. To get baseline data without using PowerShell Remoting, I stored a list of computer names in a $Computers variable and piped it to a loop.

$Computers | foreach { Get-WinEvent –FilterHashTable @{logname=”security”;id=4624} –MaxEvents 20 –ComputerName $_ }

For the comparison, I used the same Get-WinEvent cmdlet, but in conjunction with Invoke-Command, which is a PoweShell Remoting command. Invoke-Command takes my list of computer names and tells them to run the command specified in the script block. The ThrottleLimit parameter is telling Windows PowerShell to connect to 50 computers simultaneously.

Invoke-Command –ComputerName $Computers –ScriptBlock { Get-WinEvent –FilterHashTable @{logname=”security”;id=4624} –MaxEvents 20 } –ThrottleLimit 50

By using a foreach loop, similar to how it might be done with VBscript or without PowerShell Remoting, it took over six hours to complete the operation against 100 computers. By using PowerShell Remoting, it took 15 seconds. This is a real-world situation on a production network against Windows 7 computers that were multiple wide area network (WAN) hops away in many cases. By using this same command, I increased the number of computers to see how well it scaled.

With PowerShell Remoting, I can retrieve the last twenty log-on events from the local security log on 1000 workstations in a little over two minutes.

PowerShell Remoting is the killer feature in Windows PowerShell. When it’s configured in an environment, it provides a transparent and efficient framework for managing computers. It has saved me countless hours and simplified many daily tasks. No matter what type of environment you have, PowerShell Remoting is worth checking out.

~Jason

Thank you, Jason, for an excellent blog. We look forward to Part Two tomorrow.

Ed Wilson, Microsoft Scripting Guy

Updating Group Policy on a Dark and Stormy Night

Anonymous — Wed, 17 Aug 2011 05:00:00 GMT

Summary: Guest Blogger Jason Helmick talks about updating an Enterprise GPO on a dark and stormy night using Windows PowerShell.

Microsoft Scripting Guy Ed Wilson is here. Guest Blogger Week continues today with Jason Helmick as our guest.

About the author

Jason Helmick is an Instructor at Interface Technical Training and specializes in Windows PowerShell. Jason and Mike Pfeiffer are the founders and hosts of the Arizona PowerShell User Group.

You can find Jason at:

Blog: jasonhelmick.com
Twitter: @theJasonHelmick

An enterprise GPO update on a dark and stormy night

It was a dark and stormy night in the data center. The rain fell in clumps, pounding the roof. "I hope those roof tiles hold tonight." I spoke out loud as I often do. I received the response I expected: a loud CLAP of thunder and more rain.

"I need to get these web servers deployed before morning!" The day was not a good one, filled with one emergency after another. I normally do not mind. The junior administrator staff normally handles the fires, but today was different.

It started at noon with the boss walking into my office. He sat down heavily in the chair I save for honored guests, the one next to the candy bowl. He is in the wrong chair again. He looked up and spoke: "Jason I need a new deployment of web servers on the middle tier by morning. The junior guys are racking the boxes and getting a base operating system deployed. I need 24 new web boxes or the new product launch fails. The developers tell me they can test and launch the site in the morning, but they don't think your department will be ready."

I was watching his right hand as he spoke. He usually manages to steal some of my candy, the candy I put there for special guests. I raised my eyes and smiled. "No problem." He stood with a start, "Good, then I'll see you at the launch in the morning!" With a gruff turn, he left. The rain was beginning to pound the roof harder.

I rose and closed the door to my office. No need to let my secrets slip out to the other IT admins. This was going to be a job for PowerShell Man. "This is going to be easy!" I again said out loud. "I'll grab the computer names from Active Directory, build a PowerShell remote session to them, and then load and run the ServerManager cmdlets to install the web servers. Easy!"

All I need to do is type—SCREAM! LOUD CRASH! "Help! The roof is leaking all over my Windows 7 PC!" The shrill of her voice made my spine freeze. Alice needed my help quickly, so I had better get this problem solved fast.

All I need to do is start by importing the Active Directory module. I’m running Windows Server 2008 R2, so I just installed the RSAT-ADDS tools with ServerManagerCMD –I RSAT-ADDS, but I keep a great article around in case I need them on a Windows 7 computer.

Import-Module ActiveDirectory

New-PsSession -computername (Get-ADcomputer -filter {name -like Web*} | Select-Object -ExpandProperty name)

"Dang!" THUNDER CLAP! "Remoting is not enabled on the new web servers!"

Yes, I like the Don Jones idea of coloring my errors green. It makes the errors seem less repulsive and more inviting. You can add this line to your profile to do the same.

$host.PrivateData.ErrorForegroundColor = "green"

I made a quick phone call to the junior administrators, also known as “the screw driver crew.” No one answered. There was no one to run out to the servers and enable Windows PowerShell remoting.

YELLING: “Someone help me, water is pouring all over my desk!” I needed to rescue Alice, but I also just needed to get this done!

I can create a GPO for the servers that enables Windows PowerShell remoting! Now where is that darn link that describes the GPO settings?

I quickly added the remoting and script execution GPO for the web servers. Using the GPO article, I modified the following keys:

I enable “Allow automatic configuration of listeners,” and set IPv4 and IPv6 to “*”. The key can be found at the following location:

Computer Configuration\Policies\Administrative templates\Windows Components\Windows Remote Management\WinRM Server
I also wanted to enable script execution in case I need it later. I enabled “Turn on Script Execution” and set the policy setting to “Allow only signed scripts”. I always sign my scripts to be the most secured. The key can be found at the following location:

Computer Configuration\Policies\Administrative templates\Windows Components\Windows PowerShell\
In addition, I wanted to set the WinRM service to start automatically, so I set the Windows Remote Management service to “Automatic” at this key:

Computer Configuration\Policies\Windows Settings\Security Settings\System Services\
Last, if I had Windows Firewall running on those computers, I would need an Inbound Rule because WinRM listens on port 5985. Again, I checked this article to get it right. The key can be found at the following location:

Computer Configuration\Policies\Windows Settings\Windows Firewall with Advanced Security\

It took me about a minute to set the GPOs, but it would take time for the servers to update the policy—too much time. Alice was in bad shape. Like a sinking ship, she was up to her wheelhouse.

I knew I could restart all the servers with a Windows PowerShell cmdlet, but that is crazy. I just needed to update the policy! LOUD THUNDER CLAP! Gently, I felt a cool touch and a slight whisper in my left ear. The message wasn’t clear so I responded to the haunting voice: “Go to the Bonsai tree in my forest?”

LOUD THUNDER CLAP!

“No, you fool. Do you have BSonPoSH cmdlets for your Active Directory forest!?” Ah, it was The Scripting Guy, Ed Wilson! “Hey Scripting Guy, I don’t have the BSonPoSH cmdlets!” He responded with a gruff grumble, something about me not checking his blog on a regular basis, and then magically on my screen the URL appeared. “Go there and install them.”

Astonished at his power over my computer screen, I gasped, “But how is that going to help me, Scripting Guy?!” I could tell there was a slight pause of exacerbation before he responded.

“Get-Help and Get-Command shall lead you to the solution.” I quickly installed the cmdlets, imported the module (Import-Module BSonPosh) and typed Get-Help GPO.

That’s it! That’s the cmdlet I needed! A quick look at the full help for the cmdlet showed me that –computername expected string input and could be piped to both ByValue and ByPropertyName.

SCREAM! “I’m going to drown!” GURGLE!

I started to stand up and race from the office to save Alice, but, just needed to type one more thing. I imported the modules for ActiveDirectory and BSonPosh, and then updated the policies with the Update-GPO cmdlet:

Import-Module ActiveDirectory

Import-Module BSonPosh

Get-ADComputer –filter {name –like ‘web*’} | Select-Object –ExpandProperty name | Update-GPO

Without wasting anymore of Alice’s life than I needed to, I finished with a quick Windows PowerShell remote session installation of a web server.

$Session=New-PSSession –computername (Get-ADComputer –filter {name –like ‘Web*’} | Select-Object –ExpandProperty name)

Invoke-Command –Session $session {Import-Module ServerManager}

Invoke-Command –Session $ssesion {Add-WindowsFeature Web-Server}

Done!

I ran to Alice’s cube and reached into the murky water. I felt a hand and then a Windows 7 PC. I lifted them both to safety. As I escorted Alice from the building a gentle whisper returned to my left ear.

“Well done. Remember that the Scripting Community has many resources. Spend your time there.”

I sank back into my office chair closing up for the night. “Hey Scripting Guy? Want some candy before you go?”

And with a squeak of the chair opposite me, I knew my Active Directory management experience was just beginning. So many wonderful cmdlets: those by Microsoft, Quest, and of course BSonPoSH can help me manage a better Active Directory and network. The storms cleared and the rain stopped. In the morning, my boss came into the office again and sat in the wrong chair.

“I see you deployed the web servers. Must have taken you all night. Good job.” At that moment, he sneaked a candy, the ones I reserve for special guests.

I want to thank Jason for writing both an entertaining and informative guest article. Join us tomorrow as Guest Blogger Week continues with Thiyagu and part 1 of a two-part blog post about Exchange message headers.

Ed Wilson, Microsoft Scripting Guy

Use PowerShell Invoke-Command for Remoting

Anonymous — Mon, 13 Jun 2011 05:00:00 GMT

Summary: Microsoft Windows PowerShell MVP, Don Jones, talks about using the Invoke-Command cmdlet for remoting.

Microsoft Scripting Guy, Ed Wilson, here. I am really excited about the idea I had for this week, and I hope you will be too. I asked Candace Gillhoolley at Manning Press about posting some sample works from some of the Manning Press library of books. She responded enthusiastically and shared five samples that we will post this week. Today we present Don Jones’ Learn Windows PowerShell in a Month of Lunches.

Learn Windows PowerShell in a Month of Lunches

By Don Jones

One of the coolest things in Windows PowerShell is to send a command to multiple remote computers at the same time. In this article, based on chapter 10 of Learn Windows PowerShell in a Month of Lunches, author Don Jones explains how to use the Invoke-Command cmdlet to execute one-to-many, or 1:n, remoting. To save 35% on your next purchase, use Promotional Code jones1035 when you check out at www.manning.com.

Using Invoke-Command for Remoting

The trick I will show you in this article—and one of the coolest things in Windows PowerShell—is to send a command to multiple remote computers at the same time. That’s right, full-scale distributed computing. Each computer will independently execute the command and send the results right back to you. It’s all done with:

Invoke-Command -computername Server-R2,Server-DC4,Server12
[ CA]-command { Get-EventLog Security -newest 200 |

[ CA]Where { $_.EventID -eq 1212 }}

Try it now

Go ahead and run this command. Substitute the name of your remote computer (or computers) where I’ve put my three computer names.

Everything in those outermost {braces} will get transmitted to the remote computers—all three of them. By default, PowerShell will talk to up to 32 computers at once; if you specified more than that, it will queue them up, so that, as one computer completes, the next one in line will begin. If you have a really awesome network and powerful computers, you could raise that number by specifying the -throttleLimit parameter of Invoke-Command—read the command’s help for more information.

Be careful about the punctuation

We need to pause for a moment and really dig into that example command because this is a case where Windows PowerShell’s punctuation can get confusing, and that confusion can make you do the wrong thing when you start constructing these command lines on your own. There are two commands in that example which use curly braces: Invoke-Command and Where (which is an alias for Where-Object). Where is entirely nested within the outer set of braces. The outermost set of braces enclose everything that is being sent to the remote computers for execution; that includes:

Get-EventLog Security -newest 200 | Where { $_.EventID -eq 1212 }

I should tell you that you won’t see the -command parameter in the Help for Invoke-Command—yet, the command I just showed you will work fine. The -command parameter is actually an alias, or nickname, for the -scriptblock parameter that you will see listed in the Help. I just have an easier time remembering -command, so I tend to use it instead of -scriptblock—but they both work the same way.

If you read the help for Invoke-Command carefully (see how I’m continuing to push those help files?), then you’ll also notice a parameter that lets you specify a script file, rather than a command. That parameter lets you send an entire script to the remote computers—meaning, you can automate some pretty complex tasks and have each computer do its own share of the work.

Try it now

Make sure you can identify the -scriptblock parameter in the help for Invoke-Command and that you can spot the parameter that would enable you to specify the file path and name instead of a scriptblock.

I want to circle back to the -computername parameter for just a bit. When I first used Invoke-Command, I typed a comma-separated list of computer names, just as I did in the example above. But I have a lot of computers I work with, so I didn’t want to have to type them all in every time. I actually keep text files for some of my common computer categories, like Web servers and domain controllers. Each text file contains one computer name per line, and that’s it—no commas, no quotes, no nothing. Windows PowerShell makes it really easy for me to use those files:

Invoke-Command -command { dir }
[ CA]-computerName (Get-Content webservers.txt)

The parentheses there force Windows PowerShell to execute Get-Content first—pretty much the same way parentheses work in math. The results of Get-Content are then stuck into the -computerName parameter, which then works against each of the computers that were listed in the file.

I also sometimes want to query computer names from Active Directory. This is a bit trickier. I can use the Get-ADComputer command (from the ActiveDirectory module in Windows Server 2008 R2) to retrieve computers, but I can’t just stick that command in parentheses like I did with Get-Content. Why not? Because Get-Content is just producing simple strings of text, which -computername is expecting. Get-ADComputer, on the other hand, is producing entire computer objects, and the -computername parameter won’t know what to do with them. So if I want to use Get-ADComputer, I need to find a way to just get the values from those computer objects’ Name properties. Here’s how:

Invoke-Command -command { dir } -computerName (

[ CA]Get-ADComputer -filter * -searchBase "ou=Sales,dc=company,dc=pri" |

[ CA]Select-Object -expand Name )

Try it now

If you’re running Windows PowerShell on a Windows Server 2008 R2 domain controller or on a Windows 7 computer that has the Remote Server Administration Toolkit installed, then you can run Import-Module ActiveDirectory and then try the above command. If your test domain doesn’t have a Sales OU that contains a computer account, then change ou=Sales to ou=Domain Controllers and be sure to change company and pri to the appropriate values for your domain. (For example, if your domain is mycompany.org, you would substitute mycompany for company and org for pri.)

Within the parentheses, I’ve piped the computer objects to Select-Object, and I’ve used their -expand parameter. I’m telling it to expand the Name property of whatever came in—in this case, those computer objects. So, the result of that entire parenthetical expression will be a bunch of computer names, not computer objects—and computer names are exactly what the -computername parameter wants to see.

By the way, just to be complete, I should mention that the -filter parameter of Get-ADComputer specifies that all computers should be included in the command’s output. The -searchBase parameter tells the command to start looking for computers in the specified location—in this case, the Sales OU of the company.pri domain. The Get-ADComputer command is only available on Windows Server 2008 R2 and on Windows 7 after installing the Remote Administration Server Toolkit (RSAT). On those operating systems, you have to run Import-Module ActiveDirectory to actually load the Active Directory cmdlets into the shell so that they can be used.

Ideas for on your own

One of the Windows PowerShell modules included in Windows 7 is Troubleshooting Pack, which provides command-line access to the new troubleshooting pack functionality in the operating system. I always tell my students and clients to consider enabling Windows PowerShell remoting on all of their client computers, in part because it gives you remote command-line access to those troubleshooting packs. When a user calls for help, rather than walking them through a wizard over the phone, you can just remote in and run the same wizard, in command-line form rather than GUI form, yourself.

Guest Writer’s Week will continue tomorrow when we will have a post from Richard Siddaway.

Ed Wilson, Microsoft Scripting Guy