My friend, Thom Schumacher, who has been leading the Arizona PowerShell User Group for the past few months, is getting to know PowerShell Studio. Like many of us, he came to PowerShell Studio from PowerShell ISE, so he looks for the “ISE way” to do things in PowerShell Studio.

“How do I use PSEdit in PowerShell Studio?,” Thom asked on Twitter. Here’s my answer.

Um, you don’t need it

Being very literal, you don’t need the PSEdit function in PowerShell Studio.

The PSEdit function, which is defined in and works only in PowerShell ISE (not in the ISE module), opens a script that you specify in a new PowerShell Tab, that is, a new runspace.

In ISE, you need to create a new runspace because, by default, everything that you run in ISE runs in the same runspace in its console. That’s obviously not the best test environment. A new runspace is an improvement, even though the new runspace still includes your personal PowerShell profiles and anything that they import or auto-load.

As a best practice test environment, by default, PowerShell Studio runs every script in a new runspace every time. It not only creates a new runspace for every script. It creates a new runspace each time you use Run, Run Selection, or Debug, even if you run them repeatedly on the same script. You always get a new runspace. And, that runspace never includes PowerShell profiles, so you don’t need to hide, move, or disable them.

If you need a persistent runspace to share content, like variables, use the PowerShell Studio Console Pane. Run the script from the console or use the Run in Console or Run Selection in Console commands. Commands that run in the same Debug session also share a persistent runspace.

A PSEdit to Open a Script in PowerShell Studio

But, that’s probably too literal. Many people who use the PSEdit function aren’t even worried about a runspace. They just want a console command that opens a new script in their favorite editor.

To open any script (.ps1), module (,psm1) in PowerShell Studio, use the Invoke-Item cmdlet or its alias, ii.

For example, this command opens the Get-CmdletAttributes.ps1 script in PowerShell Studio.

ii C:\Scripts\Get-CmdletAttributes.ps1

You can use Invoke-Item in any PowerShell console, including, but not limited to, the PowerShell console in PowerShell Studio.

The Invoke-Item cmdlet works because it opens the file in the program that is associated with that file type. When you install PowerShell Studio, the installer sets the file association for you.

A PSEdit to Open PowerShell Studio

When people ask for a “PSEdit” equivalent, sometimes they just want a console command to open PowerShell Studio.

My CurrentUserAllHosts PowerShell profile includes this function. I named it “SPS” for “SAPIEN PowerShell Studio.” It works anywhere in PowerShell. It’s not limited to PowerShell Studio.

When I want to open PowerShell Studio from any console (except the one in PowerShell Studio, of course), I type sps.

function sps
{
    $keyPath = 'HKLM:\Software\Sapien Technologies, Inc.\PowerShell Studio*'
 
    if ($key = (dir $keyPath | Sort-Object -Descending | Select-Object -First 1) -replace 'HKEY_LOCAL_MACHINE', 'HKLM:' )
    {
       if ($path = Get-ItemProperty -Path $key -Name Path)
       {
           Start-Process $path.Path
       }
       else
       {
           Write-Error "Found PowerShell Studio. Cannot find path in $key."
       }
    }
    else
    {
        Write-Error "Cannot find PowerShell Studio on this computer."
    }
}

So, there you have it. If you’ve just started using PowerShell Studio, and you need an equivalent for your favorite command in your previous tool, post your request on our PowerShell Studio forum.

June Blender is a technology evangelist at SAPIEN Technologies, Inc. and a Windows PowerShell MVP. You can reach her at juneb@sapien.com or follow her on Twitter at @juneb_get_help.

 
Follow @SAPIENTech
 
             

If you ever want to start an argument with programmers or scripters, mention your preferred code or script formatting habit.

A tweet about the PowerShell backtick continuation character or the placement of comment-based help for a function will elicit enough reaction to bring down a small server.

But nothing gets people more riled up than the position of curly braces in a script block. On the same line or a separate line?

From 10PM.com

First, PowerShell MVP Aleksandar Nikolic will remind you (and rightly so!) that “curly braces” is redundant, because all braces are curly. That’s how you distinguish braces from brackets.

Then, everyone who’s not on deadline, and a few people who are, will weigh in about how their curly brace placement is the right way. It’s the professional way. It’s the clearest way. It’s the historic way. It’s the new way.

In general, PowerShell doesn’t care about white space or line breaks before curly braces in script blocks. They matter only in structures like hash tables. But, everyone else cares.

Place open brace on new line (or not!)

PowerShell Studio wouldn’t dare to make the critical choice of curly brace placement for you. Instead, you decide where you want your curly braces in script blocks.

To declare your choice:

1. In PowerShell Studio, click Home and in the Windows group, click Options.
2. Under Editor, click Formatting.
3. Check or uncheck: Place open brace on a new line.

The script diagram shows you the effect.

On the same Formatting page, you can also set your Triggers, that is, the characters on which PowerShell Studio evaluates and reformats for you, if necessary.

As a result, when you hit a trigger or click the amazing Format Script button (Home/Edit), PowerShell Studio formats your script with the curly braces where you want them.

Remember that Place open brace on a new line affects only basic script blocks, like those in an IF statement. It doesn’t affect other instances of curly braces, like those in hash tables, functions, or even the script blocks in event handlers.

So, there’s only one right place for curly braces in a script block. It’s where you want them.

June Blender is a technology evangelist at SAPIEN Technologies, Inc. and a Windows PowerShell MVP. You can reach her at juneb@sapien.com and follow her on Twitter at @juneb_get_help.

 
Follow @SAPIENTech
 
             

Like most things, once you know the basics, it’s really easy to build GUI applications with Windows PowerShell and PowerShell Studio. And, like most things, it’s hard to learn the basics. We’re here to help.

We just posted a two-part series of videos. You can watch them in any order.

• My First Form: Build a Simple PowerShell GUI App is a step-by-step guide to building a little PowerShell GUI app that displays the versions of Windows and Windows PowerShell on your system.
• My First Form: Controls and Properties is like a prequel. It introduces you to the concepts of the Windows Forms controls that we use in the GUI applications. It shows you how to add them to your app and how to find and change their property values. It also introduces you to the SAPIEN Spotlight articles that provide clear, simple help for each control, along with examples written in Windows PowerShell.

If you want more information designed especially for GUI development, see PowerShell GUIs; Where do I start?

To see all of the videos from SAPIEN Technologies, subscribe to our YouTube channel: SAPIENTech. If you have comments, questions, ideas for more videos, be sure to let us know.

 
Follow @SAPIENTech
 
             

We get this question every week: Why can I not include my data files, secondary scripts, modules, other executables etc. with the packaged executable and have it unpack them when I run it?

If you have been a SAPIEN customer for a few years you may remember that we had this feature in the packager until the 2012 version. The predominant operating system at the time was Windows XP and this worked fine. With the advent of Windows Vista and Windows 7 we received this question more and more: “Why does my packaged script no longer work?. You need to fix this!”

Basically with the shift in the dominant operating system additional security measures came into play. An application running from the program files folder can no longer just willy-nilly create files there. It just fails.
So all that extracting does not work. You need elevation to do that and we know that you should “usually” run your applications under a normal user account.

Secondly, many virus and malware detectors became very good at detecting executables that generate secondary executable files, so extracting scripts, dlls, exes and so forth can result in your files being quarantined and your solution will not work.
So even if you installed your solution outside of the protected “Program Files” folder, thus circumventing a Windows security measure, you still may have trouble getting this to work.

Sure, you can always run elevated and add exceptions to your anti-virus and malware software for your solutions. That is fine on one computer, but what if you need to do this on all machines in multiple networks? Will your clients or employers allow you to open these doors and security risks just to run that one script you need? Usually not.

So we added a simple way to create an MSI Installer for your script applications. Wrap your files including the packaged executable into a Windows Installer file (MSI) and unpack your files once during install, which usually happens elevated.
This also adds the ability for the user to see your installed solution in “Programs and Features” and the version number, which makes things easier when you need to find out what a customer has installed.

If for some reason you really, really despise MSI files or installing software is not allowed on a server (Simply copying files is ok?), create a zip file and unpack it at the destination. Once.

 
Follow @SAPIENTech
 
             

One of the best parts of the PowerShell community culture is the willingness of people at all levels of expertise to help others to learn. It acknowledges that we learn from each other all the time and pays backward and forward for help that others have given to us.

So, there are many people giving talks and presentations about PowerShell. And, PowerShell Studio has several features that make presentations easier.

• Filegroups: Open all scripts and modules for your presentation in a single click, even if the code files are on different machines in different locations. The files open in PowerShell studio in the order that you specify. No more fumbling at presentation time; no more delays during practice.The process does not change the script files, so it doesn’t invalidate testing or jeopardize demos. For information about filegroups, see a demo video: FileGroups in PowerShell Studio.

• Pin to Recent Documents: Beginning in PowerShell Studio 5.2.117, you can pin files to the Recent Documents list in PowerShell Studio. You can pin your filegroup file and any other files you need so they’re available quickly during your presentation.

• Quick-switch themes: It’s easy to change the theme of your PowerShell Studio display. If you prefer one theme, but it’s not optimal for presentation mode, switch it. And when the presentation ends, switch it right back. To change the theme, use the drop-down menu in the top right corner of the PowerShell Studio window.

• Font slider: The font slider lets you adjust the font size in the Editor pane dynamically to optimize it for the audience. The font slider is in the lower left corner of the PowerShell Studio window.

