phatair

Hi Martin, danke dIr! Dann nutzen wir ab sofort auch nur noch SetSPN. Soweit ich das verstanden haben, nutzt man die SPNs ja auch nur wegen der Kerberos Authentifizierung und da reicht es ja, wenn in der AD die Einträge gesetzt werden. Gruß, Steffen

Vielen Dank Martin. Ich habe jetzt auch rausgefunden woran es liegt, dass ich mit dem Domänen Admin "Zugriff verweigert" beim abrufen der SPNs mit dem NetDom Befehl erhalte. Bei uns sind die Domänen Admin Accounts auf den Servern und Clients aus der "Administratoren Gruppe" entfernt. Der NetDom Befel benötigt aber wohl die administrativen Rechte um den SPN auszulesen, da ich ja remote auf den Server zugreifen würde (meine Vermutung). Wenn ich den Domänen Admin in die "Administratoren Gruppe" aufnehme, funktioniert auch der NetDom Befehl. Wenn ich es also richtig sehe, dann fragt der setspn Befehl die Infos direkt aus dem AD Objekt ab, der netdom Befehl fragt diese dann wohl vom Server direkt ab. Das ist wahrscheinlich die Info vom Martin, dass Netdom WinNET-Provider nutzt und SetSPN ADSI nutzt. Ich dachte auch immer, dass beim SPN setzen auch lokal auf der Maschine was verändert werden muss und das mit dem netdom Befehl automatisch durchgeführt wird. Die Info hatte ich hier gefunden: https://woshub.com/add-alternate-computer-name-windows/ Macht das der setspn auch oder setzt der nur den Wert im AD Objekt und ich müsste den registry parameter dann manuell auf dem entsprechenden Server setzen? Grüße

Top, danke dir. Dann werden wir in Zukunft SetSPN verwenden und nicht mehr netdom. Mich wundert es zwar immer noch, warum es bei netdom den "Zugriff verweigert" Fehler gibt, aber mir fehlt die Zeit das jetzt zu klären :) Das die Berechtigungen passen, sieht man ja eigentlich am funktionierenden SetSPN Befehl. Schönen Abend Dir.

Hi Jan, ha...das ist ja faszinierend. Damit funktioniert es. Das heißt dann wohl auch, dass wir setspn auch zum setzen der SPNs nehmen sollten und nicht mehr netdom, oder? Wenn ich es richtig sehe, ist netdom dann die "alte" Variante? Ich war einfach nur verwundert, da das setzen der SPN bisher damit immer gut funktioniert hat. Nur beim auslesen ist nun aufgefallen, dass es bei unterschiedlichen Usern plötzlich Probleme gab (obwohl deren Berechtigung auf die AD Objekte identisch waren). Gruß, Steffen

Hallo zusammen, ich habe folgends Problem bzw. verstehe das Verhalten nicht so ganz. Wir haben bei einigen Windows Server 2019 Servern den SPN über den Netdom Befehl eingetragen. Das Auslesen des SPN über "netdom computername <server name> /enum" funktioniert dann manchmal mit dem Domänen Administrator und manchmal mit unseren "Server Admins". Die Fehlermeldung lautet dann einfach nur "Zugriff verweigert". Ein wirkliches Muster habe ich noch nicht rausgefunden. Beide User haben auf das Attribut "msDS-AdditionalDnsHostName" Leserechte. Soweit ich das verstehe, sollte das doch ausreichen um mit dem oben genannten Befehl den SPN auszulesen. Schreibrechte auf das Attribut brauche ich ja nur, wenn ich den SPN mit dem User setzen will. Aber auch das Rechte hätte der User. Oder was für Voraussetzungen müssen noch gegeben sein, damit man den SPN auslesen kann? Vielen Dank Grüße

Haben jetzt den download mode auf 99 gestellt. Updates vom Teams Client funktionieren nun und auch die WSUS Anbindung scheint weiterhin wie gewohnt zu gehen. Danke Dir!

