Alle Aktivitäten

Moin, dann ist das Skript vom Prinzip her ziemlich einfach: BACKUP DATABASE MyDatabase TO DISK = 'D:\Pfad\Datei.mdf' DROP DATABASE TestDatabase RESTORE DATABASE TestDatabase FROM DISK = 'D:\Pfad\Datei.mdf' Der Code ist aus dem Gedächtnis und ungetestet, sollte aber im Wesentlichen so gehen. Gruß, Nils

selbes System, sogar selbe Instanz. Nur anderer Name der Datenbank.

Moin, Wiederherstellung auf demselben System? Oder auf einem anderen? Grundsätzlich lässt sich sowas per T-SQL-Skript und SQL Server Agent gut machen, alternativ auch per Windows-Taskplaner. Die wichtigen Kommandos dazu sind BACKUP DATABASE und RESTORE DATABASE, das ist im Prinzip nicht weiter schwer. Gruß, Nils

Guten Morgen, ich würde gerne in definierten Intervallen eine Datenbank sichern und unter anderem Namen wiederherstellen. Dies passiert heute schon manuell, der Vorgang soll allerdings automatisiert werden. Es geht dabei um die Bereitstellung von Produktivdaten in einem Testsystem. Gibt es dafür Boardmittel oder hat das schon jemand via Skript gebaut?

Da deine Server nicht Mitglied des AD sind kannst du vermutlich einfach die Option zur Registrierung im DNS auf der netzwerkverbindung deaktivieren. Ob das korrekt ist, kann ich dir nicht sagen, weil ich keinen wg Cluster nutze. Alternativ ignoriere den Eintrag doch einfach.

Hallo Leute, ich habe mit 2x Windows Server 2025 in einer Workgroup einen Failover-Cluster erstellt. Soweit läuft auch alles bisher. Die Hyper-V-Server hängen im gleichen Subnet wie die Domäne, habe beide Knoten per statischem Eintrag im DNS der Domäne registriert. Ansonsten habe ich die Einrichtung laut MSFT-Video durchgeführt, mit Einträgen der Hosts und des Clusters in der LMHosts. Nur wird mir für den zweiten Knoten alle 15 Minuten folgender Fehler geloggt: Protokollname: System Quelle: Microsoft-Windows-FailoverClustering Datum: 12.09.2025 08:23:08 Ereignis-ID: 1196 Aufgabenkategorie:Network Name Resource Ebene: Fehler Schlüsselwörter: Benutzer: SYSTEM Computer: Hyperv02.domain.local Beschreibung: Die Cluster-Netzwerknamensressource "Clustername" konnte mindestens einen dazugehörigen DNS-Namen nicht registrieren. Ursache: Im Sicherheitspaket sind keine Anmeldeinformationen verfügbar. . Stellen Sie sicher, dass die Netzwerkadapter, die mit den abhängigen IP-Adressressourcen verknüpft sind, für den Zugriff auf mindestens einen verfügbaren DNS-Server konfiguriert wurden. Ereignis-XML: <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"> <System> <Provider Name="Microsoft-Windows-FailoverClustering" Guid="{baf908ea-3421-4ca9-9b84-6689b8c6f85f}" /> <EventID>1196</EventID> <Version>0</Version> <Level>2</Level> <Task>19</Task> <Opcode>0</Opcode> <Keywords>0x8000000000000000</Keywords> <TimeCreated SystemTime="2025-09-12T06:23:08.1203823Z" /> <EventRecordID>10041</EventRecordID> <Correlation ActivityID="{ae6af8d4-d0db-4319-a11e-a88babc13e29}" /> <Execution ProcessID="12424" ThreadID="12056" /> <Channel>System</Channel> <Computer>Hyperv02.domain.local</Computer> <Security UserID="S-1-5-18" /> </System> <EventData> <Data Name="ResourceName">Clustername</Data> <Data Name="StatusString">Im Sicherheitspaket sind keine Anmeldeinformationen verfügbar. </Data> </EventData> </Event> Es soll also der Clustername im DNS zu registriert oder aktualisiert werden, was dann nicht funktioniert... Wenn ich im DNS einen statischen Eintrag für den Clusternamen eintrage löst es das Problem auch nicht. Jemand eine Idee wie ich dieses Problem lösen kann?

Falsch. Falls du auf den ffl anspielst, es gibt keinen ffl 2022 sondern entweder 2016 oder jetzt neu 2025. letzterer ist bisher nicht für exchange 2019 und Se freigegeben. man könnte sich natürlich auch einfach selbst die Systemanforderungen usw. Durchlesen.

Danke! Eine Frage hätte ich noch: Der DC kann ja Server 2025 sein, aber für Exchange 2019 darf der Mitgliedsserver nur 2022 sein - richtig? Oder darf die Domainstruktur nur Server 2022 sein? Bitte jetzt keine Diskussion bzgl. Exchange 2019, SE und Online!

Gute Entscheidung 👍 gutes gelingen… bei Fragen melden 🍀

Top 👍, danke für die Rückmeldung. Viel Spaß damit. VG, Jan

Na endlich, hat nur bis zur Seite 3 gebraucht Ne, spaß Solltest du auf Fehler stoßen, einfach nochmal mit einem Thread melden.

Egal. No Risk, No Fun... Also ALLE Server neu. Räumt ja auch mal auf...

nach der Installation ist die exe jetzt vorhanden, jedoch die Verknüpfung funktionierte so nicht: %ProgramFiles%\PowerShell\7\pwsh.exe -File "W:\Kunden\list_selected_files.ps1" Es kam die Meldung: "Die Datei %ProgramFiles%\PowerShell\7\pwsh.exe wurde nicht gefunden." Mit der Verknüpfung auf die konkrete Datei: "C:\Program Files\PowerShell\7\pwsh.exe" -File "W:\Kunden\list_selected_files.ps1" geht es. Viele Dank.

