Ghost Solution Suite

Message Edited by David.Poprik on 06-20-200710:19 AM

I've been able to use the ODBC connection and PHP with great success

Just to address the complaint in the first post about the lack of changes to inventory in recent versions, that's not been for a lack of desire to make improvements to inventory; it's just that product management have prioritized our development budget elsewhere recently. If this is an important thing to you, this is a good place to ask for it; real customers asking for things is something we can show product management to help them decide what features our budget gets devoted to developing.

As for the database (which is Sybase SQLAnywhere, by the way, not something proprietary) we've never had any objection to customers working directly with it and there's nothing really "secret" about it, it's just that we've not had the resources to devote to creating lots of documentation and examples of things you can do - and of course, we'd like to retain the freedom to change some of how things work internally if we need to as part of new versions.

Anyway, here's an example of one way to access the database that I just whipped up; it uses the Windows Script Host and the ADODB scripting objects to just run a trivial query to print machine names to a console window. The only tricky part is the first bit, which asks the Configuration Server service for the database credentials to use to connect. You can get the script and a batch file to launch it properly from here and run it using the included .bat file

You can also look up the database connection name and password in the console and use those to build your own ODBC or ADO connection to the database in other tools. There's also a script I wrote that I think is somewhere on the product CD that shows how to re-enable the original database DBA password if you want to re-enable the Sybase DBA account with a password of your choice if you want to add your own user accounts using SQL.

Trying to work against a copy of the database itself is probably more complex than working against the thing itself, at least with how things are right now - on the console machine our installer does all the complex stuff of setting up the database server and has an ODBC data source configured that you can probably just point Access at.

I don't have Access currently installed on my developer machine to walk through the process, but I just tried this with OpenOffice 2.1 Base:

1. First, open the Ghost console and under the "Tools" menu, choose "Database Password...". This pops up a little dialog that shows you the randomly generated user name and password that we generated for the console to use when we installed it. Take a copy of these, since you'll need to use them to connect.

2. Fire up OpenOffice Base, and in the connection wizard pick "Connect to an existing database".

3. In the drop-down, pick the database drivers to use; ODBC is simpler to set up, ADO just adds another layer of wrapping around ODBC (one of the benefits of that extra wrapping is that you can save the password, though). We'll use ODBC since it's simple

4. The next step in the wizard is to choose the ODBC data source. Hit browse, and you should see "Symantec Ghost" listed as a available database. You can look at the setup of this in your Windows control panel, by the way, under "Administrative Tools", "Data Sources (ODBC)", and on the "System DSN" tab (except on 64-bit systems, which don't display 32-bit data sources).

5. Pick the "Symantec Ghost" ODBC data source, and move on

6. The next step asks for a user name. Here you can paste in the user name from the first step, which should be something like GhostSolution3h7 (it's GhostSolution plus 3 random letters or numbers). Also, tick the "Password required" tickbox so you're prompted to enter a password.

7. At this point you can save the connection, and when you're prompted for the database password you can enter the password from step 1.

8. You're done! The only thing about an ODBC connection in OpenOffice is that it displays all the tables in groups based on their "Owner" in Sybase, and shows you a bunch of internal stuff in the database engine under the "dbo" heading. All the actual tables we use are listed under "NORTON".

Doing the process using ADO in OpenOffice is similar, but you choose the ODBC connection and username and password from within some ADO dialogs. The basic idea is the same, though; pick the "Symantec Ghost" ODBC connection, and put in the username and password you got from the console. Using ADO inside OpenOffice doesn't show you all the "dbo" and "NORTON" stuff.

Access changes around how it works with "foreign" data every release, making it hard to describe the procedures to use. In Access 2003 it's done with a process like "File" "New..", picking "Blank data access page", opening "+Connect to new Data Source.odc", choosing "Other/Advanced" rather than SQL Server, and then you proceed to the exact same ADO setup as in OpenOffice, where you can use "Microsoft OLE DB Provider for ODBC Data Sources" to get access to ODBC data.

I can't say why Access would be shutting down on you; our services do write to the database, but since it's a proper database and we put everything in transactions as we should, Access ought not to have trouble browsing things.

As to the schema, as I said earlier writing this up (along with opening up the whole thing to scripting) is something we've wanted to do but never really had the budget for. In the specific case of the WMI data, the current schema isn't really something we want to keep - the techniques we use for representing the WMI data at present are tied to limitations in the edition of Sybase we're using. Rather than dynamically creating tables in the database to match WMI data that we're collecting, all the WMI data is mapped into a set of three fixed tables and we do the work in our code of untangling it all.

[ Note that how WMI data is represented is one of those parts of the database that we'd like to reserve the right to change in future, mainly for performance reasons. Really, I'd like to see WMI classes become actual database tables. However, before we can possibly do that we'd first have to change to embedding the full version of SQLAnywhere rather than the run-time edition. ]

For working out what refers to what in the database, there are some well-followed conventions; most tables have a primary key of "ID", and columns named "SomethingID" pretty much always represent a foreign-key relationship to the "Something" table's "ID" column.

So, the bottom-level table in the WMI data store is WMIData: the main columns in that table WMIClassID, WMIPropertyID, and MachineID all link to the WMIClass, WMIProperty, and Machine tables. The WMIData.Instance column groups is a these property bags together into rows.

The WMIProperty table conceptually sits above that, representing the property names of elements of a WMI Class, and WMIClass is the table above that which describes the name of the WMI class and any namespace-related mumbo-jumbo.