HeizungAuf5

Hey, Das hab ich eben versucht. Mein Aufbau sieht so aus: Connection Broker: 10.0.1.10 RDS01: 10.0.1.11 RDS02: 10.0.1.12 DNS Eintrag "TS-MeineSammlung" (DNS Eintrag ist identisch zum Namen der angelegten Sammlung) zeigt auf die 10.0.1.10. Verbindet sich jemand drauf, landet er aber direkt auf dem Connection Broker. Nicht-Admin Benutzer werden direkt abgewiesen und ebenfalls nicht auf einen der Terminal Server verbunden. Wo mach ich hier was falsch?

Hallo zusammen, ich bin gerade dabei, die erste RDS Farm/Sammlung zu erstellen (deswegen ist die Frage vielleicht etwas merkwürdig ) Konfiguriert habe ich die Sammlung nach dieser Anleitung. Hat soweit auch alles geklappt, Sammlung Anlegen, Server konfigurieren, alles gut. Als einen der abschließenden Schritte soll man ja nun die DNS Einträge mit dem Sammlungsnamen anlegen und jeweils auf einen der Hosts zeigen lassen. Hier steh ich aber glaub etwas auf dem Schlauch. In der RDS Sammlung kann ich ja den Lastausgleich konfigurieren. Allerdings wird die Einrichtung davon doch dann durch die DNS Einträge wirkungslos? Wird beispielsweise festgelegt, dass ein Server maximal 20 Sitzungen haben darf, durch Round Robin allerdings der DNS Eintrag des "vollen" Servers antwortet kommt der (21.) Benutzer dann trotzdem drauf? Das gleiche, wenn ein Benutzer sich über den Sammlungsnamen per RDP verbinden, der Server 1 aufgelöst wird, der Benutzer die Verbindung verliert und sich neu verbindet, dann allerdings der Server 2 aufgelöst wird. Wird der User dann (durch was?) wieder auf den Server 1 "verschoben", oder startet auf Server 2 dann eine neue Sitzung? Danke für eure Erleuchtung! Schönen Abend!

Ich nehme mal an, das muss ich auf dem Office 365 Exchange von bbb.com machen (oder doch auf dem Lokalen von aaa.de)? Schnallt Outlook das dann überhaupt, da es ja scheinbar versucht, über den eigenen Exchange den Benutzer aufzulösen. Ich teste mal.

Hallo zusammen, wir haben an einem Arbeitsplatz ein merkwürdiges Phänomen beim verschicken von Outlook Mail. Eingebunden sind dort 2 Postfächer. Eines zur Domain aaa.de (Lokaler Exchange) und ein Office 365 Postfach von der Domain bbb.com. Wird nun eine Mail von der aaa.de Adresse an einen Empfänger von bbb.com versendet funktioniert das beim ersten mal auch. Danach cached Outlook scheinbar den Empfänger und weitere Mails an den Empfänger von bbb.com kommen mit einem "Die eingegebene E-Mail-Adresse konnte nicht gefunden werden." zurück. Schaut man sich den String in der Return Mail an, wohin die Mail versucht wurde zu senden, sieht man, dass versucht wird der Kontakt über die aaa.de Domäne zu erreichen: <IMCEAEX-_O=ExchangeLabs_ou=Exchange+20Administrative+20Group+20+28FYDIBOHF23SPDLT+29_cn=Recipients_cn=4193d65c92c3411cbb99982752d80c62-m+2mustermann@aaa.de>, Gesendet wurde die Mail allerdings an m.mustermann@bbb.com. Den Outlook Cache zu leeren funktioniert zwar, aber eben nur ein mal. Jemand eine Idee, wie wir das Problem in den Griff kriegen? Ich vermute mal den X500 Eintrag zu setzen wird nicht viel bringen, da ja nicht mal die richtige Empfängerdomäne angesprochen wurde. Danke!

Sou, ich glaube ich habs ^^ Die Lösung des SysVol-Problems hat dann auch gleich die Problematik mit der AD-Verwaltung gelöst. An diejenigen, die durch die Suche auf dieses Thema gekommen sind: In diesem Video wird euch gut erklärt, wie ihr die Replikation reparieren könnt. Ca. 80% wusste ich noch so, aber mit einer "bestätigenden" Anleitung gehts doch deutlich einfacher. Danke Dir @NorbertFe!

