Admin666

@Cryer hast du mehr als einen DC im Einsatz?

Schöne neue Welt und alles Neuland

Hallo nein es handelt sich hier nur um eine .local domäne. Die Anmeldung erfolgt hier nicht klassisch sondern über Hardware token und PIV Zertifikaten (Nein daran liegt es nicht schon getestet). Und es ist nur mit Windows 11 bei windows 10 ist alles wie gehabt und normal. Ich vermute das es entweder eine Einstellung von m,einm Vorgänger ist die ich wieder suchen muss oder vl sogar die Firewall (ja hier ist nichts normal und alles nicht nach best praktice).

Uff ja es kam wieder ein Update und wieder ein Problem mit Windows 11 die vorigen clients funktionieren immernoch *auf holz klopf* aber ein neuer client macht wieder die selben Mucken. Diesmal hab ich nur das Gateway weggenommen und siehe da es funktioniert alles einbanfrei. Sobald der Client Internet hat, nichts mehr, in der Ereignissanzeige ist auch nichts zu sehen Winlogon und NETLOGON geben keine Fehler. Ich werd noch kirre hier. DNS Einträge sind sauber und IPv6 deaktiviert.

Oh vielen Dank das ist extrem hilfreich. Ich finde es gut das MS einem diese Möglichkeit gibt.

Ah vielen Dank da wäre ich im Leben nicht so schnell draufgekommen dort zu suchen.

Hallo liebe Community, Wiedermal habe ich ein recht komisches Problem aber vl bin ich da nicht alleine. Mir ist heute morgen aufgefallen das mein PC (wegen eines Updates) einen Neustart wollte, dass machte mich schon etwas stuzig weil ich noch keine genehmigt habe. Es handelt sich hier um das KB5023696 Update für Windows 10 22H2, daraufhin habe ich im WSUS nachgeschaut und habe gesehen, dass alle Updates weiterhin nicht genehmigt waren. Als ich die Liste durchgeschaut habe stellte ich allerdings fest das genau dieses Update nicht in der Liste war, alle anderen schon (für Versionen 21H2,1809, Win 11 22H2, Server 2019- 2016, etc). Jetzt zu meiner Frage wie kann sowas passieren? Ich wollte eigentlich noch bis nächste Woche warten bis ich die Updates zulasse.

Ja da musste ich auch höllisch aufpassen damals bei der Azure Associate nichts falsch zu verstehen. Aber gut to know werde ich im Hinterkopf haben wenn ich mich mal in Richtung 365 zertifizieren lasse.

Achso habe das so verstanden das du meintest die Mailbox selber brauchte eine Lizenz um zu senden.

Hallo, das was @NorbertFe dort zitiert hat ist richtig. Bei einer Group Mailbox (z.B. info@contoso) können User, denen die Berechtigung erteilt wurde und die eine gültige Lizenz haben, im Namen dieser senden. Das bedeutet nur die User brauchen diese Lizenz, nicht die Mailbox selber. Desweiteren kann eine Shared Mailbox für den reinen Empfang eingerichtet werden ohne weitere Lizenzen zu benötigen. Hier ein kleiner Auszug aus der Admin Oberfläche um es zu bildlicher darzustellen.

Nein überraschen tut mich das nicht hatte, aber gehofft es gibt einen Trick oder best Praktice der einem das Leben erleichtert. Oder zumindest einen Anhaltspunkt wo man suchen muss. Nunja dann muss ich wohl oder übel mal alles zerpflücken ohne Schaden anzurichten Trotzdem Danke für die Informationen muss noch viel lernen.

Die Frage die ich dann aber als nächstes habe, wo findet man eine solche Konfiguration die dann Fehlerhaft ist bzw wie findet man sowas ohne Wochen oder Monate mit der Suche zu verbringen?

Das Wort Fehlkonfiguration stört mich hier. Wenn es von Anfang an nicht funktioniert dann würde ich es ja verstehen, aber wie kann etwas eine Fehlkonfiguration sein wenn es erst durch ein Update kaputt gepatched wird? Zur Info nur wenn du einen Benutzer hinterlegst kommt das, wenn du eine RDP Sitzung ohne Benutzer machst kommt das normale Fenster und eine Kerberos Anmeldung funktioniert. Naja egal könnte hier auch wieder mal ein Fall von "Das war immer schon so und muss weiter funktionieren" sein. Das Netzwerk hier betreue ich seit fast 2 Jahren und es existiert seit Windows NT, gibt vieles was man hier erneuern muss. Allerdings ist das auch ein Produktionsbetrieb und hier darf nie was stillstehen, also Zeit für Wartung ist sehr begrenzt und Fehlersuche ist extrem schwierig. Man könnte ja in der Dokumentation schauen aber... es gibt keine.

Achso jetzt verstehe ich was du meinst. Nein soweit müssen wir gar nicht gehen das ist ein Bug der anscheinend durch ein Update hereingekommen ist. Außerdem sind in der AD immer beide Varianten eingetragen im Reiter Konto man kann nicht nur eine wählen. würde ich gerne glauben wenn das nicht vorher wieder einmal funktioniert hat und mit Updates dann nicht mehr.

Ich verstehe deine Frage gerade nicht @Nobbyaushb.

Hallo liebe Community, tritt bei euch auch ein Problem auf das beim Aufbau einer RDP Sitzung? Es dauert ewig lange und im Hintergrund öffnet ein Fenster das man nicht wirklich auswählen kann. Nach etwas Recherche im Internet habe ich noch andere gefunden die genau dieses Problem haben, leider ohne Lösung (auch seitens Microsoft nichts). Was genau dieses Problem verursacht ist wieder mal eine Frage die ich nicht ganz verstehe, allerdings kann ich einen Workaround anbieten der bei uns funktioniert. In der RDP-Verbindungs Einstellungen ist bestimmt ein Benutzer mit folgendem Format eingetragen "Benutzer@contoso.local" das "@" verursacht hier das Problem. Man kann entweder den Benutzer komplett rausnehmen (z.B. rechtsklick auf die RDP Verknüpfung und dann auf "Bearbeiten"). Oder wenn ein Benutzer eingetragen sein muss sollte man diesen in dem "alten Format" eintragen z.B. "CONTOSO\Benutzer" Ich hoffe das kann Leuten weiterhelfen die diese Art von Problematik haben. Mfg Jan

@deipua Sind das Azure AD Member (365) oder Onpremise AD Member über die wir reden? Wenn das Onpremise Ad Member sind, also Domänen User auf einem DC (virtuell, in der Cloud oder physisch vor Ort) dann ist die Lösung von @testperson die richtige. Sollten es allerdings Benutzer sein die rein in der Azure AD sind z.B. 365 Konten im Admin Center, dann sollte die Regel "Self-Service-Kennwortzurücksetzung" eigentlich greifen. Die Frage von WSUSPraxis ist allerdings berechtigt, meiner Meinung nach. Statische Passwörter die der User nicht ändern kann sind: -unsicher -viel administrativer Aufwand -und soweit ich es weiss schwierig dem Datenschutzbeauftragten zu erklären Besser wäre es wenn die Admins die Passwörter nicht wissen (als Admin kannst du die eh zurücksetzten nach belieben). Der User soll seine Passwörter verwalten und nach belieben ändern können. Noch besser wäre es allerdings gar keine Passwörter mehr zu haben und andere Login Methoden zu benutzen.

Genaues kann ich dazu leider nicht sagen, ich kam nur auf die Idee weil erwähnt wurde es könnte ein Kerberos Problem sein. Mir viel ein das MS in den letzten Updates (seit Okotber oder November glaub ich) viel daran ändert. Ich hatte ehrlich gesagt nicht damit gerechnet, dass es funktioniert und es war auch nur ein Versuch. Um den Fehler genau zu untersuchen und zu analysieren fehlt mir leider die Zeit und die Kenntnis. (Weiterbildungen sind aber schon geplant )

Um es genauer zu sagen der Win 11 Client wurde nicht in unserem Netzwerk eingerichtet. Der Arbeitsplatz an dem dieser Client eingerichtet wurde verfügt über einen seperaten von unserem Netz losgelösten Internetzugang (für Testzwecke). Dieser wurde unabsichtlich benutzt um den Client upzudaten (KB5022845). Somit war der Client auf einem neueren Stand als unsere DCs. Der Systemintgrator, der zur Zeit diese Arbeiten macht hat die Anschlüsse verwechselt (deswegen sind es mehrere Clients). Ich habe heute unsere DCs mit den kumulativen Update vom Februar versorgt, (KB5022840) danach waren die Versionsstände wieder gleich und der Client konnte sich wieder an-und abmelden.

So (Admin zusammegefaltet) Lösung gefunden, Es lag daran das der Win 11 auf einer anderen Version war als unsere Domän Controller. Da ja gerade viele kumulative Updates kommen die, die Systeme härten ist es natürlich wichtig Clients und Server gleichzuhalten. Ich hatte heute eh vor das Februar Update zu installieren (andere Projekte hielten mich davon ab). Der Client funktioniert wieder wie gewohnt mit und ohne Internet.

Guten Morgen, Die Benutzer haben wir bereits überprüft und diese scheinen in Ordnung zu sein. Aber @daabm hat mich auf eine Idee gebracht ich werde mal etwas ausprobieren. (Zur Info ich habe den Win 11 nicht eingerichtet und denke der wurde ausserhalb unseres WSUS geupdatet).

Hallo, wie bereits erwähnt habe ich beides schon gemacht und es hat reibungslos funktioniert. Der DC lässt sich mit und ohne Internet pingen die Namensauflösung der IPs klappt wunderbar. @winmadness danke für den Tipp ich werde mir das auf jedenfall mal anschauen.

@Sunny61 Ich hab das immer nur über Netzwerkadapter Eigenschaften gemacht allerdings sagt @winmadness über die Registry wäre die bessere Lösung.

Leider kann ich nicht auf das Gerät zugreifen im Moment. Ja die beiden Adressen sind DCs sobald ich das Gerät wieder in die Finger bekomme kann ich was zum Eventlog sagen

Das ist eine gute Idee und die Eklärung macht da auch Sinn wir schiessen hier auch mit Kanonen auf Spatzen. (kleines Netz aber extrem gut ausgebaut und redudant ausgelegt Netzwerklast kleiner 20%) Die IP Config von den Clients kann ich euch gerne geben: IP: 192.168.1.91 /24 (WIN 10 funktioniert) Gateway 192.168.1.1 DNS1 192.168.1.15 DNS2 192.168.1.9 IP: 192.168.1.92 /24 (WIN11 funktioniert nicht) Gateway 192.168.1.1 DNS1 192.168.1.15 DNS2 192.168.1.9 Ich hoffe das hilft dir weiter.