NeoLEX

Besten Dank Günther, dein Tipp war goldrichtig. Da habe ich wohl wieder etwas über den SBS gelernt. Es hat mich überrascht wieviele Updates nur als "Optional" eingestuft waren. Nach einer kleinen Patchorgie ist jetzt alles wie gewünscht. MfG, NeoLEX

Hallo, hat zu diesem Thema jemand etwas Neues herausgefunden? Bei mir liegt die gleiche Situation wie bei blob vor. Outlook 2010 in Verbindung mit Exchange 2007 (SBS 2008). Bei jedem Öffnen des Outlooks kommt die Abfrage nach den Zugangsdaten, das Postfach wird aber auch ohne Eingabe synchronisiert. Ich habe bereits erfolglos verschiedene Authentifizierungseinstellungen ausprobiert. Und die Registry-Änderungen aus dem KB-Artikel helfen mir ebenfalls nicht weiter. MfG NeoLEX

Lösung: Mittlerweile konnte ich das Problem beheben. Die Zugriffsrechte auf eine Datei des WGA waren für MSE nicht ausreichend. Nach Erweiterung auf Jeder-Vollzugriff für die Datei C:\Dokumente und Einstellungen\All Users\Anwendungsdaten\Windows Genuine Advantage\data\data.dat funktionierte die Überprüfung wieder tadellos und MSE verhielt sich wieder kooperativ. :D Quelle: Genuine Windows Validation Error With MS Security Essentials Bis dann, NeoLEX

Als nächsten Lösungsversuch habe ich die alte Version deinstalliert und die aktuelle manuell installiert. Der Fehler ist aber erneut aufgetreten. Es liegt also nicht nur am Update sondern generell an der neuen Version (1.0.1961.0). Diesen Lösungsversuch können sich andere Betroffene also sparen. NeoLEX

Dank Systemwiederherstellung bin ich das Problem nun erstmal wieder los. Jetzt meckert MSE lediglich noch, dass eine neuere Version zur Verfügung steht. Um das Update mache ich aber jetzt erstmal einen großen Bogen.

Hallo Necron, an der Gültigkeit meiner Lizenz habe ich keinen Zweifel. Die Windows Gültigkeitsüberprüfung wird auch erfolgreich abgeschlossen (Vielen Dank, dass Sie die Gültigkeitsprüfung durchgeführt haben und Microsoft-Originalsoftware verwenden). Aber MSE zeigt sich leider davon unbeeindruckt. Ich gehe eher von einem Fehler von MSE aus, welcher durch das Update ausgelöst wurde, und suche nun nach einer Möglichkeit der Fehlerbehebung.

Hallo Leute, seit meiner letzten Aktualisierung über Microsoft Updates meckert mein MSE (1.0.1961.0) regelmäßig, dass mein Windows XP (SP3) eine Softwarefälschung sein könnte. Es gibt zwar Buttons eine Echtheitsüberprüfung vorzunehmen, welche auch erfolgreich verläuft, aber MSE zeigt sich davon unbeeindruckt. Mir scheint also, dass eines der installierten Updates diesen Fehler verursacht. :shock: Die Updates waren bei mir im einzelnen: Update für den Junk-E-Mail-Filter von Outlook 2007 (KB979895) Sicherheitsupdate für 2007 Microsoft Office System (KB978380) Windows-Tool zum Entfernen schädlicher Software - März 2010 (KB890830) Microsoft Security Essentials Client update package - KB2019198 Sicherheitsupdate für Microsoft Office Excel 2007 (KB978382) Sicherheitsupdate für Windows XP (KB975561) Update für 2007 Microsoft Office System (KB977724) Update für den Junk-E-Mail-Filter von Outlook 2007 (KB979895) Sicherheitsupdate für 2007 Microsoft Office System (KB978380) Windows-Tool zum Entfernen schädlicher Software - März 2010 (KB890830) Hat sonst noch jemand ähnliche Probleme oder vielleicht sogar bereits ein Lösung für das Problem? Der regelmäßige Warnhinweis nervt gewaltig. :confused: Vielen Dank im Voraus, NeoLEX

