phoenixcp

Aarghh.... das hatte ich selber übersehen das das fehlte... is ja fast peinlich...

Und wenn es damit nicht ausreicht, dann hier noch eine Anmerkung aus den SQL Server Books online zu sp_password:

Es sieht so aus, als würde deinem Anwender das Recht auf die SP sp_password fehlen. Probier mal folgendes: GRANT EXECUTE ON sp_password TO <Username> [/Code] für einen deiner Anwender und mach dann nochmal den Test, ob sich das Passwort ändern lässt.

Reicht dir das als Info?

Kleiner Debugtip: Schreib dir mal den Inhal von cmd auf ne MessageBox raus und schau, was da raus kommt und setz das mal selber in einer Commandline ab und schau was dabei rauskommt.

Dann setz doch einfach statt des Feldes "distinguishedName" das Feld "cn" ein und frag einfach nur den CN des Computers ab. Wie wäre es damit? :D

Und an was scheitert es im Moment?

Probier mal folgende Zeile: cmd = "net send %computername% " & Nachricht [/Code]

Hast du noch nen Link für's Merkbrett? :) Der Mensch lernt nie aus...

Entspricht denn dein Username dem CN? Oder eher dem samName? Probier mal folgendes Statement aus: dsquery user domainroot -samid %username% -gc [/Code] -name geht auf den CN -samid auf den samName mehr dazu auch hier: Microsoft Corporation

Das sollte kein Angriff sein, deswegen ist auch ein Smily dahinter... Hoffe das dir die ADSI-Scriptomatic ein wenig weiterhilft. Ansonsten meld dich einfach nochmal...

In dem Fall würde ich das ganze folgendermaßen probieren: dim cmd cmd = "net send " & computername & " " & Nachricht wshshell.run(cmd) [/Code] Dann musst du nur noch dafür sorgen, das die Variablen computername und Nachricht belegt sind...

WSHShell.Run(<cmd Befehl>) [/Code] Mehr Infos dazu hier: Run Method (Windows Script Host)

Siehst du überhaupt irgendwelche Inhalte aus deiner Domäne bei der Suche?

Also ich / wir gehen momentan davon aus, der er alle deaktivierten User sauber mit dem Flag "hideFromAdressbook" versehen hat und diese im Adressbuch nicht mehr sichtbar sind. Lediglich im LOKALEN Adresscache des Outlookclients sind diese noch vorhanden. Das hat aber auch nix mit dem Cachemodus zu tun...

STOP Was hat denn der Exchange Cache Modus mit dem Adressspeicher zu tun? Quelle: Outlook FAQ

Hast du trotzdem mal die Treiberversionen verglichen und gegebenenfalls angeglichen?

Bist du als lokaler Administrator angemeldet oder als Domänenadmin? Ist der Server Mitglied der Domäne oder ein Stand-Alone-Server?

So, war das dann die endgültige Entscheidung oder entscheidest du dich nochmal um? :-) Aber hier mal was zum selber spielen: ADSI (Active Directory Service Interfaces) Scriptomatic Damit lässt sich das AD-Skripting von "fast" alleine bewerkstelligen...

Wo suchst du denn die Administratoren? Lokal auf dem Server oder in deinem AD? Gibt es die Gruppe dort?

Quelle: MSXFAQ.DE - Exchange Installationsmatrix

Ok... also was ist jetzt die Klasse und was das Attribut???? Dein erstes Posting: erst: dann: Off-Topic:Wenn, dann ist das Attribut Bestandteil der Klasse und nicht andersherum... dann: Also: die Objektklasse scheint enatelSoftwareVersion zu sein Was ist denn nun das Attribut was du Abfragen willst?

Off-Topic: Jetzt beschweren sich die Leute schon, wenn der Spam ausbleibt... Freu dich doch einfach drüber und nimm es hin...

das hab ich schon so verstanden...

Was für ein Exchange? 2000? 2003? 2007? Welcher Patchlevel? Welches OS unten drunter? Was geht denn nicht mehr? Welche Fehler meldet er? Was sagen die Eventlogs?