woiza

Ja klar, du brauchst den distinguishedName zusätzlich. Das kannst du z.B. mit einem Excel-makro machen. Füge eine leere erste Spalte ein. Danach sollte dann der Vornamen und dann der Nachname stehen. Dann gehst du mit dem Makro in einer Schleife über alle Felder und setzst dir den Wert zusammen. Hier wäre ein Beispiel: Gruß woiza ' Erstellt den DN in der ersten Spalte der Tabelle Sub createDN() ' Die erste Zelle ist leer. Aktive Zelle sollte der erste Vorname '(zweite Spalte sein) Dim xlsReadDoc As Workbook Dim xlsReadUserTab As Worksheet Dim xlsReadLeseZelle As Range Dim iSpaltenAnzahl As Integer Dim dnSuffix As String Dim tempResult As String Set xlsReadDoc = ActiveWorkbook Set xlsReadUserTab = ActiveSheet Set xlsReadLeseZelle = ActiveCell 'hier muss angepasst werden dnSuffix = ",OU=kontakte,DC=test,DC=local" 'Schleife iSpaltenZahl = xlsReadLeseZelle.CurrentRegion.Rows.Count - 1 For I = 0 To iSpaltenZahl 'Zeile zusammensetzen tempResult = """" & "CN=" & ActiveCell.Value & " " & _ ActiveCell.Offset(0, 1).Value & dnSuffix & """" 'In Spalte eins Schreiben ActiveCell.Offset(0, -1).Value = tempResult 'Nächste Zeile ActiveCell.Offset(1, 0).Activate Next End Sub

Hi, bei C kann ich dir zustimmen, bei C++, naja. Ich finde, man kann die OO dann auch gleich mit JAVE/C# lernen und spart sich einige Magengeschwüre mit Speicherlecks, Pointern usw. Aber ist wahrscheinlich Geschmackssache. Gruß woiza

'eine Schleife startet hier und wird bis zum Ende des RecordSet durchlaufen Do Until objRecordSet.EOF 'Für den aktuellen Datensatz wird die Variable Profalt mit dem aktuellen Wert des Feldes profilePath befüllt strProfalt = objRecordSet.Fields("profilePath") 'InStr siehe Windows Script Doku; grob wird in strProfalt geschaut, ob darin strSrvalt vorkommt 'if then ist ja hoffentlich aus der Ausbildung bekannt, ansonsten Doku If InStr(1,strProfalt,strSrvalt,1) Then 'ist der Server gefunden, wird der distinguishedName des aktuellen Datensatzes in strUser geschrieben strUser = objRecordSet.Fields("distinguishedName") 'Sucht das Userobjekt mit dem entsprechenden Namen Set objUser = GetObject("LDAP://" & strUser) 'Put schreibt in das Feld profilePath das Zeug hinter dem Komma ' dort wird strSrvneu mit dem alten Profilpfad abzügl. dem alten Server verbunden 'dies geschieht durch das Right, auch hier Doku objUser.Put "profilePath", strSrvneu & Right(strProfalt,Len(strProfalt)-Len(strSrvalt)) 'Put hat nur das gecachte Objekt angefasst, mit SetInfo wird die Änderung ins AD geschrieben objUser.SetInfo 'Ein Zähler, der sich bei jeder Änderung um eins erhöht intZaehler = intZaehler+1 'Ende des If-Blocks End If 'Der Zeiger des RecordSet rutscht in die nächste Zeile objRecordSet.MoveNext 'hier endet die Schleife, wenn EOF erreicht ist Loop ' Clean up. 'Die Verbindung wird geschlossen objConnection.Close 'Die Objekte werden aus dem Speicher geworfen Set objRootDSE = Nothing Set objCommand = Nothing Set objConnection = Nothing Set objRecordSet = Nothing 'Die Messagebox meldet die Anzahl der Benutzer, die geändert wurden, siehe Zähler weiter oben MSGBOX "Es wurden" & intZaehler & "Benutzer geändert"

