Weingeist

Wieso tut man sich bei sowas kritischem wie ein DFS-Root verschiedene Server-Versionen/Stände an? Auch wenn die Chance eher klein ist, dass hier das OS der Schuldige ist weil an DFS nicht so wirklich entwickelt wurde, es ist halt unnötig ;) Da bleibt wie so oft nur Mühsam alles mögliche durchchecken - Kannst Du denn auf den Clients jedes der verschiedenen Ziele erreichen wenn Du direkt die FQDN eingibst? Also nicht nur von Deinem PC aus oder von jenen die gut sind? - Teste mal eine Firewallfreigaben In/Out mit vollen Berechtigungen zu den AD-Servern. Wenn es dann geht, blockt irgendwas. - Dann kann noch eine nicht gute Replikation zwischen den AD-Servern und somit dem DFS-Root ein Problem sein (Replikation prüfen), sprich Daten sind nicht gut bei einem AD - Dann kann sich ein Client per VPN evtl. einen "falsches" Fileserver anlachen, welcher gar nicht für seinen Standort ist und somit evtl. nicht erreichbar ist (oben eigentlich ausgeschlossen) - Zu guter letzt, wenn DNS nicht perfekt ist, dann läuft auch DFS nicht wirklich sauber (evtl. als erstes einfach mal DNS cache löschen im client)

Nicht von meinen Rumspiel-VM's. Da geht eh jedes zweite mal das OS hops wenn ich mal wieder was zuviel entfernt habe. Nur habe ich die Aufzeichnung normal auf einer separaten VHD die ich jeweils separat ablege/einbinde und wiederverwende. @zahniAuch wenn etwas OT: Ein Teil von Cortana ist nach wie vor drinn. Dazu gehört die Kernkomponente mit dem Indexkram + ein Teil der Aufzeichnungstasks sowie Autologger-Zeugs wenn ich mich richtig erinnere. Nur die Menge des indexierten Zeugs ist tiefer. Was davon am Ende tatsächlich genau übermittelt wird, weiss ich nicht. Angeblich wird aber auf die zahlreichen Index-Files zugegriffen während der Telemetrie-Kram eine Verbindung zu MS aufgebaut hat. Manche Datenschutz-Senstive Dinge wie Handschrifterkennung lässt sich nichtmal ohne weiteres vom Index ausklammern. Und das ist - soweit ich mich erinnere - wohl auch bei LTSC der Fall. Da der Krempel so eng mit dem Starmenü bzw. allgemein (fast) der ganzen Oberfläche verzahnt ist, geht es gar nicht mehr komplett ohne. An den relevanten Stellen rumschrauben ist "etwas" mühsam zu automatisieren. ;) @mltw: Wie bereits gesagt wurde, damit hast ein Server OS und brauchst unter Umständen eine andere Lizenzierung für Software die darauf läuft. VDA oder Enterprise für den zugreifenden Client würde gründsätzlich auch reichen. Dann hast auch Zugriff auf die LTSC-Versionen. Pro will man eigentlich eh nicht. Da wid ziemlich viel an "Telemtrie" übermittelt. Aber TS ist natürlich auch eine gute Lösung (auch wenn ich immer SA dazu nehme und es im Endeffekt wie Miete ist, aber eben halt mit Ausstiegsmöglichkeit und weiterbetrieb).

