Why is Quest doing free PowerShell stuff?

I love conspiracy theories and here’s the one from me. In his Registration-Free AD Cmdlets post Jeffrey raises questions on why Quest is providing AD cmdlets for free, and what is the commercial thinking behind this. He makes a great point that a commercial vendor like Quest needs to make money and whatever is not making money for a vendor might not be viewed as a long-term investment on which you can rely. So here’s the truth: Quest is making money on the free PowerShell cmdlets. And here’s how:

1. Indirectly as a marketing tool: Quest gets a lot of money selling Active Directory migration and management tools and AD cmdlets are getting us even better brand-recognition in this target market. I think Tyler got it.
2. Directly to upsell: Letting us sell our flagship AD management product – Quest ActiveRoles Server.

I think everything is more or less clear with the former, so let me explain more about the latter.

<commercial product pitch section>

We’ve been very successful selling ActiveRoles Server for normal UI-based operations. Basically, it substitutes Active Directory Users and Computers and makes all AD management go through its proxy. The proxy brings a lot of additional value:

• Role-based delegation: you don’t have to give your helpdesk staff – you don’t have to give them native AD permissions, instead you can do that through proxy and in a very efficient fashion (e.g. “allow to reset passwords for locked-out accounts if the user office is ‘New York’”).
• Full auditing: any changes made to AD are audited providing full change history for any object.
• Automated policy enforcement: specify policies on what your AD objects need to be and have them applied to any change (e.g. when a user gets deprovisioned the account is actually not deleted but disabled, moved to a special OU, membership gets cleared, email forwarding gets set to the manager, etc.)
• (My favorite feature) Approval workflows: if certain changes need to be approved (e.g. group membership in some privileged groups) the change won’t get into effect until the person in charge reviews and approves.

Now here comes the conspiracy part: if you have the (free) AD cmdlets and the (commercial) ActiveRoles Server – you can make the cmdlets use all these benefits for your cmdline and PowerShell scripts. All you need to do is initialize your session with Connect-QADService -proxy and all your PowerShell code will go through this policy/approval/etc. engine.

	AD cmdlets	AD cmdlets with Quest ActiveRoles Server
PowerShell command-line for Active Directory	+	+
Auditing for all changes	-	+
Role-based delegation (e.g. for helpdesk scenarios)	-	+
Automated policy enforcement	-	+
Approval workflows	-	+

Here’s a slide that illustrates the architecture:

We believe that this commercial functionality brings tremendous value. I know that PowerShell is magnitudes more readable than VBScript with ADSI. However, wouldn’t you want to have a safety net around your AD automatically applied to all your scripts? Wouldn’t you want to get “flight recorder” automatically working for all your scripts so you know what they are actually doing? Wouldn’t you want to have all your corporate policies, standards, and approvals applied to scripts and command-line? We are seeing that enterprises answer yes to all of the above and here’s why for them we find our product a great fit.

This has been that way for UI administration and VBScripts for quite some time. Now it’s time to move to PowerShell!

</commercial product pitch section>

Tags: ActiveRoles Server , AD cmdlets Quest Software PowerShell ARS Conferences Active Directory Blogosphere

About these ads