P.Foeckeler

Heyho, in Deinem Fall könntest Du also mit diesem Kommando nach dem Namen Der betreffenden GPO-GUID suchen: dsquery * -filter "(name={4e558f9f-a7cf-4c60-95ef-f2c503201c88})" -attr displayName ...oder, wenn du gleich alle GPOs auf einmal sehen willst, dann nimm den hier: dsquery * -filter "(objectClass=groupPolicyContainer)" -attr name displayName Ein LDAP-Browser, mit dem man sich das auch optisch "ansprechend" in einer Liste darstellen lassen kann, ist LEX - The LDAP Explorer: www.ldapexplorer.com :D...wenn man sehen möchte, an welche Container die GPOs verlinkt sind, dann verwendet man einfach den LDAP Filter hier: (gPLink=*) Gruß, Philipp

Hmm, dann wird's schwierig. Ich hätte da keine Idee, wie man Deinen Wunsch umsetzen könnte... Sorry. Wenn ein Client mit verschiedenen NET USE - Verbindungen auf ein zentrales Laufwerk zugreift, kann der File-Server ja in den BErechtigungen nicht mehr unterscheiden, von wo und über welche Tehnik der betreffende User angemeldet ist... Gruß, Philipp

Hallo, also das ist bestimmt nicht die entgültige Lösung, aber es gibt das Wellknown-Princple "TERMINALSERVERBENUTZER" (keine echte Gruppe, sondern da ist jeder automatisch drin, der über am Terminalserverdienst angemeldet ist, damit sind doch alle RDP-Clients eingeschlossen, oder nicht??) Diese vordefinierte "Gruppe" könntest Du verwenden, um die zusätzlichen Rechte zu vergeben. Problem: In dieser "Gruppe" ist halt jeder drin über RDP, also wenn du die Rechte für einzelene Benutzer unterscheiden willst, dann geht's vielleicht auch so: Gib die Rechte zum Ändern/Lesen/Löschen spezifisch für die jeweiligen Benutzer User, verweigere aber zusätzlich im betreffenden gesamten NTFS-Bereich dem Wellknown Prinicpal "NETZWERK" alle Rechte außer "Schreiben"...das müßte doch darin münden, dass alle, die über ein NET USE an das Laufwerk kommen, nix dürfen außer schreiben, über RDP (da sind sie ja lokal an dem Laufwerk und nicht über NET USE verbunden) dürfen Sie dann alles. Ist nur so eine Idee, ich komme auch gerade nicht dazu, es auszuprobieren...:confused: Gruß, Philipp

Zu 2.) Die Daten mit einem XCopy oder Robocopy zu übertragen ist zwar super einfach, aber da gehen die Berechtigungen des NetWare-Filesystems verloren. Du mußt dir also bei der Übertragung der Benutzer und Gruppen eine Art Mapping-Tabelle machen, anhand der Du dann bei den übertagenen Daten die Berechtigungen entsprechend wieder setzen kannst (z.B. mit SETACL.EXE oder XCACLS.EXE). Aber Vorsicht, die Übertragung und das Setzen der Berechtigungen muß in einem Rutsch geschehen, denn Du kannst ja schlecht die Benutzer gleichzeitig noch auf den alten und den kopierten neuen Daten rumorgeln lassen. Also wenn das zu viele Daten werden um Sie mal schnell an einem Tag zu kopieren (ich habe bei entsprechenden Scripten schon erlebt, dass alleine das Setzen der Berechtigungen mehr als einen Tag dauert...), dann mußt Du dies in einer sehr sorgfältigen Planung in eizelnen Schritten (ein Volume nach dem anderen, ein Login-Script-Mapping-Bereich nach dem anderen oder so...) Zu 3.) Die Benutzer, die vorher vielleicht einen Novell-Dynamic Local User oder ähnliches verwendt haben, um sich an Ihren Stationen anzumelden, tun das jetzt mit ihrem neuen AD-Account. Dafür mußt du die stationen alle in deiner AD Domäne zum Mitglied machen (z.B. mit NETDOM.EXE). Allerdings willst Du ja vielleicht auch, dass die User Ihre alten Profil-Einstellungen nicht verlieren, das ist kompliziert und macht dann auf jeder einzelnen Station Arbeit (hier hilft vielleicht der User State Migration Wizard...) Sodele, ich hoffe dabei ist rausgekommen, dass einem das ganze ohne entsprechende Erfahrung auch schnell über den Kopf wachsen kann. Es gibt im Pinzip zwei Tools, die sich um die ersten beiden der hier angesprochenen Probleme kümmern: Die Microsoft Services for NetWare mit zwei Utilities: - Microsoft Directory Synchronization Services (MSDSS) und - Microsoft File Migration Utility (FMU) Microsoft Windows Server 2003: Microsoft Windows Services for NetWare 5.03 Von Novell NetWare zu Windows Server 2003 - Lösungshandbuch für die Migration von Datei-, Druck- und Verzeichnisdiensten (Teil 2: Aufbau) Quest NDs Migrator Active Directory Migration with NDS Migrator - a Novell Directory Services Migration Tool from Quest Software Im Prinzip taugen beide nur für überschaubare Umgebungen, das Microsoft SFN ist wenigstens kostenlos. Viele Grüße, Philipp