'Heißt soviel, wie du darfst keine Variable verwenden, die du nicht mit dim definiert hast Option Explicit 'Variablendefinitionen Dim objRootDSE, strDNSDomain, objCommand, objConnection Dim strBase, strFilter, strAttributes, strQuery, objRecordSet Dim strDN, strAltRecipient 'Liefert den RootDomänenKontext zurück Set objRootDSE = GetObject("LDAP://RootDSE") 'Liefert den Namen der Root, also DC=Test,DC=local strDNSDomain = objRootDSE.Get("defaultNamingContext") '## Die Suche wird mit ADO ausgeführt ## 'Das Command-Object wird hier initialisiert, die Suchoptionen werden danach an das Commandobjekt angehängt Set objCommand = CreateObject("ADODB.Command") 'Connection wird initialsiert Set objConnection = CreateObject("ADODB.Connection") 'Der Provider der Connection wird auf ADSI gesetzt; hier könnte die Connection z.B. auch auf Access/SQL Server... gesetzt werden objConnection.Provider = "ADsDSOObject" 'Connection wird geöffnet objConnection.Open "Active Directory Provider" 'Dem ADO-Command wird die soeben geöffnete Verbindung zugeordnet objCommand.ActiveConnection = objConnection '## Der Suchstring wird zusammengebaut siehe auch RFC 2254 ## 'Die Searchbase wird auf die Domäne eingestellt, alternativ könnte die Suche z.B. erst in einer OU beginnen strBase = "<LDAP://" & strDNSDomain & ">" 'Der Suchfilter wird definiert, in etwa der WHERE-Teil von SQL strFilter = "(& (objectCategory=person)(objectClass=user))" 'Welche Attribute soll die Suche zurückliefern, etwa der Teil hinter dem SELECT bei SQL strAttributes = "distinguishedName,profilePath" 'Die gerade definierten Werte werden zu einer LDAP-Query zusammengesetzt; 'das zusätzliche Subtree ist der Scope, in dem Fall wird der LDAP-Tree also nach unten durchsucht strQuery = strBase & ";" & strFilter & ";" & strAttributes & ";subtree" 'Auch der LDAP-Query qird jetzt an den ADO-Command angehängt objCommand.CommandText = strQuery '## Es werden noch ein paar Abfrageoptionen definiert ## 'PageSize: es werden immer 100 Werte am Stück zurückgeliefert; ist der Wert zu hoch, scheitert die Suche -> LDAP Policy im AD 'Standardlimit ist 1000 -> ntdsutil objCommand.Properties("Page Size") = 100 'Timeout erklärt sich von selbst, der Wert sind Sekunden objCommand.Properties("Timeout") = 30 'Die Abfrage wird nicht gecacht objCommand.Properties("Cache Results") = False 'Das ADO_Command hat jetzt alles, was es braucht und wird ausgeführt; das Ergebnis wird an ein Recordset übergeben Set objRecordSet = objCommand.Execute 'zwei Variablen werden befüllt, ich hätte dies aus "ästhetischen Gründen" schon oben gemacht strSrvneu="\\W2K3-05" strSrvalt="\\W2K-05"

