Tag Archives: powershell

Microsoft’s VS Code embrace prompts PowerShell editor debate

Windows admins who write scripts with PowerShell ISE must switch allegiances if Microsoft has its way.

Since 2009, Microsoft has positioned the PowerShell Integrated Scripting Environment (ISE) as the official PowerShell editor to develop and debug scripts on Windows. But Microsoft’s effort to steer Windows, Linux and macOS users to PowerShell Core as an all-encompassing management tool requires a script editor that works on all those systems.

In May 2017, Microsoft named a new official PowerShell editor: Visual Studio Code (VS Code), a free, open source editor with a PowerShell extension so admins on multiple platforms can build PowerShell scripts. Microsoft continues to support PowerShell ISE for now but plans to focus development efforts on VS Code.

For IT engineers who code in multiple languages, VS Code is the recommended tool. It’s also a better tool even for people who only write PowerShell scripts and modules, said Jeffery Hicks, IT author and trainer.

“It’s the future,” he said. “ISE will no longer get improvements; we’re not going to see updates to it. What we have now is what we’re always going to have. VS Code is going to be continually updated, and they’ll fix bugs.”

Microsoft continues to support PowerShell ISE for now but plans to focus development efforts on VS Code.

While VS Code might be the future of PowerShell development, not everyone thinks it’s ready for prime time.

Jeff Wilson, an IT admin based in Los Angeles who works in a Windows shop, experiments with VS Code to learn how it works but quickly noticed it lacked some of PowerShell ISE’s functionality. ISE uses default profiles to let Wilson access all his administrative sessions — such as Exchange Online, SharePoint and Hyper-V clusters — without delay.

“It’s a huge time-saver, and it’s really valuable to me,” he said. “It’s the famous single pane of glass because it’s so flexible. So with VS Code, when I installed it, I wanted to duplicate the experience I had with ISE. … It wasn’t immediately evident to me how I would do that. That’s problematic, but [at least] I still have ISE.”

Expect a bumpy transition to VS Code

PowerShell ISE veterans such as Wilson will need time to adapt to the different layout and terminology in VS Code.

Admins use the integrated PowerShell console in PowerShell ISE to access menu items and keyboard shortcuts. With the integrated console, admins see the output as they write scripts. The console in VS Code needs work, Hicks said.

“The PowerShell integrated terminal that is shipping in VS Code now is not quite as feature-complete as it is in the ISE,” he said. “It’s still a little buggy, and it doesn’t quite feel the way you want it to. I have muscle memory [from PowerShell ISE], so when I do presentations, I still typically use PowerShell ISE because I can toggle between the code and the presentation on the full screen. I can’t really do that in VS Code.”

Despite these shortcomings, Hicks recommends admins move to VS Code as their PowerShell editor for its integration with the Git code management system and ability to auto-format code to make it easier to read.

PowerShell Studio gives scripts a GUI

For IT pros who want more advanced features from a PowerShell editor, a commercial product such as PowerShell Studio is another option.

Wilson builds front ends to his scripts with PowerShell Studio for his company’s help desk workers who want a point-and-click UI.

PowerShell Studio, which is a Sapien product, is Windows only, although Sapien also offers iPowerShell, a pared-down and free tool that’s designed for Mac, Android and iOS users who write scripts remotely. Additionally, Sapien’s PrimalScript product is compatible with PowerShell Core.

For Hicks — a former Sapien employee — one of the editor’s big selling points is that it builds a GUI on a PowerShell script, which isn’t possible in PowerShell ISE or VS Code. Admins can also use PowerShell Studio to export scripts as executable files, easily create modules, build advanced functions with multiple parameters, and auto-generate comment-based help for existing functions.

Wilson writes longer scripts and complex functions in PowerShell Studio, which he calls a more fully thought-out developing environment than ISE or VS Code. It also features a way to add a layer of security to the finished script.

“I always sign my scripts with a digital certificate and [PowerShell Studio] makes it easier to do,” Wilson said.

There’s a cost to this feature richness; a one-year subscription to PowerShell Studio 2017 is $389.

