Alle Aktivitäten

Die Daten und Rollen müssen erhalten bleiben. Der Hersteller der installierten Software muss ein Update machen und da sehr viele Kundendaten usw. in der / einer Datenbank sind, dürfen die auf keinen Fall verloren gehen. Eine Neuinstallation über den Support ist preislich gesehen unangemessen hoch und ich müsste dann auch alle anderen Rechner bearbeiten. So blöde wie Foundation damals eigerichtet wurde müssen wir trotzdem erst einmal auf 2019 Standart kommen. Es soll später auch von 2019 auf 2025 ein Upgrade gemacht werden. Im Augenblick kann ich aber nur ein MB nehmen, wo es Treiber für Win8 und Win10 gibt. Deswegen wird nach dem endgültigen EOL von Server 2019 das ganze Spiel noch einmal mit Server 2025 oder neuer gemacht.

Ok, danke euch. So hatte ich das jetzt gar nicht gesehen, macht aber Sinn. Anders wäre es auch irgendwie komisch gewesen, aber bei MS weiß man ja nie

Noch einer

Genau so interpretiere ich das auch. Was ja auch vollkommen logisch ist. Es bezeichnet eben den Fall, dass jemand meint er wäre jetzt nicht betroffen weil er keinen WSUS nutzt und 2 Wochen später kommt Kollege Schnürschuh auf die Idee jetzt den WSUS auf diesem "nicht gepatchten" Server in Betrieb zu nehmen und macht damit die RCE Lücke auf.

Ich lese das eher als Warnung für Admins: Wenn man einen Server hat und das Update nicht installiert hat, weil der bisher nicht die WSUS Rolle hatte, und jetzt die WSUS Rolle aktiviert ist der Server angreifbar. Ich lese da nicht raus, das zur Installation des Patches die Rolle deinstalliert werden müsste.

Hallo zusammen, es gibt eine schwerwiegende Sicherheitslücke im WSUS https://www.heise.de/news/Microsoft-WSUS-Notfallupdate-stopft-kritische-Codeschmuggel-Luecke-10845666.html https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-59287 Was mich wundert ist folgende Aussage von MS Heißt das jezt, dass ich die WSUS Rolle vorher deinstallieren muss, dann fix installieren und dann wieder die Rolle installieren? Oder verstehe ich das falsch?

Wenn es nur darum geht Daten zu kopieren hilft die robocopy weiter.

Hallo, ich bin Andreas und müsste bitte etwas wissen. Vorhanden ist ein sehr alter Server 2012 R2 Foundation, damals mit OEM Lizenz im Legacy-Modus und dynamischen Datenträgern installiert. Nicht von mir ! Darauf befindet sich nur eine Anwendung, welche über Netzwerkfreigaben und Verknüpfungen auf den 3 Client´s die Zugriff auf dieses Programm haben. Kalender / Rechnung usw. Vorhanden sind 3 Konten / Benutzer Administrator als Admin Administrator1 als Admin und Benutzer !? Paul als Benutzer Es befinden sich auf der 2" Festplatte die Ordner Hauptserver und Server Dementsprechend sind die Freigaben auch mal gesetzt worden, damit jeder Client nur Zugriff auf den jeweiligen Unterordner hat. Jetzt die Frage: Ein Upgrade von Foundation ist ja ohne Eingriff in die Registry auf Server 2019 Standart nicht möglich. Jetzt wollte ich einen Server 2019 Standart auf neuer Hardware und ohne dynamische Datenträger neu aufsetzen bzw. ist schon fertig. Wie bekomme ich jetzt die Daten / Programme auf den neuen Server 2019 ? Ich habe von Server 2012 eine Bare-Metal Sicherung erstellt aber die bring ja wohl nix, da altes System auf neuer Hardware ohne Treiber. Ich habe auch die 2 Festplatten 1 zu 1 geklont und versucht damit auf anderer Hardware zu starten, ging auch nicht. Wie bekomme ich jetzt die Daten auf den neuen Server ? UEFI und GPT ohne dynamische Datenträger eingerichtet. Danke für eine Unterstützung

Moin! Der Kaffee ist fertig, greift zu. Das Wetter hier ist besch...eiden, doch es ist Freitag, so langsam kann die Entspannungsphase eingeleitet werden. Heute in zwei Monaten ist Weihnachten, aber die Eierpreise sollen stabil bleiben. Oder... Moment mal... VG Damian

Was wir in solchen Szenarien meistens getan haben, war folgendes: Accounts im Ziel anlegen (wegen mir per PowerShell, insbesondere wenn auch OU-Strukturen stark unterschiedlich sind) Die Attribute, die im Ziel wichtig sind, so konfigurieren, wie im Ziel vorgesehen, und aus der Quest-Sync ausschließen Dann die Sync anschalten (irgendein Attribut muss ja zum Matching vorhanden sein, zu Not benutzerdefiniert) und Kennwort, sidHistory, Gruppenmitgliedschaften, managedBy und den ganzen Beziehungsrotz synchronisieren lassen Wenn euer DL nicht gerade "Facts & Figures" ist (aber die verstehen ihr Handwerk, das wäre euch da nicht passiert) können sie mich gern kontakiteren und die Ideen mal mit einem frischen Satz Augen von jemandem, der jahrelang auf der "PSO Waiver"-Liste für dieses Produkt gestanden hat, begutachten lassen

Es ist schwierig. Wir migrieren in ein neues AD (nicht meine Idee) und wechseln dabei den Anmeldnamen. Es gibt einen Trust mit SID-History via Quest-Software. Das Problem: Die Herrschaften auf der anderen Seite verwenden nicht "HomeShare" zum Mappen vom UserHome, sondern den Inhalt von SamAccoountName, CN, oder ähnlich. Das passt dann aber nicht zu den Namen der User-Ordner, die wir aber noch nicht ändern können. Verstanden? Ich auch nicht. Der DL raubt mir den letzten Nerv. Aktuelle Idee: Den alten Usernamen in ein Extensionattribut schreiben (durch Quest).

Moin, fragen wir mal anders: Was ist denn da die Anforderung? Gruß, Nils

Probier's doch einfach aus. Mach Dir einen Test-Account und ändere das Attribut "Name" oder "CN" und schau, was mit dem jeweils anderen Attribut passiert. 🤷🏼‍♂️ ... das dauert 3 Minuten ...

Ok, dass hatte ich so noch nicht betrachtet. Bringt mich aber erstmal weiter. Danke.

Das habe ich mich auch gefragt... :-D: "Name" und "CN" ist also immer identisch,

Hätten sie halt sa kaufen müssen. Ansonsten sind sie ja jetzt seit Jahren ohne weitere Investition funktional gewesen. Also… Beim distri und die Kunden dann von uns. Erstaunlich. ;) Nein für 30 User (Menschen). Wieviele Postfächer du denen gibst ist vollkommen egal.

Also brauche ich für 30 Postfächer 30 Exchange Online Plan 1 und die SA für den Exchange für 3 Jahre? Wo bezieht ihr eure Lizenzen denn? Direkt bei Microsoft? Ich habe einige Kunden, die ihre CALs und Exchange Lizenzen vor Jahren einmalig gekauft haben und müssen jetzt natürlich lizenzieren, um Updates zu erhalten

Du nutzt bei manage-bde den -SkipHardwareTest switch und bei Enable-Bitlocker nicht

Moin, der war gut. Gruß, Nils PS. AD-Attribute und "klar" ... wo kommen wir denn da hin?