Hi Marin, hab das Skript jetzt mal kommentiert. Darf ich fragen, in welchem Kontext die Projektarbeit steht? Achso und noch ein paar Links, die ich mir auf alle Fälle ansehen würde, sonst kommst du mit den Comments nicht weit: Hier kannst du die aktuelle Windows Script Doku herunterladen. Die ist wirklich gut verständlich und Klasse geeignet, um die VBS-Funktionen, wie Right, Instr usw. nachzuschlagen. Auch die Funktionsweise von DO LOOP und If Then findest du dort. Hier gibts die Doku zu ADSI, wobei ich mir lieber das gesamte Microsoft Platform SDK runterladen würde. Darin findest du auch viel Zeugs zu AD, LDAP usw. Und vor Allem hast du dann auch die Infos zu ADO, das ist das Zeugs, mit dem du die DB-Abfragen definierst. LDAP ist dir hoffentlich geläufig, ADSIEdit auch bekannt. Damit kannst du die Feldnamen im AD herausfinden. Außerdem hilft es, wenn dir Begriffe, wie Subtree, Onelevel usw. schon mal begegnet sind. Wenn nicht, dann schau dir mal DSQuery oder ldp.exe an. Da wird in der Hilfe einiges erklärt. Alternativ wieder Platform SDK. Zu den LDAP-Queries, oder LDAP Search Filter, wie sie ganz korrekt heissen: rfc 2254 Du kannst auch zum besseren Verständnis des Skripts an allen Stellen, wo eine Variable befüllt wird, diese in der nächsten Zeile mal mit msgbox variablenname ausgeben. Das trägt auch zum besseren Verständnis bei. Also z.B.: strDNSDomain = objRootDSE.Get("defaultNamingContext") msgbox strDNSDomain Ach und du solltest den Code bei Schleifen oder Ifs immer einrücken, das erhöht die Lesbarkeit. Gut, das sollte dann mal genügen. Ist letztendlich deine Sache, ob du dir das ansiehst, aber besser wäre es wahrscheinlich. Noch ein letzter Tipp Hier gibts zig fertige Scripts, Erklärungen, Beispiele, Tutorials usw. Gruß woiza

Wenn du den DC mit NTDSUtil sauber rauswirfst, kannst du ihn gerne als DC mit gleichem Namen neuinstallieren, kein Problem. Wenn du allerdings die alte Maschine, z.B. mit einem Backup wieder hochbringst, hast du doppelte FSMOs...

Hi, der Unterschied zw. seize und transfer: transfer macht das Gleiche, wie die GUI. Da das bei dir nicht tut, hilft dir auch transfer nix. Kurz gesagt nimmt transfer dem alten fsmo-Server die Rolle weg und gibt sie dem neuen. Ist der Server aber defekt und kann kein Übertrag mehr stattfinden, kannst du mit seize die Rolle gewaltsam übernehmen, aber nicht verschieben. Will sagen: wenn du den alten Rolleninhaber wieder hochfährst, hast du die Rolle doppelt, dann krachts! Beim RID-Master ist das besonders lustig.

Naja, mit SW-Entwicklung hat das auch wenig zu tun. Ich kanns dir aber gerne morgen kommentieren. Für dein eigenes berufliches Fortkommen würde ich dir aber dringend die Beschäftigung zumindest mit einer Skriptsprache empfehlen.

Vielleicht ist spät, aber wieso Hausaufgaben? :confused: Edit: ist wirklich spät, hab jetzt das Zitat gesehen. Naja, wenn's ne Hausaufgabe ist, wid er mit der Erklärung allein etwas im Regen stehen, weil er ja bei der ersten Nachfrage farbe bekennen müsste...

Hi, das Skript ist ja eher simpel. Ich kann dir das gerne kommentieren, allerdings sollte ich wissen, wofür du das ganze brauchst, bzw. was du damit bezweckst. Willst du das Skript verstehen oder sollst du es jmd. anderem erklären. Bin nicht neugierig, aber ich sollte ja schon wissen, ob der Adressat ne Ahnung von Skripting hat oder eher nicht. Gruß woiza

Bist du sicher, dass du es in der VM ausführst?

Hi, wenn du's nicht brauchst, würde ich mir C++ nicht antun. Die ganze Pointerei verwirrt zum Einstieg doch sehr. Und Mehrfachvererbung kapiere ich bis heute nicht... ;) Ich würde dir gleich Java oder C# empfehlen, wobei meiner Erfahrung nach die Erfolgserlebnisse mit C# schneller kommen. Gruß woiza Edit: Hier gibts ein Openbook zur Syntax. Da gibts auch noch ein etwas fortgeschritteneres oder alternativ ein gutes Javabuch, dito hier.

