Import von 500.000 Benutzer aus einer .csv ins ActiveDirectory
Performantere Methode gesucht.
Derzeit ca. 3000 Benutzer/Std.
Hat jemand eine performantere Methode zum Import von ca. 500.000 Benutzer aus einer .csv in eine ActiveDirectory OU?
Derzeit ca. 3000 Benutzer/Std.
Hat jemand eine performantere Methode zum Import von ca. 500.000 Benutzer aus einer .csv in eine ActiveDirectory OU?
Dim fso, f, Zeile, Feld
Set fso = CreateObject("Scripting.FileSystemObject")
Set f = fso.OpenTextFile ("user.txt",1,0)
Do while not f.AtEndOfLine
Zeile = f.readLine
Feld = split(Zeile,";")
Benutzer = Feld(0)
Vorname = Feld(1)
Nachname = Feld(2)
Passwort = Feld(3)
Call BenuntzerAnlegen(Benutzer,Vorname,Nachname,Passwort)
Loop
f.Close
Wscript.Quit(0)
Sub BenuntzerAnlegen(Benutzer,Vorname,Nachname,Passwort)
Dim ouo, b
Set ouo = GetObject("LDAP://OU=Benutzer,DC=evaluation,DC=procon,DC=local")
Set b = ouo.Create("user", "CN=" & Vorname & " " & Nachname)
Dim WshShell, ret
Set WshShell = WScript.CreateObject("WScript.Shell")
b.Put "sAMAccountName", Benutzer
b.Put "displayName", Vorname & " " & Nachname
b.Put "givenName", Vorname
b.Put "sn", Nachname
b.Put "userAccountControl", 66082
b.Put "userPrincipalName", Benutzer & "@evaluation.procon.local"
b.SetInfo
b.SetPassword Passwort
b.AccountDisabled = False
b.SetInfo
WScript.Sleep(1000)
End Sub
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 104248
Url: https://administrator.de/forum/import-von-500-000-benutzer-aus-einer-csv-ins-activedirectory-104248.html
Ausgedruckt am: 22.12.2024 um 10:12 Uhr
9 Kommentare
Neuester Kommentar
Hallo,
ob ich bin mir nicht sicher, ob mein Vorschlag wirklich performanter ist (zumindest nutzt er kein WSH). Aber du könntest dir mal ldifde und csvde anschauen. Beide kommen von MS und sollten in sofern taugen (und performant sein).
Definitiv würde ich dir empfehlen, die Datei zu "zersägen" und in tranchen zu importieren. Vielleicht erliegt man sonst doch einem "Schluckauf" der Speicherverwaltung, vor allem wird Fehlersuche wohl _deutlich_ einfacher.
Weitere positiver Effekt: Ich bin mir nicht sicher, wie die Replikation reagiert, wenn innerhalb kürzerster Zeit 500k Objekte erzeugt werden.
Gruß
Filipp
ach ja: einfachste Methode um deine Methode performanter zu machen dürfte sein das Sleep(1000) zu entfernen.
ob ich bin mir nicht sicher, ob mein Vorschlag wirklich performanter ist (zumindest nutzt er kein WSH). Aber du könntest dir mal ldifde und csvde anschauen. Beide kommen von MS und sollten in sofern taugen (und performant sein).
Definitiv würde ich dir empfehlen, die Datei zu "zersägen" und in tranchen zu importieren. Vielleicht erliegt man sonst doch einem "Schluckauf" der Speicherverwaltung, vor allem wird Fehlersuche wohl _deutlich_ einfacher.
Weitere positiver Effekt: Ich bin mir nicht sicher, wie die Replikation reagiert, wenn innerhalb kürzerster Zeit 500k Objekte erzeugt werden.
Gruß
Filipp
ach ja: einfachste Methode um deine Methode performanter zu machen dürfte sein das Sleep(1000) zu entfernen.
Hallo FaBMiN,
ich hab mal 500 Benutzer auf einmal angelegt.
Der Server ist ein altersschwacher w2k und ich habe mir mit Excel mit der Autofill-Funktion eine Batch-Datei angelegt und den "net user"-Befehl benutzt. (das geht natürlich bei 500000 Benutzern nicht, weil Excel soviel Daten nich verarbeiten kann).
Dabei habe ich auch festgestellt, dass es nach Ablauf des Batch-Programms eine ganze Weile dauert, bis die neuen Benutzer korrekt im AD angezeigt werden (die Zeitdauer weiß ich nicht mehr). Ich vermute, dass hier die Grenzen durch die Verarbeitungsgeschwindigkeit der Daten im AD vorgegeben werden.
Markus
ich hab mal 500 Benutzer auf einmal angelegt.
Der Server ist ein altersschwacher w2k und ich habe mir mit Excel mit der Autofill-Funktion eine Batch-Datei angelegt und den "net user"-Befehl benutzt. (das geht natürlich bei 500000 Benutzern nicht, weil Excel soviel Daten nich verarbeiten kann).
Dabei habe ich auch festgestellt, dass es nach Ablauf des Batch-Programms eine ganze Weile dauert, bis die neuen Benutzer korrekt im AD angezeigt werden (die Zeitdauer weiß ich nicht mehr). Ich vermute, dass hier die Grenzen durch die Verarbeitungsgeschwindigkeit der Daten im AD vorgegeben werden.
Markus
Hallo,
ich arbeite gerade an so einem script, ist mit 300 benutzern schon getestet. (Batch mit dsadd, ob das performater ist???)
da es aber noch sehr "unschön" geschrieben ist möchte ich es hier im forum noch nicht posten.
wenn es dringend ist schreib mir ein mail an juergen@pilgram.at ich schick es dir dann zu mit den anmerkungen was du noch händisch anpassen mußt.
lg
jürgen
ich arbeite gerade an so einem script, ist mit 300 benutzern schon getestet. (Batch mit dsadd, ob das performater ist???)
da es aber noch sehr "unschön" geschrieben ist möchte ich es hier im forum noch nicht posten.
wenn es dringend ist schreib mir ein mail an juergen@pilgram.at ich schick es dir dann zu mit den anmerkungen was du noch händisch anpassen mußt.
lg
jürgen
Servus,
ganz genau - und deshalb hat derjenige, der das Script ursprünglich geschrieben hat diesen "Sleep" auch dort plaziert.
Auch die "doppelten" Setinfos haben einen Grund.
Egal, wie deine CPU und RAM auslastung liegt.
Vergiss bitte nicht, daß du immer noch einen schreibenden Datenbankzugriff auf ein AD damit betreibst.
Das ist kein MYSQL oder Oracle Denk auch an die "Daten" die dabei erzeugt werden, obwohl du die nicht in dem Script explizit in Auftrag gibts. (SID usw.)
Klasse statt Masse - so nenne ich deine Art, die User anzulegen.
(fehlen da nicht ein paar Infos bei dem anlegen und *WTF* braucht 5.000 User innerhalb 50.000 oder 500.000 sekunden?)
Auch wenn es ein Script ist - immer daran denken, was es auslöst - löst viele Probleme, die eigentlich keine sind
Gruß
Das Sleep braucht er, weil den account sonst nicht richtig aktiviert, habe ich festgestellt.
ganz genau - und deshalb hat derjenige, der das Script ursprünglich geschrieben hat diesen "Sleep" auch dort plaziert.
Auch die "doppelten" Setinfos haben einen Grund.
Egal, wie deine CPU und RAM auslastung liegt.
Vergiss bitte nicht, daß du immer noch einen schreibenden Datenbankzugriff auf ein AD damit betreibst.
Das ist kein MYSQL oder Oracle Denk auch an die "Daten" die dabei erzeugt werden, obwohl du die nicht in dem Script explizit in Auftrag gibts. (SID usw.)
Klasse statt Masse - so nenne ich deine Art, die User anzulegen.
(fehlen da nicht ein paar Infos bei dem anlegen und *WTF* braucht 5.000 User innerhalb 50.000 oder 500.000 sekunden?)
Auch wenn es ein Script ist - immer daran denken, was es auslöst - löst viele Probleme, die eigentlich keine sind
Gruß
Hallo,
ich würde mal vermuten, daß Du eine Menge Zeit dadurch verschenkst, daß Du die Verbindung zum Active Directory bei jedem Durchlauf neu erzeugst (GetObject) anstatt die vorhandene Verbindung weiterzubenutzen. Also einmal zu Beginn "GetObject" durchführen, und dann den Loop über die "b."-Objekte durchführen.
Ich glaube nicht, daß das Sleep wirklich nötig ist, ich vermute einfach mal, daß es daran liegt, daß Du am Ende des Subs die Objekte nicht wieder freigibst. Damit muß sich VBScript selbst um das Freigeben kümmern, weswegen dann wohl auch das Sleep nötig ist. Wenn Du also am Ende hinzufügst:
Set b=Nothing
Set ouo = Nothing
Und dafür das Sleep wegläßt, sollte es eigentlich besser und schneller funktionieren. Hab's aber nicht getestet, ist nur eine Vermutung.
Wie gesagt, um die Performance dann noch mehr zu steigern, 1. Objekt erzeugen mit GetObject und dann den Rest des Programms durchlaufen lassen und als letzte Zeile mit Set ouo=Nothing erst das Objekt schließen und terminieren.
Viele Grüße
Christian
ich würde mal vermuten, daß Du eine Menge Zeit dadurch verschenkst, daß Du die Verbindung zum Active Directory bei jedem Durchlauf neu erzeugst (GetObject) anstatt die vorhandene Verbindung weiterzubenutzen. Also einmal zu Beginn "GetObject" durchführen, und dann den Loop über die "b."-Objekte durchführen.
Ich glaube nicht, daß das Sleep wirklich nötig ist, ich vermute einfach mal, daß es daran liegt, daß Du am Ende des Subs die Objekte nicht wieder freigibst. Damit muß sich VBScript selbst um das Freigeben kümmern, weswegen dann wohl auch das Sleep nötig ist. Wenn Du also am Ende hinzufügst:
Set b=Nothing
Set ouo = Nothing
Und dafür das Sleep wegläßt, sollte es eigentlich besser und schneller funktionieren. Hab's aber nicht getestet, ist nur eine Vermutung.
Wie gesagt, um die Performance dann noch mehr zu steigern, 1. Objekt erzeugen mit GetObject und dann den Rest des Programms durchlaufen lassen und als letzte Zeile mit Set ouo=Nothing erst das Objekt schließen und terminieren.
Viele Grüße
Christian
mann könnte auch gleich das programm eUser verwenden ....
Google hilft
mfg
Google hilft
mfg