Jump to content

CyberDoc

Members
  • Gesamte Inhalte

    83
  • Registriert seit

  • Letzter Besuch

Alle erstellten Inhalte von CyberDoc

  1. 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
  2. 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
  3. 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).
  4. 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
  5. 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. :)
  6. 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
  7. 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
  8. 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.
  9. Ja nee! ;) Fehlermeldung... Fehler: Typen unverträglich: 'p.PutEx'
  10. 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:
  11. 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.
  12. 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?!
  13. 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
  14. 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
  15. 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
  16. CyberDoc

    Was wollt Ihr gewinnen?

    also ich würd auch das TechnetAbo nehmen...obwohl...hmm ein SQL2006EE...nee zu dreist :D Greetz Cyber
  17. so Leute, da ich noch keinen passenden Thread gefunden habe, mach ich jetzt mal einen auf. Ich habe seit 2 Wochen den neuen Exchange auf einem W2k3-R2 EE Server im Einsatz. Dabei hat sich bisher folgendes Problem ergeben: Da ich für die Testumgebung keine externe Domäne zur Verfügung habe, musste ich auf die altebewehrten Mittel popcon + simple Webpäsenz bei Strato und den dazu passenden smarthost zurückgreifen. Über telnet bekomme ich zwar eine Verbindung zu port 25... popcon meldet aber einen Verbindungsabbruch und den Status "Client not authenticatet" und kann die abgeholten Mails nicht zustellen. Also ich kann mir nicht vorstellen, dass sich ein Mailserver aus dem Internet an einem veröffentlichten Mailserver aus meiner Firma authentifizieren muss?! Hab im Receive-connector schon alles ausprobiert... Basic oder keine Auth. aber nix zeigt Wirkung. Hab den popcon-service unter dem Administrator starten lassen, aber auch das hat nichts bewirkt. Hat jemand ne Idee? Die Dokumentation zum Exchange 2007 ist ja auch noch nicht vollständig (besonders im Bereich Security), also hat nachlesen auch keine Lösungsansätze gebracht. Hat sonst noch jemand schon Erfahrungen im Beta-Test mit dem Exchsvr12? Vielen Dank schonmal, für´s Ankurbeln der grauen Zellen und die Tipparbeit. Gruß Cyber
  18. Also ich habe den WSUS am WE bei uns installiert. Die Clients bekommen ihre Einstellungen per GPO da wir eine AD-Domäne haben. Die XP-Clients haben sich innerhalb von einer Stunde beim WSUS gemeldet, die 2k-Clients brauchten einen Neustart und danach ein paar Minuten. Ich würde sagen, deine Einstellungen sind soweit korrekt. Versuche doch mal bei einem Client die lokale Ricktlinie entsprechend zu modifizieren. Der Client sollte sich spätestens nach dem Neustart beim WSUS melden. Tut er das nicht, hast du ein Kommunikationsproblem. Andernfalls liegt es wohl doch an deinen Einstellungen.
  19. @lefg Danke für das Lob aus berufenem Munde :D @fads Wenn du die DSL-Anschlüsse beide in die Zentrale bekommen könntest... Schau mal hier: Netgear FVS124G ProSafe Gigabit VPN Firewall 25 käuflich zu erwerben für ca. 150 Euronen :D Um deine MonoWall weiter zu nutzen musst du dann allerdings die Firewall des Netgear quasi "abschalten" und das Ding auf die reine Loadbalancing Funktion kastrieren. Wenn meine Dual-NIC mal den Geist aufgibt, wir das Teil der Ersatz.
  20. hi fads einfach zu lösen, wenn du beide Internetrouter direkt mit einem WAN Router (z.B. 3Com 5000 Serie) verbindest. Diesen definierst du bei deinen Clients als Gateway. Der prüft dann in einstellbaren intervallen, über welchen Port er das Paket am besten Routen soll. Im Regelfall sollte das die Verbindung über die gekabelte Strecke sein. nur wenn die ausfällt routet er eben über die Andere. Das Problem dabei ist, dass du die beiden DSL-Router wirklich direkt mit dem WAN Router verbinden musst. Das bedeutet, du musst für den per WLAN angebundenen Router eine eigene Verbindung aufbauen und der Verkehr von den Clients am entfernten Standort geht immer erst über die WLAN-Strecke zum WAN-Router. Aber das ist wohl bisher auch so?! Dann hast du ein vollständiges Loadbalancing. Nebenbei würde ich mal prüfen, welche Möglichkeiten sich unter freeBSD ergeben, da deine MonoWall ja dieses OS verwendet. Ich glaube da gabs auch sowas wie Loadbalancing. Musst du mal googlen. Ich habe noch eine zweite Lösung. Bei mir liegen die beiden Anschlüsse physikalisch direkt nebeneinander. Deshalb hab ich bei mir eine Dual-Netzwerkkarte im Webserver (der macht außerdem Firewall, eMail und Routing), die wahlweise Loadbalancing, Failover oder separate IP´s betreibt. Das ist jedoch etwas Tricky. Bei LB und bei Failover läuf die Steuerung der ganzen Geschichte nämlich über den Kartentreiber. Die Router prüfen ständig die Verbindung (via script). Fällt einer aus, wird der LAN-Port deaktiviert!!! Das führt zum Verbindungsverlust an der Dual-NIC und das wiederum aktiviert das Failover, sprich das umschalten auf den zweiten Port-zum anderen Router. Das Betriebssystem erkennt die beiden Ports als einen und bekommt von dem Verbindungsabriss nix mit. Funktioniert auch, kostet nur die Hälfte, ist aber mit ner Menge know how verbunden.
  21. @Kelly du hast ein anderes Problem... Erstell mal bitte einen eigenen Thread dazu. @Pogoist Wer verwaltet denn nun die Einstellungen deiner WLAN-PCI Karte? Das mitgelieferte Tool, oder das in Windows integrierte? Nach meinem Gefühl kannst du dich einfach nicht authentifizieren. Das liegt an falschen oder nicht vorhandenen Sicherheitseinstellungen für das verwendete Drahtlosnetzwerk. Schau mal in die Eigenschaften deiner "Drahtlosen Netzwerkverbindung" und da unter "Drahtlosnetzwerke". Den Haken bei "Windows zum Konfigurieren der Eigenschaften verwenden" wegnehmen (falls da einer ist). Wenn´s das nicht war: Hast du einen WLAN-Sniffer/Verwaltungstool installiert? (Lycos oder Boingo oder ähnliches, die T-Online Software macht auch sowas) Kann sein, das solch ein Tool die Einstellungen deiner Konfigurationssoftware überschreibt. Das hatte ich letztens am Notebook ;) mit dem gleichen Resultat. Wenn nix hilft, erstell nochmal ein neues Netzwerkprofil in der Konfigurationssoftware für die Karte. Vielleicht wurde irgendwas überschieben/verstellt. (kann ich mir aber nicht vorstellen) Killerlösung: WEP Verschlüsselung am Router deaktivieren und einfach mal so connecten. Wenn es dann geht, lags an den Einstellungen. Was für ne WLAN-Karte ist das eigentlich??? so Nebenbei: Der Hostname deines PC´s wird wahrscheinlich nicht angezeigt, weil keine Verbindung besteht. Du hast ja keine IP bekommen und der Router hat somit keine Möglichkeit deinen Rechner nach seinem Namen zu fragen. ;) Mein Router macht das sowieso nur für die Clients, die sich bei ihm eine IP über DHCP geholt haben. Alle anderen (mit statischer IP) muss ich ohnehin von Hand benennen.
  22. Du musst auf dem Windows Server 2003 noch ein paar Sachen konfigurieren. Ganz so "out of the box" geht es dann doch nicht. ;) (sonst hätten wir ja alle keine Jobs mehr) 'Rechtsklick' auf Routing und Ras - Eigenschaften: Häkchen machen bei "Router" Unter IP-Routing -NAT/Basisfirewall auf der Internetschnittstelle (wahrscheinlich eine PPPoE-Wählverbindung, erkennst du an der öffentlichen IP-Adresse): 'Rechtsklick' -Eigenschaften -NAT auf dieser Schnittstelle aktivieren (wenn du die Firewall mitaktivierst, nicht vergessen die Ports für deinen Apache zu öffnen, falls der von "draußen" erreichbar sein soll ;) ) Das müsste es gewesen sein. Gruß Cyber
  23. Das du im "Internetnetz über einen Proxy musst, macht die ganze Sache für mein Verständnis etwas Tricky. Aber vielleicht ist es ja auch einfacher als es aussieht. Grundsätzlich ist es so: Der Server ist sicher schon mit einer 2. Netzwerkkarte am "Internetnetz" angeschlossen und die sollte eine statische IP besitzen?! Hier trägst du auch das Gateway und den/die DNS-Server für das "Internetnetz" ein. Im Routing musst du auf der "Internetnetz-Netzwerkkarte" NAT aktivieren (ggf. muss du die Netzwerkkarte bei "NAT/Basisfirewall" erst noch hinzufügen). Danach können die Clients auf das Internetnetz zugreifen, also auch den Proxy erreichen. Die Server (DNS, Proxy, Gateway etc) aus dem Internetnetz würde ich noch in mit einem DNS Eintrag auf dem Server versehen. Nach meiner Auffassung würde es jetzt ausreichen, wenn du den Proxy einfach bei den Clients einträgst. Die Anfragen müssten einfach weitergeroutet werden. Im Zweifelsfall würde ich auf dem Proxy noch eine statische Route für dein Clientnetzwerk definieren.
  24. Also um nochmal zu übersetzten was die Experten dir sagen wollen: Im Moment ist es so: Dein Client sendet ein Paket (z.B. ne anfrage für einen Server im Internet) an deinen Server auf 192.168.0.2 Der Server kennt den Weg ins Internet. Also routet er das Paket über 192.168.37.2 an die 192.168.37.1 und der sendet das Paket ins Internet und merkt sich die 192.168.0.3 als Absender und potentiellen Antwortempfänger (NAT). Wenn der Server aus dem Internet jetzt antwortet, will er das Paket an die 192.168.0.3 senden, kennt den Weg aber nicht und verwirft das Paket. Wenn du also auf dem Router (192.168.37.1) eine statische Route definierst: Ziel: 192.168.0.3 Subnetz 255.255.255.0 Gateway: 192.168.37.2 Metrik: 3 (bin mir nicht sicher aber sollte egal sein) ...weiß er nun, dass alles was an deinen PDA geht zuerst zum Server (192.168.37.2) muss. Und der kennt ja wieder den Weg. So müsste es funktionieren. P.S. Nebenfrage an die Experten: Sollte der Router nicht eine dynamische Route per Update vom Server übermittelt bekommen? (richtige Konfiguration vorausgesetzt)
×
×
  • Neu erstellen...