CyberDoc

Da niemand eine Antwort geben konnte, hab ich es jetzt mal selbst gelöst ^^ Nach ein wenig suchen habe ich herausgefunden, dass dem Prozess der Namensauflösung ein hartgecodeter Timeout vorgegeben ist. Wenn die Domaincontroller nicht innerhalb einer bestimmten Zeitspanne antworten, läuft der Client in diesen Timeout und die Auflösung schlägt fehl. Deswegen auch das "Geht - geht nicht - geht wieder" Verhalten. Manchmal waren die AD-Server nicht so stark belastet, dann kamen die Antworten zügig oder der Verteiler war nicht so groß, dann ging es auch. Wir haben die Auflösung nun auf performantere Domaincontroller umgebogen und siehe da, es läuft alles. Der Teufel liegt immer im Detail ;) Ich hoffe das hilft dem Einen oder Anderen der auch in dieses Problem läuft. Grüße Cyber

Hallo Jungs (und Mädels falls vorhanden), ich habe folgendes Problem: Wenn ein User eine Mail an eine Verteilerliste schicken will und er sich dabei die Verteilerliste auflösen lassen möchte (auf das + klicken um zu sehen an wen die Mail dann gesendet wird), kann Outlook die Liste nicht auflösen. Der User bekommt den Fehler: "Der gewünschte Vorgang konnte nicht ausgeführt werden. Der ausgewählte Befehl ist für diesen Empfänger nicht gültig. Fehler beim Ausführen der Operation." Das ist aber leider (oder zum Glück) kein generelles Verhalten. Manchmal klappt es einfach, manchmal nicht und manchmal klappt es, nachdem man einen anderen Verteiler mit weniger Usern aufgelöst hat. Weiterhin ist es client- und standortunabhängig. Also egal von welchem Client, an welchem Standort und unabhängig von der verwendeten Outlook Version, das Phänomen ist das Gleiche. Einzige Gemeinsamkeit ist, dass die User auf Exchange 2010 liegen und auf die gleichen CAS zugreifen (über HW-Loadbalancer verteilt auf einen der vier CAS). Aufgefallen ist das Ganze, nachdem User von Exch2003 auf Exch2010 verschoben wurden. Als sie auf 2003 lagen soll es funktioniert haben. Kann jemand Licht ins Dunkel bringen und mal skizzieren wie die Auflösung von Verteilerlisten auf technischer Seite funktioniert? Also wer fragt wen auf welchem Weg? Danke schon mal im Voraus. Gruß Cyber

Ich habe mir jetzt die Möglichkeiten mal angesehen, hilft aber leider nicht. Die beiden Varianten über die Delivery Restriction (MaxMessageSize=0 oder nur Mails von sich selbst/TempUser) sind die aktuell hier verwendete Lösung. Mit dem Nachteil das alle zur löschung markierten (deaktivierten) User keine Mails mehr bekommen. Versehentlich deaktivierte User die dann auf Anfrage wieder reaktiviert werden verlieren somit alle Mails aus dieser Zeit. Das ist so nicht gewünscht. Um das zu verhindern müssen wir im Moment unter den zu deaktivierenden Useraccounts diejenigen der Funktionsuser raussuchen. Das ist leicht wenn sie neueren Datums sind, denn dann greift die aktuelle Naming Rule "FU-Name". Je nachdem wie lange dieser Account schon besteht und welches Department ihn erstellt hat können die jedoch z.B. auch als "beamer01.ManagementMeetingRooms" oder so ähnlich benannt sein. Das lässt sich dann nur noch händisch abfangen. Könnte man gescriptet allen Userkonten bei der Deaktivierung einen Autoresponder verpassen, kämen die Mails trotzdem an und alles wär gut. Ob man sowas per GPO setzen kann?! Die Accounts landen ja nach dem deaktivieren alle in der gleichen OU (recycler).

Danke, Norbert, für die Tipps und auch für die super schnelle Responsezeit. Ich schau mir die Info´s gleich mal an und geb dann Rückmeldung. Gruß Cyber