Hallo Norman, nachdem ich den anderen erstmal etwas zustimmen muss, dass Du Dir da ganz schön was vorgenommen hast, möchte ich aber trotzdem mal ein paar fachliche Hinweise geben... :) Es kommt ja auch immer darauf an, wie komplex die Umgebung wirklich ist, die Du da migrieren willst. Nehmen wir uns mal eine derartige Migration Novell->Microsoft vor. In erster Linie hat man dabei zwei Hauptaufgaben: 1. Du mußt die Benutzerkonten inklusive Gruppen und Gruppenzugehörigkeiten vom eDirectory ins AD ziehen. 2. Du mußt Dateien von einem NetWare-Filesystem auf einen Windows-Fileserver kopieren, damit Sie von da aus dann den AD-Usern zur Verfügung stehen. 3. Du mußt Arbeitsstationen in deine AD-Zieldomäne hieven, d.h. sie dort zu Domänenmitgliedern machen, damit sich die Benutzer dann auch am AD anmelden können. Alles andere lassen wir jetzt mal außen vor. In der Praxis kommen vielleicht noch irgendwelche spezielen Services dazu, die unter NetWare implementiert waren und die Du dann unter Windows/AD auch irgendwie wieder bieten mußt, z.B. NetWare DFS->Windows DFS, NetWare PKI->Windows CAs, Druckdienste oder ganz zu schweigen von einem GroupWise-Mailsystem->Microsoft Exchange... Du siehst es kann also noch beliebig kompliziert werden. Bleiben wir also lieber bei den Hauptaufgaben: Zu 1). Die User zu übertragen mit einem einfachen Export und Import von Hand (z.B. in CSV-Dateien mit dem CSVDE.EXE) kannst du nur, wenn du die CSV-Dateien vor dem Import anpasst, und dabei mußt du wissen was du tust, denn z.B. unterscheiden sich Objektklassen und Attributnamen von eDirectory nach AD, du kannst also nicht einfach sagen "Datei raushauen und drüben wieder reinhauen". Du mußt die Export/Import-Dateien also auf jeden Fall bearbeiten...bei ein paar Usern geht das ja noch von Hand, aber sonst? Die Passwörter gehen z.B. auf jeden Fall verloren, auch andere Eigenschaften wie Anmeldebeschränkungen oder auch Login-Scripte sind nicht ganz einfach zu handhaben, weil sie eben nicht 1:1 übertragbar sind. Es muß aber gewährleistet sein, dass Gruppenmitgliedschaften und Login-Script-Laufwerksverbindungen wieder stimmen, ansonsten stimmen später die Verbindungen und Berechtigungen auf die Daten nicht mehr (und das ist nicht ganz unwichtig für den reibungsfreien Ablauf!!!!!) :p Womit wir gleich beim nächsten wären: (Fortsetzung folgt...)

Yep, war ein Schreibfehler, sorry :shock: Natürlich heißt es immer DC=ForestDnsZones,DC=rootdomain,DC=com DC=DomainDnsZones,DC=rootdomain,DC=com Gruß, Philipp

