Alle Aktivitäten

Habe gerade festgestellt, das überhaupt kein DC installiert war Füge ich jetzt einmal nachträglich hinzu, kann mich ja austoben weil ich mit dem geklonten System arbeite. Lernen ist immer gut. Der Hersteller und auch meine Meinung ist, das WIN11 Pro völlig ausreichend ist. Ich wollte eigentlich ein System mit 2x NVME Raid1 und eine zusätzlich WD RED oder Plus als Backuplösung zusätzlich zum Bandlaufwerk aufsetzen. Dafür möchte ich aber kein Gaming Board von ASUS benutzen. Also weiter umsehen, was es an bootfähigen Raid Controllern gibt. Das bedeutet aber eine Neuinstallation und die Pfade an den Clients anpassen. Kann ich aber nicht entscheiden und Chef liegt in der Sonne.

Moin, wenn es nur drei Clients sind, kann man sich den Zauber mit dem zusätzlichen DC vielleicht auch sparen. Einfach auf dem neuen Server ein neues AD installieren, die Daten kopieren, die Anwendung installieren. Die drei Clients dann eben neu aufnehmen. Falls dort Daten in den Profilen der früheren Anmeldekonten gespeichert sind, kommt man da mit Adminrechten lokal ran und kann die in die neuen Profile verschieben. Ob das grundsätzlich funktioniert, weiß man in ca. 2 Stunden. Die Chance ist groß. Falls doch nicht, dann gilt der Weg von Evgenij im Groben. Gruß, Nils

Moin, das ist alles irgendwie sehr konfus. Wenn nur Clients dieses Programm aus einer Freigabe starten, muss es doch nach dem Umzug lediglich diese Freigabe wieder geben, idealerweise unter demselben Namen. Nun habe ich Foundation nicht mehr so im Kopf, glaube aber mich zu erinnern, dass er zwingend Domain Controller sein muss. Somit hast Du ein Active Directory, in dem (wieder Annahme) die Clients Mitglied sind. Wenn das alles zutrifft, sähe die Migration wie folgt aus: BACKUP!!!!!! Server 2019 wird zur Domäne hinzugefügt und zum DC hochgestuft Datenordner werden per Robocopy kopiert und unter den gleichen Namen freigegeben FSMO-Rollen werden vom 2012R2 auf 2019 verschoben, der 2012R2 heruntergestuft und aus der Domäne entfernt, danach vom Netz getrennt oder zumindest umbenannt. Server 2019 wird gemäß Rename Domain Controller - Der Windows Papst - IT Blog Walter in den Namen des 2012R2 umbenannt Theoretisch müssten die Clients die Anwendung wieder finden und auch aufrufen können. Wenn jetzt auf dem 2012R2 ein Datenbankserver irgendeiner Art läuft (SQL, Firebird, MySQL, was weiß ich), dann lass lieber den Hersteller der Anwendung die Migration machen. Das werden wir hier im Forum nicht gelöst bekommen.

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.