Smidddi

Hallo, der Zugriffsfehler auf dem Zertifikat irritiert ein wenig. Gibt es da noch genaueren Input? Kannst du den Wizard nochmal durchführen? Vom Grundsatz stellt sich mir allerdings die Frage: Warum möchtest du den Server per http/https/rdp von außen erreichbar machen?

Guten Morgen zusammen, vor ca. 2 Monaten hat es einen Kunden bei uns auch erwischt. Die Probleme fingen ziemlich zeitgleich mit einem Update der Druckertreiber (leider stehen nur V3 Treiber zur Verfügung) an. Nachdem ich gestern dann diverse Anpassungen und Bereinigungen in der Registry (auch den Key zum Disconnect der Drucker bei Benutzerabmeldung gesetzt), Anpassungen in den Gruppenrichtlinien, Treiberbereinigungen, automatisch ausgeführtes Script zum Trennen aller Drucker und Wipe der Registry (Client Side Rendering) etc. gemacht habe sah es für meinen Benutzer soweit gut aus, die Drucker wurden nur noch einfach und nicht bis zu 5-fach angezeigt. Bei den Anwendern hat das genannte Prozedere leider keine Auswirkungen gehabt, weiterhin werden alle Drucker doppelt (zum Glück nicht mehr dreifach oder als verwaiste Objekte) bereitgestellt. Ein guter Hinweis kam schließlich vom IT Verantwortlichen des Kunden: Das Problem mit doppelt bereitgestellten Druckern tritt nicht bei Anwendern auf, die über Fatclients verfügen. Der Unterschied zwischen diesen Anwendern und den Thinclient-Usern ist, dass hier lediglich Remote-Apps verwendet werden. Dazu kommt der Loopbackverarbeitungsmodus (Modus: Zusammenführen) für Anwender, den ich an dieser Stelle ebenfalls noch prüfen werde (beim Admin ist alles in Ordnung, Unterschied zu Anwendern: Die Richtlinie zur Verbindung der Drucker wird nicht angewendet). Ich werde heute noch ein wenig verifizieren und im Anschluss Rückmeldung geben. Kleiner Nachtrag: Die Änderungen gestern hatten zur Auswirkung, dass nun teilweise Ghost Sessions auftreten (nur bei den Remote-App Usern...)

Guten Morgen Squire, danke! Daran hatte ich nicht gedacht. Der Workaround gefällt mir zwar nicht wirklich weil noch irgendetwas an diesem Server defekt ist, aber so habe ich etwas Zeit gewonnen.

Guten Tag, derzeit stehe ich an einem Exchange 2010 (SP3, UR16) auf einem SBS2011 (tagesaktuelle Updates) vor folgender Herausforderung: https://social.technet.microsoft.com/Forums/exchange/de-DE/3fc4f18a-8c14-46fb-b6a6-f8a187b1c788/assistent-zertifikatkonfiguration-bleibt-hngen?forum=exchange_serverde Im Prinzip habe ich dasselbe Problem mit der Erweiterung, dass auch ein manuell erstelltes Zertifikat nicht mehr importiert werden kann (weder per Shell, noch per GUI). Es wurde geprüft und mit vergleichbaren SBS2011 Installationen abgeglichen: - AD - DNS - Exchange Dienste - IIS Konfiguration In 5 Minuten werde ich den Server neu starten (warum auch immer wurde irgendwann die UAC deaktiviert...). Sollte auch nach dem Neustart mit aktivierter UAC keine Besserung auftreten bin ich mit meinem Latein am Ende und wäre für jeglichen Vorschlag dankbar. Zeitlich kann ich mit Sicherheit sagen, dass die Funktionen noch bis zum 30.03.2016 in Ordnung waren. Nachtrag: Auch nach Neustart und aktivierter UAC keine Änderung. Powershell funktioniert weiterhin, sobald ein cmdlet in Bezug auf die Zertifikatsverwaltung (get-... funktioniert allerdings noch) ausgeführt wird hängt das cmdlet und kann nicht fertiggestellt werden.

Nachdem diverse Versuche keine Erfolge gezeigt haben wurde die Dokumentvorlage nun angepasst...Also keine plausible Lösung für das Problem vorhanden.

Clear Type ist getestet. Ich muss den Fehler weiter etwas einschränken: Wordpad i.O. Excel i.O. (!) Also möchte ich die RDS ausschließen und werde mich mal weiter der Word Thematik widmen.

Juhu, danke für die Hinweise. Kleiner Nachtrag noch: An einem "normalen" Client (Windows 10, Office 2013 oder Office 2016) funktioniert die Schriftart (btw: TrueType) wunderbar. Die Installation ist grundsätzlich dieselbe (Vollinstallation, OneNote, OneDrive sowie sonstige ungewünschten Programme nicht mit installiert). Der Unterschied ist lediglich die Edition: Einmal OPEN, einmal PKC.

Guten Morgen zusammen, die Schriftart Keystrokes MT wurde bei Microsoft gekauft und hat bislang ordentlich funktioniert. Mittlerweile tritt ein interessantes Phänomen auf: - Windows 2008R2 RDSH + Office 2010: Schriftart wird korrekt dargestellt - Windows 2008R2 RDSH + Office 2013: Schriftart wird nicht (also wikrlich garnicht, der geschriebene Text ist nicht vorhanden) dargestellt - Windows 2012R2 RDSH + Office 2013: Schriftart wird nicht (also wikrlich garnicht, der geschriebene Text ist nicht vorhanden) dargestellt - In Wordpad wird die Schriftart auf sämtlichen Systemen korrekt dargestellt any ideas? Die Schriftart wurde auch schon in der neuesten Version installiert (Schriftfarbe "weiß" ist auch als Fehler auszuschließen :-)) Edit passte den RDHS nach RDSH an...

Moin zusammen, gibt es eine einfache Möglichkeit, den Empfang von E-Mails über interne Absender von externen Quellen in Exchange 2016 zu verbieten? (also user@domain.tld darf nur via exchange.domain.tld versenden, E-Mails von einem anderen Mailserver werden direkt verworfen)

get-exchangecertificate -> Gebundene Dienste anschauen -> Wenn es das SMTP Zertifikat ist: Verlängern

/solved Lösung: Kopf-Tisch... Nach Installation einiger Updates in folgender Reihenfolge hat das Ganze (VC++ Runtime Installation und anschließend auch die Office Ausführung) geklappt...Nichtsdestotrotz habe ich noch keine Erklärung, warum die Server selbst nach 3-4 Tagen keine Updates mehr angezeigt haben (und diese nach der Installation des KB2919355 nun verfügbar sein sollen) 1.KB2919442 2. KB2919355 3.KB2932046 4.KB2937592 5.KB2938439 6.KB2934018

Ah und @ Nobby: Ja, ist eine VL (habe ich selbst heruntergeladen :-)). Auf einem anderen Client habe ich das nun so noch nicht getestet, aber ich verfolge gerade konsequent noch den Ansatz: Kopf - Tisch (wenn es ein simpler Admin-Fehler war muss ich leider wirklich ausrasten)

Nope, ich zweifle nur gerade an mir selbst. Aber Norbert, wenn du das gerade laufen hast: Kannst du mal bitte bei dir im C:\Windows\system32 respektive SysWOW64 schauen, ob die oben angesprochene DLL vorhanden ist?

Hallo Zahni, die Updates wurden alle online gesucht und alles an verfügbaren Updates installiert, auch sämtliche die für VC++ angeboten wurden.

Hallo zusammen, folgende Struktur: - 4 x Windows Server 2016 Datacenter (2 x DC, 2 x Fileserver) - 1 x Windows Server 2012R2 Datacenter (Terminalserver / Remote Desktop Sitzungshost) - Office 2016 Standard OPEN NL Folgendes Problem: Der Terminalserver wurde von mir ebenso aufgesetzt wie jede Menge anderer Terminalserver (sprich Windows, alle Updates, Remote Desktop Dienste, erneute Updates falls verfügbar, Installationsmodus starten, Anwendungen, Installationsmodus beenden, Updates). Nach der Office Installation erhalte ich beim Start von Programmen die Fehlermeldung WINWORD.EXE - Systemfehler Das Programm kann nicht gestartet werden, da api-ms-win-crt-stdio-l1-1-0.dll auf dem Computer fehlt. Installieren Sie das Programm erneut, um das Problem zu beheben. Es spielt keine Rolle, ob Office 2016 Standard in 32 Bit oder 64 Bit Version installiert wird. Auch macht es keinen Unterschied, ob das System zuvor in den Installationsmodus versetzt wurde. Auf der Suche nach der Fehlerursache habe ich glaube ich sämtliche diesbezüglichen Technet- und Foreneinträge durchforstet und die vorgeschlagenen Anpassungen durchgeführt (auch mit manuellem Entpacken des KB2999226). Ich bin langsam mit meinen Ideen am Ende, es kann doch nicht sein, dass Office 2016 nicht kompatibel zu Windows Server 2012R2 als RDSH ist... Any ideas?