Sanches

Danke an euch für den Input, wir werden ISL mal in die Auswahl mit aufnehmen. Und danke auch Damian für's Verschieben

Hallo zusammen, wir (im Bereich ERP Dienstleistung unterwegs) nutzen seit Jahren u.a. TeamViewer für Fernwartung auf die Serversysteme bei unseren Kunden. Vor ca. 2 Jahren wollten wir eigentlich zentral auf FastViewer (genau FastMaster) umstellen. Aufgrund einer internen Entscheidung wird FastViewer jedoch nicht mehr weiter zum Einsatz kommen und wir benötigen Ersatz. Alle Verbindungen auf TeamViewer umzustellen ist nicht geplant. Was sollte abgedeckt werden: - zentrales Management der Verbindungen inkl. Rechtevergabe, wer welche Verbindungen sehen soll - AD-Koppelung - Kunde soll nach Möglichkeit den Zugriff z.B. über einen Dienst de- und aktivieren können - Vorrangig als On-Premise Lösung gesucht, Cloud jedoch nicht ausgeschlossen - 2FA für Zugriff auf Managementkonsole - Wenn möglich: Option für Adhoc Verbindungen zum Enduser (kann aber alternativ über TeamViewer realisiert werden) - Zugriff als RDP-Variante, damit auch mehr als ein Mitarbeiter parallel mit dem Fernzugriff arbeiten kann => Das ist auch einer der Knackpunkte, warum TeamViewer nicht als zentrales Tool dafür verwendet wird (TV verbindet normalerweise immer auf die Konsole bei unbeaufsichtigten Systemen) - Dateiübertragung Unsere Kollegen haben jetzt mal spontan ein Auge auf Splashtop und Anydesk geworfen. Jedoch haben die Kollegen erst angefangen, die Produkte zu evaluieren. Was habt ihr ggf. als Fernwartungssoftware (ggf. auch als Dienstleister) im Einsatz? Welche Alternativen gibt es ggf. noch? Gruß und Danke im vorraus für euren Input.

Hallo Gerd, welche (Fehler-)Meldung bekommst du? "Funktioniert nicht" kann ja vieles bedeuten ... Haben beide SQL Server das gleiche Patchlevel? SQL Server 2014 ist ja auch nicht mehr der neuste ... Welches Betriebssysteme arbeitet unter dem jew. SQL-Server? Sind auf den Server Virenscanner mit FW installiert? Oder kann das ausgeschlossen werden? Oder wurde auch serverseitig (testweise) mal die Firewall deaktiviert ? (oder entsp. passend konfiguriert?) PS: Ist das eine Art Testlab oder Heimnetzwerk oder gibts einen Grund für die Nutzung der HOSTS Dateien statt DNS?

Hi und willkommen im Board. Hast du schon mal einen Blick in die Ereignisanzeige des Servers geworfen? Der sollte dir zum Zeitpunkt des Problems hoffentlich Hinweise geben. Welche Programme laufen auf dem TS? Aber nichts desto trotz kann ich dir nur raten, den Terminalserver wenn möglich zügig bzw. zeitnah durch einen Terminalserver mit einem aktuellem Betriebssystem (z.B. 2016 oder 2019) zu ersetzen. Ich nehme an, das du weißt, das der 2008er Server seit fast 2 Jahren keinen Support mehr hat und somit auch keine Updates mehr bekommt. Gerade durch die jüngsten Ereignissen (Printnightmare und Co) würde ich hier entsp. handeln.

Hole dir ggf. ext. Unterstützung ins Haus! In solchen Situationen sollte man lieber ein paar Euro in die Hand nehmen und dies machen lassen. Wenn du zig Stunden damit verbrätst und es ggf. nicht dein Tagesgeschäft ist, ist es unterm Strich für alle am effektivsten - schließlich ist deine Zeit auch nicht umsonst.

Ich kann mich den vorherigen Kommentaren nur anschließen, möchte aber dennoch einen kleinen Anstoß geben. Was "spricht" denn das Eventlog der Clients? Blockt ggf. eine AV-Lösung (durch eine integr. Firewall) den Zugriff? Klappt der RDP Zugriff ggf., bevor du dich in die Firma per VPN einwählst?

Lasse doch einfach auf einem Server eine Batch/PowerShell-Datei in einem bestimmten Rhythmus (Bsp. jede Minute) laufen, in welcher mit "if exists" auf die .txt Datei geprüft wird. Wird diese gefunden, dann starte (bei Batch z.B. mit "start /wait ...") das Programm XYZ.exe und nach Beendigung kannst du die .txt Datei löschen/verschieben/was-auch-immer...

Wenn alle Aufrufe aus dem gleichen Verzeichnis starten können, kannst du's wie folgt aufbauen. cd\ C: cd \Users\admin\Desktop\batchordner\Batches call "C:\Program Files (x86)\XXXX\XXX.exe" --server=localhost\XXX--database=XXX --dbuser=XXX --dbpass=ABCD --templateid=XXXXX --inputfile=batcheins.csv call "C:\Program Files (x86)\XXXX\XXX.exe" --server=localhost\XXX--database=XXX --dbuser=XXX --dbpass=ABCD --templateid=XXXXX --inputfile=batchzwei.csv ... exit Wie BOfH_666 schon schrieb - Pause entfernen. Ansonsten einfach mal testen und versuchen. Sollte dann noch eine Frage dazu auftauchen, nochmals melden.

