Hepprum Hulk

Quatschblödsinnunfug - NEIN, ich meinte natürlich 3301 - 3301 und nicht 3389 ... (habe ich so geändert, nur falsch hier reingeschrieben - guckt mal auf die Uhr, is mitten in der Nacht ). Ich schick den Server nach dem Mittag mal eine Runde runter und wieder rauf (Neustart) ... Dann sehe ich es @dukel / zahni: VPN ist natürlich sicherer, aber wenn ich "außer Haus" bin, finde ich u. U. immer ein Internet und einen PC mit RPD-Client, aber ich kann meist nicht einfach irgendwo ein VPN installieren

Da ich noch keinen Neustart machen konnte (Backup läuft), ist der Sachstand noch dieser: Fritzbox Port an Gerät 3389 - 3389 Port extern gewünscht; 3389 (-> soll 3301 werden) Server: In der Registry ist ebenfalls zur Zeit Port 3389 drin. Ich hätte aber später gerne wieder Port 3301 für diesen Server. Zur Zeit reagiert der Server intern nur auf 192.168.1.1:3301 (also den "falschen" Port), nur mit der IP wird er auch intern über RDP nicht gefunden. Ein Zugriff von extern geht immer noch nicht.

Mal so, mal so. Ich habe das schon vor etwas längerer Zeit so neu einstellen müssen, da mir die Platte kaputtging und ich den Server neu aufgesetzt habe. Die Änderung von 3389 auf 3301 hat er sofort ohne Neustart gefressen. Seitden lief das. Haken tut es ja erst, seit ich den Speicher verdoppelt habe. Bei den aktuellen Problemen habe ich es dann mit Neustarts probiert, was war aber nix.

Jo - inzwischwen kann ich aber als Port einstellen, was ich will, es läuft nur noch über Port 3301. Ich starte das Ding wohl mal neu.

In der Box sieht das so aus - wie gesagt, das ist die Einstellung, die bis zum Speicherwechsel gelaufen ist ... Und im internen Netz läuft die RDP-Verbindung auf 192.168.1.1:3301. Lasse ich den Port weg oder nehme 3389, habe ich keinen Zugriff. Ich habe mal aus Spaß den Port in der Registry wieder zurückgestellt auf Port 3389 und die Einstellungen in der FritzBox so gelassen. Erfolg: Ich kann intern von der 192.168.1.152 immer noch nur mit 192.168.1.1:3301 zugreifen, die Rückumstellung auf Port 3389 interessniert den Server nicht...

Die 192.168.1.1 (also der Hauptserver) hat mittels HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp\PortNumber einen anderen Port bekommen, den ich in der FritzBox auf den internen Port 3389 umsetze. Da diese 192.168.1.1 meine erste DynDNS-Adresse ist, musste ich die Registry bearbeiten. Ging auch immer einwandfei. Bei allen anderen PCs in meinem Netz reicht es, wenn ich in der Fritte einen anderen externen Port hinterlege und den bei der IP in der Fritte zuweise. Vorteil: Ich habe mittels RDP von außen auf jedem PC einen "eigenen" Zugang und brauche eigentlich keine internen Verbindungen mehr. Bis eben auf diese 192.168.1.1, da kommt von außen nix mehr an. 'tschuldigung - BITTE? Klingt etwas so, als sei ich bei einem Seitensprung erwischt worden, ich selber nenne das "Recherche bei verschiedenen Quellen". Seit wann ist das "illegal"? Ich mein, vielleicht kommt ja einer aus einem anderen Forum auf die Lösung und ich könnte die hier dann posten. Also echt jetzt ...

