Completing 5 days of Forefront Protection Suite (Stirling) Training

davidzi — Tue, 28 Jul 2009 18:12:00 GMT

Last week I came out to Redmond for 5 days of training on the Forefront Protection Suite, formerly Forefront codenamed “Stirling”. The final name was announced at the Worldwide Partner Conference:

Forefront codename “Stirling” - the next generation of the Forefront Security Suite for integrated, comprehensive protection across endpoints, servers and the edge – will be officially known as Forefront Protection Suite (FPS).

FPS will include the products in the current suite, plus the Forefront Protection Manager (formerly known as the “Stirling” management console) and the Forefront Threat Management Gateway Web Security Service.

The training was pretty interesting. We covered most of the components of the suite, the console, and the integration between all the components. That integration is going to be the real differentiator. Client, Server, and Edge security can all be tightly integrated as well as Network Access Protection (NAP). The solution is built on top of PowerShell so there are significant automation capabilities even beyond the in box solutions.

With very capable component pieces and many integration points, there are a huge number of implementation scenarios and options. This can be very powerful but also a bit daunting until you gain experience with the products. The suite leverages the System Center infrastructure, particularly Operations Manager.

I came away from the 5 days pretty impressed with the suite and the scenarios it enables but also with a healthy respect for the effort required to implement the solution. If the appropriate time and resources are allocated, the end result can be a very robust security infrastructure and most importantly a single console providing situational awareness and reporting across the entire security infrastructure.

If you want to take a look at the suite yourself, the Beta2 release is available here both in installable form and in a pre-configured virtual machine.

Head-to-Head: Workflow Studio vs PowerShell for Automation

davidzi — Sun, 28 Jun 2009 21:07:11 GMT

Here’s an interesting and slightly amusing mock debate between Brandon Shell and Jason Conger on Citrix’s Workflow Studio vs PowerShell for automation. If you aren’t familiar with it, here is the description of what Workflow Studio is:

“Citrix Workflow Studio™ is an infrastructure process automation platform that enables you to transform your datacenter into a dynamic delivery center.”

“Built on top of Windows PowerShell™ and Windows Workflow Foundation, Workflow Studio provides an easy-to-use, graphical interface for workflow composition that virtually eliminates scripting. Workflow Studio acts as the glue across the IT infrastructure allowing administrators to easily tie technology components together via workflows.”

The debate is amusing because in reality both guys understand that each has its place, one is a foundational component of the other, and the combination of the two can be extremely powerful. The core of the “debate” is one’s definition of automation: execution of atomic tasks with as little effort/code as possible (basic PowerShell) or event/workflow driven execution of multiple tasks with associated logic (advanced PowerShell and/or Workflow Studio). The first is an enabler for the latter.

It’s been my opinion since Exchange 2007 and Virtual Machine Manager 2007 committed entirely to PowerShell and with the PowerShell team’s continued focus on simplicity and consistency, that this was the tipping point that was going to enable real automation and orchestration of IT infrastructures. Now with partners (Citrix) and competitors (VMware) alike building on and/or leveraging PowerShell, we’re going to see significant advancements in the state of the art this year.

David Ziembicki on Infrastructure Architecture : PowerShell

Completing 5 days of Forefront Protection Suite (Stirling) Training

Head-to-Head: Workflow Studio vs PowerShell for Automation