Cortana ist nicht identisch implementiert. Bei LTSC fehlt da ein Teil wenn auch nicht alles. Ich vermute das wurde wegen der Kompatibilität von Terminalservern mit Desktop OS so gemacht. Hatte mal etwas Zeit investiert und den Kram rausgeschrieben. Dummerweise habe ich die Test-VM wo diese Daten drauf waren aus versehen gelöscht wo ich die genauen Pakete und ein Teil der Einstellungen aufgeschrieben hatte. Habe diverse W10/S2019 Test-VM's die ich verändert habe, Telemetrie abgedreht etc. und dann all jene gelöscht wo ich dachte ich bräuchte sie nicht mehr, eine hätte ich noch gebraucht. ;) Probleme hatte ich mit LTSC auch noch keine. Allerdings verweigert meines Wissens z.Bsp. Adobe den Support. Ich wage zu behaupten, dass es MS tunlichst vermeiden wird, Office 365 tatsächlich auf LTSC einzuschränken. Habe schon von Grossfirmen munkeln gehört, dass sie angedroht hätten auf ein freies Office zu wechseln wenn das passiert. Gleiches mit den OnPremise Varianten von Office. Aber man wird sehen. MS hat jedenfalls kalte Füsse bekommen und wird ein 2022 anbieten. Das wird mit Sicherheit auf LTSC laufen. Ganz speziell darauf vermutlich =)

Für LTSC muss er aber auch Enterprise lizenzieren. LTSC 1809 ist nicht ganz identisch wie Server 2019. LTSC ist punkto zusätzlichem Zeugs sogar besser als die Server-Version. Also weniger von dem Desktopzeugs dabei.

Es ist nicht möglich und MS will das auch gar nicht ermöglichen weil sie Mietlizenzen verkaufen wollen. Mittlerweile bin ich wieder soweit, dass ich Client-Maschinen nicht mehr konsoldiere sondern einfach jedem Arbeitsplatz eine physische Maschine spendiere. Ökologisch ist das klar nicht wirklich.

Aus dem Grundsatz heraus ist es immer so, dass der Hauptnutzer eines physikalischen Geräts welches mit einer 0815 Kauflizenz lizenziert wurde, auf seine Maschine Remote zugreifen darf. Andere nicht. Der Hauptnutzer darf maximal alle 90 Tage wechseln. Wenn eine physikalische Maschine nicht von einem Hauptnutzer verwendet wird sondern von mehreren, ist es eine Serverähnliche Umgebung. Da gibt es den Hauptbenutzer nicht mehr, auch nicht der eine der hauptsächlich darauf arbeitet. Folglich muss es anders lizenziert werden. Bei VDA ist es dann z.Bsp. so, dass die zugreifende Maschine nicht-Windows-Maschine lizenziert sein muss +- egal worauf die Instanz dann läuft. Ist der zugreifende Client Windows basierend muss der zugreifende Client mindestens mit der (Client)OS-Version lizenziert sein wie auf die Maschine wo er drauf zugreift. Da nur die Enterprise oder Education Versionen von ClientOS eine installation in einer serverähnlichen Umgebung erlauben, musst Du die zugreifenden Clients eben auch damit lizenzieren. Rein mit Kauflizenzen kannst du konsolidierte Maschinen nur mit Server-OS und RDP-CAL's realisieren. Hierbei gilt es dann zu beachten, dass Du zwei Server-Standard Lizenzen brauchst, damit Du 3 Server-Instanzen auf der gleichen physischen Maschinen laufen lassen darfst wenn jeder sein "eigenes" OS haben möchte. Hoffe das war +- verständlich. MS macht die Bedingungen bewusst super mühsam, damit man eben die Mietlizenzen kauft wo die Freihehiten relativ gross sind man aber einen Status Quo nicht mehr mehr einfrieren kann z.Bsp. für ein altes System.

Auch wenn die Gesprächsprotokolle heute ziemlich stabil sind und mit instabilen Verbindungen tendenziell besser umgehen können als früher, wie sieht es mit der Internetverbindung aus? vorgeschaltete Firewall? --> z.Bsp. mit Wireshark die anzahl veworfene Pakete prüfen. Eine grosse Anzahl Verworfener Pakete führen gerne zu unerwünschtem Verhalten jeglicher Art in verschiedensten Programmen auch wenn der Speed eigentlich gut wäre. Auch innerhalb vom LAN. Testen kannst das z.Bsp. auch mit einem Mobiltelefon-Hotspot und WLAN. Also Ort mit gutem Empfang aussuchen, Hotspot auf dem Handy, per WLAN verbinden. Ist das Problem weg, ist das LAN/Internetverbindung/Firewall schuld, ansonsten eher deine Mühle oder das Gegenüber am Telefon bzw. dessen Umgebung.

