Udostępnij za pośrednictwem

Getting Started

  • Artykuł

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.

Comments

  • Anonymous
    October 16, 2006
    Hi Jakub, I really like your blog. Neat and clear. However, I'm trying to "get started" but ran into some problems. I have installed the UI of SCOM RC1 on my XP machine with all it's dependencies. The UI is running fine. The problem is that within the VS2005 environment I cannot to reference the mentioned dll's as it does not appear in the .Net (add reference) selection list, although it shows in the global assembly cache when I browse to c:/windows/assembly. I would also like to explore all the possibilities of extending the current UI. Can you please give some guidance on getting started in this regard as the sdk help files are in complete silence. Kind regards, Andre

  • Anonymous
    October 16, 2006
    Correction, the installed UI is that of "SCOM RC0" (version 6.0.4295.0)

  • Anonymous
    October 17, 2006
    The assemblies won't appear in the Add Reference dialog unless you add some registry keys which I am not quite sure what they are. The easiest way to do it, as mentioned in the post, is to copy out those assemblies from the GAC into another directory and reference it from there. You might also want to check if the assemblies are already in the SCOM directory (I just don't remember if they were there for RC0). With regards to extending the UI, do you mean using the SDK, or more specifically around UI extensibility itself (views, etc)?

  • Anonymous
    October 17, 2006
    Regarding my request for extensibility of the UI. At this stage it is a matter of finding out what is possible through the SDK rather then planning to extend it according to a specific scenario. To give you an idea what we have in the back of our minds, just the following: We are mainly a support company for the SME market with our own monitoring service using our in-house developed system called SATAware™. This system uses MOM2005 and optionally another event collection system as data sources and consolidates monitoring across domains (i.e. our clients). We are currently using a SATAware™ Client to provide our operators with a specific UI to fit our needs, i.e. an abstract view of network provider/company/site/device state (together with geographical information). With SCOM we obviously consider service information to be included in such a view. Please see http://www.sat.co.za/_images/scHeartBeats.gif We are also currently using an advanced change control functionality within the SATAware™ system as well as an advanced notification functionality based on operator response rather than a mere e-mail on automated system responses. We would therefore like to combine all of our functionality with the great features that SCOM provides within one UI. There are obviously a lot of how’s and why’s, but I think you get the idea what our needs are regarding the extensibility of the SCOM UI. It would be great if you can provide me with any kind of documentation or guidelines (the content formality is really not an issue – I’m desperate) on how to start building or looking for extension possibilities of the SCOM UI through the SDK. If it suits you better we can rather correspond through microsoft.beta.opsmgr.ui newsgroup as I am participating in the TAP.

  • Anonymous
    October 18, 2006
    The comment has been removed

  • Anonymous
    October 19, 2006
    Thanks for your prompt feedback. On your last question: We would preferably customize your UI to our need. It will make no sense simulating what you have already done just to add a couple of our own features. Is it possible to provide at least some preliminary guidance on adding custom “URL Views” / “ASP.Net page views” (see the spaces in the chm), as well on the mentioned extensibility points: toolbars and action panes?

  • Anonymous
    October 19, 2006
    You can create a web page view and have a URL which points to to your own web site.   To create this kind of view in the UI go to the Monitoring space, select “New View”->”Web Page View” and enter the URL of the webpage that you want displayed in that view.   You can also author a Management Pack which contains a web page view.   With regards to the rest of the extensibility, there is zero documentation currently on the feature, and there will most likely not be any public support for UI extensiblity outside of authoring existing view types. (To correct my earlier comment). Basically, there is a framework that is extensible, we just don't have to time to provide an adequate amount of testing to make it public. If more full-fledged UI extensibility is something you really want, I encourage you to talk directly about this with your TAP contact and additionally post any feedback here: http://www.microsoft.com/mom/feedback.

  • Anonymous
    October 19, 2006
    Hi Jakub, Thanks for a great blog.  It is the single best source of information on SCOM that I have found.  It is so useful to know what is going on with the SCOM development work. I too am in the same position as andretttt.  We are working in a different industry (virtualization management) but we would like to do similar integration of our solutions into MOM/SCOM. I have been working during the last couple of years with open source software and, more specifically, the plug-in architecture of the Eclipse RCP so I have been spoilt with such openness and with abundant code to examine.  It may be that this experience has given me unreasonable expectations, in which case I apologise. It was frustrating to see that SCOM supports custom providers, custom diagrams, custom whatever, only to find that 'custom' does not mean we can write our own but only that we can set a few properties on a very limited set of providers or diagrams. I had sent a request to mma at microsoft for some information on how we can supply a custom diagram.  I was told that diagrams will be a lot easier to implement in SCOM.  Great.  Having no diagrams in our MOM 2005 solution is not a problem.  Then I found there is no documentation (as previously noted in this thread, the documentation is blank on all issues of interest).  Fine, I can wait for RC0 for the documentation.  Now, however, you have stated something that is extremely concerning.  In response to a request for information on creating custom views, the only solution you can come up with is "You can create a web page view and have a URL which points to to your own web site".  We are not looking for a web browser.  We expected we could create custom diagrams, similar to those produced by Microsoft but with different classes of objects and different classes of connections shown between the objects.  When I started looking at MOM and SCOM, I assumed we could integrate our management software into MOM or SCOM in the same way that the teams within Microsoft are able to with their management packs. There are quite a few other areas where I am looking for some documentation that enables us to produce our management pack.  For example, I notice the administrator console based on MMC  has been replaced.  This means we no longer have the option of writing a MMC snap-in.  I  am inquisative as to how this should be done in SCOM. I know writing documentation takes time, but just the documentation generated from the code comments would be enormously helpful.  Sample code for an existing diagram would be fantastic.

  • Nigel Westbury

  • Anonymous
    October 19, 2006
    To clarify on my earlier post, you will be able to use the URL view as mentioned, but you can also author your own views, as long as they are of one of the types we ship (for instance Diagram View, State View, etc). Let me see what I can come up with in terms of view authoring and report back soon.

  • Anonymous
    October 19, 2006
    Regarding the view types, most are defined in the Microsoft.SystemCenter.Library management pack. If you export this management pack, you will see the view type definitions and the schemas that views need to conform to when being defined. The diagram view in particular does not have a sample we ship with, but if you create one from the UI, it will go to the default management pack, which you can then export and see what was created. I understand this is not ideal, but at least it's something to get you started at this point. Do you think the ability to "instantiate" our view types will not suffice for you needs? In other words, from the different views you see in the UI, do you not see your extensibility requirements conforming to one of those? I will also forward your comment to the appropriate people on the team to better voice your concerns. Thanks for the feedback though, it is much appreciated.

  • Anonymous
    December 04, 2006
    Hi Jakub, Thanks for providing imho best SCOM-SDK knowledge resource. Unfortunately I've a problem setting up the SDK. I installed a SCOM 2007 RC1 on my test machine and searched for the two above-mentioned .DLLs, but I could not find them. Then I installed the UI on my dev-workstation and tried to reference the .DLLs in the UI directory but they can't be referenced by VS 2003. Searching the web does also not help. What .DLLs do I need? Where can I find them? I've also some general questions: It's possible to create custom management packs with the SDK, right? In the meanwhile does a SDK documentation exist? Thanks for your effort. Hendrik

  • Anonymous
    December 04, 2006
    Have you looked at my "Getting Started" post? The files you need should only be in the GAC, and not dropped into the product directory. Also, I don't think Visual Studio 2003 supports .Net 2.0? I could be wrong about that though. Regarding your other questions:

  1. Yes, you can build a custom management pack via the SDK.
  2. I believe there is some limited documentation posted on the connect site where you downloaded RC1. Better documentation is in the works.

  • Anonymous
    December 05, 2006
    Sorry, I've overlooked the GAC hint. Now it works. Thanks for your patience.

  • Anonymous
    December 05, 2006
    Great, I am glad you were able to get it to work.

  • Anonymous
    January 27, 2008
    If I write a .NET C# Dll module how do I deploy it in SCOM. Is there a way to import it like we do for MP XML? I want to write a C# module that will help me change some of the values in my monitored computers application.

  • Anonymous
    January 28, 2008
    We don't support writing your own modules for mainly this reason; we don't have a deployment option, you need to do it manually. This is something we are looking at addressing in the future.

  • Anonymous
    January 28, 2008
    Thanks for the update Jakub. We are currently monitoring an application running on a few machines and displaying the monitored values in SCOM view. Going forward we were planning to add a view in SCOM which will allow the user to modify these values and on submit the C# module will kick in and update this value in the application running on all monitored machines. From your reply I understand that there is no way currently whereby a customised page can be added to SCOM which can call a C# dll to do the processing on submit. So you are suggesting we create our own program outside SCOM to achieve the same

  • Anonymous
    January 29, 2008
    Yeah, that is correct.