Update von Update: Ich habe die Protokolle der Firewall aktiviert. Interne RDP-Sitzungen auf den Server werden sauber aufgezeichnet. Bei externen benimmt sich der Server so, als ob in keinster Weise irgend was von außen kommt. Im Beispiel hier ist die 192.168.1.152 die virtuelle Maschine, die ich von außen erreiche, und die IP 192.168.1.1 ist der "echte" Server, der nicht mehr von außen erreichbar ist. #Version: 1.5 #Software: Microsoft Windows Firewall #Time Format: Local #Fields: date time action protocol src-ip dst-ip src-port dst-port size tcpflags tcpsyn tcpack tcpwin icmptype icmpcode info path 2018-09-03 15:56:16 ALLOW UDP 192.168.1.152 192.168.1.1 137 137 0 - - - - - - - RECEIVE 2018-09-03 15:56:17 ALLOW UDP 192.168.1.2 192.168.1.1 137 137 0 - - - - - - - RECEIVE 2018-09-03 15:56:23 ALLOW UDP 192.168.1.1 239.255.255.250 49385 3702 0 - - - - - - - SEND 2018-09-03 15:56:23 ALLOW UDP 127.0.0.1 239.255.255.250 49385 3702 0 - - - - - - - SEND 2018-09-03 15:56:23 ALLOW UDP 127.0.0.1 239.255.255.250 49385 3702 0 - - - - - - - RECEIVE 2018-09-03 15:56:23 ALLOW UDP 127.0.0.1 239.255.255.250 49385 3702 0 - - - - - - - RECEIVE 2018-09-03 15:56:24 ALLOW ICMP 127.0.0.1 127.0.0.1 - - 0 - - - - 8 0 - SEND 2018-09-03 15:56:24 ALLOW ICMP 127.0.0.1 127.0.0.1 - - 0 - - - - 8 0 - RECEIVE 2018-09-03 15:56:24 ALLOW ICMP 127.0.0.1 127.0.0.1 - - 0 - - - - 8 0 - SEND 2018-09-03 15:56:24 ALLOW ICMP 127.0.0.1 127.0.0.1 - - 0 - - - - 8 0 - RECEIVE 2018-09-03 15:56:30 ALLOW TCP 192.168.1.152 192.168.1.1 56021 3301 0 - 0 0 0 - - - RECEIVE 2018-09-03 15:56:30 ALLOW TCP 192.168.1.152 192.168.1.1 56022 3301 0 - 0 0 0 - - - RECEIVE 2018-09-03 15:56:37 ALLOW TCP ::1 ::1 55861 445 0 - 0 0 0 - - - SEND 2018-09-03 15:56:37 ALLOW TCP ::1 ::1 55861 445 0 - 0 0 0 - - - RECEIVE 2018-09-03 15:56:37 ALLOW TCP ::1 ::1 55862 135 0 - 0 0 0 - - - SEND 2018-09-03 15:56:37 ALLOW TCP ::1 ::1 55862 135 0 - 0 0 0 - - - RECEIVE 2018-09-03 15:56:38 ALLOW TCP 192.168.1.1 192.168.1.1 55864 389 0 - 0 0 0 - - - SEND 2018-09-03 15:56:38 ALLOW TCP 192.168.1.1 192.168.1.1 55864 389 0 - 0 0 0 - - - RECEIVE 2018-09-03 15:56:38 ALLOW TCP 192.168.1.1 192.168.1.1 55865 389 0 - 0 0 0 - - - SEND 2018-09-03 15:56:38 ALLOW TCP 192.168.1.1 192.168.1.1 55865 389 0 - 0 0 0 - - - RECEIVE 2018-09-03 15:56:39 ALLOW UDP 192.168.1.1 255.255.255.255 22936 22936 0 - - - - - - - SEND 2018-09-03 15:56:40 ALLOW UDP 192.168.1.1 255.255.255.255 49386 22936 0 - - - - - - - SEND 2018-09-03 15:56:40 ALLOW UDP 192.168.1.1 255.255.255.255 49387 22936 0 - - - - - - - SEND 2018-09-03 15:56:45 ALLOW UDP 192.168.1.1 192.168.1.255 49388 22936 0 - - - - - - - SEND 2018-09-03 15:56:50 ALLOW UDP 192.168.1.1 192.168.1.210 49389 9 0 - - - - - - - SEND 2018-09-03 15:56:53 ALLOW UDP 192.168.1.1 255.255.255.255 22936 22936 0 - - - - - - - SEND 2018-09-03 15:56:53 ALLOW UDP 192.168.1.1 255.255.255.255 49390 22936 0 - - - - - - - SEND 2018-09-03 15:56:54 ALLOW UDP 192.168.1.1 255.255.255.255 49391 22936 0 - - - - - - - SEND 2018-09-03 15:56:57 ALLOW TCP 127.0.0.1 127.0.0.1 55867 389 0 - 0 0 0 - - - SEND 2018-09-03 15:56:57 ALLOW TCP 127.0.0.1 127.0.0.1 55867 389 0 - 0 0 0 - - - RECEIVE 2018-09-03 15:56:58 ALLOW UDP 192.168.1.1 192.168.1.255 49392 22936 0 - - - - - - - SEND 2018-09-03 15:57:03 ALLOW UDP 192.168.1.1 192.168.1.210 49393 9 0 - - - - - - - SEND 2018-09-03 15:57:04 ALLOW TCP ::1 ::1 55868 135 0 - 0 0 0 - - - SEND 2018-09-03 15:57:04 ALLOW TCP ::1 ::1 55868 135 0 - 0 0 0 - - - RECEIVE 2018-09-03 15:57:04 ALLOW TCP 192.168.1.1 192.168.1.1 55870 389 0 - 0 0 0 - - - SEND 2018-09-03 15:57:04 ALLOW TCP 192.168.1.1 192.168.1.1 55870 389 0 - 0 0 0 - - - RECEIVE 2018-09-03 15:57:04 ALLOW TCP 192.168.1.1 192.168.1.1 55872 389 0 - 0 0 0 - - - SEND 2018-09-03 15:57:04 ALLOW TCP 192.168.1.1 192.168.1.1 55872 389 0 - 0 0 0 - - - RECEIVE 2018-09-03 15:57:33 ALLOW UDP 192.168.1.1 239.255.255.250 49394 3702 0 - - - - - - - SEND 2018-09-03 15:57:33 ALLOW UDP 127.0.0.1 239.255.255.250 49394 3702 0 - - - - - - - SEND 2018-09-03 15:57:33 ALLOW UDP 127.0.0.1 239.255.255.250 49394 3702 0 - - - - - - - RECEIVE 2018-09-03 15:57:33 ALLOW UDP 127.0.0.1 239.255.255.250 49394 3702 0 - - - - - - - RECEIVE 2018-09-03 15:57:34 ALLOW TCP 192.168.1.152 192.168.1.1 56023 445 0 - 0 0 0 - - - RECEIVE 2018-09-03 15:57:36 ALLOW 2 192.168.1.200 224.0.0.1 - - 0 - - - - - - - RECEIVE 2018-09-03 15:57:38 ALLOW 2 192.168.1.1 224.0.0.22 - - 0 - - - - - - - SEND 2018-09-03 15:57:38 ALLOW UDP 192.168.1.150 192.168.1.1 137 137 0 - - - - - - - RECEIVE 2018-09-03 15:57:44 ALLOW UDP 192.168.1.210 192.168.1.255 137 137 0 - - - - - - - RECEIVE 2018-09-03 15:57:45 ALLOW 2 192.168.1.1 224.0.0.22 - - 0 - - - - - - - SEND 2018-09-03 15:57:52 ALLOW TCP 192.168.1.1 192.168.1.200 55873 49443 0 - 0 0 0 - - - SEND 2018-09-03 15:57:57 ALLOW TCP 127.0.0.1 127.0.0.1 55875 389 0 - 0 0 0 - - - SEND 2018-09-03 15:57:57 ALLOW TCP 127.0.0.1 127.0.0.1 55875 389 0 - 0 0 0 - - - RECEIVE 2018-09-03 15:58:16 ALLOW UDP 192.168.1.152 192.168.1.1 137 137 0 - - - - - - - RECEIVE 2018-09-03 15:58:17 ALLOW UDP 192.168.1.2 192.168.1.1 137 137 0 - - - - - - - RECEIVE 2018-09-03 15:58:21 ALLOW TCP 192.168.1.152 192.168.1.1 56024 135 0 - 0 0 0 - - - RECEIVE 2018-09-03 15:58:21 ALLOW TCP 192.168.1.152 192.168.1.1 56025 49158 0 - 0 0 0 - - - RECEIVE 2018-09-03 15:58:24 ALLOW UDP 192.168.1.152 192.168.1.1 62025 389 0 - - - - - - - RECEIVE 2018-09-03 15:58:24 ALLOW TCP 192.168.1.152 192.168.1.1 56026 88 0 - 0 0 0 - - - RECEIVE 2018-09-03 15:58:24 ALLOW TCP 192.168.1.152 192.168.1.1 56027 88 0 - 0 0 0 - - - RECEIVE 2018-09-03 15:58:24 ALLOW TCP 192.168.1.152 192.168.1.1 56028 88 0 - 0 0 0 - - - RECEIVE 2018-09-03 15:58:24 ALLOW TCP 192.168.1.152 192.168.1.1 56029 445 0 - 0 0 0 - - - RECEIVE 2018-09-03 15:58:24 ALLOW TCP 192.168.1.152 192.168.1.1 56030 88 0 - 0 0 0 - - - RECEIVE 2018-09-03 15:58:24 ALLOW TCP 192.168.1.152 192.168.1.1 56031 88 0 - 0 0 0 - - - RECEIVE 2018-09-03 15:58:24 ALLOW TCP 192.168.1.152 192.168.1.1 56032 88 0 - 0 0 0 - - - RECEIVE 2018-09-03 15:58:24 ALLOW TCP 192.168.1.152 192.168.1.1 56033 49155 0 - 0 0 0 - - - RECEIVE 2018-09-03 15:58:24 ALLOW TCP 192.168.1.152 192.168.1.1 56034 88 0 - 0 0 0 - - - RECEIVE 2018-09-03 15:58:24 ALLOW TCP 192.168.1.152 192.168.1.1 56035 445 0 - 0 0 0 - - - RECEIVE

