Archive for June, 2007

PowerShell session at St. Petersburg .NET Usergroup – July 6th

Next Friday, July 6th 2007 I will be presenting at St. Petersburg (Russia) .NET Usergroup.

The usergroup will start at 6 pm local time and will go till approximately 9. We will start with Gaidar Magdanurov demoing some of his WCF work, and then I will do a PowerShell for developers session, sharing our experience and evangelizing PowerShell as the best command-line you can implement for your applications.

If you happen to be in St. Petersburg, Russia please register and drop by:

Tags: , , , , , ,

Get a list of ALL user properties

Learning something new every day. There was a question in the forums on today on obtaining a list of all attributes a user object has.

I used to think that the way to get the list of attributes exposed directly via PowerShell is to call:

PS:\> Get-QADUser | Get-Member

Or use a user as an example:

PS:\> Get-QADUser "Dmitry Sotnikov" | Format-List

And if you want to get to the more advanced AD properties (such as for example Msds-ResultantPSo in this example of managing fine-grained password policies) you are screwed and have to go to MSDN and read the AD schema docs.

As it turns out, this is not the case! You can get the full list of attributes available for a user object with this one call:

PS C:\> Get-QADUser -ReturnPropertyNamesOnly -IncludeAllProperties


Thanks to Rostislav for the tip!

In my network this gave 458 attributes so I am not providing the full output here.

See the whole thread here.

Tags: , , , , , , ,

UPDATE: Changed Format-Table to Format-List. Format-Table with no property names specified after it is more or less useless – it just gives the default output. Format-List by default lists all properties exposed directly via PowerShell with their values.

PowerShell Answers site and blog

I stumbled across this new (for me) PowerShell site:

The site is run by Trevor Barry who is also delivering PowerShell training. He has just blogged about PowerGUI as well:

“…it has just made the job of building your own PowerShell based management tools so much easier :-)”

(Of course I made sure to take only the most complimentary words out of the post. ;))

Tags: , ,

Webcast: Active Directory Management Made Easy with PowerShell

On July 12 I will be co-presenting (with Bob Bobel – Quest’s Senior Product Manager for Active Directory products) at a webcast:

Webcast: Active Directory Management Made Easy with PowerShell

When: Thursday, July 12, 2007 – 10 a.m. PDT/1 p.m. EDT

In this session, we will talk about using Windows PowerShell to manage Active Directory. We’ll cover different approaches ranging from ADSI to AD cmdlets, and demo the features that are backwards-compatible with Windows 2000/2003 and the ones unique to Windows Server 2008 (e.g. Server Core and Read Only Domain Controller).

In the first half of the session, we will also highlight how you can customize and extend provisioning with Quest ActiveRoles Server through PowerShell. In the second half of the session, we’ll demo how you can use PowerGUI to build custom administrative consoles for PowerShell enabled systems, such as Active Directory, IIS, Exchange and Operations Manager.

Register at the webcast page

As you can see from the description besides the general introduction to PowerShell and AD cmdlets you will get exposed to Quest commercial products as well – which can still be pretty handy if you are planning using PowerShell to manage AD in enterprise infrastructure.

You can register here (you might want to pre-register and login in advance because I think those webcasts have limited number of connections).

Tags: , , , , , , , , , ,

Are Exchange and AD cmdlets compatible?

This is one of the questions I get asked a lot: When and how would you use Exchange 2007 and AD cmdlets together?

The short answer is that the libraries are perfectly compatible and you can mix and match the cmdlets on one machine using the Exchange ones to manage Exchange-related objects/attributes and AD cmdlets for the rest.

For example, AD cmdlets don’t have all the mailbox data, but I can get this from Exchange cmdlets:

Get-QADUser DSotnikov | ForEach { Get-Mailbox $_.DN }

The opposite example would be when I need to reset a password for a mailbox owner – this is something I cannot do with Exchange cmdlets but can do with the QAD stuff:

Get-Mailbox DSotnikov | ForEach { Set-QADUser $_.Identity -UserPassword "M%NewP@ssw0rd" }

Note that instead of piping in the cmdlets directlyI am joining them with ForEach and using DN from AD, or Identity from Exchange to do the match.

System Requirements would be:

  1. Exchange 2007 management tools installed on the local computer (it does not have to be an Exchange server – just a computer with the Exchange 2007 Management Console).
  2. AD cmdlets (again, just the cmdlets installed locally – not necessarily on a DC.)
  3. Have both registered in the same PowerShell console. This can be done by running the following commands in the PowerShell prompt:

PS:\> Add-PSSnapin Microsoft.Exchange.Management.PowerShell.Admin
PS:\> Add-PSSnapin Quest.ActiveRoles.ADManagement