Hi Leute, ich habe ein neues Thema, Aktivieren von Bit-Locker auf Win10 Geräten mit Powershell 7.5.2 64 Bit. Die Geräte, um die es geht, sind ebenfalls alle 64 Bit Geräte mit Windows 10. Der Code zur Aktivierung, erst TPM auf Vorhanden sein prüfen, wenn ok, dann Enable Bit-Locker: $CheckTPM=(Get-Tpm).TpmPresent Enable-BitLocker -MountPoint "C:" -EncryptionMethod XtsAes256 -UsedSpaceOnly -TpmProtector Danach erhalte ich "Bit-Locker enabled" - als return code. Später, nach einem Reboot lässt sich auch der TPM Schlüssel abfragen - auch ok. Das funktioniert an einer bestimmten Geräteserie mit Win10 PCs einwandfrei. Allerdings nicht an einigen anderen Geräten nicht, die haben alle Win10 und einen funktionierenden TPM-Chip. Wenn ich hier den Code wie oben beschrieben ausführe, erhalte ich auch "Bit-Locker enabled" - als return code. Frage ich später - auch nach einem Reboot - den Status nochmal ab - ist Bit-Locker nicht aktiv. Das Bios ist richtig eingestellt, Clear-TPM, Reboot hilft nicht. Initialize TPM ebenfalls nicht. Was dann ging, war folgender Aufruf (mit späterer Auswertung): $encryptionMethod = "xts_aes256" manage-bde -on C: -SkipHardwareTest -EncryptionMethod $encryptionMethod -RecoveryPassword Bei einer späteren Abfrage ist es dann auch aktiv: manage-bde -status C: Größe: 238,01 GB BitLocker-Version: 2.0 Konvertierungsstatus: Vollständig verschlüsselt Verschlüsselt (Prozent): 100,0 % Verschlüsselungsmethode: XTS-AES 256 Schutzstatus: Der Schutz ist aktiviert. Sperrungsstatus: Entsperrt ID-Feld: Unbekannt Schlüsselschutzvorrichtungen: Numerisches Kennwort TPM Jetzt die Frage der Fragen: Warum geht das nicht auf allen Geräten mit Enable Bit-Locker?

ADD: Im Quest Migration Manager kann man die Synchronisierung des "name" anfordern, was einer Umbenennung des Objektes gleichkommt, falls es bereits vorhanden war aber unter einem anderen CN...

https://www.rlmueller.net/Name_Attributes.htm Das sollte es klarer machen. Du kannst name nicht getrennt von CN verwenden.

Hi, da ich in den offiziellen Dokus von MS das irgendwie nicht finde: Kann mir jemand sagen, wozu das Attribut "name" beim Benutzer gut ist? Das ist offenbar vom Inhalt her identisch mit dem "cn" und wird in der GUI immer identisch mit geändert. Da wir gerade in einem Projekt sind, bei dem der Quest-AD-Migrator benutzt wird, bei dem der CN und der SamAccountName geändert werden soll, zeigt es sich aber, dass dieses Attribut scheinbar keine Funktion hat. Es muss also mit CN nicht identisch sein. Wir würden den Inhalt eventuell temporär für etwas Anderes nutzen. Kann man das Attribut überhaupt unabhängig vom CN ändern? In einem Attributeditor lassen sich CN und NAME jedenfalls nicht ändern. Per LDP kommt Error 0x20B1 Das Attribut konnte nicht geändert werden, da es dem System gehört.

Moin, naja, nicht ganz. Oder je nachdem habt ihr auch beide Recht. Eine VHDX-Datei wird normalerweise mit dynamischer Größe angelegt, sie ist dann nur so groß wie der tatsächlich belegte Platz. Die Größe der Partition ist dabei egal. Man kann so eine Datei aber auch mit fester Größe anlegen, dann ist sie so groß wie definiert. (Auch dies dann aber unabhängig von der Partitionsgröße, nur ist die ja meist so groß wie das Volume.) Das ging so auch schon mit VHD-Dateien, aber das nur am Rande. Gruß, Nils

Hier wird genau das gleiche erwähnt, habe aber selber kein WSUS im Einsatz https://www.computerbase.de/forum/threads/trotz-aktivierter-windows-10-esu-lizenz-wird-fehler-angezeigt.2254834/