none
AD-SCCM connector vs. CSV import

    Domanda

  • sicce the AD/SCCM connector are not very flexible I have a couple of question concerning the CSV import

    - are there any disadvantages concerning the SCOM integration (or other integrations) if the computers or user are imported by csv and not by the AD/SCCM connectors?

    - does the SCCM connector always import not only the computers but also all the software/updates which are installed on the computer?

    - are there any attributes which are imported by the default connectors (AD, SCCM Connector) which are not shown in the different forms (user, computer, printer, ...) or do I see all the neccessary attributes on the form?

    - how does the csv connector know if an object already exist (and therefore has only to be updated) or not (and therefore has to be created in the database) => what is used as the primary key during the imports?

    - how is it possible to import relationships via csv connector (e.g. primary owner of a computer)?

    Thanks for your thoughts!

    BR
    gk

    giovedì 14 aprile 2011 20:26

Risposte

  • Importing objects is always based on the class' key property (For example: Principal Name is the key property of the Microsoft.Windows.Computer class). As long as all three connectors (AD, SCOM, SCCM) use the same Principal Name the object will be updated by all three.

    As far as I know, the SCCM connector imports all the software/updates installed on a computer.

    The only AD User property I know of that is not displayed out of the box is "Email". In fact, Email isn't even a field in the AD User class. But, if you extend the AD User class and add Email as a property, the AD connector will populate it. (The AD connector actually populates SMTP objects which represent the email(s) of users)
    See this article for details about the mapping between AD and SM:
    http://technet.microsoft.com/en-us/library/gg232586.aspx

    The CSV connector is quite smart. It updates any objects that already exist (based on the key of the class) or creates new objects that it cannot find (again, based on the key of the class). The primary key used for CSV imports is the primary key of whatever class or classes you're importing.

    Relationships can be imported with CSV connector, it just requires a little understanding about the CSV Import Format. Take a look at the following blog post. There's a document attached that gives all the detail you'll need to do CSV imports including relationships:
    http://blogs.technet.com/b/servicemanager/archive/2009/05/26/using-the-csv-import-feature.aspx

    Hope that helps a little :)


    • Contrassegnato come risposta gk_2009 lunedì 18 aprile 2011 18:39
    venerdì 15 aprile 2011 22:06
  • I'm not sure about "recreating" the AD connector. The built-in AD connector is probably pretty complicated..it brings in relationships that might not be immediately obvious (like SMTP objects for user's email addresses, groups the user's belong to, etc). I personally would not advise replacing it with your own.
    However, you could extend the capabilities of the AD connector by building your own csv import connector workflow so you wouldn't have to do a CSV import manually all the time:
    http://blogs.technet.com/b/servicemanager/archive/2009/12/21/creating-an-ad-connector-using-powershell-and-csv-import.aspx
    That post shows an example of how you can write your own connector (based on a CSV import) to bring in custom information from AD.
    It might seem pretty overwhelming, especially if you're just interested in CSV imports for now..but it's a possibility for you to consider :)
    Incidentally, your CSV import doesn't have to contain every field on a form or in a class for the import to work. You have to have _at least_ the keys for the class..but you can include or exclude any other class field.

    Disdvantages and problems can occur, but if you plan out your connectors carefully, they shouldn't happen. A couple problems that could happen: Multiple connectors "over-writing" each other when updating an object. For instance: Let's say SCOM has a computer X with the Serial number 123. Your CSV Import file has the same computer X but the serial number is 456. So, you could imagine that the SCOM connector and your CSV Import would be changing computer X's serial number over and over if you ran your CSV Import often.

    The other possible problem is the creation of duplicate records. For instance..let's say AD has a user Bob with a Domain of MyCompany. In Service Manager, AD User's have a username and domain field as keys (Both fields must be filled in). If you created a CSV import file that contained Bob, but the Domain field was MyCompany.com, then you would have two User records in Service manager for Bob. One with a domain of MyCompany (from AD), the other with a domain of MyCompany.com (from your CSV import). This sort of problem really comes down to the keys used with a CSV import. Records with matching keys will be updated..keys that do not exist will result in the creation of a brand new record.

    Those are just a couple theorecitcal problems that could crop up, but they can be mitigated with good design. But no worries..the out of the box connectors will work..they shouldn't crash or fail or anything like that if you're importing objects yourself with a CSV import :) 

     

    • Contrassegnato come risposta gk_2009 lunedì 18 aprile 2011 18:39
    lunedì 18 aprile 2011 16:36