Update: Nach kleinen Problemen mit der Lizenzierung (ich habe versucht, die Lizenz zu lösen und wieder zuzuteilen; an anderer Stelle sprach einer davon, daß das die Lösung sein könnte) und einem Gespräch mit Microsoft geht der Server nun zumindest nicht mehr alle Stunde einmal aus und ist wieder aktiviert. Man sollte nicht rumspielen Da ich aber mit dem Problem selber noch keinen Meter weiter bin, habe ich mal AVM kontaktiert mit der Frage, ob ich in der FritzBox irgend welche erweiterten Protokolle finden kann. Die Frage wäre nämlich, ob schon die Box die Einwahl blockt oder auf dem Weg von der Box zum Server irgend was in die Hose geht. Ich habe die Serverprotokolle nochmal gelöscht und den Server neu gestartet in der Hoffnung, irgend welche Hinweise auf eine Portblockierung o. ä zu finden - Fehlanzeige ...

Nachtrag: Portfreigabe auf dem Router gelöscht und neu gesetzt - nichts.

VPN habe ich auch, das läuft einwandfrei. Ich habe inzwischen herausgefunden, daß ich bei einem telnet auf den DynDNS-Namen mit dem bestimmten Port an die Wand laufe. Warum, kann ich noch nicht sagen, aber die RDP-Verbindung auf diesen Server ist das einzige, was NICHT funktioniert.

200 aus der Liste entfernt. Hat sich aber nichts geändert. Ich denke auch eher, daß sich das Problem irgendwo zwischen Internet, der FritzBüchse und dem Host abspielt, nicht auf dem Host in Sachen DNS oder so. Leider sehe ich im Fritz keine Protokolle, die irgendwie auf Verbindungsversuche hindeuten (das kann das Ding nicht). In sofern kann man auch nicht diagnostizieren, ob der Fritz die Anfragen über RDP aus dem INet überhaupt registriert oder zumindest mal abweist. Der Server würde mir ja in den Protokollen wenigstens erzählen, daß ein Versuch des Connect stattgefunden hat. Fehlanzeige, Ach so, EINE Änderung habe ich doch noch gemacht: Ich habe beiden virtuellen Maschinen gestern nach der Erweiterung je 2 GB mehr Arbeitsspeicher zugeteilt.

Firewall kann ich ein- oder ausschalten, das ändert nix. Und das Malwarebytes-Gelöt läuft ja auch unverändert (also keine Updaes derzeit oder so). Außerdem ist das nicht vergleichbar mit "normaler" AV-Software, also hat beinhaltet keine Firewall oder so. Siehe https://forums.malwarebytes.com/topic/211708-latest-version-mbarw-beta-09-v-0918807-download/ Meine Netzwerkkonfig: LAN-Verbindung: LAN-Verbindung 3 (IP 200 ist der Router und der 2. DNS-Server):

Richtig, alles läuft normal in dieser Richtung, nur der Host nicht. IP6 habe ich eben wieder aktiviert. Brachte nix. Die Sache mit "2008 ist veraltet" ist soweit korrekt, das Ding läuft aber, steht in meinem HomeOffice, und bisher habe ich noch keinen Spender gefunden, der mir einen 2012er oder 2016er schenkt . Der 2008er konnte ich legal als Enterprise für unter € 100 kriegen, gleichlautende Angebote für neuere Versionen sind bisher Fehlanzeige. Firewall ist aus, ich habe nur den Defender sowie eine MalwareBytes-AntiRansomWare.

Liebe Gemeinde, (dieses Thema scheint sich in abgewandelter Form als Dauerbrenner zu entwickeln und tribt mich die nackte Wand hoch) ich hatte schon mal Probleme mit RDP von extern (auch auf die virtuellen Maschinen), hier hatte sich aber meine Festplatte verabschriedet, was die Fehler verursacht hatte, und nach Neuinstallation des Servers war alles gut. Auf besagtem 2008er Server R2 spielt sich folgendes Szenario ab: 1. AutoLogin bei einem User, der außer der Anzeige des Anrufbrantworters nichts darf. Eine externe VNC-Sitzung von außen auf diesen Server geht. 2. Über RDP ist normalerweise auch ein externer Zugriff möglich, nämlich auf das Administrator-Konto auf den Server direkt sowie auf zwei virtuelle HyperV-Maschinen - alles bestens. Ich habe nun gestern die bisherigen 16 GB Arbeitsspeicher rausgerissen und gegen 32 GB ersetzt, soweit eine feine Sache. Ich konnte auch nach ersten Tests 3. am angemeldeten Anrufbeantwort-Profil aus eine interne RDP-Sitzung starten und den Server als Admin administrieren (externe Tests hatte ich keine gemacht, ich war ja direkt am Server). Ein erster Zugriff heute morgen von einem externen Standort zeigt nun: a) Ein externer RDP-Zugriff auf den Server ist nicht mehr möglich, es kommt die Standard-Meldung. b) Die externen RDP-Zugriffe auf die virtuellen Maschinen auf diesem Server gehen. Die Virtuellen haben logischerweise andere IPs, ich komme nur auf die IP des Servers selber nicht mehr drauf c) Eine VNC-Verbindung auf den Anrufbeantwort-User und von da aus interne RDP-Sitzung auf den User des Admin gehen. Ich hätte aber gerne wieder meinen unmittelbaren externen RDP-Zugriff über DynDNS (auch dieser ist unverändert). d) Ein externer VPN-Tunnel auf den Server läuft problemlos. Sonstige Änderungen am Server (bis eben auf den Speicherwechsel): Keine. Protokoll-Einträge, die auf Fehler hinweisen: siehe hier: Änderungen an meinem Router bzgl. Portfreigabe etc.: Keine. IP V6 auf dem Server aktiviert: Nein (brauchte ich vorher auch nicht) Windows-Updates in den letzten Tagen: Keine. "ping" / "tracert" auf externe IP oder den DynDNS-Namen: Möglich. "netstat -a" zeigt, daß der betreffende Port abgehört wird. Am Router sehe ich, daß beim Start der RDP-Sitzung nicht mal ansatzweise ein Verbindungsversuch stattfindet. Was bitte ist da schon wieder los bzw. kennt jemand Wechselwirkungen zwischen Speichererweiterungen und toten RDP-Verbindungen?

