Adding modules into PowerShell 3.0 ISE for services running on other machines

In my last blog I talked a little about the new Commands menu within the PowerShell 3.0 ISE, the ability to view all the cmdlets relating to an individual module, and then use it to build a command.

It's a great feature and of course there are a lot of modules out there for different applications and services. As you install new roles and features that use their own set of modules the installer adds those modules into the list, so by default the PowerShell ISE modules list contains all the modules relevant to the local installation.

But what if you want to write your script and insert cmdlets into it on a machine that doesn't have those roles or features installed? You could install the relevant management pack, but that seems somewhat overkill to me.

The other option is to simply copy the relevant files from a machine that already has them.

All of the module files installed on a machine can be found in :

c:\windows\system32\WindowsPowerShell\v1.0\Modules\

with an individual folder for each module installed. These obviously get loaded when PowerShell ISE loads.

To make these available on another machine, for instance making the DNS Server module show up on your desktop machine, simply copy the relevant folder(s) (in this case DnsServer) from a server that it's installed on, into the modules folder on your target machine (your desktop).

The next time you load the PowerShell ISE you'll find the module and its list of cmdlets listed and available for use. This way on one machine you can have all your required modules, be they SQL Server, Exchange Server, Active Directory, DNS Server etc on a single machine.

Update:

Just to avoid confusion, my intention when finding this method was simply to allow me to write the code on my local machine, NOT to allow me to execute the cmdlets locally. Using the -Computer parameter to specify the machine to run the command against won't work, since your local machine is missing the required dll's. That said, if you've established a connection to the remote server, eg using Enter-PSSession, then the cmdlets generated on your local machine can be run since you're using the dll's on the remote machine not the local ones.

 

PowerShell v3 and new features including DNS Server cmdlets

With the introduction of PowerShell v3 in Windows Server 2012 we now have a new collection of cmdlets to play with, and amoung them are a collection of cmdlets for controlling and administering DNS Server.

As someone who's been rewriting many old batchscripts to use PowerShell, and is also in the process of migrating to a new 2012 DNS setup this obviously came as great news. No more using PowerShell as a wrapper for dnscmd or having to dig into WMI calls. Unfortunately as is often the case being up to date has its drawbacks, yep, you guessed it, there's a definite drought of documentation out there explaining how to use it all. There are other additions as well, but DNS Server's the area I've been playing with recently.

For a straight forward list of DNS cmdlets check out http://technet.microsoft.com/en-us/library/jj649850%28v=wps.620%29.aspx. Once you know which cmdlet you need the easiest option is perhaps to use the Commands menu within the PowerShell v3 ISE, which if not already displayed on the right hand side can be viewed by selecting View and then Show Command Add-on.

Using the new commands menu definitely helps, for any cmdlets you haven't used before. Selecting the DnsServer option from the modules list gives you a list of the available cmdlets in that category, and selecting one of them displays the parameter details for it. Note, where the options change depending on what you're doing (for instance using Add-DnsServerResouceRecord, where A records have different options to MX records etc), you'll see tabs along the top to allow you to select the required set of parameters. Simply fill in the required text boxes, and then click Insert, the complete PowerShell command line using those parameters will be created in the bottom window. Either run it there or copy and paste the code into your script.

If you're unsure which details need to go into which box, the -WhatIf parameter will let you know what your current selection would do if it was run (without actually doing it and potentially doing something wrong / unexpected). The WhatIf parameter isn't new to v3, but its combination and availability in the commands menu makes it even more useful. One thing worth noting about the -WhatIf parameter is that it gives an overview of what will happen, not always the exact detail. Take the following example :

Add-DnsServerResourceRecord -DomainName mail.domain.com -Name _autodiscover._tcp -Port 443 -Priority 0 -Srv -Weight 0 -ZoneName foo.com -WhatIf

The output produced will be :

What if: Adding DNS resource record _autodiscover._tcp of type SRV in zone foo.com on MYSERVER server.

You'll see that it confirms the command will create the resource record, that it's an SRV record, where it is and in which zone, but not the finer details. So if you put the port details in the wrong place then WhatIf won't help.

That's enough for now, the next couple of blogs will be looking at specific DNS Server cmdlets and how they can be used.