cj_berlin

Moin, ja, seit einiger Zeit schreiben sich gemappte Drucker auch in die Maschinen-Registry rein. Über die Sinnhaftigkeit müssen wir nicht diskutieren, aber vermutlich ist genau das, was Du gerade beobachtest, "gewünschtes Verhalten" für irgendjemanden gewesen.

Normalerweise wird Dir GPRESULT sogar anzeigen, aus welcher GPO die effektive Einstellung kommt, aber natürlich gibt es keine Garantie, dass es die *einzige* GPO ist, wo diese Einstellung gesetzt ist...

Moin, Du musst im selben Segment sein, dann funktioniert es genau so wie Du es beschrieben hast. Wenn Du in einem anderen Subnetz sitzt, hilft Dir ARP wenig. Auf dem Switch solltest Du die MAC-Adresse auch sehen, wenn er einigermaßen gemanagt ist.

Moin, grundsätzlich gilt: Backup ist egal, solange das Restore funktioniert. Und wenn das Restore nicht funktioniert, haben alle Best Practices versagt. Du musst also vom Restore ausgehen, und dafür musst Du die Bedrohungen formulieren, gegen die Du dich schützen willst: Eine Wiederherstellung nach Komplettverlust der gesamten Infrastruktur (auf eine Stunde mehr oder weniger kommt es nicht an) stellt andere Anforderungen an das Backup als ein Wiederherstellung versehentlich gelöschter Elemente (User ist am Telefon und trommelt mit den Fingern) Eine Überschwemmung (Backups müssen geographisch weg aus dem RZ, z.B. in einen Cloud-Storage) hat andere Hürden als ein Ransomware-Befall (Backups müssen auch logisch von der Infrastruktur getrennt werden, so dass kein Durchgriff möglich ist). Erst wenn Du definiert hast, welche "Restore Services" Dein Backup anbieten soll, kannst Du anfangen, das Backup zu konzipieren und zu bauen. Hier werden Dir Konzepte wie 3-2-1 genannt werden und einiges mehr, aber wichtig ist, den Restore gedanklich durchzuspielen. Veeam beispielsweise kann alle Plattformen, die Du genannt hast, abdecken (vSphere, Proxmox VE, Hyper-V). Das kann auch Restore von Einzelelementen. Es gibt aber auch andere Produkte, die das alles können. SEP sesam sei hier genannt. "ansehen" ist das richtige Stichwort. In dem Szenario "RZ ist abgebrannt" musst Du halt vergleichen, was machbarer ist: ein neues LTO-Laufwerk besorgen (oder man hat es im Bank-Safe mit den Tapes gelagert) und zur Recovery-Site schaffen --> das Recovery an sich geht dann sehr schnell den Internet-Downlink wiederherstellen (also evtl. neuer Router, Modem, was auch immer nötig ist) --> das Recovery ist durch die Bandbreite limitiert, die man "auf die Schnelle" umgesetzt bekommt. Je nach Standort und Datenmenge kann der Vergleich so oder so ausfallen...

OK, also die EXE, die Du geschrieben hast, ist powershell.exe? Respekt! Spaß beiseite: Wenn die eigene Exe sich genau so verhält, dann ist Dein Problem ja nicht, dass sie nicht startet, sondern, dass sie nicht endet, und Du sie abbrechen musst? Oder sieht der Log, wenn Du nicht angemeldet bist, signifikant anders aus? Womöglich ist der Fehlercode ja richtig, und die vorherige Instanz läuft tatsächlich noch? Um Deine ursprüngliche Frage zu beantworten: Ich habe Derartiges schon tausendmal gemacht, es gibt kein Prinzipielles Problem hier.

Moin,. was steht denn im Task Scheduler-Protokoll dazu? Bei angemeldetem Benutzer: Steht da wirklich, dass die Session für "ServiceDesk" initialisiert wurde? Und wenn der Benutzer nicht angemeldet ist, welche Events finden sich da?

Na wenn das sooo ist...

gMSA haben ein Benutzerprofil, wie ich bereits schrub, und Du kannst mit einem SchTask dort einen Key Pair erzeugen. Ob das für SSH reicht, muss man verifizieren.

Kannst Du mal das Szenario beschreiben? Ich kann mir so gar nicht vorstellen, wann das nötig wäre... Aber grundsätzlich, wenn Du es schaffst, dem gMSA den Private Key unterzujubeln (vermutlich am Einfachsten per Scheduled Task, der als gMSA läuft), sollte der Public Key davon für Authentifizierung verwendet werden können... Aber denke daran: SSH mit Keys ist Type 3, wird also nicht für Second Hop funktionieren.

Moin, ich bin bereit zu wetten, dass die DMZ nicht jeden einzelnen Host in Prod braucht, sondern nur eine kleine Auswahl. Die kannst Du manuell oder per Skript pflegen. Solange die Kommuinikation von Prod nach DMZ initiiert wird, ist es nicht problematisch. Wenn DMZ tatsächlich *jeden* Host in Prod auflösen muss, hast Du ein Architektur-Problem, und DNS ist vermutlich die kleinste Deiner Sorgen.

Moin, verwaiste Server kannst Du entfernen, und vielleicht repariert es auch die Replikation

Ja. Es ist "Client Access", nicht "Network Access".

Genau, Das müsstest Du evtl. von "Microsoft Windows" auf "Microsoft UEFI CA" umstellen.

Wenn es der erste Server 2025 ist, ja.

Was willst Du denn wissen? Funktionieren wird's, supported ist es nicht mehr, aber offenbar ist es noch nicht lange her, dass es supported wurde. Wobei ich mir ein paar Stände der Support-Matrix in der Wayback Machine angeschaut habe, und es scheint eher so zu sein, dass die Grenze von ursprünglich 2025 auf nun 2022 und 2025 angehoben wurde. Vielleicht haben Jan und ich uns beide in die gleiche Richtung geirrt. Aber Windows 11 ist auf 2019 supported, somit wird 2025 auch laufen. Wenn Du hochkritische Workloads in diesen 2025er Maschinen fahren möchtest, für die Du dir vorstellen kannst, auch mal ein Ticket bei MSFT aufmachen zu müssen, würde ich die Frage stellen, aus welcher Not heraus das ausgerechnet auf 2025 laufen muss.