Forseti2003

Noch eine Zwischenfrage, der genutzte Server-Manager ist der lokal auf dem betroffenen Server oder Remote? Kann eventuell eine Firewall-Einstellung zu machen? Bspw. wenn das erkannte Netzwerk nicht mehr Mitglied der Domäne ist?

Prüf mal ob über Nacht Updates eingelaufen sind - eventuell hat da etwas zugemacht.

Du hast ja eine Sammlung in der beide RD-Sitzungshost eingebunden sind. Sobald Deine drei User eingeloggt sind kannst Du in der Sammlung mitteilen das auf Sitzungshost X "Keine Verbindungen zulassen" - dann leitet der Broker die Anfragen automatisch auf die restlichen Verfügbaren um. Das geht über den Server-Manager grafisch oder mittels PowerShell-Befehl, was Dir lieber ist.

Nicht zu vergessen, man kann auch neben dem Veeam Backup & Replication das Veeam Endpoint Backup für Free einsetzen. Damit mußt Du zwar auf dem betreffenden virtuellen Server das direkt installieren und einrichten, aber bei zwei Kisten kein Problem und der Vorteil ist, das Deine Anforderungen komplett abgedeckt wären (inkrimentiell etc.).

Guten Morgen in die Runde, stelle mal gerade wieder fest, Zertifikate sind nicht so mein Ding. Vorab der Aufbau: 1x Sessionbroker / RD-Gateway / WebAccess 6x RD-Sitzungshosts 2x Domaincontroller 1x Stammzertifizierungsstelle (für intern) Alle Server sind auf Windows Server 2012 R2 installiert. Anmeldungen erfolgen an die RDS-Sammlung alle intern mittels VPN aus den Subnetzen. Zur Anmeldung kommt eine gemischte Landschaft: Windows10, 7, XP, ThinClients (Liscon/Igel) Gestern lief das Zertifikat für den Sessionbroker aus, habe dieses erneuert und mir dabei gedacht, das es praktisch wäre eine Wildcard-Zertifikat einzusetzen um die Zertifikats-Bestätigungen auf den Win-PC's zu minimieren. Habe ein Zertifikat beantragt, alle Server die damit involviert sind eintragen lassen und beim Sessionbroker im ServerManager bei Bereitstellung eingetragen, gleichzeitig dieses Zertifikat an die Hosts importiert und dort eingebunden. Danach konnte kein User mehr sich am System anmelden, außer er hat bei der MSTSC die Warnung ausgeschaltet. Der Hinweis war der Fehlermeldung war auf Sperrzertifikate - aber an jedem PC ist das Root-Zertifikat installiert. Danach habe ich die Hosts wieder zurück gestellt auf ihre ursprüngliche Zertifikate, bzw. hab diese auch erneuert, wenn diese am ablaufen waren. Ergebnis: Es konnten sich soweit wieder User anmelden, mit Ausnahme an einem Host - dieser verweigerte dann mit dem Hinweis auf 0x607 Authentifizierungsfehler. Dort nochmal alle Zertifikate rausgeworfen, aus der Bereitstellung geworfen, die RD-Dienste neuinstallieren lassen, wieder eingebunden - selbes Problem. An was könnte das liegen? Im Prinzip sind alle Hosts geklont und bei jedem Server hab ich den selben Schritt gemacht (mein ich zumindest) Aber irgendwie will es nicht wirklich funktionieren. Hab mir zwar im Netz auch schon einige ToDo's zum Thema Zertifikate angesehen, aber ich werde daraus nicht schlau, wo mein Fehler liegt. Verstehe auch nicht, wieso das WildCard nicht geklappt hat. Zweites Problem was mir nun noch auffällt, was aber wohl eine Randerscheinung sein dürfte: ein XP-Rechner will sich überhaupt nicht mehr verbinden, egal was wir machen. Drittes Problem: Wenn wir die MSTSC vom RDWeb runterladen lässt sich an dieser nichts verändern, selbst wenn man nur den Benutzernamen einträgt, führt dies zu einer "Beschädigung der Remotedatei" und ist damit unbrauchbar. Also wenn einer zu einem der Punkte eine Idee hat, ich bin ganz Ohr. Grüße Forseti