Hallo zusammen, ich habe mal eine kurze Frage zum Download Mode der Delivery Optimization Einstellung Aktuell nutzen wir den download mode 100 (Bypass) da wir keine Delivery Optimization benötigen und die Downloads über WSUS bereitgestellt werden. Dual Scan ist deaktiviert. Nun ist es so, dass der neue MS Teams Client über DO 100 keine Updates laden kann. Dqs wird auch bei MS so kommuniziert. https://learn.microsoft.com/en-us/microsoftteams/new-teams-bulk-install-client#prerequisites-for-target-computers Wir überlegen nun den MS Teams Client manuell über unser Client Management zu aktualisieren oder den DO Mode umzustellen. Bei MS habe ich dazu folgende Tabelle gefunden https://learn.microsoft.com/en-us/windows/deployment/do/waas-delivery-optimization-reference#download-mode So ganz schlau werde ich daraus aber noch nicht. Mode 100 verstehe ich ,hier wird BITS verwendet und keine Delivery Optimization. Mode 0 würde zwar peer-to-peer deaktiveren, aber trotzdem HTTP Anfragen zu MS durchführen Mode 99 deaktivert Delivery Optimization - also keine Kommunikation zu MS (so würde ich es verstehen), aber trotzdem wird gesagt ->In this mode, Delivery Optimization provides a reliable download experience over HTTP from the download's original source or a Microsoft Connected Cache server, with no peer-to-peer caching Ist das nicht ein Widerspruch? Einmal wird gesagt DO ist deaktiviert und dann wird erwähnt das DO wird in diesem Mode verwendet um aus der original Quelle Daten nachzuladen (das wäre dann ja MS oder wäre da mit der WSUS gemeint?) Was wir wolle ist einfach ein download der Updates über den WSUS ohne jegliche MS Konnektivität (so wie es jetzt mit Mode 100 funktioniert). Oder ist das mit den anderne Modi gar nicht möglich? Was hätte Mode 99 für einen weiteren Nachteil? Danke schon mal im Voraus. Grüße

Danke für den kurzen Erfahrungsbericht. Dann ist für uns LTSC auch erstmal raus. Wir setzen auch DELL Geräte ein und haben einige Schnittstellen die Treiber benötigen und einiges an Third-Party Software. Dazu kommt, dass wir nicht bei jedem Update von einer LTSC zur nächsten eine komplette Neuinstallation durchführen wollen. Da der LTSC Support ja auch von 10 auf 5 Jahre reduziert wurde, ist das auch kein großes Argument mehr. Mal abgesehen davon, dass es ja aktuell noch gar keine Win 11 LTSC gibt. Dann prüfen wir noch mal den genauen Unterschied zwischen Pro und Enterprise und werden dann wohl hier eine Entscheidung treffen. Danke für die Rückmeldung. Wir haben das schon mal durchgerechnet und uns die MS Pakete angeschaut. Natürlich können wir damit viel bisherige Services ablösen, die Frage ist nur - wollen wir wirklich alles über MS Produkte lösen (meine Meinung ist dazu - nein) - wer soll diese Migrationen durchführen (da bräuchte ich 1-2 zusätzliche Mitarbeiter die nur mit der Migration der Systeme beschäftigt sind - Mail Gateway, Patch Management, EMM/MDM, Endpoint, Project Management, usw). Das können wir aktuell nicht stemmen und zum anderen sind wir mit den Produkten auch nicht unzufrieden. Aber das ist ein anderes Thema :)

Hallo zusammen, wir planen aktuell die Migration zu Windows 11. Aktuell laufen bei uns alle Clients mit Windows 10 Pro 22H2. Die Frage die wir uns aktuell stellen ist, werden wir auch bei Windows 11 auf Pro gehen oder vielleicht doch auf Enterprise bzw. LTSC. Ich habe bei MS jetzt keinen direkten Vergleich von Pro und Enterprise gefunden. Ich habe mit jetzt mal an diesem Vergleich orientiert und da wäre jetzt der Aufpreis für Enterprise für uns nicht wirklich lohnenswert. https://www.xda-developers.com/windows-11-pro-vs-enterprise/ Es war zwar auch schon bei Win 10 so, dass einige GPOs nur mit Enterprise funktioniert haben, aber auch das konnten wir ganz gut abfedern. So wie ich es sehe, ist für uns einer der Hauptgründe die etwas längere Supportzeit. Enterprise 36 Monate Pro 24 Monate Die LTSC wäre dann ja noch mal länger im Support, richtig? Hier wären es dann 5 Jahre und die Windows Funktionen bleiben auf dem Stand des Releases und werden nicht wie bei Pro und Enterprise immer weiter aufgebläht. So wie ich das aber aktuell sehe, gibt es noch gar kein Windows 11 LTSC, dass soll wohl erst noch kommen. Was wir hier brauchen ist ein stabiles OS, ohne großen Schnickschnack wie Copilot, Windows Store, Wetter Apps usw. Kann man die Unterschiede grob so zusammenfassen? LTSC -> OS auf die wichtigsten Funktionen reduziert, langer support Enterprise -> OS kann etwas feiner per GPOs administriert werden als die Pro, größerer Funktionsumfang für Unternehmen, etwas längerer Support Pro -> OS mehr oder weniger wie in Consumer OS mit dem kürzesten Support Eine Frage hätte ich noch zur LTSC Version. Wie war das bei der Win 10 Version. Wenn ich einen Client auf Win 10 1809 LTSC hatte und wollte den dann auf Win 10 21H2 bringen. Konnte ich das einfach per InPlace Upgrade machen? Brauchte ich für das Update dann wieder eine neue Lizenz? Danke euch. Grüße, Steffen P.s. Abo Lizenen wie M365 E3 / E5 usw stehen bei uns aktuell nicht zur Debatte.

Interessant - das gleiche Problem haben wir immer mal wieder auch. Den RegKey werde ich mal ausprobieren. Danke Dir. Das Thema werde ich mal unseren Fortigate Kollegen geben. Danke!

Die "Wait for network" GPO haben wir eigentlich auf allen Clients aktiviert und diese greift auch für VPN Clients https://admx.help/?Category=Windows_10_2016&Policy=Microsoft.Policies.WindowsLogon::SyncForegroundPolicy Wir sprechen ja von dieser GPO, richtig? Cloud joined ist bei uns nicht möglich, wir sind nicht in der Azure/EntraID Welt und werden das auch zeitnah nicht sein. Ob das jetzt gut oder schlecht ist würde ich hier gerne nicht diskutieren

Alles klar. Das heißt ein Großteil der VPN Lösungen ist davon betroffen, wenn die nicht bei der Anmeldung warten bis wirklich die VPN Verbindung steht und die DCs befragt werden können. Gut zu wissen. Ich werde beim Support mal nachfragen ob man hier irgendwie eine Verzögerung definieren kann. Danke für die Hilfe.

Uff...jetzt stehe ich irgendwie auf dem Schlauch. Aber MS sagt ja extra, wenn Gruppenmitgliedschaften bei einer VPN Verbindung nicht aktualisiert werden, soll man die VPN Verbindung vor dem Login aufbauen. Das wäre, nach meinen Verständnis, ja bei uns gegeben, da der FortiClient erst die VPN Verbindung aufbaut und dann die Windows Anmeldung durchführt. Wenn ich dich jetzt aber richtig verstehe, ist aber auch in dieser Konstellation (da die Anmeldung zu schnell nach der VPN Verbindung hergestellt wird) der Fehler nicht wirklich gelöst. Man müsste somit erst eine VPN Verbindung aufbauen, kurz warten und dann die Windows Anmeldung durchführen, richtig? Wenn ich dich also richtig verstehe, gibt es keine wirklich Lösung für das Problem? Außer man sperrt den Bildschirm nach der Anmeldung, entsperrt den Bildschirm und meldet sich ab und wieder an. Das hatte bei uns zumindest geholfen.

Danke für den Tipps und Hilfestellungen. Wir beobachten das Verhalten jetzt erstmal weiter. Möglicherweise ist es wirklich nur das Verhalten bzw. die Trägheit von whoami /groups.

Hi Nils das ist bzw. war auch meine Vermutung und das versuche ich gerade mit dem Support rauszufinden. Allerdings bin ich jetzt doch noch mehr verwirrt. Bei den letzten 2 Tests hat es jetzt plötzlich funktioniert. Neue AD Gruppe erstellt. Meinen User hinzugefügt Von Windows abgemeldet und Anmeldung inkl SSL VPN whoami /groups hat jetzt dann die neue Gruppe angezeigt puh....gibt es irgendeine Einstellung mit der definiert wird, wie lange die Verbindung zum DC dauern darf bis eine zwischengespeicherte Anmeldung verwendet wird? Meine Vermutung ist, dass vielleicht manchmal die Connection einfach etwas zu langsam ist und der Client (trotz bestehender DC Verbindung) meint er ist offline. Gruß, Steffen Edit: Ein kurzer Nachtrag. bei dem command whoami /groups werden Gruppen unterschiedlich dargestellt einige Gruppen sind als "Typ" Gruppe angegeben und einige als "Alias" und werden bei den Gruppen als "Lokale Gruppe" angezeigt. So z.B. auch meine Test Gruppe die dem User schon längst entzogen wurde. Aber auch andere Domänen Gruppen werden als "Alias" und "Lokale Gruppe" angezeigt. Andere Domain Gruppen werden eben als "Gruppe" und ohne "Lokale Gruppe" angezeigt. Ist das normal bzw. was ist hier der Unterschied? Heißt das Attribut "Lokale Gruppe" wirklich, dass der Client diese Gruppen als lokale Gruppe ansieht und nicht als AD Gruppe?