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: AD, AD cmdlets, Active Directory, ActiveRoles Server, Freeware, Password management, PowerShell, Release, Security, cmdlets
Subscribe by email
Dmitry's Blog: Cloud, PowerShell and beyond 
Are AD cmdllets only supported on WS2008R2? Are they supported on AD2003? and how are they different from powershell ?
There are two sets of AD cmdlets:
Quest’s free AD cmdlets (also sometimes called QAD-cmdlets): work on pretty much anything: XP+ as admin console, and 2003+ AD as the target (or ADAM/ADLDS). Can be downloaded here: http://www.quest.com/powershell/activeroles-server.aspx (online reference here: http://wiki.powergui.org/index.php/QAD_cmdlets_reference)
And there are the Microsoft’s Windows Server 2008 R2 cmdlets, which indeed have limitations. You could use them against older versions of domain controllers though if you install Active Directory Web Services (ADWS) on it – see this for some details: https://dmitrysotnikov.wordpress.com/2009/09/18/microsofts-ad-cmdlets-available-for-win-2003-and-later/
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.
Thanks
Jai
Jai,
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.
Dmitry
Dmitry,
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.
Regards
Jai