• Layouts: A layout is an arrangement of panes in a PowerShell Studio window. You can use the preset layouts or use the Save Layout feature to create custom layouts.I often use a custom layout to simplify my window during presentations.

  If it suits your presentation, you can turn Auto-Layout off. (The switch is in the bottom left corner of the PowerShell Studio window, just to the right of the font slider.)

  But, more often, I just change the Auto-Layout settings (Home\Windows\Options\Panels\AutoLayout) to those that are best for my presentation. For example, I change the Editor Layout to Editor Only Layout.

• Copy HTML: After my talk, when I’m working on a follow-up blog, it’s easy to copy my code from PowerShell Studio — with the formatting and syntax coloring — and paste it into my blogger. Select the code, right-click, and then click Copy HTML.

These few tricks make my presentations much smoother and allow me to focus on the content.

Do you have tricks I haven’t listed? Use the comments to let me know and I’ll add them to this post.

June Blender is a technology evangelist at SAPIEN Technologies, Inc. and a Windows PowerShell MVP. You can reach her at juneb@sapien.com or follow her on Twitter at @juneb_get_help.

 
Follow @SAPIENTech
 
             

We are wrapping up our Deal of the Day week with 25% off your purchase of PowerShell Studio 2016!  Don’t let this one pass you by.  Shop on-line using the discount code SPS25 at https://store.sapien.com, today ONLY, to secure your copy at this discounted price!

Restrictions:

This offer is valid Friday, April 29th, 2016 from 6AM to 11:59PM PST.  This offer is only valid when purchasing directly through our on-line store.  This offer is not available through resellers or through purchase orders sent to sales@sapien.com.  This offer cannot be combined with any additional discounts.  Use of promotional code must occur at the time of purchase in order to receive the offer.  No substitutions or exchanges of product will be permitted once purchased.  We are not responsible for a failure to redeem this offer due to a browser incompatibility.  Multiple licenses of PowerShell Studio 2016 can be purchased within an order, but the discount code can only be processed one time, per customer.

 
Follow @SAPIENTech
 
             

We all love blog posts that explain something complex in simple terms or demonstrate an elegant technique for performing a task or solving a problem. But, sometimes, a quick video is more effective, especially when the result is visual. Also, there are many people who can learn more quickly by watching than reading.

I’ve been spinning up some short videos about PowerShell solutions and cool features of SAPIEN products that are easy to miss in the treasure trove of features. They’re all on our YouTube channel: YouTube.com/SAPIENTech.

