Netloggon Script Fehler: UNC Pfade werden nicht unterstützt

[killinspree 10]

Hallo zusammen,

 

wir haben vor kurzen ein zentrales Managemet Tool für Virenscanner in unserer Firma eingeführt.

 

der agent der mit diesem server komuniziert wird via silent setup auf den clients installiert, aufgerufen wir das setup über das netloggon script des benutzers.

 

bei einigen funktioniert das nicht. obwohl die rechner alle eins zu eins installiert und konfiguriert sind >> softwareverteilung.

 

der fehler lautet:

UNC Pfade werden nicht unterstützt. (...steht im cmd fenster...)

 

natürlich haben wir dann sofort probiert die installation über ein gemapptes Laufwerk zu starten, aber bisher haben sich noch keine neuen Clients am Server gemeldet.

 

kann mir jemand sagen warum der obige fehler bei einigen auftritt und bei einigen nicht und vor allem wie ich den beheben kann!!??

 

Danke

KillinSpree

[edv-olaf 10]

Welcher Befehl verursacht denn die Fehlermeldung?

 

Grüße

Olaf

[killinspree 10]

Das ist das Script das über denn Netloggon ausgeführt wird.

 

 

@ECHO OFF

if not exist c:\programme\epoagent\mcscript.exe J:\agent\framepkg.exe /INSTALL=AGENT /INSTDIR=C:\Programme\ePOAgent /S

 

 

Info dazu:

 

/S = Silent Setup

J: ist ein für jeden benutzer gemapptes Laufwerk auf ein Server Share auf dem jeder lesen und ausführen darf.

 

ansonsten spricht das ding wohl für sich.

 

 

 

Beispiel für ein Netloggonscript:

 

# Laufwerkszuweisung für Vertrieb-Benutzer

NET USE H: \\SRV_1\Vertrieb

NET USE J: \\SRV_1\JEDER

NET USE E: \\SRV_1\APPS

 

# Aufruf für EPolicy Orchestra

J:\agent\agent_inst.cmd

 

 

Fehler kommt folgender:

Verwendung von UNC Pfaden nicht unterstützt

>> darauf hin haben wir die unc Pfade auf das Laufwerk J: umgeschrieben, aber es funkt noch nicht bei allen.

[edv-olaf 10]

Steht das "net use J: ...." kurz vor dem "framepkg.exe"-Befehl? So von wegen Timingproblem?

[killinspree 10]

Hi,

 

die scripten sind genau so wie ich die gepostet hab.

------------------------------------------------------------------------------------

 

ich glaube nicht das es an den timing liegt schliesslich sind die nw laufwerke wie z.b j: schon verbunden. wenn diese manuell getrennt wurden dann werden sie wieder aufgebaut.

 

in der regel sind sie aber schon verbunden.

 

---------------------------------------mfg----------------------------------------

[edv-olaf 10]

Verursacht der betreffende Befehl denn Probleme, wenn er manuell nach dem Login-Script aufgerufen wird?

 

Grüße

Olaf

[zuschauer 10]

Hi,

diese Fehelrmeldung kommt, wenn man ein Batch - bzw. CMD-File aus dem Netlogonverzeichnis heraus startet.

Das Problem scheint der Scriptaufruf

 

J:\agent\agent_inst.cmd

 

im LoginScript zu sein.

Da zum Anmeldezeitpunkt noch kein aktuelles Laufwerk zugewiesen ist soll es im Netlogon-Verzeichnis als aktuelles Verzeichnis ausgeführt werden -daher dann die Fehlermeldung.

 

Ihr könntet dies so umgehen, daß Ihr den gesamten Inhalt der agent_inst.cmd in das LoginScript mit aufnehmt (falls das nicht zu viel ist).

[edv-olaf 10]

Ach Zuschauer, hättest du das nicht eher sagen können? ;)

 

Klingt aber logisch. Wie sähe es aus, die cmd.exe explizit mit dem Befehl als Parameter aufzurufen?

Etwa

c:\windows\system32\cmd.exe /c "if not exist c:\programme\epoagent\mcscript.exe J:\agent\framepkg.exe /INSTALL=AGENT /INSTDIR=C:\Programme\ePOAgent /S"

 

Grüße

Olaf

 

[edit] das "/c" fehlte noch in der Befehlszeile. Danke an zuschauer. [/edit]

[zuschauer 10]

Original geschrieben von edv-olaf

Ach Zuschauer, hättest du das nicht eher sagen können? ;)

Ne, konnte ich nicht, ich komm am Tag nicht dazu, hier mitzulesen.

 

Ich bin mir auch nicht sicher, ob man mit der cmd.exe weiterkommt.

Wenn Olaf´s Tipp nicht greift, könnte man es noch über einen direkten Aufruf der command.com versuchen:

 

