by willsteele at 2012-09-07 19:55:38
So, I have a domain with 150 machines. Right now we are all set up with a mix of Powershell 1 and 2. I am trying to get our team to push out WMF 3.0 in our next set of updates. Once I have WMF 3.0 on my machines, what are the basic steps I need to perform to enable the ability to take advantage of fan-out management? I know with WMF 2.0 you have enable remoting, configure listeners, etc. However, I have never gotten a good working set of more than one or to machines. With WMF 3.0 (and workflows) will it be enabled/configured by default even on older machines (2003/2008/2008 R2) or is that only on 2012? I am trying to figure out if I need to go ahead and manually handle the configuration of the old machines that don’t work at the moment.by coderaven at 2012-09-08 05:52:07
To start taking advantage or fan out management, not much is needed to get moving. You can take some of your existing functions and combine them with a simple workflow to start taking advantage right away.by DonJ at 2012-09-08 10:55:52
For example, I have created a function Get-MyServerHealth which takes a -ComputerName parameter. And each morning I run it from my computer against a list of my servers. Since I watch 50 servers, running Get-MyServerHealth -ComputerName (Get-Content .\Serverlist.txt) takes well… a long time, because it runs on one system at a time. It works and it is already fanning out, but wrapping it in a simple workflow allows me to run all of it much faster with out doing more complex stuff in my original function.
[code2=powershell]workflow Get-WFMyServerHealth
{
param([string]$ComputerName)
foreach -parallel($Computer in $ComputerName)
{
Get-MyServerHealth -ComputerName $Computer
}
}[/code2]
The parallel switch on the foreach command in the workflow tells it to execute these commands at the same time. All the actions would still run on my computer but I am using a simple workflow to increase the usefulness of my existing tools.
To get into some of the true power of workflows, remoting does get involved and I recommend you give Don Jones’s - Secrets of PowerShell Remoting - (http://powershell.org/wp/2012/08/06/ebook-secrets-of-powershell-remoting/) a good read, it does cover PowerShell 3.0
As for deploying PowerShell 3.0 and getting it configured, remoting is only enabled by default on Windows Server 2012. You can install WMF 3.0 on Windows 7 SP1, Windows 2008 SP2 and Windows 2008 R2 SP1. For your Windows XP, Windows 2003 Servers, computers and older, you must stick with PowerShell 2.0. If getting your systems configured for remoting and even some of the memory needs to execute long running task, consider using Group Policy.
Any system running PowerShell 3.0 can execute a Workflow. Computers running PowerShell 2.0 can remote into a computer with PowerShell 3.0 and execute a Workflow on that system.
Hope that helps!
[quote]what are the basic steps I need to perform to enable the ability to take advantage of fan-out management? I know with WMF 2.0 you have enable remoting, configure listeners, etc. However, I have never gotten a good working set of more than one or to machines. With WMF 3.0 (and workflows) will it be enabled/configured by default even on older machines (2003/2008/2008 R2) or is that only on 2012? I am trying to figure out if I need to go ahead and manually handle the configuration of the old machines that don’t work at the moment.[/quote]by willsteele at 2012-09-08 12:21:10
It’s the same in WMF 3.0 - you run Enable-PSRemoting, or you do it via GPO (which "Secrets of PowerShell Remoting" covers; it’s a bit harder). There’s nothing necessary for workflow beyond that. You’ll notice in most cases that Enable-PSRemoting creates a remoting endpoint specifically for workflow to use. Run Get-PSSessionConfiguration to verify. If you take the GPO approach, it’s on you to set up the necessary endpoints, so it’s definitely more work.
But if your goal is simply to parallelize effort…
[quote]I have created a function Get-MyServerHealth which takes a -ComputerName parameter. And each morning I run it from my computer against a list of my servers. Since I watch 50 servers, running Get-MyServerHealth -ComputerName (Get-Content .\Serverlist.txt) takes well… a long time, because it runs on one system at a time.[/quote]
You don’t need workflow for that, and workflow would be a significantly more complex way of simply getting parallelization. This is one of the concerns I have around the messaging we’ve been seeing for workflow - it’s as if everyone’s forgotten that v2 had perfectly capable features for achieving some of the same things. Not all, but parallelization is definitely one.
For example, rewrite your function to assume it’s being run on the local machine, and querying only local resource. In other words, get rid of its -computerName parameter entirely. Then:
Invoke-Command -computername (Get-Content .\Serverlist.txt) -filepath { c:\path-to-your-script.ps1 }
Ensuring that your PS1 file not only defines your function, but also calls it. E.g., define Get-MyServerHealth, and on the last line of the script, run it. That’ll parallelize in up to 32 simultaneous threads by default. You get all the results back locally, with the computer names attached magically.
If you’re planning to use remoting (and you should be), there’s little reason to ever write your own -computerName parameter. The whole point of remoting is that you write every function to run locally, and then let remoting push it out for you, and let it worry about parallelization. Add -AsJob to Invoke-Command if you’ve got a ton of machines, and let it all run in the background. Let the shell do the heavy lifting.
Workflow is a powerful feature, to be sure, but I think the right approach is to talk yourself into it, rather than talking yourself out of it - e.g., convince yourself that it’s the only way to get the job done, because it will be more complex.
Unfortunately we are dealing with a gimp 2003 domain that has lots of weirdness. It is the bain of our network admins life. Unfortunately the CISCO wizard who ran the network was not quite as proficient on AD. I need to pull up some of my machines and ask for specific help on getting one machine fully up and running. Once I do that, I think we should be good. The GPO was deployed, but, was not pushed across the forest (we have with dual-trust). One of those pull you hair out kind things. I keep hoping our team will get the domain up and running, but, not yet. My hope with WFM 3.0 was that it might allow us to bypass some of these issues. Let me play with what it outlined above on my test domain.by DonJ at 2012-09-08 12:49:48
Nope. WMF doesn’t change anything about how remoting gets turned on. And workflow depends on remoting - it doesn’t modify it.