When I saw that Lee Holmes twittered about COM had been improved in WMF 5 September release, I just had to try it right away..

I have several scripts that does some auditing of computers in AD, and populates an Excel spreadsheet, where different properties get highlighted depending on its value. It usually takes around 10 minutes pr 200 servers, I upgraded the machine from PS v3 to PS v 5 September release and went down to 2 minutes for the same 200 machines. Almost 5x improvement. If you don’t believe me I have to screnshots to prove it 🙂

PowerShell v3
PowerShell v5

The European PowerShell Summit, organised by PowerShell.org, will be in Amsterdam September 29 – October 1 2014 at the Park Hotel. Details at http://powershell.org/wp/community-events/summit/

The Summit will feature 3 days of PowerShell sessions from PowerShell team members, PowerShell MVPs and other PowerShell experts. It’s the in-person gathering place for PowerShell enthusiasts and PowerShell users. It’s a place to make new connections, learn new techniques, and offer something to your peers and colleagues. If you can’t get your PowerShell questions answered at the PowerShell Summit you’ll never get an answer.

The Summit agenda is available to view at: http://eventmgr.azurewebsites.net/event/agenda/PSEU14

Registration is now open via http://eventmgr.azurewebsites.net/event/home/PSEU14


Denne gang er det med ret kort varsel i forhold til hvad vi plejer, vi
har ligget i “forhandlinger” med Aleksandar Nikolic ( en af de førende specialister inden for PowerShell remoting, restrained endpoints etc.)
om at komme op og afholde sessioner. Aleksandar blev desværre forhindret i sidste øjeblik, og vi har derfor måttet skyde
arrangementet med ham til start september.

Vi har derfor valgt at holde et arrangement hvor vi selv fra gruppen holder indlæg, programmet ikke helt fast endnu, da vi gerne til have DIG til at tale også.

På nuværende tidsunkt har vi:

Dennis Rye (System Hosting) kommer og fortæller om deres daglige brug af PowerShell i en hosting virksomhed, det være sig integrationer med Orchestrator, planlagt automatisk udvidelse af disk/CPU/RAM i Hyper-V.

Claus T Nielsen (AP Pension) Performance optimeringer, hvornår kan det betale sig at bruge Pipelinen, Jobs, Runspaces etc.

Jakob Svendsen T.B.A

Hvis der er andre der har lyst til at præsentere noget de har lavet, eller noget andet fedt de har brugt PowerShell til, kan i kontakte mig på claustn “Snabel@” Gmail.com, så vi kan få dig på listen over talere.

Lokation og tidspunkt på dagen meldes ud snarest. Så følg med her og på vores LinkedIN gruppe.

We are in the process of testing out Office 365, to see if it will be useful for us, so initially we are just going to use DirSync for some specific users, instead of setting up the complete ADFS solution. I have been extremely busy lately, so I decided to hire someone to come in and setup the DirSync and change the UPN’s for the users who are going to the cloud.

Everything went fine, I gave him a list of OU’s which contained the users who needed the change, and he started opening each user going in and changing the UPN from the GUI.. But apparently I have gotten allergic to doing stuff in the GUI, so I ended writing a small script for him. Which after some procrastinating ended up with a GUI.

It will load a tree view of the current directory (Requires AD cmdlets to be present on the system), then you can select each OU you want to change the containing users UPN name, it will also let you choose to recurse through multiple OU’s.

Be aware this is version 1, so there are no “are you sure prompts”, proceed with caution..

I have exported the code from PowerShell studio with recovery info, so you can load the form, and work with it.


The treeview code is based on code from Thepip3r:

Today I had a discussion with a vendor, they are delivering a solution that reads email from a specific email account on Exchange, and create a ticket in our helpdesk system. Often the email subjects shows up mangled in the helpdesk system, and the particular vendor blames Exchange EWS for not messing up the data.. I had a hard time believing that, so I set out to prove it is not Exchange that is a fault.

First off I needed to download Exchange EWS, which is a separate download from Microsoft.

So just download and install the MSI file.

Then it is time to fire up PowerShell, first thing we need to do is load the EWS assembly

Then we need to specify a username, Password, domain and the mailbox that we want to look at. There are several ways to do this, the simplest way is just writing this in clear text.

Or you could query for it:

Then we have to create a EWS Exchange object.

Possible options for ExchangeService types are Exchange2007_SP1, Exchange2010, Exchange2010_SP1 or Exchange2010_SP2.

Then we have to pass credentials to the $EWS objects depending on how we chose to supply the password initially, we have 2 options again.