Wieso geht es über die GPO nicht? Dein Deployment wird ja ungefähr so aussehen: 1x Sessionbroker, 3x RDS-Host - daraus kommt die Sammlung "Farm". Die Farm sollte bei den Eigenschaften auf Laufwerksmapping offen sein, im Anschluss eine GPO definieren und diese mittels WMI auf externe Clients filtern lassen. Innerhalb der GPO das Laufwerksmapping deaktiveren. Müsste eigentlich funktionieren.

Ist zwar ein interessanter Ansatz, löst aber das Problem nicht wirklich. Wie ich nämlich auch schrieb, hatte ich die Einstellungen des Benutzerprofilpfads in Word manuell geändert, aber auch diese Änderung greift ja nicht, insofern kann es nicht zwingend an der GPO liegen, .... Aber habe nun nochmal die Änderung manuell bei einem User reingeschrieben und jetzt greift die Arbeitsgruppenvorlage in Word wieder. Merkwürdig.

Du meinst aber VBR ich rede von VEB - VEB hat automatisierte Jobs.

Moinsen, weiss nicht, ob ich hier richtig bin, aber eventuell kennt ja schon jemand das Problem. Mittels GPO haben wir an unsere Terminalserver Benutzervorlagen-Speicherorte ausgegeben, die für MS Office 2010 greifen. Hat ja auch bisher jahrelang tadellos funktioniert. Heute stelle ich fest, das seit einem größeren Update auf den Terminalservern die Benutzervorlage lokal liegt und die Umleitungen aus der GPO nicht mehr greifen. Aus Testzwecken hab ich die Umleitung bei einem Benutzer manuell in Office geändert, aber darauf reagiert Office nicht und nutzt weiterhin den Benutzerprofilfpad. Ich schätze, das mit einem der Updates die eingespielt wurden, das Problem entstand, könnte auch sein, das es sich durch irgendeine Option ganz normal lösen lässt, ohne gleich alle Updates zu deinstallieren. Habt Ihr eine Idee, was es sein könnte? Grüße Forseti

Ja, kann ich nur bestätigen, das Treiberupdate funktioniert, ist aber so eine Sache, da wir hier nur Server einsetzen und keine Desktop-PC's kann man das ganze abschalten. Aber um im Thread zu bleiben, mein WSUS macht nach einem Update das ähnliche Problem, er verbindet sich mit sich selbst nicht mehr. Das KB 3159706 ist zwar installiert, aber die Nachbearbeitungsschritte aus dem Artikel kann ich nicht nachvollziehen, da das besagte zweite KB bei mir gar nicht vorhanden ist. Jetzt sitz ich irgendwie in der Zwickmühle, hau ich das ganze KB einfach nur raus und hoffe das es dann wieder läuft oder gibt es noch einen anderen Trick, da ja scheinbar das KB irgendwie doch benutzt wird, insofern verschlüsselte Updates zum ausrollen kommen müssten.

Schau Dir aber auch mal Veeam an - gerade die Endpoint Backup ist gar nicht so verkehrt, man kann damit schon gute Ergebnisse erzielen und das sogar auch auf visuellem Weg ;-) - vorallem ist es kostenlos.

Auf dem Terminalserver - die Verzeichnisfreigabe dient eigentlich nur dazu, das die authentifizierten Benutzer auch die Möglichkeit haben bei der Verbindung die Treiberkopien vom Druckserver auf den TS abzulegen. GPO sind ein Thema für sich. In einigen Fällen hilft es, wenn es alte GPO's sind diese zu löschen und komplett neu aufzusetzen. Aber auch gänzlich ohne Einsatz der GPO kann man je nach Mitarbeiteranzahl und Druckern gute Ergebnisse erzielen. Verschwindende Drucker ist meist ein Hinweis auf noch nicht bereinigte Registry-Einträge. Welche in Frage kommen wurden in diesem Thread ja schon ausführlich besprochen. Vorallem nicht vergessen, wenn Du einen TS bereinigst, mach Dir gleich die Mühe und säuber alles, danach erst die Druckwarteschlangen neustarten oder auch den TS neustarten. Sollten sich bereits Treiberfragmente verheddert haben, muss wirklich alles akribisch abgesucht werden. Das plötzliche Verschwinden deutet aber auf GPO's hin, die im Intervall ja sich ausführen und dann dabei die Drucker "killen" - ich würde eh empfehlen die Drucker in einer eigenen GPO zu bündeln.