Binge. Hat er nicht. (Daran hab ich noch gar nicht gedacht, shame und so ^^) Ein "For /f %i IN ('dsquery server -o rdn') do @echo %i && @wmic /node:"%i" /namespace:\\root\microsoftdfs path dfsrreplicatedfolderinfo WHERE replicatedfoldername='SYSVOL share' get replicationgroupname,replicatedfoldername,state" zeigt auf dem DC01 ist es mit dem Status 5 vorhanden und auf dem DC01 befindet es sich mit Status 2 noch in anfänglicher Syncronisation (Wohl seit über 2 Wochen, seit es den DC gibt.)

Done. Hab jetzt bei beiden als Primären den "guten" DC01 eingetragen und sekundär den DC03. Das ist auch genau das, wo ich auch keinen grünen Zweig komme. Die Einrichtung (Höherstufung) lief ohne Probleme durch und auch nen "repadmin /syncall" erklärt mir, dass alles tutti sei. Selbst wenn ich mit einem "repadmin /showrepl" den letzten Sync überprüfe, krieg ich auch keine Fehler zurück (auf dem DC03). Repadmin: Befehl "/showrepl" wird für den vollständigen DC "localhost" ausgeführt Default-First-Site-Name\DC03 DSA-Optionen: IS_GC Standortoptionen: (none) DSA-Objekt-GUID: 97ebcb50-99a7-43cc-9be5-73d1bc32f403 DSA-Aufrufkennung: 089ba02e-f89d-4582-8229-2db7c5d0620b ==== EINGEHENDE NACHBARN===================================== DC=DOMAIN,DC=local Default-First-Site-Name\DC01 über RPC DSA-Objekt-GUID: d46e8e5a-abc8-4815-af84-08b28fd3cc6f Letzter Versuch am 2021-10-16 15:31:31 war erfolgreich. CN=Configuration,DC=DOMAIN,DC=local Default-First-Site-Name\DC01 über RPC DSA-Objekt-GUID: d46e8e5a-abc8-4815-af84-08b28fd3cc6f Letzter Versuch am 2021-10-16 15:37:22 war erfolgreich. CN=Schema,CN=Configuration,DC=DOMAIN,DC=local Default-First-Site-Name\DC01 über RPC DSA-Objekt-GUID: d46e8e5a-abc8-4815-af84-08b28fd3cc6f Letzter Versuch am 2021-10-16 15:23:12 ist fehlgeschlagen, Ergebnis 8524 (0x214c): Ein DSA-Vorgang kann aufgrund eines DNS-Aufruffehlers nicht fortgesetzt werden. 1 aufeinander folgende Fehler. Letzte Erfolg um 2021-10-16 14:49:34. DC=ForestDnsZones,DC=DOMAIN,DC=local Default-First-Site-Name\DC01 über RPC DSA-Objekt-GUID: d46e8e5a-abc8-4815-af84-08b28fd3cc6f Letzter Versuch am 2021-10-16 15:31:25 war erfolgreich. DC=DomainDnsZones,DC=DOMAIN,DC=local Default-First-Site-Name\DC01 über RPC DSA-Objekt-GUID: d46e8e5a-abc8-4815-af84-08b28fd3cc6f Letzter Versuch am 2021-10-16 15:32:35 war erfolgreich. Quelle: Default-First-Site-Name\DC01 ******* 1 AUFEINANDERFOLGENDE FEHLER seit 2021-10-16 15:19:30 Letzter Fehler: 8524 (0x214c): Ein DSA-Vorgang kann aufgrund eines DNS-Aufruffehlers nicht fortgesetzt werden. Der Fehler um 15:19 dürfte gewesen sein, als ich testweise den DC01 nochmal runter gefahren hab. Gibt es eine Art "Richtig durchspühlen" Funktion, in der der DC03 seine komplette(!) Konfiguration und Replikation nochmal vom DC01 zieht?

