Shariq Sheikh | Port 389

Whereas most of newly added cmdlets focus on  PKI and Email Address Management in v1.4, there are a few cmdlets and handful of new parameters that ought to come in very handy with your AD tasks. Below I review a few that I think are some great adds :

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.

From version 1.2 with 49 cmdlets, to version 1.3 with 63 cmdlets and now on to version 1.4 that has 32 new cmdlets making it total of 95.

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

Often times you need to analyze your existing permissions (delegations) on your AD Objects within your domain/forest, perhaps you have just taken over an administrative role over AD and would like to quickly surface information regarding what group and user accounts have certain rights across the board in a pertinent domain. With PowerGUI and Kirk Munro’s “Reporting” PowerPack, you can generate nicely formatted HTML files (that expand and collapse) for each object that has delegated permissions within AD.

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.

Often times there is a need to standardized Groups’ naming convention such as with migrations, when you don’t have a rich migration tool that can conform the names or when you don’t have a AD proxy management tool such as ARS in your normal provisioning process. Using Quest Cmdlets with PowerShell to rename groups is a snap. There are numerous ways you can fit the Cmdlets and different parameters to meet your need. In this post, I show you a few ways I have used to rename groups in bulk.

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.

There are two types of PowerShell versions out there. PowerShell v1 that dates back to 2006 and the PowerShell v2 that is bundled with Windows 7 and Windows Server 2008 R2, and also mysteriously released for down level clients such as Windows Vista and XP (under vaguely named Windows Management Framework (Windows PowerShell 2.0, WinRM 2.0, and BITS 4.0).

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.

For small shops that do not leverage automated provisioning tools, they face challenge in keeping the attributes for Users and other objects in AD standardized. For similar situation, recently I was asked from Access Control team if there is an easy way to fix the displayName attribute for all users or to fill in the display name where its missing based on the Users’ first and last name. The answer is a simple PowerShell one-liner using Quest Cmdlets.

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.

What is Active Directory Tombstone Lifetime (TSL) ?

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.

A request came in from the Access Control team requesting that they be provided with the users that have been created in a particular office since last 90 days. As usual, PowerShell (with QAD cmdlets) has very simple one liners you can retrieve this information with.

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

I had earlier posted about the Add-Computer cmdlet bug in Windows 7 RC builds which didn’t allow the computer to be added to the domain via PowerShell. With Windows 7 RTM, it is fixed and turns out to be pretty handy should you need to script the domain joins for your new builds. The command to add the machine is pretty simple.

The –passthru switch as chosen in the example shows the results.

Check out help for what you can do with this cmdlet such as when you need to add the computer account to a specific OU. Remember that adding machine via PowerShell to the domain does not require you to create the computer name before hand, but it pre-exists than its not an issue.

Few examples :

Add-Computer -domainname Domain02 -OUPath OU=testOU,DC=domain,DC=Domain,DC=com

Add-computer -workgroupname WORKGROUP-A

Add-computer -domainname Domain01; restart-computer   (this adds the restart option)

For more info. see http://technet.microsoft.com/en-us/library/dd347556.aspx

For reasons unknown to me the useful Rename-Computer cmdlet (shown in my earlier example) seems to have been removed past CTP3 builds and the RTM. Even though the technet reference for all Windows 7 PowerShell cmdlets still has it listed.

Here is a discussion I found.

http://social.technet.microsoft.com/Forums/en-US/w7itproinstall/thread/8cdf0302-a41d-4973-9bff-2923e7ad0178

What is the AdminSDHolder and SDPROP ?

Ever wonder what controls the native permissions on the security principal such as Domain Admins and Administrators in Active Directory ? What if an owner changes the permission these entities have ? The permissions do come back. They must. John Policelli had a great article on the subject of AdminSDHolder and SDPROP in this month’s technet article. The magic is driven by the AdminSDHolder which is an object that resides under the System container of Domain NC. This object has a unique ACL which is used to control the permissions of security principals that are members of built-in AD groups, also known as “protected groups”. The SDPROP (Security Descriptor Propagator) is the process that runs in the background and complies all the permissions according to the AdminSDHolder.

Every hour, a background process called SDPROP runs on the domain controller that holds the PDC Emulator operations master role. It compares the ACL on all security principals (users, groups and computer accounts) that belong to protected groups against the ACL on the AdminSDHolder object. If the ACL lists aren’t the same, the ACL on the security principal is overwritten with the ACL from the Admin–SDHolder object. In addition, inheritance is disabled on the security principal.

John has done an excellent job on explaining the process and how it can affect you. I would like to show you the one-liners with which you can look-up who is part of that “elite” bunch in your AD with PowerShell (ADWS) on Windows Server 2008 R2 and as well with PowerShell (and Quest) in Windows Server 2003 domain.

For every recipient of this process i.e security principal such as user, group or computer, there is an attribute named “admincount” that gets marked as “1″ indicating that this principal via nesting or explicitly is part of a protected group in AD.

On Windows Server 2008 R2 where can you use (ADWS), the simple command to retrieve the user and group objects with admincount set as 1 is this.

Get-ADgroup -LDAPFilter “(admincount=1)” | select name

Get-ADuser -LDAPFilter “(admincount=1)” | select name

In domains that are pre-Windows Server 2008 R2, you can use similar QAD cmdlets.

Get-QADGroup -LDAPFilter “(admincount=1)”

Get-QADuser -LDAPFilter “(admincount=1)”

If you would just like to get the total number of users, you may count it like this.

(Get-QADuser -Ldap “(admincount=1)”).count

Another great read on AdminCount, AdminSDHolder, and SDPROP is right here from Mike B. Smith.

Some discrepencies pointed out by Joe in the technet article. He explains in great detail. http://blog.joeware.net/2009/09/08/1693/

Launch the PowerShell under Administrator’s account context, and type this cmdlet.

Enable-ADOptionalFeature -Identity ‘CN=Recylcle Bin Feature,CN=Optional Features,CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=yourdomain,DC=com

Read and understand the warning of this action’s irreversebility, and hit “Y” for yes to continue.

In following screenshot I show you an error not neccesarily applicable to you, the cmdlet complained about not being able to verify the FSMO ownership role. The reason for this was the fact that in my VM Lab environment I had shut down another DC for maintenance and it had not been replicated or talked to.

As I brought that downed DC back online, forced the replication, I was able to proceed. You can then confirm with this cmdlet.

Get-ADOptionalFeature ‘Recycle Bin Feature’

Here is a great post on this hot feaure of Windows Server 2008 R2.

http://msmvps.com/blogs/ad/archive/2009/03/31/taking-out-the-trash.aspx

A couple years back someone made a recommendation on Microsoft Exchange Forums that equivalent to Exchange BPA, it would be nice for AD Admins to have an AD Best Practices Analyzer, this was passed on to the AD Team. Though I am not if this particular thread was the driver behind it, but starting in Windows Server 2008 R2, AD Admin will have the BPA.

“Active Directory Domain Services (AD DS) Best Practices Analyzer (BPA) is a server management tool that can help you implement best practices in the configuration of your Active Directory environment. AD DS BPA scans the AD DS server role as it is installed on your Windows Server 2008 R2 domain controllers, and it reports best practice violations. You can filter or exclude results from AD DS BPA reports that you do not need to see. You can also perform AD DS BPA tasks by using either the Server Manager graphical user interface (GUI) or cmdlets in the Windows PowerShell command-line interface.”

ADBPA is a great idea, it gives you a quick glance into the new DC you have just stood up. It points you toward setting the NTP settings correctly if the DC is also PDC. It lets you know if your OUs are not set to be protected from accidental deletion. It also reminds you that certain directory partitions (NC) have not been backed up since a certain of period time. You can access the ADBPA from the Server Manager -> ADDS.

You may notice that if you are running the Windows Server 2008 Beta version, there seems to be a bug with ADBPA rule. One of the non-compliant complain is about the DC’s inability to reach a DNS server to retrieve DC specific records even when the DC itself is also the DNS and the pertaining records are existing. This behavior has been corrected in the RC version.

The compliant section also shows where your DC meets the expected configuration, such as when it advertises itself as a DC in its local site. One downside I see with ADBPA is that it cannot be self-launched into its separate MMC. Or unlike the Exchange BPA, it is only accessible in a small window from within the Server Manager. So there if is large number of non-compliant/compliant messages, the browsing ability is not that great.

How does ADBPA gather this data ?

“When you run the AD DS BPA scan on a domain controller, the BPA engine invokes the AD DS BPA Windows PowerShell script that collects configuration data from the AD DS environment that this domain controller belongs to. The AD DS BPA Windows PowerShell script then saves the collected AD DS configuration data to an XML document. The BPA run-time engine validates this XML document against the XML schema.”

For more information on ADBPA. See this.

Apparently there is a bug with Add-Computer cmdlet in PowerShell V2 version of Windows 7. This cmdlet according to the help (examples) allow you to join a machine to the domain. I was successful in renaming the machine with the Rename-Computer cmdlet but had issues adding the machine to the domain. Keep in mind that in Windows 7 and Windows Server 2008, you have to launch PoSH with elevated privileges, even if you are logged on as an Admin. You have to right click on the shortcut and do “run as administrator”, see screenshot 1 for the error you receive, if you don’t.

Then I take a look at the help and confirm that the syntax being passed is the right one and try with the computername,

A different error as if the credentials being password are not sufficient which is not the case as they are of Domain Admins’

While that bug gets fixed, Kirk from over at PowerGUI forums has this QAD cmdlet alternative for you as the solution.

C:\PS>new-qadObject -ParentContainer 'OU=ComputersOU,DC=company,DC=com' -type 'computer' -name 'comp1' -ObjectAttributes @{sAMAccountName='comp1'}

Lets wait for Add-QADComputertoDomain too, perhaps !

A long awaited PowerShell version 2 will be released with Windows Server 2008 R2 and Windows 7 (currently both in beta). As Microsoft intends to push PoSH as the management/interactive/command driven shell, you will find the PoSH short-cut in your quick launch toolbar. In addition to what PoSH v2 has to offer such as remote management capabilites, a notable difference is the number cmdlets over version 1. PoSH v2 will have total of 235 native cmdlets where version 1 only had 129.

Watch a quick (first) screencast I did on this.

Using PowerShell, you can get a report of patches that are installed on a remote workstation/server. Launch the PowerShell and run the following command where testworkstation is the name of your computer.

Get-WmiObject -Class Win32_QuickFixEngineering -ComputerName testworkstation

If you need to provide another set of credentials for the domain-joined machine you are after, or if you get access-denied error. Use the Get-Credential cmdlet to provide the credentials.

You can see above the default output of the cmdlet, but you can narrow down the results with the following option.

Get-WmiObject -Class Win32_QuickFixEngineering -ComputerName testworkstation | select description,hotfixid,installedon

I would further export it to a CSV for an easier review and analysis with the following export option.

Get-WmiObject -Class Win32_QuickFixEngineering -ComputerName testworkstation | select description,hotfixid,installedon | export-csv c:\Testworkstation_Hotfixes.csv

As you can see that this cmdlet relies on the WMI object class. It is necessary to have the pertinent ports open between the workstation you are running this from to the target. WMI is an entity of shared DCOM ports/services. If there are firewall issues you can’t overcome then perhaps run the PowerShell cmdlets from within the same subnet of your target machine.

One of the exciting features of Windows Server 2008 is Powershell (command-line interactive shell and scripting language). Powershell allows Admins to achieve control over their Active Directory/Servers environment and accomplishes the remote management tasks which used to be done with VB, WMI and ADSI scripts. Where WMI and ADSI calls are still part of Powershell cmdlets pronounced command-lets (commands that trigger the call in the interactive PS shell), the number of lines and the need to know the ‘scripting’ has substanially been lowered.

Powershell v1.0 can be installed as a feature in Windows Server 2008 or can be individually installed on Windows XP SP2 or Windows Server 2003 SP1 from here as RTW. This provides 130 cmdlets that enable easier system administration and accelerated automation. On top of that Quest Software has released ActiveRoles Management Shell for Active Directory (for free) that provides another set QAD (Quest Active Directory) cmdlets that extend the AD specifics management tasks. You can get the Quest Management Shell and subsequent cmdlets from here (http://www.quest.com/powershell/activeroles-server.aspx)

While Quest cmdlets run in their own shell, the quest snap-in can also be registered in the Powershell by running the following command, after installing Quest Management Shell.

Add-PSSnapin Quest.ActiveRoles.ADManagement

You may run Get-PSsnapin to validate

Alternatively you can work directly within the Quest Management Shell where you will have all the native PS cmdlets available to you. To find out all the QAD related cmdlets, run get-commad *-qad*.

And lastly give one of the QAD cmdlets a test drive, for instance to create a new user in AD and to find out how the New-QADuser can be used, run the Get-Command New-QADuser -detail to learn the full syntax and available options.

Here are a couple of great resources to hit the ground running with Powershell and Quest Management Shell (a.k.a QAD Cmdlets).

PowershellPro Tutorials
PowerGUI and QAD Wiki
PowerGUI Forums
Windows Powershell Forums