18
Win 11 24H2 - Vertrauensstellung zur Domäne verloren
Moin zusammen,
Ich habe hier mit einem einzelnen Notebook Probleme nach dem Update von Windows 11 23H2 auf die Version 24H2.
Umgebung / allgemeine Infos:
Dutzende Mitarbeiter mit Win 10 22H2 und Win 11 23H2/24H2 Geräten am Standort arbeiten ohne Probleme lokal an Notebooks und auf RDP, sowohl per LAN, als auch WLAN.
VPN zu RDP von außerhalb ist eingerichtet.
Windows Domäne, DCs sind aus internem Netz zur Authentifizierung erreichbar, aus Gast-Netz natürlich nicht.
DHCP verteilt IPs, Gateway, DNS, also automatische Aushandlung.
Alle arbeiten sind meinerseits vorerst remote erfolgt, also kein physischer Zugriff auf den Laptop erstmal.
Vorhandene Netzwerke für dieses Notebook am Standort:
- WLAN_Intern
- WLAN_Gast
Kunde hat ein Dell Notebook ohne LAN-Buchse, nur WLAN-Adapter vorhanden.
Betriebssystem Update von Windows 11 23H2 auf Version 24H2 ist am 07.02.25 durch User erfolgt.
Der Mitarbeiter hat direkt nach dem Update versucht, sich regulär wie immer an der Domäne anzumelden über WLAN_Intern, Gerät wird mit Netz auch verbunden, folgender allseits bekannter Fehler tritt dabei auf: Fehlermeldung „Die Vertrauensstellung zwischen dieser Arbeitsstation und der primären Domäne konnte nicht hergestellt werden“
So weit, so bekannt.
Mitarbeiter nutzt das Gerät täglich, keine längere Offlinephase, so daß das Gerät eventuell neu an der Domäne registriert werden müsste. Computerkonto überprüft, Mitarbeiterkonto überpüft, Zeit zur Domäne passt, nichts deaktiviert, nichts gesperrt, keine Passwortwechsel, keine Änderungen am Konto, keine Verschiebung in andere OUs, alles ist wie immer VOR dem Update.
Der Mitarbeiter hat dann das WLAN gewechselt auf WLAN_Gast:
Anmeldung am Gerät funktioniert dann natürlich, aufgrund der gecacheten Anmeldeinformationen.
So, also zumindest schonmal angemeldet am Notebook, allerdings nicht an der Domäne.
Ich habe dann zumindest lokal das letzte und einzige KB für Version 24H2 vom 17.02. deinstalliert, eine Rückkehr zu 23H2 war leider bereits aufgrund des Zeitraumes nicht mehr möglich, weitere Updates sind erstmal ausgesetzt.
Dann mit administrativen Rechten per Registry alle öffentlichen Netzwerkprofile sämtlicher vorhandener interner WLAN auf "Domainauthenticated" umgestellt, bei allen war "öffentlich" als hinterlegte Option, das sollte so nicht. WLAN-Adapter danach deaktviert und wieder aktiviert.
Beim anschliessenden Wechsel des Netzwerkes von GAST auf INTERN wurde der angemeldete Domänenaccount aus der Sitzung geworfen, also der Desktop gesperrt und der User musste sich erneut anmelden.
Bei Anmeldung an internem Netz erneut der obige Fehler der fehlenden Vertrauensstellung.
Also Neustart, wieder WLAN_Intern vor der Anmeldung ausgewählt, erneut selbiger Fehler.
Habe den Kunden dann gebeten, einen Hotspot per Handy zu errichten. Über Hotspot, per VPN, ist die Anmeldung Gerät und am RDP möglich, allerdings nur Behelfslösung. Die gecacheten Credentials sind ja am Gerät meines Wissens nur 30 Tage gültig.
Ich habe mir die gemeldeten Netzwerkprobleme nach Update auf 24H2, die der Kollege Born ja auch schon thematisiert hat, dazu durchgelesen, es gibt ja auch genügend Infos zum gemeldeten Fehler der Vertrauensstellung, allerdings passt das alles irgendwie nicht zu dem Problem auf nur diesem Gerät.
Das Problem scheint hier direkt mit dem Update zusammenzuhängen, ich finde aber keinen passenden Ansatz.
Hat irgendwer eine Idee, nach was ich suchen könnte oder ein selbiges Problem derzeit?
Vielen Dank für Eure Ideen dazu, egal ob vielleicht abwegig oder nicht, ich möchte einfach mal sammeln, falls sich das Problem ausweitet. Ich bekomme eventuell die Tage das Gerät auch zugeschickt und kann dann vor Ort schauen.
Grüße, N3cro
Ich habe hier mit einem einzelnen Notebook Probleme nach dem Update von Windows 11 23H2 auf die Version 24H2.
Umgebung / allgemeine Infos:
Dutzende Mitarbeiter mit Win 10 22H2 und Win 11 23H2/24H2 Geräten am Standort arbeiten ohne Probleme lokal an Notebooks und auf RDP, sowohl per LAN, als auch WLAN.
VPN zu RDP von außerhalb ist eingerichtet.
Windows Domäne, DCs sind aus internem Netz zur Authentifizierung erreichbar, aus Gast-Netz natürlich nicht.
DHCP verteilt IPs, Gateway, DNS, also automatische Aushandlung.
Alle arbeiten sind meinerseits vorerst remote erfolgt, also kein physischer Zugriff auf den Laptop erstmal.
Vorhandene Netzwerke für dieses Notebook am Standort:
- WLAN_Intern
- WLAN_Gast
Kunde hat ein Dell Notebook ohne LAN-Buchse, nur WLAN-Adapter vorhanden.
Betriebssystem Update von Windows 11 23H2 auf Version 24H2 ist am 07.02.25 durch User erfolgt.
Der Mitarbeiter hat direkt nach dem Update versucht, sich regulär wie immer an der Domäne anzumelden über WLAN_Intern, Gerät wird mit Netz auch verbunden, folgender allseits bekannter Fehler tritt dabei auf: Fehlermeldung „Die Vertrauensstellung zwischen dieser Arbeitsstation und der primären Domäne konnte nicht hergestellt werden“
So weit, so bekannt.
Mitarbeiter nutzt das Gerät täglich, keine längere Offlinephase, so daß das Gerät eventuell neu an der Domäne registriert werden müsste. Computerkonto überprüft, Mitarbeiterkonto überpüft, Zeit zur Domäne passt, nichts deaktiviert, nichts gesperrt, keine Passwortwechsel, keine Änderungen am Konto, keine Verschiebung in andere OUs, alles ist wie immer VOR dem Update.
Der Mitarbeiter hat dann das WLAN gewechselt auf WLAN_Gast:
Anmeldung am Gerät funktioniert dann natürlich, aufgrund der gecacheten Anmeldeinformationen.
So, also zumindest schonmal angemeldet am Notebook, allerdings nicht an der Domäne.
Ich habe dann zumindest lokal das letzte und einzige KB für Version 24H2 vom 17.02. deinstalliert, eine Rückkehr zu 23H2 war leider bereits aufgrund des Zeitraumes nicht mehr möglich, weitere Updates sind erstmal ausgesetzt.
Dann mit administrativen Rechten per Registry alle öffentlichen Netzwerkprofile sämtlicher vorhandener interner WLAN auf "Domainauthenticated" umgestellt, bei allen war "öffentlich" als hinterlegte Option, das sollte so nicht. WLAN-Adapter danach deaktviert und wieder aktiviert.
Beim anschliessenden Wechsel des Netzwerkes von GAST auf INTERN wurde der angemeldete Domänenaccount aus der Sitzung geworfen, also der Desktop gesperrt und der User musste sich erneut anmelden.
Bei Anmeldung an internem Netz erneut der obige Fehler der fehlenden Vertrauensstellung.
Also Neustart, wieder WLAN_Intern vor der Anmeldung ausgewählt, erneut selbiger Fehler.
Habe den Kunden dann gebeten, einen Hotspot per Handy zu errichten. Über Hotspot, per VPN, ist die Anmeldung Gerät und am RDP möglich, allerdings nur Behelfslösung. Die gecacheten Credentials sind ja am Gerät meines Wissens nur 30 Tage gültig.
Ich habe mir die gemeldeten Netzwerkprobleme nach Update auf 24H2, die der Kollege Born ja auch schon thematisiert hat, dazu durchgelesen, es gibt ja auch genügend Infos zum gemeldeten Fehler der Vertrauensstellung, allerdings passt das alles irgendwie nicht zu dem Problem auf nur diesem Gerät.
Das Problem scheint hier direkt mit dem Update zusammenzuhängen, ich finde aber keinen passenden Ansatz.
Hat irgendwer eine Idee, nach was ich suchen könnte oder ein selbiges Problem derzeit?
Vielen Dank für Eure Ideen dazu, egal ob vielleicht abwegig oder nicht, ich möchte einfach mal sammeln, falls sich das Problem ausweitet. Ich bekomme eventuell die Tage das Gerät auch zugeschickt und kann dann vor Ort schauen.
Grüße, N3cro
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 671492
Url: https://administrator.de/forum/win-11-24h2-vertrauensstellung-zur-domaene-verloren-671492.html
Ausgedruckt am: 21.02.2025 um 05:02 Uhr
18 Kommentare
Neuester Kommentar
Moin,
DNS Einstellungen hast du sicher schon gecheckt, oder? Weil eigentlich ist es ja immer DNS...
Dann:
Gerät aus der Domäne nehmen, altes Computerobjekt aus dem AD löschen und dann die Kiste wieder joinen. Vorher natürlich sicherstellen, das lokales Admin-PW bekannt ist.
lg,
Slainte
DNS Einstellungen hast du sicher schon gecheckt, oder? Weil eigentlich ist es ja immer DNS...
Dann:
Gerät aus der Domäne nehmen, altes Computerobjekt aus dem AD löschen und dann die Kiste wieder joinen. Vorher natürlich sicherstellen, das lokales Admin-PW bekannt ist.
lg,
Slainte
Moin,
hast du die Vermutung, dass das 24H2 Update die DNS-Einstellung am lokalen Netzwerkadapter so verändert haben könnte, das trotz automatischer Aushandlung durch Gerät und den DHCP dann trotzdem keine Verbindung zur Domäne zustande kommt? Wie gesagt, VOR dem Update gab es keine Probleme. Ich sehe das leider derzeit nicht, da der Kunde mir NACH Anmeldung nen Teamviewer aufmachen muss, das klappt aber nur ausm Gästenetz. Das Interne Netz kann ausgewählt werden, am Anmeldebildschirm, das ist auch "verbunden", mehr Infos bekomme ich so leider nicht. Die allgemeinen DNS-Einstellungen funktionieren auf allen anderen Clients am Standort auch weiterhin.
Ich komme derzeit also leider nur per Teamviewer in die nicht authentizierte Sitzung des Mitarbeiters über Gästenetz, und über das Gäste WLAN kriege ich die Kiste vielleicht dann nicht wieder in die Domäne, wenn ich die jetzt remote rauswerfe. Lokaler Admin ist aber bekannt, der muss auch herhalten für die administrativen Eingriffe, der Mitarbeiter darf ja mit seinem Account nix. Ich muss also warten, bis das Gerät hier ist.
Zumindest die Problemursache möchte ich zudem auch herausbekommen, ich habe die vage Vermutung, dass es nicht bei einem Gerät mit diesem Problem bleibt, wenn Richtung Oktober so einige Kisten die 24H2 Updates fahren.
hast du die Vermutung, dass das 24H2 Update die DNS-Einstellung am lokalen Netzwerkadapter so verändert haben könnte, das trotz automatischer Aushandlung durch Gerät und den DHCP dann trotzdem keine Verbindung zur Domäne zustande kommt? Wie gesagt, VOR dem Update gab es keine Probleme. Ich sehe das leider derzeit nicht, da der Kunde mir NACH Anmeldung nen Teamviewer aufmachen muss, das klappt aber nur ausm Gästenetz. Das Interne Netz kann ausgewählt werden, am Anmeldebildschirm, das ist auch "verbunden", mehr Infos bekomme ich so leider nicht. Die allgemeinen DNS-Einstellungen funktionieren auf allen anderen Clients am Standort auch weiterhin.
Ich komme derzeit also leider nur per Teamviewer in die nicht authentizierte Sitzung des Mitarbeiters über Gästenetz, und über das Gäste WLAN kriege ich die Kiste vielleicht dann nicht wieder in die Domäne, wenn ich die jetzt remote rauswerfe. Lokaler Admin ist aber bekannt, der muss auch herhalten für die administrativen Eingriffe, der Mitarbeiter darf ja mit seinem Account nix. Ich muss also warten, bis das Gerät hier ist.
Zumindest die Problemursache möchte ich zudem auch herausbekommen, ich habe die vage Vermutung, dass es nicht bei einem Gerät mit diesem Problem bleibt, wenn Richtung Oktober so einige Kisten die 24H2 Updates fahren.
Ich sag mal so.... bei mir taucht auch immer wieder mal bei den Clients die Fehlermeldung wegen der verlorenen Vertrauensstellung auf. Alles Fatclients mit noch Windows 10 und mit LAN angebunden und auf denen wird 5 Tage die Woche gearbeitet.
Ich hab mir irgendwann mal vorgenommen, da das Problem zu suchen, wenn ich mal Zeit und Muse habe. Das Problem taucht jetzt nicht übermäßig of auf, aber doch immer wieder mal. Und immer wieder einfach so, ohne dass es eine Änderung gegeben hätte. Auch die Batterie ist nicht das Problem (falsche Uhrzeit oder so).
Direkt auf das Upgrade würde ich es nicht festlegen wollen.
Ich hab mir irgendwann mal vorgenommen, da das Problem zu suchen, wenn ich mal Zeit und Muse habe. Das Problem taucht jetzt nicht übermäßig of auf, aber doch immer wieder mal. Und immer wieder einfach so, ohne dass es eine Änderung gegeben hätte. Auch die Batterie ist nicht das Problem (falsche Uhrzeit oder so).
Direkt auf das Upgrade würde ich es nicht festlegen wollen.
Zitat von @kpunkt:
Ich sag mal so.... bei mir taucht auch immer wieder mal bei den Clients die Fehlermeldung wegen der verlorenen Vertrauensstellung auf. Alles Fatclients mit noch Windows 10 und mit LAN angebunden und auf denen wird 5 Tage die Woche gearbeitet.
Ich hab mir irgendwann mal vorgenommen, da das Problem zu suchen, wenn ich mal Zeit und Muse habe. Das Problem taucht jetzt nicht übermäßig of auf, aber doch immer wieder mal. Und immer wieder einfach so, ohne dass es eine Änderung gegeben hätte. Auch die Batterie ist nicht das Problem (falsche Uhrzeit oder so).
Direkt auf das Upgrade würde ich es nicht festlegen wollen.
Ich sag mal so.... bei mir taucht auch immer wieder mal bei den Clients die Fehlermeldung wegen der verlorenen Vertrauensstellung auf. Alles Fatclients mit noch Windows 10 und mit LAN angebunden und auf denen wird 5 Tage die Woche gearbeitet.
Ich hab mir irgendwann mal vorgenommen, da das Problem zu suchen, wenn ich mal Zeit und Muse habe. Das Problem taucht jetzt nicht übermäßig of auf, aber doch immer wieder mal. Und immer wieder einfach so, ohne dass es eine Änderung gegeben hätte. Auch die Batterie ist nicht das Problem (falsche Uhrzeit oder so).
Direkt auf das Upgrade würde ich es nicht festlegen wollen.
Ja, der Fehler ist ja Dauerthema und ansonsten ohne Probleme auch meist durch erneuten DomainJoin zu klären. Mich stört hierbei allerdings das direkte Auftreten nach dem Funktionsupdate am 07. Februar.
Wenn die Kundengeräte alle dabei in der Nähe stehen würden, auch kein Problem. Kurz rüber und gut.
Da derzeit allerdings so einige Netzwerkprobleme in Verbindung mit dem Funktionsupdate gemeldet wurden, welche teils auch auf den DHCP verweisen, teils auch andere Ursachen haben, vermute ich hier zumindest bei dem Gerät einen Zusammenhang:
Netzwerkprobleme 24H2 - Borns IT- und Windows-Blog
Da hier viele DELL-Geräte eingesetzt werden, möchte ich da nicht vor eine Wand aus Problemen rennen, wenn andere ebenfalls updaten.
Das bringt mir nichts, da der Mitarbeiter sich mit den gleichen Creds am VPN und internen RDP ohne Probleme anmelden kann. Das Problem liegt lokal.
Zitat von @N3cronomicon:
Das bringt mir nichts, da der Mitarbeiter sich mit den gleichen Creds am internen RDP ohne Probleme anmelden kann.
Die User-Credentials haben damit ja rein gar nichts zu tun. Der Befehl setzt das Computer-Passwort zurück und stellt somit wieder die Vertrauenststellung zwischen Maschine und Domain wieder her, wenn diese out of sync mit den in der Domain hinterlegten sind!Das bringt mir nichts, da der Mitarbeiter sich mit den gleichen Creds am internen RDP ohne Probleme anmelden kann.
Das Problem liegt lokal.
Ja eben deshalb ja. Der obige Befehl setzt das Computer-Passwort zurück nicht die User-Credentials,
1
Also wenn ich das richtig verstanden hab, was ich mir da immer wieder mal schnell durchgelesen hab kommts zum genannten Fehler, wenn da beim Ab- oder Anmelden ein Schluckauf in der Verbindung Client-Server besteht. Durch irgendwelche IT-Mechaniken (aka Zauberei) steht dann plötzlich auf dem Server ein anderes Passwort (Computer-Passwort) als auf der lokalen Maschine. Mismatch und Computer sagt nein.
Frage: wenn ich lokal über reset-computermachinepassword (als lokaler Admin) das lokale Passwort zurücksetze, holt sich die Maschine dann das Passwort vom Server? Oder was passiert da?
Mir kommt das jetzt (so mit ohne groß Überlegen oder Durchdenken) als Aushebeln von Sicherheitsmechanismen vor.
Frage: wenn ich lokal über reset-computermachinepassword (als lokaler Admin) das lokale Passwort zurücksetze, holt sich die Maschine dann das Passwort vom Server? Oder was passiert da?
Mir kommt das jetzt (so mit ohne groß Überlegen oder Durchdenken) als Aushebeln von Sicherheitsmechanismen vor.
Oder was passiert da?
Machine Account (AD Computer Object) Password Updates
Moin,
hast mal im Ereignislog des Clienten und des DCs geschaut, was so passiert ?
Eigentlich sollte er dir sagen was nicht läuft. 24h2 macht ja so einiges in dem Bereich Domäne anders als 23H2 (NTLM, SMB, usw.). Vll blockt nen Antivirus was, oder oder oder.
hast mal im Ereignislog des Clienten und des DCs geschaut, was so passiert ?
Eigentlich sollte er dir sagen was nicht läuft. 24h2 macht ja so einiges in dem Bereich Domäne anders als 23H2 (NTLM, SMB, usw.). Vll blockt nen Antivirus was, oder oder oder.
wlan mac fix?
Moin,
Stimmen eigentlich Datum/ Uhrzeit am Client (bitte genau hinschauen, auch auf Monat und Jahr)?
Stimmen eigentlich Datum/ Uhrzeit am Client (bitte genau hinschauen, auch auf Monat und Jahr)?
Kunde hat ein Dell Notebook ohne LAN-Buchse
Dafür gibt es ja Docking-Stations/ USB-Adapter 
Hi,
kurz ins Blaue geraten:
Nutzt Ihr für das Wlan den Windows NPS bzw. Zertifikate zum Authetifizieren?
MS hat ja mit dem Februar-Patchday am strong-certificate-mapping-enforcement-february-2025 rumgeschraubt.
kurz ins Blaue geraten:
Nutzt Ihr für das Wlan den Windows NPS bzw. Zertifikate zum Authetifizieren?
MS hat ja mit dem Februar-Patchday am strong-certificate-mapping-enforcement-february-2025 rumgeschraubt.
Danke erst einmal für die vielen Vorschläge, ich gehe da morgen wieder ran, der besagte User ist vor einer halben Stunde in den Feierabend gegangen.
@mediodia
Ich schau mir die Computer Passwort Sache mal genauer an, eventuell hat das Funktionsupdate da nen async getriggert, wie auch immer. Danke!
Passt zu einem EventLog-Eintrag, den ich gerade gefunden habe von gestern morgen noch, auf anraten von @kevsei:
0x18
KDC_ERR_PREAUTH_FAILED
Pre-authentication information was invalid
The wrong password was provided.
--> Da das Accountpasswort allerdings korrekt ist, kann es sich hierbei eventuell tatsächlich um das Computer Passwort handeln. Wird geprüft!
@em-pie
Ja, Zeit stimmt mit der Domäne überein. Eine Dock oder ein Adapter ist am Standort nicht greifbar gerade und "mal eben hin" geht nicht. Ich bin dran, das mir das Gerät zugeschickt wird.
@Delta9
Danke für den Vorschlag, aber das wird nicht genutzt.
@mediodia
Ich schau mir die Computer Passwort Sache mal genauer an, eventuell hat das Funktionsupdate da nen async getriggert, wie auch immer. Danke!
Passt zu einem EventLog-Eintrag, den ich gerade gefunden habe von gestern morgen noch, auf anraten von @kevsei:
0x18
KDC_ERR_PREAUTH_FAILED
Pre-authentication information was invalid
The wrong password was provided.
--> Da das Accountpasswort allerdings korrekt ist, kann es sich hierbei eventuell tatsächlich um das Computer Passwort handeln. Wird geprüft!
@em-pie
Ja, Zeit stimmt mit der Domäne überein. Eine Dock oder ein Adapter ist am Standort nicht greifbar gerade und "mal eben hin" geht nicht. Ich bin dran, das mir das Gerät zugeschickt wird.
@Delta9
Danke für den Vorschlag, aber das wird nicht genutzt.
Hallo,
Was meinst du mit async getriggert?
Wenn das Computerpasswort nicht passt, ist keine wirkliche kommunikation zwischen Lokalen PC und dessen DC(s) wirklich möglich.
Gruss,
Peter
Zitat von @N3cronomicon:
Ich schau mir die Computer Passwort Sache mal genauer an, eventuell hat das Funktionsupdate da nen async
getriggert, wie auch immer. Danke!Ich schau mir die Computer Passwort Sache mal genauer an, eventuell hat das Funktionsupdate da nen async
Was meinst du mit async getriggert?
Wenn das Computerpasswort nicht passt, ist keine wirkliche kommunikation zwischen Lokalen PC und dessen DC(s) wirklich möglich.
geht nicht.
Warum nicht? Anreise zuuuu laaaang? Problem ist ja erst seit dem 07.02 bekanntIch bin dran, das mir das Gerät zugeschickt wird.
Dann lass dir den DC ebenfalls zuschicken, weil der Client alleine nutzt dir nix.Gruss,
Peter
Zitat von @Pjordorf:
Hallo,
Was meinst du mit async getriggert?
Wenn das Computerpasswort nicht passt, ist keine wirkliche kommunikation zwischen Lokalen PC und dessen DC(s) wirklich möglich.
Hallo,
Was meinst du mit async getriggert?
Wenn das Computerpasswort nicht passt, ist keine wirkliche kommunikation zwischen Lokalen PC und dessen DC(s) wirklich möglich.
Mag sein, daher auch eventuell die Fehlermeldung beim Anmeldeversuch in Verbindung zeitgleich mit dem EventLog-Eintrag. Das will ich ja rausbekommen. Wenn es direkt VOR dem Update geht und direkt NACH dem Update nicht, ist es zumindest für mich erstmal auffällig. Wenns was anderes ist, wird sich das auch zeigen.
geht nicht.
Warum nicht? Anreise zuuuu laaaang? Problem ist ja erst seit dem 07.02 bekanntProblem wurde erst am 18.02. an uns gemeldet, einige Kunden haben da wohl ne entspannte Ader, ansonsten hätte ich das Gerät direkt wieder auf 23H2 gesetzt.
Und für den Kunden sieht die augenscheinlich "funktionierende" Anmeldung mit seinem Account im Gästenetz mit den gespeicherten Konto-Anmeldeinfos halt in Ordnung aus, sobald er die Notebookoberfläche sieht.
Ich bin dran, das mir das Gerät zugeschickt wird.
Dann lass dir den DC ebenfalls zuschicken, weil der Client alleine nutzt dir nix.Gruss,
Peter
Peter
Dann lass dir den DC ebenfalls zuschicken, weil der Client alleine nutzt dir nix.
Oder er hat ne Site 2 Site Verbindung
Och Leude,
die Server-VMs sind bei uns im eigenen Hosting, das ist nicht das Problem. ;-P
Das Endgerät liegt halt beim Kunden und "mal eben" hinfahren kostet ordentlich Zeit, Geld und Nerven. Es ist deutlich günstiger für den Kunden, das Teil herzuschicken. Wir haben schliesslich nicht nur einen Kunden und da mache ich in der Wartzeit lieber was anderes, als auf ner Ruhrpott-Autobahn rumzugammeln. Die A40 zum Beispiel haben die hier vor 50 Jahren einfach unter parkende Autos betoniert.
Wie gesagt, ich schaue erst wieder drauf, wenn das Teil hier ist.
die Server-VMs sind bei uns im eigenen Hosting, das ist nicht das Problem. ;-P
Das Endgerät liegt halt beim Kunden und "mal eben" hinfahren kostet ordentlich Zeit, Geld und Nerven. Es ist deutlich günstiger für den Kunden, das Teil herzuschicken. Wir haben schliesslich nicht nur einen Kunden und da mache ich in der Wartzeit lieber was anderes, als auf ner Ruhrpott-Autobahn rumzugammeln. Die A40 zum Beispiel haben die hier vor 50 Jahren einfach unter parkende Autos betoniert.
Wie gesagt, ich schaue erst wieder drauf, wenn das Teil hier ist.
