Andimann

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.

Wir benutzen keine Roaming Profiles, nein.

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.

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.

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

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?

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

Kann ich mir kaum vorstellen, dass außer bei mir noch nirgends das Problem aufgetreten ist. :confused:

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ß

Ja das mit dem RSOP.MSC hat mir auch noch geholfen. Danke für den Tipp.

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

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?

Nope, leider nicht. Das hatte ich als 2. versucht. ;)

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).

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.

Hallo zusammen, ich habe das Problem, dass per GPO gemappte Netzwerklaufwerke unter Windows 7 als "Nichtverbundenes Laufwerk" angezeigt werden. Der Zugriff darauf funktioniert allerdings. Das Auführen von Dateien kann aber schonmal nict klappen. Mir ist ja bereits bekannt, das Laufwerke (bei Anwendung von GPOs) nicht mehr (wie bei WinXP) über ein Loginscript mit "net use" verbunden werden, sondern direkt in der GPO unter "Benutzerkonfiguration / Einstellungen / Windows-Einstellungen / Laufwerkzuordnungen" hinzugefügt werden. Ich habe also schon ein neue GPO erstellt, die das so bewerkstelligt und sie mit einer neuen OU verknüpft, die alle Win7 User enthält. Die alte GPO (net use Script) ist mit der alten parallel liegenden OU für XP User verknüpft. Das ganze hat aber keine Abhilfe geschaffen. Auch der Eintrag GPO-FAQ No. 36 (Gruppenrichtlinien - Übersicht, FAQ und Tutorials), auf den hier schonmal hingewiesen wurde, hat nicht geholfen (zumal er eh für XP gilt). Desweiteren nützt das Erstellen eines Registry-Eintrags "EnableLinkedConnections" nicht, der hier mal empfohlen wurde: t-error.ch - tag: enablelinkedconnections Ich habe bereits hier im Forum und über Google nach einer Lösung gesucht. Allerdings haben die meisten das Problem, dass sie ein "Nichtverbundenes Laufwerk" nicht gelöscht bekommen oder Laufwerke erst garnicht gemappt werden. Hat jemand eine Idee, was ich falsch mache??? Gruß

Aber genau das ist ja das Problem, dass ich die gleichen Einstellungen definieren muss. Konkretes Beispiel: Laut default domain controller policy haben die User <domain>\ASPNET <domain>\SUPPORT_388945a0 NT AUTHORITY\LOCAL SERVICE das Recht, sich als Dienst anzumelden. Jetzt muss ich aber erreichen, dass ein weiterer manuell angelegter AD-User das auch darf, soll aber diese GPO nicht verändern. Also bleibt mir nur übrig, eine weitere GPO anzulegen und dem User dort das Recht zu erteilen. Diese neue GPO wird dann als zweites nach der default domain controller policy abgearbeitet. Wird dadurch nicht die erste Einstellung überschrieben, sodass die 3 User <domain>\ASPNET <domain>\SUPPORT_388945a0 NT AUTHORITY\LOCAL SERVICE nicht mehr das Recht haben sich als Dienst anzumelden und das AD läuft nicht mehr ordnungsgemäß??? Das gleiche Problem habe ich z.B. auch bei "Anmelden als Stapelverarbeitungsauftrag" oder "Einsetzen als Teil des Betriebssystems". Das Ändern der Kennwortrichtlinie in der default domain policy ist also legitim? Maximum password age von 42 Tagen ist auch arg krass, kann man den Benutzern ja kaum zumuten.

Hallo zusammen, ich bin gerade dabei, parallel zu einer alten Win 2003 Domain eine neue aufzubauen, und designe gerade neue GPOs, die sich natürlich an den Alten orientieren. Dort wurden damals (vor meiner Zeit in der Firma) einige Änderungen an den der "default domain controller policy" und der "default domain policy" vorgenommen (Kennwortrichtlinie, zusätzl. Benutzer bei "Anmelden als Dienst" oder "Anmelden als batch", etc.). Laut MS sollen diese Default GPOs ja nicht geändert werden. Erstelle ich eine zusätzliche GPO, die die gleichen Einstellungen festlegt, und priorisiere diese höher, gibt es doch sicherlich Probleme. Wie wird dieses Problem üblicherweise gelöst? Danke für Hilfe im voraus!