mal ganz doof zwischengefragt, kann es sein das die User eine andere Zeitzone bei sich haben und daher der Client bei der Anmeldung nachträglich auf eine andere Zeit springt?

Also ich würde auch nicht unbedingt auf RoboCopy als Sicherungssoftware zurückgreifen wollen und mit Verlaub, der Einwand das PowerShell nicht zum Einsatz kommen soll, weil man kein Programmierer ist, aber sich dann gleichzeitig das Scripting mit RoboCopy anzutun ist nicht ganz nachvollziehbar. Um schon kleine brauchbare Ergebnisse mit PS zu bekommen, bedarf es lediglich zweier Trainings-Videos auf MVA und mal ein wenig Zeit um die Seite der Scripting-Guys durchzustöbern. Dann sollte der Umgang mit PS recht zügig von der Hand gehen. Habe anfänglich auch wie Du versucht mit Robocopy Daten zu "sichern" bin dabei aber recht schnell an Grenzen gekommen, deren Umsetzung einfach zu umständlich oder nicht beständig genug sind/waren. Sogar Exchange-Server kann man, wenn man möchte so sichern, aber es macht keinen "Spass" auf Dauer. Danach bin ich auch die Windows-Sicherungs-Software gestiegen, diese würde schon Dein Szenario sogar ohne PS weitgehend abdecken. Eine Sicherung des Fileservers bzw. der Datenlaufwerke geht ab 2012R2 ja ohne Problem. Die Sicherung kannst Du auf einen NAS auflaufen lassen und den NAS dann 1x am WE mittels großer USB-Festplatte quer sichern. Damit sollte schon ein ausreichendes Backupszenario vorhanden sein, wenn man noch keine großen Anforderungen/Ansprüche hat. Da wir aber im laufenden Betrieb auch mit den Windows-Server-Sicherungen einiges an Problemen hatten, bspw. die permanente Verfügbarkeit der FileShares, haben wir dann Veeam eingesetzt, bereits die Freeware deckt sehr viele Ansprüche ab, kann auch Shares nach dem Backup abtrennen so dass ein Virus/Trojaner am Server nicht direkt auf das NAS aufläuft. Achja, noch zur PS - ich würde es Dir dringend empfehlen - wenn man sich damit mal auseinandersetzt, wird man schnell Ansätze für seine tägliche Admin-Arbeit entdecken, die einem das Leben extrem erleichtern. Ein einfaches Skript ohne viel Aufwand und schon kann ich morgens prüfen ob ein User sich in der TS-Farm temporär angemeldet hat, den fehlerhaften Eintrag entfernen und der User kann wieder normal arbeiten. Manuell dauert das rund 10-15 Minuten pro User - mittels Skript bearbeite ich das in 10 Sekunden und ob das ein User oder 20 User sind, ist dann vollkommen egal. Ja, und ich hab kein PS-Admin im Namen oder der Signatur ;-)

Was haltet Ihr eigentlich von VeraCrypt? Auf den ersten Blick sieht und hört es sich ja zum Thema Datenverschlüsselung auch nicht uninteressant an, hat damit schon jemand Erfahrung?

