Installing PowerShell Core on Amazon Linux

In preparation for my latest course in the AWS Networking Deep Dive series, I wanted to install PowerShell Core on an Amazon Linux instance to test out cross-platform compatibility for some scripts.

Specifically, I wanted to see if I could use methods in the System.Net.Dns class to perform name resolution. The dnsclient PowerShell module provides some cmdlets for this very purpose, but that module is Windows-only, and I needed something that would work on across different platforms.

To my surprise, it wasn’t as easy as just running sudo yum -y install powershell. Fortunately, it wasn’t as difficult as building from source. Here’s what I did:

Install the dependencies

sudo yum install -y curl libunwind libicu libcurl openssl libuuid.x86_64

Download the installation script

This script just fetches the tarball and extracts it to /opt/microsoft/powershell


Set the script to be executable

chmod +x

Run the script, specifying the PowerShell version (6.0.1) and package tarball as the arguments:

sudo ./ 6.0.1 powershell-6.0.1-linux-x64.tar.gz

If you want to install a specific version (like the latest), then refer to the releases on the PowerShell repo.

Run PowerShell!

The command is pwsh, as in “Present Working SHell” (clever points). Be sure to use sudo, as it does require root privileges:

sudo pwsh

Get Your .NET On

The whole point of this exercise was to see if I could use .NET to perform DNS name resolution without any of the cmdlets in the Windows-only dnsclient module. Did it work? Let’s see.

PowerShell v6.0.1
Copyright (c) Microsoft Corporation. All rights reserved.
Type 'help' to get help.
PS /home/ec2-user> [System.Net.Dns]::GetHostAddresses("").IPAddressToString

Yes indeed! Of course, I can still use the usual PowerShell tricks to extract just the data I want:

PS /home/ec2-user> [System.Net.Dns]::GetHostByName("") | Select-Object AddressList

I can also drill down to pick out just the first IP address in the list:

PS /home/ec2-user> ([System.Net.Dns]::GetHostByName("")).AddressList[0].IpAddressToString

Run it again, and I get a different address:

PS /home/ec2-user> ([System.Net.Dns]::GetHostByName("")).AddressList[0].IpAddressToString

Looks like round-robin DNS! But will this command work cross-platform? Let’s try it on my Windows 10 machine:

PS C:\Users\admin> ([System.Net.Dns]::GetHostByName("")).AddressList[0].IpAddressToString

Yes! This is exactly why I chose PowerShell. The same command that works on Linux also works on Windows, which makes it perfect for an OS-agnostic course.

Ready to learn more PowerShell? Sign up for a free trial with Pluralsight and get unlimited access to every course in their humongous library!

Visual Studio Code as a PowerShell Integrated Scripting Environment

I know what you’re thinking. “Why use Visual Studio Code instead of the PowerShell ISE?” Well, if you’re using Mac OS or Linux, you don’t have the option to use the PowerShell ISE natively. And that’s a problem if you want to take advantage of the cross-platform capabilities of PowerShell Core. In this article, I’ll show you how to use Visual Studio Code (free!) to perform the key functions of the PowerShell ISE, namely:

  • Simultaneously view code and execute it in the PoSh terminal
  • Execute code on a selection or line-by-line basis (F8)
  • Syntax highlighting (for people who are easily bored like me)

Installing Visual Studio Code

The best way to install most things is with a package manager. This would be something like apt-get or yum for Linux distros, homebrew for Mac OS, and Chocolatey for Windows. Or you could go old school and download it here.

Installing the PowerShell Extension

Go to the Extensions button (looks like a busted up square) or View > Extensions.

If the PowerShell extension doesn’t show up under the bombastic “RECOMMENDED” heading, just search for it in the “Search Extensions” field. Then install it.

Integrating the PowerShell Terminal

Open up a PowerShell script of your choice. Then in the menu, go to View > Integrated Terminal. You should see the following.

If you don’t see the PS prompt Make sure you select “TERMINAL” and “PowerShell Integrated” from the drop-down menu.

Running Only Selected Code

In the PowerShell ISE, you can select a block of text and hit F8, and the ISE runs only that code. Or you can position your cursor at the end of a line and hit F8, and the ISE runs only the code on that line. Next we’ll enable the exact same behavior in Visual Studio Code.

Go To File > Preferences > Keyboard Shortcut

In the text entry field at the top, type “runsel”. You should see two items:

  • “Run Selection” with a keybinding to F8
  • “Run Selected Text In Active Terminal” with no keybinding

