PKI Management Console 1.5

Vadim‘s enterprise certificate management PowerPack went 1.5 and got significantly enhanced. The new features include:

• Native use of Quest AD Cmdlets (version 1.4.2) – so better performance and the code which is easier to understand.
• Additional error handling.
• Certification Authorities information includes CA CRL status.
• New Active Directory PKI node that contains the most common AD PKI-related containers. You can review container contents and publish/unpublish certificates/CRLs by using new actions.
• Now the PowerPack correctly retrieves all available Enterprise OCSP Responders even if they are not running CA service.
• For Certificates node now has two subcontainers: Certificates and CRLs. This allows you to browse both — certificates and CRLs in the local certificate store. For CRLs added new basic actions.
• Graphical dialog boxes for certificate export and import actions.

And of course it still has the great functionality from previous versions:

Here’s a very quick summary of some of the features his tool has:

• Certificate Authorities management:
  • CRL Distribution Points (CDP)
  • Authority Information Access (AIA) settings
  • Review CRLs
  • Publish new CRLs
  • Change CRL publishing periods including overlap settings
  • Revoked Certificates
  • Issued Certificates
  • Pending requests
  • Failed requests
  • Issued certificate templates
  • Revoke/unrevoke certificates
  • Issue or deny pending requests for certificates
  • Add/remove certificate templates to issue
  • Change CRL/CRT/OCSP URL priorities
• Local certificate store management:
  • Import/Export certificates using various certificate types (such CER/pkcs12/pkcs7/SST)
  • Copy/move certificates between stores
  • Delete certificate from store
  • Validate certificates passing them through certificate chaining engine
  • Sign files
• Online Certificate Status Protocol (OCSP) Responders management
  • Review and change OCSP Responder settings
  • Change OCSP URL priorities

All of these support bulk operations, filtering, and reporting. All are available with their source PowerShell code for your reference and scripting.

Learn more about the Enterprise PKI PowerPack and download it here.

New PowerShell, AD, PowerGUI Training

LeadThem Consulting together with Quest Software developed and started offering professional classes covering:

• PowerShell 2.0,
• PowerGUI (including all Pro features!),
• Active Directory scripting, and even
• Non-Windows scripting with PowerShell.

This is a great hands-on training which you can order to help IT professionals in your company get up to speed with PowerShell and these popular PowerShell tools so they can get the most out of the technology available to them.

The training is available in North America, Europe and Asia, in English, Japanese, French and Spanish.

Go to the LeadThem Consulting PowerShell training page to learn the details on the topics covered, and sign up for the training. PowerShell skills you get from a training like that make a great return on investment!

Resolving external accounts in domain groups

You do not have to do anything to do that. If you group contains an account from a trusted domain, good old

Get-QADGroupMember MyGroup

will resolve foreign security principals and show them as regular users.

However, in some cases – for example for performance reasons – you might not want AD cmdlets to perform these look-ups in trusted domains. For that, you just need to use the KeepForeignSecurityPrincipals parameter that we added in AD cmdlets 1.4:

Get-QADGroupMember MyGroup -KeepForeignSecurityPrincipals

Resolving Foreign Security Principals

Starting with version 1.4 AD cmdlets can retrieve and provide detailed information on all properties for foreign security principals.

When you add a user from a trusted domain to a group in your domain, AD creates a local auxilliary object – foreign security principal – to represent this external account. You can essentially think about this object as a pointer to the actual account in a trusted domain. You can read more about them in the Security Principals section of this TechNet article.

Now QAD cmdlets can resolve these “pointers” and show you real accounts to which they point.

For example, this command will retrieve all foreign security principals which you have in your domain (i.e. all foreign accounts ever granted any rights) and try to resolve them to external accounts from original domains:

Get-QADObject -ResolveForeignSecurityPrincipals -Type foreignSecurityPrincipal

Remove disabled accounts from groups

Get-QADGroupMember now has Disabled and Enabled parameters which are very handy when it comes to tasks such as cleaning up a group from disabled accounts:

Get-QADGroupMember MyGroup -Disabled |
    Remove-QADGroupMember MyGroup

Or obviously helps when you need to do something with group members and need to make sure that they are all valid enabled accounts:

Get-QADGroupMember MyGroup -Enabled

Happy scripting!

Manage Email addresses without Exchange cmdlets

AD cmdlets 1.4 added new cmdlets and parameters which let you manage email addresses in your environment even if you do not have Exchange Management Shell. This is very handy if you are on Exchange 2003, do not have Exchange cmdlets installed, or just don’t want to switch between snapins.

Here’s the quick overview of what we have added:

Retrieving accounts by any proxy addresses:

Now Get-QADObject, Get-QADGroup, and Get-QADUser all have PrimaryProxyAddress, ProxyAddress and SecondaryProxyAddress parameters which can let you be more specific in your queries and thus retrieve objects much faster (compared to just supplying the address as identity parameter and relying on default resolution).

For example, you could do:

Get-QADUser -ProxyAddress 'x400:C=US;A= ;P=Quest Software;O=Aliso Viejo;S=Sotnikov;G=Dmitry;I=A;'

or

Get-QADUser -SecondaryProxyAddress '*Sotnikov@algorithm.aelita.com'

Adding email addresses:

Just use Add-QADProxyAddress and specify various parameters for specifics (pair with Clear-QADProxyAddress to replace previous addresses):

Get-QADUser company\jsmith |
  Add-QADProxyAddress -Address 'smtp:jsmith@company.com' |
  Add-QADProxyAddress -Type SMTP -Address 'john.smith@company.com' -Primary |
  Add-QADProxyAddress -CustomType 'sip' -Address 'john.smith@company.com'

Removing all addresses:

Did I mention Clear-QADProxyAddress?

Get-QADUser company\jsmith |
  Clear-QADProxyAddress |
  Add-QADProxyAddress -Address 'smtp:jsmith@company.com' |
  Add-QADProxyAddress -Type SMTP -Address 'john.smith@company.com' -Primary |
  Add-QADProxyAddress -CustomType 'sip' -Address 'john.smith@company.com'

Removing individual addresses:

Use Remove-QADProxyAddress and it’s parameters to operate on a specific address or a set of addresses:

Get-QADUser |
  Remove-QADProxyAddress -Pattern '*@company.com'

Modifying addresses:

Set-QADProxyAddress lets you pick and replace specific addresses:

Get-QADUser |
  Set-QADProxyAddress -From '*@source.com' -MakePrimary

or

Get-QADUser |
  Set-QADProxyAddress -From '*@before.com' -To '*@after.com'

Enabling or disabling email address policy:

Enable-QADEmailAddressPolicy and Disable-QADEmailAddressPolicy are your respective friends and can be applied to individual objects. For example:

Get-QADUser DomainName\UserName | Disable-QADEmailAddressPolicy

Get-QADUser -City London | Enable-QADEmailAddressPolicy

Happy scripting!

Best PowerShell Editor & Debugger

PowerGUI seems to be it if I read Don’s recent roundup right. Let me explain why I think so.

With any product comparisons, teams of the products being compared have bias and feeling that they are not being treated justly, that the criteria are not fair, that some of the features they are really proud of were not considered and so on. This is just the reality. We are passionate about what we are doing and everyone thinks that their However, independent comparisons are very important because they provide some common ground on which you can compare the solutions.

Don Jones reviewed 3 PowerShell script editors and debuggers: PrimalScript, PowerShell Plus, and PowerGUI Script Editor, and found PowerGUI Script Editor and PrimalScript to be the best.

Obviously, considering that this does not take into account PowerGUI Admin Console and MobileShell (in-browser mobile PowerShell command-line to your environment), and that most of PowerGUI Script Editor functionality (excet for source control) is available for free (where as being a for-money thing with competition) – sharing number one spot is a great honor and achievement!

However, if you start looking at details on how the scores were granted you would see that a lot of the features for which we did not get scores are actually present for PowerGUI Script Editor in forms of free add-ons easily available from powergui.org. (Add-ons among other things were out of scope of the review.)

So if you take the review and add the points for these features available as add-ons – PowerGUI ratings will absolutely sky rocket:

• Alias expansion,
• Ability to publish scripts to poshcode.org,
• Transcription support,
• Built-in blue interactive PowerShell console,
• Script signing,
• Smart selection execution,
• View white space characters,
• Word wrap,
• Use virtual white space in your open documents, allowing you to place the cursor anywhere in the document (even after the end of a line),
• Zoom in and zoom out capabilities: great when doing presentations,
• Multiselect in File Open, support for *.ps1xml, *.psc1, *.xml and *.txt files.

A few quotes which I could not help having here:

I was really taken with the maturity and sophistication of PowerGUI… PowerGUI’s snippets feature, in particular, is just seamless and awesome…