“If you don’t need 90% of the features, maybe it’s not worth your time and money,” he said. “But if that one feature Sapien offers [in PowerShell Studio] saves you a lot of time and money, then it’s worth it.”

Dan Cagen is the associate site editor for SearchWindowsServer.com. Write to him at dcagen@techtarget.com.

Filter and query Windows event logs with PowerShell

In addition to its automation capabilities, PowerShell helps the IT staff troubleshoot problems with Windows, specifically…


* remove unnecessary class from ul
$(“#inlineregform”).find( “ul” ).removeClass(“default-list”);

* Replace “errorMessageInput” class with “sign-up-error-msg” class
function renameErrorMsgClass() {
$(“.errorMessageInput”).each(function() {
if ($(this).hasClass(“hidden”)) {
$(this).removeClass(“errorMessageInput hidden”).addClass(“sign-up-error-msg hidden”);
} else {

* when validation function is called, replace “errorMessageInput” with “sign-up-error-msg”
* before return
function validateThis(v, form) {
var validateReturn = urValidation.validate(v, form);
return validateReturn;

* DoC pop-up window js – included in moScripts.js which is not included in responsive page
$(“#inlineRegistration”).on(“click”,”a.consentWindow”, function(e) {
window.open(this.href, “Consent”, “width=500,height=600,scrollbars=1”);

when they need to find errors in the Windows event logs. PowerShell parses logs and has a few more advantages over the numerous third-party tools at administrators’ disposal. Microsoft includes PowerShell for free with Windows, which gives it a cost advantage over other vendors’ products. Also, PowerShell connects deeply with the OS to provide many options to filter logs and query across multiple systems simultaneously.

Get-EventLog is the primary cmdlet administrators utilize to manage Windows event logs. This cmdlet shows the log’s contents with the -LogName parameter, followed by the name of the desired log file.

Log files can get large, but this cmdlet cuts results down to more easily reveal relevant events.

Use this command to show a summary of available log files:

Get-EventLog -List

PowerShell returns the log names and the number of events in each. Let’s focus on the Application log, which can contain several thousand entries. This command displays the Application log events:

Get-EventLog -LogName “Application”

The command output shows the log file’s full contents, which is not helpful. To filter the results, use this example to show the 10 most recent entries:

Get-EventLog -LogName “Application” -Newest 10

Next, take the command a step further, and find the 10 most recent errors with the -EntryType parameter:

Get-EventLog -LogName “Application” -EntryType “Error” -Newest 10

PowerShell also finds specific error occurrences. Find the 10 most recent instances of event 7670 — an issue related to SQL Server database access — with this command:

Get-EventLog -LogName “Application” -Index 7670 -Newest 10

Event 7670 often accompanies several other SQL Server events, such as 7671 or 7673. PowerShell specifies a range of event IDs rather than a single event ID. Let’s say you’re interested in event IDs 7670, 7671, 7672 and 7673. Use this command to view the 10 most recent SQL Server-related errors with those event IDs in the Application log:

Get-EventLog -LogName “Application” -Index(7670..7673) -Newest 10

Alternatively, the command to list SQL errors — which varies based on the SQL Server version — resembles this:

Get-EventLog -LogName “Application” -EntryType “Error” -Source “SQLLocalDB 11.0” -Newest 10

How to check logs on remote machines

PowerShell also filters log events on Windows systems across the network. The administrator must specify the -ComputerName parameter, followed by the NetBIOS name, fully qualified domain name or the target system’s IP address.

To show results from several computers, store the computer names in a variable, and then use a ForEach loop. If the server names are Server1, Server2 and Server3, for example, use these commands to query each server:


ForEach($Computer in $Computers){Get-EventLog -ComputerName $Computer -LogName “Application” -Newest 10}

The output does not list the name of the server with the event. To adjust this, customize the results: Append the pipe symbol, followed by the Select-Object cmdlet and the fields to display. The valid field names are EventID, MachineName, Data, Index, Category, CategoryNumber, EntryType, Message, Source, ReplacementStrings, InstanceID, TimeGenerated, TimeWritten, UserName, Site and Container.

[embedded content]

How to parse event log
message field with PowerShell

This command returns the server name, event ID, time and description:


ForEach($Computer in $Computers){Get-EventLog -ComputerName $Computer -LogName “Application” -Newest 10} | Select-Object MachineName, EventID, TimeGenerated, Message

These are just a few methods to parse Windows event logs with Get-EventLog. Microsoft provides an extensive list of other ways this cmdlet helps administrators troubleshoot Windows systems.

Next Steps

PowerShell commands to troubleshoot Exchange Server

Implement PowerShell’s piping capabilities to build scripts

PowerShell Gallery offers easy access to scripts

Why Your Hyper-V PowerShell Commands Don’t Work (and how to fix them)

14 Sep 2017 by Eric Siron
Hyper-V & PowerShell

I occasionally receive questions about Hyper-V-related PowerShell cmdlets not working as expected. Sometimes these problems arise with the module that Microsoft provides; other times, they manifest with third-party tools. Even my own tools show these symptoms. Most GUI tools are developed to avoid the problems that plague the command line, but the solutions aren’t always perfect.

The WMI Foundation

All tools, graphical or command-line, eventually work their way back to the only external interface that Hyper-V provides: its WIM/CIM provider. CIM stands for “Common Information Model”. The Distributed Management Task Force (DMTF) maintains the CIM standard. CIM defines a number of interfaces pertaining to management. Anyone can write CIM-conforming modules to work with their systems. These modules allow users, applications, and services to retrieve information and/or send commands to the managed system. By leveraging CIM, software and hardware manufacturers can provide APIs and controls with predictable, standardized behavior.

Traditionally, Microsoft has implemented CIM via Windows Management Instrumentation (WMI). Many WMI instructions involved VBS or WMIC. As PowerShell gained popularity, WMI also gained popularity due to the relative ease of Get-WmiObject. Depending on where you look in Microsoft’s vast documentation, you might see pushes away from the Microsoft-specific WMI implementation toward the more standard CIM corollaries. Get-CimInstance provides something of an analog to Get-WmiObject, but they are not interchangeable.

For any of this to ever make any sense, you need to understand one thing: anyone can write a WMI provider. The object definitions and syntax of a provider all descend from the common standard, but the provider’s developer determines how it all functions behind the scenes.

Why Hyper-V PowerShell Cmdlets May Not Work

Beyond minor things like incorrect syntax and environmental things like failed hardware, two common reasons cause prevent these tools from functioning as expected.

The Hyper-V Security Model

I told you all that about WMI so that this part would be easier to follow. The developers behind the Hyper-V WMI provider decide how it will react to any given WMI/CIM command that it receives. Sometimes, it chooses to have no reaction at all.

Before I go too far, I want to make it clear that no documentation exists for the security model in Hyper-V’s WMI provider. I ran into some issues some time ago with WMI commands not working the way that I expected. I opened a case with Microsoft, and it wound up going all the way to the developers. The answer that came back pointed to the internal coding of the module. In other words, I was experiencing a side effect of designed behavior. So, I asked if they would give me the documentation on that — basically, anything on what caused that behavior. I was told that it doesn’t exist. They obviously don’t have any externally-facing documentation, but they don’t have anything internal, either. So, everything that you’re going to see in this article originates from experienced (and repeatable) behavior. No insider secrets or pilfered knowledge were used in the creation of this material.

Seeing Effects of the Hyper-V Security Model in Action

Think about any “Get” PowerShell cmdlet. What happens when you run a “Get” against objects that don’t exist? For example, what happens when I run Get-Job when no jobs are present?

psnowork_emptygetjobNothing! That’s what happens. You get nothing.

So, if I run Get-VM and get nothing (2012/R2):


That means that the host has no virtual machines, right?

But wait:

Hyper-V Powershell commands help

What happened? A surprise Live Migration?

Look at the title bars carefully. The session on the left was started normally. The session on the right was started by using Run as administrator.

The PowerShell behavior has changed in 2016:


The PowerShell cmdlets that I tried now show an appropriate error message. However, only the PowerShell module has been changed. The WMI provider behaves as it always has:


To clarify that messy output, I ran
gwmi -Namespace rootvirtualizationv2 -Class Msvm_ComputerSystem -Filter ‘Caption=”Virtual Machine”‘ as a non-privileged user and the system gave no output. That window overlaps another window that contains the output from Get-VM in an elevated session.

Understanding the Effects of the Hyper-V Security Model

When we don’t have permissions to do something, we expect that the system will alert us. If we try to open a file, we get a helpful error message explaining why the system can’t allow it. We’ve all experienced that enough times that we’ve been trained to expect a red flag. The Hyper-V WMI provider does not exhibit that expected behavior. I have never attempted to program a WMI provider myself, so I don’t want to pass any judgment. I noticed that the MSCluster namespace acts the same way, so it may be something inherent to CIM/WMI that the provider authors have no control over.

In order for a WMI query to work against Hyper-V’s provider, you must be running with administrative privileges. Confusingly, “being a member of the Administrators group” and “running with administrative privileges” are not always the same thing. When working with the Hyper-V provider on the local system, you must always ensure that you run with elevated privileges (Run as administrator) — even if you log on with an administrative account. Remote processes don’t have that problem.

The administrative requirement presents another stumbling block: you cannot create a permanent WMI event watcher for anything in the Hyper-V provider. Permanent WMI registration operates anonymously; the Hyper-V provider requires confirmed administrative privileges. As with everything else, no errors are thrown. Permanent WMI watchers simply do not function.

The takeaway: when you unexpectedly get no output from a Hyper-V-related PowerShell command, you most likely do not have sufficient permissions. Because the behavior bubbles up from the bottom-most layer (CIM/WMI), the problem can manifest in any tool.

The Struggle for Scripters and Application Developers

People sometimes report that my tools don’t work. For example, I’ve been told that my KVP processing stack doesn’t do anything. Of course, the tool works perfectly well — as long as it has the necessary privileges. So, why didn’t I write that, and all of my other scripts, to check their privilege? Because it’s really hard, that’s why.

With a bit of searching, you’ll discover that I could just insert
#requires -RunAsAdministrator at the top of all my scripts. Problem solved, right? Well, no. Sure, it would “fix” the problem when you run the script locally. But, sometimes you’ll run the script remotely. What happens if:

  • … you run the script with an account that has administrative privileges on the target host but not on the local system?
  • … you run the script with an account that has local administrative privileges but only user privileges on the target host?

The answer to both: the desired outcome will not match your expectations.

I would need to write a solution that:

  • Checks to see if you’re running locally (harder than you might think!)
  • Checks that you’re a member of the local administrators
  • If you’re running locally, checks if your process token has administrative privileges

That’s not too tough, right? No, it’s not awful. Unfortunately, that’s not the end of it. What if you’re running locally, but invoke PowerShell Remoting with -ComputerName or Enter-PSSession or Invoke-Command? Then the entire dynamic changes yet again, because you’re not exactly remote but you’re not exactly local, either.

I’ve only attempted to fully solve this problem one time. My advanced VM settings editor includes layers of checks to try to detect all of these conditions. I spent quite a bit of time devising what I hoped would be a foolproof way to ensure that my application would warn you of insufficient privileges. I still get messages telling me that it doesn’t show any virtual machines.

I get better mileage by asking you to run my tools properly.

How to Handle the Hyper-V WMI Provider’s Security

Simply put, always ensure that you are running with the necessary privileges. If you are working locally, open PowerShell with elevated permissions:


If running remotely, always ensure that the account that you use has the necessary permissions. If your current local administrator account does not have the necessary permissions on the target system, invoke PowerShell (or whatever tool you’re using) by [Shift]+right-clicking the icon and selecting Run as different user:


What About the “Hyper-V Administrators” Group?

Honestly, I do not deal with this group often. I don’t understand why anyone would be a Hyper-V Administrator but not a host administrator. I believe that a Hyper-V host should not perform any other function. Trying to distinguish between the two administrative levels gives off a strong “bad plan” odor.

That said, I’ve seen more than a few reports that membership in Hyper-V Administrators does not work as expected. I have not tested it extensively, but my experiences corroborate those reports.

The Provider Might Not Be Present

All this talk about WMI mostly covers instances when you have little or no output. What happens when you have permissions, yet the system throws completely unexpected errors? Well, many things could cause that. I can’t make this article into a comprehensive troubleshooting guide, unfortunately. However, you can be certain of one thing: you cannot tell Hyper-V to carry out an action if Hyper-V is not running!

Let’s start with an obvious example. I ran Get-VM on a Windows 10 system without Hyper-V:


Nice, clear error, right? 2012 R2/Win 8.1 have a slightly different message.

Things change a bit when using the VHD cmdlets. I don’t have any current screenshots to show you because the behavior changed somewhere along the way… perhaps with Update 1 for Windows Server 2012 R2. Windows Vista/Server 2008 and later include a native driver for mounting and reading/writing VHD files. Windows 8/Server 2012 and later include a native driver for mounting and reading/writing VHDX files. However, only Hyper-V can process any of the VHD cmdlets. Get-VHD, New-VHD, Optimize-VHD, Resize-VHD, and Set-VHD require a functioning installation of Hyper-V. Just installing the Hyper-V PowerShell module won’t do it.

Currently, all of these cmdlets will show the same or a similar message to the one above. However, older versions of the cmdlets give a very cryptic message that you can’t do much with.

How to Handle a Missing Provider

This seems straightforward enough: only run cmdlets from Hyper-V module against a system with a functioning installation of Hyper-V. You can determine which functions it owns with:

When running them from a system that doesn’t have Hyper-V installed, use the ComputerName parameter.

Further Troubleshooting

With this article, I wanted to knock out two very simple reasons that Hyper-V PowerShell cmdlets (and some other tools) might not work. Of course, I realize that any given cmdlet might error for a wide variety of reasons. I am currently only addressing issues that block all Hyper-V cmdlets from running.

For troubleshooting a failure of a specific cmdlet, make sure to pay careful attention to the error message. They’re not always perfect, but they do usually point you toward a solution. Sometimes they display explicit text messages. Sometimes they include the hexadecimal error code. If they’re not clear enough to understand immediately, you can use these things in Internet searches to guide you toward an answer. You must read the error, though. Far too many times, I see “administrators” go to a forum and explain what they tried to do, but then end with, “I got an error” or “it didn’t work”. If the error message had no value the authors wouldn’t have bothered to write it. Use it.

Have any questions or feedback?

Leave a comment below!

PowerShell Core’s march ahead gives pause for IT admins

Microsoft’s roadmap plans for PowerShell indicate the Windows version won’t be along for the ride.

A production version of Microsoft’s open source PowerShell automation and configuration management tool, PowerShell Core 6.0, will arrive by the end of 2017, Joey Aiello, program manager at Microsoft, wrote in a blog post last month. Microsoft will continue to support Windows PowerShell 5.1, but only to supply critical fixes, with no expectation for big feature updates or lower-priority fixes.  

In short, PowerShell users who want function upgrades must switch from Windows PowerShell to PowerShell Core, even though it’s missing some features, such as PowerShell Workflow. And with few details on an expiration date, some wonder if this is the end of the road for Windows PowerShell.

“Microsoft specifically said PowerShell Core is not going to replace Windows PowerShell — yet,” said Wes Miller, research analyst at Directions on Microsoft. “PowerShell Core is a separate effort, and Microsoft will be working to shore it up. In the meantime, Windows PowerShell stays and keeps working the way we expect it to.”

Open source switch brings seismic shifts

In August 2016, Microsoft open-sourced PowerShell — its venerable automation and configuration management tool — and made it available on Linux and macOS; though, the company reaffirmed its commitment to Windows at the same time. The move stunned many longtime Microsoft observers, who witnessed PowerShell’s debut as a curiosity in 2006 then blossom into an integral management tool for Windows Server, Microsoft Azure and the Office 365 productivity platform.

Jeffrey Snover, technical fellow at Microsoft, built PowerShell to bring Unix command-line functionality to Windows, but with key enhancements. Instead of unstructured text, PowerShell works with objects and uses a series of commands called cmdlets to build scripts that handle various administrative jobs.

“PowerShell represents Snover’s vision for what a better Linux shell would look like. He just happened to implement it on Windows first because he worked for Microsoft,” said Don Jones, a PowerShell expert and president of PowerShell.org.

Microsoft has recently made a number of unpopular moves in the server space, including a switch to the rollup servicing model, cancelled Server Management Tools service in Azure and reduced feature set in Windows Server 2016’s Nano Server. But administrators who rely on Windows PowerShell have no cause for concern.

“[Windows PowerShell] still has a ton of capabilities that PowerShell Core doesn’t have — might never have — simply because the need to manage Exchange Server is not something you would ever need on Linux,” Jones said. “I think Windows PowerShell still has a strong life.”

Why the cloud paved the way for PowerShell Core

At a recent PowerShell User Group meeting in Boston, Snover said Windows PowerShell achieved its purpose as a complete Windows scripting tool with the 5.1 release. Administrators use it to manage most devices in the data center because it’s widely supported by Microsoft’s partners.

“If you look at the on-premises data center infrastructure — the traditional server, storage array, network switch, virtualization infrastructure — PowerShell is the lingua franca for that space,” said Paul Delory, research director at Gartner.

As virtualization matured and the use of monolithic servers began to fade, IT departments maximized their server hardware investment to run multiple workloads — some with a relatively short lifecycle — and they used PowerShell scripts to handle much of the tedious deployment work.

“You can configure one server with a GUI, but if you’re building 50 servers — or you want servers to be spun up and spun down on demand — this is something that has to be automated,” Delory said.

It’s no coincidence that work on PowerShell ramped up as Microsoft expanded the Azure cloud platform. The company uses PowerShell extensively to manage its cloud and developed newer features such as classes and Desired State Configuration to automate administrative work. The forthcoming Azure Stack appliance contains more than 250,000 lines of PowerShell code to deploy, maintain and secure the system.

“Azure runs a ton of Linux workloads. The ability to run PowerShell inside all the guest operating systems is powerful from the Azure management perspective,” Jones said.

We want PowerShell to be the connector of the hybrid cloud.
Jeffrey Snovertechnical fellow at Microsoft

With a change in focus to PowerShell Core, Microsoft combined its PowerShell team with its Azure Automation and Operations Management Suite team to devote more personnel to the cross-platform project and other areas that PowerShell touches, such as Azure and various applications and services. Microsoft’s goal is to build a comprehensive management platform for users on different operating systems to control their entire infrastructure.

“We want PowerShell to be the connector of the hybrid cloud,” Snover said. “We want to be able to use PowerShell from any client to manage any server running in any cloud, or on premises using any hypervisor, storage stack and networking stack.”

Suspicions linger around the ‘new’ Microsoft

Microsoft surprised many IT veterans with a stream of other open-source-friendly disclosures in 2016. The company discussed plans for a Linux version of its SQL Server database application, it added the Linux Subsystem for Windows to Windows 10 and it joined the Linux Foundation at the Platinum level. But gradual changes to Linux, such as exposing more services through APIs and returning structured objects, have brought it closer to how Windows operates, which might weaken resistance to PowerShell Core.

“As more and more of the Linux world produces APIs and structured documents, PowerShell becomes a stronger shell for them,” Snover said.

But many in the open source community can’t embrace Microsoft’s about-face from a proprietary software vendor to a company that writes blogs entitled “Microsoft loves Linux.”

“It’s a bit of a paradigm shift, but at the same time, it’s just Microsoft trying make this more about its services in the cloud and its management infrastructure down below. Is it going to be enough to win over everybody who’s still scared of Microsoft? Absolutely not,” Miller said.

Construct a chain of commands with the PowerShell pipeline

Administrators new to PowerShell can construct intricate workflows within a single line of code once they learn how to tap into the automation tool’s piping abilities.

The ability to take output from one command and send it as input to the next command with the PowerShell pipeline is a major feature that sets PowerShell apart from other scripting languages. The pipeline links multiple commands to perform complex actions, such as configuration changes. In other operating systems such as Linux, the shell needs to parse the text output from a command before it can work with the data.

It’s useful to think of PowerShell objects as analogous to a car, and the methods as the actions a car can take, such as moving forward or backward. Usually, an administrator would need a separate script for each method, but the PowerShell pipeline enables admins to consolidate those scripts and pass — or pipe — rich objects from one command to another.

The PowerShell pipeline helps condense code. For example, take the script below:

$service = Get-Service -Name XXX

$serviceName = $service.Name

Stop-Service -Name $serviceName

The administrator can shorten this code with the PowerShell pipeline to chain commands to pass the objects. The previous script is now one line of code that begins the task and stops it automatically when it completes:

Get-Service -Name XXX | Stop-Service

This video tutorial further explains what the PowerShell pipeline is and demonstrates how it works with real-life examples. 

View All Videos

Powered by WPeMatico

How can IT put PowerShell Integrated Scripting Environment to use?

PowerShell Integrated Scripting Environment is a tool that can benefit all levels of users, which is why many developers and administrators use it almost exclusively when working with PowerShell — often skipping the original console altogether.

With PowerShell ISE, which provides a graphical user interface (GUI) for writing and fixing PowerShell scripts, IT administrators and developers can write, edit and run PowerShell scripts and commands. It provides a more user-friendly way to work with the wide range of features available for creating and testing PowerShell codes.

For example, PowerShell ISE includes IntelliSense for autocompleting commands and for matching cmdlets, variables, parameters and other language elements. The GUI also provides quick access to a variety of snippets that make it easier to construct command logic, such as looping structures. In addition, admins get multiple execution environments, selective code execution and the ability to run commands from either the PowerShell script or the console pane.

What else can PowerShell ISE do?

PowerShell script development

PowerShell Integrated Scripting Environment provides many other features to support PowerShell script development, such as drag-and-drop editing, tab completion, block selection, syntax coloring, keyboard shortcuts and Unicode support. Plus, admins can open PowerShell script files by dragging them from Windows Explorer to the PowerShell ISE GUI. They can even extend the PowerShell Integrated Scripting Environment object model to customize the deployment and add functionality.


Admins can also use PowerShell Integrated Scripting Environment to troubleshoot and debug PowerShell scripts. Although this goes hand in hand with script development, sometimes admins must fix an existing script and want to use PowerShell ISE’s debugging capabilities. Not only do they get features such as selective execution and multiple execution environments, but they can also set up breakpoints, step through code, check variable values and display call stacks. In addition, PowerShell Integrated Scripting Environment displays parsing errors as admins type.

PowerShell Integrated Scripting Environment is also useful as a learning tool.

Running complicated commands

Admins might also use PowerShell Integrated Scripting Environment when they want to run complex ad hoc commands and prefer to avoid the inherent clunkiness of the PowerShell console. With PowerShell ISE, they can type all their code in the script pane and then, when they’re ready, run part or all of the code. This also makes it easier to tweak the script if admins need to run it multiple times, incorporating slight modifications with each execution.


PowerShell Integrated Scripting Environment is also useful as a learning tool. Someone new to PowerShell can benefit a great deal from built-in features, such as IntelliSense, snippet access and parse error displays.

Powered by WPeMatico

PowerShell Script: Change Advanced Settings of Hyper-V Virtual Machines

   Each Hyper-V virtual machine sports a number of settings that can be changed, but not by any sanctioned GUI tools. If you’re familiar with WMI, these properties are part of the Msvm_VirtualSystemSettingData class. Whether you’re familiar with WMI or not, these properties are not simple to change. I previously created a script that modifies the BIOS GUID setting, but that left out all the other available fields. So, I took that script back into the workshop and rewired it to increase its reach. If you’re fairly new to using PowerShell as a scripting language and use other people’s scripts to learn, there are some additional notes after the script contents that you might be interested in. What this Script Does This script can be used to modify the following properties of a Hyper-V virtual machine: BIOS GUID: The BIOS of every modern computer should contain a Universally Unique Identifier… Read More»

Read the post here: PowerShell Script: Change Advanced Settings of Hyper-V Virtual Machines