This is not what we want because it will not run the selected text in the PowerShell terminal. It will run the selection in the “OUTPUT” section, but not in the terminal. Obviously, that’s not the normal behavior of the PowerShell ISE. Let’s fix it.

Right-click the “Run Selection” item and select “Remove keybinding”

Right-click the “Run Selected Text in Active Terminal” item and select “Add Keybinding”

Depress the F8 key (or whatever you want to use) then hit Enter.

Testing It Out

Go back to your code and select a block of code. Hit F8 and watch the magic!

That’s what I’m talking about!

But… as of this writing, there’s an issue with this that’s being tracked on the vscode-powershell GitHub repo, and it’s this: multi-line input in the integrated console doesn’t work. That means you can’t select a function block, hit F8, and have it work. It will throw ugly errors in your face.

Ready to learn more PowerShell? Get unlimited access to Pluralsight’s entire course library!

Fixing PowerShell’s Copy-Item “Access is Denied” Error

Recently I needed a way to copy a certificate file from within a PowerShell session to another Windows machine without opening a nested PowerShell session. But I ran into a little snag along the way: Copy-Item‘s dreaded Access is denied error.

Here’s my setup:

  • A Windows 10 laptop, from which I’m remoting
  • NC1, a Server 2016 virtual machine I’m remoted into. It’s a member of a domain.
  • HYPERV1, the Server 2016 machine I want to copy a certificate file to. It’s not a member of a domain.

I execute all of the following commands on NC1, the VM I’m remoted into.

Here’s the first thing I tried. The HYPERV1 machine is not a member of a domain, so the following doesn’t work:
$ Copy-Item .\nccert.cer \\hyperv1\c$
Access is denied
+ CategoryInfo          : NotSpecified: (:) [Copy-Item], UnauthorizedAccessException
+ FullyQualifiedErrorId : System.UnauthorizedAccessException,Microsoft.PowerShell.Commands.CopyItemCommand

What about specifying the -Credential parameter? That doesn’t work either.
$ Copy-Item .\nccert.cer \\hyperv1\c$ -Credential hyperv1\administrator
The FileSystem provider supports credentials only on the New-PSDrive cmdlet. Perform the operation again without specifying credentials.
+ CategoryInfo          : NotImplemented: (:) [], PSNotSupportedException
+ FullyQualifiedErrorId : NotSupported

And that error pretty much tells me what I need to do: use the New-PSDrive cmdlet!
$ New-PSDrive -Name H -PSProvider FileSystem -root \\hyperv1\c$ -Credential hyperv1\administrator
$ Copy-Item .\nccert.cer h:\
$ Remove-PSDrive -Name H

Ready to beef up your PowerShell skills? Get unlimited access to every course in Pluralsight’s online training library!

[amazon_link asins=’1617294160,1617291161′ template=’ProductCarousel’ store=’benpiperbloginline-20′ marketplace=’US’ link_id=’ff330eeb-fd95-11e7-9367-6b18dc756ddf’]

How to Fix the Blurry, Fuzzy, Ugly Text in Windows 10

After upgrading my Lenovo ThinkPad to Windows 10, I was so pumped. The upgrade went smoothly, all my apps worked, but then I noticed something: some apps had blurry, fuzzy text.

Ugly, blurry, fuzzy text on Windows 10:


This might not bother some people, but to me it felt like trying to read a wet book with my glasses off. Most everything else looked sharp and normal, so I knew it wasn’t a native resolution or global DPI scaling issue, which is what most of my Google-fu turned up.

The fix (hint: not prescription eyeglasses)

The fix turned out to be crazy stupid. Well, more stupid than crazy. Go into the Properties of the app that’s rubbing salt water in your eyes:


Navigate to the Compatibility tab. Check that “Disable display scaling on high DPI settings” check box, apply the settings, then launch the app again.


That’s what I’m talking about. The window is bigger, and the text doesn’t look like garbage.

But wait, there’s more! (PowerShell)

If you’re a PowerShell 1337 scripter, you may run into a similar issue. Check this out:


If you’ve ever hooked up a computer to an old CRT television using an RF converter, well, this is about what it looks like. Ugly as homemade sin, as they used to say. Don’t worry about the error. I left it to highlight how horrendously eye-stab-worthy this console looked when I first opened up a can of PoSH on my newly minted Windows 10 upgrade.

The fix? Go to PowerShell properties:


Navigate to the Options tab (intuitive, right?). Check the box “Use legacy console” (duh), then apply the settings. Relaunch PowerShell.