Tutte le risposte

  • Importing objects is always based on the class' key property (For example: Principal Name is the key property of the Microsoft.Windows.Computer class). As long as all three connectors (AD, SCOM, SCCM) use the same Principal Name the object will be updated by all three.

    As far as I know, the SCCM connector imports all the software/updates installed on a computer.

    The only AD User property I know of that is not displayed out of the box is "Email". In fact, Email isn't even a field in the AD User class. But, if you extend the AD User class and add Email as a property, the AD connector will populate it. (The AD connector actually populates SMTP objects which represent the email(s) of users)
    See this article for details about the mapping between AD and SM:
    http://technet.microsoft.com/en-us/library/gg232586.aspx

    The CSV connector is quite smart. It updates any objects that already exist (based on the key of the class) or creates new objects that it cannot find (again, based on the key of the class). The primary key used for CSV imports is the primary key of whatever class or classes you're importing.

    Relationships can be imported with CSV connector, it just requires a little understanding about the CSV Import Format. Take a look at the following blog post. There's a document attached that gives all the detail you'll need to do CSV imports including relationships:
    http://blogs.technet.com/b/servicemanager/archive/2009/05/26/using-the-csv-import-feature.aspx

    Hope that helps a little :)


    • Contrassegnato come risposta gk_2009 lunedì 18 aprile 2011 18:39
    venerdì 15 aprile 2011 22:06
  • Hi Aaron,

    thanks for your answers. That helps indeed a lot and clarifies some things. But two more questions:

    - I can recreate the AD connector for persons by simply putting all fields which are for example on the user form into the format file - right?
    - will there be any disadvantages/problems with the other integrations (SCOM/SCCM) if persons and computers are beeing imported via CSV (maybe SCOM connector doesn't work if CIs are not beeing imported by the ootb connectors)?

    BR
    gk

    domenica 17 aprile 2011 19:05
  • I'm not sure about "recreating" the AD connector. The built-in AD connector is probably pretty complicated..it brings in relationships that might not be immediately obvious (like SMTP objects for user's email addresses, groups the user's belong to, etc). I personally would not advise replacing it with your own.
    However, you could extend the capabilities of the AD connector by building your own csv import connector workflow so you wouldn't have to do a CSV import manually all the time:
    http://blogs.technet.com/b/servicemanager/archive/2009/12/21/creating-an-ad-connector-using-powershell-and-csv-import.aspx
    That post shows an example of how you can write your own connector (based on a CSV import) to bring in custom information from AD.
    It might seem pretty overwhelming, especially if you're just interested in CSV imports for now..but it's a possibility for you to consider :)
    Incidentally, your CSV import doesn't have to contain every field on a form or in a class for the import to work. You have to have _at least_ the keys for the class..but you can include or exclude any other class field.

    Disdvantages and problems can occur, but if you plan out your connectors carefully, they shouldn't happen. A couple problems that could happen: Multiple connectors "over-writing" each other when updating an object. For instance: Let's say SCOM has a computer X with the Serial number 123. Your CSV Import file has the same computer X but the serial number is 456. So, you could imagine that the SCOM connector and your CSV Import would be changing computer X's serial number over and over if you ran your CSV Import often.

    The other possible problem is the creation of duplicate records. For instance..let's say AD has a user Bob with a Domain of MyCompany. In Service Manager, AD User's have a username and domain field as keys (Both fields must be filled in). If you created a CSV import file that contained Bob, but the Domain field was MyCompany.com, then you would have two User records in Service manager for Bob. One with a domain of MyCompany (from AD), the other with a domain of MyCompany.com (from your CSV import). This sort of problem really comes down to the keys used with a CSV import. Records with matching keys will be updated..keys that do not exist will result in the creation of a brand new record.

    Those are just a couple theorecitcal problems that could crop up, but they can be mitigated with good design. But no worries..the out of the box connectors will work..they shouldn't crash or fail or anything like that if you're importing objects yourself with a CSV import :) 

     

    • Contrassegnato come risposta gk_2009 lunedì 18 aprile 2011 18:39
    lunedì 18 aprile 2011 16:36
  • No doubt, that the out of the box connector work. The problem is they work too good. Since they lack the possibility of filtering the import they only do import nothing or all. FRom the AD I only need users and no groups. Since the users are not in one OU i would have to create AD connectors for more than 200 OUs. A CSV give  me a lot more flexibilty of just filtering all the users I'm interested in (no admin accounts, no system accounts, no groups, no special accounts, ....). FRom the 43000 AD objects which are imported by the AD connector I only need less than 50%. The rest is overkill and slows down the whole system.

    The SCOM connector is the same: Besides all the computers it also imports all the software/updates which are installed on those machines. 20000 computers of interest and hundreds of thousands of relations (filesystems, patches, software, ...) That's insane. The initial run of the SCOM connector took days. And I was pretty happy when it finally finished. 

    The "nothing or all" principle of the ootb connectors led me to the idea of using CSV imports instead

    I now MS is working on a more flexible connector for the 2012 version but that is something for the future...

    Aaron, I'll mark this thread as answered. Thank you very much for your time and thoughts. Any further comments are welcome!

    lunedì 18 aprile 2011 18:39