Och da bin ich zumindest immer noch skeptisch bezüglich dem Sicherheitsgewinn. Die neuen Formate sind ZIP-Container, ob das wirklich ein Sicherheitsgewinn gegenüber dem rein proprietären Format ist und nicht nur ein Pseudo-Gewinn? In der Vergangenheit gabe os öfter mal Sicherheitsprobleme mit ZIP. Aber eben, reine Spekulation ;) Sobald Anhänge mit von der Party sind, ist DOCX aber defintiv besser, weil bessere Qualität ;)

Mit Schriftarten ist das manchmal so eine Sache. Es gibt Szenarien wo eine hinterlegte Schriftart durch jene in einer Vorlage ersetzt wird. So richtig nachvolziehen wann und wie genau konnte ich es damals nicht (hatte das mal vor 10 Jahren oder so). Gehäuft hat sich das Phänomen, wenn das abschliessende "Absatzzeichen" nicht in der Schriftart formatiert wurde sondern nur der Text. Sprich die Schriftart innerhalb des Absatzes so faktisch gewechselt hat. Ganz ähnliche Probleme gibt es manchmal mit der Gliederung und der Aufzählung. Wird der Text statt die entsprechende Formatvorlage angepasst, kann es sein, dass es neu formatiert wird. Was ich nun machen würde: - Prüfen ob das Zeilen-Abschlusszeichen ebenfalls die richtige Schrift ist - Analysieren auf welcher Formatvorlage die Dokumente basiseren (normal.dot oder was anderes) - Sicherstellen, dass überall richtige Formatvorlage auf allen Rechnern vorhanden ist, ansonsten verteilen - Sofern die hinterlegte Vorlage die Normal.dot ist, ist diese möglicherweise einem Windows-Upgrade zum Opfer gefallen und muss neu erstellt oder ausm Backup gezogen und auf allen Rechner ersetzt werden

Yep, den Neustart hätte ich evtl. noch erwähnen müssen, danke für den Hinweis. =)

Weiss nicht ob Du das wirklich auch so gemeint hast, aber ich nutze nach kurzer Abstinenz auch wieder vermehrt bzw. hauptsächlich fixe IP's. Habe deutlich weniger Ärger. Insbesondere bei Stromausfällen und solchen Spässen wo zBsp. die Clients nicht per USV abgesichert sind und dann teilweise selber wieder hochfahren, die Server aber nicht usw. Mit fixen IP's ist das total wurscht. Sonst immer wieder mal Ärger gehabt oder auch mal ne Doppelvergabe obwohl es das nicht geben sollte weil vielleicht DHCP abgeschmiert ist und den lease nicht mehr hatte, der alte Client seine aber noch hielt etc. Mit Reservierungen und danach fixer Hinterlegung im Client gibts das nicht. Auch Thin/Zero-Clients können so ohne irgend eine Reihenfolge wieder angestartet werden, also bevor Connection-Broker und DHCP da ist. Ich finde es deutlich entspannter. Auch DNS-Aktualisierung sind so fast nie notwendig, bleibt also alles irgendwie starr und nur sporadische Clients bekommen DHCP und fallen auch sofort als fremd auf. Habe aber auch nur mit kleinen Umgebungen zu tun. Da kann man die IP's gut fix vergeben. Bei grösseren dürfte wohl auch die USV jeweils per Notstrom abgesichert sein und die Server müssen so gut wie nie ganz runter ;)

Das einfachst wäre wohl den Dienst pausieren, Daten löschen, Dienst wieder starten. Dann sollte alles von vorne anfangen. Wenn es wieder seltsame Files gibt welche nicht per Cmdlet ersichtlich sind, ist es wohl ein "Feature per Design" =)

