Die virtuelle Maschine VM2 steht endlich und es geht weiter:
Der MS-SQL-Express Server soll unter Win-10 als Dienst installiert werden.
Bereits hier muß man tüchtig aufpassen, denn es gibt zwei Betriebsarten dieser Engine, einmal als sogenannter "Dienst" - immerwährend im Hintergrund laufend und dann aber auch als Anwendungsprogram im Vordergrund. Das wollen wir aber nicht, wir wollen den automatisch startenden Dienst und nichts weiter.
.
Welche Software installieren wir da ?
Microsoft stellt ein fertiges Installations-Archiv für Windows zur Verfügung. das haben wir runter geladen.
"Sie" haben sich wirklich viel Mühe gemacht .....
Die Überraschung ist komplett, die Installation ist sehr sauber strukturiert und erklärt - auf Deutsch !!! von Microsoft !!!
Es sind doch große Datenmengen - aber Dank unserer SSDs geht das alles noch zügig
Die Lizenzbedngungen
Am Anfang verzichten wir auf irgendwelche Updates
Hier in dem Anzeige-Menü auf der linken Seite
sehen Sie den Fortgang der Installation, sehr ähnlich den Windows Installationen
.
Der erste Teil ist zwar fertig, aber nicht abgeschlossen.
In unserer alten "Fujitsu Rescue ISO" Installation waren seit dem Anbeginn von WIN 10 noch keine Microsoft Updates eingeflossen. Das wir hier bemängelt und deutlich angezeigt.
Klicken wir auf den Fehler, kommt Folgendes
Hier der angezeigte Tip ......
Das SQL Express Setup wird hier abgebrochen
Es sind ca 80 MB , die jetzt installiert werden
Diese ".net" Installation dauert scheinbar ewig
>>>>>> Das letzte "Win 10" Update vom Okt 2025
ist 1,8 Gigabyte groß und weigert sich standhaft, auf diesem PC installiert zu werden. Also lassen wir es erstmal aus. Vermutlich brauchen wir von den dortigen Reparaturen gar nichts.
Also geht es weiter mit der SQL Installation
und wirklich, die Installation geht ganz normal weiter
Für Azure haben wir keine Lizenz
nochmal ganz deutlich
Replikation ist etwas für Vollprofis, wollen wir nicht
Hier die Betätigung, daß wir die SQL Engine als Dienst installieren
Jetzt geht es zur spezfischen Konfiguration
Wir wollen Benutzer und Passwörter von Windows und MS-SQL unbedingt trennen !
So haben wir das Formular ausgefüllt - mit "SA" Passwort
.
Das "Super Admin" Passwort wird natürlich nicht verraten !
.
Jetzt rauschen die installierten Module im Schnellgang vorbei
So schnell konnte ich gar nicht klicken, wie die Anzeigen gewechselt hatten
Bis hier her ohne Fehler fast fertig
.
Aber das war nicht alles. Es geht noch weiter ...
.
Wie gesagt - noch nicht alles !!!! Prüfen wir den SQL-Dienst :
.
Im Win10 Dienste Manager sehen wir einen CEIP Service
Dort wird oder würde ein Telemetrie Dienst gestartet (siehe Liste oben drüber). Was soll der machen ? Den setzen wir erstmal gezielt auf manuell.
Wird da etwas ausspioniert und nach USA übertragen ?
.
Die Clients sollen/müssen von draußen an die Engine kommen
Dazu müssen noch einige nicht ganz einfache Admin-Funktionen ausgeführt werden. Zum Verständnis - bislang installieren und arbeiten wir auf dem "lokalen" Bildschirm einer virtuellen Maschine (unserer VM2) - die wir im Virt-Manger in der DOM-0 auf dem Linux-Server sichtbar am laufen haben.
Und die grafische Server-Konsole holen wir mit dem TightVNC-Client auf meinen lokalen PC (mit 4 x 27" Monitoren).
Doch die SQL-Engine dieser VM2 soll ja völlig autark von außen zu erreichen sein. Diese VM2 braucht also eine eigene IPV4-Nummer (das brauchte sie bsher nicht, weil ja lkal gearbeitet wurde) und sie braucht einen ganz speziellen offenen SQL-Port (zuerst mal Port 1433) für die Anbindung von außen an die SQL-Engine.
Das muß der MS-SQL Express Manager gesagt bekommen und die WIN-10 Firewall muß dieses Türchen auch offen halten.
.
Der SQL "Server Configuration Manager" kann sehr viel
Um das System stbil al Laufenzu halten, brauchen wir feste IP Nummern in dem lokalen Netz, in den der Server später stehen wird. Und das wird hier eingetragen.
.
.
.
Als nächstes ist die Win10 Firewall an der Reihe
Hier muß ein "Löchlein" in die eingehenden Regeln gesetzt werden
Der Port (ursprünglich 1433) der SQL Engine muß von draußen offen sein.
Protokoll ist TCP und der Port ist noch 1433
Damit man es auch später überschauen kann
.
Jetzt kommt das Wichtigste - die Port-Kontrolle mit dem AngryIP-Scanner
Hier der erste Hauruck-Test, ob beide VMs (mit den vorläufigen temporären lokalen IPs .131 und .132) überhaupt sichtbar sind.
Jetzt der Detail-Test mit Port-Prüfung
Wie in der Einleitung zu der ganzen MS-SQL-Installation ausgeführt, sollen beide virtuellen Maschinen von aussenliegenden SQL-Clients über den gleichen SQL-Port angesprochen werden können. Hier haben wir endlich das Ergebnis, es funktioniert.
Auffällig ist, daß die Antwortzeiten der WIN10 VM2 deutlich länger sind als die der VM1 unter Linux. Ob das später bei der realen Prüfung irgend etwas erkennbares ausmacht, ist noch unbestimmt.
.
.
In dem Prüfprogramm "angry ip scanner" habe ich explizit den Standard MS-SQL Express Port 1433 abgefragt, denn nur der interessiert uns zur Zeit.
.
.
Als zweiter Test wird dann der gesamte Port-Bereich von Port 1 bis 3000 an gescannt, genauso wie es die Chinesen und Russen bei uns machen können oder tun.
Das dauert natürlich bedeutend länger und erzeugt heftigen Netzwerk-Traffic. Soetwas ist sehr auffällig und kommt aus den "asiatischen Ländern" seltenst vor.
.
Bei der Auflistung der offenene Ports der VM2 (Windows 10) sieht man, daß dort noch mehr Ports geöffnet sind. Doch diese Ports sind durch die spätere Fritzbox- Portweiterleitung unsere SQL Ports geblockt und von draußen nicht sichtbar und auch nicht zu erreichen.
.
Auf der nächsten Seite wird ein SQL-Admin Client vorgestellt.
kommt noch






















