The image makes it look a bit fuzzy still, but on my screen it looks crisp and sharp.

Creating a File Share with PowerShell and Windows Server Core

Sometimes you just need to create a file share.

With Windows Server Core, you don’t have all the old GUI tools that we’re all used to. So you have to make do with PowerShell and the old fake DOS prompt. Fortunately, with a little help, it’s pretty easy.

First, create the folder you want to share. In this case, c:\share

Next, modify the ACL to grant the DOMAIN\File Server Admins group full control

$sharepath = "c:\share"
$Acl = Get-ACL $SharePath
$AccessRule= New-Object System.Security.AccessControl.FileSystemAccessRule("DOMAIN\File Server Admins","full","ContainerInherit,Objectinherit","none","Allow")
Set-Acl $SharePath $Acl

Finally, create the share and grant everyone full access.
NET SHARE sharename=c:\share  "/GRANT:Everyone,FULL"


Windows Server Core Full Configuration with PowerShell

How to Configure Server Core with Active Directory Services, DNS, and DHCP Using Nothing But PowerShell

Windows Server 2012 offers two installation options: Server Core or “Server with a GUI”. This begs the question: Why would you want to install Server Core instead of the GUI? One reason may be that you have limited physical hardware resources and want to keep the footprint as small as possible.

Recently I needed to build a domain controller, DHCP, and DNS server for a branch office. This office has a Riverbed Steelhead WAN optimization appliance which runs a nested VMware ESXi hypervisor. The appliance has limited memory and disk space, so I needed to keep the installation as small as possible (Incidentally, if I only needed DNS and DHCP, I would have just installed RedHat Enterprise Linux, but having the server be an Active Directory domain controller was also a requirement.)

I’m going to show you step-by-step how I configured Active Directory Services, DNS, and DHCP on a Windows Server 2012 Server Core installation. Continue reading

Use PowerShell to Find Citrix ICA Client Versions In Use On a XenApp 6 Farm

In many Citrix environments it’s common to have a large variety of ICA client versions. One thing that sometimes surprises users and IT folks alike is how much of a performance increase can be seen after upgrading an old ICA client. But how do you know which clients need upgrading?

One of the biggest challenges has been deciphering what ICA client version the cryptic “client build number” in a user’s session information translates to. Well thanks to the XenApp 6 PowerShell SDK and Get-XASession, we can easily find Citrix ICA client version information in a snap with the following script (download the script here):