Hallo DJMaker, ich danke dir für die Rückmeldung. Ich stecke leider mal wieder in einer Sackgasse. Ich habe jetzt eine Testumgebung frisch installiert: Domaincontroller: W2K3 Standard SP1 DNS, WINS, AD Gesamtstrukturfunktionsebene: Windows 2000 Domänenfunktionsebene: Windows 2000 gemischt Feste IP Exchange-Server: W2K3 Standard SP1 Exchange 2003 Feste IP, Connector zum Mailgateway Mailgateway: W2K3 Standard SP1 SMTP-Dienst Feste IP Keine Updates installiert; Keine spezielle Konfigurationsänderung vorgenommen. Nur das erforderliche für die Exchange-Installation (ASP.NET, NNTP-, SMTP-, WWW-Dienst, Support-Tools, ForestPrep, DomainPrep) Die Relayingberechtigungen sind im Standardzustand, im Detail: Nur Computer in der Liste unten [AKTIV] Alle, mit Ausnahme der Computer in der Liste unten [iNAKTIV] Computerliste [LEER] Jedem Computer, der erfolgreich authentifiziert ist, unabhängig von der Liste oben, das Relay erlauben [AKTIV] Der generelle Versand nach extern aus dem Postfach heraus funktioniert theoretisch. Die versendeten E-Mails landen in der Queue des Mailgateways, wo Sie jedoch absichtlich nicht mehr weiterverarbeitet werden. Wenn ich jetzt von einem beliebigen Computer (Domänenmitglied) versuche per SMTP (Telnet) eine Nachricht für einen externen Empfänger am Exchange-Server abzuliefern erhalte ich den Fehler "5.7.1 Unable to relay". Wenn ich den Computer in die Computerliste aufnehme funktioniert es. Ich bin bisher davon ausgegangen, dass die aktive Option "Jedem Computer, der erfolgreich authentifiziert ist, unabhängig von der Liste oben das Relay erlauben" es ermöglicht, von jedem Domänencomputer aus, E-Mails an externe Empfänger per SMTP abzuliefern. Genau dies funktioniert bei mir aber nicht. Weder in der Produktivumgebung, noch in der geschilderten Testumgebung. Da keinerlei Updates in meiner Testumgebung installiert sind, fällt auch meine mein vorheriger Verdacht, dass sich das Verhalten mit einem Update geändert hat, als Fehlerursache aus. Es bleibt jetzt eigentlich nur noch übrig, dass ich diese Option falsch deute und sie etwas ganz anderes bedeutet. Kann das jemand bestätigen? Danke im Voraus, NeoLEX

Hallo, ich berichte mal den aktuellen Zwischenstand. Bisher habe ich hauptsächlich versucht das Problem weiter einzugrenzen. Zunächst habe ich mit Hilfe der technischen Referenz überprüft, ob ich die Option "Jedem Computer, der erfolgreich authentifiziert ist, unabhängig von der Liste oben das Relay erlauben" überhaupt richtig verstanden habe. Diese bestätigt aber meine Annahme. Durch diese Option sollte es möglich sein, von jedem erfolgreich authentifizierten Domänencomputer aus, E-Mails für Fremddomänen abzuliefern. Das Fehlverhalten kann ich aber eindeutig reproduzieren. Trotz aktivierter Option wird mir das Relaying verweigert. Dies habe ich mitttlerweile an zwei produktiven und einem Referenzserver nachgestellt. Aktuell halte ich es für wahrscheinlich, dass das Verhalten dieser standardmäßig aktivierten Option mit einem Update geändert wurde. Als nächstes will ich nun einen neu installierten Server ohne installierte Updates testen. Wenn das Relaying, wie erwartet funktioniert, werde ich jedes Update, welches auf meinen produktiven Servern installiert ist, einzeln testen. Ich werde weiter berichten. NeoLEX

