mymicha

Hallo, ich habe das "Problem" gestern Abend lösen können. Ist etwas verzwickt, aber ich versuche es zu erklären. Bei diesem Kunden nutze ich die Software PopCon (ExchangeServer hat keine statische Adresse), um die E-Mails der Benutzer von einem Linux Mail Server zuladen, nach Viren zu prüfen und an den Exchange weiter zu leiten. Da einige mehrere E-Mailadressen haben, habe ich jeweils ein Sammelpostfach auf dem Linux Server eingerichtet, was die E-Mails pro Benutzer auffängt. PopCon ruft die E-Mails dann ab und leitet sie direkt an die interne E-Mailadresse des Benutzers weiter. Die Filterung, welche externe Adresse an welchen internen Benutzer geleitet wird, erfolgt also auf dem Linux Server. Hoffe soweit klar. Jetzt kommt der Knackpunkt: Kommt eine Spam-E-Mail für den Benutzer auf einer Adresse an, die nicht unter den SMTP Adressen im AD steht, dann wird sie vom Exchange zwar mit einem SCL versehen, aber NICHT serverseitig in den Junk-E-Mail Ordner einsortiert. Trage ich die E-Mail Adresse dann unter den SMPT Adressen des Benutzers im AD ein, funktioniert die Sortierung. Das Problem ist für mich als solches gelöst. Als Fehler kann man es nicht richtig sehen, oder?

Hallo Zusammen, dann möchte ich mich doch auch noch mal an der Diskussion beteiligen. Ich betreue mehrere Exchange Organisationen in kleineren Unternehmen im Mittelstand. Die Bandbreite reicht von 5 Useren auf einem W2k3 SBS Server bis hin zu 500 Usern auf drei Exchange Enterprise Servern (2 Back-End und 1 Front-End). Bei Servern, die ich alleine betreue und über Exchange Themen alleine Entscheiden kann, gibt es keine MailBox Limits. Wir haben versucht beim User lieber ausführlich Aufklärung zu betreiben, was z.B. das Speichern von "Lustigen" PowerPoints, Videos usw. angeht, die NICHT zum Alltagsgeschäft gehören. Private E-Mails sind bei den meisten generell NICHT verboten. Dafür legen sich die User KEINE PST Ordner an, sondern ziehen die E-Mail als Datei (MSG Datein ==> E-Mailinformationen + Anhang bleiben vollständig erhalten) auf einen Share. Damit fällt nämlich *SCHWUPS* das Problem mit der Sicherung der PST Datei (Quasi immer Vollsicherung bei kleinen Dateiänderungen) weg. Die meisten User legen sich solche E-Mails auf die lokale Festplatte ab oder brennen bei Gelegenheit ne CD. Keine Frage gibt es hier auch ein paar schwarze Schafe, aber der generelle Postfach-Größen-Schnitt wird gedrückt. Meiner Auffassung und Erfahrung nach ist es für die Mitarbeiter zeitsparender und effizienter, wenn ALLE geschäftsrelevanten E-Mails im Postfach liegen und z.B. bei Notebook Usern (Vertrieb) immer dabei sind, per OWA eingesehen werden können (Was mache ich, wenn ich unterwegs eine E-Mail aus meiner PST brauche? ZEITAUFWAND!!??) und schnell durchsucht werden können. Hierzu haben wir auf den Clients Lookout installiert, um eine ordentliche Suchfunktion zur Verfügung zu stellen. Super Ressonanz. Bei den größeren Kunden (> 100 Usern) sieht es etwas anders aus. Hier gibt es ein Limit bei 250MB und auf Anfrage ein größeres Postfach. Generell wird es niemanden verweigert, aber erst mal versucht den User etwas unter Druck zu setzen, seine E-Mail doch bitte per PSTs zu archivieren. Es gibt leider auch keine Richtlinien bezüglich Ablage der PST Dateien auf Server Shares bzw. lokalen Datenträgern. Leider habe ich hier kein großartiges Mitspracherecht, sondern agiere nur bei Serverproblemen bzw. anstehenden Updates. Ich bin quasi nur Zuschauer. Dieses Thema wird aber nicht wirklich als "Thema" angesehen und auch nicht weiter verfolgt. Es funktioniert und somit sieht damit keiner ein Problem. Mein Einwand, was passiert wenn eine Festplatte crashed und alle E-Mails des Users weg sind: Antwort "Sein Problem. Er trägt die Verantwortung (Also der User)." Finde ich keine gute Einstellung. So, langes Statement. Mein Postfach ist mittlerweile 2,4GB groß und ich habe KEINEN Müll daran (Lässt sich sicherlich streiten). Ich bin froh, dass ich gerade in alten E-Mails suchen konnte, um an Informationen zu kommen die eigentlich verloren gegangen wären. Auch aus Beweispflicht gegenüber Kunden usw. musste ich da schon mal ältere E-Mails raus kramen. Ein Dank an Lookout. Wünsche ein erfolgreiches Backup.

Hallo liebe Exchange-"Liebenden", seit kurzem nutzen wir zusätzlich zu unserem vorgeschalteten SPAM Filter auch den IMF des Exchanges. Klappt wunderbar ... bis auf eine Kleinigkeit. Ich habe den SCL Wert zur Verschiebung wahrscheinlicher SPAM Mails im IMF auf 3 stehen und zum Blockieren bzw. Archivieren auf 7. Klappt auch so. Leider werden Mails mit einem SCL von 3,4,5,6 dem Benutzer im Posteingang zugestellt und erst beim direkten Öffnen des Postfaches durch den Benutzer in den Junk-E-Mail Ordner verschoben. Ich habe aber in verschiedenen Dokumentationen gelesen und auch von anderen Admins gehört, dass hier die E-Mails vom Exchange Server einsortiert werden und NICHT vom Client. Was mache ich also falsch? Vielen Dank.

Hallo, ich kämpfe momentan an einer WMI Abfrage zur Filterung von GPOs, die nur dann True ergeben soll, wenn der angemeldete Benutzer über lokale Adminrechte verfügt. Ich kann zwar eine funktionierende Abfrage schreiben, ob ein bestimmter Benutzer in der lokalen Admingruppe ist, jedoch steht der Benutzer bei mir nicht direkt in der lokalen Admingruppe. Bei uns gibt es eine Sammelgruppe in der Domäne, in der Benutzer eingetragen werden, die lokale Admins sind. Diese Gruppe ist Mitglied der lokalen Admingruppe. Meine Frage nun: Wie ist es möglich per WMI herauszufinden, ob der derzeit angemeldete Benutzer über lokale Adminrechte verfügt? Vielen Dank für evtl. Hilfe.

Danke - nach fast genau einem Jahr hat der Post jemanden geholfen *G* JUHU

Hallo Leute, ich hatte vereinzelt bei WinXP mit SP1 oder SP2 (Spielt keine Rolle) das Problem, dass er zwar den Rechner im WSUS aufgenommen hat, jedoch keine Updates installiert hat und auch keinen Bericht an den WSUS gesendet hat. Teilweise wurde der Rechner auch gar nicht im WSUS angezeigt. Im Verzeichnis C:\WINDOWS findet man die Datei "WindowsUpdate.log". Hier wird alles bezüglich Updates mitgeloggt. Habe ich mit dem Command: "wuauclt /detectnow" den Updatevorgang manuell angestoßen, habe ich folgende Zeilen in der Log entdeckt: ---------------------------- Triggering AU detection through DetectNow api AU received event of 1 WU client ... .... .... Send failed with hr = 80072efd SendRequest failed with hr = 80072efd. Proxy List used: <(null)> ... usw. ... ... ---------------------------- Ich habe im Internet hierzu etliches gefunden und alle (einschließlich Microsoft ;) ) wollten, dass man die Proxyconfiguration überprüft und per Command: "proxycfg -d" zurücksetzt usw. Das hat nie bei mir geholfen. Und nach ein kurzen Werbepause nun das Ergebnis Smiley Start -> Ausführen -> cmd -> Enter regsvr -u wuaueng.dll // Meldung mit OK bestätigen cd \ cd windows cd system32 del wuaueng* exit Nun auf die Website für Windowsupdates (Microsoft Windows Update). Jetzt werde die Windows Updates neu installiert. Es kann vorkommen (zu 90% *G*), dass er während des Downloads der Aktualisierung abbricht und eine Fehlermeldung anzeigt. NICHT DEN BROWSER schließen und wieder neu öffnen. Einfach die Seite aktualisieren. Sprich neu laden lassen. Jetzt läuft alles von vorne an und er sollte es schaffen. Schaut mal in die Adresszeile - ja! Jetzt habt ihr Version 6 der Windows Updates installiert! Anschließend einfach mit dem bekannten Befehl "wuauclt /detectnow" die Updates anfordern und freuen Smiley Wem es geholfen hat, der kann sich hier ja noch mal melden.

@Stefan.Haegele Diese Einstellung bewirkt leider nur, dass User erst am Ende der Installation eine Nachricht bekommen - Eben die zum Neustart des Rechners. Diese Nachricht können auch nur Administratoren auf später verschieben. User "müssen" neustarten. @hekmek Ich hoffe ja immer noch, dass evtl. diese "Freiheit" nachgerüstet wird. Sollte ja nicht so schwer sein.

Hallo herakles99 Bei normalen Updates möchte wir nicht, dass der Benutzer gestört wird bzw. überhaupt eine Meldung kommt. Am Abend wird er seinen Rechner eh ausschalten und am nächsten Morgen wieder einschalten. Somit ist der Restart (Für den User unbewusst) erfolgt. :) Bei kritischen Updates können wir ja immernoch NET IQ Patchmanager verwenden, um sofort zu verteilen und den Benutzer dazu zu zwingen, den Rechner neu zu starten (Stichwort: Blasterpatch).

Hallo Leute, ich habe in den letzten paar Tagen den aktuellen WSUS installiert und in unserer Testumgebung ausführlich getestet. Klappt soweit auch alles wunderbar. Leider musste ich folgendes feststellen: Wenn man einem Computer ein Paket zuweist, das nach der Installation einen Neustart erfordert, so bekommt der angemeldete Benutzer einen Dialog angezeigt, dass er doch bitte einen Neustart machen soll. Kann man das irgendwie deaktivieren. Ein Admin kann ja wenigstens den Knopf "Später neustarten" auswählen. Beim Benutzer ist dieser Knopf auch noch hintergraut. Die standardmäßige Richtlinie sieht nur vor, dass der Rechner entweder nach einer bestimmten Zeit automatisch neu gestartet wird oder eben es kommt dieser Dialog. :confused: :confused: :confused: Momentan verteilen wir unsere Patches noch mit NETIQ Patchmanager. Hier werden die Patches zugewiesen - sprich direkt beim Client installiert. Das ist bei sehr vielen Clients etwas unübersichtlich. Aber hier haben wir wenigstens die Möglichkeit den Neustart zu unterdrücken. Irgendjemand eine Idee? Besten Dank schon mal.

@mickey Jo, nur Benutzer mit administrativen Rechten auf diesem Computer bekommen dieses Symbol angezeigt und können ggf. Updates schon früher installieren. Benutzer sehen nix und können nix machen.

Hallo, ich kämpfe mit einem kleinen Problem auf unserem Terminalserver. Ich habe ein MSI Paket installiert (natürlich im Installmodus direkt in der Console) soweit kein Problem. Das Paket legt jedoch im Startmenü "All Users" einen Advertised Shortcut an - sprich, wenn bei der Ausführung (klick auf den Shortcut) der MSI Mechanismus feststellt, dass noch etwa Registryschlüssel im Current User fehlen, werden diese nachinstalliert. Melde ich mich per Remotedesktop am TS an und klicke auf den Shortcut, so sagt mir eine Fehlermeldung, dass nur Administratoren in einer Remotesitzung eine Installation durchführen dürfen. Diverse Richtlinien habe ich jedoch gesetzt, dass der Installer die Benutzerinstallation durchführen darf. Melde ich mich mit diesem Benutzer jedoch an der Console an, so funktioniert es tadellos. Das MSI installiert ein paar Current User Registry Keys und startet die Anwendung. Anschließend funktioniert die Software natürlich auch in der Remotesitzung. Nun meine Frage: Dieses "Problem" tritt doch sicherlich auch bei anderen Standard-MSI-Paketen auf. Es kann nun nicht sein, dass sich jeder Benutzer auf dem TS erst an der Konsole anmeldet, oder? Wie kann man dies beheben? Vielen Dank für eure Hilfe. Verzweifle langsam.

>> Problem ist gelöst!!! Okay, es war kein wirkliches Problem, sondern einfach nur Dummheit. Standardmäßig ist beim SBS Exchange für die Speichergruppe die Umlaufprotokollierung aktiviert. Muss ich wohl übersehen haben - aber bei allen? Tja, und dann kann man natürlich weder ein Differenz- noch ein Inkrement-Backup fahren. Wie Selbstgespräche doch helfen können, oder? :) Aber vielleicht sucht ja auch mal jemand anders nach dieser kleinen Hürde!

So, noch eine kleine Ergänzung. Ich habe über einen Snapshot die VMWare mit dem SBS Testserver ohne Exchange SP1 zurückgeholt und es auch noch mal probiert. Auf die Gefahr hin, dass das SP1 für den Exchange mit dem SBS NTBACKUP vielleicht Probleme macht. Die Antwort: Gleiches Problem. Vollbackup o.k. Differenzbackup versagt mit obiger Meldung! Das Prob muss doch schon mal bei jemand anderen aufgetreten sein, aber ich finde dazu Null!

Hallo Leute, ich arbeite schon relativ lange mit Windows Server 2003 und Exchange 2003. Bisher war es bei meinen Kunden (die Windows Server 2003 Small Business Server haben) so, dass ich Exchange über NTBACKUP gesichert habe. Also nicht die vorgefertigten Scripte von SBS, sondern selber angelegte Scripte. Dabei habe ich stets eine Vollsicherung gemacht, da es auf die paar MB nicht ankam. Nun wollte ich unter der Woche umstellen auf Differenz bzw. Inkrementelle Sicherung. Bei meinem eigenen Exchange 2003 Standard Server und Windows 2003 Standard habe ich das schon seit geraumer Zeit im Einsatz. Keine Probleme. Auch beim Restore. Nun musste ich feststellen, dass der SBS Exchange 2003 sich nicht Differenziell oder Inkremetell sichern lässt. In der NTBACKUP Log steht der Satz: Fehler: FFSERVER1\Microsoft Information Store\SP1 ist kein gültiges Laufwerk, oder Sie haben keinen Zugriff. Daraufhin habe ich es auch bei meinen anderen Kunden mit SBS probiert und stellte das gleiche Ergebnis fest! Daraufhin habe ich einen neuen SBS Server in einer VMWare aufgesetzt und stellte das gleiche fest. Der Exchange hat dabei das Service Pack 1 installiert. Nun meine Frage: Ist das ein Bug oder ein Feature von Microsoft? Im Internet konnte ich nix konkretes finden, dass der Exchange im SBS generell nicht Inkrementell oder Differenziell gesichert werden kann. Danke schon mal im Voraus. :)

Wow, sogar in PHP - ist ja großartig. Ich werde es dann gleich mal testen. Vielen Dank!!