Wenn ich das richtig lese, liegt das Problem eventuell nur an der Art Deiner Anbindung. Über Systemsteuerung - Neuen Drucker hinzufügen - Drucker im Netzwerk suchen - wird tatsächlich im Netzwerk nach Druckern gesucht. Werden diese erkannt, pflegt er diese dann so ein, wie sich er Drucker meldet. Wenn Du aber sagst, das Du Netzwerkdrucker hast, dann dürfte da ja auch ein Druckserver installiert sein? Dann reicht es schon aus, im Explorerer (Adressezeile) \\printserver\druckername (damit ist der Freigabename gemeint) einzutragen und der Drucker verbindet sich dann und zeigt den definierten Namen auch an. Wie Sunny61 dazu schreibt, die Freigabe sauber konfigurieren und auch den Drucker ins AD schreiben lassen, der Rest ist dann wirklich nur ein paar Klicks.

Auch noch ein Feedback von meinerseite, überwiegend haben wir nun das ganze in den Griff bekommen, Standarddrucker verstellen sich nun im Regelfall nicht mehr und Druck funktioniert auch. Wir gehen aktuell sogar über Druckserver und lassen die Aufbereitung über diesen und nicht am RDS laufen. Viele Fehler scheinen am Anfang so auszusehen, als gehören sie zusammen, was aber scheinbar überhaupt nicht der Fall ist. Man sollte sich am besten eine Checkliste zu legen und diese in jedem einzelnen Fall zwingend abarbeiten. Wir stellten dabei nämlich fest, das plötzlich, Stück für Stück und User für User, die Fehler abnahmen, einige bestimmte Fälle sogar recht rapide. Aktuell haben wir eigentlich nur noch zwei Arten von Fehlern, die aber auch nur noch gelegentlich auftreten: 1) Am Druckserver (!) verstellt sich bei einigen bestimmten Druckern (selber Hersteller) der Druckprozessor. Ist uns bisher 2x in den letzten 2 Monaten aufgefallen. Fehler lässt sich aber recht schnell beheben. 2) Einmal sporadisch will ein Drucker (meist einer der unter 1) sich bei einem Benutzer nicht mehr regulär anlegen lassen. Wird der Drucker neu verbunden sind die Eigenschaften doppelt und führt je nach Anwendung dazu, das kein Druck mehr erfolgt. Die Umstellung von einem NETBIOS-Namen auf einen FQDN erzielt dann aber die gewünschte Wirkung also anstelle von \\printserver\Drucker dann \\printserver.domain.tld\Drucker. Wer noch massive Probleme hat bei seinen Druckern kann mir auch gerne eine PN senden, allgemeine Erläuterungen find ich eher problematisch, da wirklich jeder Drucker und davon auch jedes Problem eine eigene Fehlersuche erfordert. Das reicht von Firmware am Drucker, über Universal-Treiber vom Hersteller, v3 und v4-Versionen müssen ein wenig getestet werden, auch hier gibt es starke Unterschiede. Die Benutzerprofile säubern, Registry reinigen, Druckwarteschlangen prüfen, Rechte nachsetzen, GPO prüfen und und und....es ist ein riesiger Rattenschwanz, wobei ich feststelle, je weniger Drucker-MischMasch vorliegt, desto niedriger sind auch die Probleme. Grüße Forseti

Bringt aber leider auch nicht wirklich viel. Wir haben versuchsweise die Drucker lokal aufgesetzt, die am meisten fehlerauffällig waren. Auch hier, ging eine ganze Zeit lang gut, so das wir dachten, okay Problem könnte damit umgangen werden, aber nach einigen Wochen haben sich dann auch da wieder Probleme eingeschlichen. Besonders auffällig, das die Druckgeschwindigkeit oder das Rendern bei der Vorschau in den Anwendungen sehr lang dauert. Irgendwie ist es derzeit so, als wenn man wirklich nur den Teufel mit dem Belzebub austreiben würde. Extrem frustrierend.

