What’s new in AD cmdlets 1.1.0?

Here’s a quick summary of the new and exciting features added in Quest’s free AD cmdlets 1.1.0 just published on the web (I plan to provide more details and examples next week):

1. Get-QADGroupMember -Indirect – this new parameter allows you to retrieve complete group membership for nested AD groups in one command!

2. Permission management cmdlets:

  • Get-QADPermission,
  • Add-QADPermission,
  • Remove-QADPermission,
  • Get-QADObjectSecurity,
  • Remove-QADObjectSecurity.

3. New parameters of Get-QADUser:

  • HomeDirectory (string)
  • HomeDrive (string)
  • ProfilePath (string)
  • LogonScript (string)
  • Email (string)
  • AccountExpiresBefore (DateTime)
  • AccountExpiresAfter (DateTime)
  • AccountNeverExpires (bool)
  • PasswordNeverExpires (bool)

4. New parameters of Set-QADUser

  • HomeDirectory (string)
  • HomeDrive (string)
  • ProfilePath (string)
  • LogonScript (string)
  • Email (string)
  • AccountExpires (DateTime, nullable)
  • PasswordNeverExpires (bool)
  • UserMustChangePassword (bool)
  • TsProfilePath (string)
  • TsHomeDirectory (string)
  • TsHomeDrive (string)
  • TsWorkDirectory (string)
  • TsInitialProgram (string)
  • TsMaxDisconnectionTime (TimeSpan)
  • TsMaxConnectionTime (TimeSpan)
  • TsMaxIdleTime (TimeSpan)
  • TsAllowLogon (bool)
  • TsRemoteControl (int)
  • TsReconnectionAction (int)
  • TsBrokenConnectionAction (int)
  • TsConnectClientDrives (bool)
  • TsConnectPrinterDrives (bool)
  • TsDefaultToMainPrinter (bool)

5. New properties of User object

  • HomeDirectory (string)
  • HomeDrive (string)
  • ProfilePath (string)
  • LogonScript (string)
  • AccountExpires (DateTime, nullable)
  • PasswordLastSet (DateTime, nullable, readonly)
  • PasswordAge (TimeSpan, nullable, readonly)
  • PasswordExpires (DateTime, nullable, readonly)
  • LastLogonTimestamp (DateTime, nullable, readonly)
  • LastLogon (DateTime, nullable, readonly)
  • LastLogoff (DateTime, nullable, readonly)
  • AccountIsDisabled (bool)
  • AccountIsLockedOut (bool)
  • PasswordNeverExpires (bool)
  • UserMustChangePassword (bool)

6. Set-QADGroup now has GroupType and GroupScope parameters (to change group type and scope ;))
7. New cmdlet Get-QADRootDSE
8. Disambiguation prefixes in Identity parameter: e.g. Get-QADUser ‘dn=cn=object_with@sign’
9. Access to default domain password policies through the domain object:e.g. Get-QADObject mydomain.local/ | format-list *
10. Functionality specific to Quest ActiveRoles Server (this will only work if you have the commercial app):

  • Access template link management,
  • Dynamic groups.

Lots of cool and exciting features and numerous bugfixes.

You can download the beta on the Quest’s AD cmdlets page. Please provide your feedback in the AD PowerShell discussion forums.

Tags: , , , , , , , , ,

10 Responses to “What’s new in AD cmdlets 1.1.0?”

  1. 1 Abhi November 8, 2010 at 11:18 am

    Are AD cmdllets only supported on WS2008R2? Are they supported on AD2003? and how are they different from powershell ?

  2. 3 Jai Maharaj March 21, 2011 at 2:28 am

    Hi Dmitry,

    I am try to use the get-qadpermission and add-qadpermission cmdlets and get the permissions on one OU and then set the same permissions on another OU but using a different User/Group. Currently, if I user get-qadpermission “OU=OUname,DC=Contoso,DC=Com” | add-qapermission “OU=OUname,DC=Contoso,DC=Com” , it sets the permissions for the same User/Group that has the permission on the first OU. I would like to set the same permissions but for a different User/Group.


    • 4 Dmitry Sotnikov March 22, 2011 at 6:36 pm


      You could obviously script checking for the Account and then manually recreating the Add-QADPermission call, like:

      Get-QADPermission dmitry.local/source | ForEach-Object {
      if ($_.AccountName -eq ‘DMITRY\CBarber’) {
      Add-QADPermission ‘dmitry.local/target’ -Account ‘DMITRY\ABurks’ -ApplyTo $_.ApplyTo -Rights $_.Rights
      } else {
      Add-QADPermission ‘dmitry.local/target’ -InputPermission $_

      However, keep in mind that there might be other ACE options like ExtendedRight, Property, PropertySet, ApplyToType, ChildType – and depending on which ones you have in your environment, you might need to check for them as well.

      Also, there is a fairly active Active Directory and PowerShell forum here: http://powergui.org/forum.jspa?forumID=173 – you might want to check with the folks over there.


  3. 5 Jai Maharaj March 23, 2011 at 2:25 am


    Thanks a lot for you reply. I finally got it going by exporting the settings to file and then reading that file to import the settings as a different group.

    I tried the method you have just suggested and it fails because as soon as you specify one option, then you have to specify all of them.

    The export to file worked well for me though. I has to massage the data a bit, especially for the -Property and -ExtendedRight options because the format of the exported data was not what it was expecting as an input.

    Thanks a lot once again.


  1. 1 Nested AD Groups and PowerShell « Dmitry’s PowerBlog: PowerShell and beyond Trackback on May 5, 2008 at 7:03 am
  2. 2 Retrieving Domain Password Policies « Dmitry’s PowerBlog: PowerShell and beyond Trackback on May 7, 2008 at 7:02 am
  3. 3 Read Active Directory Permissions « Dmitry’s PowerBlog: PowerShell and beyond Trackback on May 13, 2008 at 8:16 am
  4. 4 Find and fix broken inheritance « Dmitry’s PowerBlog: PowerShell and beyond Trackback on June 4, 2008 at 7:01 am
  5. 5 AD cmdlets 1.1 RTM! « Dmitry’s PowerBlog: PowerShell and beyond Trackback on July 4, 2008 at 9:29 am

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

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

May 2008

%d bloggers like this: