Yearly Archives: 2012

New article on PowerShell Magazine: Working with a Uniform Resource Identifier (URI) in PowerShell

The article explains how the [System.Uri] .Net class can be used to manipulate URIs and to convert them into objects. For more information on this topic please have a look at the article that has been posted on PowerShell Magazine:


Code samples from my DuPSUG presentation

Last Friday we had a great day in Eindhoven, the first Dutch PowerShell User Group meeting. It was a day packed with presentations and a lot of talk about PowerShell. I would like to thank everyone involved for making this into a great day! It was great to see the enthusiasm of everyone there.

I have joined the DuPSUG team and I am excited to be involved with the planning and setting up of future events. If you have any suggestions in regards to future events, be sure to contact me or anyone of the team as we are currently gathering feedback for our next event. For more information about the Dutch PowerShell User Group have a look at our website:

The topic of my session was Splatting and [Adsisearcher], I have attached the code samples I used during the presentation to this post, this includes the samples I did not get around to showing:

And for those of you who just could not get enough of Splatting, I will be posting an article on splatting on my blog this week.

Update: Have a look at the Scripting Guy blog post, some photos of the event have been posted: Hey, Scripting Guy! Blog: The First-Ever Dutch PowerShell User Group


New article on PowerShell Magazine: Using UNC paths when working with PowerShell providers

The article explains two solutions to errors that you might run in to when utilizing UNC paths when working PowerShell providers. For example the execution of the following command will fail:

Set-Location HKLM:
Get-ChildItem | Export-Csv -Path \\localhost\c$\registry.csv

This can be solved by adding the specific provider, in this case the FileSystem PowerShell provider:

Get-ChildItem | Export-Csv -Path Microsoft.PowerShell.Core\FileSystem::\\localhost\c$\registry.csv

For more information on this topic head on over to PowerShell Magazine to have a look at the article:


New script: Set AD User/Group on as Local Administrator

I was recently asked to add a certain Active Directory group to a few dozen computers. Using Group Policy and Restricted Groups was not an option here, since there were already other users and groups in the Administrators group. That triggered me to write up a script in PowerShell which could do this for me.

The script is available here: Technet Gallery: Set-ADAccountasLocalAdministrator.ps1

To set an AD Group as a Local Administrator the script can be executed as follows:

.\Set-ADAccountasLocalAdministrator.ps1 -Computer 'Server01,Server02' -Trustee HRManagers

It is also possible to run this script with a plain text file containing a list of computer names:

.\Set-ADAccountasLocalAdministrator.ps1 -InputFile C:\ListofComputers.txt -Trustee User01

New script: Find Orphaned Home Folders

I recently uploaded a new script, Get-OrphanHomeFolder.ps1 to the TechNet Gallery. The script is designed to get a list of all folders in a path and for each of those folders it will query AD to verify if there is a matching Sam account. If this property is not found the script considers this to be an orphaned home folder. If the -FolderSize property is specified the script will retrieve the size of the orphaned folder and display the results as an array of objects.

The script is available here: Technet Gallery: Get-OrphanHomeFolder.ps1

This portion of the script will grab the folder name and query AD for a matching samaccountname, to do this I utilize the [adsisearcher] accelerator so there is no dependency on the AD Cmdlets in this script:

$CurrentPath = Split-Path $_ -Leaf
$ADResult = ([adsisearcher]"(samaccountname=$CurrentPath)").Findone()

If a matching account is not found the script will display the error, in this case the ‘Account does not exist and has a home folder‘ message and the full path to the folder. This information is stored in a hashtable. The code for that look like this:

$HashProps = @{
    'Error' = 'Account does not exist and has a home folder'
    'FullPath' = $_.FullName

The information gathered in this hash table is then used to build a custom PowerShell object with the hash table as its properties:

New-Object -TypeName PSCustomObject -Property $HashProps

For more information about this script or any of the other contributions, drop me a line and I will be happy to discuss this further.