Ja die werden auch als Ressource genutzt. Zum einen als Teamkalender zur Eventplanung, als auch als Reservierung für Räume, Beamer etc. sowie als Mail-Verteilerliste. Für eine fiktive Ressource "Hüpfburg" sieht das dann ungefähr so aus: Im AD gibts einen Funktionsuser "FU-Hüpfburg", mailenabled und im Exchange als Ressource verwaltet. Die Nutzer reservieren die Ressource indem sie Terminrequests an den FU schicken und dieser antwortet dann automatisch. So weit so gut. Wenn nun die Hüpfburg platzt, wird der User im AD disabled und in eine andere OU verschoben. Unbeeindruckt davon können die Nutzer aber weiterhin Teminrequests schicken und bekommen auch fein brav Zusagen vom Exchange. Sie bekommen also nicht mit das der User deaktiviert ist. Deaktivierte User werden nach 60 Tagen inkl. des Exchangepostfachs gelöscht. Dann ist das Geschrei groß... gerade wenn es sich um eine Verteilerliste handelt. Was ich möchte ist, dass die Nutzer mitbekommen wenn ein User, aus welchen Gründen auch immer, deaktiviert wurde. Dann könnten sie nämlich INNERHALB der dafür vorgesehenen 60 Tage noch den Finger heben und reaktivierung beantragen. Könnte man... Jedoch handelt es sich um eine Domäne mit mehreren tausend Usern in einem Forrest mit noch wesentlich mehr tausend Usern und zwölfunddrölfzig Exchangeservern. Ich kann nicht sicher sagen ob es nicht irgendwo doch einen SUPERHEFTIG-wichtigen, deaktivierten User gibt der Mails bekommt und die auch unbedingt weiterhin bekommen soll. ;) Das sicher auszuschließen könnte doch mehrere Schaltjahre dauern und es einfach auszuprobieren und nachher "sorry, i just tried to do this and that" zu sagen, kostet mich sicher mehr als ein "Vater unser" und 12 Rosenkränze. :)

Folgendes Problem: Kurz und bündig: Ich möchte bei ausgewählten AD-Usern via Script einen Email-Autoresponder setzen. Hintergrund: Wir haben Funktionsuser im AD, die nur dazu dienen um Mailboxen für Mailingaktionen, Raumbelegung oder Events bereitzustellen. Standardmäßig werden diese User nach Ende der Aktion oder nach Ablauf einer bestimmten Zeit bzw. Auflösung eines Projektteams deaktiviert und nach einigen Monaten gelöscht. Da sich die Nutzer dieser Mailboxen ja nie mit diesen Accounts anmelden, bekommen sie von der Sperrung auch nichts mit. Sie senden fröhlich weiter Mails an die Mailbox um z.B. Räume zu buchen etc. und wundern sich dann irgendwann das der Account gelöscht ist. Ich wollte nun bei der Deaktivierung einfach einen Autoresponder einrichten, der die Nutzer über die Deaktivierung informiert. Da es sich immer um eine größere Anzahl Userkonten handelt, wäre es am sinnvollsten, das via Script zu erledigen. Hat da schon jemand Erfahrung mit? Geht das überhaupt? (Powershell ist aktuell via Firmenpolicy nicht erlaubt, könnte man aber nutzen wenn es nur damit geht) Gruß und Dank im Voraus Cyber

Ich habe mir den Link mal angesehen und finde ihn vielversprechend. Mein Problem ist aber, dass ich mit ADO Objekten nichts am Hut habe. Deswegen könnte ich bezüglich der endgültigen Syntax nur herumraten. Hat jemand schnelle Finger und kann das Script aus dem Link an mein Script anpassen bzw. einfügen? Vielleicht wagt sich ja auch nochmal jemand an das MS beispielscript, was ich oben angehängt hatte. Das sah auch gut aus, aber ich bin an der Anpassung gescheitert. Irgendwie raff ich´s nicht. Ich kann nur rumraten. Vielleicht nur zur Info: 1. Ich kann auch im AD (manuell) die Einwahlberechtigung nicht auf "Zugriff über RAS Richtlinie steuern" setzen, denn der Bereich ist ausgegraut. Weshalb auch immer. 2. Die User liegen in einer eigenen OU. Kann es vielleicht damit zusammenhängen? Wär toll wenn wir es zusammen hinbekommen würden. :D

Danke erstmal... Jetzt brauche ich erstmal ein paar Erfolgserlebnisse, deswegen geh ich vorerst ne Weile sinnvolleren Beschäftigungen nach. z.B. Azubis quälen :D Ich schau mir das heute Nachmittag nochmal an und werd dann mal sehen, ob ich das hinbekomme. Vielleicht schrei ich dann nochmal um Hilfe.

Ja nee! ;) Fehlermeldung... Fehler: Typen unverträglich: 'p.PutEx'

Ich dreh hier ab. :D Null Wirkung. Weder direkt nach dem "objekt.SetInfo" noch nach einem erneuten "GetObjekt" ... b.SetInfo Const ADS_PROPERTY_CLEAR = 1 Const ADS_PROPERTY_UPDATE = 2 Const ADS_PROPERTY_APPEND = 3 Const ADS_PROPERTY_DELETE = 4 b.PutEx ADS_PROPERTY_CLEAR, "msNPAllowDialin", 0 b.SetInfo cn = Klasse &" "& Vorname &" "& Nachname objGroup.Add ("LDAP://cn=" & cn & ",OU=Hotspotuser,DC=MMBBS-WLAN,DC=local") Set p = GetObject("LDAP://cn=" & cn & ",OU=Hotspotuser,DC=MMBBS-WLAN,DC=local") p.Put "msNPAllowDialin", True p.SetInfo ... Kann das denn so schwierig sein? :suspect:

