teletubbieland

Hast Du keinen Händler zur Hand? Zum freien Download gibt es nur die Evals.

Einen anderen Weg, als eine Vollversion zu Kaufen sehe ich nicht. Auch lizenztechnisch ist das afaik der richtige Weg

Moin, https://learn.microsoft.com/de-de/windows-server/get-started/upgrade-conversion-options Da steht genau das drin.

Das Thema ist relativ einfach: Wenn Du SMB1 im Produktivnetzwerk betreibst, kannst Du die Daten auch gleich ans schwarze Brett heften. Daher ist afaik der beste Weg einen Samba Server dazwischen zu schalten der die SMB1 Freigaben via SMB3 an die Windows-Clients weitergibt. In der Industrie ist das immer wieder anzutreffen, dass man uralte Windowsinstallationen antrifft und die Maschinenhersteller sich weigern, diese zu aktualisieren. Wurde hier auch schon diskutiert und in der c't gab's auch nen Artikel: https://www.heise.de/ratgeber/Upcycling-Raspberry-Pi-als-Bruecke-zu-Altgeraeten-mit-SMBv1-Protokoll-nutzen-6148994.html

Moin, damit hast Du das Problem ja schon erfasst: SMB1 wird per default nicht mehr unterstützt und Benutzer ohne Passwort mag WIndows 10 auch nicht.

Moin, weiß nicht, ob es das exakt trifft. Ich hatte mal den Fall, dass ein Spaßvogel einen Router als Switch verwendet und den DHCP-Server nicht abgeschaltet hat. Bei einem Rundgang in alle Ecken, fand ich das 'böse' Gerät...

Dafür gibt es natürlich die 2te Backup-Destination, zyklisch getauscht wird (Ext. HDD oder Tape...)

Moin. Verschlüssetes Backup auf NAS mit eigenem Backup-User.

das wäre zu einfach gewesen...

Moin, nachdem die monatlichen Updates auf einen Server 2022 Standard installiert wurden, funktioniert die Druckerfreugabe nicht mehr. Auf dem Server ist der Drucker "ganz normal" freigegeben und funktionierte ohne Probleme. Seit den Updates Kann man lokal drucken, allerdings nicht über die Freigabe. Beim Versuch über die Freigabe zu drucken schmiert der Druckwarteschlangendienst ab. Im Ereignisprotokoll findet man leider auch keinen Hinweis. Auch eine Tausch der Druckertreiber blieb ergebnislos. Hat jemand die gleichen Erfahrungen gemacht und das in den Griff bekommen ?

Moin, hab's gelöst bekommen: Die Win7 VMs waren tatsächlich fehlerhaft. Zumindest 2 davon. Nachdem ich sfc /scannow und chkdsk angewandt habe, sind die Fehler weg. Allerdings verstehe ich nicht, warum in den VMs selbst nix im Eventlog stand, aber der RAID Controller eine Inkonsistenz festgestellt hat Auf jeden Fall Danke für Eure Unerstützung !

Das hatte ich gemacht. Der Erfolg war, dass die Fehler nur auf dem RAID-Verbund der Win7 VMs kam. Somit konnte ich das Problem ja eingrenzen.

Ja Bei Servern vermeide ich eine dynamische Zuweisung. Was spricht bei Workstation-VMs dagegen?

Nix, was auf HDD-Fehler zeigt. Allerdings gibt es wohl ein Problem mit der dynamischen Speicherzuweisung. Ich stelle das mal auf statisch um. Ja, vom Controller. Dateisystem steht auf NTFS.

Moin, ich habe auf einem Windows 2022'er Server verschiedene VMs laufen (Neues System Supermicro-Board + LSI-Controller). Nachdem die SSDs durchgetauscht wurden (inkl. Herstellerwechsel) gab es immer constistency check errors bei den SSDs auf denen die VMs laufen. Habe jetzt einen neuen RAID1-Verbund aufgesetzt und ein paar VMs umgezogen mit dem für mich überraschenden Ergebnis, dass die errors dort auftauchen wo die Win7-VMs laufen. Zur Erklärung: Der Kunde hat eine uralte Software (und nein - ich konnte ich in den letzten 20 Jahren nicht davon überzeugen, dass das Mist ist) für die diese VMs benötigt werden. Hat jemand eine ähnlich Erfahrung gemacht, bzw. eine Idee, was bei einer Win7 VM zu ändern ist, damit das nicht mehr auftaucht ?

Sehr schön

Es geht beide Male um die Auswertungen. Das Eine ist Automobilbranche mit SQL-Server (Kein MS) Das Andere eine Objektverwaltungs-SW mit MS SQL Ob das jetzt schlecht programmiert ist, was ich nur vermuten, aber man hält sich im Zweifel an die Vorgaben, damit man nicht ewige Diskussionen führt

Du wirst Dir da die Zähne ausbeissen. Klräre den Kunden darüber auf, dass er um ein Update nicht rum kommt.

Moin, das sollte vorher mit Inloox abgesprochen werden. Habe 2 Installationen verschiedener Hersteller, die den SQL auf dem TS haben wollen wg. performance.

Moin, ich schau vor Allem darauf, wie viele User auf die Systeme Zugriff haben. In kleineren Betrieben mit einer simplen Domänenarchitektur und nur Fileserver reichen tatsächlich noch HDDs. Allerdings verbaue ich allein wegen der Wartungsarbeiten mindestens S-ATA SSDs. Exchange läuft darauf auch performant (zumindest in KMU Bereich). Wenn komplexere Systeme zum Einsatz kommen orientiere ich mich gleich in Richtung NVMe. Hoffe, das hilft ein wenig.

Zum Austesten würde ich zuerst 4 vCPUs vergeben und wenn das nicht reicht, auf eine SSD verschieben. Wenn das immer noch nicht besser ist, eine neue VM aufsetzen.

Ketzerische Frage: Wie viele CPU-Kerne hast Du der VM gegeben ?

dann schalt doch einfach mal das LSO aus und guck was passiert

Bei der Pysikalischen und Virtuellen Maschine die ganzen offloads deaktivieren. Bevor Du die Clienst testest, teste doch mal wie die Geschwindigkeit zwischen VMs ist. Wenn die gut ist, dann hast Du ein 'externes' Problem.

Du kannst die disablen, solltest danach die VM aber neu starten. Kenne keine Komplikationen.