HeizungAuf5

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!

vor einer Stunde schrieb Sunny61:

Welches Update?

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!

vor 2 Stunden schrieb BOfH_666:

korrekterweise "Outlook fragt nach Kennwort" heißen?

check!

Hey,

vor 10 Minuten schrieb testperson:

welchen Stand hat denn der Exchange 2013

[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 :

vor 13 Minuten schrieb testperson:

AFAIK war eine Migration von Exchange 2010 zu 2013 RTM nicht machbar und es wurde mindestens CU1 oder CU2(?) benötigt.

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.

Am 7.10.2020 um 16:28 schrieb Dominik Weber:

Zum testen eventuell den Drucker über TCP/IP direkt auf einem TS einrichten. Hat bei kleinen Kunden (1-2 TS) bei uns auch viele Probleme gelöst.

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,

vor 17 Stunden schrieb testperson:

Hast du denn die Office ADMX

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.

vor 17 Stunden schrieb testperson:

dass der Drucker halt nicht bei jeder Verwendung versucht sämtliche Einstellungen / Optionen zu aktualisieren

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.

vor 16 Stunden schrieb MurdocX:

Ich hab schon gesehen das einfache Druckaufträge von 200kb auf 700MB Druckauftrag aufgebläht wurden

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,

vor 42 Minuten schrieb testperson:

da könnte das https://gpsearch.azurewebsites.net/#12120 helfen

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?

vor 45 Minuten schrieb testperson:

ob die Drucker auf dem Printserver im Treiber Optionen angehakt haben, um Zubehör [...]automatisch bei jedem Druckjob zu erkennen

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.

vor 15 Minuten schrieb Sunny61:

Ist Terminal02 auch korrekt aktiviert?

Ja. Dieser hat ebenfalls einen Key für Windows Server 2019 Datacenter eingetragen (Bevor jemand ums Eck kommt: Ja, wir haben auch die Lizenz dazu und nicht nur nen Key  )

vor 16 Minuten schrieb Sunny61:

Hast Du den Lizenzserver auch per GPO den beiden RDS Servern bekannt gemacht? https://it-dude.de/anleitungen/server-2019-remotedesktop-service-terminalserver-lizenzserver-gpo/

Danke. Das wars! - Diese Richtlinei habe ich nicht gesetzt, da ich davon ausgegangen bin, dass er sich den Lizenzserver nach der Einstellung im Server-Manager (siehe oben) zieht. GPO gesetzt, läuft.

Grüße!

Hallo zusammen.

ich habe in unserer Umgebung 2 Terminalserver, welche sich beide an den RDS CALs, die auf einem Server eingetragen sind bedienen sollen.

Kurz zum Aufbau:

Beide Server sind Windows Server 2019 Datacenter. Terminalserver gibt es "Terminal01" und "Terminal02", wovon Terminal01 der RDS Lizenzserver ist und auch die RDS CALs (sind - falls es wichtig sein sollte per User CALs -) eingetragen hat.

Nun möchte ich, dass sich der Terminal02 ebenfalls an den RDS CALs von Terminal01 "bedient".

Dazu habe ich bereits auf Terminal02 im Servermanager -> Remotedesktop-Dienste -> Bereitstellungseigenschaften ändern den Lizenzserver angegeben.

In den "Bereitstellungsservern" tauch der Terminal01 ebenfalls auf:

Wenn ich mir nun auf dem Terminal02 die RDS-Lizenzdiagnose anschaue, erhalte ich die Meldung, dass keine RDS Lizenzen da seien.

Kann mir jemand sagen, wo ich falsch abgebogen bin?

Danke!

Hallo zusammen,

zuerst sorry für die späte Rückantwort.

Am 7.8.2020 um 14:25 schrieb Sunny61:

Sind denn die verwendeten Treiber aktuell?

Ja. Es sind jeweils die aktuellsten Treiber der Hersteller vorhanden. Lediglich für den HP gäbe es noch eine Major Version 4, diese ist aber nicht verwendbar. Scheint aber ein bekantnes Problem zu sein, wenn man danach im Web sucht. Die V3 wird von HP aber noch weiter gepflegt.

Am 7.8.2020 um 13:14 schrieb testperson:

schau mal mit dieser Verknüpfung, ob die Drucker da sind: %SystemRoot%\explorer.exe shell:PrintersFolder

Jup. Da sind die Drucker da.

Grüße!

vor 14 Minuten schrieb Sunny61:

allen Benutzern auf allen Clients

So richtig eingrenzbar ist das nicht wirklich. Bei manchen gehts immer (dass die Drucker angezeigt werden), bei manchen gar nicht, bei manchen nur manchmal. Alle Benutzer und Geräte sind in der gleichen Domäne mit gleichen GPOs.

In der Ereignisanzeige ist auch nichts dazu findbar.

Hallo Zusammen,

wir haben mal wieder eines der unbekannten Windows 10 Phänomene.

Wir verteilen unsere Drucker von einem Printserver per GPO an die Clients. Funktionierte bisher auch wunderbar. Seit gestern haben wir aber den Sachverhalt, dass die Drucker in der Systemsteuerung und in der Einstellungsapp von Windows nicht mehr auftauchen.

Interessanter Weise sind die Drucker in allen Anwendungen (Office, Webbrowser, etc) die Drucken können, vorhanden (auf mit Pfand zum Printserver) und auch mit WMIC sind die Drucker alle sichtbar:

Die Drucker per Script zu entfernen und per GPUpdate wieder zu ziehen führt zum gleichen Effekt. Auch Drucker entfernen und manuell über den Explorer zu verbinden sieht so aus.

Jemand eine Idee, wie ich die Drucker in den Einstellungen wieder sichtbar kriege?

Danke!

Hallo zusammen,

ich habe nun mal die Registry nach dem Screenrecorder durchsucht. Leider ist das Ergebnis eher ernüchternd. Die gefundenen Einträge sind die Einträge, wo das Programm installiert ist, damit es in der Deinstallationsliste in der Systemsteuerung steht.

Der Einzige Pfad, mit dem ich nicht viel anfangen kann ist unter "HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Compatibility Assistant\Store". Dort  stehen aber auch Einträge von Programmen drin, die wiederum nicht in der Zugriffsliste für das Mikrofon stehen.

Am 26.6.2020 um 18:48 schrieb Damian:

Im Event-Log gibt es auch keine seltsamen Meldungen?

Leider nein.

//edit

Hab noch was gefunden (hier). Die Einstellungen sind wohl unter "HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\CapabilityAccessManager\ConsentStore\microphone" zu finden. Allerdings mit einer Kryptischen Zeichenkette hinter dem Appnamen. Jemand eine Idee, wie ich die RDP "Anwendung" hier hinzufügen kann, dass die auch erkannt wird?

//edit2

Kommando zurück, hier sind nur die Apps aufgelistet, nicht aber programme

Grüße!

Hallo @Damian

sorry für die verspätete Antwort. Habe wohl keine Mail Benachrichtigung erhalten.

Am 22.6.2020 um 21:25 schrieb Damian:

Hast Du einmal die Mikrofoneinstellungen des betroffenen Rechners mit denen der funktionierenden Systeme verglichen?

Leider ja. Ich habe auf beiden Rechner die Einstellungen zum Mikrofon-Datenschutz wie folgt:

Generell funktioniert das an meinem "Problemkind" auch. Testweise einen Screenrecorder auf der Maschine installiert, der kam nach dem ersten Start automatisch in die Liste.

Hast Du vielleicht eine Idee, wo, diese "Programme die das Mikro verwenden dürfen" gespeichert werden (Registry?) - Dann müsste ich ja theoretisch die Einstellungen aus dem funktionierenden Rechner exportieren und hier händisch einfügen.

Grüße!

Niemand eine Idee?

Schade :(

vor 5 Stunden schrieb gqcdrdtim5:

Wenn du inzwischen auf 2004 geupdatet hast, lautet der problematische Patch KB4557957. Schau mal nach, ob der installiert ist und ob eine vorübergehende Deinstallation das Problem löst

Danke! Das wars. Der Patch war tatsächlich installiert. Deinstalliert: geht wieder.

Grüße!

vor 12 Stunden schrieb gqcdrdtim5:

Windows-Update (KB4560960).

Ist auf dem Rechner nicht installiert.

Hab auch mal das Update auf Windows 10 2004 durchgezogen. Leider keine Besserung.

Was mir noch aufgefallen ist, sobald ich eine Testseite auf den Drucker schicke, stürzen die Druckdialoge ab. Könnte ich aber nicht sagen, ob sich das gestern auch so reproduzieren hätte lassen.

Eine generelle Erkennung vom Drucker kann ich aber glaube ich abhaken. Eigenschaften wie Patronenfüllstände werden richtig angezeigt:

Virenscanner ist auf dem Rechner bis auf einem (aktuell deaktivierten) Defender nicht aktiv.

Grüße!

vor 37 Minuten schrieb Sunny61:

Der USB-Anschluß ist in Ordnung?

Der vom Laptop denke ich mal schon. Ein USB Stick an dem Port funktioniert zumindest. Einen anderen Drucker zum Testen habe ich nicht da. 

vor 37 Minuten schrieb Sunny61:

An einem anderen Anschluß hast Du getestet?

Den Drucker? Den hab ich an einem anderen Gerät (Macbook) getestet. Dort druckt er.

Grüße!

//edit

Hab den Drucker jetzt auch mal umgesteckt. Also gleiches Notebook, anderer USB-Port. Leider gleiches verhalten.

Hallo @Sunny61

vor 4 Minuten schrieb Sunny61:

Spooler beenden, jetzt in C:\Windows\System32\spool\PRINTERS alles löschen was da ist. Spooler wieder starten

Der Ordner ist leer. Wenn ich einen Druckauftrag starte, legt er zwar Dateien da drin ab, die verschwinden aber auch wieder, wenn die Auftragswarteschlange auf 0 zurückspringt.

Danke!

Hallo zusammen,

ich habe ein kleines Problem, mit meinem USB Drucker.

Seit heute (letzte Woche ging es noch) kann ich auf dem Drucker nichts mehr ausdrucken. Kurioser Weise bekomme ich auch keine Fehlermeldung. Versuche ich, etwas auf diesem Drucker auszudrucken, zählt die Warteschlange kurze Zeit hoch und springt dann wieder auf null (Wie es normalerweise auch aussieht), allerdings passiert einfach "nichts".

Was ich bereits probiert habe:

• Drucker neu "gestartet"
• Rechner neu gestartet
• Drucker entfernt, Treiber aus dem Geräte-Manager und der Druckerverwaltung gelöscht. Den Drucker dann auch aus der Registry gelöscht.
• Drucker automatisch erkennen lassen, oder auch per Treiber-Installier installieren lassen

Aktuell erkennt Windows 10 den Drucker wieder wie folgt:

Am Drucker selber scheint es nicht wirklich zu liegen, wenn ich das Mac Book meiner Frau dran packe, funktioniert das alles wunderbar.

Jemand noch eine Idee, was ich versuchen könnte?

Danke!

Systeminfos

Drucker ist ein Brother MFC 290c, der Laut Brother auch noch Windows 10 tauglich sein sollte

Windows 10 ist ein Windows 19 1909. Upgrade auf 2004 versucht ich gerade noch.

Hallo zusammen,

ich habe an einem Rechner das Problem, dass das Mikrofon nicht in eine RDP Sitzung "mitgenommen" werden kann. .RDP Datei stimmt und von anderen Rechnern aus funktioniert es auch.

Was ich allerdings gesehen habe, dass auf dem Rechner, von dem aus es nicht funktioniert (Ist ein Windows 10 Pro) in den Einstellungen unter Datenschutz -> Mikrofon der Eintrag Remotedesktop fehlt. An den anderen Rechnern, wo das Mirofon in der RDP funktioniert existiert der Eintrag:

Jemand eine Idee, wie ich die Remtotedesktop "Anwendung" in die Liste bekomme?

Grüße und Danke!