Ich habe es in wildem Eifer einfach mal reinkopiert und ausgeführt ohne wirklich zu wissen was ich damit bewirke. Läuft durch, bewirkt aber nichts. Script sieht dann wie folgt aus. ... Sub BenuntzerAnlegen(Benutzer,Vorname,Nachname,Passwort) Dim ouo, b, objGroup Set ouo = GetObject("LDAP://OU=Hotspotuser,DC=Domäne,DC=local") Set objGroup = GetObject("LDAP://cn=Hotspot-Benutzer,OU=Hotspotuser,DC=Domäne,DC=local") Set b = ouo.Create("user", "CN=" & Klasse & " " & 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 & "@Domäne.local" Const ADS_PROPERTY_CLEAR = 1 Const ADS_PROPERTY_UPDATE = 2 Const ADS_PROPERTY_APPEND = 3 Const ADS_PROPERTY_DELETE = 4 b.PutEx ADS_PROPERTY_CLEAR, "msNPAllowDialin", 0 b.Put "msNPAllowDialin", True b.SetInfo ... Ohne die Zeile "b.Put "msNPAllowDialin", True" endet das Ganze in einer Fehlermeldung wegen Bereichsverletzung.

Das Script läuft auf einem Windows Server 2k3 R2 Standard Edition incl. SP2 und ich hab True ohne "" angegeben. Mit "" hab ichs auch versucht. Zeigt alles keine Wirkung. Ich habe das Gefühl, der Wert hat auf die Einstellung im AD keine Wirkung, denn das Script läuft ja ohne zu meckern durch. Ob sich die User dann faktisch trotzdem einwählen dürfen, hab ich natürlich nicht getestet. Wär mir aber ein Rätzel, wenn das gehen sollte?!

Erstmal Danke für die schnelle Antwort. Das führt zum gleichen Ergebnis. Script läuft sauber durch, User wurden angelegt, aber die Brechtigung zum Einwählen steht noch immer auf "Zugriff verweigern". Auch die Schreibweise des Attributes ändert nix (TRUE, True, true) Ich habe in einem Script von MS folgende Zeile gefunden, die angeblich genau das bewirken soll. objObjectSDO.PutProperty SDO_REMOTE_ACCESS_PERMISSION, true Da ich aber kein Scripting-Guru bin, bekomme ich es nicht zum Laufen. Keine Ahnung wie ich dieses "objObjectSDO" erzeuge?! Ich habe das Beispielscript von MS mal angehängt. Vielleicht kannst du mir sagen, wie die genaue Syntax in meinem Fall aussehen müsste?! Bitte Bitte :D Danke Script.zip

Hi Leute, ich benutze ein VBscript um User im AD anzulegen. Diesen Usern möchte ich gleichzeitig auch die VPN einwahl erlauben. Die Benutzer werden auch schön sauber erstellt. Nur die Einwahlberechtigung wird nicht gesetzt. Wenn ich mir nachher die erstellten User ansehe, ist die RAS Einwahlberechtigung noch immer auf "Verweigert". Hier ist der betreffende Codeabschnitt. Sub BenuntzerAnlegen(Benutzer,Vorname,Nachname,Passwort) Dim ouo, b, objGroup Set ouo = GetObject("LDAP://OU=Hotspotuser,DC=MMBBS-WLAN,DC=local") Set objGroup = GetObject("LDAP://cn=Hotspot-Benutzer,OU=Hotspotuser,DC=Domäne,DC=local") Set b = ouo.Create("user", "CN=" & Klasse & " " & 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 & "@Domäne.local" b.Put "msNPAllowDialin", "TRUE" 'das sollte funktonieren, tut es aber nicht!!! b.SetInfo b.SetPassword Passwort b.AccountDisabled = False b.SetInfo Hab ich was vergessen? Hat jemand eine Idee? Müssen vielleicht noch andere Werte vorher gesetzt werden? Ich bin für kreative Antworten dankbar. MfG Cyber

danke... das hab ich eben auch in der Newsgroup gefunden... aber nächstes Problem... jetzt gibt er bei einigen Mails folgende Meldung zurück: Exchange did not accept the sender and returned the following error message: 550 5.7.1 Client does not have permissions to send as this sender. [edit] Problem gelöst [/edit] jetzt wird weitergetestet... irgendwie find ich den Konfigdialog ja unglücklich aufgebaut? sonst noch jemand der gleichen Meinung? Schreibt doch mal was ihr für Erfahrungen im Test macht. Danke für die Hilfe. Gruß Cyber