# XenApp 6 Client Version Retrieval Script
# Created by Ben Piper
function convertToVersion($build) {
		6685 {"13.0"; break}30 {"12.1"; break}6 {"12.0.3"; break}6410 {"12.0"; break}142{"Java"; break}317{"3.0"; break}324{"3.0"; break}330{"3.0"; break}349{"3.0"; break}304{"MAC 6.3"; break}314{"MAC 6.3"; break}323{"MAC 6.3"; break}326{"MAC 6.3"; break}400{"MAC 7.0"; break}402{"MAC 7.0"; break}405{"MAC 7.0"; break}406{"MAC 7.0"; break}407{"MAC 7.0"; break}402{"MAC 7.0"; break}411{"MAC 7.0"; break}500{"MAC 7.1"; break}600{"MAC 10.0"; break}601{"MAC 10.0"; break}581{"4.0"; break}606{"4.0"; break}609{"4.0"; break}614{"4.0"; break}686{"4.0"; break}715{"4.2"; break}727{"4.2"; break}741{"4.2"; break}779{"4.21"; break}730{"wyse1200le"; break}910{"6.0"; break}931{"6.0"; break}961{"6.01"; break}963{"6.01"; break}964{"6.01"; break}967{"6.01"; break}985{"6.2"; break}986{"6.2"; break}1041{"7.0"; break}1050{"6.3"; break}1051{"6.31"; break}1414{"Java 7.0"; break}1679{"Java 8.1"; break}1868{"Java 9.4"; break}1876{"Java 9.5"; break}2600{"RDP 5.01"; break}2650{"10.2"; break}3790{"RDP 5.2"; break}6000{"RDP 6.0"; break}2650{"10.2"; break}5284{"11.0"; break}5323{"11.0"; break}5357{"11.0"; break}6001{"RDP 6.0"; break}8292{"10.25"; break}10359{"10.13"; break}128b1{"MAC 10.0"; break}12221{"Linux 10.x"; break}13126{"Solaris 7.0"; break}17106{"7.0"; break}17534{"7.0"; break}20497{"7.01"; break}21825{"7.10"; break}21845{"7.1"; break}22650{"7.1"; break}24737{"8.0"; break}26449{"8.0"; break}26862{"8.01"; break}28519{"8.05"; break}29670{"8.1"; break}30817{"8.26"; break}31327{"9.0"; break}31560{"11.2"; break}32649{"9.0"; break}32891{"9.0"; break}34290{"8.4"; break}35078{"9.0"; break}36280{"9.1"; break}36824{"9.02 WinCE"; break}37358{"9.04"; break}39151{"9.15"; break}44236{"9.15 WinCE"; break}44367{"9.2"; break}44376{"9.2"; break}44467{"Linux 10.0"; break}45418{"10.0"; break}46192{"9.18 WinCE"; break}49686{"10.0"; break}50123{"Linux 10.6"; break}50211{"9.230"; break}52110{"10.0"; break}52504{"9.2"; break}53063{"9.237"; break}55362{"10.08"; break}55836{"10.1"; break}58643{"10.15"; break}				
		default {$build; break}
$clientUsage = @()
foreach($session in Get-XASession -full | where {$_.state -eq "Active" -and $_.protocol -eq "Ica"}) {
	$clientUsage += new-object psobject -Property @{
		User = $session.accountname
		Workstation = $session.clientname
		Client = convertToVersion($session.clientbuildnumber)
$clientUsage | sort-object -Property Workstation | get-unique -asstring

The script makes use of build-to-version information gleaned from Nick Holmquist’s ICA Client Build List and the Citrix Client Build List thread on Citrix Forums (Thanks!). The convertToVersion function uses the PowerShell switch command to identify and then return the ICA client version based on the build number. If the key-value pair is not in the list, the build number is returned. All ICA client versions in the list have at least one decimal place to make it easy to distinguish build numbers from client versions.

Instantly Publishing Citrix Apps to Individual Servers Using PowerShell

Sometimes there is a need to publish an application to individual XenApp servers for baselining or troubleshooting purposes. But if you have a lot of published applications in your XenApp 6 farm, this can be a huge hassle. Thankfully PowerShell allows us to quickly and easily take our existing published applications and automatically create individually published apps for each server. We can use Worker Groups to control which servers get an individually published application. Not only that, we can organize the applications neatly by creating separate console and Client folders for each server. I wrote this script to accomplish all of the above using XenApp 6 PowerShell SDK’s powerful features:

$appFolder = "Applications"
$testfolderpath =  "Applications/Test/Single Server Test"
$sourceAppPath = "Applications/Test"	#apps in the root of this path will not be copied
$publishTo = "DOMAIN\GroupWithAccessToIndividualServers"
$targetWorkerGroup = "Main Farm Servers"
$clientFolder = "Test\Single Server Test"
$WhatIfPreference = $false		# Simulate script but do not execute any changes (will yield errors)
# Main Program
$servers = Get-XAServer -workergroupname $targetWorkerGroup
$sourceFolders = Get-XAFolder -folderpath $appFolder -recurse | where {$_ -notmatch $testfolderpath -and $_ -match $sourceAppPath -and $_ -ne $sourceAppPath}
# Create folder for each server
foreach ($server in $servers) {						
	#generate folder name for each server
	$createfolder = $testfolderpath+"/"+$server.servername
	#create folder for each server
	new-xafolder -folderpath $createfolder
	foreach ($folder in $sourceFolders) {
		#get list of apps to copy in each folder
		$appstocopy = Get-XAApplication -folderpath $folder			
		foreach ($app in $appstocopy) {
			## generate name for new app
			$newname = $app.displayname+" "+$server.servername
			$newclientfolder = $clientfolder+"\"+$server.servername
			## get existing accounts to remove			
			$accountsToRemove = ($app | Get-XAApplicationReport).accounts
			## copy application to server's folder		
			$newapp = $app | Copy-XAApplication -folderpath $createfolder
			## publish application to lone server		
			$newapp | set-xaapplication -servernames $server.servername -clientFolder $newclientFolder
			## remove existing accounts
			foreach ($account in $accountsToRemove) {
				$newapp | remove-xaapplicationaccount -Accounts $account
			## publish application to AD group
			$newapp | add-xaapplicationaccount -Accounts $publishTo
			## rename new application
			$newapp | rename-xaapplication -newdisplayname $newname						

Download the script from GitHub.

Just set the variables with what is appropriate for your environment and run the script.
The $appFolder variable is the root path of your applications (default is “Applications”)
$testfolderpath is the full path of the folder where the applications published to individual servers will be published (no trailing slash)
Set $sourceAppPath one level higher than the path of the folder containing the applications you wish to copy. The script will recurse down into child folders from this path, but will not copy applications that reside within this path.
$publishTo is a string containing the AD users or groups the newly published applications should be published to
$targetWorkerGroup is the name of the worker group containing the servers the applications will be published to
$clientFolder is the root Program Neighborhood/Client folder that the individual server folders will be created under

The once-daunting and time-consuming task of copying and modifying applications for each server can now be done automatically in a matter of minutes!

Update: It’s even easier to undo the changes made by the above script if you decide you want to scrap the newly published apps and folders and start over. Just use the following script:

$testfolderpath =  "Applications/Test/Single Server Test"
$WhatIfPreference = $false
# Main Program
(get-xaapplication -folderpath (Get-XAFolder -folderpath $testfolderpath)) | remove-xaapplication
(get-xafolder -folderpath $testfolderpath) | remove-xafolder

How To Get a Unique STA ID for each of your PVS Provisioned XenApp Servers

Citrix Provisioning Services is very nice, but it does come with a slightly annoying quirk: All of your provisioned XenApp servers end up with the same STA ID! This will cause all sorts of problems for Citrix Access Gateway, Citrix Receiver, and anything else that may depend on having unique STA IDs. The good news is that fixing this little problem is easier than you might think.

To resolve the duplicate STA ID issue, we’ll do the following:
1. Create personality strings in Provisioning Services for each XenApp server
2. Put a PowerShell script on our golden image
3. Create a startup task to execute the PowerShell script

Let’s begin:

The format of the STA ID is simple. It is “STA” followed by the MAC address of the XenApp server’s NIC. The STA ID can really be anything beginning with “STA”, so you could get creative and have “STABLEFLY”, “STANK”, “STALE”, “STARTBUTTON”, “STACKOVERFLOW”.. and the list goes on. But I recommend sticking with the MAC address because it’s unique (usually), and is easy to match up.

1. In Provisioning Services, create a personality string for each server with the Name “UID” and the String “STA001122DDEEFF”, substituting the MAC address of the server for the hex I just threw in there.
Define Personality Strings

2. Copy this PowerShell script to your scripts location on your golden image: (Note: Download the file from the above link and do not copy and paste the text below, otherwise PS will complain.)

# STA Replacement Script for Citrix Provisioned Servers
# Created 7-25-11 by Ben Piper (email:, web: )
# Get UID string
# Replace STA ID
# Restart CTXHTTP service

$stastr = get-content C:\Personality.ini | Select-String -Pattern “UID=STA”
$CtxStaConfig = Get-Content ‘C:\Program Files (x86)\Citrix\system32\CtxSta.config’ | ForEach-Object {$_ -replace ‘^UID=.+$’, $stastr}
$CtxStaConfig | Set-Content ‘C:\Program Files (x86)\Citrix\system32\CtxSta.config’
Stop-Service CtxHTTP
Start-Service CtxHTTP

3. Create a scheduled task to execute the PowerShell script at startup. Make sure the account that will be executing the script has appropriate permissions.

If you are not already running PowerShell scripts, you’ll need to set the ExecutionPolicy on your gold image to Unrestricted by issuing the cmdlet ” Set-ExecutionPolicy Unrestricted” at a PS prompt.

I recommend testing the script first on your Master Target server before deploying it farm-wide. The script will still work as long as you have a personality string defined for your Master Target server, even if the vDisk is in Private mode.

How To Create XenApp Published Applications for Test In Just Seconds Using PowerShell

Prerequisite: XenApp6 PowerShell SDK

Let’s say you want to copy all currently published applications into a folder named “Test” in the console tree, while simultaneously modifying the new published apps with different permissions and client folder settings. Here’s how:

First, create the “Test” folder by hand (you can use New-XAFolder -FolderPath Applications\Test if you are so inclined), then use the following command to copy the applications into it:

get-XAApplication | Copy-XAApplication  -folderpath Applications\Test

Second, modify the published application properties to set the client folder (what folder the applications show up under in Program Neighborhood or Web Interface), and the permissions in one fell swoop. We’ll call the client folder “Test” and publish to the groups “domain1\citrix admins” and “domain2\Test Users”:

Get-XAApplication -folderpath Applications\Test | set-xaapplication -clientfolder Test -accounts "domain1\citrix admins","domain2\Test Users"

That’s it! Now doesn’t that beat right-click -> “Duplicate Application”?