Hallo,

ich weiß nicht inwieweit sich Chris erinnert, aber für die Version 2.7.5 hatte ich eine SQL-Server 2000-Version fertig. Diese ist nur in einigen Scripten anders. Die Datenbank lässt sich über die MSDE-Variante auch lizenzkostenfrei nutzen.

Stellt sich die Frage, ob Interesse an einer Aktualisierung besteht. dann wäre da auch die Frage ob es Sinn macht dauerhaft mit zwei Datenbanken zu arbeiten oder zumindest die Scripte komplett datenbankunabhängig zu gestalten.

Viele Grüße
Adben

SQL-Server Anbindung finde ich durchaus sinnvoll.

Ich würde die Datenbankanbindung offen gestalten. So könnte ich mir eine Datenbankwahl per Konfig denken.
Zur Auswahl sollten auf jeden Fall MS SQL und Access stehen. Vieleicht lässt sich das ja irgendwie realisieren.

Ich beschäftige mich momentan mit dem Inventarisierungsscript. Das schreibt die Daten ja momentan in Textfiles - ist also Datenbank unabhängig.

Da ich das Script komplett überarbeite (die Version aus V2.8.1 enthielt ziemlich viel "Code-Müll") kann das aber etwas dauern.

Chris - was meinst Du?

SQL? Ich kann mich euch beiden nur anschliessen! Supper!

@Adben
kannst Du gerne reinfriemeln. 2.8.2 ist die aktuelle Version.
Ist aber kein muss!

Meinst Du die Version?
http://www.microsoft.com/sql/prodinfo/previousversions/msde/download.mspx

plus SP 4?


@Potsdam
Die vielen zeilen Code, die nicht benutzt werden (ein paar Funktionen, die nicht aufgerufen werden) habe ich irgendwo in Netz wieder gefunden und da kommen sie in irgendwelchen scripte vor, die die Daten als XML ausgeben. Warum die da rein gekommen sind, weiss ich nicht. Weg damit...

Oder meinst Du das garnicht?

Ich meine:
function get_sku_xp(value), function get_sku_2003(value), get_release_type(value)...


Ich werde mich (bald) um die Remote-Sache kümmern.
Ich will nicht nur ein Passwort pro Rechner speichern, sondern auch den Username dazu.
Hier sind nicht alle Rechner in der selben Domäne, Viele haben ihren Administrator-Account umbenannt, Laptops sind gerne mal in einer Arbeitsgruppe usw...

So kommen wir uns nicht in die Quere...

Chris

@Chris

genau die mein ich - sowie doppelte Funktionen mit gleichem Inhalt.
Sowas braut sich zusammen, wenn zuviele Köche ohne Absprachen an einem Brei brauen

Ich hab mir mein Script-Grundgerüst genommen, und übernehm jetzt so nach und nach die benötigten Funktionen aus dem alten Script. Dabei werden alle Funktionen gleich überarbeitet und remotetauglich gemacht. So fällt der ganze Code Müll automatisch raus.

Ergebnis: hoffentlich ein Script, das universell einsetzbar ist:
- Scannen von AD
- Scannen einzelner Rechner
- automatisch gesteuert per ini-file oder
- Steuerung per Parameterübergabe

das Rechtfertigt dann denke ich einen Versionssprung auf 3 (zumindest fürs Script).

wenn das fertig ist - sehen wir weiter.

Frage: für was wird Username/PW eigentlich alles verwendet?
Ich habe Bedenken, diese Daten in der Datenbank zu verewigen. Datenschutz!

Pah! Sag' du nochmal Du wärst kein 'crack', was coden angeht )

Es soll nur der Admin-Account gewählt werden können. Mehr nicht.
Keine Userpassworte oder so. 'Nur' das Domain-Admin-Passwort.

Bis jetzt ist es ja so, dass der User ADMINISTRATOR fest gecodet ist und man in der DB das Passwort dazu abspeichert. Verschlüsselt, aber es steht in der DB. Das gefällt mir eigendlich auch überhaupt nicht. Ich dachte, es eigendlich eine gute Idee, dass man den Adminaccount wählen kann und das Passwort selber eingeben muss um z.B. remoteDesktop zu starten.

Vielleicht hast Du eine bessere Idee. Was ich erreichen möchte ist folgendes:

Ich sitzte an meinem Rechner und schaue mir gerade Detailansicht von Rechner ABC001 an.
Rechts oben gibt es den Knof 'remoteprogr. starten'. Wenn ich da drauf klicke, will ich z.B. eine Remote-Desktop-Verbindung von meinem Rechnr zu dem Rechner ABC001 haben.
Lokal starte ich das ja so:

%SystemRoot%system32mstsc.exe /v:ABC001

Jetzt ist es so, dass der Server (wo inventory läuft) meinem Rechner per psexec , Adminaccount und AdminPasswort den Befehl unterschiebt und der Befehl ...system32mstsc auf meinem Rechner gestartet wird.
Dazu der AdminAccount und das Passwort, denn sonst könnte der Server das ja nicht unterschieben. Aber das muss doch anders (sicher) gehen, oder?

Das soll jetzt nur ein Beispiel sein, denn es könnten auch andere Tools gestartet werden.
Aber ich nutzte die sache bis jetzt nicht, denn mir ist das viel zu unsicher. Ich hätte es aber gerne


Gruß,
Chris

was hältst du davon, in die Website eine kleine Userverwaltung einzubauen. So kann gewährleistet werden, das z.B.
- die Buchhaltung nur die Inventardaten einsehen kann
- Eine Aushilfe Daten pflegen kann (Inventur, Standorte, Umsetzungen)
- Der Admin alles kann. Da der Admin sich dann mit seinen Domain-Userdaten anmeldet, können diese gleich dazu genutzt werden, um diverse Tools remote zu starten.