You obviously need to run just one of them if you are using a PowerShell console shipping with either of the cmdlet libraries so you simply add the other library.

If you want more information about Exchange 2007 cmdlets I would highly recommend to subscribe to Evan Dodd’s blog at (and if you are at a conference with him presenting – make sure you attend the session or chalk-talk – I saw him at this TechEd and he was great!)

Tags: , , , , ,

PowerGUI Roadmap Updated

I’ve updated the PowerGUI roadmap and version history page at

Based on the feature poll and discussions in the community we will provide a few pretty significant improvements in our next release (1.0.8 in a week or two from now) in the following areas:

  • Stability and performance:
    • More stable in various PowerShell environments even with corrupt PowerShell installations or third-party snapins. For example, with 1.0.8 there won’t be any need to comment out community extensions start-up commands from the profile, etc.
    • Slightly faster start-up time and less memory consumption.
    • No restart required when linking to PowerShell snapins (libraries).
  • More control of PowerGUI UI from script nodes, actions, and links
    • PowerPack creators will be able to dynamically create tree nodes (e.g. to give OU or public folder hierarchy) and change the labels in the path control above the object grid.
    • Better system requirements enforcement for PowerPacks.
  • “Smarter” parameter dialog boxes
    • we used to have text edit boxes for all types of parameters now we try to be better than that and provide drop-down boxes for enumerations and booleans, date picker for dates, etc.

I know we’ve been asked for more advanced features as well such as a better built-in script editor and we are working on that but this will take slightly longer than a couple of weeks. Stay tuned!

Is there something else that we are missing? Please comment here or in the discussion forum at

Tags: ,

Autoupgrade for PowerShell snapins?

There’s an interesting side-effect of being agile and releasing updates too often – not everyone is able to keep track of your updates and upgrade to the latest version.

With rich applications this is kind of easier. For example, PowerGUI checks for newer version on start-up (we even have a bug when it manages to display the notification behind the splash screen) and offers to perform the upgrade.

By how would you handle the same issue in the command-line?

AD cmdlets 1.0.0 had issues installing on Vista/Longhorn. We fixed this in 1.0.1. The current version freely available for download is 1.0.3 and there are still people trying to use 1.0.0 and suffering from all the issues we have fixed a long time ago.

Is anyone trying to solve similar issues with other PowerShell snapins? Any advice?

One thing I find useful is making PowerShell at least display the snapin version so you know which computer has which version installed (yes, you can look this up in Add/Remove Programs but that’s not that handy.) For AD cmdlets you can do this by checking the version info with the following command:

(get-command (get-pssnapin Quest.ActiveRoles.ADManagement).ModuleName).FileVersionInfo.ProductVersion

Or even modify your profile to have that displayed at each startup:

# add the following code to your profile
# this gives the greeting message with the version info

"Loaded AD cmdlets v."+ (get-command (get-pssnapin Quest.ActiveRoles.ADManagement).ModuleName).FileVersionInfo.ProductVersion

# this changes the window caption:
function Prompt
$host.ui.RawUI.WindowTitle = "ActiveRoles Management Shell for Active Directory (beta) v."+ (gcm (get-pssnapin Quest.ActiveRoles.ADManagement).ModuleName).FileVersionInfo.ProductVersion
"PS> "

But this still does not give auto-update… Can you even have the snapins go to the internet, check for latest version, download it and start the upgrade?

Tags: , ,

Free UI Console for Fine-Grained Password Policies

I spent most of the day today using the password policy cmdlets and the PowerShell UI we all use and love to create graphical user interface for fine-grained password policies (see overviews in 4sysops and Ulf’s blog) in my Windows 2008 lab. And here’s the result (click to see it full size):

Graphical console to manage fine-grained password policies in Windows 2008 domains

What you see on the screen is the graphical user interface to manage those granular password policies and they are far nicer than ADSIEdit. 😉

I included the following functionality:

  • Create new password policy,
  • See password policy properties (PowerGUI adds sorting, filtering, reporting, copy to clipboard and other goodies),
  • Link a password policy to a user or group,
  • Unlink a password policy,
  • Remove a password policy,
  • See the resultant policy for a selected user.

All these operations also support bulk selection.

You can download the pack from PowerGUI library: Fine-Grained Password Policies – please provide feedback so I can make it better.

And, as usual, should you want to learn the command-line or script the same actions, just click the PowerShell Code tab at the bottom of the PowerGUI window – and copy/paste from there.


Tags: , , , , , , , , , , ,

Manage Fine-Grained Password Policies with PowerShell

