SCIF 2.0 Specification

2 SCIF 2.0 General Architecture

The first incarnation of this integration kit was a collection of code that was written on the fly, as needed to solve specific problems in developing OEM integrations with Configuration Manager operating system deployment features. With 2.0, we are taking a more deliberate approach in designing the structure, function and operation of the Framework. The expectation is that the Framework will grow over time, and we need to think about that growth now to avoid completely rewriting it each time. To that end, the 2.0 design is patterned after typical enterprise frameworks or application libraries where the design patterns and major functions are categorized into operational areas.

2.1 PowerShell Framework

SCIF takes into account that the Common Engineering Criteria (CEC) for many Microsoft products (including all new System Center products) requires that the product have an interface controllable via PowerShell scripting, as well as providing Cmdlets to accomplish standard tasks via PowerShell. Because of this common extensibility interface across products, it only makes sense to continue that methodology by providing enhancements and extensions via PowerShell. The benefit of providing extension this way instead of just C# is that it provides a dual-use interface, accessible by IT administrators as well as developers, and can be controlled via either compiled code or Powershell scripts.

Aside from the growing number of product automations and interfaces, the other benefit of utilizing PowerShell is the inherent capabilities of PowerShell, such as remoting, pipelining, security, and easy handling of XML, WMI, the registry, and other data via providers. The prescriptive development guidance also steers developers towards a best practices approach to developing (and documenting) their Cmdlets so that users experience a uniform look and feel as well as consistent usability in utilizing these Cmdlets.
All PowerShell code will be provided as script modules (requires PowerShell 2.0), with an option and instructions for compiling the code into DLL form for partners who wish to modify and/or protect any IP they may have added to the common code.

2.2 The Presentation Layer

Professional developers expect to use tools like Visual Studio to develop user interfaces in C# that are both stand-alone and integrated with other user interfaces (such as SCCM’s admin console). For those users of the Framework, we will provide a set of .NET (C#) assemblies and code to form that presentation layer for creating user interfaces on top of the PowerShell actions. PowerShell also has the capability of loading and using all the standard .NET classes and generating user interfaces as well, but the tools to accomplish that are not as advanced as those for C#. This may be appropriate for administrators or developers creating quick dialogs or user prompts, but it not likely appropriate for professional console development. So, for those users, we will provide this additional layer which will provide the UI but the actual work is being done by PowerShell code.

2.3 Organization of Functionality

The following diagram depicts the general architecture and linkages of SCIF and the products it works with:

The primary actions of the Framework occur within the PowerShell layer. Where possible, existing PowerShell Cmdlets (or scripts) are utilized from the products themselves. When those capabilities are not available or do not provide adequate or appropriate functionality needed for integration purposes, additional PowerShell Cmdlets will be created in the Framework, with the intention of eventually working those Cmdlets into the products themselves at a later release.

Additional command functionality needed during WinPE (which does not provide .NET or PowerShell capability) is done via VBScript in Windows Script Host. These scripts will check for the existence of Microsoft Deployment Toolkit (MDT) utilities and classes in a WinPE boot and utilize those where possible. This standardizes functionality for MDT users, which have a much longer history with OS deployment that SCCM or the OEM integration kit.

2.4 Dependencies and Supported Products

The goal of this Framework is to support the entire System Center product line. Given the infancy of this project and resource constraints, this is only an eventual goal and not currently a reality. Most of the functionality in 2.0 will be aimed at Configuration Manager and related products, though there will be a concerted effort to ensure that adding new product functionality is just a snap-in and not a rewrite and recompile of the framework. This is one of the major advantages of utilizing PowerShell as the primary framework layer.
SCIF, like anything else that is tied to another product, has dependencies on that product. Since SCIF will interoperate with multiple System Center products as well as other related products, it will have multiple dependencies that will need to be monitored closely to ensure no product functionality is broken with any change in those related products.

For SCIF 2.0, the project will have dependencies on the following products:
System Center products:
  • System Center Configuration Manager 2007 (supporting RTM, SP1, R2, and SP2)

Related products:
  • Microsoft Deployment Toolkit (supporting 2007 and 2010)
  • Windows Automated Installation Kit (supporting 2.0, 2.1 and 3.0)
  • PowerShell (supporting version 2.0)
  • WSUS (3.0 SP1+) – including WUA
  • Microsoft Installer (MSI)

Related frameworks and technologies:
  • Windows Forms
  • Windows Presentation Foundation (WPF)
  • Windows Workflow Foundation (WF)

The development platform for SCIF will include the following:
  • Visual Studio 2008 SP1
  • Visual Studio Team Foundation Client (linked to CodePlex and Extranet TFS)
  • InstallShield 2008 (though we could move to Wix)

2.5 Assumptions and Design Constraints


Last edited Aug 28, 2009 at 5:26 PM by rhearn, version 3


No comments yet.