Jump to content

Andimann

Members
  • Gesamte Inhalte

    22
  • Registriert seit

  • Letzter Besuch

Profile Fields

  • Member Title
    Newbie

Fortschritt von Andimann

Contributor

Contributor (5/14)

  • Erste Antwort
  • Engagiert
  • Erster eigener Beitrag
  • Eine Woche dabei
  • Einen Monat dabei

Neueste Abzeichen

10

Reputation in der Community

  1. Hallo zusammen, so, kleines Update: In OWA scheint das Problem nicht aufzutreten. Ich hab die Benutzerin aber gebeten, das nochmal regelmäßig zu prüfen. Nebenbei habe ich auf ihrem PC das Outlook Profil komplett gelöscht und neu angelegt (inkl. aller 9!!! shared mailboxes auf die sie Zugriff hat/braucht). Ich habe bei allen Postfächern bewusst den Cache Mode beim Einrichten und vor dem ersten Outlook-Start deaktiviert. Auch dann tritt das Problem nach einiger Zeit wieder auf. Desweiteren fragt Outlook immer nach dem Passwort für den Zugriff auf eine bestimmte shared mailbox, die auf einem anderen Exchange Server in der parent domain gehostet ist.
  2. Ja wir haben eben mal Cache Mode für alle Postfächer deaktiviert und nochmal den Eintrag aus der Auto-Completion-List gelöscht. Trotzdem erhalten wir noch die Fehlermeldung.
  3. Achso, jetzt weiß ich, was du meinst. Ersteres. Also unter E-Mail-Konten alle einzeln über "Neu..." hinzugefügt und nicht unter dem Hauptkonto. Für jedes Konto gibt es eine eigene OST Datei. Mit der anderen Variante hatten wir in der Vergangenheit mal schlechte Erfahrungen gemacht.
  4. Könntest du mir den Unterschied erklären? Die Postfächer sind in der Systemsteuerung unter Mail/Exchange E-Mail-Konten manuell eingebunden. Ohne Automapping. Der Benutzer hat FullAccess
  5. Hallo NorbertFe, danke für deine Antwort. Das habe ich schon getan, wie oben beschrieben oder kann es daran liegen, das eines der anderen in Profil eingerichteten Postfächer im Cache Mode läuft?
  6. Hallo zusammen, einer unserer User hat ein Problem mit dem Versenden von E-Mails an einen bestimmten Empfänger (eine Shared Mailbox) auf dem gleichen Exchange 2010 Server (Ja ich weiß, alt, aber wir migrieren bald zu O365). Der User erhält ständig die folgende Fehlermeldung: Fehler bei der Nachrichtenzustellung an folgende Empfänger oder Gruppen: <Adresse> Die eingegebene E-Mail-Adresse konnte nicht gefunden werden. Überprüfen Sie die E-Mail-Adresse des Empfängers, und versuchen Sie, die Nachricht erneut zu senden. Wenden Sie sich an den Helpdesk, falls das Problem weiterhin besteht. Diagnoseinformationen für Administratoren: Generierender Server: <server.ad-domain> IMCEAEX-_O=MAIL_OU=EXCHANGE+20ADMINISTRATIVE+20GROUP+20+28FYDIBOHF23SPDLT+29_CN=RECIPIENTS_CN=address@ad-domain.com #550 5.1.1 RESOLVER.ADR.ExRecipNotFound; not found ## Ursprüngliche Nachrichtenköpfe: Received: from <server.ad-domain> ([::1]) by <server.ad-domain> ([::1]) with mapi id 14.03.0399.000; Wed, 19 Sep 2018 11:19:10 +0200 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: binary From: Last name, firstname <e-mail-adress> To: <Adress> <IMCEAEX-_O=MAIL_OU=EXCHANGE+20ADMINISTRATIVE+20GROUP+20+28FYDIBOHF23SPDLT+29_CN=RECIPIENTS_CN=address@ad-domain.com>, Subject: blabla Thread-Topic: blabla Thread-Index: AdRP+bq/sJ7llr0HSzCLPM8nw4rAIg== Date: Wed, 19 Sep 2018 11:19:09 +0200 Message-ID: <541A7E013D86F345BB7032090185C44D0A9C7B87@server.ad-domain> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: yes X-MS-TNEF-Correlator: <541A7E013D86F345BB7032090185C44D0A9C7B87@server.ad-domain> MIME-Version: 1.0 X-Originating-IP: [10.0.0.188] Die betreffende Shared Mailbox war vorher mal eine Verteilergruppe. Die Gruppe wurde gelöscht, eine neue Shared Mailbox mit gleicher E-Mail-Adresse angelegt, AD Replikation durchgeführt, Offline Addressbuch neu erzeugt, das ganze Programm. Danach hatten wir auch über einen Monat keine Probleme damit. Folgendes habe ich schon versucht: - Eintrag aus der Auto-Completion-List löschen (die Fehlermeldung lässt darauf schließen), keine Änderung - Offline Adressbuch auf dem Client gelöscht und neu heruntergeladen, danach funktionierte es für eine Test, eine halbe Std später nicht mehr - Den Outlook Cache Mode deaktiviert, danach funktionierte es auch eine Weile, später nicht mehr Im Adressbuch des Servers sollte alles korrekt sein, andere Benutzer können fehlerfrei Mails an diese Shared Mailbox senden. Der Client unterscheidet sich eigentlich nur in dem Punkt von anderen Clients, dass wirklich sehr viele Shared Mailboxes in das Outlook Profil eingebunden sind (ca. 8) Hat jemand Erfahrungen mit dem Problem und kann helfen? Viele Grüße
  7. Kann ich mir kaum vorstellen, dass außer bei mir noch nirgends das Problem aufgetreten ist. :confused:
  8. Hallo zusammen, weiß nicht genau ob das Thema besser hier oder im Allgemeinen Windows Client Forum angesiedelt ist. Ich habe vor 3 Wochen unsere PCs mit ADMT in eine neue (Sub-) Domäne migriert. Hat alles soweit ganz gut geklappt. Jetzt hab ich aber auf allen WinXP Clients das Problem, das MSI-Installationen den folgenden Fehler bringen: Auf den Windows-Installerdienst konnte nicht zugegriffen werden. Dies kann vorkommen, wenn Sie Windows im abgesicherten Modus ausführen oder der Windows-Installer nicht korrekt installiert ist. Wenden Sie sich an den Support, um Hilfe zu erhalten. Im App-Eventlog kommt folgende Warnung: Die Beschreibung der Ereigniskennung ( 1015 ) in ( MsiInstaller ) wurde nicht gefunden. Der lokale Computer verfügt nicht über die zum Anzeigen der Meldungen von einem Remotecomputer erforderlichen Registrierungsinformationen oder DLL-Meldungsdateien. Möglicherweise müssen Sie das Flag /AUXSOURCE= zum Ermitteln der Beschreibung verwenden. Weitere Informationen stehen in Hilfe und Support. Ereignisinformationen: 0x80070005; (NULL); (NULL); (NULL); (NULL); ; . Im System-Eventlog folgende Fehlermeldung: Der Dienst "Windows Installer" wurde mit folgendem Fehler beendet: Der angeforderte Nachschlageschlüssel konnte in keinem aktiven Aktivierungskontext gefunden werden. Mit dem Befehl "msiexec /regserver" lässt sich der Installer wieder ans Laufen bringen, jedoch geht die Registrierung nach einiger Zeit wieder verloren, meisten nach Neustart. Ich habe bereits die folgenden Artikel und einige weitere durchgearbeitet, ohne positive Änderung: Fehlermeldung "Auf den Windows Installer-Dienst konnte nicht zugegriffen werden" beim Installieren von Office Fehlermeldung "Fehler 1719. Auf den Windows Installer-Dienst konnte nicht zugegriffen werden" beim Hinzufügen oder Entfernen von Programmen Windows Installer deinstallieren und neu installieren [msiexec.exe] Das Problem kommt definitiv durch die Migration mit ADMT und ist beliebig reproduzierbar. Hat jemand dieses Problem auch schon mal gehabt und eine Lösung? Gruß
  9. Ja das mit dem RSOP.MSC hat mir auch noch geholfen. Danke für den Tipp.
  10. Gut, die einfachste Erklärung ist dich meist die Richtige. Es gab doch noch eine gemeine GPO, die das Startskript ausführte. Viel Zeit für eigene ****heit verschwendet
  11. So, ich bin wieder einen Schritt weiter: Ich habe rausgefunden, dass die Nichtverbundenen LW unter dem Systemkonto laufen und wie ich sie mit Hilfe der SysteminternalsSuite entfernen kann. Dazu rufe ich in einer CMD Box folgenden Befehl auf: psexec.exe -s net use u: /delete /yes Danach rufe ich noch gpupdate /force auf und melde mich ab und wieder an, sobald ich dazu aufgefordert werde. Anschließend sind meine beiden Netzlaufwerke korrekt da. Starte ich jetzt Windows neu, habe ich anschließend wieder nichtverbundene LW. Jetzt wird es noch verrückter: Es wird mir ein drittes nichtverbundenes LW angelegt, dass garnicht in der GPO konfiguriert ist, die mit der OU mit den Windows 7 Benutzern verknüpft ist. Diese LW steht nur in dem Startskript (net use) drin, dass bei der GPO ausgeführt wird, die mit der OU verknüpft ist, in der die XP User sind. Die beiden OUs liegen parallel auf einer Ebene, die GPO werden also nicht vererbt. Ich habe auch schon alle anderen GPOs durchgeschaut, um auszuschließen, dass das Startskript noch woanders ausgeführt wird. Im Benutzerobjekt unter AD-Benutzer und -Computer ist es natürlich auch nicht eingetragen. Aber da das dritte LW wieder gemappt wird, ist ja quasi bewiesen, dass das Startskript auch bei Win7 Benutzern ausgeführt wird. Gibt es die Möglichkeit die Anwendung der GPOs beim Systemstart/Login zu protokollieren?
  12. Nehme ich den gleichen Bachstaben, sagt er mir natürlich, dass der schon verwendet wird. Benutze ich einen freien, funktioniert es und das LW wird auch korrekt angezeigt. Ja, der Benutzer ist local admin und UAC ist eingeschaltet. Laut diesem Artikel werden in dem Fall die LW garnicht verbunden. Das kann ich so nicht nachvollziehen. Ich habe ein frisches Win7-System aufgesetzt und es der Domäne hinzugefügt. Beim Login mit einem User (für den die neue GPO greift, bei der das LW direkt in der GPO konfiguriert ist, also kein net use Batch) wurden die LW korrekt gemappt. Dann habe ich den User zu lokalen Admin-Gruppe hinzugefügt und neu gestartet. Danach wurden die LW wieder korrekt dargestellt. Aber: fahre ich den PC ohne Netzwerkverbindung hoch und melde mich an, werden die LW als unverbunden angezeigt, obwohl in der GPO konfiguriert ist, dass sie NICHT wiederverbunden werden. Muss man das verstehen? Wenigstens siehts wieder korrekt aus, sobald ich mich mit verbundenem Kabel einlogge. Die produktiven Workstations sind natürlich weiter das Hauptproblem: Ist das Problem der nichtverbundenen LW einmal da (weil früher noch das net use Script lief), kommt es immer wieder. Ich vermute, man bekommt das erst weg, wenn man die nichtverbundenen LW einmal entfernt hat. Kennt jemand einen Weg, z.B. über die Registry? (weder net use /d noch Rechtsklick-Trennen funktioniert).
  13. Der Gegentest ist ja schon erfolgt. Denn ich habe ja erst von net use auf den neuen Weg umgestellt, nachdem das Problem mit Win7 Clients und net use auftauchte und ich irgendwo im Netz einen Beitrag gefunden habe, das net use angeblich die Ursache dafür ist, was ja scheinbar doch nicht korrekt ist. Einen Tippfehler im UNC Pfad kann ich definitiv ausschließen. Denn erstens habe ich den schon gefühlte 20 mal überprüft, und zweitens wird das Laufwerk ja gemappt und ich kann darauf zugreifen. Es wird nur als unverbunden angezeigt und kann nicht gelöscht werden. Zum Berechtigungsproblem: Unter XP oder manuell unter Win7 kann ich mit dem User die Freigabe mappen und drauf zugreifen. Ein Berechtitungsproblem scheint es also auch nicht zu sein, es sei denn die Win7 Neuerungen haben ihre Finger im Spiel (UAC vielleicht? hab ich aber schon aus- und wieder eingeschaltet). Kann der Virenscanner schuld sein (Symantec Endpoint Protection)? Das Eventlog zeigt mir keine Fehler an.
×
×
  • Neu erstellen...