Das Tool wäre wohl Excel. Du musst die Namen in der 1. Zeile durch die Feldnamen ersetzen, also Nachname durch sn usw. Die entsprechenden Werte kriegst du z.B. über ADSIEdit oder, indem du nen Kontakt anlegst und mit csvde exportierst. Hier wieder der Hinweis auf Carlos. Auf der gleichen Seite kriegst du auch ein Makro, um die csv in Excel wieder abzuspeichern. Excel will nämlich immer Semikolon machen, du brauchst ür csvde aber Komma. Wenn noch Fragen sind, einfach Fragen... Gruß woiza

Deshalb: Der User, mit dem du das Skript ausführst, also im Normalfall der angemeldete, muss Adminberechtigungen auf dem entfernten Rechner haben. Es muss also der gleiche Benutzer mit gleichem Passwort auf der Remotemaschine existieren. Ist ja auch klar, sonst könnte ja jeder Dödel per Skript auf deinem Rechner sich nen Benutzer verschaffen. Erste Regel beim Skripten: Das Skript darf nur das, was der User auch so darf. Alternativ kannst du beim Skripten mit dem WinNT-Provider auch Creds übergeben: siehe auch: Technet Hier wäre folgender Codeschnipsel interessant: strComputer = "WinNT://atl-ws-01” strUser = "Administrator" strPassword = "4rTGh2#1" Set objDSO = GetObject("WinNT:") Set objComputer = objDSO.OpenDSObject _ (strComputer, strUser, strPassword, _ ADS_SECURE_AUTHENTICATION OR ADS_USE_ENCRYPTION) Falls noch Fragen sind, her damit! Gruß woiza

Man sollte mit NTDSUTIL in großen Strukturen nur darauf achten, dass man die Replikation abwartet, bevor man die Kiste mit gleichem namen wieder reinholt. Sonst gibts lustige Fehler mit dem SPN.

Für den MCSE würde ich NAT machen

Die Leiche macht dann Probleme, wenn die Kiste mit gleicem Namen wieder rein soll.

@squire (hat das was mit YES zu tun?) Die Seite kenn ich, mich hätte nur mal interessiert, ob es auch Zahlen für D gibt...

Hi, hast du auch Zahlen für 2003?

Hi, hast du die Express? Da war zu Beginn das Management Studio nicht dabei. In dem Fall kannst du es hier herunterladen. Gruß woiza

Hi, schau dir mal das und das an. Solltest du noch speziellere Rechte wissen wollen, meld dich einfach noch mal. Gruß woiza

Wie bekommst du denn die Liste? Als csv? Welche Werte stehen in der Liste zusätzlich zur Adresse noch drin?

Nö, 20 ist das Maximum. Gruß woiza

Ich kann nur wiederholen, was ich bereits geschrieben habe. Genau lesen und dann ist gut. So wie es aussieht gibts eben 2 Sims. Macht ja auch Sinn aus der Sicht von MS. Wenn sich einer vorher informiert und hört, dass in der GPO etwas einzustellen ist und er kriegt dann die andere, fällt er auf die Nase. Zumindest, wenn er nicht nachliest, sondern sich auf das verlässt, was er gehört. Und womit? Mit recht! Bei den DNS-Sims gibts ja auch Variationen...

Forceremoval entfernt das AD auf dem Server, ohne die Einträge im AD der anderen zu tilgen, grob gesagt. Wenn du dein AD danach bereinigst, kann nix passieren. Im Prinzip kannst du statt forceremoval auch die Maschine neu installieren, kommt aufs gleiche raus. Wenn du die Maschine aber wieder mit gleichem Namen reinholen willst, ohne die Bereinugung zu machen, dann knallts.