Ich glaub das wird mit 2012 R2 ein Klassiker. Also wenn man hier viele Lösungsvorschläge abarbeitet und die Updates einigermassen regelmässig auf die Server nachführt, genauso wie konsequent Treiberupdates durchführt, lassen sich einige Fehler dauerhaft eindämmen. Leider, nicht wirklich alle und einige tauchen immer mal wieder auf. Ein paar der Probleme, die immer irgendwie hängenbleiben: 1) Standarddrucker wird geändert (sporadisch, selten, unterschiedliche Benutzer) 2) Plötzlich mehrfach gleicher Drucker vorhanden, System erkennt nicht, das es der selbe Drucker ist 3) Registry-Eintragungen sind ein wenig wirr, führen nicht vorhandene Printserver auf oder falsche Eintragungen Lösungen dazu sind dann meist eh nur Registry-Bereinigen, Drucker entfernen neu installieren in der User-Session und bei 1) prüfen ob die MSTSC über den Sessionbroker das Deployment sauber zieht. Unter 2003 und 2008 hatte ich mit den ganzen Druckern nie derartige Probleme. Soll aber unter 2016, wie einige sagen, auch nicht besser werden.

Prüf mal als lokaler Administrator auf dem jeweiligen Terminalserver die Eintragungen in der Registry, auch die Eintragungen bei HKEY_USERS sind wichtig, da hier einige Einträge drin stehen, die später spontan Fehler auslösen können. Der Geisterdrucker ist meist ein Indiz für ein Fehler in der GPO oder Registry. Wenn es nur beim Chef und dann nur auf einem bestimmten TS auftritt, kannst Du Dir einiges an Arbeit sparen, wenn es auf allen TS vorkommt, musst Du am besten alle mal durchgehen. Empfehlen kann ich neben der Registry noch folgendes: 1) Universaltreiber - sofern mgl einsetzen. Darauf achten, je nach Drucker ob PS oder PCL - das kann schon für sich allein viele Fehler auslösen. Prinzipiell reagieren PS-Treiber besser, in einigen Fällen brauchen die Drucker aber PCL-Treiber 2) Firmware-Update der Drucker - HP ist da so ein Kandidat, der mit älteren FW gerne rumzickt 3) Druckwarteschlangen auf TS und Printserver prüfen, im Verzeichnis PRINTER ältere Aufträge entfernen. 4) Wenn alle User unten sind, über Druckserver alle Treiber rausfeuern und neu einlesen lassen. 5) Verzeichnis Spool Rechte für User einräumen 6) Vermeide die WSD-Anschlüsse bei Druckern und geh auf TCP 7) Stelle die Druckprozessoren auf WINPRINT ein Das sind mal so die Sachen, die uns am meisten geholfen haben. Gibt noch einige Detailsachen, aber das kommt dann auf das Fehlerbild direkt an. Wenn Du möchtest, kannst mich dazu ja gerne direkt anschreiben, dann können wir die Punkte mal durchgehen. Grüße Forseti

Der Windows Server 2012 R2 ist ein wenig eigen mit seinen Druckern - aber ein paar Punkte zu Deinem Setup, der HP LaserJet P2015 hat doch normalerweise auch eine LAN-Schnittstelle? Eventuell mal darüber ansprechen und die Geschwindigkeit im Vergleich testen. Ansonsten, sofern die ThinClients ein Winbasiertes OS haben, die Drucker dort anschließen und installieren und mittels Richtlinie auf den TS in die RDP-Sitzung nehmen, das kannst du über EasyPrint dann entsprechend konfigurieren. Der Netzwerkdrucker im Flur wird wohl deswegen schneller sein, da er über das LAN besser angesprochen wird, wir setzen bei uns prinzipiell nur LAN-Drucker ein und haben damit sehr gute Erfahrungen gesammelt. Entscheidend bei Deinen Treibern ist aber, vermeide Treibervielfalt, die nimmt Dir der 2012 schnell ganz krumm. HP bietet u.a. auch Universal-Treiber an, leider nur PCL Treiber, auch hier ein wenig aufpassen, einige Drucker arbeiten mit PCL5 besser, andere mit PCL6. Foxit hat bei uns auf den TS recht häufig gezickt, haben wir dann gegen PDFX-Change Viewer ausgetauscht, hiermit lief auch der Ausdruck größerer PDF's recht zügig. Solltest Du mit einem zentralen Printserver arbeiten, achte darauf, das die TS die Druckaufträge nicht verarbeiten, sondern zentral der Printserver, das vermeidet später Probleme in den Druckwarteschlangen. Auch nicht unwesentlich, solltest Du am TS direkt Drucker einbinden, gib das Spool-Verzeichnis für die User frei, da ansonsten öftersmal Zugriffsprobleme bei den Druckdaten entstehen.