c:\windows\system32\command.com /C "if not exist c:\programme\epoagent\mcscript.exe J:\agent\framepkg.exe /INSTALL=AGENT /INSTDIR=C:\Programme\ePOAgent /S"

 

Wobei ich dabei momentan nicht weiß, ob dann als aktuelles Directory c:\windows\system32 genommen wird - müßte man mal testen. ;)

[killinspree 10]

Hi Ihr da draussen,....

 

der fehler kommt beim aufruf des netloggonscripts wie ZUSCHAUER schon sagte.

 

wenn ich die 2te CMD ausführe funkts eigendlich immer.

 

das ganze hat ja folgenden hintergedanken, wenn ich nun änderungen an dem installscript vornehmen muss, muss ich die nur in einem script pflegen, nicht in jedem netloggon script.

 

____________________________________________________

 

was mich so wundert ist das einige clients es anstandslos durchführen und den agent schon sauber installiert haben.

 

@zuschauer:

sorry aber das mit den netzlaufwerken die nicht aktiv sind kann ich mir nicht vorstellen. schliesslich werden die netzlaufwerke von den von uns verwendeten scripten nur verbunden aber nicht getrennt. d.h. es sollten auch wenn ein user mal kein script bekommt noch die laufwerke von seiner letzten anmeldung vorhanden sein.

[zuschauer 10]

Original geschrieben von killinspree

sorry aber das mit den netzlaufwerken die nicht aktiv sind kann ich mir nicht vorstellen. schliesslich werden die netzlaufwerke von den von uns verwendeten scripten nur verbunden aber nicht getrennt. d.h. es sollten auch wenn ein user mal kein script bekommt noch die laufwerke von seiner letzten anmeldung vorhanden sein.

So hab ich das auch nicht gemeint.

Deine LoginScript wird aus dem Netlogon-Verzeichnis ausgeführt.

Dies hat keinen Laufwerksbbuchstaben sondern wird über den UNC-Pfad erreicht.

Wird in dem Script ein weiteres Script (CMD o. Batch) aufgerufen, wird für versucht, für diese Umgebung das aktuelle (DOS-)Laufwerk zu ermitteln - dies existiert nicht und führt zu der UNC-Warnmeldung.

 

Deine Argument, daß Du bei einer Veränderung der Installroutine, diese dann auf alle Netlogonscripte verteilen müßtest, zieht aber nicht. Die Netlogonscripte werden automatisch verteilt - das wäre also kein Hinderungsgrund. ;)

[himbidas 10]

Original geschrieben von zuschauer

Deine LoginScript wird aus dem Netlogon-Verzeichnis ausgeführt.

Dies hat keinen Laufwerksbbuchstaben sondern wird über den UNC-Pfad erreicht.

Wird in dem Script ein weiteres Script (CMD o. Batch) aufgerufen, wird für versucht, für diese Umgebung das aktuelle (DOS-)Laufwerk zu ermitteln - dies existiert nicht und führt zu der UNC-Warnmeldung.

Das hört sich soweit plausibel an. Doch so recht kann ich das nicht glauben. Bei mir starten die User z.b. je nach Abteilung ein anderes "Initial-Script", dieses "called" ein "Zentral-Script" im NETLOGON und darin gibt's je nach Gruppenzugehörigkeiten noch ein paar Calls auf weitere CMD's. Diese Aufrufe funzen und nix versucht das Aktuelle (DOS)-Laufwerk zu ermitteln. Was könnte also noch faul sein??

@killinspree

Kommt der Fehler nur auf Clients, die die if-Klausel nicht erfüllen? Oder ist das eher "zufällig"? Trifft es nur bei allen Nicht-ePo-Agent-Kisten zu, dann ist zuschauer's Erklärung die Wahrscheinlichste. Gibt es aber welche, die es installieren und welche, die nicht -> dann muss es einen anderen Grund geben.

Der Einfachheit halber würde ich auch dazu raten, im Export-NETLOGON-Verzeichnis ein Unterverzeichnis epo-inst zu erstellen, dort die framepkg.exe reinpacken und das ganze zu replizieren. Vorher noch das Anmeldescript so umschreiben, dass es auf die neue exe zur Installation losgeht.

Und sollte es überhaupt nicht wollen, versuche deine agent-inst.cmd so zu rufen:

call %LOGONSERVER%\NETLOGON\agent-inst.cmd

 

Am Rande noch zwei Tipps

a) benutze ich seit neuestem auch die ePo von NAI. Habe dabei u.a. festgestellt, dass einige Clients sich nicht sauber updaten konnten, da sie keine Verbindung zum Repository-Server bekamen. Ursache: DNS-Auflösung für WINDOWS war bei einigen nicht aktiviert. Dadurch keine Namensauflösung, keine Verbindung zum Server. U.U. wäre das auch ein Grund für Dein Problem.

