Alle Aktivitäten

Soo ein paar Projekte später (und viel zu viel Zeit die schon wieder vorbei ist) konnte ich mich heute wieder dem Problem widmen. ich hab mal mit "get-content auf den pfad mit der GPO die fehlschlägt gemacht: PS C:\Users\mcflym> get-content "\\ad.XXXX.XX\SysVol\ad.XXXX.XX\Policies\{C8F39FFF-E6A3-4D86-A9EA-F5F804B8659E}\gpt.ini" [General] Version=4 displayName=Neues Gruppenrichtlinienobjekt Das gleiche Ergebnis habe ich wenn ich das ganze im Systemkontext ausführe. Ich habe aber dadurch noch etwas gefunden mit den gespeicherten Anmeldeinformationen mittels "rundll32 keymgr.dll,KRShowKeyMgr" und habe das auf dem Rechner ausgeführt. Ergebnis: nur ein Eintrag mit: "virtualapp/didlogical". Den zu löschen hilft leider nicht weiter Das was da drinnen steht wirkt irgendwie wie eine andere Ansicht zu den "Anmeldeinformationen" in der Systemsteuerung Auf anderen Hinweisen und weil mich das mit dem Computerobjekt nicht in ruhe gelassen hat, habe ich den Rechner aus der Domain genommen, Hostname gewechselt und nochmal gejoint damit der komplett neu ist (altes Objekt selbstverständlich gelöscht). Das Problem ist immer noch womit ich das Computerobjekt als Quelle rausfallen.

Ja, da steht als Kanal "Handelspartner" und dann entsprechend da dann ALSO. Unter "Abrechnungskonto" steht dann wiederum als Typ "Microsoft Kundenvereinbarung". Ich werde dann denke ich tatsächlich mal unserem Systemhaus eine Anfrage schicken um das klären. Als wir damals von Office 365 Business Premium nach Microsoft 365 E3 gewechselt sind war die Geschichte mit der "Extended Use Right" für uns nämlich auch schon relevant. Finde ich aber trotzdem sehr "unfein", dass die gleichen Lizenzen unterschiedlich bewertet werden, je nachdem über wen man die kauft.

Sowas ist in der Regel entweder wegen blöder Treiber (da hilft Isolation) oder wegen blöder Druckjobs (da *kann* das Verlegen auf den Client helfen)... Aber manchmal sind Treiber so schlecht, dass da gar nichts hilft als einen generischen zu nehmen und auf irgendwelche fortschrittlichen Features zu verzichten. Spooler Logging hochsetzen: Two Minute Drill: Enabling Print Queue Logging | Microsoft Community Hub

Lustig, dass MS an der Stelle wieder mal schaut, damit die Leute bloß nicht zuviel On-Prem Optionen erhalten. :/

Ich sag ja, genau krieg ich das nach x Jahren grad nicht mehr zusammen. Aber ich stand beim Kunden vor demselben Problem und hab definitiv kein Backup und keine Neuinstallation gebraucht.

Du solltest bei den Produkten "Kanal für Käufe" / "Purchase channel" sehen. Wenn dort "Handelspartner" / "Reseller" steht, dürfte das CSP über euer Systemhaus sein, dass wiederum mit ALSO zusammenarbeitet.

hi zusammen, am einfachsten wäre es, einfach Deinen Partner zu fragen, notfalls kann er ja beim Distri nachfragen, dann bis du sicher, welche Produktbestimmungen relevant sind. Sollte Dein Partner/Distri leifern (müssen) ansonsten lieber einen kompetenteren Partner/Distri suchen.... Viele Grüße, Franz

Haben wir noch nie gemacht, lese mich da gerade mal ein. Hast Du damit gute Erfahrungen?

Ich wüsste nicht wie! Ich habe den DC soeben erneut falsch umbenannt und anschließend im DSRM-Modus gestartet. Jetzt frag ich den neuen DC Namen ab: netdom computername NeuerDC /enumerate Ergebnis: NeuerDC.testlab.local (Der Befehl wurde ausgeführt) Frage ich den alten DC Namen ab erhalte ich: Der Netzwerkpfad wurde nicht gefunden! Versuche ich dann mit dem u.a. Befehl den alten DC Namen als Alternativen Namen zu setzen, erhalte ich folgenden Fehler: AlterDC.testlab.local konnte nicht als alternativer Name für den Computer hinzugefügt werden! Fehler: Eine vorhandene Verbindung wurde vom Remotehost geschlossen. netdom computername NeuerDC.testlab.local /add:AlterDC.testlab.local