One of the major new features in the upcoming Windows Server 2008 (aka Longhorn) are granular password policies. The feature allows you to have multiple password policies within a single AD domain and thus be able to better fine-tune the security in your organization.

You can find pretty good write-ups about the feature and using ADSIedit to manage it at 4sysops and Ulf’s blog. However, as Richard pointed recently, using PowerShell to manage them is so much easier than ADSIEdit, so here’s a transcript of me experimenting with the policies in my Longhorn (Beta 3) lab (using AD cmdlets 1.0.3):

PS C:\> # Get the list of all password policies in the domain
PS C:\> Get-QADPasswordSettingsObject

Name      Type               DN                                                                       ----      ----               --                                                                       new pso   msDS-PasswordSe... CN=new pso,CN=Password Settings Container,CN=System,DC=cow,DC=spb,DC=qsft

PSO2      msDS-PasswordSe... CN=PSO2,CN=Password Settings Container,CN=System,DC=cow,DC=spb,DC=qsft   

PS C:\> # Let's see all settings of a particular policy
PS C:\> Get-QADPasswordSettingsObject pso | Format-List

AppliesTo                   : {CN=Haruki.Murakami,OU=Demo,DC=cow,DC=spb,DC=qsft, CN=Event Log Readers,CN=Builtin,DC=cow                              ,DC=spb,DC=qsft}

CanonicalName               : cow.spb.qsft/System/Password Settings Container/PSO2

CreationDate                : 5/16/2007 4:50:29 PM

Description                 : 

DisplayName                 : 

DN                          : CN=PSO2,CN=Password Settings Container,CN=System,DC=cow,DC=spb,DC=qsft

Guid                        : 59632928-e3ff-4ced-afbf-c99ba2b60a8d

LockoutDuration             : -00:30:00

LockoutThreshold            : 0

MaximumPasswordAge          : -20.00:00:00

MinimumPasswordAge          : -1.00:00:00

MinimumPasswordLength       : 8

ModificationDate            : 6/18/2007 11:03:13 AM

Name                        : PSO2

PasswordComplexityEnabled   : True

PasswordHistoryLength       : 24

Precedence                  : 10

ResetLockoutCounterAfter    : -00:30:00

ReversibleEncryptionEnabled : False

Type                        : msDS-PasswordSettings

PS C:\> # Create a new policy, set a few attributes and leave the rest default
PS C:\> New-QADPasswordSettingsObject -Name BeatlesPolicy -Precedence 5 -PasswordHistoryLength 10 -PasswordComplexityEnabled $true

Name            Type               DN                                                                               ----            ----               --                                                                               

BeatlesPolicy   msDS-PasswordSe... CN=BeatlesPolicy,CN=Password Settings Container,CN=System,DC=cow,DC=spb,DC=qsft  

PS C:\> # See the properties of the new policy
PS C:\> Get-QADPasswordSettingsObject BeatlesPolicy | Format-List

AppliesTo                   : CanonicalName               : cow.spb.qsft/System/Password Settings Container/BeatlesPolicy

CreationDate                : 6/18/2007 11:41:17 AM

Description                 : 

DisplayName                 : 

DN                          : CN=BeatlesPolicy,CN=Password Settings Container,CN=System,DC=cow,DC=spb,DC=qsft

Guid                        : c76a72fd-6612-4647-b279-b42cf648e4eb

LockoutDuration             : -00:30:00

LockoutThreshold            : 5

MaximumPasswordAge          : -42.00:00:00

MinimumPasswordAge          : -30.00:00:00

MinimumPasswordLength       : 0

ModificationDate            : 6/18/2007 11:41:17 AM

Name                        : BeatlesPolicy

PasswordComplexityEnabled   : True

PasswordHistoryLength       : 10

Precedence                  : 5

ResetLockoutCounterAfter    : -00:30:00

ReversibleEncryptionEnabled : False

Type                        : msDS-PasswordSettings

PS C:\> # Link the policy to the COW\Beatles group
PS C:\> Add-QADPasswordSettingsObjectAppliesTo BeatlesPolicy -AppliesTo COW\Beatles

Name          Type               DN                                                                               

----          ----               --                                                                               

BeatlesPolicy msDS-PasswordSe... CN=BeatlesPolicy,CN=Password Settings Container,CN=System,DC=cow,DC=spb,DC=qsft  

PS C:\> # See where are all the polies linked now
PS C:\> Get-QADPasswordSettingsObject | Format-List Name, AppliesTo

Name      : new psoAppliesTo : {CN=Kelly Smith,CN=Users,DC=cow,DC=spb,DC=qsft, CN=Event Log Readers,CN=Builtin,DC=cow,DC=spb,DC=qsft}

Name      : PSO2