Ja, alle beteiligten Computer sind Domänenmitglieder. Auf den PCs soll eine Software automatisiert E-Mails über einen der Exchange-Server per SMTP versenden, auch an externe Empfänger. Durch die, im SMTP-Server gesetzte Option "Relaying für alle authentifizierten Computer erlauben" sollte dies eigentlich möglich sein. Trotzdem wird es in der Praxis mit der Fehlermeldung "Relaying denied" verweigert. Derzeit bin ich ratlos.

Hallo Kollegen und alle die es werden wollen. Meine Exchange Server lassen aktuell kein Relaying mehr zu. In der Konfiguration des virtuellen SMTP-Servers ist das Relaying für alle authentifizierten Computer erlaubt, aber es wird trotzdem verweigert. Ein Test per Telnet verlief fehlerhaft. Wenn ich die IP-Adresse des Rechners explizit in die Positivliste eintrage funktioniert es wieder wie gewohnt. Dies ist jedoch keine dauerhafte Lösung, da die Software zum Versenden der E-Mails auf wechselnden Clients ausgeführt wird. :confused: Was könnte hier los sein? Eine einzelne Störung kann ich ebenfalls ausschliessen, da ich das gleiche Verhalten bei zwei Servern nachstellen konnte. Aus meiner Sicht scheint mit der Authentifizierung der Computer etwas nicht zu stimmen. Hat jemand eine Idee? NeoLEX

Hallo Leute, also ich habe jetzt beide Möglichkeiten überprüft und konnte keinen Fehler mehr feststellen. Sowohl bei der Auswahl des Verteilers aus dem Cache, als auch bei Auswahl aus dem Kontaktordner tritt der Fehler nicht mehr auf. Auch eine Sichtung der NK2-Datei mit nk2view.exe brachte keine neuen Erkenntnisse. Vermutlich gab es ein temporäres Problem mit dem Cache, vielleicht durch einen Fehler beim Herunterladen des servergespeicherten Profils, welches jetzt jedoch nicht mehr nachvollziehbar ist. Mein Anwender ist jedenfalls zufrieden, er weiß nun, dass er einige Empfänger nochmal anschreiben muss. Vielen Dank für die Unterstützung. NeoLEX

Vielen Dank für den Hinweis. Das habe ich nicht bedacht. Diesen Umstand werde ich mit meinem Anwender überprüfen. Einmal werde ich eine Testmail explizit aus den Kontakten auswählen und einemal ggf. aus dem Cache vervollständigen. Nach der Theorie müsste dann die Zustellung bei der der Adressat aus dem Cache kommt fehlschlagen. Ich melde mich wieder. NeoLEX

Diese Informationen habe ich mir mal besorgt. Die E-Mail enthielt Empfänger aus - einer Verteilerliste aus dem globalen Adreßbuch, - einzelne Empfänger aus dem globalen Adressbuch, - zwei Verteilerlisten aus den Kontakten. Bei den nicht erfolgreichen Zustellungen handelt es sich ausnahmslos um Empfänger aus den beiden Verteilerlisten aus den Kontakten. Die Verteiler habe ich überprüft. Sie enthalten alle gültige interne Adressen und funktionieren auch generell. Eine Testnachricht an diese Verteiler wurde problemlos übermittelt. Es scheint sich also nur um eine einmalig aufgetretene Störung zu handeln, bei der die Adressaten aus den Kontakten nicht berücksichtigt wurden. Seltsam. NeoLEX