Doch, ich habe noch eine Idee :cool: Also, was Du brauchst sind erstmal Rechte in allen AD-Partitionen, die in Deiner AD-Replikation ein Rolle spielen. Nicht nur Domänen-Partition und Configuration plus Schema, sondern auch die Application Partitions, in denen evtl. DNS-Daten gelagert werden (deshalb auch Deine Fehlermeldung mit DomainDnsZones...) Wenn Deine domäne also "dom.tld" heißt und Dein Forest aus dieser einen Domäne besteht, dann brauchst du Rechte in DC=dom,DC=tld DC=Configuration,DC=dom,DC=tld DC=Schema,DC=Configuration,DC=dom,DC=tld DC=ForestDnsZones,DC=Configuration,DC=dom,DC=tld DC=DomainDnsZones,DC=Configuration,DC=dom,DC=tld die Rechte werden an eine globale Gruppe vergeben, sagen wir sie heißt "RepOperators". Wenn du AD-Replikationen anstoßen willst, benötigst Du nun spezielle Rechte, so genannte Extended Rights oder auch Control Access Permissions. Die sind intern im AD definiert, wer schonmal in einer Exchange-Umgebung die "SendAs" und "ReceiveAs" Rechte gesehen hat: Das sind ebenfalls Control Access Rights. Oder das Recht "ChangePassword". Naja, bei uns ist es etwas komplizierter: Du brauchst diese drei Rechte hier: Replication Synchronization Replicating Directory Changes Replicating Directory Changes All Bei den letzten beiden bin ich mir nicht ganz sicher, ob die tatsächlich benötigt werden, ich persönlich nehme Sie immer dazu, klingt ja auch irgendwie logisch. Außerdem ist noch sinnvoll, das Recht Monitor Active Directory Replication für Deine Gruppe zu setzen, dann können Sie später auch REPADMIN /showrep und ähnliches veranstalten... Also, dann mal los. Du setzt das ganze besser mit DSACLS-Kommandos auf der Eingabeauffordernug an einem DC, und zwar als Enterprise-Admin! DSACLS DC=dom,DC=tld /I:T /G DOM\RepOperators:CA;"Replication Synchronization" DSACLS DC=dom,DC=tld /I:T /G DOM\RepOperators:CA;"Replicating Directory Changes" DSACLS DC=dom,DC=tld /I:T /G DOM\RepOperators:CA;"Replicating Directory Changes All" DSACLS DC=dom,DC=tld /I:T /G DOM\RepOperators:CA;"Monitor Active Directory Replication" DSACLS DC=Configuration,DC=dom,DC=tld /I:T /G DOM\RepOperators:CA;"Replication Synchronization" DSACLS DC=Configuration,DC=dom,DC=tld /I:T /G DOM\RepOperators:CA;"Replicating Directory Changes" DSACLS DC=Configuration,DC=dom,DC=tld /I:T /G DOM\RepOperators:CA;"Replicating Directory Changes All" DSACLS DC=Configuration,DC=dom,DC=tld /I:T /G DOM\RepOperators:CA;"Monitor Active Directory Replication" ...und dann das gleiche noch für die drei anderen Partitionen. Ächz, mir ist ganz schwindlig...jaja o kommt's wenn man so komplizierte Wünsche hat :p Wenn Du noch mehr über spezielle Delegation im AD wissen willst, hier gibt's Anregungen: Microsoft Best Practices Whitepaper for Delegating Active Directory Administration Viele Spaß beim Replizieren, Philipp

Und wenn du nicht weißt, welche technischen Attribute hinter den Feldern in "AD Users and Computers" stecken, die du löschen willst: Beschreibungen für die Felder im Windows 2003 AD Users and Computers: http://www.selfadsi.de/user-attributes-w2k3.htm Beschreibungen für die Felder im Windows 2008 AD Users and Computers: http://www.selfadsi.de/user-attributes-w2k8.htm Beschreibungen für die Felder in Exchange 2007 Management Console: http://www.selfadsi.de/attributes-e2k7.htm#UserAttributes Gruß, Philipp

Hallo Nils, mit Get-Content wird leider ebenfalls die gesamte Datei ausgelesen, deswegen dauert es so lange (Get-Content bringt immerhin als Ausgabe ein Array mit allen Zeilen der Datei....). Du mußt das schon direkt mit einem .NET FileStream oder was ähnlichem anpacken. Da kannst Du den Lese-Zeiger direkt aufs Ende setzen und gehst dann zurück, bis du zum erstem Ml auf Character 10 (Line Feed) triffst, das wäre dann der letzte Zeilenumbruch, von da ab liest Du dann die Zeile. So wird von der Datei wirklich nur die letzte Zeile gelesen. Allerdings ist der Powershell-Code sehr häßlich, weil wie gesagt ein .NET-Objekt benutzt werden muß. Hier ein möglicher Code-Entwurf (es gibt wahrscheinlich noch Probleme, wenn die Datei von einem anderen Programm gerade exklusiv geöffnet ist...): $path = "C:\test.txt" $reader = New-Object System.IO.StreamReader($path, $true) [long]$pos = $reader.BaseStream.Length - 1 while($pos -gt 0) { $reader.BaseStream.Position = $pos if ($reader.BaseStream.ReadByte() -eq 10) {break} $pos-- } $line = $reader.ReadLine() $reader.Close() $line Das gibt die letzte Zeile aus. Auch wenn diese eine Leerzeile ist. Um die letzte nicht-leere Zeile zu bekommen, müßte man ein bisschen was ändern... Gruß, Philipp

