When you are enumerating a large number of objects in shell (without outputting results into a file), you might just want to have a quick idea of the ‘total’ number of objects meeting the criteria of you query.

Get-QADProgressPolicy

“displays a progress bar for long-running commands”

This progress bar overlays (highlights in and out) as your query is running. It also appears when you are performing a count using the measure-object cmdlet or the “.count” switch

You can set the progress bar setting and its threshold with

Set-QADProgressPolicy -ShowProgress $true -ProgressThreshold 2

The –activity parameter when relying on the progress bar allows you tag each line of progress with a number so that lengthy process is a bit more obvious with respect to the process to one or more cmdlet’s retrieved results.

Some new parameters :

Five new parameters for Get-QADUser

ExpiredFor

Inactive

InactiveFor

NotLoggedOnFor

PasswordNotChangedFor

Four new parameters for Get-QADComputer

Inactive

InactiveFor

NotLoggedOnFor

PasswordNotChangedFor

But what mechanism decides the “inactivity” benchmark to ask cmdlet to retrieve that information ?

You do.

Get-QADInactiveAccountsPolicy

You can change these settings,

Set-QADInactiveAccountsPolicy -AccountExpiredPeriod 0 -AccountNotLoggedOnPeriod 30 –PasswordNotChangedPeriod 120

Note : These settings are profile specific so ones you define these thresholds they will stay there until you change those settings again.

The NotLoggedOnPeriod is probably based on the LastLogonTimeStamp, but I will check and edit this post if its any different. If it is, remember it may not be accurate and should only be used for estimation. The LastLogonTimeStamp gets updated from the LastLogon (DC specific attribute) based on a 9-14 day swing period.

Also :

“This parameter overrides the logon-related inactivity condition of the Inactive or InactiveFor parameter. Thus, if the NotLoggedOnFor value of 60 is supplied in conjunction with the InactiveFor value of 30, the cmdlet searches for accounts that are expired for 30 or more days, or have the password age of 30 or more days, or have not been used to log on for 60 or more days.”

Previously if you had to use the Get-QADGroupMember cmdlet to retrieve the enabled accounts only, you had to pass the LDAPFilter, now you can use the same –enabled and –disabled parameter as you could with Get-QADUser cmdlet since v1.3.

This and much more. All details can be found here.

The folks who develop these cmdlets and work on adding new parameters do take the feedback very seriously. I have myself asked and gotten couple of requests met. You can do the same.

Share/Bookmark

Here are the new cmdlets in v1.4 :

• Get-QADLocalCertificateStore
• New-QADLocalCertificateStore
• Remove-QADLocalCertificateStore
• Get-QADCertificate
• Where-QADCertificate
• Add-QADCertificate
• Import-QADCertificate
• Show-QADCertificate
• Edit-QADCertificate
• Export-QADCertificate
• Remove-QADCertificate
• Remove-QADPrivateKey
• Get-QADCertificateRevocationList
• Add-QADCertificateRevocationList
• Import-QADCertificateRevocationList
• Export-QADCertificateRevocationList
• Remove-QADCertificateRevocationList
• Get-QADPKIObject
• Publish-QADCertificate
• Unpublish-QADCertificate
• Publish-QADCertificateRevocationList
• Unpublish-QADCertificateRevocationList
• Add-QADProxyAddress
• Set-QADProxyAddress
• Remove-QADProxyAddress
• Clear-QADProxyAddress
• Enable-QADEmailAddressPolicy
• Disable-QADEmailAddressPolicy
• Set-QADProgressPolicy
• Get-QADProgressPolicy
• Set-QADInactiveAccountsPolicy
• Get-QADInactiveAccountsPolicy

With tons of new parameters and bug fixes. All details can be found under ‘ARMS Build History’ text file under the zip file.

http://www.quest.com/powershell/activeroles-server.aspx

Also Dmitry Sotnikov tweeted regarding the updated cmdlet references wiki :

http://wiki.powergui.org/index.php/QAD_cmdlets_reference

Share/Bookmark

1. Download PowerGUI 2.1 from here

2. Get the Advanced Reporting PowerPack from here

3. Launch PowerGUI and import Advanced Reporting PowerPack

4. Click on the root node, go to New and click on the ‘Script Node’ sub-menu option

5. Name your script in the Title bar and type the following cmdlet in the body of the script

Get-QADObject -Type organizationalUnit -SecurityMask dacl | Get-QADPermission

6. By hitting OK the report will run. From the Action Pane (right) click on the ‘Create Report’ link, name the report and add the desired attribute you would like to export on the report

7.  Hit OK and and your HTML based report will be saved by default in your Documents\PowerGUI Exports folder.

You can create all sorts of reports from your AD, do any modifications to your scripts, the format how the Report Pack creates the HTML report and how it generates the data. Download PowerGUI and the Reporting PowerPack and start playing with it.

Share/Bookmark