The latest video, Parentheses, Braces, Brackets & Quotes in PowerShell Studio, shows how to use the enclosure features of PowerShell studio to accelerate your scripting. You can enable/disable the auto-closure feature that adds an ending enclosure ( ), }, ], “) whenever you type a beginning enclosure ( (, {, [, “). You can also use the Ctrl key to enclose text that you’ve already typed, and the handy Ctrl-Alt-‘ to toggle quotation marks from single to double and back.

And, there’s more:

• Filegroups in PowerShell Studio
• Rewind in PowerShell Studio: A Built-in Safety Net for your Scripts
• A PowerShell GUI with a Fixed-Sized UI
• My First Form #1: Build a Simple PowerShell GUI App

To make sure you’re notified when we post a new video, subscribe to our channel.

To get our current video list, use a function like this one. You can probably come up with something more elegant, but this works for me.

function Get-SAPIENVideo
{
    $Url = "https://www.youtube.com/user/SAPIENTech/videos"
    $SAPIENVideos = (Invoke-WebRequest -uri $Url).Links | Where-Object { $_.Title -and $_.href -like "/watch*" }
    $SAPIENVideos | Select-Object -Property Title, @{L='URL';E={'http://youtube.com' + $_.href}}
}

If you have a suggestion for a feature video, please let me know. We try to focus on basic PowerShell tasks that can be explained quickly in a short video.

 
Follow @SAPIENTech
 
             

Sometimes, I say things so many times that I start to believe them, even when I’m wrong. Here’s a correction of one of the details that I’ve gotten wrong repeatedly.

“You can only use the Properties pane on one object at time.” — me

Um, no.

The Properties pane in PowerShell Studio displays the properties and property values of an object, that is, one of the Windows Forms controls on the Designer pane. By default, it displays the properties of one object at a time.

To determine which object the Properties pane displays:

• In the Designer pane, click the object.

-or-

• In the Properties pane, use the menu at the top of the pane.

All true.

However, when you select multiple objects in the Designer pane, such as by using Shift+Click or Ctrl+Click, PowerShell Studio shows its smarts.

First , it indicates that more than one object is selected by not displaying the name of an object in the Properties pane menu. That’s your clue that it’s displaying properties of multiple objects.

Then, it displays only the properties that the selected objects have in common. When all selected objects have a property, that property is displayed; otherwise, it is omitted.

For example, when I select a Textbox and a Button, I see only the subset of common properties.

When all selected objects have the same value for a shared property, that property value is displayed; otherwise, the value is blank.

For example, in this image, I’ve selected two Textbox object. Because they both have an Anchor property, the Anchor property appears in the display. But, because they have different values for the Anchor property, no property value appears.

You can also change the property values of multiple objects at one time. For example, this GUI app has six Textbox objects. I can select all of them and then change their properties.

For example, I can change the value of the ReadOnly property to True and the value of the Anchor property to Top, Left, Right. The change affects all selected objects.

That’s not just efficient. It also helps me to keep the property values of similar objects uniform.

And, now I know that the Properties pane displays the properties of one object at a time, except when it doesn’t, and that’s when it really shines!

June Blender is a technology evangelist at SAPIEN Technologies, Inc. and a Windows PowerShell MVP. You can reach her at juneb@sapien.com or follow her on Twitter at @juneb_get_help.

 
Follow @SAPIENTech
 
             

Over the years, the articles in this blog have grown extensively. There’s a lot of valuable information in here, but it’s become hard to find because it’s mixed in with various tour announcements, special offers, conference recaps, and the like. So, we have decided to pull the important articles and place them—along with information relevant to PowerShell and scripting—in a more organized and easily searchable venue.

We are proud to introduce the SAPIEN Information Center.

The most recent articles are always highlighted in a list on the left side of the window.

The SAPIEN Information Center currently has the following categories:

• Debugging
• Graphical User Interface (GUI)
  • Advanced GUI Tips
  • Controls
  • GUI Design / Best Practice
  • GUI Scripting
• Packaging and Deployment
• Quick Guides
• SAPIEN How To…
  • iPowerShell Pro
  • Multi-title
  • PowerShell Studio
  • PrimalScript
  • WMI Explorer
• Scripting
  • Classes
  • Help with Help
  • Modules
  • Tips and Tricks
• Survey Says…
• Version Control

You can find the categories in the Contents menu.

To list the articles in a category, click the category entry in the menu. Or, click the triangle to expand the category.

The SAPIEN Information Center has a Tag feature that helps you to search for articles. For example, to winnow the articles to just the ones marked “PrimalScript,” use the tag drop-down menu on the left-side of your browser window.

To find articles, use the search box in the top left corner.

For more detailed searches, click Advanced Search. You can search by author or category, too.

When you open an article, you get a list of related articles as well. Related articles share keywords with the article you are viewing.

SAPIEN Blog subscribers, never fear – we will announce the arrival of new SAPIEN Information Center articles with blog posts. The blog will still be used
to announce our sales, tours, conferences and the like.

We will be constantly adding to this cornucopia of material about SAPIEN Technologies, Inc. products, PowerShell, and things you never knew you needed to know. So make the SAPIEN Information Center a place you frequent often for tips, tricks, advice and plain old ‘how-tos’.

 
Follow @SAPIENTech
 
             

Tested on: PowerShell 2.0+, PowerShell Studio 2016

This step-by-step example shows you how to create a very simple multi-form PowerShell GUI app. The app consists of a parent form that gets data from a child form and displays it. When you finish, you’ll know how to use the basic multi-form features of PowerShell Studio.

For details about how these features work under the covers, see How Do Multi-Form Projects Work?

For this task, we assume that you know how to create a single-form PowerShell GUI app or that you’ve participated in a Thinking in Events hands-on lab. Otherwise, start with the My First Form videos (Part 1: Build a Simple PowerShell GUI App and Part 2: Controls and Properties) and read the beginner blogs in PowerShell GUIs: Where do I start?

———————

I had a great time in Austin, Texas (yes, Austin is still in Texas) last week with the Austin PowerShell User Group (@ATXPowerShell). Founded by Thom Schumacher and now admirably led by Aditi Satam, this awesome group serves PowerShell folks in the whole Austin metro area. And, Austin is home to whole slew of computing powers, including Facebook, Dell, IBM, AMD, 3M, and the famous University of Texas at Austin.

Read the full post in the SAPIEN Information Center….

June Blender is a technology evangelist at SAPIEN Technologies, Inc. and a Windows PowerShell MVP. You can reach her at juneb@sapien.com or follow her on Twitter at @juneb_get_help.

 
Follow @SAPIENTech
 
             

The newest version of PowerShell Studio, 5.2.128, includes some nice updates, additions, and fixes, but I wanted to call your attention to the change in our keyboard shortcuts. We’ve updated them to simplify the most frequently used shortcuts and to make our shortcuts consistent with other Windows tools. Special thanks to our Wish List contributors for their suggestions.

If you are using a keyboard shortcut program or you have a programmable keyboard or input device, you might need to adjust your settings.

These keyboard changes are listed in our update log, https://www.sapien.com/software/version_history, and on the Keyboard Shortcuts page in PowerShell Studio (on the ribbon, click Help and, in the Product Support section, click Keyboard Shortcuts).

I peek at Keyboard Shortcuts list often, so I’ve added it to the Quick Access toolbar in PowerShell Studio.

We hope these changes make PowerShell Studio even easier to use.

 
Follow @SAPIENTech
 
             

The Script Packager in PrimalScript 2016 gets an update with the next service build (7.2.95). Since this service build changes the locations where your executable files are generated and some new options are available, we thought we’d let you know about these changes before they are actually released.

Based on your feedback, the script engine selection in the Packager settings was too confusing. So we updated the user interface to minimize the number of selections and provide you with a preview of what this selection will do.

Furthermore, as many of you indicated that you still need to support 32 bit machines, this new packager version supports building 32 and 64 bit executables at the same time. Additionally, we added a native Windows platform option, which will always execute the correct version, depending on the current platform. This means you have four options:

1. Microsoft Windows 32 bit, which will generate a 32 bit executable.
2. Microsoft Windows 64 bit, which will generate a 64 bit executable.
3. Microsoft Windows 32 and 64 bit, which will generate a 32 bit and a 64 bit executable.
4. Microsoft Windows Native, which does the same as above (with different naming) but also creates a starter executable, which will launch the correct version for you.

Since the packager can now generate multiple targets with the same name, it can no longer place these files side-by-side with your script. Instead, the executable files are generated in a platform specific folder under a common folder. The common folder can be specified in the packager options and defaults to “bin”. We suggest you stick to that name to keep things uniform, but you can, of course, change it if necessary.

Let’s assume we package a file called “CoolApp.ps1”. Where will the executable file end up?

Depending on your choice, the file CoolApp.exe will be in bin\x86 for 32 bit and bin\x64 for 64 bit. If you selected 32 and 64 bit, well, you will get both files generated in their respective folders.

But what about the last option? The native platform option?

Choosing this build target will put all the files in a folder called bin\Any platform. You will get a CoolApp.exe, CoolAppx86.exe and CoolAppx64.exe. Additionally, .config files are generated for each of them if you checked that option.
The CoolAppx86 and CoolAppx64 files are your actual packaged script. The CoolApp.exe file is a starter application that will execute the right package for the current platform. For your application to work, you must install or deploy all three files together. The starter application receives the same icon, digital signature and manifest as the packaged files, so a shortcut to that file will create the same experience.

We have also added Windows 10 as a target restriction to PrimalScript. All newly generated executables using the default templates are now marked as Windows 10 applications. Additionally, when restricted to a specific version, the executables display the expected and encountered versions in the error message.

The option for auto-incrementing the file version was moved to the Version Information tab.

Oh, and one more thing.

A great many users indicated that they dot source files with common functions. Since these are external to a packaged script, they needed to be deployed with the executable. That created the need to create an installer for an otherwise simple application, required a review or change of script execution policies and, last but not least, opened the application up for user intervention by editing the external script files.

This is why we added an option to resolve dot sourced files while packaging. If the option is enabled, the code of the external scripts gets injected into the packaged script when building the executable.

• Files specified with or without single and double quotes are supported. Files that do not exist will issue a warning. If you have a dot source statement inside a comment block, the file will be inserted into the comment block.
• Using a line comment will prevent a file from being resolved.
• If you need to resolve only some but not all external files, you can use a different case for the file extension.
  . ./include/lib.ps1 will be resolved by the packager,
  . ./include/lib.PS1 will not be resolved.

To make this clear, the statement is case sensitive, the actual filename’s case is not relevant.

As always, questions and comments are welcome. And yes, all these changes will come to PowerShell Studio as well very soon.

 
Follow @SAPIENTech
 
             

As of the KB3000850 update and PowerShell 5.0, PowerShell has included script block logging so that admins would have more tools for the blue team side of pen testing. If you’re unfamiliar or have never heard of it before, I recommend giving this blog post a read.

Not only does the post describe what script block logging is, but it outlines two separate ways to enable it. For example, you can edit your group policy and enable the “Turn on PowerShell Script Block Logging feature” through Windows Components -> Administrative Templates -> Windows PowerShell.

Of course, this being PowerShell, the other way to enable it is a change to a registry key that can be done with a custom function or cmdlet. The blog article even goes as far as providing you with a custom function that will do just this.

What does this have to do with SAPIEN?

While the function provided will enable script block logging, it doesn’t modify the registry in the same way the policy editor does. If you make the modification using the function from the mentioned blog post, the key becomes an REG_SZ with the value of 1.

This technically will work with PowerShell, and the logs will be created as expected. The problem is, if any other application or script relies on that value to determine if logging is enabled, they must account for it being a String instead of an int or their app won’t crash. Which is exactly what happened recently when we were testing the new features around script block logging that were added to PrimalScript and PowerShell Studio.

With that being said, I’ve written a script that contains the same 4 functions from the blog post except they’ve been slightly modified. Each enable-function checks to see if the key exists, if it does and is of the right data type, nothing is done. If it exists and is of the wrong data type, it is removed and the correct type is added.

Manage_PSScript_Block_Logging

I posted a new article on how to design a GUI for high DPI displays on our SAPIEN Information Center:

Designing GUIs for High DPI Displays

In this article, I will cover techniques on how to make your PowerShell GUI compatible with high DPI (Dots per inch) displays. The article will also cover a few caveats to be aware of.

To get a better understanding of what different DPI settings mean, let’s look at standard screen resolutions. A typical 1080p screen will a have 96 DPI (Font scale: 100%). Higher resolution monitors, such as 4K monitors can have a DPI of 192 or higher (Font scale: >=200%).

DPI is determined by the font scale of the OS. If you would try to maintain a DPI of 96 on a 4K monitor, everything will appear to be tiny. Increasing the font scale, will decrease the DPI, which in turn will make icons and text appear larger and easier to see.

One of the more common tasks for an administrator is to write a script for a helpdesk employee or a fellow admin who is maybe not so PowerShell savvy (yet). Many of you like to package that script as an executable file to prevent the user from “experimenting” with your code and messing things up in the process.
From what we hear, it is quite common for these users to come back and say they only see a flashing window when they try to run your script. Now you have to go and explain that this is a console window flashing and they need to open a console to run that exe or script from there.
After wasting this perfectly good explanation you most likely have to go in person and set up a shortcut for the user to do all you just explained.
Let’s face it, PowerShell is a console language, but not everyone is familiar or comfortable with using a console.

So here you are, trying to make your life easier by writing a script only to have to go into either development mode and make that script a GUI application or to go into teaching mode and lecture helpdesk employees on the use of consoles.
If only there was an easier way …

I did what many do today, I searched the internet for a script and modified it to suit my purpose. So here is my shoutout to Martin Pugh at https://thesurlyadmin.com/, thanks for the network speed script!

Here is what it looks like when you run the script. Pretty simple. The seasoned admins among you know that it gets squirrely when there are many more servers and content scrolls. Consoles have buffer limits and, for some reason, those more inclined to use a mouse, have an inexplicable dislike for anything in a console.
But wait, Notepad, everyone knows how to use Notepad, right?

Now lets package that script with the Windows Application engine and see what happens.

Much better. Anyone familiar with Notepad can handle that.

The File and Edit menus provide the usual functions, you can save the output of your script as a text file, the edit menu can find and copy specific text, so if things go wrong it is quite easy for the user to provide you with actual feedback and error messages.
Additionally, there is an automatically generated About box in the Help menu which contains all the information you specified in the version resource while packaging.

Now you can actually determine what version your users run by asking them to simply go to the about box.

It took about ten minutes and some minor modifications to make a simple command line script into a Windows Notepad style application.
There are some limitations of course but we here at SAPIEN think you will find this very useful in enabling others to use your scripts.

As always, if you have any ideas, comments, feedback, please use our feedback forum and reference this post.
https://www.sapien.com/forums/viewforum.php?f=23

One of the great benefits of PowerShell is the ability to very quickly retrieve system information and metrics. We have added three new packager engines to PowerShell Studio and PrimalScript to make it easier to present or log that information in a standard way. I have already discussed the new Windows Application engine here:
https://www.sapien.com/blog/2017/06/14/new-script-engines-for-windows-powershell/

This time around I will show you how easy it is to create a Windows System Tray Application with PowerShell and the new packager engine.
Just like last time we start with a script I found on the internet:
https://gallery.technet.microsoft.com/scriptcenter/Powershell-Script-for-13a551b3

Here is a shout out to Sravan Kumar for sharing his script to check website availability and response times. His script produces an HTML report that we will not use. We want a tray application that checks a list of web sites in intervals and alerts us if one is not available or slow with a tray message.
The list of sites the application checks must come from a text file that is loaded for each iteration, so that there is no need to stop and start the application to pick up new URLs.
The goal for this engine was to allow you to convert a simple script to a system tray application while only using Write-Host, Write-Output etc. You should not have to know much about how tray applications actually work.

Don’t worry, the source for this script is attached to this post.

The file containing the URLs to be checked has to be here: C:\ProgramData\URICheck\URLList.txt
and it contains one URL per line.

There are a few simple things you need to do when making a script into system tray application:
1. It needs to be a loop. As you can see, this script has a while($true) loop. If you do not do that, your tray app will do things just once and then sit there.

2. Sleep when you are not doing anything. The example sleeps a minute after checking the list. Realistically, it could check only every ten minutes and still be fine. If you omit that, you will be using up way more CPU cycles than you need.
Your script runs on its own thread, so exiting the tray application is not dependent on your script sleeping or not.

3. Set $progressPreference = ‘silentlyContinue’, unless you really, really need progress windows. Since the System Tray App engine is a Windows Application, it will display progress notifications as a popup window. Cmdlets like Invoke-WebRequest will display progress, no matter how quick. This can result in flashing progress popups from your applications. We did not generally disable progress display, because you may need to use it for some lengthy operation.

4. Limit your output. Every time a tray app uses any PowerShell output method, a notification in the lower right corner will pop up and the associated system sound will be played. So only produce output if there is something that requires the user’s attention.

5. Supply a meaningful icon. The icon of your application will be display in the system tray. You want to have a distinguishable icon in case you have more than one PowerShell based tray application.

6. Fill out your version resources. A tray application package has an automatic about box, which displays the information in your version resources.

Last but not least, here is how you do all that. It is pretty simple. After running and debugging your script just as you always would, package it using the new Windows Tray App engine:

That’s it.

You can download the script and the packaged executables from here: https://sapien.s3.amazonaws.com/Blog_Post_Files/CheckURI.zip

As always, if you have any ideas, comments, feedback, please use our feedback forum and reference this post.
https://www.sapien.com/forums/viewforum.php?f=23

Previously I showed you the new Windows Application engine (https://www.sapien.com/blog/2017/06/14/new-script-engines-for-windows-powershell/) and the Windows System Tray engine https://www.sapien.com/blog/2017/07/10/creating-a-system-tray-application-with-powershell/.
Today I will show you the last of the three new engines, the Windows Service engine.

Writing a Windows Service can be a challenging experience, even for a programmer. Generally, unless you do that exact thing for a living, nobody writes a Windows Service very often. So most folks don’t have a lot of experience with this particular task.
You do what most programmers do, you Google the task at hand. If you google “write a windows service in powershell” the first hit points to an MSDN magazine article: https://msdn.microsoft.com/en-us/magazine/mt703436.aspx
My compliments to the author, Jean-Francois Larvoire, who did a great job explaining the intricate details of building a service in Windows PowerShell.
If you do this very often, you should definitely read that article.

But, for most of us, this is not a very frequent task. So I will show you a way of doing this without knowing much about services or C#. All you need is PowerShell. Instead of using a script from somewhere on the internet we use a one-liner today.

Get-Process solitaire -ErrorAction SilentlyContinue | Stop-Process –PassThru

I am assuming you can see that this will simply terminate any process named ‘Solitaire’. We will call our service “SolitaireKiller”
Just as previously with the System Tray Application in the last post, the script needs a loop, so it executes the code inside again and again. Also like the tray app, we need to sleep in between iterations so we don’t hog a CPU core for no reason.
For terminating a solitaire game it is not necessary to do that within a second of startup anyway, so we just go with a minute. I don’t think many folks will finish a game in that time.

while($true) {
Get-Process solitaire -ErrorAction SilentlyContinue | Stop-Process –PassThru
Start-Sleep –Seconds 60
}

Run that as a script and it will just kill any Solitaire game you are playing within a minute. We do want to get a notification when a process was terminated, so we make a little adjustment to our script

while($true) {
$ProcessList = Get-Process solitaire -ErrorAction SilentlyContinue
if($ProcessList) {
Write-Host “Terminating Windows Solitaire process”
$ProcessList | Stop-Process –Force | Out-Null
}
Start-Sleep –Seconds 60
}

That’s all. So now we make that a service. Package your script with the Windows Service engine and the PowerShell version most appropriate for your script.

Make sure you enter all pertinent information in the Version settings.

Services need to be installed on a system. To make your life easer, all that is also already build in. All you need to do is run the service executable from an elevated command prompt with /i (as in install)

Now you can look at your service control panel and you will see the Solitaire Killer service. Remember the items you wrote in the ‘Product name’ and ‘Description’ fields for the version information? They are automatically used for the service name and description.

So now go ahead and start that service. Launch a game of Solitaire and wait. Within a minute it will be gone.
Now look at your event log. What you wrote there with Write-Host (or any other PowerShell output mechanism) will show up here in the Application Event Log.

To remove the service from your system, simply stop the service and use the /u parameter (as in uninstall) and it will be gone. Please note that it may take a few seconds to exit and that you may need to restart the services control panel to see that.

You can download the script and the packaged executables from here: https://sapien.s3.amazonaws.com/Blog_Post_Files/SolitaireKiller.zip

As always, if you have any ideas, comments, feedback, please use our feedback forum and reference this post.
https://www.sapien.com/forums/viewforum.php?f=23

One feature of PowerShell Studio that you want to pay attention to is the PowerShell Cache Editor. When PowerShell Studio is opened for the first time, it creates a cache of all available cmdlets and modules that are on your local machine. The *cached cmdlets and modules are used to provide PrimalSense, syntax coloring for your PowerShell scripts, and are displayed in the Object Browser.

The module must be located in a PSModulePath directory in order to be discovered by the caching process. Use the following PowerShell one-liner(s) to display the content stored in the PSModulePath: “$env:PSModulePath“, or “$env:PSModulePath.Split(‘;’)“.

Because PowerShell Studio uses a cache of the modules, newly installed modules will not be displayed automatically in the Object Browser.

There are two ways you can update the cache:

1. Refresh Cache – Refresh the cache using the  button via the Ribbon->Home->Platform->Refresh Cache.

2. Or use the PowerShell Cache Editor  – to modify and update the existing cache, which can be found via the Ribbon->File->Home->Platform->Edit Cache icon.

This will open the “PowerShell Cache Editor“.

Using the Cache Editor to manually add or update a module

In order to load the new module(s) manually, follow these steps:

1. Open the “PowerShell Cache Editor“.
2. For example, look at the SQLPS module which has two versions installed:
   
3. Uncheck the older version – 1.0, then check the newer version (14.0).
4. To update the Object Browser with the changes, click on the “Build Cache“, and “Close” the editor.
   

Now, the local cache has been updated with the module(s) you want to use in PowerShell Studio. Please notice that when you hover the mouse over the module name, the module version will be displayed.

At this point, the selected module is available under the Object Browser section and can be easily added using the following steps:

1. By drag-drop from the Object Browser.
   
2. Or, by just typing the command and the PrimalSense will response with a list of commands to choose.
   

Notice, while working with the “PowerShell Cache Editor”, there’s no need to use the “Refresh Local Cache“.

Just remember, when having multiple versions of the same module, make sure to use the latest one.

SAPIEN Technologies strives to bring the best products to all levels of IT administration. The announcement of PowerShell Core, which is not a finished product yet, causes a lot of confusion. It is our policy that we can’t support products that haven’t been released-to-manufacturers (RTM).  But this particular product, which is Open Source, is steadily taking shape thanks to both the Microsoft PowerShell Team and the contributions of the PowerShell community, so it deserves some attention.

The State of PowerShell Core

Just to be clear! PowerShell Core will not be replacing Windows PowerShell, as it’s meant to provide .NET scripting automation to non-Windows Systems.  This is a good thing, as many Administrators managing Multi-OS systems can use the time invested in learning PowerShell to work across multiple platforms.

In order to understand what’s going on with PowerShell Core, check out these two Microsoft PowerShell Team Blog posts:

• PowerShell Core Roadmap: https://blogs.msdn.microsoft.com/powershell/2017/07/14/powershell-6-0-roadmap-coreclr-backwards-compatibility-and-more/
• PowerShell Core Release Candidate: https://blogs.msdn.microsoft.com/powershell/2017/11/17/powershell-core-6-release-candidate/

Reporting Windows PowerShell vs. PowerShell Core Issues

There is a big difference – Windows PowerShell is not Open Source. It’s a Microsoft product and it will remain closed source and be maintained by them.  Any feedback and bug issues need to be submitted through the UserVoice PowerShell link at: https://windowsserver.uservoice.com/forums/301869-powershell

On the other hand, PowerShell Core, is Open Source and handled by both Microsoft and the community.  Any feedback and bug issues need to be reported at the PowerShell Github link at: https://github.com/PowerShell/PowerShell/issues

There is a lot of information flowing through PowerShell GitHub as each issue gets discussed and resolved.  Don’t be afraid to take a look at it! There are very interesting discussions and exchange of ideas.

But most importantly, they are meant to coexist side by side!

How to test-drive PowerShell Core?

There are plans to integrate PowerShell Core in our SAPIEN Products, but for now you can use PrimalScript. It’s a manual setup, as PowerShell Core needs to be added in the “Command Windows” section. Also, take the time to add Ubuntu shell (RTM) from the Microsoft Store. It’s only available on the Windows 10 September 2017 RTM release Build 16299.

For more information on how to setup PowerShell Core in PrimalScript, click on the following post: https://www.sapien.com/blog/2017/09/15/using-powershell-core-in-primalscript/

Our products keep evolving. Watch for PowerShell Core integration coming soon!

On the evening of Friday, February 2nd, I had the pleasure of speaking at the PowerShell User Group meeting in Jacksonville, FL. We sponsored the JAX group with pizza and had a great time talking about PowerShell Core and demoing some of the SAPIEN PowerShell Studio features, such as:

• File Grouping
• Custom tools
• Cache editor
• Object Browser

And, more!

The JAX PowerShell User Group has also started to promote their upcoming IT Pro Camp 2018, which is going to be at Keiser University in Jacksonville, FL on Saturday, June 9th.

Thank you for having us!

Max Trinidad is a technology evangelist at SAPIEN Technologies, Inc. and a Microsoft PowerShell MVP. You can reach him at maxt@sapien.com.