Moin, habt ihr schon versucht, mit Treiberisolation herumzuspielen? Manchmal kann das helfen. Was auch helfen kann, ist das Rendering auf die Clients zu verschieben (da gibt es Gruppenrichtlinien für). Natürlich nur, wenn sie das können.

Hallo Freunde der Microsoft Welt, ich verzweifle gerade an unserem Management Server - er läuft im Schnitt etwa einmal die Woche auf 100% CPU Last, Auslöser Spooler.exe. Eckdaten: - Windows Server 2022 - kein DC - UniFi Manager, Axis Camera Station etc - Drucker von Develop, Epson, HP, und Lexmark werden über ihn gespoolt Wir können bislang nicht eingrenzen woher das kommt, es passiert sowohl innerhalb als auch außerhalb der Schulzeiten, sprich egal ob die Geräte an sein müssten oder nicht, ob gedruckt wird oder nicht - einfach null Ansatz. Durch die bunte Mischung an Aufgaben ist es leider leichter gesagt als getan die Maschine komplett neu aufzusetzen drum würden wir schon gerne versuchen der Ursache auf den Grund zu gehen - nur wie? Dank Monitoring mit Zabbix wissen wir, das die CPU Last gestern bis etwa 19:30 Uhr komplett friedlich war, dann aber sich stetig gesteigert hat und heute morgen war mit Dienstneustart der Spuck auch wieder vorbei, siehe Anlage. Die andere Spitze kommt durch die Datensicherung und erscheint damit in der Nacht jedes Werktags, somit ist das in Ordnung. Was ich schon gecheckt habe ist die Ereignisanzeige, unter den Drucker- und Dokumentdiensten ist die letzte Meldung vom 23. April 2025 und somit auch nicht zielführend Wenn euch nichts anderes einfällt würde ich alle Drucker Schritt für Schritt auf unseren zweiten Management Server auslagern und auf dem problematischen löschen, aber es wäre ja schon cool dem Problem auf den Grund gehen zu können.... Grüße aus BaWü Norbert

Doch aus der Nummer kommt man mit netdom wieder raus. Deswegen ja auch die Fragen oben. Ich kann mich dunkel erinnern, mal beim Kunden vor demselben Problem gestanden zu haben.