Stimmt im Grundsatz schon, sobald sich aber der Zeitstempel ändert, wird sie aber erneut einmalig ausgeführt. Sprich alleine das aktualisieren der Richtlinie bewirkt ein erneutes ausführen. Ein wirklich "einmalig" gibt es eben nicht wirklich. Sie lösen daher in der Regel das angestrebte Ziel nicht wirklich, weil eben im Grundsatz die Standardisierung angestrebt wird. Lohnen tut es sich je nach Situation für manche Ressourcenfressende Aufgaben.

Die GPO's bieten die Möglichkeit der Einmal-Ausführung nicht. Da musst selber etwas "basteln". Wäre üblicherweise auch etwas sinnfrei. Der Grundgedanke von GPO's ist die Standardisierung und nicht die individualisierung. Also genau das Gegenteil. ;) Ideen: Du könntes im User-Profil einen Reg-Eintrag erstellen welcher steuert ob der Standard geladen werden soll oder nicht. Die GPO dann via einen WMI-Filter welcher den Reg-Eintrag abfragt und die GPO dann ausführt oder eben nicht. Oder ein Login-Script welches +- das gleiche macht. Vielleicht würde es den User die sich daran stören auch an einem kleinen Script erfreuen mit welchem sie den Ist-Zustand speichern und wiederherstellen können. (ob man das will?) Imho alles etwas aufwendig :-P

Und wenn nun das Headset gar nicht das Standardgerät ist Du aber das Standardgerät in Jabber verwenden möchtest? Diese Krux gibts gerne bei BT oder sonstigen Funk oder USB-Geräten wenn das Notebook auch über entsprechende Klinken-Stecker verfügt. Eigentlich muss es fast etwas in dieser Art sein wenn es sonst funktioniert. ;) Gar nicht mitgeschnitten das Jabber nicht mehr eigentständig ist. War zu meiner Jungend-Zeit aktuell für Chats. =)

Eigentlich wie immer der gleiche Fehler in Kleinumgebungen. Zu wenig GHZ und vermutlich am Ende auch zu wenig Write-Iops und allgemein zu hohe Latenz aufm Storage. Wobei das meist noch so halb geht bei Local Storage bei RAID mit BBU wenn 10k oder 15k statt 7.2k Platten gewählt wurde mit wenigstens 4 oder 6 Platten im RAID 10. ;) Der Host auf welchem TS oder VDI läuft braucht viel GHZ und vorzugsweise auch IOPS mit möglichs tiefer Latenz und dann rennts. Alleine der VM-Overhead liegt vermutlich auch irgendwo bei 10-20%. Habe keine aktuelle Zahlen im Kopf, aber dann bist auf dem Niveau einer Uraltmühle. Auch typische KMU-Server-Anwendungen brauchen oft hohe GHZ, da nicht wirlich Multi-Core optimiert und allgemein nicht undbedingt ressourcenschonend. Also viel direkt ab Platte statt ausm Ram-Cache. Alles was mit Industrie zu tun hat sowieso. Auch die virtuelle Netzwerkkarte profitiert enorm von hoher GHZ auch wenn die ziemlich gut mit der Menge Cores skaliert. Keine Ahnung warum die typischen Dienstleister so oft das Gefühl haben, ein KMU bei dem alles auf einer Kiste rennt es mit 2.1GHZ getan ist. Das ist aus genannten Gründen ca. 10x wichtiger als bei grösseren Umgebungen. Aber dann müsste man halt Single-Sockets verkaufen, weil die Dual Sockets CPU's mit viel GHZ für KMU's oft schlicht zu teuer sind. Da wirds dann leider sehr schnell wieder eng mit der Auswahl bei den grossen drei Server-Herstellern für vernünfte Server Dabei wäre es eigentlich so einfach. 16 Cores, möglichst hohe GHZ und man ist lizenz- und Performancetechnisch und preislich relativ gut dabei. Dann noch eine Optan als Primärspeicher und das zeug fliegt wie die Hölle, egal wie grottig es progammiert wurde und ein paar Einstellungen nicht optimal sind. Dank dem High-Speed Host-Internen-LAN hat man je nach Anwendung nichtmal mehr Bock auf die Physische Mühle als Client. ;) Die bereits genannten Optimierungen sind natürlich trotzdem gut wenn man sie umsetzt. Auch Telemetrie und Aufzeichnung frisst jede Menge IOPS und teilweise auch CPU-Cycles die man noch abdrehen kann.

Windows ME. Da ringeln sich mir immer noch die Zehennägel auf. Hat mir jede Menge Ärger bereitet. Ganz grauselig war es, wenn man die Zusatz-CD's bei ME installiert hat *brrrrr* Unzählige Private Maschinen W98SE zurückgerüstet. =) Windows 98SE war dafür sehr stabil. Habe noch ein paar Spezialmaschinen im Einsatz, mit Office und 16bit Applikationen, HASP-Dongles. Alle virtuell. Laufen rasend schnell und super stabil. OS hat glaub mit Office und Installationsdateien keine 500MB. Ohne Hardlinks *g*. Keinen einzige Absturz in mehr als 10 Jahren seit ich auf Virtualisierung und "moderne" Pentium D gewechselt habe. W95 nur noch eine einzige Robotersteuerung. Läuft stabil mit glaub 128MB RAM verteilt auf zwei Riegel. Der Steuerung bzw. dem Motherboard habe ich dieses Jahr neue Kondis spendieren müssen, waren alle explodiert.

- Noch eine Idee, hast Du die W10 Maschine neu installiert oder eine andere kopiert? --> Kopiert = ID muss händisch gelöscht werden - Funktioniert eigentlich überhaupt DNS? Sprich die Namensauflösung des WSUS-Servers? - Wie viel mal hast Du versucht die Updates abzugleichnen? Bei neu installierten Clients mit eher älteren Builds kann das gerne mal einige Anläufe brauchen, weil im ersten und zweiten Durchlauf nicht der ganze Katalog abgeblichen wird bis er ins Timeout läuft. So aus den Logs ergeben sich die üblichen Fehler-Codes die immer kommen bei Verbindungsproblemen. Hatte ich sie von gestern her noch offen, jetzt ist sie weg, aber bei solchen Fehlern immer besser erst das log löschen, einen Versuch unternehmen, dann nur den aktuellen Teil des Logs kopieren (in Code Tags). Ich würde nochmals das Standardverfahren durchziehen wenn DNS funktioniert, die notwendigen Sicherheitsprotokolle allesamt aktiviert sind (wobei Dein Port 8530 eher auf unverschlüsselt deutet). Müsste aber eigentlich auch gehen. 1. Manuelles Update des Update-Clients (Internet oder selber einspielen), evtl. auch aktuellstes Update manuell einspielen 2. netstop Bits, wuauserv und cryptsvc 3. SoftwareDistribution löschen, catroot und catroot2 in system32 löschen 4. RegKeys löschen (sofern kopiert wurde) reg delete HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate /v AccountDomainSid /f reg delete HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate /v PingID /f reg delete HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate /v SusClientId /f reg delete HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate /v SusClientIDValidation /f 5. alle servcies wieder starten oder gleich ein reboot 6. wuauclt.exe /resetauthorization /detectnow Wenn das nicht geht, hast du mit sehr grosser Wahrscheinlichkeit schlicht und einfach ein Verbindungsproblem. Firewall die blockt, Namensauflösung, nicht die richtigen Protokolle

Finde ich jetzt durchaus komisch. Habe die 3. Adresse immer gesetzt, allen Umgebungen. Defender ist aber "speziell" oder? Der zieht doch seinen Kram gerne standardmässig aus dem Netz auch wenn es bei Updates anders defniert wurde. Dem muss man das Verhalten ebenfalls abklemmen, dann funktioniert soweit ich mich erinnere auch die 3. Adresse. Aber ist jetzt reine "Erinnerung" müsste ich erst nochmals Validieren. =) Hinweis: Ich setze auch nur die LTSC/LTSB Builds von W10 ein. Da MS ja immer wieder etwas an dem Update-Kram ändert ist es auch gut möglich, dass es nicht überall identisch funktioniert.

Sicher, dass dies nicht auf die Sicherheitsprotokolle oder einen alten Update-Client zurückzuführen war? Ich habe überall die 3. Adresse drinn, allerdings bei manchen Clients die sich länger nicht gemeldet hatten auch schon manuell den Update-Client nachspielen müssen. Via Internet zieht er diesen automatisch, ist Internet Kommunikation deaktiviert, eben nicht. Lokal in WSUS aber eben nicht zwingend wenn z.Bsp. in der Zwischenzeit die Umstellung auf SSL erfolgte oder der Client die entsprechenden Protokolle nicht aktiviert hat.

Der müsste natürlich gehen. Wird irgendwas banales sein, das nicht auf Anhieb ersichtlich ist. Weitere Möglichkeiten sind noch SSL/TSL Einstellungen. Die ganzen Protokolle müssen im System aktiviert sein. Wobei das - soweit ich mich erinnere - eher Probleme beim Download als beim anmelden macht. Neuere OS haben da evtl. nur noch SSL aktiviert, wenn der WSUS nicht umgestellt ist, kann das Ärger geben. (Gibts diverse Tuts im Netz) Aber eben, Ereignislog-Meldungen sowie das Update-Log wären mal noch gut. Sonst ist das alles Kaffeesatzleserei.

@NorbertFe: Verhindert aber lokalen Ärger. Ich musste sie schon eintragen damit alles zuverlässig funktioniert hat. Und ohne geht er manchmal über die Uso wo ihm egal ist welche Updates man will und welche nicht, trotz allen anderen Einstellungen. Wie das in aktuellen Builds ist, weiss ich aber nicht. Also alles aus meinem vorletzten und letzten Post? Dann tippe ich entweder auf ein nicht-WSUS-Kompatibles W10 (evtl. kann Home das nicht?) oder Schadstoffbefall. Insbesondere wenn alles grün angezeigt wird in der Systemsteuerung.

Ist das die, welche ich bevorzugt übergehe/ausbremse/mobbe solange es noch geht? Die UsoClient.exe mit ihrem Dienst macht normal aber eher in dem Sinne Ärger, dass evtl. unerwünschte Updates/Treiber etc. reinkommen. Da ich diese im Moment noch per GPO mobbe habe ich diese Art von Ärger allerdings nicht mehr. Evtl. wäre es möglich, dass er darüber etwas ziehen möchte, es nicht bekommt, aber als Alternative nicht WSUS nimmt... Müsstest mal schauen ob Du in der GPO tatsächlich "übergehen" drinn hast für die Übermittlungsoptimierung. Sowie den WSUS bei allen drei Adressen eingetragen. Stimmt, /Reportnow hatte glatt vergessen aufzuführen, führe eh immer beides aus. Wusste ich gar nicht, dass W10 detectnow ignoriert bzw. nur zusammen mit Resetauthorization funktioniert. Vorher wars eher so, dass ein Client erst dann in der WSUS-Konsole erschien, wenn das erste mal Reportnow durchlief. Naja eigentlich wars eh eher undurchsichtig, daher immer beides =)

Ja, weil der WSUS dumm wie Brot ist oder so ähnlich... - Firewallfreigabe könnte noch fehlen --> entweder testweise deaktivieren oder Audit-Logging aktivieren (bevorzugt) - Registrierung manuell anstossen (wuauclt /detectnow) - Authorisierung neu machen (wuauclt.exe /resetauthorization danach detectnow) - kontrollieren ob der Client evtl.noch Überrest von einer vorherigen Anmeldung hat, also die ID in der Registry löschen und anschliessend Neustart und dann detectnow

Hersteller sowie unsere Auto-Zeitschriften etc. haben das aber immer als Qualitätsmerkmal hervorgehoben und diemeisten sehen das wohl auch etwas so. Und ja es macht ja auch irrsinnig Spass, auch wenn man es mit der Zeit immer weniger auslebt. Man weiss ja, man könnte.