Schemamaster DC03.DOMAIN.local Domänennamen-Master DC03.DOMAIN.local PDC DC03.DOMAIN.local RID-Pool-Manager DC03.DOMAIN.local Infrastrukturmaster DC03.DOMAIN.local Als DNS Server sind bei den beiden DCs jeweils als primärer Server sich selber (127.0.0.1) und als sekundärer DNS die IP des jeweils anderen DCs. In den Logs zum DFSR finde ich rellativ häufig das Ereignis 5014, dass er das "Gegenüber" nicht erreichen kann. Ist ja aber logisch weil aus. Der DFS-Replikationsdienst beendet die Kommunikation mit Partner DC01 für Replikationsgruppe Domain System Volume aufgrund eines Fehlers. Der Dienst wird regelmäßig versuchen, die Verbindung wiederherzustellen. Weitere Informationen: Fehler: 1722 (Der RPC-Server ist nicht verfügbar.) Verbindungs-ID: DF021ADE-C732-4ED0-AADE-6295CBA0FCAC Replikationsgruppen-ID: 6E32825A-2D30-437E-8F1E-491296DEE836 Ein paar Sekunden später habe ich das Ereignis 4612 Der DFS-Replikationsdienst hat SYSVOL im lokalen Pfad "C:\Windows\SYSVOL\domain" initialisiert und wartet darauf, die erste Replikation auszuführen. Der replizierte Ordner bleibt im ersten Synchronisierungsstatus, bis er mit seinem Partner DC01.DOMAIN.local repliziert wurde. Wenn der Server zu einem Domänencontroller heraufgestuft wurde, führt der Domänencontroller keine Ankündigung durch und dient als Domänencontroller, bis dieses Problem behoben wurde. Dies kann darauf zurückzuführen sein, dass der angegebene Partner sich selbst in einem ersten Synchronisierungsstatus befindet. Eine weitere mögliche Ursache ist, dass auf diesem Server oder beim Synchronisierungspartner Zugriffsverletzungen aufgetreten sind. Wenn dieses Ereignis bei der Migration von SYSVOL aus dem Dateireplikationsdienst (FRS) zur DFS-Replikation aufgetreten ist, werden die Änderungen nicht nach außen repliziert, bis dieses Problem behoben wurde. Dies kann dazu führen, dass der SYSVOL-Ordner auf diesem Server nicht mehr mit anderen Domänencontrollern synchron ist. Weitere Informationen: Name des replizierten Ordners: SYSVOL Share ID des replizierten Ordners: 7E67AD4E-520F-451B-8C69-BFE867F3DF0E Replikationsgruppenname: Domain System Volume Replikationsgruppen-ID: E499178F-DCF6-48D5-813B-054E84E3D4C7 Mitglieds-ID: F0F7BCD8-CFE4-495D-B43A-42CE2D10807F Schreibgeschützt: 0 Danach gibt es noch das Ereignis 5008 Fehler beim DFS-Replikationsdienst bei der Kommunikation mit Partner "DC01" für Replikationsgruppe "Domain System Volume". Dieser Fehler kann auftreten, wenn der Host nicht erreichbar ist oder der DFS-Replikationsdienst nicht auf dem Server ausgeführt wird. Partner-DNS-Adresse: DC01.DOMAIN.local Optionale Daten, falls verfügbar: Partner-WINS-Adresse: DC01 Partner-IP-Adresse: 192.168.15.10 Der Dienst versucht regelmäßig, die Verbindung erneut herzustellen. Weitere Informationen: Fehler: 1722 (Der RPC-Server ist nicht verfügbar.) Verbindungs-ID: E499178F-DCF6-48D5-813B-054E84E3D4C7 Replikationsgruppen-ID: 6E32825A-2D30-437E-8F1E-491296DEE836 Für die Directory Services finde ich einen Fehler, dass der den globalen Katalog nicht finden kann (ID 1126) Die Active Directory-Domänendienste konnten keine Verbindung mit dem globalen Katalog herstellen. Zusätzliche Daten Fehlerwert: 1355 Die angegebene Domäne ist nicht vorhanden, oder es konnte keine Verbindung hergestellt werden. Interne ID: 320137b Benutzeraktion Überprüfen Sie, ob der globale Katalog in der Gesamtstruktur verfügbar ist und von diesem Domänencontroller erreicht werden kann. Zur Diagnose dieses Problems können Sie das Hilfsprogramm "nltest" verwenden. Mehr Gedanken mache ich mir hier um die Warnung 2092 Dieser Server ist der Besitzer der folgenden FSMO-Rolle, die jedoch nicht als gültig eingestuft wird. Für die Partition, die das FSMO enthält, wurde dieser Server seit dem letzten Neustart nicht erfolgreich mit einem beliebigen Partner repliziert. Replikationsfehler verhindern die Verifizierung dieser Rolle. Vorgänge, die eine Kontaktaufnahme mit dem FSMO-Betriebsmaster erfordern, sind nicht erfolgreich, solange dieser Zustand nicht behoben wird. FSMO-Rolle: DC=DOMAIN,DC=local Benutzeraktion: 1. Die ursprüngliche Synchronisierung ist die erste Replikation, die von dem System beim Start durchgeführt wird. Das Scheitern der ursprünglichen Synchronisierung ist eventuell die Ursache dafür, dass die FSMO-Rolle nicht verifiziert werden kann. Dieser Prozess wird im KB-Artikel 305476 erklärt. 2. Dieser Server verfügt über mindestens einen Replikationspartner, und die Replikation scheitert bei allen Partnern. Führen Sie den Befehl "REPADMIN /showrepl" aus, um die Replikationsfehler anzuzeigen. Beheben Sie den fraglichen Fehler. Es sind eventuell Probleme mit der IP-Konnektivität, der DNS-Namenauflösung oder mit der Sicherheitsauthentifizierung aufgetreten, die die erfolgreiche Replikation verhindern. 3. In dem Ausnahmefall, dass alle Replikationspartner voraussichtlich offline sind (z. B. zu Wartungszwecken oder zur Notfallwiederherstellung), können Sie die Verifizierung der Rolle erzwingen. Führen Sie NTDSUTIL.EXE aus, um die Rolle für den gleichen Server zu übernehmen. Dieser Vorgang sollte entsprechend den Schritten, die in den KB-Artikeln 255504 und 324801 unter "http://support.microsoft.com" aufgelistet sind, durchgeführt werden. Die folgenden Vorgänge werden eventuell beeinträchtigt: Schema: Sie können das Schema für diese Gesamtstruktur nicht mehr modifizieren. Domänenbenennung: Sie können keine Domänen zu dieser Gesamtstruktur hinzufügen bzw. daraus entfernen. PDC: Sie können auf dem primären Domänencontroller keine weiteren Vorgänge durchführen, wie z.B. die Aktualisierung von Gruppenrichtlinien oder das Zurücksetzen von Kennwörtern für nicht in Active Directory Lightweight Directory Services vorhandene Konten. RID: Sie können keine neuen Sicherheits-IDs für neue Benutzer- oder Computerkonten bzw. für Sicherheitsgruppen zuweisen. Infrastruktur: Domänenübergreifende Namensverweise, wie z.B. universelle Gruppenmitgliedschaften, werden nicht ordnungsgemäß aktualisiert, wenn das Zielobjekt entfernt oder umbenannt wird. Grüße!