Danke schonmal für den Hinweis. Die Suchfunktion habe ich tatsächlich nicht benutzt weil ich das Problem für zu exotisch hielt und ich keine eindeutigen Schlagworte ausfindig machen konnte. Bei Google wurde ich mit meinen Suchworten von Erbnissen erschlagen und die 10-15 Treffer die ich recherchiert habe, hatten nicht oder nur sehr entfernt mit exakt meinem Problem zu tun. Ich werde aber jetzt noch ein bisschen im Board stöbern gehen, in der Hoffnung einen ähnlichen Fall zu finden. Mit internen oder externen Empfängern hat es in meinem Fall nichts zu tun. Alle Adressaten sind intern, sowohl die mit erfolgreicher Zustellung, als auch die mit nicht erfolgreicher Zustellung. Mir fehlt es aktuell an jeglicher Idee, wie ich das Problem analysieren könnte. Wie kann ein solcher Fehler entstehen, an welcher Stelle tritt die Störung auf und wie kann ich sie zukünftig vermeiden? NeoLEX

Hallo Kollegen und alle die es werden wollen, ich brauch mal wieder Eure Hilfe. Einer meiner Anwender schwört Stein und Bein darauf, dass seine E-Mail nicht alle Empfänger erreicht hat. Er hat die Übermittlungsbestätigung genutzt und hat von einigen der Adressaten keine Bestätigung erhalten. Er hat bei den Personen nachgefragt und diese haben bestätigt, dass die Mail nicht angekommen ist. Dieser Fehler ist bisher nur einmal aufgetreten. Als Software wird Outlook 2003 mit Exchange 2003 SP2 benutzt. Was ich schon gemacht habe: Überprüfung der Mail im Postfach des Absenders: Alles wie geschildert. Überprüfung der Mail im Postfach eines Empfängers: Mail ist nicht angekommen. Überprüfung der Nachrichtenverfolgung im Exchange: Mail wurde abgeschickt und an die Adressaten zugestellt, aber die Adressaten sind nicht vollständig aufgeführt. Aus meiner Sicht scheint die E-Mail das Outlook fehlerhaft verlassen zu haben. Im Outlook stehen einige Empfänger mehr drin als in der Nachrichtenverfolgung im Exchange. Die Kommunikation zwischen Outlook und Exchange via MAPI scheint in diesem Fall fehlerhaft verlaufen zu sein. Obwohl ich das eigentlich für ziemlich unwahrscheinlich halten würde. Was könnte die Fehlerursache sein? Wie kann ich hier weiter vorgehen? Hat schonmal jemand einen solchen Fehler gehabt? Für Tipps und Hinweise bedanke ich mich im voraus, NeoLEX

Hallo Kollegen und alle die es werden wollen, ich habe da mal ein etwas merkwürdiges Problem, mit dem ich nicht mehr weiterkommen. Villeicht hat von euch jemand eine Idee. Gegeben sind zwei Benutzer mit Outlook 2K3 an Exchange 2K3. Benutzer A hat Berechtigungen Stufe 4 für Benutzer B auf seinen Kalender eingerichtet. Benutzer A hat einen über mehrere Wochen fortwährenden Termin (Abwesend), gültig werktäglich von 9-17 Uhr. Jetzt möchte Benutzer B eine Besprechungsanfrage an A senden und sieht in der Zeitleiste, dass A abwesend ist. Wechselt B aber in die Detailansicht, in der üblicherweise die Termine inkl. Text sichtbar sind, sieht er nichts mehr. Benutzer A scheint an diesem Tag verfügbar zu sein, obwohl er sich eigentlich als abwesend eingetragen hat. Bei eigenen Versuchen, wurde ein gleichartiger Termin korrekt angezeigt und wurde von ggf. vorhandenen Einzelterminen überlagert. Als Lösungsversuch ist mir bisher nur eingefallen die Frei-Gebucht-Zeiten über den Outlook-Startparameter /CleanFreeBusy zu reparieren, den Termin mal zu löschen und neu zu erstellen und eine Änderung des Termins auf ganztägig. Alles blieb jedoch erfolglos, der Termin ist nach wie vor, trotz ausreichender Berechtigung, in der Detailansicht nicht sichtbar. Hat von euch noch jemand eine Idee, warum der Dauertermin nicht ordentlich angezeigt wird, und wie man das reparieren könnte? Vielen Dank im voraus, NeoLEX