PowerGUI, frankly, is pretty complete – and almost everything I wrote about in my review of it comes in the free version. Given the availability of Quest- and community-developed add-ons, I suspect there’s very little you won’t be able to do in PowerGUI. And it’s free. It’s also being very actively developed, and I’ve seen bugs squashed pretty quickly… Frankly, that add-on architecture – and the price tag – has really put PowerGUI on my radar. Unless you need to work on VBScript or other languages, which would definitely push you to PrimalScript, I’m having a tough time seeing why you wouldn’t at least give PowerGUI a shot. In fact, I believe the other commercial editors need to not compete with the Microsoft ISE as much as they need to compete with PowerGUI, especially given the fact that you get such a rich editor for free. Again, I have to admit that PowerGUI hasn’t been on my radar much, but it’s going to be a lot more, now.

I am obviously taking just the quotes I like. For full reviews, go to Don’s posts here.

For the record, we love what other companies are doing in the space. Competition is good for all of us and for the common mission we all have on making PowerShell the automation platform in the enterprise. But we love being the best too.

Locating obsolete users and computers

Just got easier (and faster!) in AD cmdlets 1.4! Before this release you still could manually filter user or computer records by pwdLastSet or LastLogonTimestamp – now user and computer retrieval by a bunch of attributes with an easy command like:

Get-QADUser -Inactive

or

Get-QADComputer -Inactive

This -Inactive parameter retrieves all accounts which have been in expired state, not used for logon, or with with password not being changed beyond the thresholds set by the  Set-QADInactiveAccountsPolicy cmdlet. Like this:

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

You can get the current settings in your environment by executing Get-QADInactiveAccountsPolicy.

In addition to -Inactive, there are other related parameters, such as -InactiveFor – which lets you specify the number of days the account has been in the inactive state:

Get-QADComputer -InactiveFor 30

Or you can go more granular and just use:

NotLoggedOnFor – to specify the number of days since last time the account was used to log on (note that LastLogonTimestamp parameter is used, which means that it is replicated between DCs and the retrieval is fast and works with any domain controller, but it requires 2003 or later AD schema and is only replicated every 9-14 days (so please don’t specify values less than 14):

Get-QADUser -NotLoggedOnFor 60

Get-QADComputer -NotLoggedOnFor 60

PasswordNotChangedFor – days since the account last changed password (computer accounts also have passwords which they are automatically rolling over):

Get-QADUser -PasswordNotChangedFor 180

Get-QADComputer -PasswordNotChangedFor 90

ExpiredFor – just for Get-QADUser – the number of days since the account expired:

Get-QADUser -ExpiredFor 30

You can also use a combination of Inactive/InactiveFor and ExpiredFor/NotLoggedOnFor/PasswordNotChangedFor – in which case the more specific parameters override the default inactivity criteria you set.

Read more about these cmdlets and their parameters in our online reference:

• Get-QADUser
• Get-QADComputer
• Set-QADInactiveAccountsPolicy
• Get-QADInactiveAccountsPolicy

Custom script header and other snippets

Check out the snippets for PowerGUI Script Editor that Bhargav Shukla just shared here. They offer nice templates which you can re-use when working on your scripts.

I downloaded and extracted the files to the snippets folder:

Started PowerGUI Script Editor, pressed Ctrl-I and could see the new snippets:

Here is what – for example – Custom_Script.Header gave me – very handy!

Check out these snippets here. And obviously if you have you own custom snippets that you created and are using – please consider sharing them with the community.

Creating your first PowerGUI Script Editor Add-On

We’ve published a step by step tutorial on creating add-ons for PowerGUI Script Editor. It takes you from the obligatory ‘Hello World’ example (I am sure you have always wanted PowerGUI Editor to show this at start-up! ) all the way through creating a useful add-on (actually the Clear Console add-on we have) with menu item, proper clean up code, and so on.

We also made available full add-on SDK which documents all the APIs we expose.

These are more powerful than ISE extensibility points. Giving you the ability to redefine (or intercept and ammend) any standard functionality in PowerGUI Script Editor, add your own menu and toolbar items (anywhere), event-handlers, and even custom dockable panes within the editor. With the SDK we provide, the sky is really the limit.

PowerGUI Script Editor is one of the richest PowerShell IDEs out there and add-ons take it to the next level. We already have some really useful add-ons – and hopefully the tutorial and SDK can help you add whatever functionality you were missing.

Give them a try and let us know what you think!