Hallo zusammen, erstmal ja, mir ich für den Titel wirklich nichts besseres eingefallen, wenn jemand Vorschläge hat, gerne her damit . Zum eigentlichen Problem: Wir haben in einer Infrastruktur 2 DCs (Beide Server 2019). Wenn beide Server online sind, funktioniert auch alles bestens und ich kann das AD von beiden Servern verwalten. Fahre ich einen DC herunter funktioniert das auch noch wunderbar, dass der andere DC das im Alleingang macht. Alles kein Problem. Allerdings funktioniert es anderherum nicht. Fahre ich den 1. DC herunter, während der Zweite läuft ist nach ca. 5 Minuten, oder nach einem Neustart des verbleibenden DCs (Wozu dieser dann auch knappe 10 Minuten braucht - normal ist ca. eine) Schicht im Schacht. Beim versuch die AD Verwaltung aufzurufen bekomme ich die Fehlermeldung: Ist der andere DC wieder erreichbar, funktioniert wieder alles ohne Probleme. Zur Vereinfachung kurz eine Übersicht, was klappt und was nicht: Es gibt in dem Netz 2 DCs (DC01 und DC03; FMSO Rollen sind bei DC03). DC01 online + DC03 online -> Alles ok DC01 online + DC03 offline -> Alles ok DC01 offline + DC03 online -> oben genanntes Fehlerbild Verwunderlich ist nur, dass sämtliche Anzeigen für eine AD Replikation (in meinen Augen) gut aussehen. Sind beide DCs online, werden auch beide in der AD Konsole als online angezeigt. Auch der "fehlerhafte" DC03 Ebenso läuft ein "repadmin /syncall" ohne Probleme durch (auf beiden DCs). Die Problematik hatten wir so 1:1 schon mit dem DC02. Damals haben wir noch eine "kaputte" Windows Installation im Verdacht, weswegen es nun den DC03 gibt. Hat von euch jemand eine Idee? Danke und Grüße!