Bin gerade etwas knapp bei Zeit. Sehe nur: Backup der fraglichen Ordner auf Tape läuft, nur NAS muß ich nochmal überarbeiten, Zugriffsfehler. Der Admin ist aber der selbe, komische Sache ...

Schaue ich mir mal an Korrrrrrrrrrrrrrrrrrrekt Also jetzt etwas weg davon, aber ursprünglich.

Das mit dem Backup ist nur ein "Nebenkriegsschauplatz" (ich nutze Z-DBackup mit einem Streamer und auf NAS). In der "alten" Konfiguration hatte ich nie Probleme, aber seit der Neuinstallation ist der Wurm drin.

Es handelt sich im meinen privaten "Test-Server", da ist das immer so eine Geldfrage mit neuen Server-Betriebssystemen Neu aufgesetzt wurde er, weil die Systemplatte kaputtging und ich jetzt eine SSD reingeschraubt habe. Der Server ist Hardware, drauf laufen noch zwei VMs unter Windows 7. Updates mache ich regelmäßig, alle Computer im Netz sind auf dem neuesten Stand. Ist das nicht eine ewige Fummelei, wenn der User beispielweise in seinem Ordner einen Unterordner erstellt? Diese Rechte wandern bei mir nämlich nicht mit. Genau so, wenn ich als Admin ein Dokument von User1 in User2 kopiere. Früher hatte der User2 Rechte auf dieses Dokument und konnte es bearbeiten. Jetzt muß ich der Datei als Admin erst die Rechte von User2 zuteilen, damit die Datei von User2 zu öffnen ist.

Liebe Gemeinde, nach einer notwendigen Neuistallation meines Server (2008 R2, Domaincontroller) kämpfe ich mir Berechtigungs-Problemen, die ich mir nicht so richtig erlöären kann: Ich habe als Beispiel drei User User1, User2 und User3 in der AD, auf eines zweiten Festplatte ist ein freigegebener Order "Data". Innerhalb dessen sind jeweils User-Ordner mit mehreren Unter-Ordnern und Zugriff für immer genau diesen User, ein vierter Ordner ist freigegeben für alle drei. Ich stelle nun fest: Dir jeden User möchte ich eine Zugriffsberechtigung erstellen ersten z. B. auf Ordner User1 für den Administrator (Vollzugriff) und User1 (kein Vollzugriff, aber lesen, schreiben, löschen etc.). Im freigegebenen Netzwerkordner stellt es sich so dar, daß User1 und der Admin Rechte haben auf den Ordner User1. Das selbe gilt auf die Ordner der zweiten Ebene innerhalb des Ordners User1. Auf der dritten Ebene, also in den weiteren Unterordnern, ist aber Schluß. Der Administrator bekommt keine Zugriffsrechte auf diese Ordner, das darf nur der User. Möchte ich das in den Rechten ändern, habe ich keinen Zugriff und muß wieder den Besitz der Ordner übernehmen. Damit fliegen aber die Rechte für User1 raus. Er steht sauber eingetragen in den Ordner-Rechten, kommt aber über das Netzwerk nicht dran. Ich habe alle Daten schon auf eine andere Platte verschoben, die Platte formatiert, alle Daten zurückgeschoben und alles neu eingerichtet, die Zugriffsrechte auf die Ordner bleiben wacklig. Eine weitere Konsequenz daraus ist, daß der Administrator im Rahmen des Backup auf 40 % der Ordner keinen Zugriff hat und die Daten nicht ins Backup schreiben darf. MIt viel Hin und Her habe ich das halbswegs hinbekommen, aber stabil geht anders. Ist mein AD kaputt oder kennt jemand dieses Phänomen?

