forum.opsi.org

Hallo,

wir machen Fortschritte. Der erste Client ist im System, allerdings hat die Clientinstallation leider nicht aus der Kommadozeile vom OPSI Server aus funktioniert - der Batch wurde abgebrochen:
Das Problem besteht weiterhin. Liegt's an der Übergabe des Benutzers an winexe? Bei -U "domainAdmin%*** confidential *** fehlen mir die Trenner. Liegt's daran?

Den zweiten Versuch machte ich über die SMB-Freigabe unter Windows. Die Authentifizierung schlug fehl.

Es stellte sich heraus, dass zum Installieren des Clients das Netzwerk des Clients ebenfalls in der Variablen "admin networks" genannt werden muss. Ich muss daher gestehen, dass ich den Sicherheitsaspekt der Variablen deshalb nicht ganz verstehe. Auch zum Zugriff auf das netboot Produkt hwinvent scheinen Admin Rechte erforderlich - das Einmalpasswortverfahren habe ich nicht ausprobiert - wie ginge das?

Andere Sache: Letztlich ist es so, dass man unseren Benutzern das Booten in ein netboot Produkt nicht wirklich zumuten kann. Schon gar nicht, wenn man sich dort als opsiadmin authentifizieren muss. Was habe ich also falsch gemacht? Ich kann mir nicht vorstellen, dass das so sein muss?

Ich musste auch feststellen, dass der Zugriff auf hwinvent mit dem user "pcpatch" durchgeführt wird. Insofern muss der User in der Sambakonfiguraton für den Depot-Share auch berechtigt werden. Ich erinnere mich nicht mehr genau - war das initial schon so in der VM so eingestellt?

Deutlich einfacher und vollständiger(!) geht die Hardware-Inventur natürlich über das Script "hwaudit". Klasse, ich bin echt begeistert. Der Test fand jetzt auf einer Windows XP Maschine statt. Bin schon gespannt, wie das mit einer Windows 7 Kiste klappt...

poste mal wie du das aufgerufen hast. Ich tippe darauf das die Firewall das am Client nicht erlaubt.

tobias hat geschrieben:poste mal wie du das aufgerufen hast. Ich tippe darauf das die Firewall das am Client nicht erlaubt.

Nun, ich habe den Standardaufruf aus der Doku genutzt - Nichts Besonderes. Eine Firewall ist auf dem Testclient nicht aktiv, kann also nicht wirksam sein. Die Ausführung aus dem Depot-Share hat ja dann auch funktioniert, wenn auch die Verbindung natürlich anders herum aufgebaut wurde...

Heute habe ich den opsi-client auf einer Windows7 64bit Maschine (über ddie Depot-Freigabe) installiert. Habe ich richtig beobachtet, dass der Client UAC wieder aktiviert? Muss das so sein? Das würde ich unheimlich gern vermeiden!

installier mal ne neue winexe version.

(bei debian/ubuntu und co apt-get install winexe)

dann muss sichergestellt sein das wirklich keine Firewall blockt und die administrativen freigaben müssen zugänglich sein auf dem Client (c$)
wenn das auch nicht geht mal die -old probieren die auch im opsi-client-agent ordner liegt.

außerdem beachten das du den hostname full qualified angibst und probier ma zusätzlich mit der option -c das hat bei mir geholfen.
Erfahrungsgemäß funktionieren lokale administratoren außer der Benutzer "Administrator" nicht also am besten den verwenden.

zur benutzerkontensteuerung:
viewtopic.php?f=7&t=3291

tobias hat geschrieben:installier mal ne neue winexe version.

(bei debian/ubuntu und co apt-get install winexe)

dann muss sichergestellt sein das wirklich keine Firewall blockt und die administrativen freigaben müssen zugänglich sein auf dem Client (c$)
wenn das auch nicht geht mal die -old probieren die auch im opsi-client-agent ordner liegt.

außerdem beachten das du den hostname full qualified angibst und probier ma zusätzlich mit der option -c das hat bei mir geholfen.
Erfahrungsgemäß funktionieren lokale administratoren außer der Benutzer "Administrator" nicht also am besten den verwenden.

zur benutzerkontensteuerung:
viewtopic.php?f=7&t=3291

danke Tobias!

Ich habe winexe installiert und damit ging es. Allerdings hatte ich wohl zusätzlich den Parameter für den Benutzer falsch übergeben, nämlich ohne Anführungszeichen. Richtig ist die Übergabe als
Nach Installation des Clients habe ich auch hier (win7 64bit) versucht, hwaudit zu "installieren". Hier kam es, vermutlich wegen des anderen Sicherheitsmodells, zu einem Fehler beim Aufruf von WNetAddConnection(2). HWAUDIT funktioniert also hier zunächst mal nicht. Was ist zu tun, muss ich auf den Clients einen Benutzer "pcpatch" anlegen?

poste mals log von der "installation" ob x86 oder x64 sollte eigtl. keine rolle spielen. Konnte ich jedenfalls noch nicht feststellen.

tobias hat geschrieben:poste mals log von der "installation" ob x86 oder x64 sollte eigtl. keine rolle spielen. Konnte ich jedenfalls noch nicht feststellen.

Missverständnis: Auf WinXP geht hwaudit tadellos, auf Win7 hingegen nicht - egal ob 32bit oder 64bit. Ein Logfile der Aktion kann ich nicht finden. Wo sollte das sein?

Ich konnte in der opsi Statuszeile sehen, dass dort WNetAddConnection(2) - Access Denied" stand.

Hi,

bitte mal die opsiclientd.log bzw. im configed die clientconnect logdatei prüfen. Das riecht nach einem Kommunikationsproblem des agents.

ueluekmen hat geschrieben:Hi,

bitte mal die opsiclientd.log bzw. im configed die clientconnect logdatei prüfen. Das riecht nach einem Kommunikationsproblem des agents.

sorry, sieht alles gut aus. Für mich sieht es so aus, als dürfe der User (ist das pcpatch?) die Methode nicht aufrufen. Auf XP geht's ja auch perfekt.

Hi,

dieser Fehler kommt vom client-agenten, eventuell im Bereich des Depotshare-Mounts. Der Fehler besagt normalerweise, dass der User keine Rechte auf die Resource hat. Kann man den ausser hwaudit überhaupt Produkte verteilen, oder funktioniert nur hwaudit nicht?

Ohne Blick in die log vom Client kann man da nicht viel zu sagen.