Besteht das Problem nur auf einem Client-PC? Dann sollte mal die DNS-Config auf dem Client geprüft werden.

Hi Oreg, Welche Exchange Version hast du im Einsatz? Welche Outlook Version wird genutzt? Mit welchem Browser hattest du den OWA Zugriff getestet, im welchem kein Zertifikatsfehler erschien? Leider ist in deinem 2. Post deine/eure URL nur zum teil anonymisiert (bitte korrigiere das noch!). Schaut man sich jedoch dahinter die URL mal kurz an, erkennt man das selbst signierte 5-Jahres Zertifikat. Hier müsste eigentlich jeder aktuelle Browser bereits beim Aufruf eine Warnung bringen! Kauf dir bitte ein richtiges, öffentliches Zertifikat. Ein einfaches Zertifikat kannst du schon für unter 50€ pro Jahr haben. Ich vermute, das könnte dein Problem schon lösen ...

Mist, dann habe ich mich da in die Irre führen lassen. Man lernt nie aus. Die Clients, die bereits das Build 1909 haben, kommunizieren auch aktiv mit dem WSUS. D.h. im Screenshot sind bereits einige Clients, welche das Build 1909 haben und auch Ihren Statusbericht an den WSUS heute oder vor Tagen gesendet haben. Mit der Verteilung des Build 1909 haben wir vor 2 1/2 Wochen begonnen, diese Woche wollten wir das ganze mal auswerten. Besteht ggf. via PowerShell Befehl oder ähnliches eine Art Auswertung, welcher Client das Build 1909 bereits hat bzw. welcher Client noch aussteht? Ich ziehe die Frage zurück, ich kann ja einfach im jew. Update einen Bericht erstellen... Manchmal sieht man den Wald vor lauter Bäumen nicht Gruß und Danke.

Hallo zusammen, in einer überschaubaren Umgebung (knapp 50 Clients - überwiegend Notebooks, restlich PCs) haben wir vor kurzem über den WSUS begonnen, das Featureupgrade auf 1909 zu verteilen. Zuvor wurden auch schon weitere Featureupgrades, z.Bsp. 1903, 1809, ... über den WSUS (auf einem Win2016) verteilt. Die Clients installieren auch der Reihe nach das Update, allerdings kann ich nun nicht mehr im WSUS über die angegebene Windowsversion analysieren, wer es bereits installiert hat. Anbei mal ein Blick in unserem WSUS. Die Betriebssystemversion wird überwiegend mit 10.0.18362.836 angegeben (teils auch älter, aber das ist ein andere Baustelle ). Einige der Clients sind jedoch bereits mit 1909 versorgt, aber anhand der Version nicht ersichtlich! 10.0.18362.xxx ist eigentlich "Win10 1903", für die bereits versorgten Clients mit 1909 sollte die Version "10.0.18363.xxx angegeben sein. Beispiel am Client, welcher bereits mit 1909 hat: Im WSUS sind auch die Haken für die Produkte "1903 und neuer" gesetzt (daher ja auch das verfügbare Featureupgrade auf 1909...) Hat einer evtl. eine Idee, an was dies liegen könnte? Bin ich vielleicht irgendwo auf dem Holzweg? Gruß und danke vorab, Sebastian

Hi und willkommen im Forum. Kannst du uns noch weitere Details liefern? - Welche genaue Windows Server Version und Edition ist im Einsatz? - Welche genaue SQL Server (Version) und Edition ist installiert? - Laufen noch weitere Sachen auf diesen Server oder ist dieser exkl. ein SQL-Server? Ist Windows und der SQL-Server auf dem aktuellen Stand (Updates)? Gruß Sebastian BTW: 8 GB für einen SQL- bzw. DB-Server ist nicht unbedingt viel, kommt jedoch auf die Anwendung bzw. auf die DB an.

Moin, nur so am Rande... Ein virt. DC kommt eigentlich mit 1 (max. 2) vCPU sowie 4 GB vRAM gut aus, beim Filer denke ich ähnlich. Gruß Sebastian

So ein kurzes Update hierzu. Ich habe nun auf dem Notebook mal nach Windowsupdates suchen lassen. Er hat dabei das Featureupgrade 1909 entdeckt und direkt (ohne Nachfrage) installiert Nunja, war zwar nicht gewollt (interner Rollout mit 1909 soll erst noch folgen), Installation verlief dennoch erfolgreich. Im WSUS selbst zeigt der betroffene Client nach wie vor noch 100% an. Ich warte jetzt mal auf den nächsten Patchday und schaue dann mal, wie das Notebook reagiert bzw. ob sich das ganze nun bessert / ändert / whatever ... Vielen Dank nochmals an alle für den Input