Hallo, ich nochmal. Blub hat Rech, Dein Fehler hat mit nix mit GetEx() zu tun, sondern mit dem fehlenden 'Set' in der zweiten Zeile (siehe Code unten). Sorry. Hab's grad probiert... Ohne das Set erzeugt er kein ADSI-Objekt, und dadurch hat er er dann keine Interface-Properties "objLastLogon.HighPart" und "objLastLogon.HighPart", die du weiter unten verwendest. So wie ich das sehe macht zu allem Überfluß der Script-Code, den Du verwenden willst, auch einen Berechnungsfehler. Die Lowpart-Anteil des Large Integers kann nämlich so groß werden, dass VBScript denkt, es wäre ein negativer Wert (im Script gibt es halt keine "Unsigned Integers"....). Da fehlt einfach noch das hier Set objUser = GetObject("LDAP://cn=username,dc=yourdomain,dc=com") [b][color="Red"]Set[/color][/b] objLastLogon = objUser.Get("lastLogonTimestamp") [b][color="Red"]i8High = objLastLogon.HighPart i8Low = objLastLogon.LowPart If (i8Low < 0) Then i8High = i8High + 1 End If[/color][/b] intLastLogonTime = i8High * (2^32) + i8Low intLastLogonTime = intLastLogonTime / (60 * 10000000) intLastLogonTime = intLastLogonTime / 1440 Wscript.Echo "Last logon time: " & intLastLogonTime + #1/1/1601# Ansonsten war der Link http://www.selfadsi.de/ads-attributes/user-lastLogonTimestamp.htm eigentlich schon ein Volltreffer, brauchst nicht im Script-Repository zu suchen, sondern da steht genau das Beispielscript, das Du brauchst... Viele Grüße noch, Philipp

Heyho, Der LDAP-Filter, der auch die deaktivierten Benutzer ausschließt, lautet so: (&(objectCategory=person)(whenCreated>=20060401000000.0Z) (!(homeDirectory=\\cluster1*))(!(userAccountControl:1.2.840.113556.1.4.803:=2))) Das mit dem "1.2.840.113556.1.4.803" bedeutet, dass man alle Objekte sucht, die in dem Attribut "userAccountControl" das 2. Bit nicht gesetzt haben. Eine gute Beschreibung zu diesen "Bit-Feld-Filtern" (neben dem Whitepaper, das Nils schon gepostet hat), findest du auch hier: http://www.selfadsi.de/ldap-filter.htm#BitAndOr und entsprechende Beispiele hier: http://www.selfadsi.de/ldap-filter.htm#FilterADS Nebenbei erwähnt: Wenn du eine Domäne mit sehr vielen Objekten durchsuchst, dann ist dieser Filter hier besser (=schneller) für dich, da er auch nach Benutzern sucht, das Attribut "samAccountType" intern aber schneller durchsucht werden kann als "objectCategory" :cool:: (&(sAMAccountType=805306368)(whenCreated>=20060401000000.0Z) (!(homeDirectory=\\cluster1*))(!(userAccountControl:1.2.840.113556.1.4.803:=2))) Viele Grüße, Philipp

Heyho, dein Fehler kommt, weil du entweder GetEx() anstatt Get() verwenden solltest, um lastLogonTimestamp auszulesen. Oder du erzeugst in der zweiten Zeile mit [b]set [/b]objLastLogon = objUser.Get("lastLogonTimestamp") ein ADSI-Large Integer Object... Dann sollte der Laufzeitfehler nicht auftreten. Ich glaube die Beschreibung zu lastLogonTimestamp im SelfADSI Tutorial sollte Dir weiterhelfen. Dort gibt es auch ein Beispielscript für eine Suche nach Objekten, deren lastLogonTimstamp-Wert älter als 6 Monate sind. Dazu muß ein LDAP-Filter erzeugt werden, aber das ist dort alles sehr gut erklärt... :D Gruß, Philipp

