MapDriveAdd mit Kontrolle der AD Gruppenzugehörigkeit.

    Wir nutzen zur Zeit eine batch Datei um laufwerke zu mappen:
    So soeht die aus:

    [autoit]

    REM @echo off

    [/autoit][autoit][/autoit][autoit][/autoit][autoit]

    net use /delete * /YES

    [/autoit][autoit][/autoit][autoit]

    net use G: \\Firmanname.local\dfs\Abteilung /persistent:no

    [/autoit][autoit][/autoit][autoit]

    net use H: \\Firmanname.local\dfs\Home$\%username% /persistent:no

    [/autoit][autoit][/autoit][autoit]

    net user /DOMAIN %username% | find "G-Betriebsrat"
    if not errorlevel = 1 (
    net use O: \\Firmenname.local\dfs\Betriebsrat /persistent:no
    )

    [/autoit][autoit][/autoit][autoit]

    net user /DOMAIN %username% | find "IT-Abt"
    if not errorlevel = 1 (
    net use S: \\Firmanname.local\dfs\Software /persistent:no
    )

    [/autoit][autoit][/autoit][autoit]

    net user /DOMAIN %username% | find "G-Buchhaltung"
    if not errorlevel = 1 (
    net use L: \\DATEVSERVER\Windvsw1 /persistent:no

    [/autoit][autoit][/autoit][autoit]

    net use M: \\DATEVSERVER\Windvsw2 /persistent:no

    [/autoit][autoit][/autoit][autoit]

    )

    [/autoit]


    G-betriebsrat, ITAbt und G-Buchhaltung sind AD Gruppen.
    Kann man sowas mit DriveMappadd abbilden? So dass die Gruppenzugehörigkeit überprüft wird?

    Einmal editiert, zuletzt von Camulus (31. Januar 2012 um 10:46)

    Kurz und Knapp, ja es geht :)
    ich würde folgendermaßen vorgehen
    als erstes würde ich mir die AD Udf von Water Downloaden (eine Funktionssammlung der AD Funktionen, um über Autoit seine Domainstrucktur zu verwalten)
    AD UDF
    alle wichtigen Funktionen sind in Hilfefiles erklärt, und sollte zu bewerkstelligen sein.
    als zweites brauchst du noch die Funktion DriveMapAdd(), diese kannst du dir ausführlich in der Autoit Hilfe anschauen.

    Gruß Marvin

    Und wenn Du Fragen zum AD UDF hast, poste sie hier - ich werd' ein Auge auf den Thread haben.

    Danke dir.
    Das ist eine von mehreren Möglicgkeiten die gerade diskutiert werden. Ob es das wird weiss man noch nicht.

    Das alles soll in ein Tool das die VPN Verbindung aufbaut und dann Laufwerke mappt. Momentan wird alles über eine Batchdatei gemappt.
    Der Nachteil es über Auoit direkt zu machen wäre dass wenn sich änderungen ergeben eine neue Exe raus muss.

    Es sei denn ihr habt noch bessere Ideen :D

    Zitat von Camulus

    Der Nachteil es über Auoit direkt zu machen wäre dass wenn sich änderungen ergeben eine neue Exe raus muss.

    Aber das Problem hast Du mit einer Batch-Datei doch auch, oder nicht?

    Also erstens brauchste dass bei der Batch Datei auch und zweitens kannst du auch ein Externes File verwenden in dem du Wichtige Daten speicherst zb Die Pfade usw.. dese Datei könntest du auf einem FTP ablegen (ausserhalb vom Firmennetz) und diese Datei dir bei jedem Aufruf Herrunterladen. somit brauchst du nur diese Datei ändern und alle Clients hätten die Änderung gleich mit oder lösung 2 einen Updater bauen der eine Lokale inidatei zb Ändert aus der das Tool seine Informationen bezieht

    Gruß Marvin

    Also momentan liegt die Batch auf dem Logonserver in netlogon Verzeichnis.
    Dieses Datei rufe ich dann auf:

    [autoit]

    RunWait(@LogonServer & "\netlogon\logon.bat","",@SW_HIDE)

    [/autoit]

    Das funktioniert soweit auch. Allerdings nicht immer zuverlässig. gerade bei UMTS verbindungen gibt es da schonmal Probleme.
    Der Plan ist jetzt das alles in eine Schleife zu packen die nach den Ausführen überprüft ob die Netzlaufwerke da sind, und wenn nicht es eben nochmal ausführt. Maximal drei mal. Wenns dann immer noch nicht geklappt hat gibts ne entsprechende Meldung.

    Um dem UMTS Problem aus dem Weg zu gehen haben wir überlegt die Batch Datei erst ins @scriptidr zu kopieren und dann lokal auszufühen.

    Wenn ich eine ini- Datei irgendwo im Netz liegen habe hab ich ja letztendlich wieder das selbe Problem. Ob das jetzt wirklich an einer wackeligen verbindung liegt muss natürlich noch getestet werden.

    Also ich würde es auch so lösen die Batch Datei dir vom LogonServer zu laden in dein Lokales Temp verzeichniss und dann sie von dort aus auszuführen, ob die Datei geladen wurde ist ja einfach zu prüfen, habe dass mit der INI auch nur als eine der Möglichen alternativen aufgezählt ..

    Gruß Marvin

    Zitat von Camulus

    Also momentan liegt die Batch auf dem Logonserver in netlogon Verzeichnis.
    Dieses Datei rufe ich dann auf:

    [autoit]

    RunWait(@LogonServer & "\netlogon\logon.bat","",@SW_HIDE)

    [/autoit]

    Das funktioniert soweit auch. Allerdings nicht immer zuverlässig. gerade bei UMTS verbindungen gibt es da schonmal Probleme.
    Der Plan ist jetzt das alles in eine Schleife zu packen die nach den Ausführen überprüft ob die Netzlaufwerke da sind, und wenn nicht es eben nochmal ausführt. Maximal drei mal. Wenns dann immer noch nicht geklappt hat gibts ne entsprechende Meldung.

    Um dem UMTS Problem aus dem Weg zu gehen haben wir überlegt die Batch Datei erst ins @scriptidr zu kopieren und dann lokal auszufühen.

    Wenn ich eine ini- Datei irgendwo im Netz liegen habe hab ich ja letztendlich wieder das selbe Problem. Ob das jetzt wirklich an einer wackeligen verbindung liegt muss natürlich noch getestet werden.


    Hi,

    ich habe das bei mir so gelöst, dass ich das Netlogon verbinden lasse und erst nach erfolgreicher Verbindung wird das Logon script ausgeführt.

    [autoit]


    Global $mapping = "g:"
    Func netlogon()
    DriveGetDrive( "network" )
    If @error = 1 Then
    DriveMapAdd($mapping, "\\DC\netlogon")
    DriveGetDrive( "network" )
    While @error = 1
    DriveGetDrive( "network" )
    WEnd
    ShellExecuteWait($mapping & "\wkix32.exe", "odw.kix $SITE=" & $SITE & " $fileserver=" & $fileserver & " $NET=" & $NET, $mapping )
    DriveMapDel($mapping)
    EndIf
    EndFunc ;==>netlogon

    [/autoit]

    Funktioniert sehr stabil. Auch über schlechte Verbindungen.

    Gruss

    Stefan