Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.
Endpoint Management Community Blog

Script Import of Computer Details for DS 6.9

Created: 28 Mar 2011 • Updated: 27 Apr 2011
MurrayW's picture
+1 1 Vote
Login to vote

In the first of a few "how we do things" blog entries, I thought I'd start at the beginning - importing the new computers. Now I understand that Altiris (and now Symantec) have an "Import" process that uses a CSV file, INP files, a few others formats, and you can also run the computers through an "Initial Deployment" process, but we have particular usage cases. These issues are;

  1. We don't own all the computers we deploy. They are ordered in for clients and all have names already assigned. in this case we can't rely on any automated method for deployment as we don't want the wrong computer configured for a client. As such, we scan all computers (usually hundreds at a time) on arrival. We simple want to import the computer names, which are used for later scripting in the deployment process, and use the barcoded Serial Number and or MAC Address to identify them during deployment. We REALLY can't select computers from a 200+ line list of names within automation.
     
  2. We have visitors bringing in their own computers, students, and staff that like to tinker. As such, we can't offer any method that will allow users to accidentally image their computer. So we need to identify each computer correctly before an image is started. As some of us may have found out in the past, if you set up an new DS account with an image task, and someone (usually messing around) manages to boot their computer into automation... well... bad things happen.
     
  3. We don't want to rely on any inventory process initially to register computer details. While it's not the intended use, our Deployment Server Console becomes our Deployment Asset Manager during deployment times, and as such we require Computer Names, Serial Numbers and MAC Addresses to be imported and registered before we begin the deployment

The easiest way of achieving the above process is to create the appropriate computer names in advance, combine this list with at least a serial number (such that the computer can be found and attached to when queuing up a deployment task), and use the most robust of supported input methods - XML.
 

To Start With...

The process is quite easy actually. I created a single new computer account using the in-built wizard. I only added a Computer Name, Serial Number and MAC Address. I created the account in a "Test" folder just to be sure. The process was then all about selecting that single computer, clicking "File" > "Import/Export" > "Export Computers...", and then saved out the XML file. The next step was to look through the XML and strip out anything and everything that I possibly could while still allowing the computer to import correctly. What I ended up with was a header and footer XML structure, and 22-lines of nicely formatted tags to populate data into. The next process was to automate the creation of the XML file.
 

The Process...

The process took a little while to sort out. We tried all manner of things including Crystal Reports to generate the contents from a database, and quite a few others. What we found though, was that we mostly dealt with Excel documents from the suppliers anyway, and it's easy enough to deal with XML as text files. The solution was a CSV and a VBScript. Not exactly the most glamorous solution, but one we've used for a few years with great success. Now, I know what you're thinking, "If you're using a CSV, then why don't you use the CSV import method provided by Altiris?"... that's easy to answer... we've been entirely unsuccessful in doing so. Back in the DS 6.1 days, we could only import 13 computers at a time due to an issue with Excel and/or the import process in that DS version. In DS 6.8 we had an issue where the CSV format appeared to have changed (or something had) and NONE of the rows imported citing an issue with the "MAC_ADDR_1" column (or some such error). And so, we've gone our own way.

So to make this process work, we simply collate the vendor delivery spreadsheet of names with our scanned spreadsheet containing. We have various formula then generating a computer name for us as another column. In the end, I copy the "Computer Name", "Serial number", "LAN MAC", and "Import Group Name" columns into a new sheet and save this out as a comma-separated value file (CSV). I then simply double-click on a VBS that I wrote (which is stored in the same location as the CSV) and it generates me an XML file that is ready for import.

For your convenience, and to avoid the blog codes from breaking any scripts, I have attached all the parts you will need. What we have is as follows;

  • "DSCompGen.vbs_.txt" - The VBScript that does the work. Rename the extension of this file, review it, validate it, and then store it in a folder that you can use for testing. Please note: While this script works well in our environment, I have no control over it once posted... so use at your own risk and make sure you understand what it does before putting it into production.
     
  • "Template_Header.xml" - This is the top-most, non-repeated, part of the XML. While I have included this as a separate file, it is actually embedded within the VBScript and will not be required in order to make the script function.
     
  • "Template_Footer .xml" - As above, this is the footer part of the XML required for import. This is also included in the VBScript and is not required to make the script function.
     
  • "Computer_Template.xml" - This IS required to make the script work, and needs to be in a sub-folder called "Resources" within the folder where the script will live. I am not sure why I included the header and footer int eh script and keep this section separate, but it's how I wrote it at the time. This is the main (required) block of XML tags required for each and every computer we will import. It simply uses some unlikely tokens in the file and substitutes these with real values as it's inserted into the final XML document. Nothing amazing here.
     
  • "computers.csv_.txt" - The data-source for the script. Sure I could have made this an actual Excel document, or some other data source, but CSVs were easy and I wrote this script during a push towards a deadline where the DS CSV Import failed. This contains the columns that are simply read line-by-line and substituted into the template above, and then output to XML suitable for the Deployment Server Console to read.

And that's it. Populate the CSV file, copy that and the VBS to the same location, add a "Resources" sub-folder that contains the template (or simply change the VBScript to use a different path/folder), double-click, and watch a file called "import.xml" appear and get populated. You then click "File" > "Import/Export" > "Import Computers..." and select this file. It will likely complain (once per row)) that the IP Address is the same, but the enter key on the keyboard fixes this. It will create the appropriate groups from the import file, and import the DS accounts that are already tied to the computer hardware via MAC/Serial. (can leave one or both blank... doesn't really matter).
 

Conclusion:

Some of you may think this unnecessary, others reinventing the wheel (as DS already supports CSV import), but we can't live without this. The code isn't pretty, and can certainly be optimised, but it hasn't let us down and is suffering from the "if it ain't broke" development hold. It get's used several times a year to handle the initial import and creation of all our computers. I just hope that it saves someone the grief of trying to import computers that match our usage cases.
 

Final Words

Thanks for reading my blog. Please note that, although I have written these scripts for use in our production environment, and they work fine here, this sub-set of script provided in the blog have not been completely tested and may not work correctly in your environment. As with everything, please try to understand what the code is doing and test in a non-production environment first. Neither my employer or I will accept any responsibility for the (mis)use of these scripts and do not claim that they are a final production-ready solution. If the scripts or ideas presented here do help you, then please drop me a comment, email, and.or PM to let me know.