Hallo, hast du vielleicht vergessen, Euren neuen WINS-Server in der TCP/IP-Konfiguration der beiden Informix-Server anzugeben? Denn nur dann tragen die beiden sich dort ein und werden von den Clients gefunden... Gruß Philipp

Hallo Frank, es ist eine fest eingebaute Eigenschaft der Windows Permissions (auf Dateien/Verzeichnisse/Drucker/Registry/Ad-Objekte...), dass der Owner stets die ACL (Access Control List => Rechteliste des jeweiligen Objektes) ändern darf, völlig unabhängig davon, welche Rechte in der ACL festgelegt wurden. An diesem Verhalten des Systems kannst du nix ändern.... :cry: Du könntest für bestehende Daten vielleicht im Nachhinein den Owner ändern (z.B. mit Tools wie SetACL), aber für Verzeichnisse und Dateien, die gerade erstellt wurden, kannst du nix machen.... Gruß, Philipp

Hallo, wenn Domänencontroller merken, dass eine Enterprise CA da ist, dann fordern sie Zertifikate an, um LDAPS (LDAP über SSL) Verbindungen anbieten zu können. Was das EFS anbelangt, so ist es nichts was du direkt installierst, vielmehr ist das Encryptet File System ein integraler Bestandteil von NTFS, d.h. für die dortigen Verschlüsselungsmöglichkeiten werden Zertifikate angefordert, auch wenn du die Verschlüsselung garnicht benutzt (die ließe sich in den erweiterten Attributen deiner Verzeichnisse und Dateien aktivieren). Gruß, Philipp

Hallo, wenn's Dir nur darum geht, warum Dein Script nicht läuft...hier ist eine Variante für Dich, probiers mal damit. On Error Resume Next strCN = "Gruppenname" Set objConnection = CreateObject("ADODB.Connection") Set objCommand = CreateObject("ADODB.Command") objConnection.Provider = "ADsDSOObject" objConnection.Open "Active Directory Provider" Set objCommand.ActiveConnection = objConnection objCommand.CommandText = _ "<LDAP://DC=intra,DC=firmenname,DC=de>;(sAMAccountName=" & strCN & ");[color="Red"]description[/color];subtree" Set objRecordSet = objCommand.Execute objRecordSet.MoveFirst [color="Red"]strDescription[/color] = objRecordSet.Fields("[color="Red"]description[/color]").Value MsgBox [color="Red"]strDescription[/color] Der Fehler bei Dir lag übrigens daran, dass 1. Du als Ergebnis der Suche (das kam im 'objRecordSet') in die Variable 'strADsPath' geschrieben hast, dann aber versucht hast, eine nicht deklarierte und auch vorher nie benutzte Variable 'ADSPath' auszugeben... ('MsgBox ADSPath'); und 2. Du versucht hast, nicht die Description, sondern den gesamten LDAP-Pfad der betreffenden Gruppe ausgeben zu lassen. Das Attribut das Du wolltest, heißt intern tatsächlich auch 'description' :) Ansonsten habe ich eine etwas andere Syntax bei der Abfrage verwendet, nicht den SQL-Style, sondern die LDAP-Syntax, die von einer solchen ADO-Suche auch unterstützt wird. Dabei kann man den Parameter 'Subtree' (der sagt dass in der gesamten domäe in allen OUs gesucht werden soll) direkt mit übergeben... Deinen "PageSize"-Parameter habe ich auch weggelassen, den braucht man nur, wenn man als Ergebnis der Suche sehr viele Objekte erwartet (bei uns ja nur die eine Gruppe) Eine genaue Anleitung für derartige LDAP-Suchen findest du im SelfADSI LDAP Script Tutorial http://www.selfadsi.de/search.htm Und eine Übersicht, wie die technischen Attribute von Gruppen heißen, wenn man sie in solchen Suchen verwenden will: http://www.selfadsi.de/group-attributes-w2k3.htm Gruß, Philipp

Hallo, schau mal, hier gibt's ein großes Beispielscript zur Excel-Fernsteuerung, du siehst unter anderem, wie du neue Sheets erstellen kannst oder auch Sorierung und Autofilter von VBScript aus benutzt: CerroTorre Networking - FAQ - Excel-Dokumente erzeugen per VBScript Gruß, Philipp