Here is the way if we supplied the information in clear text

Here is the way if we prompt for the username/password with Get-Credential

Then we use the AutoDiscoverURL method to look up the Exchange Server URL endpoint.

In this example we will iterate through the inbox and list the first 20 items and output the subjects.

Here is the script in its entirety.

After analyzing the output from Exchange many times, I am convinced that the vendor is mistaken when he claims Exchange is screwing up the data.

Because of a report from our auditors, I was tasked with writing a password generator
for our helpdesk staff, so instead of using a generic variation of the same password,
they needed something more “secure”.

One of the issues is that this password is often read to the user over the phone, so just generating
a random string of characters, would make it very hard to convey over the phone.

So what I did was take a list of common words and generate a password based on the words from a wordlist.

The package consists of 1 script file, and 6 wordlist files (I have taken 100 words with 2,3,4,5,6,7 characters, more words can easily be added to the files)
(This package have wordlists, the one I have for work, I am using Danish words)

Download full package here: PWDGenerator

We are using Queue-IT for some of our external websites, and we needed to start/stop the queues when we doing maintenance on our sites, I found this very easy to do, with Powershell’s Invoke-WebRequest cmdlet.

Here are a few examples.

We are not everyone running Powershell on machines with ”en-US” locale, and sometimes that gives some unexpected problems, if you are running on a non US system, and have been working with Excel for instance, you have probably run into this error when trying to add something to Excel like this:

$xl= New-Object -COM Excel.Application

$xl.Visible = $true



I stumbled upon another culture “gotcha” when trying to get some eventlog info using (Wasn’t obvious to me at the time it was a Culture issue)

$daysBack = (Get-Date).Adddays(-2)

Get-WinEvent -ComputerName Localhost -FilterHashTable @{LogName=’Application’; StartTime=$daysBack; ID=8224}


When I ran it I would get basic information back, just not the contents of the “Message” property, which in this case I very relevant.

I tried running both commands on a test server, where both command worked without any problems. Since the server culture was set to ”en-US” that led me to dig a little deeper into the culture settings.

First thing I tried was to set the culture manually:

[System.Threading.Thread]::CurrentThread.CurrentCulture = "en-US"

Then check to see if the culture was changed.



To my surprise my culture was still da-DK, my initial thought was that PowerShell in v2 is default is running in MTA mode (Multi Threaded Apartment), meaning that my culture query might have been executed by a different thread. I tried to set the CurrentCulture to ”en-US” 100 times, but still every time I queried CurrentCulture I would get ”da-DK” back. (PowerShell v3 is running in STA (Single Threaded Apartment) mode per default)

Next I tried was to wrap it in a ScriptBlock

& {[System.Threading.Thread]::CurrentThread.CurrentCulture = "en-US"

[System.Threading.Thread]::CurrentThread.CurrentCulture }

Which worked, and returned ”en-US” as CurrentCulture

I then tried wrapping it in a function

Function Test {[System.Threading.Thread]::CurrentThread.CurrentCulture = "en-US"

[System.Threading.Thread]::CurrentThread.CurrentCulture }

Which also gave me the Expected ”en-US” Culture.

After conferring with Joel Bennet, this led is to believe that the CurrentCulture is being reset after every pipeline.

We then tried (on a single line)

[System.Threading.Thread]::CurrentThread.CurrentCulture = "en-US";[System.Threading.Thread]::CurrentThread.CurrentCulture


Which confirmed that the culture change is only “active” in the current pipeline.

I found this strange and wrote to the PowerShell team at Microsoft to have them shed some light on why this was happening.

Lee Holmes replied:

“PowerShell saves and restores the thread’s current culture before and after invoking a pipeline so that scripts don’t trash your entire session. When you invoke the command to set the culture, it impacts the entire pipeline – but then we restore it when the pipeline completes. When you put the two commands in the same pipeline, our culture restoration code hasn’t kicked in yet and thus you get to see what the pipeline’s culture was changed to”

So remember if you are trying to run a script that requires a different Culture setting, that it gets reset after each pipeline completes.

Last thing we tried was to see if PowerShell was using $PSCulture to reset the Culture settings, so I tried changing $PSCulture to “en-US” instead of “da-DK” (It is a “read-only” variable, so you have to use –Force)

Set-Variable PSCulture -Value en-US -Force


But to no avail, it seems as if PowerShell checking the system culture, and not something defined within the PowerShell session.

I was tasked with writing a script that would send out an e-mail to users, when there were 14,7,3,2 and 1 days before their AD passwords expired.

I use the Quest AD cmdlets to get users from AD.