Nun frag mich aber nicht wie das geht... ASP hab ich noch nie gemacht. Mein Steckenpferd ist eher PHP. In PHP wollte ich dies auch schon umsetzen - bevor ich Net-Inventory fand. Wäre dann wohl eine Komponente für Joomla geworden, mit Userauthentifizierung per LDAP gegen das AD.

Ach nochwas: Gab es nicht irgend so eine Erweiterung für den IIS, mit der man Remotedesktopverbindungen direkt in die Website einbinden kann?? Bilde mir ein, bei der Installation von dem Teil kann man sowas auswählen.

Doch zurück zum Thema dieses Threats:

Was jetzt kommt bedeudet wieder komplettes Umschreiben der ganzen Geschichte - stelle es einfach mal so in den Raum:

Ist ASP prinzipiell in HTML eingebettes VBScript?
wenn ja, könnten ja bestimmte Codeparts gemeinsam genutzt werden. Die würden dann in einem Includefile liegen, das sowohl von den ASP-Seiten, als auch von Erfassungsscript genutzt wird.
Ich denke da an den Aufbau einer Klasse "Computer" mit den notwendigen Eigenschaften und Funktionen um die Daten:
- zu speichern
- zu ermitteln
- anzuzeigen
- ...

die Funktion computer.store könnte dann gleich so ausgelegt sein, das sie je nach Config/Aufruf in textfiles, csv, Datenbank abspeichert.

Ein scannen eines Rechners im code könnte dann so aussehen:

Dim o_computer
set o_computer = New Computer
o_computer.Rechnername = str_computername
o_computer.ScanInventory
o_computer.Store()
set o_computer = Nothing

Vorteile:
gemeinsame Code_base_ für Erfassung und Auswertung
keine doppelten Funktionen und doppelte Codepflege

Machbarkeit: keine Ahnung

Ok dann werde ich mich in den nächsten Tagen an die Umstellung machen. Was die universelle Verwendbarkeit anbelangt, müssen wir dann über Includes eine Zwischenschicht einziehen. SQL-Server und Access sind bei einigen Feldern nicht deckungsgleich.
Sofern wir eine Trennung zwischen Datenbank-spezifischem Code und Inventory fertig haben, liesse sich auch bei Bedarf MySQL und Oracle anbinden.

@ChrisBox
Genau die Version + SP4 meinte ich. Für SQL2005 gibt auch eine Variante, diese hat sich bei ersten Tests allerdings nicht so stabil gezeigt. Für einen Echtbetrieb würde daher momentan noch bei SQL2000 bleiben.

Was das AD anbelangt hätte ich zwei mögliche Suchstringvarianten als ADO-Recordset zur Hand:

Variante 1
Set conn = Server.Create_object_("ADODB.Connection")
conn.Provider = "ADSDSO_object_"
conn.Open "ADs Provider"
Set objCMD = Server.Create_object_("ADODB.Command")
Set objCMD.ActiveConnection = conn
objCMD.CommandText = "select name, sAMAccountName " & "from 'LDAP://DC=DOMÄNE,DC=DE'" & "WHERE _object_Category='Person'" & "AND _object_Class='user'" & " AND department'' " & "ORDER BY sn"
Set rs = objCMD.Execute

Variante 2
Set conn = Server.Create_object_("ADODB.Connection")
conn.Provider = "ADSDSO_object_"
conn.Open "ADs Provider"

ldapStr = ";(&(&(&(|(&(_object_Category=person)(_object_Sid=*)(!samAccountType:1.2.840.113556.1.4.804:=3)) (&(_object_Category=person)(!_object_Sid=*))(&(_object_Category=group) (groupType:1.2.840.113556.1.4.804:=14))))(_object_Category=user)(department=*)(givenName=" & Request("Vorname"«») & "*) (sn=" & Request("Nachname"«») & "*)));adspath;subtree"

Set rs = conn.Execute(ldapStr)

Für die Buchhaltung sehe ich ein Problem bei wechselnden Anwendern. Zumindest bei uns im Netz gibt es einige Geräte, welche mit unterschiedlichsten Namen inventarisiert werden (z.B. Terminalserver). Dies liesse sich über einen Schlüssel erledigen, mit dem man einzelne Geräte von der Übersicht ausnehmen kann.

Ich sehe bei der Buchhaltung eigentlich kein Problem:
Die Buchhaltung interessiert doch eigentlich nur:
- Inventarnummer
- Standort
- Anschaffungsdatum
- Abschreibung (die erfassen wir hier nicht)
- Nachaktivierungen (z.B. neue Festplatte, mehr Speicher)
Wer an dem PC/Server sitzt ist der BH in der Regel egal.

Frage: wie Organisieren wir das Coden wenn Ihr jetzt zu zweit an den ASP-Seiten werkelt?
Nicht das mehrere parallel an den gleichen Geschichten programmieren. Wie soll man das dann zu einem stable Release zusammenfügen ...

Ok, jetzt habe ich den Zweck der Buchhaltungsseite auch verstanden Dann ist die Benutzerordnung in der Tat egal.

Das gleichzeitige Arbeiten ist problematisch. Es notwendig, dass jeder seine Änderungen an den 2.8.2er Quellen protokolliert und wir diese dann in Einklang bringen. Wie wäre es wenn wir die gerade in Bearbeitung befindlichen Scripte im Forum als Themen einstellen und dort die Änderungen als Antworten posten. Sobald die Änderungen getestet und in ein Release überführt wurden, könnten die Themen gelöscht werden.

das sollte machbar sein - ich richte mal einen separaten BEreich Entwicklung ein, in dem das stattfinden kann ...