First rule of PowerShell scoping rules…

March 6th, 2013 by Alex Riedel
… never talk about PowerShell scoping rules. Judging from the posts, emails and questions we get about variable scope in PowerShell Studio forms, PowerShell scoping rules are shrouded in mystery. When you read about_scopes you get a lot of information. When you come from any other scripting language, for example VBScript, you are used to two scopes; global and local. The default scope of a variable in VBScript depends on its first use or its declaration. So if you want a variable to have a specific scope you just declare it with a DIM statement. This code sample illustrates…   More »

LOST! The forgotten features, Part II

October 23rd, 2012 by Alex Riedel
Sometimes we get so used to how software works that we just miss if anything works differently. I am amazed to how many users I talk who have never noticed this feature in PrimalScript, even though it has been there since 2.0… In case you don’t remember, that was in the year 2000. I hope you a appreciate that I had to look for the dates scribbled on backup CDs from 12 years ago to find out when that version was released. If you feel nostalgic, here are some screenshots from PrimalScript 1.0 (1998) and 2.0 (2000)   And yes,…   More »

Developing PowerShell scripts for other machines (Part 1)

October 15th, 2012 by Alex Riedel
One of the challenges you face while developing any PowerShell script is that modules that reside on your target platform are not available on your local computer. Just as an example, try installing Microsoft SharePoint 2010 modules on your 32 bit Windows XP/Vista/7/8 machine. It just won’t work. PrimalScript 2012 and SAPIEN PowerShell Studio 2012 now support a mechanism which allows you to do that. As a first step you need to get the PowerShell cache information our products use from your target machine. To make this as simple as possible, we packed all the files required into a zip…   More »

Get help for modules on other machines

October 10th, 2012 by Alex Riedel
When you develop scripts for other computers you don’t always have the luxury of installing the relevant modules on your own computer. In many cases they simply won’t install because you are running the wrong OS or don’t have some required server software running. Luckily the context sensitive help in PrimalScript or PowerShell Studio doesn’t rely on the actual module being installed like PowerShell’s Get-Help does. In this post we will show you how to export a help file from your target machine and add it to the SAPIEN Document Explorer locally. As an example we will use the Microsoft.WSMan.Management…   More »

How to get support from SAPIEN

October 8th, 2012 by Alex Riedel
Once a year we need to refresh this information, so forgive us if you heard this before. Our trial software is usually not crippled in any way, so just because your are evaluating it nothing should be switched off. So if something is grayed out or inaccessible, it’s usually a configuration issue and not because its a trial version. If you have questions, regardless if it is about a trial or a licensed copy, feel free to contact us: For sales related questions, quotes, prices, discounts, licensing agreements and so forth please contact sales@sapien.com For customer support, for example if…   More »

LOST! The forgotten features

October 2nd, 2012 by Alex Riedel
A week ago I was hanging out with PowerShell trainer extraordinaire Jason Helmick and while we where geeking out over PowerShell tricks and software features (yes, I know, bad, isn’t it?) I asked him how he would improve file groups. (…) (crickets) (…) File groups? So I demonstrated. I learned some time ago that most admins don’t like to use projects. Which isn’t really a surprise as most scripts used to be a single file affair. So anything that deals with projects was considered a “developer” feature.But there was the occasional script that used multiple files or some txt, inf…   More »

Introducing the PowerShell Profile Editor

August 4th, 2012 by Alex Riedel
PowerShell’s profiles make setting up your work environment a bit easier, allowing you to pre-load your most common snapins or modules, define functions, set variables and whatever else you need on startup. However, since there are quite a number of profiles, potentially one for each host, one for all users, one for each user, one for all users and all hosts, the number of files can get a bit out of hand. If you consider that some of these are also duplicated for 32 and 64 bit if you happen to run on a 64 bit OS, you’ll see that…   More »

Single form or multiple dialogs?

June 11th, 2012 by Alex Riedel
In this installment of our series about user interface design for administrators we explore the transformation of a command line script to a Windows application. We start with a simple little script as shown below: It just prompts for a computer name on the command line, uses that information for WMI query and outputs the result to the console. Your existing command line scripts may just use a parameter instead of a prompt but that makes no difference for the purpose of this article. It follows, like most scripts, a basic Input-Processing-Output pattern. If you have previously used VBScript you…   More »

User interface design for administrators

June 4th, 2012 by Alex Riedel
This post is the first in a series describing some fundamental design guidelines. Software developers usually have some kind of training in designing user interfaces or they benefit from having a specially staffed department for this task. Administrator usually don’t have the time and don’t get paid to attend UI design classes or study on their own. So we thought we put a series of articles together which outline some basic good practices and teach some general rules about which control to use for what. Let’s start with the most basic controls and see what they are for:    …   More »

PSModulePath discrepancies

May 22nd, 2012 by Alex Riedel
While investigating a bug report about ChangeVue’s installer we stumbled across a discrepancy with PowerShell’s PSModulePath environment variable. On a virgin Windows 7 machine the environment variable is set to “C:\windows\system32\WindowsPowerShell\v1.0\Modules\” via a System Environment Variable.There is no default that links to the per-user module path. If you query the environment variable in CMD you get the expected result: If you do the same thing in PowerShell you get a different result: Same thing happens in the ISE or any custom PowerShell host, like PrimalScript. Now, Microsoft says here to add persistent changes to the PSModulePath variable in the profile.…   More »