Get only the required parameters when using Get-Help

February 24, 2013

If you type down A cmdlet and forget to include A required parameter (within A parameter set – each parameter set has its own required parameters) than PowerShell will produce an error with the relevant parameter that’s missing.
This trial and error scenario, and carefully reading all of the cmdlet’s help file, is the effective way to get comfortable with A cmdlet.
but sometimes you’ll just want A quick refresher of the required parameters, that’s when I’ll pipe Get-Help -Parameters * to Where-Object:

PS C:\> Get-Help Get-ADUser -Parameter * | where {$_.required -eq “true”}

The output will be the required parameters help content that lives inside the cmdlet’s help XML file.
Again, that’s a little “trick” I use from time to time when I want A quick refresher about the required parameters.
Don’t forget, not all the parameters you see in the output can work together – some cmdlets have more than 1 property sets. In the case of Get-ADUser, you can’t use “-Filter” alongside “-Identity”.

Do you also need to remind yourself from time to time what are the required parameters?

Tell me what you think!


Find Active Directory computer objects by their Operating System

January 15, 2013

Find out if you still have any Windows 2000 objects left in your domain

I was recently asked by a friend how to find Windows 2000 computers with PowerShell.

While its very easy to accomplish with ADUC, he needed a script.

Every computer object in Active Directory has an Operating System attribute (simply called “OperatingSystem”).

All you need to do is to use Get-ADComputer cmdlet and provide an expression for its filter parameter.

PS C:\> Get-ADComputer -Filter ‘OperatingSystem -like “Windows 2000*”‘

Checking \ Setting Remote Desktop Services Profile Settings

December 24, 2012

Check or Set Remote Desktop Services Profile Settings With PowerShell

Many Administrators and Helpdesk teams are assigned with the task of configuring their clients RDP Settings. from the GUI, It is done through the “Remote Desktop Services Profile” tab in the ADUC user settings (that’s in Windows Server 2008 R2. in earlier versions, its called “Terminal Services Profile”)

Like most IT tasks (when it comes to Microsoft’s products), this task can be automated with PowerShell.
Personally, I like to use Microsoft’s ActiveDirectory PowerShell module for all PowerShell AD tasks.

In order to retrieve Remote Desktop settings, the Classic “Get-ADUser -Identity SomeUser -Properties *” wont help us find properties with relevant info, because Get-ADUser can’t get them all.

Another built-in solution is to use the old-fashioned ADSI adapter type. the .NET frameworks wraps the adapter like a PowerShell object. its accessible through the .psbase member set which let us access the objects public members.
Not as friendly as a Cmdlet, but it will give us properties and methods to work with.

The ADSI adapter is operated using LDAP queries (it can also query other LDAP instances than Active Directory), which means I have to use a Distinguished Name (DN) in order to get the user object:

PS C:\> $ADUser = [ADSI]”LDAP://CN=UserName,OU=Users,DC=TestDomain,DC=com”

But I got many OU’s… and typing down DN’s is so V1…

PS C:\> $ADUser = Get-ADUser UserName | select -ExpandProperty disting*
PS C:\> $ADUser = [ADSI]”LDAP://$ADUser”

(Notice that LDAP is all upper-case!)

Next, I query the object received with its InvokeGet() method.
First, I see if the Profile Path attribute is populated:

PS C:\> $ADUser.psbase.InvokeGet(“terminalservicesprofilepath”)

And make sure that the “Deny this user permissions to log on to Remote Desktop Sessions host server”
is UN-checked (“1” stands for allow, “0” for denied):


So I can also check bulks of users:

PS C:\> Get-ADGroupMember Sales_Team | ForEach-Object {
>> Write-Host $_.samaccountname + ” RDP Configuration:”
>> $x = [ADSI]”LDAP://$($_.DistinguishedName)”
>> $x.psbase.invokeget(“terminalservicesprofilepath”)
>> $x.psbase.invokeget(“allowLogon”)
>> }

Thats pretty useful, but how do I configure those attributes? similar to the last example, I use the InvokeSet() method.

PS C:\> $x.psbase.invokeset(“terminalservicesprofilepath”,”\\TSServer\Profiles\UserName”)
PS C:\> $x.psbase.invokeSet(“allowLogon”,1)
PS C:\> $x.setinfo()

Do you find it helpful?
Let me know what you think!
Happy scripting 🙂

Enable PowerShell V2 on Windows 8

November 4, 2012

Enable PowerShell V2 in Windows 8

I’ve been working with Windows 8 for a week or so on my laptop, and I’ve noticed something.
While trying to start a PowerShell V2 host, I get a message that The .NET Framework Version 2 isn’t installed – a requirement for PowerShell V2 to work.

Here is a solution:

Very Important – In order for this to work, you need to assure 2 things:

  1. You need to open an elevated Shell.
  2. You need to open a 64 bit command shell if you’re using a 64 bit Windows OS.

.NET framework version 3.5 is available for installation – as a Windows Feature (which contains all past versions – including version 2) in Windows 8. I know that by using V3’s Get-WindowsOptionalFeature cmdlet, which is part of the DISM PowerShell Module:

PS C:\Windows\system32>; Get-WindowsOptionalFeature -Online | where {$_.FeatureName -Like ‘netfx3’}
Feature Name : NetFx3
State : DisabledWithPayloadRemoved

Now that I know its there, I have to enable that feature (you can also just pipe the former example):

PS C:\Windows\system32>; Enable-WindowsOptionalFeature -Online -FeatureName netfx3Path :
Online : True
Restart Needed : False

installation will take a few minutes. once it’s finished, I can now load a V2 Host:

I can confirm it by checking the $PSVersionTable variable, and its PSVersion property :

PS C:\Windows\system32>; $PSVersionTableName
—- —–
CLRVersion 2.0.50727.6387
BuildVersion 6.1.7600.16385
PSVersion 2.0
WSManStackVersion 2.0
PSCompatibleVersions {1.0, 2.0}
PSRemotingProtocolVersion 2.1