Dann geb ich auch noch meinen Senf dazu :) Bei der Sophos ist nur die NetworkProtection lizenziert.

Wenn die pwsh.exe nicht vorhanden ist, dann installiere die Powershell 7 nach, oder ändere den Pfad auf die vorhandene Powershell.exe ab. Hier gibt es die aktuelle Version der PS7: https://github.com/powershell/powershell/releases

Danke für den Hinweis. Ich hab das mal auf meine Testgruppe losgelassen. Ungünstig ist dabei natürlich, dass das quasi je nach System unterschiedliche Regeln gibt. Die "Klassiker" direkt aus dem Systemverzeichnis sind aber auf jeden Fall mal mit dabei. Das ist richtig. Ich war auch schon kurz davor ein paar Admin-IPs mehr Zugriff zu geben. Ist aber sowohl sicherheitstechnisch, als auch zwecks "Einsicht" nicht ideal.

Dann würde ich es woanders kaufen.

Hallo Jan, vielen Dank für die schnelle Antwort. Ich bin erst jetzt dazu gekommen, es auszuprobieren. Mit dem Zielpfad in der Verknüpfung habe ich jedoch das Problem, dass die Datei pwsh.exe nicht gefunden wird. Die gibt es auf dem Rechner nicht. Ich arbeite unter Win 11 Pro 22H2. Viele Grüße BoKat

Leider nicht, habe bei vielen meiner Kunden keinen Netzzugang und Mobilfunk ist auch nicht optimal (LTE, 1 Balken). Als mobiler Arbeitsmediziner kriegt man häufig irgendein Kabuff im Keller zugewiesen, um da die Untersuchungen durchzuführen.

"Downgrade Recht" wären die Zauberworte. Im Worst-Case brauchst du nur einen 2019er Key, den du aber auch als "Downgrade Kit" nachordern können solltest. Sofern die auf deine Anfragen nicht antworten, wende dich doch mal an den Vertrieb oder die GF dort. Notfalls musst du das bei euch halt an die GF "eskalieren", dass die dort mal nachhören. Wenn aber niemand will und alle nur den einfachen Weg gehen, dann kann man euch wohl nicht helfen.

Da hätte ich schon nachgefragt, leider weiß er es auch nicht, sprich er will sich damit nicht beschäftigen. Ich besorge mir trotzdem mal eine ESU und teste, ob es mit OEM klappen wird. Das gäbe es auch noch als Alternative, aber halt nicht konform: https://www.deskmodder.de/blog/2025/09/05/windows-10-consumer-esu-anmeldung-mit-oder-ohne-microsoft-konto-als-script/#comments

Ja, das InPlace-Upgrade eines Server 2016 auf Server 2019 habe ich im Produktivsystem (mit Backup und Snapshot vorher) schon problemlos durchgeführt. Da es aber mehrere Server gibt teste ich nun mit einem weiteren (Mitglieds-)Server 2016, den ich durch Ex- und Import auf einem anderen "Blech" ohne Netzwerk teste. Auch wenn ich den aus der Domain nehme bleibt dieser ominöse Fehler. 2019 wäre eine Alternative. Allerdings habe ich nur 2022 und 2025 er OEM-Serverlizenzen mit 2025er CALs. Mit solch einer Katastrophen habe ich nicht gerechnet! Fa. Frickel: frag lieber nicht. Ist aber z.Z. alternativlos, da nur die spezielle Anwendungen und Anbindungen ins Werk und haben.

Jetzt bist du bei "testweise" zuletzt war es dein produktives System. Ich würde - sofern die original Systeme noch laufen - einfach in einem Klon / Restore ohne Netzwerk direkt In-Place auf 2022 oder eben 2025 gehen bzw. testen, ob das klappt. Die andere Überlegung wäre, einfach auf 2019 zu bleiben. _Warum_ soll es denn unbedingt neuer werden? Jetzt von 2016 wegmigrieren, ja, macht Sinn. Da ist im Januar 2027 Support Ende*. Mit 2019 bist du schon im Januar 2029. Da ist so viel Zeit, dass alles sauber zu planen und nach und nach in geordneten Bahnen auf neue VMs zu migrieren. Da sollte sogar noch genug Zeit sein, zu hinterfragen, ob man weiterhin mit "Frickel Soft" arbeitet oder eben eine neue Software einführt. Wie stellt Ihr euch denn Support vor, wenn mit "Frickel Software" wirklich mal die Hütte brennt und Ihr wirklich Support braucht? *) Selbst bis Januar 2027 _sollte_ mehr als genug Zeit sein, die Software sauber auf neue Systeme zu migrieren.

Doch, das _sollte_ gehen. Aber es kann sicherlich nicht schaden, sich das _vor_ dem Kauf vom Distributor / CSP bestätigen zu lassen.

Die Übertragung der FSMO Rollen habe ich schon ein paar mal gemacht. Ist von der Sache her kein Problem, aber ein gewisses Zittern ist dabei den alten Server zu entsorgen... Das würde ich ZU GERN vermeiden. Problem (noch mal ganz deutlich): die beiden Frickel-Server da der Support bei denen eine Katastrophe ist - wenn sie mal erreichbar sind. Zusätzlich läuft dort lizenzierte Software wo es immer ein Problem ist die Passwörter dafür zu finden. Diese beiden Server 2016 Mitgliedsserver ohne MS-Rollen möchte ich InPlace upgraden. Auf Server 2019 ging es ja testweise auch Problemlos! Kann niemand sagen was die Ursache sein kann für die Meldung, dass das Setup nicht feststellen kann ob genug Speicher vorhanden ist? PS: bitte nicht wieder die Exchange Diskussion