Kriege ich nicht unter, Büro ist voll Bei der Maschine ist die Systemplatte hin, und da wäre in diesem Falle auch der DC betroffen. Die Daten kriege ich runter, und alle Arbeitsdaten liegen eh auf einer anderen HDD, einem NAS und den Datenbändern. Aber neu installieren ist nötig, dabei fliegt gleich mal die alte Platte raus. Bei meinen VMs ist es so, daß die jeweils unter Windows 7 laufen und einmal 2 und einmal 4 GB Arbeitsspeicher haben. Da der Server selber nur 16 GB hat (ich suche gerade günstige Riegel für eine Erweiterung, ich muß aber ALLE rausreißen, da der Server 16 GB auf 4 x 4 GB hat, jetzt alle Bänke voll sind und das Board sowieso nur 32 GB kann), wird es mit einer dritten VM eng. Zudem hätte ich noch dieses Problem: Meine Lizenz unterstützt m. W. prinzipiell eine zweie Server-Lizenz für eine VM unter Server 2008, aber ich habe nur einen Lizenzcode. Ich habe schon mal probiert, eine VM mit dieser Seriennummer zu installieren, das hat aber nicht funktioniert. Da wäre jetzt die Frage, ob ich entweder was falsch gemacht habe oder ich einen zweiten Code brauchen würde, den der Verkäufer mir aber nicht mitgeliefert hat* ... *nein, das ist nix Schwarzes, sondern ein offizieller Kaufbeleg von Microsoft, halt nur ohne Datenträger und nur einer Lizenznummer.

Ist klar - hat aber auch mit den Finanzen was zu tun und mit dem Platz Serverraum hätte ich gerne, aber vorher will meine Frau ein Ankleidezimmer Ich hatte vor Jahren mal ein Nebengewerbe, man will ja gut erreichbar sein, und es ging mir auf den Wecker, daß jede Nacht um 2 irgend welche Werbefaxe mit Gummibäumen oder Chefsesseln reingeknallt sind. Also habe ich einen PC genommen, da eine FritzCard reingenagelt und Ruhe is. Seitdem nutze ich das als Anfrufbeantworter und Fax. Der ganze Rest ist dann gewachsen, erst mit Windows 2000, dann 2003 und dann 2008. 2008 ist auch nicht taufrisch, aber war günstig, selbst in meiner Enterprise-Version. Ebenso wie die Hardware - der Elitedesk ist kein Server in dem Sinne; der wird aber z. B. von Autokonzernen gerne als Werkstattserver in die Händlerbetriebe gestellt, und da bin ich über das Teil gestolpert. Absolut leise, sehr schnell und Platz für Erweiterungen. Mit gehts halt darum, wie man es macht - HyperV einrichten, WSUS aufsetzen und so Sachen. Plus der "Spielchen", den Server als Anrufbeantworter einzusetzen oder eine virtuelle Maschine als MediaServer. Daß man DC und virtuelle trennen sollte, ist klar (und im Job habe ich auch einen entsprechenden Maschinenpark zur Verfügung), aber privat zum Testen ist das völlig ok für mich. Man kann viel ausprobieren, auch auf einem 2008er; und wenn ich dann im Betrieb an den 2016er gehe, fällt vieles leichter.

Ok, da kann ich nicht mithalten Was ist mit dem Krach? Ich hab n Elitedesk 800 Tower, den hört man selbst mit normalen HDDs fast kaum (das war auch ein Kriterium, wenn man keinen Serverraum hat). 18 Festplatten hören sich laut an ...

1. Ich hab nur einen. 2. Ich nutze den privat und zum Testen und als Selbststudium. Wenn er an die Wand knallt, tut das nur mir weh, keiner Produktivumgebung

Gerade bei Tablets hat das nie eine Rolle gespielt, ich verwende da die Android-app von Microsoft. Es kommt aber auch kein Fehler in dem Sinne, sondern einfach keinerlei Feedback. Ich fürchte, ich kann das als "gelöst" deklarieren und gehe einkaufen. Da sich alles in Wohlgefallen aufzulösen beginnt, immer mehr nicht mehr läuft und zudem ein chkdsk ewig gedauert hat, ist wohl die Platte hinüber. Kein Ding, alle Backups da und ich wollte eh SSD. Aber danke für die Hilfe Wieso?

Korrekt.