AppliesTo : {CN=Haruki.Murakami,OU=Demo,DC=cow,DC=spb,DC=qsft, CN=Event Log Readers,CN=Builtin,DC=cow,DC=spb,DC=qsft}

Name      : BeatlesPolicy

AppliesTo : {CN=Beatles,CN=Users,DC=cow,DC=spb,DC=qsft}

PS C:\> # Check resultant policy for user jlennon (note that the Beatles policy got applied via group membership)
PS C:\> Get-QADUser jlennon -IncludedProperties Msds-ResultantPSo | Format-Table Name, Msds-ResultantPSo

Name         msDS-ResultantPSO                                          

----         -----------------                                          

John Lennon  CN=BeatlesPolicy,CN=Password Settings Container,CN=Syste...

PS C:\> # Check resultant policy for user jlennon (note that the Beatles policy got applied via group membership)
PS C:\> Get-QADUser jlennon -IncludedProperties Msds-ResultantPSo | Format-Table Name, Msds-ResultantPSo

Name        msDS-ResultantPSO                                          

----        -----------------                                          

John Lennon CN=BeatlesPolicy,CN=Password Settings Container,CN=Syste...

PS C:\> # Check the resultant policy and note that the one linked directly won
PS C:\> Get-QADUser jlennon -IncludedProperties Msds-ResultantPSo | Format-Table Name, Msds-ResultantPSo

Name        msDS-ResultantPSO                                          

----        -----------------                                          

John Lennon CN=BeatlesPolicy,CN=Password Settings Container,CN=Syste...

PS C:\> # Check where the policy is applied
PS C:\> Get-QADPasswordSettingsObject PSO2 | Format-List Name, AppliesTo

Name      : PSO2AppliesTo : {CN=Haruki.Murakami,OU=Demo,DC=cow,DC=spb,DC=qsft, CN=Event Log Readers,CN=Builtin,DC=cow,DC=spb,DC=qsft}

PS C:\> # Unlink the policy
PS C:\> Remove-QADPasswordSettingsObjectAppliesTo PSO2 -AppliesTo COW\jlennon

Name  Type               DN                                                                               

----  ----               --                                                                               

PSO2  msDS-PasswordSe... CN=PSO2,CN=Password Settings Container,CN=System,DC=cow,DC=spb,DC=qsft           

PS C:\> # Resultant policy changed back to the group one
PS C:\> Get-QADUser jlennon -IncludedProperties Msds-ResultantPSo | Format-Table Name, Msds-ResultantPSo

Name         msDS-ResultantPSO                                          

----         -----------------                                          

John Lennon  CN=BeatlesPolicy,CN=Password Settings Container,CN=Syste...

PS C:\> # Remove the policy from the directory
PS C:\> Remove-QADObject BeatlesPolicy

Are you sure you want to delete this object: CN=BeatlesPolicy,CN=Password Settings
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is "Y"): Y

Windows Server 2008 and PowerShell – are better together! 😉

Here’s the fine-grained-passwords-demo.txt file with the commands in case you want to have fun with them yourself (just change the domain name, etc. to match your lab)

Tags:, , , , , , , , , ,

TechEd PowerShell session in top 5, twice

I’ve just got the scores from the TechEd evaluation forms and it looks like within the Windows Server Infrastructure track the PowerShell session Don and I were giving took the 3rd and the 5th place in top 5 sessions (actually the repeat session scored higher – practice makes perfect). Here are the evals:

Name Attendance Speaker Eval
“The Network is Slow”: Identifying the Cause of
Slow Network Communications (Session Repeats on 6/7)
979 Laura Chappell 8.66
Command Microsoft Windows from C: Level… and Get Ready
for Server Core! (Session Repeats on 6/7)
536 Mark Minasi 8.63
Microsoft Windows PowerShell: The Future of Server
Administration (Repeated from 6/5)
383 Dmitry Sotnikov; Don Jones 8.6
“The Network is Slow”: Identifying the Cause of
Slow Network Communications (Repeated from 6/6)
733 Laura Chappell 8.58
Microsoft Windows PowerShell: The Future of Server
Administration (Session Repeats on 6/6)
762 Dmitry Sotnikov; Don Jones 8.54

By the way together with the repeat the session was attended by more than a thousand attendees.

If you were not at TechEd or were there but missed the session, you can still check out the webcast recording.

Tags: , , , ,

My Recent Tweets


The posts on this blog are provided “as is” with no warranties and confer no rights. The opinions expressed on this site are mine and mine alone, and do not necessarily represent those of my employer - WSO2 or anyone else for that matter. All trademarks acknowledged.

© 2007-2014 Dmitry Sotnikov

June 2007

%d bloggers like this: