dartzen

Hallo zusammen, ich bin heute erstmals darüber gestolpert, dass in aktuellen Windows 11 Versionen der Credential Guard (der standardmäßig aktiv ist) anscheinend verhindert, dass man sich mit gespeicherten Anmeldedaten an einer RDS Remote-App anmeldet. Hintergrund: Unser ERP System kann von extern via VPN nicht vernünftig benutzt werden, daher ist die Lösung des Herstellers die Verwendung eines RDS-Servers. Wir haben daher den ERP-Client auf einem Server 2019 mit der RDS Rolle installiert und dann als Remote App freigegeben. Die Benutzer bekommen dann eine entsprechende RDP-Datei auf den Desktop, der Zugriff ist via Zugehörigkeit zu einer bestimmten Sicherheitsgruppe gesteuert. Beim ersten aufrufen der RDP-Datei muss der User zunächst sein Domainpasswort eingeben für die Anmeldung am RDS, danach startet der Client. Da der ERP-Client von sich aus immer eine Abfrage nach dem ERP internen Username/Passwort macht haben wir dann den Leuten gesagt, sie sollen bei dem Windowsanmeldefenster den Haken bei "Anmeldedaten speichern" setzen, damit man halt nicht mehrfach das Passwort eingeben muss. Das funktioniert soweit alles seit mehreren Jahren und hat bisher keine Probleme gemacht. Jetzt hat sich erstmalig ein Benutzer gemeldet und gemeldet, dass eine Windows Anmeldemaske kommt in der steht "Die Anmeldung war nicht erfolgreich". Weiter oben dann der Hinweis, dass Windows Defender Credential Guard es nicht erlauben würde, die gespeicherten Anmeldedaten zu verwenden. Wird dann das Passwort eingegeben funktioniert es, ist aber halt ein zusätzlicher Schritt, der vorher nicht notwendig war. Das Problem tritt auch nicht an allen Rechnern auf, an meinem eigenen kann ich das nicht nachvollziehen. Kann man diese Funktion irgendwie konfigurieren, am besten über eine GPO (damit ich nicht alle Rechner manuell anfassen muss)? Credential Guard ganz ausschalten ist problematisch, da das auf den verwendeten Notebooks per UEFI Lock aktiv ist. Das habe ich bei einem anderen Notebook des gleiche Modells schon mal versucht wg. VirtualBox, war aber nach einiger Zeit dann automatisch wieder an. Bin für alle Tipps dankbar.

Unseres funktionierte zu dem Zeitpunkt noch, daher habe ich es einfach per USB mit einer Linux-Distro gestartet und dann mittels den Kommandos der nvme-cli entsprechend "secure erased". Die SSD konnte leider kein "Crypto Erase" oder "Sanitize", aber "Secure Erase" sollte auch reichen. Habe ich nach der Anleitung hier gemacht: https://www.ssdblog.de/2024/02/18/nvme-ssd-sicher-loeschen-secure-erase-nvme-ssd/ Wenn du den nicht mehr einschalten kannst oder willst bliebe wohl nur auseinandernehmen und physisch zerstören.

Sowas ähnliches habe ich mal bei einem Surface Book gehabt (da kann man ja das Display als Tablet abnehmen), allerdings hinter dem Display. Da hatte sich der Akku derartig aufgebläht, dass sich der ganze Rahmen an der rechten Seite aufgedrückt hatte. Man konnte von der Seite in die Elektronik reingucken. War dem Nutzer erst spät aufgefallen, weil er es hauptsächlich am Dock betrieben hat. Das Ding haben wir dann schnellstmöglich ersetzt und entsorgt.

Als Abschluss, obwohl es keine wirkliche Erklärung gibt: Ich konnte mit keinem Tool irgendwelche Hardware Probleme feststellen. Solange das Gerät bei uns in der IT war trat das Problem auch nicht mehr auf. Ich bin absolut ratlos. Der Mitarbeiter hatte in der Zwischenzeit ein Ersatzgerät von uns bekommen und hat damit keinerlei Probleme, daher wird er das behalten. Das problematische Gerät habe ich jetzt noch mal komplett neu aufgesetzt. Ich hoffe echt, dass das nicht auch auf anderen Geräten auftritt. Lieben Dank an euch alle.

Ich habe letztens bei den Kollegen von administrator.de einen Screenshot von einem Beitrag auf X gesehen, der wie ich finde wunderbar die Hintergründe der aktuellen Speicherpreise beschreibt. Besser kann man es glaube ich nicht ausdrücken. Der Post ist übrigens dieser hier: https://administrator.de/info/speicherkrise-ram-ssd-preise-677014.html

Hi Damian, zuletzt trat das Problem wie gesagt auch auf, als der Nutzer am Rechner gearbeitet hat, daher war meine ursprüngliche Annahme, dass es am Modernen Standby liegt, anscheinend falsch. Und komplett ausschalten geht anscheinend nicht, zumindest wüsste ich nicht wie. Es war ja schon nur "Bildschirm aus" eingestellt. Ich habe mir das Gerät jetzt mal für Tests geholt und da mal auch das ausgeschaltet, sowie den automatischen Neustart nach Absturz, damit ich das auch mitbekomme. Kannst du ein Tool für Hardwarechecks empfehlen? Für RAM kenne ich Memtest, aber für CPU & Co ist mir da zumindest direkt nichts geläufig.

Leider hat das deaktivieren des Treibers im Geräte Manager nicht geholfen. Zudem scheint es auch nicht direkt mit dem Modernen Standby zusammen zuhängen, da es jetzt auch während der normalen Benutzung aufgetreten ist. War also anscheinend Zufall, dass das bisher immer bei Abwesenheit aufgetreten ist. Auch scheint das nach derzeitigem Wissen nur aufzutreten, wenn der Laptop am Dock hängt, das habe ich aber schon erfolglos getauscht. Hat jemand eine Idee, was der Fehlercode 0x133_OUT_OF_SYNC_PROCESSOR_nt!MiLockPageInline bedeuten könnte? Bei Google finde ich da faktisch nichts zu, zumindest nichts brauchbares.

Was meinst du mit auf Default setzen? Das UEFI? Du wirst lachen, aber dafür gibt es tatsächlich auch keine Option. Es gibt nicht mal ein "Speichern" Button, alle Einstellungen werden sofort übernommen. Das ist wirklich so rudimentär da drin, das kannst du dir nicht vorstellen, außer du hast selbst schon mal ein Surface (egal welches) gehabt.

Hallo Sunny, die Surface Geräte haben ein sehr übersichtliches UEFI, da gibt es dafür leider keine Einstellungen. Insgesamt kann man da im Vergleich mit anderen Herstellern wie z.Bsp. Lenovo extrem wenig konfigurieren. UEFI bzw. Firmware Updates verteilt MS komplett über Windows Updates und da sind alle installiert. Es ist halt sehr komisch, da zum einen nur dieses eine Gerät betroffen ist und dieses vorher ja bei einem anderen Benutzer einwandfrei funktioniert hat.

Hallo Nils, danke für deine Antwort. Ich habe in der Zwischenzeit die Eventlogs noch mal durchforstet, dort sehe ich noch einen Fehler mit einem Intel Treiber für "Precise Touch and Stylus". Da der aktuelle Benutzer keinen Stift verwendet, habe ich den im Geräte Manager jetzt einfach mal deaktiviert. Mal schauen, ob das hilft. Leider ist keine Garantie mehr auf dem Gerät, daher wird das mit dem Support leider nichts. Würde ja schon helfen, wenn man den Modernen Standby abschalten könnte, zumindest bei Netzbetrieb, aber was ich so gefunden habe ist das wohl nicht wirklich vorgesehen.

Hallo zusammen, ich habe hier ein sehr eigenartiges Problem mit einem Surface Laptop 4. Installiert ist Windows 11 25H2. Firmware ist laut Windows Update aktuell, es stehen keine weiteren Updates an. Anscheinend geht das Notebook, obwohl es an ein Surface Dock 2 angeschlossen ist (und somit auch Strom hat) nach einiger Zeit wenn er gesperrt ist (mit Windows+L) in den "Modernen Standby" und crasht dann nach kurzer Zeit mit Bluescreen weg. Laut Memory Dump crasht hier die ntkrnlmp.exe mit dem Fehlercode 0x133_OUT_OF_SYNC_PROCESSOR_nt!MiLockPageInline. Im Eventlog steht dann zuerst was von "System wechselt in den modernen Standbymodus. Grund: Idle Timeout" und dann kurz danach der Crash. Allerdings sollte das Notebook im Netzbetrieb nur nach 20 Minuten den Bildschirm abschalten, aber nie in Standby gehen. Auf Akkubetrieb ist 10 Minuten Bildschirmabschaltung und 20 Minuten Energiesparen eingestellt. Beim zuklappen ist "Nichts unternehmen" eingestellt. Das sind die gleichen Einstellungen wie an allen anderen Geräten auch, aber nur an diesem einen gibt es diese Schwierigkeiten. Mein eigentliches Problem ist auch eher der Absturz, da der aber immer nur kurz nach dem Eintrag für den Modernen Standbymodus kommt vermute ich da einen Zusammenhang. Das Notebook war bis vor kurzem noch bei einem anderen Mitarbeiter und hat dort nie Probleme gemacht, für den jetzigen Benutzer wurde das Gerät komplett mittels unserer Softwareverteilung mit unserem Standardtemplate neu installiert. Daher gehe ich eigentlich nicht von einen Hardware-Defekt an dem Gerät aus. Hat jemand eine schlaue Idee, was das sein könnte bzw. wie ich der Ursache weiter eingrenzen kann? Bin für alle Tipps dankbar.

Das ist eigentlich auch nicht der richtige Weg, um Shared Mailboxen anzubinden. Der korrekte Weg ohne Automapping wäre, die entsprechende Berechtigung per Shell zu setzen mittels Add-MailboxPermission -Identity "Postfach" -User "Benutzer der Zugriff haben soll" -AccessRights FullAccess -InheritanceType All -AutoMapping $false und dann am Client im Outlook als zusätzliches Konto hinzuzufügen. Also direkt über "Konto hinzufügen" und nicht über diesen Dialog in den erweiterten Einstellungen des Hauptkontos. Falls derjenige zusätzlich "Send as" oder "Send on behalf" haben soll kann man das entsprechend mit angeben oder nachträglich auch in der GUI machen, da dass keine Auswirkung auf das Automapping hat

Sieht für mich so aus, als wenn da noch irgendwo Lizenzkeys von den alten Versionen im System sind. Gib mal bitte unter einer Admin-CMD folgenden Befehl ein: cscript "C:\Program Files\Microsoft Office\Office16\OSPP.VBS" /dstatus Das sollte dir alle installierten Office Lizenzen mit den letzten fünf Zeichen des Keys anzeigen. Normalerweise sollte da nur deine aktuelle Office 2024 Lizenz auftauchen. Wenn da noch mehr sind, kannst du die alten mit dem Kommando löschen: cscript "C:\Program Files\Microsoft Office\Office16\OSPP.VBS" /unpkey: <Die fünf Zeichen des Produkt Keys>

Ja, kaum macht man es richtig klappts auch. Ich hatte beim ersten Versuch aus irgendeinem Grund gedacht es würde Calender heißen.

Genau das war es, mit Get-MailboxFolderStatistics werden mir die Ordner angezeigt und ja, es heißt tatsächlich Calendar. Dann kann ich auch die Berechtigungen abfragen. Lieben Dank euch.

Sollte ich haben, bzw. habe ich das Kommando auch mal direkt auf dem Server mit dem Domain-Administrator getestet. Über den wurden die Räume in der GUI auch angelegt. Wo müsste ich denn schauen, um das zu bestätigen und welche Rechte bräuchte ich?

Die Mailbox ist da, es werden mir, wenn ich das select weglasse, auch ein Itemcount angezeigt. Wie gesagt, funktionieren die Raumbuchungen auch und ich sehe auch die Termine im Kalender, wenn ich ihn anbinde. Daher verwirrt mich das ja so. Die Räume wurden damals über die GUI angelegt, die stehen dort im EAC unter "Ressourcen" mit dem Typ "Raumpostfach".

Hi Mirko, da kommt dann gar kein Ergebnis, bei keinem der Räume. Aber die müssen doch einen Kalenderordner haben, sonst würde es doch gar nicht funktionieren, oder?

Hallo zusammen, ich habe da ein kleines Problem mit unseren Raumpostfächern bzw. deren Kalendern im Exchange Server SE. Es kam der Wunsch auf, dass man im Kalender der Räume den Organisator eines Termins sehen kann. Ich hatte dann hier auch einen alten Thread gefunden: Die Befehle sind soweit ich gesehen habe auch im Exchange SE immer noch gültig. Allerdings habe ich bei uns das Problem, dass es angeblich in den Postfächern keinen Ordner "Kalender" bzw. "Calender" gibt, bzw. die Shell meldet mir bei einem Get-MailboxFolderPermission er könne nicht gefunden werden. Es gibt angeblich nur den Ordner "Top of Information Store", wenn ich die Abfrage direkt auf das Raumpostfach mache. Die Kalender an sich funktionieren aber, ich kann die Räume korrekt buchen und sie mir anbinden, sehe dann halt aktuell aber nur Frei/Gebucht. Hat einer von euch eine Idee, was ich hier falsch mache?

Nee, ich hab eher ne Mietzekatze gesehen.

Danke, hab's korrigiert. Ich hätte nicht so viel Looney Toons schauen sollen.

Ich hatte auch nicht grundsätzlich ein Problem damit, wenn die Leute es nicht mehr wussten. Aber dieses "Oh verdammt, da kommt ganz überraschend Weihnachten/Silvester, wie ging das nochmal" konnte man echt jedes Mal beobachten. Noch geiler waren dann die, die am Tag vor Silvester dann auf der Notfallhotline dafür angerufen haben, weil die Firma zwischen den Feiertagen zu hatte und halt nur einen Notfalldienst für Servicekunden hatte (weil u.a. Altenheime und KHs im Kundenstamm waren). Ne Ansage ist jetzt nicht so wirklich ein Notfall.

Ja, das kommt jedes Jahr so überraschend, genau wie Silvester. Furchtbar diese Feiertage, die immer am gleichen Datum sind, wie soll man sich das nur merken. Wobei ich das tatsächlich früher jedes Jahr erlebt habe, wo ich noch Telefonanlagen betreut habe, dass Kunden 1 bis 2 Tage vorher ganz aufgeregt angerufen haben und ganz dringend eine neue Mailboxansage gebraucht haben und nicht mehr wussten, wie es geht.

OK, wenn ich den Artikel richtig verstanden habe ist das Problem nicht ursächlich im Server 2025, sondern diese Extensible Storage Engine und diesen Bug gibt es quasi schon immer oder zumindest schon sehr lange. Ist nur bisher nicht aufgefallen, weil die erst ab Server 2025 automatisch mit der größeren 32K Tabelle arbeiten, wo es dann zu diesem Fehler kommt. Bzw. weil das Exchange Setup einfach gnadenlos Werte schreibt, ohne zu prüfen ob es sie schon gibt.

Super, danke für die schnelle Antwort. Da ja nach dem Update die alte Datenbank nicht mehr benötigt bzw. aktiv verwendet wird sollte das in dem Fall nicht so problematisch sein. Es wird, wie ich es verstanden habe, nur während der Migration zusätzliche DBs geben, danach sollte das wieder so laufen wie bisher.