Chapter 21. Adding automatic remoting to advanced functions and cmdlets
This chapter’s goal is to present a design pattern to help you produce PowerShell modules that contain professional-grade cmdlets that are easy and intuitive for users to run both locally and remotely with a commercial-grade user experience. This chapter focuses on the intricacies of using a PowerShell script to create cmdlets that are robust and have built-in remoting functionality. I’ll talk briefly at the end about nuances and strategies for turning your functions into enterprise-grade modules. This chapter presumes familiarity with PowerShell remoting. If you’re not familiar with the ins and outs of fan-in and fan-out in PowerShell remoting, then get-help About_Remote is a good place to start.
For the most part, solutions have their value in solving a quantifiable problem. Compared to other languages and platforms, distributed computing with PowerShell remoting is easier and can save you time. Something that may take weeks to engineer on another stack may be completed in half an hour by a seasoned PowerShell scripter. The problem is that most users of your cmdlets are not seasoned PowerShell scripters, and even if they were, half an hour is longer than the 5 or 10 seconds that it would take to call your cmdlet locally. Let’s produce a user experience in which running your cmdlet against a set of computers is as easy for the user as running Get-Process locally.