Hi, ich habe das Szenario gestern in einem Lab durchgespielt... also das umbenennen via GUI führte auch hier zu dem Anmeldefehler "Die Sicherheitsdatenbank auf diesem Server verfügt über kein Computerkonto"! Ich hatte zuvor via wbadmin ein systemstate backup ausgeführt. Dieses habe ich dann wiederhergestellt und konnte mich dann auch wieder anmelden! Wenn man das nicht hat, dann ist mir kein Weg bekannt aus der Nummer wieder rauszukommen! Anschließend habe ich dann das umbenennen via netdom (wie auch hier beschrieben https://www.der-windows-papst.de/2021/06/24/rename-domain-controller/) ausgeführt und es gab keine Probleme! Danke für Euren Input!

Erst mal danke für eure Antwort. Woran erkenne ich aber nun, ob meine Lizenz eine CSP ist oder nicht? Das ist für mich gerade immer noch nicht ganz ersichtlich.

Hallo zusammen, CSP gehört meines Wissens nach zu MCA /MOSA. Viele Grüße, Franz

Sehr spannendes Thema. Genau damit habe ich mich die letzten Tage auch befasst und bin auf das selbe Ergebnis wie testperson gekommen. 👍

Hi, vermutlich nur bedingt hilfreich, allerdings findet sich in den diversen Programmen bei folgenden ein Passus zu "Extended Use Rights for Microsoft 365 E3/E5": Passus enthalten: EA / EAS: https://www.microsoft.com/licensing/terms/productoffering/Microsoft365/EAEAS MPSA: https://www.microsoft.com/licensing/terms/productoffering/Microsoft365/MPSA OL: https://www.microsoft.com/licensing/terms/productoffering/Microsoft365/OL OV / OVS: https://www.microsoft.com/licensing/terms/productoffering/Microsoft365/OVOVS OVS-ES: https://www.microsoft.com/licensing/terms/productoffering/Microsoft365/OVSES (EES: https://www.microsoft.com/licensing/terms/productoffering/Microsoft365/EES) Passus nicht enthalten: MCA: https://www.microsoft.com/licensing/terms/productoffering/Microsoft365/MCA MOSA: https://www.microsoft.com/licensing/terms/productoffering/Microsoft365/MOSA In welches Lizenz Programm jetzt CSP gehört, kann ich dir nicht sagen. Evtl. kann - bzw. wird es so sein, dass - @lizenzdoc hier weiterhelfen kann. Gruß Jan

Moin an Board, so starten wir dann in den Tag - ich koche Kaffee Allen einen stressfreien Freitag, bleibt gesund! Derzeit leichte Bewölkung bei 17°C, es zieht sich später zu bis etwa 23°C

Hallo zusammen, ich stolpere gerade ein bisschen über die Lizenzbedingungen für den Exchange Server SE und erhoffe mir etwas Erleuchtung. Laut dem Microsoft Blog Post hier ist man ja mit M365 E3 Lizenzen berechtigt, den Exchange SE On-Prem zu betreiben (Extended Use Right). Das war ja mit dem Exchange 2019, den wir aktuell verwenden, auch so. Trotzdem sehe ich bisher den Exchange Server SE noch nicht im Admin-Center, was aktuell ja noch nicht schlimm ist, da man ja erst später einen neuen Key benötigt. Nun gibt es aber in den Kommentaren des Blogeintrags zum Release des Exchange SE diese Diskussion. Hier wird dann von Nutzern aufgeführt, dass das Extended Use Right nicht für E3/E5 Lizenzen gilt, die über einen CSP bezogen werden, für die gäbe es momentan keine Möglichkeit, den SE zu lizenzieren. Es hat sich aber noch kein MS Mitarbeiter dazu geäußert. Ich bin daher jetzt verunsichert, wir haben unsere Lizenzen von einem Systemhaus, die wiederum beziehen die über den Distributor ALSO. Die ALSO steht bei uns auch im Tenant als Partner für die Lizenz drin. Die Lizenz an sich heißt "(NCE) Microsoft 365 E3". Ist das jetzt eine CSP-Lizenz oder eine "normale"? Und woran erkenne ich das? Ich muss gestehen, dass ich bisher nicht mal wusste, dass es unterschiedliche Lizenzen mit dem gleichen Namen gibt. Wenn mir da jemand auf die Sprünge helfen könnte wäre ich dankbar. Danke schön.

Moin an Board, dann wollen wir mal - ich koche Kaffee Allen einen ruhigen Donnerstag, bleibt gesund! Hier derzeit leichte Bewölkung bei 17°C, es bleibt den ganzen Tag bedeckt bis etwa 23°C

Vielen Dank fürs Nachschauen! Dann wird das wohl so passen.

Moin, wie RemoteApp ohne Broker funktioniert, würde mich direkt mal interessieren, also zumindest wie man das so konfiguriert, dass es verwaltungstechnisch beherrschbar bleibt. Funktioniert das Starten von mstsc.exe ohne Verbindungsversuch auf den Clients zuverlässig?

Hallo zusammen, ich kämpfe seit einiger Zeit mit dem Problem, dass bei vereinzelten Anwendern die Remote Desktop Verbindung bzw. Anwendung mstsc nicht funktioniert. Der Anwender öffnet via RemoteApp verschiedene Anwendungen auf dem Serversystem. Die Umgebung ist wie folgt: Client: Windows 11 24H2 mit akt. Juni 2025 Updates Server: Windows Server 2016 DataCenter (kein Broker, direkt) Es kommt sporadisch dazu, dass bei Klick auf die rdp-Verbindung der Prozess im Hintergrund (Task-Manager, mstsc.exe) startet, aber die Anwendung sich nicht öffnet. Wenn man den Prozess killt, funktioniert es in 50% der Fälle, in den anderen 50% allerdings nicht. Häufig ist es auch so, dass dem Anwender die Sitzung getrennt wird und er will diese wieder mit aufnehmen und die Verbindung kann nicht hergestellt werden. Workaround ist das Abmelden des Benutzers auf dem Terminalserver. Habt Ihr eine Idee, wo ich ggf. tiefer forschen könnte um dem Problem her zu werden?

Moin, sehr schön. Danke dir für die Rückmeldung! Gruß, Nils

Hallo, vielen Dank an alle Helfer. Mein SQL-Server läuft wieder. Die Lösung war eigentlich ganz einfach: Ich habe die einfach die master Datenbank zurückgesichert. Nochmals Danke und Gruß Andreas