b) Kommt nach deinem ePo-Check in Deinem Anmeldescript noch irgendwas für das Login? Wenn ja, würde ich dazu raten, "Unter-Batches" mit einem CALL zu rufen. Ansonsten wird z.B. nur dein agent-inst.cmd gerufen, abgearbeitet und danach ist das LOGIN beendet, da nicht zum "rufenden" Loginscript zurückgekehrt wird.

 

Thomas

[zuschauer 10]

Hi himbidas !

Du hast natürlich recht, mit dem Call-Befehl wird kein neues Enviroment erzeugt sondern das bereits bestehende genutzt !

Somit fällt dann auch diese UNC-Fehlermeldung weg.

Manchmal sieht man halt den Wald vor Bäumen nicht ! ;)

[killinspree 10]

Hi,

 

ich habe gerade die letzten postings gelesen.

@zuschauer:

 

wir haben aneinander vorbeigeredet, ich meinte, da wir für jede abteilung und für spezielle benutzer sogar ein eigenes script haben, müsste ich wenn ich jetzt in jedem script gleich die installroutine eintrage auch wieder jedes script anfassen wenn sich am ort der framework.exe was ändert.

 

@himbidas:

 

hey cool jemand der mit ePO arbeitet, bist du zufrieden?

´

@all:

 

ich versuch mal eure tipps, ich hoffe funkt diesmal.

 

____________________________________________________

 

Wo tritt der Fehler auf:

 

 

wir haben compaq evo 300 in den vertriebsbüros stehen, alle die selbe charche von PC´s. Die Rechner sind Image-PC´s.

Die sollten also alle gleich konfiguriert sein, was so grundlegende Einstellungen angeht.

[himbidas 10]

Es gibt immer ein für und wider. Mit der Vorgängerversion (VScan 4.5) konnte ich z.b. noch externe Programme als eigene Tasks definieren, das geht in ePo nimmer :mad:

Für dein Thread-Problem (alles mal unter dem Gesichtspunkt "Sicherheit")

1. Wieso machst du dir eigentlich die Mühe zu checken, ob der Agent installiert ist?

a) sagt das Vorhandensein der mcscript.exe null-komma-nix darüber aus, ob der Agent auch läuft. Z.b. könnte ein gewitzter Zeitgenosse einfach eine Dummy-Datei in dein Agent-Verzeichnis legen.

b) benötigt die Installation des Agent Adminrechte, zumindest jedoch Rechte zur Änderung an der Registry. Haben deine User alle diese Rechte?? seeehr unsicher! Sollten sie diese Rechte nicht haben, musst du zum Installieren mindestens einen Account mit Adminrechten (Name + Passwort) mit angeben. auch seeehr unsicher!

2. Wie installiert ihr eure Clients? Macht das jeder User selber, oder geht die Kiste nicht erstmal über einen Platz der EDV-Abteilung?

a) Warum bügelt ihr dann nicht gleich den Agent mit drauf?

b) Im ePo kann man einen Agent-Ausbringungstask definieren. Nachdem 2.a) erledigt wurde und sich der Client sauber am ePo-Server gemeldet hat ist es Rille, was der Anwender mit dem Teil treibt. Selbst wenn er ihn deinstalliert (so er kann), würde der nächste Check das Servers das bemerken und den Agent wieder drüberbügeln.

 

Jedenfalls betrachte ich die Installationsmethode nach deinen Prüfkriterien als ziemlich vorgegaukelte Sicherheit. Wenn du schon die mcscript.exe zum checken nutzt, mach folgendes:

- auf einem ständig erreichbaren Server eine versteckte Freigabe anlegen, z.B. epochk$ (volle Rechte)

- im Loginscript den Check so realisieren:

 if not exist c:\programme\epoagent\mcscript.exe date /t >> \\server\epochk$\%COMPUTERNAME%.txt

Das Teil legt also eine Datei mit dem Namen des betreffenden PC's, Inhalt: Datum zum Zeitpunkt des Fehlens der mcscript in das Verzeichnis. Wegen >> wird der Check fortgeschrieben, so dass man das erste Auftreten wenigstens Tagesgenau rückverfolgen kann.

- der "Virenverantwortliche" prüft, je nachdem wie oft das notwendig ist, dieses Verzeichnis.

 

Vorteil: Man hat die Kontrolle über die Antiviren-Gschichte und kann im E-Fall dem bösen Buben, der u.U. an der Sache manipuliert hat, auf die Finger pochen. Jedenfalls legt man sich nicht gemütlich als Admin zurück und denkt "ahaaa, meine mcscript.exe ist da, alles läuft und meine User sind alle Engel..."

 

so long, Thomas