Hallo zusammen, Das hab ich gesetzt und auch testweise mal per GPO direkt den Registry Key vergeben. Leider interessiert Windows der Standarddrucker weiterhin nicht wirklich. :( Grüße!

Hallo zusammen, ich habe auf einer neuen TS 2019 Installation ein Merkwürdiges Verhalten bzgl. Standarddrucker. Die Drucker werden von Hand über den Printserver (Explorer auf, \\printserver, Rechtsklick auf Drucker, verbinden) eingebunden. GPO gibt es hierfür keine. Funktioniert auch so weit, bis auf die Thematik Standarddrucker. Nach Einbinden der Drucker kann ich den zwar als Standard festlegen, dann bekommen die auch den grünen Haken, allerdings hält diese Einstellung nicht sonderlich lange an. Teilweise 5 Minuten, teilweise bis zum nächsten Anmelden. Interessant ist auch, dass es nicht immer der gleiche Drucker ist, auf den Windows zurückspringt. Manchmal ist es der Microsoft PDF Printer, manchmal aber auch ein Drucker, der verbunden ist (aber nicht Standarddrucker sein soll). Die Drucker werden in der TS Sitzung direkt verbunden und nicht über RDP "mitgenommen". Mit dem Haken "Windows verwaltet Standarddrucker" haben wir bereits gespielt. Leider ohne Ergebnis. Jemand noch einen Tipp für mich? Danke!

Hallo zusammen, in einer Umgebung wurde der Mailserver zu Office 365 migriert. Funktioniert auch alles wunderbar, bis auf einem Rechner, an dem sich das Outlook weigert, das Office 365 Postfach einzubinden. Trag ich die Mail Adresse ein, versucht Outlook die Verbindung, bricht danach aber ab, dass "etwas nicht geklappt" hat. Sieht so aus: Video Der Benutzer hat einen normalen Domänen Account. Melde ich mich mit dem Admin auf dem Rechner an, funktioniert alles ohne Probleme. Andere Benutzer mit ihren Office 365 Postfächern auf ihren Rechnern haben keine Probleme. Dort funktioniert alles wunderbar. Getestet wurde bereits: - Office neu installiert (Office 365) - Neues Outlook Profil angelegt - Versucht das Postfach im Assistenten über "ich möchte manuell" und dann Office 365 gewählt - Den Benutzer auf dem Rechner zum Admin gemacht Irgendwie sieht mir das aus, als ob Outlook den Autodiscover nicht hin bekommt. Da die Mails vorher bei einem anderen Hosted Exchange Anbieter lagen, wurde ebenfalls geprüft, ob dieser "Mach Autosidcover aus" Key in der Registry eingetragen wurde. Wurde er nicht. Jemand einen Tipp für mich, wie wir das Postfach in Outlook eingebunden bekommen? Grüße und Danke!

Hallo zusammen! Ich habe gestern mal den Workaround von @c0smic getestet. Also Outlook (und zur Sicherheit alles andere Office Gedönse) schließen, den genannten Wert umbenannt und Outlook wieder gestartet. Geholfen hat das genau einmal. Eine Mail konnte ich bearbeiten ohne Abfrage, danach war sie wieder da. Auffällig ist auch, dass der umbenannte Schlüssel gar nicht mehr angelegt wird. Das ist übrigens auch der Fall, wenn ich statt dem ConfigContextData Schlüssel den outlook schlüssel umbenenne. Neu angelegt wird da nichts. Grüße!

Hallo zusammen, ich habe hier ein etwas seltsames Problem (oder ich bin einfach zu doof die Einstellung zu finden). Wenn ich in Outlook eine Nachricht direkt aus der Standardansicht beantworte/weiterleite funktioniert alles wunderbar. Der Hinweis "Sie haben auf die Nachricht geantwortet" wird dann auch entsprechend in der Ursprungsmail eingefügt. Alles gut, Mache ich auf die Nachricht jedoch einen Doppelklick, so dass ich die Nachricht in einem eigenen Fenster sehe und beantworte / leite die Nachricht daraus weiter funktioniert das ebenfalls, nur bekomme ich beim schließen des Fensters der Ursprungsnachricht die Meldung "Outlook 2013: Die Eigenschaften der Nachricht [...]wurden geändert. Sollen Ihre Änderungen an dieser Nachricht gespeichert werden?". Wähle ich hier Nein, wird der Hinweis auf Weiterleitung/Antwort in der Ursprungsnachricht nicht hinzugefügt. Nur wenn ich explizit auf Ja klicke. Falls wir aneinander vorbei reden, welchen Hinweis ich meine: Weiß jemand, welche Einstellung ich brauche, dass dieser Hinweis zwa hinzugefügt wird, aber eben ohne, dass ich nochmal extra gefragt werde? Die hierbei oft erwähnten COM-AddIns habe ich bereits alle deaktiviert. Verwendet wird ein Office/Outlook 2016 mit Exchange 2013. Danke euch!

Hallo zusammen, wir betreiben einen Terminalserver mit Windows Server 2019 und Visio 2019 Pro (Version 2105). Nach der Installation von Visio ist mir aufgefallen, dass die Shape Suche nicht funktioniert: Testweise mal die gleiche Visio Version mit gleichem Installer auf meiner Windows 10 Mühle installiert, funktioniert ohne Probleme. Was ich bereits versucht habe: Visio als Admin starten / Als angemeldeter Admin Visio starten (um irgend nen Windows Rechte-Klimbims auszuschließen) Visio "repariert" Visio neusinatlleirt Windows Search Dienst geprüft (in irgend nem Microsoft Forenbeitrag den ich aktuell nur nicht mehr finde, hieß es, dass der Haken "Datenaustausch zwischen Dienst und Desktop zulassen" rein oder raus soll. Funktioniert bei mir in beiden Fällen nicht) Geprüft, ob die Visio Dateien im Suchindex dabei sind -> Sind sie Jemand noch einen Tipp für mich, wie wir die suche zum Laufen bekommen? Danke!

Hallo zusammen, wir haben vor kurzem einen Kunden mit Office 365 "Microsoft 365 Apps for Enterprise" ausgestattet. Funktioniert auch alles so weit top, allerdings gehen die Anmeldecodes ins leere. Wenn sich die Benutzer anmelden, bekommen Sie ab und an diesen Dialog, dass eine Mail mit dem Anmeldecode an die <Benutzername>@<Kundenname>.onmicrosoft.com gesendet wurde. Problem dabei ist, ich komme ja an die onmicrosoft.com Adresse nicht hin, da der Benutzer keinen online O365 Exchange hat. Weiß jemand, wie ich an den Anmeldecode kommen kann, oder zumindest die Mail Adresse ändern, an die die Mails gesendet werden, damit diese nicht im Nichts landen? Grüße und Danke!

Das vom Exchange. Die Outlook Clients waren ja bereits aktuell. Exchange Update von Microsoft heruntergeladen, installiert, fertig. Ging sogar ohne "Zwischenversionen". Grüße!

Hallo zusammen, das Update scheint es behoben zu haben. Zumindest kommt keine Anmeldeaufforderung mehr. Danke! check!

Hey, [PS] C:\Windows\system32>Get-ExchangeServer|ft Name,Edition,AdminDisplayVersion -AutoSize Name Edition AdminDisplayVersion ---- ------- ------------------- EXCHANGE02 Standard Version 15.0 (Build 516.32) Major : 15 Minor : 0 Build : 516 Revision : 32 FilePatchLevelDescription : Zumindest wurde sich nirgends beschwert, dass die Mirgration nicht funktioniert, weil die Version nicht pass. Ich installier aber mal die neuste CU und Prüfe ob das danach immer noch so ist. Grüße!

Hallo zusammen, wir haben seit heute morgen ein merkwürdiges Verhalten von Outlook. Wird Outlook gestartet verbindet es sich zum Exchange Server, also alles gut. Nach ca. 1 Stunde springt Outlook dann aber im Status auf "Kennworteingabe erforderlich" und zeigt die Anmeldemaste. Wird dort der Domänenbenutzer mit seinem Kennwort eingetragen, landen wir im "Anmeldedaten ungültig"-Loop. Kurzzeitige Fehlerbehebung schafft es, die Anmeldemaske weg zu klicken und Outlook neu zu starten. Dann ist, als wäre nichts gewesen. Aber auch nur wieder ca. für eine Stunde. Betroffen sind alle Benutzer. Jemand eine Idee? Kurz zum Umfeld: Exchange: Exchange 2013 Version 15.0 (Build 516.32) Clients: Windows 10 2004 und teilw. 20H2 Office: Office 365, keine Updates verfügbar und teilweise Office 2016, auch aktueller Stand. Der Exchangeserver wurde vor. 3 Tagen von einem Exchange 2010 Version 14.3 (Build 123.4) migriert. Das allerdings ohne Fehler. Könnte es damit zusammenhängen, dass der Exchangeserver noch in der Demo-Lizenz läuft (Lizenz ist bestellt, nur noch nicht da)? Danke und Grüße!

Hallo zusammen, sorry für die späte Antwort! Nach einigem hin und her und ausprobieren auf dem Terminalserver, sowie Printserver hat sich herausgestellt, dass der Terminalserver der alleinige Verursacher der Probleme ist. Testweise auf einem der Testserver ein Office Paket installiert, dort ohne jegliche Probleme. Sogar die bidirektionale Kommunikation funktioniere innerhalb von wenigen Sekunden. Daher haben wir uns dazu entschieden, den Terminalserver neu aufzusetzen, bevor er zu "voll" wird. Das getan haben wir keinerlei Probleme mehr mit den Drucken. Sogar das ansprechen von treiberspezifischen Einstellungen (wie z. B. Finisher) funktioniert nun reibungslos und ohne Verzögerung. Office ist zwar immer noch das Langsamste, aber die Wartezeit von aktuell ca. 2-3 Sekunden ist verkraftbar. Interessant wäre natürlich noch, was bei der "alten" Installation schief gelaufen ist, dass das so ausgeartet ist. Der Server hat jetzt wieder exakt die selbe Software wie vorher auch. Aber naja. Windows halt Danke für eure Mühen!

Hallo zusammen, ich habe die letzten Tage ein bisschen rumgetestet und dadurch etwas erkenntnissreicher geworden. Auf dem Printserver selbst funktioniert ein Druck problemlos in wenigen Sekunden. Testweise habe ich im Rechenzentrum einen zweiten Server (Ebenfalls Windows 2019) installiert und die Drucker dort vom Printserver eingebunden (Gleiche Treiber, gleiche Drucker). Dort funktioniert der Druck problemlos! So wie ich das sehe, liegt die Problematik also weniger auf dem Printserver, sondern eher auf dem Terminalserver. Hier jemand eine Idee, was den Druck so dermaßen ausbremsen kann? Installiert ist auf dem Terminalserver größtenteils Standardzeug und auch keine Software, die wir nicht wo anders auch einsetzen und wo die Drucker funktionieren. Hab ich getestet, funktioniert leider auch nicht. Selbst wenn ich alle Drucker entferne, dass ich nur noch den Microsoft PDF Printer und den OneNote Printer hab, sind die Druckdialoge kaum bedienbar. Danke!

Hallo Zusammen, Jup. Die hab ich. Hab die von hier genommen und importiert. Diese werden auch im Gruppenrichtlinieneditor angezeigt, allerdings habe ich unter Benutzerkonfiguration kein Miscellaneous (was ich einfach mal mit "Verschiedenes" oder "sonstiges" übersetzt hätte): Installiert ist auf dem Terminalserver ein Office 365. Gibts noch andere Stellen, an denen man das einstellen kann? Wie es scheint führt der Terminalserver trotz "fixer" Einstellungen erst mal die Prüfung auf Toner- /Papierstand durch. Habe ich gerade getestet, kann ich nicht bestätigen. Ein Druckauftrag, wo ich sicherlich 3 Minuten im Auswahldialog hing, hatte am Ende 82kb. Grüße!

Moin, Hab ich gerade angeschaut, bei mir gibts weder den "Pfad" in den lokalen Gruppenrichtlinien, noch den Registry Pfad. Oder bin ich in der Beziehung zu doof zum suchen? ;) Wenn ich die Richtlinie richtig interpretiere, ist die auch Primär "nur" fürs Office Paket gültig, richtig? Also Ausstattungsmerkmale (Hat der Drucker nen Finisher und die Papierschächte) sind bei jedem Drucker fix. Grüße und Danke!

