Schedule update on Forefront

You know that I am a big fan of what we are going to deliver with our Forefront Suite in the next version code-named Stirling. You probably heard me talking about compliance (where, from a technical perspective Forefront can play an integral part) and what I call the best of need integrated platform – where again Forefront delivers the heart of the platform.

Now, we just released an update on our schedule plans, which you can find here Schedule Update for Forefront “Stirling”

Even though I definitely do not like delays, this are our plans as of now:

  • We will begin the release of the “Stirling” security suite with the delivery of Forefront Server Security for Exchange and Threat Management Gateway (the next generation of ISA Server) in the fourth quarter of 2009.
  • The "Stirling” management console, Forefront Client Security 2.0 and Forefront Security for SharePoint will be released in the first half of 2010. 
  • We will ship a public beta 2 of “Stirling” and a release candidate prior to final release.

This is the bad news. However, there are very good news with this delay. Whenever I talked about compliance and the platform as mentioned above, the very first question I got was always: What about third-party integration? This is not about Microsoft only! We know that and we heard you. read the reason for the delay in the post mentioned above:

One of the top customer requests was adding interoperability with third party security solutions.  In response, we plan to increase our focus on one of the unique features of “Stirling”, Security Assessment Sharing (SAS.)  SAS correlates security events from different Forefront products and third party solutions, enabling administrators to quickly investigate and remediate security events.  We will provide information about interoperability partners in the near future.

So, in order to really deliver on policy compliance there are other technologies you can deploy beforehand: We often talk about Domain Isolation using IPSec, which already can be a very good first step towards separating managed from unmanaged clients. Do this based on X.509 certificates as the step after this would then be to deploy Network Access Protection to separate policy compliant from non-compliant computers.

So, if you are serious about re-thinking the way you run your network and bringing it closer to address policy compliance, there is a lot to do beforehand. In the meantime, look at the beta and the RC we are going to release. From what I have seen already – it rocks!


Comments (0)

Skip to main content