Das scheint es gewesen zu sein, nachdem ich mich gezielt auf den DC verbunden habe, auf dem ich auch die Einstellung vorgenommen habe, hat es funktioniert. :D Vielen Dank, NeoLEX

Hallo Kollegen und alle die es werden wollen, Ich versuche gerade einen Tipp aus dem Buch "Windows Server 2003 - Die Expertentipps" umzusetzen. In Tipp 4.22 geht es darum das Kontextmenü der Verwaltungskonsole "Active Directory-Benutzer und Computer" um eigene Einträge zu erweitern. Mit ADSIEdit wird in der Configuration-Partition des AD ein Kontextmenüeintrag eingerichtet und auf den lokalen PCs das dazugehörige Skript hinterlegt. Das klappt auch soweit wunderbar, solange ich in der Root-Domain operiere. Der Kontextmenüeintrag erscheint jedoch nicht, wenn ich mit der Verwaltungskonsole in die SubDomain wechsele. Ich habe noch versucht herauszufinden ob es für die SubDomain eine eigene Configuration-Partition existiert, aber mit allen Verbindungsversuchen per ADSIEdit lande ich immer in der gleichen Partition der Root-Domain. Kann es sein, dass es keine eigene Configuration-Partition für SubDomains gibt? Wie könnte ich denn diese Änderung auch für die SubDomain realisieren? Vielen Dank im voraus, NeoLEX

Hallo Leute, hat keiner eine Idee? Ich bin in der Zwischenzeit leider auch nicht weiter gekommen. Mittlerweile habe ich schon die Berechtigungen für das Postfach komplett erneuert, aber ohne Erfolg. Ich danke im voraus, NeoLEX

Hallo Kollegen und alle die es werden wollen, ich habe hier mindestens ein fehlerhaftes Postfach, bei dem sich die Stellvertretungen nicht mehr konfigurieren lassen. Es lassen sich weder Personen entfernen, noch welche hinzufügen. Die Änderung lässt sich zwar wie gewohnt durchführen, aber wenn man anschließend die Berechtigung kontrolliert, sind sie unverändert. Die Berechtigungen habe ich durchgesehen und vorsorglich mal SELBST - Vollzugriff erteilt, aber es bleibt dabei. Andere Postfächer funktionieren problemlos, ein allgemeines Problem scheint es also nicht zu sein. Hat von Euch jemand eine Idee, was da los ist? Die letzte grössere Änderung mit Bezug zum Exchange war das Roll-Out von SP2 für Office 2k3. Beteiligte Systeme: Domäne: Windows Server 2003 SP2 (2003 pur) Exchange: 2003 Enterprise Edition SP1 auf Server 2003 Enterprise Edition SP2 Client: Outlook 2003 SP2, hauptsächlich ohne Exchange-Cached-Modus Vielen Dank im voraus, NeoLEX

Spontan aus dem Bauch heraus tippe ich mal darauf, dass entweder die Routingtabelle nicht richtig konfiguriert ist, oder es ist schlicht ein Problem der Namensauflösung. Poste doch mal die Routingtabelle inklusive der Information welcher Adressbereich vom Routing und RAS den VPN-Verbindungen zugewiesen wird und aus welchen Adressbereichen das interne Netz besteht. Versuche auch mal ob du auf das Internet via IP, z.B. 80.67.22.220, zugreifen kannst. Dann schauen wir mal weiter...