Hallo zusammen, wir haben unsere "Arbeitsplätze" mittlerweile komplett zu Terminalserver im Rechenzentrum migriert. Funktioniert auch alles wunderbar, bis auf die Drucker. Kurz zum Aufbau: Im Rechenzentrum befindet sich ein DC, ein Printserver und eben auch mehrere Terminalserver (alles Windows Server 2019). Die Terminalserver und der Printserver haben als DNS nur den DC im RZ eingetragen. Die Terminalserver bekommen die Drucker per GPO vom Printserver im Rechenzentrum eingebunden, der diese wiederum per TCP/IP Anschluss verbunden hat. Die Server im Rechenzentrum haben dort ihr eigenes LAN, welches per Side-to-Side VPN mit dem LAN am Standaort verbunden ist. Ein durchschleifen der Drucker per RDP ist nicht vorgesehen und auch teilweise nicht umsetzbar. Die müssen vom Printserver direkt an den Terminalserver. Dabei haben wir nun folgendes Problem: Soll auf den Terminalservern gedruckt werden, dauert es teilweise extrem lange, bis die Drucker dort angesprochen werden können. Z. B. möchte ich eine PDF drucken, klicke also im PDF Viewer auf das Drucken-Symbol, muss ich ca. 10 Sekunden warten, bis ich das "Druckfenster" sehe. Wechsle ich danach den Drucker kann ich nochmal ca. 5 Sekunden warten. Das selbe, wenn eine Einstellung im Druckdialog verändert wird. Das bedeutet, dass ein Ausdruck von einer PDF gerne mal 2 Minuten in Anspruch nimmt. Wenn ich etwas auf Office drucken möchte, sehe ich schon eher woher der Wind weht. Klicke ich dort auf Drucken steht der Dialog erstmal für ca. 30 Sekunden auf "Suche nach verfügbaren Druckern", bevor der Standarddrucker angezeigt wird und ich darauf drucken könnte. In der Zeit ploppen auch immer wieder die kleinen Fenster "Verbindung zu Drucker wird hergestellt" auf. Will ich dann statt dem Standarddrucker einen anderen haben, klicke also auf die Auswahlliste dauert es wieder ca. 30 Sekunden, bis die Drucker erscheinen. Meine Vermutung dabei ist: Wenn der Terminalserver etwas drucken will, verbindet er sich nicht "nur" bis zum Printserver, sondern bis zu den Druckern bei uns am Standort (dabei muss er über eine sehr langsame VPN Verbindung (Internetverbindung am Standort ist nicht wirklich gut, deswegen ja alles ins RZ)) und braucht deshalb ewig um mit den Druckern zu sprechen. Kann ich das dem Terminalserver irgendwie austreiben? Ziel wäre, dass sich der Terminalserver nur noch bis zum Printserver verbindet und dort die Aufträge abgibt ("Prüf nicht erst, mach einfach!"). Somit würde die "Wartezeit" beim Verbinden auf den Printserver wandern und nicht mehr die Programme auf dem Terminalserver zum Absturz bringen. Hat hier jemand einen Vorschlag für mich? Noch kurz zum Verständnis, nicht dass wir uns falsch verstehen: Dass der gesamte Vorgang (also Benutzer will drucken bis hin zu Benutzer hält das Blatt in der Hand) nicht schneller werden kann ist mir klar, ich möchte die Wartezeit nur eben von den Benutzern weg bringen und auf den Printserver verlagern. Danke! Noch als Nachtrag: Testweise habe ich mal einen PDF Reader direkt auf dem Printserver installiert. Dort funktioniert die Druckerei ohne diese ewigen Wartereien.