Import-CSV und New-ADUser

[Friesenjunge 17]

Moin Community!
 
 Habe folgenden Artikel ( http://technet.microsoft.com/de-de/magazine/ee914610.aspx ) gelesen und wollte es in unserer Testumgebung gleich mal ausprobieren.
 
 Erstmal die passende CSV-Datei (in UTF-8 - wichtig!) erstellt, mit folgenden Spalten:
 
 

 

name,UserPrincipalName,SamAccountName,displayname,givenname,surname,Office,Department,StreetAddress,PostalCode,City,Title,OfficePhone,Fax,Company,Path,accountpassword,enabled,ChangePasswordAtLogon:

 

 
 Nun habe ich in der Powershell (mit AD-Modul) den folgenden Befehl, wie im Artikel beschrieben, eingegeben und abgeschickt:
 
 

 

 Import-CSV c:\my-new-users.csv | New-ADUser

 

 

 So weit, so gut.
 
 Nun schmeit mir die Powershell aber für jeden anzulegenden User einen Fehler aus, mit dem ich nicht so recht was anfangen kann:
 
 +CategoryInfo: Object not found: (Probi Müller...ermany, DC=Local:String) [New-ADUser], ADIdentityNotFoundException
 +FullyQualifiedErrorID: Verzeichnisobjekt nicht gefunden, Microsoft.ActiveDirectory.Management.Commands.NewADUser
 
 Angemeldet bin ich, ich bin in der Gruppe der Domänenadministratoren.
 
 Die angegebene OU, die ich mit "Path" übergebe, sind definitiv vorhanden.
 
 Wo liegt mein (Denk?)Fehler?
 
 Falls Ihr noch weitere Infos braucht, liefere ich sie gerne nach.
 
 Danke!
 
 Euer Friesenjunge

bearbeitet 22. Mai 2014 von Friesenjunge

[Sunny61 806]

Du darfst das gerne nochmal frisch formatieren, so ist der Text schwer bis gar nicht zu lesen.

[Friesenjunge 17]

Sorry, habe im Nachhinein den Beitrag editiert und die Fehlermeldung Fett und Kursiv gesetzt und danach hat der Board-Editor diesen HTML-Schlunz reingeschrieben...

 

Werde mich gleich nochmal dranmachen...

 

Done, HTML-Code entfernt.

 

Vielleicht hat die Boardware ja ein Prob mit aktuellem IE?

 

 

Ha!

 

 

bin einen kleinen Schritt weiter:

Habe nun in der CSV die Spalte "Path" weggelassen. Dort hatte ich eingetragen: "CN=Thorsten Test, OU=Bulk-Insert,OU=Benutzer_Standort_01,OU=Benutzerkonten,DC=unsere-domain,DC=local"

 

Nun klappte es. Allerding landen erwartungsgemäß die neu angelegten User nun in dem Standard-Container "Users"...

 

Mein Ziel war eigentlich, die user direkt in einer bestimmten OU anzulegen.

bearbeitet 22. Mai 2014 von Friesenjunge

[RHaneberg 10]

Beim Path die "" vergessen?

 

Ansonsten sollte dir dieser Blog evtl weiterhelfen:

 

http://blogs.technet.com/b/samdrey/archive/2011/09/26/bulk-populate-an-ad-using-a-csv-file-and-new-aduser-including-passwords.aspx

 

der macht ja nichts anderes

 

 

Achso und Passwort im Klartext ist auch schlecht, da securestring für das cmdlet gefordert ist

bearbeitet 22. Mai 2014 von RHaneberg

[h-d.neuenfeldt 21]

mir stößt der Umlaut in der roten Fehlermeldung auf ....

ich bastle zur Zeit selbst an Scripten für AD, wenn auch auf einem 2003 Server.

Regelmäßig führen Umlaute im Editor eingegeben zu Fehlern, wenn ich die Datei dann in einer CMD-Shell mit dem Editor bearbeite funktioniert es.

Dass da unterschiedliche Zeichensätze zum tragen kommen, erkennt man, wenn man eine solche Datei wieder mit dem Editor aufmacht. Dann stehen statt der Umlaute nämlich "ganz merkwürdige" Zeichen in der Datei ..

[Daniel -MSFT- 129]

Das liegt an ANSI/ASCII. Einfach beim Speichern in Notepad den richtigen Zeichensatz auswählen.

[Friesenjunge 17]

Erstmal Danke an alle!

@Daniel und h-d.neuenfeldt: In mehreren Microsoft-Quellen habe ich gelesen, dass die CSV-Datei mit den zu importierenden Userdaten in UTF-8 gespeichert werden muss.

Bei Powershell-Scripten ist es sogar so, dass UTF-8 mit aktiviertem BOM zum Speichern des Scriptes verwendet werden muss.

Die Daten werden ja korrekt gelesen.

 

@RHaneberg:

Ich hatte es beim Path sowohl mit, als auch ohne Anführungszeichen versucht. bei beiden Varianten kommt es zu der Fehlermeldung.

 

Mit den Passwörtern ist es so eine Sache. Auf der einen Seite ist es ja komfortabel, die Passwörter in der CSV mit zu übergeben. Man kann dann im Zuge einer Migration (dafür ist das gedacht...) aus der CSV heraus einen per Serienbrief einen "Kennwortbrief" für die User erstellen.

Der Tipp zu dem Blogbeitrag ist sehr interessant, da hier die Möglichkeit beschrieben ist, die Klartextpasswörter auch im Massenimport in einen SecureString zu konvertieren.

 

Ich teste das aus und melde mich wieder.

 

Es ist auch nicht wirklich "kriegsentscheidend", ob ich die User direkt in der korrekten OU erstellt wird, oder zunächst im Container "Users" landet.

Die OU wäre halt eine separate namens "Bulk-Import" gewesen, dort hätte ich alle auf einem Schwung gesehen und bei Bedarf manuell verschoben.

[NorbertFe 2.034]

Dann redirecte doch einfach den Standard Ort in dem User erstellt werden.

[Daniel -MSFT- 129]

Erstmal Danke an alle!

@Daniel und h-d.neuenfeldt: In mehreren Microsoft-Quellen habe ich gelesen, dass die CSV-Datei mit den zu importierenden Userdaten in UTF-8 gespeichert werden muss.

Bei Powershell-Scripten ist es sogar so, dass UTF-8 mit aktiviertem BOM zum Speichern des Scriptes verwendet werden muss.

Die Daten werden ja korrekt gelesen.

 

Das stimmt. Ich bezog mich auf:

 

Regelmäßig führen Umlaute im Editor eingegeben zu Fehlern, wenn ich die Datei dann in einer CMD-Shell mit dem Editor bearbeite funktioniert es.

 

Beim Copy&Paste in die CMD-Shell und wenn man CMD-Dateien mit dem Editor bearbeitet, spielt die ASCII/ANSI-Frage eine Rolle. PowerShell löst das mit UTF-8 vorbildlich.

[Friesenjunge 17]

Dann redirecte doch einfach den Standard Ort in dem User erstellt werden.

 

Stimmt, das wäre eine Möglichkeit, ist aber in dieser Situation, da der Massenimport nur einmal erfolgen soll, nicht notwendig.

 

@Daniel: OK, ist angekommen ;)