okay, verstanden. Hab aber schon Rückmeldung vom Softwarehersteller, wir können das Scoring für den RBL höher setzen und später, wenn der Provider den SPF gemacht hat, die Software auf SPF umstellen. Dann sollte das erledigt sein, hoffe ich ;-) Danke für eure Mühen und Tipps.

Hab es mal an den Provider weitergeleitet, damit es nachgetragen wird. Der Verweis auf alle MX-Einträge sollte ja ausreichen um besser geschützt zu sein. Den Hersteller von der Anti-Spam-Software hab ich dazu auch mal angeschrieben, damit er hier evtl. was nachbessern kann. Wenn nicht kann ich die Blacklist ja auch direkt in den Exchange eingeben, dann lehnt er ja eh ab - wobei das mal vor längerer Zeit ein Problem war, da dann einige Mails uns nicht mehr erreicht haben. Ich beobachte mal weiter.

Ja, hier scheint der Hund begraben zu liegen, der SPF-Record fehlt. Soweit ich das jetzt weiss, muss das der Provider der Domain am Nameserver eintragen, korrekt? Oder muss ich da intern noch was setzen?

Letzteres kann ich Dir sofort beantworten: Wir setzen Exchange Server Toolbox als Anti-Spam-Programm ein, dort werden Scores anhand der einzelnen Prüfschritte ermittelt und dann entweder abgelehnt oder zugestellt. Problem in dem Fall dieser Mail besteht darin, das er den Score auf 2,9 setzt und somit ihn passieren lässt. Warum der Hersteller aber nicht erst eine Prüfung auf Blacklists durchführt und selektiert und danach den Rest in der nächsten Phase weiterprüft, kann ich nicht beantworten. Ist mir aber nun auch schon mehrfach aufgefallen, das er sich so verhält, muss mal mit dem Hersteller darüber sprechen, was er dazu meint. Aber zum ersten Teil, im Transportlog sehe ich auch nichts auffälliges Sender Recipients Recipient Count Message Subject Time Stamp Event Id Message Id Internal Message Id Client Ip Client Hostname Server Ip Server Hostname Connector Id Source Related Recipient Address Return Path Message Latency Recipient Status Total KBytes orders@meine.domain.de meineMail@meine.domain.de 1 [sPAM] RE: unpaid order 09.02.2016 16:54 DELIVER <38646AA6.206F8147@meine.domain.de> 67018669687083 Mail.meine.Domain.de Mail STOREDRIVER orders@meine.domain.de 00:00:11.5070000 311,69 orders@meine.domain.de meineMail@meine.domain.de 1 [sPAM] RE: unpaid order 09.02.2016 16:54 HAREDIRECTFAIL <38646AA6.206F8147@meine.domain.de> 67018669687083 Mail SMTP orders@meine.domain.de 309,59 orders@meine.domain.de meineMail@meine.domain.de 1 [sPAM] RE: unpaid order 09.02.2016 16:54 RECEIVE <38646AA6.206F8147@meine.domain.de> 67018669687083 192.168.4.40 Mail.meine.Domain.de Mail MAIL\Default MAILEX01 EMSC SMTP orders@meine.domain.de 309,59 orders@meine.domain.de meineMail@meine.domain.de 1 [sPAM] RE: unpaid order 09.02.2016 16:54 AGENTINFO <38646AA6.206F8147@meine.domain.de> 67018669687083 Mail AGENT orders@meine.domain.de 311,6 orders@meine.domain.de meineMail@meine.domain.de 1 [sPAM] RE: unpaid order 09.02.2016 16:54 SEND <38646AA6.206F8147@meine.domain.de> 67018669687083 192.168.4.40 Mail Mail.meine.Domain.de Organisationsinterner SMTP-Sendeconnector SMTP orders@meine.domain.de 00:00:11.5070000 250 2.1.5 Recipient OK 311,69