August, 2006

  • Jakub@Work

    Getting Started

    • 18 Comments

    The easiest way to get going is to install the SCOM UI on the machine that you want to develop on. This will ensure all the necessary components are installed and drop the assemblies you need in order to write against the SDK. There is currently a work item being tracked to have a special installer for just the SDK and any necessary components in order to easily facilitate developing on a non-SCOM box. Hopefully we can get this in for RTM, if not, I'll make sure to post exact instructions when that time comes.

    Programmatically, the only assemblies of interest are:

    Microsoft.EnterpriseManagement.OperationsManager.dll (The main SDK assembly)

    Microsoft.EnterpriseManagement.OperationsManager.Common.dll (A common assembly that the SDK service and client share, containing mostly exceptions)

    Although in Beta 2 there was also a dependency on EventCommon.dll and Microsoft.Mom.Common.dll, both of these dependencies have been removed for the upcoming release candidate and will not be present at RTM.

    If you want to develop and run on a machine that does not have the UI installed, you will need to:

    1. Copy over the assemblies mentioned above (the two main assemblies in bold will have to be copied from the GAC) to a directory on the machine you want to develop on.
    2. Copy over Bid2ETW.dll from the SCOM install directory to the same machine.
    3. Install the correct version of Microsoft .Net Framework 3.0.
    4. In the registry at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\BidInterface\Loader add a new string value: “<Directory where you code will be running>\*”=”<Path to Bid file from #2>\Bid2ETW.dll”

    This should be everything you need to do to setup your dev machine. Now just link against the assemblies and you're ready to get started.

    The first thing any application needs to do in order to work with SCOM is create a new ManagementGroup object.  The sample code below creates a ManagementGroup connected to the local machine (Note: In order for this code to work, it needs to be run on the Primary Management Server.)

    using System;

    using Microsoft.EnterpriseManagement;

     

    namespace Jakub_WorkSamples

    {

        class Program

        {

            static void Main(string[] args)

            {

                ManagementGroup localManagementGroup = new ManagementGroup("localhost");

            }

        }

    }

     

    With this object, you can begin to explore the rest of the API and accomplish, hopefully, any tasks you need to. In future posts, I will talk more about connecting options and the ManagementGroupSettings class, but for now, this should get you started.

    EDIT - In recent builds (I believe RC1 included) you do not need to do step 2 and 4 above, unless you want SCOM tracing to work.

  • Jakub@Work

    Introductions

    • 6 Comments

    First, a little bit about myself. My name is Jakub Oleksy and I am a developer for the System Center Operations Manager (SCOM) team at Microsoft. I started working for Microsoft (and this particular team) in the middle of 2003 after graduating from UCLA with a Master's degree in Computer Science.

    The first feature I worked on was the MOM to MOM Product Connector for MOM 2000 SP1. I then worked on the MOM Connector Framework and the MOM to MOM Product Connector for MOM 2005. During this time I also began work on what became officially known as the Managed Class Library in MOM 2005 (I usually refer to this as the SDK).

    In 2005, the SDK was built after the product was almost complete, so it mirrored functionality that the UI did, but it did not provide any service to the UI or other components. These components were written directly against a data access layer that talked to the database. Also, in MOM 2005 there was no built in way to remote the SDK.

    For SCOM 2007, we set off with a goal that the SDK would provide 100% of the functionality that the UI exposes and in fact have the UI built entirely on top of our public SDK. SCOM being a platform more than anything else, we felt it was more important than ever to provide as much accessibility and extensibility opportunities to the product as possible, and the SDK is one of the main focuses of that effort. At this point in the product cycle, I feel that we have more than succeeded in our goals. Today the UI, the Command Shell and various modules in the product all use the public SDK as their sole provider for interacting with SCOM. In fact, the SDK provides more functionality that is even exposed in these components. Further, the SDK is fully remotable using WCF (Windows Communication Foundation).

    My primary areas of responsibility for SCOM 2007 are the SDK, MCF (or OMCF now) and parts of tiering (the replacement for the MOM to MOM Product Connector). I was also primarily responsible for the redesign of MCF and making it fit with the new SCOM 2007 product design as we move to a service-oriented architecture.

    My goal with this blog is to provide as much information as I can about topics that interest you about SCOM in general and particularly the SDK, MCF and tiering. Please feel free to contact me with any requests or questions you might have, I will be more than happy to address them either directly, or in future posts. Thanks!

Page 1 of 1 (2 items)