You’re probably still unraveling the smirk on your face and thinking “wtf is that title about?”  Fair enough.  So, allow me to digress…


I’ve blogged and blabbered about this before, and I’ll probably do it again (I am a human and humans are prone to repetitive stupidity, after all).  Basically, I’ve been “tasked” on quite a few occassions with developing custom interfaces to System Center products.  Latching into it’s internal organs to accomplish various capabilities for various customer needs.   This may be a bit dry, but so am I right now.  I need to dry out from holiday parties, so you might need a drink to put a “fun lens” on this article.

The usual connection points being:

  • SQL Server
  • WMI / WBEM
  • COM or .NET
  • File / Registry direct (seldom)
  • RPC / DCOM direct (seldom)

These are the conduits through which data flows in and out of the various components and services that underpin the System Center suite of products.  For the record, most of my work has been focused on Configuration Manager, but there’s been a few instances dealing with Service Manager, SCOM and VMM.

Lately however, the demand for this has been very low.  Customers are prone to buying an off-the-shelf product rather than have someone build a custom-fit solution.  The reasons vary, but it really comes down to risk aversion (risk, as in risk of one developer getting hit by one bus).  So I see the future of this as declining for individual developers, at least beyond the role of small, focused utilities.  Enterprise systems solutions will (a) be sought from recognized vendors and (b) exist in the cloud.

I told you I would digress.  Don’t say I didn’t warn you.

App Models

Anyhow, if you are sitting in a position of building a custom-fit solution to expose or interface SC features with other resources, you have a few basic options:

  • Dedicated Client Application
  • Server Application
  • Web Application
  • Hybrid

The Dedicated Client Application is most often some form of installed component set, such as a Visual Studio project, but may also be a runtime platform, such as HyperText Application (HTA) or COM-based forms via scripting.  There’s also the MMC add-in option.

The Server Application is often either a service provider endpoint, or a shared repository.  The standard Configuration Manager console relies on the SMS Provider interface with a site server to complete the feature set.  In biological terms, this is analogous to a virus and a host.  Not to belittle the technology as being a (computer) “virus”.

A Web Application is simply a service provider endpoint which is hosted for remote access via HTTP/HTTPS or as a web service endpoint (SOAP/XML/WebDAV/etc.).  The Office365, Azure and Intune portals are examples of web application interfaces to backend services.

Hybrid solutions are combinations of two or more of the above options.  The Configuration Manager console is an example of a Server Application (the SMS Provider, SQL backend, etc.) and a Dedicated Client Application ( the console itself).  Either of them alone are not practically useful, but when combined they enable useful capabilities.

Intune, Azure and Office365 are also hybrid applications.  In fact, nearly every application that doesn’t provide all of it’s resources and services on one host could be considered a hybrid in some capacity.

Requirements Analysis

Here’s where this stuff matters.  Any software developer will understand the dilemma of weighing the good and bad for each model when it comes to building a new application.  Client/Server? Client? Server? Web? Mobile?  On-premises or Cloud?  Compiled or Interpreted?  The direction and constraints are often laid out for you already:

  • Platform requirements
  • Connectivity
  • Operating environment

All of these get dumped into a requirements blender and pureed.   Let’s take Configuration Manager 1511 for example.  If given the following use-case constraints, we can narrow down the solution alternatives much more quickly.

  • Needs to tie directly into a third-party hardware inventory system
  • Needs to restrict access to particular AD security groups
  • Needs to be accessible from any connected device, regardless of operating system

The first one means it could exist independent of either system back-end (a third server or host).  Maybe it’s own database repository.  Maybe it’s own scheduler.

The second one means it needs to be Active Directory aware or integrated.  Possibly AD-LDS or ADFS (or Azure AD)

The last one means a direct OS platform “fit” is not going to be practical.  Probably a web application.  Then it needs to be analyzed from a browser aspect (capabilities, supported standards, etc.)


As with anything in life, there are trade-offs to consider for each model.

  • A dedicated client application requires installation on each target user or device.  It means more activity to update or upgrade each installation in the future.  It also means more potential points of failure and troubleshooting effort.  However, it mitigates security concerns on remote services as compared with a server application model.
  • A server application consolidates security and management aspects, and avoids endpoint installation concerns.  However, it places more demand on the host, and adds exposure and potential risk relating to ports, services, security, processes, etc.  It also becomes a potential single point of failure.
  • A web application consolidates management control aspects in a single location, and mitigates the need to deploy installations to each user/device.  However, it incurs the same risks as a server application, but adds more complexity due to added service layers and increased overhead.  There is also the added complexity of endpoint browser compatibility.
  • A hybrid solution incurs all of the benefits and risks of each model as well as adding a layer of complexity in itself.
  • A mobile app is somewhat of a unique hybrid between a dedicated client application and a web application.  However, it is also a hybrid in the sense that it usually incurs a server or web host component for shared resource exposure and management.

What does all this really mean?  It means the following:

  • You have options.  Options are good.
  • You can build almost anything on top of a Microsoft platform without spending any additional money, or you can spend a lot.
  • There are always risks to consider.
  • I need food and something to drink.

Happy Holidays!


Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s