Following is an example where all (or most of your groups have a company name as prefix and now that the migration has occurred you would like to strip the company name out.

First, lets take a quick inventory to define your scope;

Get-QADGroup -Name companyname* -sizelimit 0 | ft name, SamAccountName

You can also define a specific OU to target a specific location;

Get-QADGroup -name companyname* -searchscope “onelevel” -searchroot “ou=Groups,ou=,dc=mydomain,dc=int” -sizelimit 0

Note that the ‘companyname’ string is the number of characters i.e 11 is what we are manipulating and stripping out here;

Get-QADGroup -name companyname* -searchscope “onelevel” -searchroot “ou=Groups,ou=,dc=mydomain,dc=int” -sizelimit 0 | Rename-QADObject -newName {$_.name.substring(11)} -whatif | Set-QADGroup -samAccountName {$_.samAccountName.substring(11)} -whatif

Always use the –whatif parameter to confirm what changes you are about to make before you process the change. If needed, export the results out to a CSV by adding the export-csv cmdlet at the end.  Note, in above the piping “|” can be written on the same line, ignore the wrapping due the site layout.

Similarly, you can chose to rename to rename by adding a new name or after you have stripped out the name completely, you can add a new prefix to your groups

Get-QADGroup -searchscope “onelevel” -searchroot “ou=Groups,ou=,dc=mydomain,dc=int” -sizelimit 0 | FOREACH {Rename-QADObject $_ -newName (“IT-” + $_.name)}

Above query will grab all the Groups from the defined path and will add “IT-“ as the prefix to all groups. Make sure to append the –samAccountName command to ensure that rename happens properly.

Share/Bookmark

An easy of distinguishing both versions is to look for a PowerShell variable called $psversiontable. If it is not defined, then you are running v1. If it is there, you have v2. You can also look at a registry key to differentiate between v1 and v2: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1\PowerShellEngine\PowerShellVersion.

Note that if PowerShell was installed as an update package you may not find it under installed software. You may have to look at the update packages. Also note that PowerShell v2 can be installed over v1 without having to uninstall v1 first. If you were running any CTP versions than the install may make you find and manually uninstall v1 first.

Share/Bookmark

Using Get-QADUser cmdlet, you can define the location of all your users using the –searchlevel parameter or you can sweep the whole directory for all user accounts. And then pipe the results to the foreach and use Set-QADuser to fix the display names (in this example) based on the users’ first and last name

Get-QADUser mydomain.int/users -sl 0 | foreach {Set-QADUser $_ -DisplayName ("{0} {1}" -f $_.firstname,$_.lastname)}

The –sl 0 parameter defines the limit of users to 0.

Share/Bookmark

The tombstone lifetime in an Active Directory forest determines how long a deleted object (called a “tombstone”) is retained in Active Directory Domain Services (AD DS). The tombstone lifetime is determined by the value of the tombstoneLifetime attribute on the Directory Service object in the configuration directory partition.

Directory Services veteran and MVP Joe Richards has published a short blog entry demystifying the confusion a technet article has caused in regards to how to go about figuring a TSL on a particular domain. Note that new forests that are installed with Windows Server 2003 with SP1 and up have a default tombstone lifetime of 180 days.

Joe shares his ADFIND tool to lookup the current value of the TSL attribute (irrespective of what OS was used to build the forest). Note that as Joe pointed out if this attribute is not set (i.e empty value) then the TSL is 60 days. Here I show you how to lookup the TSL with PowerShell.

Using Quest cmdlets :

Get-QADbject “CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=yourdomain,DC=int” includeallproperties | Select TombstoneLifetime

And with using native AD cmdlets (of ADWS) in Windows Server 2008 R2 :

Get-ADObject -Identity “CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=R2,DC=lab” -properties tombstonelifetime

Also within PowerShell, you can also use ADSI to lookup the TSL value.

[ADSI]$config=LDAP://cn=Directory Service,cn=Windows NT,cn=Services,cn=Configuration,DC=R2,dc=lab

$config.TombstoneLifetime

Also, here is how you can use DSQUERY from the Windows Support Tools to lookup the TSL.

dsquery * “CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=R2,DC=lab” -scope base –attr

tombstonelifetime

Note that I have used my test forest’s DN of R2.lab in above examples, be sure to replace the values with your forest’s DN. Above query should be typed in one line.

Share/Bookmark

You may also use this to export this data to a CSV file. Notice that when using the export-csv cmdlet you must choose the ‘select’ and define the attributes that should be exported. Format-Table (aliased above as FT) is used to display the information on the console.

GetQADUser-sizelimit 0 | where{$_.whencreated -gt (get-date).adddays(-90)}| select Name,WhenCreated,DN | Export-csv c:\Users90days.csv

There is always a couple of ways to accomplish the same task with further fine tuning your query. As you can see that above query would grab all the users in the domain, going by their whenCreated attribute and present you the pertinent users.

You can define the OU to search with the –searchroot parameter.

Get-QADUser –Searchroot ‘test.mydomain.int/Users/Chicago/’ | where{$_.whencreated -gt (get-date).adddays(-90)}

Alternatively, if you would to like find users account that have been modified since x number of days, you can try something like this.

$OU = <OU PATH>
Get-QADUser -LastChangedAfter (get-date).adddays(-7) -search $OU -sl 0 | ft name,whenchanged

Share/Bookmark

$old=(get-date).adddays(-30)

Get-QADUser -SearchRoot ‘mydomain.int/users’ -Name “*$*” -IncludedProperties pwdlastset | where {$_.pwdlastset –gt $old}

You may also sort and view the results as below

Any trusts that have not reset their passwords in last 30 days are probably no longer valid. If you are using ADWS on Windows Server 2008 R2, then something like below should suffice, assuming you have already created the $old variable using the same command as above.

Get-ADUser -Filter ‘Name -like “*$*”‘ -Properties pwdlastset | where {$_.pwdlastset –gt $old}

Share/Bookmark

I highly recommend to use the built in cmdlet help to learn the syntax and available parameters. Whether you are using the cmdlet as an one-off task or trying to incorporate it into a script.

First we run, Help Set-ADaccountPassword -examples to look at what the options are and then use,

Set-ADaccountPassword -Identity Moyo -reset where the user id is moyo, and provide the new value of the password. Unlike many other functions where you must run the ADWS under elevated ‘administrative’ privileges, if you are running this cmdlet on your DC, you can run this under normal security context.

Share/Bookmark