[Daniel -MSFT- 129]

Habe nun in der CSV die Spalte "Path" weggelassen. Dort hatte ich eingetragen: "CN=Thorsten Test, OU=Bulk-Insert,OU=Benutzer_Standort_01,OU=Benutzerkonten,DC=unsere-domain,DC=local"

 

Der Pfad ist falsch. Da sollte meines Wissens nach nur die Ziel-OU drin stehen. Du schreibst den CN mit rein.

[Friesenjunge 17]

Auch ohne den CN wurde der Fehler ausgegeben. Daher hatte ich ihn ja mit reingenommen.

Aber es ist im Moment auch nicht so dramatisch, da wir sehr gut im Zeitplan der Migration sind. Ob ich die User aus "Users" oder aus der eigentlichen Ziel-OU verschiebe, ist nicht wirklich entscheidend.

Da wir das Feld "Description" im Unternehmen im Userobjekt nicht verwenden, habe ich hier fest den Wert "Scriptgenerierter, deaktivierter Account" hinterlegt. Dann muss ich nur noch die User sortieren und dann verschieben.

 

Wenn die User dann nach und nach (geplanter Parallelbetrieb) aktiv gehen, wird der Hinweis entfernt.

 

Ursprünglich war geplant, das mit CSVDE umzusetzen, das scheitert aber an der maximalen Spaltenanzahl beim Import.

Das hatten Nils und Norbert auch in Ihrem Buch "Windows Server 2003 - Die Expertentipps" (MS Press 5604, ISBN 9783866456044) geschrieben.

 

Dann stieß ich auf die Powershell (war über den Scripting Guy) und war sofort "angefixt"... ;)

[Daniel -MSFT- 129]

Das mit der Zeilenlänge kenne ich. Deswegen hatte ich - bevor es die PowerShell mit den AD-Commandlets gab - das mit ldifde gemacht. Mit einem kleinen Trick konnte man das mit CSV-Dateien kombinieren: http://www.faq-o-matic.net/2004/12/31/erzeugen-von-ldifde-templates-aus-excel-mit-gnu-awk/

 

Krass, dass das jetzt schon 10 Jahre her ist...

[Friesenjunge 17]

Ja, Daniel, die Tools von Microsoft waren früher eher bescheiden.

Inzwischen hat sich da glücklicherweise einiges getan!

 

Auf jeden Fall klappt es jetzt, wenn auch nicht 100% so, wie geplant, aber das stört nicht wirklich. Manchmal muss man andere Wege gehen.

 

Auf jeden Fall vielen Dank an alle für Eure Tipps und Lösungsansätze!