Jump to content

Netloggon Script Fehler: UNC Pfade werden nicht unterstützt


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

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

Link zu diesem Kommentar

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.

Link zu diesem Kommentar

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----------------------------------------

Link zu diesem Kommentar

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).

Link zu diesem Kommentar

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]

Link zu diesem Kommentar
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. ;)

Link zu diesem Kommentar

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.

Link zu diesem Kommentar
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. ;)

Link zu diesem Kommentar
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. :confused: 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

Link zu diesem Kommentar

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.

Link zu diesem Kommentar

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

Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...