Hallo zusammen, danke für eure Antworten. Ich kann mitlerweile verstehen, dass ihr einen besseren Überblick über das Gesamte haben möchtet, um bessere Tipps zu geben. Deshalb hier noch ein paar Details: dmetzger hat schon richtig erkannt, dass es auch darum geht, zwei unterschiedliche Exchange Organisationen zu vereinen. Die Vorteile liegen auf der Hand: ein gemeinsames Gobales Adressbuch, Frei-/Gebucht-Zeiten werden angezeigt, und vor allem einheitliche E-Mail-Adressen. Aber auch abseits von Exchange soll der Zugriff auf Ressourcen wie Windows Freigaben, Sharepoint Server oder das zukünftige gemeinsame CRM vereinfacht werden. Des geht jetzt auch schon über einen Trust, aber innerhalb eines Forrests ist es dann doch komfortabler. Warum es jetzt speziell eine Sub-Domäne sein soll, kann ich auch nicht genau sagen. Aber die Muttergesellschaft hat mehrere verschiedene kleiner Unternehmen eingekauft, um seine Kompetenzen zu erweitern. Diese kleineren Unternehmen sind jetzt quasi einzelne (Länder-)Standorte, die aber relativ autonohm arbeiten und deshalb auch im AD getrennt bleiben sollen. Administrativ heißt das, dass ich als Admin weiterhin meine eigenen Sicherheitslinien fahren und Postfachgrößen bestimmen kann. Bei den anderen haben bzw. werden sie es auch mit einer Sub-Domäne machen, deshalb werden wir uns nur schwer wiegern können. Zur DNS-Frage: Es macht also Sinn, auf dem ersten DC der Sub-Domäne vor dem Ausführen von dcpromo die DNS-Server der Root-Domäne einzutragen. Steht die Dub-Domäne dann, kann auch ein lokaler DNS Server in den Verbund rein installiert werden. Korrekt? Gruß

Das ist letztendlich nicht meine Entscheidung, sondern die des IT-Management der Muttergesellschaft. Gibt es denn triftige Gründe die gegen eine Sub-Domäne sprechen? Ich will eigentlich jetzt auch garkeine Grundsatzdiskussion vom Zaun brechen. Lieber wären mir Antworten auf meine Fragen. Lieben Gruß

Ich glaube du verstehst da was falsch. Firma A hat die Domäne firmaA.de. Firma B hat die Domäne firmaB.com. Firma B kauf Firma A ein und möchte Firma A in ihr eingenes AD integrieren. Also wird firmaA.de abgeschafft und stattdessen eine neue Sub-Domäne von firmab.com erstellt. (wir sind übrigens Firma A) ;)

Hallo zusammen, ich habe ein paar Fragen zu folgendem Szenario: Die bestehende Win2003 Domäne firma.de soll abgeschafft werden. Stattdessen soll eine neue Win2003 Sub-Domäne der Muttergesellschaft entstehen, die über VPN mit der Hauptdomäne repliziert. Ich habe jetzt bereits einen ersten (virtuellen) Windows 2003 Server R2 installiert, der bereit ist, DNS Server und DC zu werden. 1. Kann ich im bestehenden Netzwerk (im gleichen Subnetz), wo bereits die Domäne firma.de mit DNS Servern läuft, parallel einen DNS Server für die neue Sub-Domäne installieren, oder kommen die sich in die Quere? 2. Macht es sinn, erstmal anstatt eines eigenen DNS Servers die DNS Server der Hauptdomäne als primär zu setzen? 3. Wie geht man bei der Installation der neuen Sub-Domäne am besten vor? 4. Gibt es triftige Gründe, die neue Sub-Domäne in einem anderen Subnetz als die bestehende Domäne firma.de aufzubauen? Das würde erheblichen Aufwand u.a. in den Bereichen Routing/VPN/Firewall erzeugen. Danke im Voraus für Tipps!