Hallo Kollegen und alle die es werden wollen. Hatte von Euch schon mal jemand den Fall, dass die Liste der Sicheren Absender in OL nicht funktioniert hat? Ich habe hier einen merkwürdigen Fall, bei dem die Junk-E-Mail-Funktion "Nur sichere Absender und Empfänger" nicht wie gewünscht funktioniert hat. Nach einigen Entstörversuchen mit der großen Keule (Postfach neu angelegt, Benutzerprofil neu angelegt), habe ich durch Zufall festgestellt, dass es nicht funktioniert sobald die Liste der sicheren Absender wieder importiert wurde. Also wenn die Liste der sicheren Absender leer ist, landen ankommende Mails von extern im Junk-E-Mail-Ordner, wenn der alte Inhalt wieder importiert wurde, landen alle Mails von extern im Posteingang. Die exportierte Liste habe ich ausgiebig untersucht, kann aber keinen offensichtlichen Fehler finden. Die aufgelisteten Adressen sehen plausibel aus und ich konnte keine Sonderzeichen finden. Im HEX-Editor fängt die Datei mit FF FE an und dann kommen nur die E-Mail-Adressen und Zeilenumbrüche (0D 00 0A 00). Es ist also offensichtlich, dass die Verarbeitung dieser Liste nicht funktioniert. Der Fehler lässt sich auch beliebig reproduzieren, selbst über verschiedene Postfächer hinweg. In der MS KB und hier im Forum konnte ich keinen Hinweis auf dieses oder ein ähnlich gelagertes Problem finden. Kennt jemand dieses Problem? Ist es vielleicht schon irgendwo dokumentiert und gibt es eine Lösung dafür? Vielen Dank im voraus, NeoLEX

So, dann will ich mal zum Abschluss berichten, damit die Anderen auch noch was davon haben. Ich habe jetzt dem technischen Benutzerkonto weitergehende Rechte im DNS eingerichtet und seitdem funktionieren die Aktualisierungen der DNS-Einträge wieder tadellos. Es hat also vermutlich im SP2 eine Änderung für den DNS-Server gegeben, wodurch die Zugriffsrechte etwas anders gehandhabt werden. Das Recht "Untergeordnete Objekte erstellen" ist nicht mehr für eine DNS-Registrierung ausreichend. Vielen Dank ITHome, du warst ein große Hilfe. Bis zum nächsten Mal NeoLEX

Die dynamisch Aktualisierung im DHCP ist aktiviert. A- und PTR-Einträge nur nach Aufforderung aktualisieren, beim Löschen der Lease verwerfen und die zur Aktualisierungsaufforderung unfähigen Clients (NT4, Non-Windows) werden zwangsregistriert. Die Registrierung erfolgt unter gesonderten Anmeldeinformationen. Das verwendete Benutzerkonto hat weder in der Domäne relevante Gruppenzuweisungen, lediglich "Domänenbenutzer" und "Internetverbot", noch ist es im DNS besonders berechtigt. Das DNS akzeptiert nur sichere dynamische Updates und die relevanten Zugriffsrechte für die Forward- und Reverse-Zonen scheinen "Authentifizierte Benutzer" = "Untergeordnete Objekte erstellen" zu sein. Es gibt zwar noch diverse Rechte für Dom-Admins und System etc. aber darunter fällt der technische Benutzer nicht. Das scheint mir zumindest Teil des Problems zu sein, da hier vorhandene Einträge nicht geändert oder gelöscht werden können. Die DHCP-Option, dass die Einträge bei Leaseablauf gelöscht werden sollen, wird dadurch jedenfalls konterkariert. Der DHCP-Client ist im Standard aktiv und die Reverse-Zonen passen zu den eingerichteten DHCP-Bereichen und den darin vergebenen IP-Adressen. Nachtrag: Das im KB-Artikel 926296 beschrieben Problem konnte ich ausschließen. Die Clusterfunktion hat in den letzten fünf Wochen nicht gewechselt und die Anmeldeinformation ist auf allen Clusternodes korrekt hinterlegt. NeoLEX