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

Guten Morgen zusammen, @Sunny: Ich habe deine Angaben getestet, leider ohne Erfolg. @Gulp: Ja, die Option "Windows 10 1903 and later" ist im WSUS ausgewählt. Es ist sehr seltsam. Alle anderen Clients, darunter auch baugleiche Notebooks, können problemlos mit Windows Updates versorgt werden. Nur dieses eine Notebook bekommt zwar Office (2016) Updates über den WSUS, aber keinen "Kumulative Updates", auch keine "Servicing Stack Updates", ...

@Norbert: Die Clients (allesamt Win 10 Prof.) haben die Versionen 10.0.18362.449 oder 10.0.18362.628. @Sunny: Danke für den Tipp, ich werde es versuchen, heute zu testen.

Hallo zusammen, wir haben im Unternehmen einen WSUS auf einem Server 2016 laufen. Die Server sowie Rechner (überwiegend Notebooks) werden darüber sauber mit Windows- und Officeupdates versorgt. Allerdings haben wir auf einem Notebook das Problem, das im WSUS angezeigt wird, es sei zu 100% installiert - das stimmt aber nicht. Siehe Bild. Verg. Woche waren wir remote auf dem System (ursprünglich wg. eines anderen Themas), dabei ist dies zufällig aufgefallen. Auf dem Notebook war z.B. das letzte "Kumulative Update" vom 2019-12 installiert - kein neueres (obwohl freigegeben). Die anderen Notebooks haben dieses Update weiterhin problemlos bekommen. Das Notebook ist wie viele andere auch in einer entsp. Zuordnung, auch die OS-Sprache ist identisch zu den anderen Systemen. Seltsamerweise werden Officeupdates auf dem Notebook (vom WSUS) angezeigt und können auch problemlos installiert werden. Der Ordner "SoftwareDistribution" wurde bereits gelöscht, brachte nichts. Ich habe auch mal versuchsweise das letzte "Kumulative Update" deinstalliert, aber auch anschließend zeigt er im WSUS "100% installiert" ... Hat jemand evtl. noch eine Idee, was man prüfen könnte oder was die Ursache sein könnte? Gruß und Danke, Sebastian

Wünsche euch ebenso frohe und ruhige Festtage.

Hi, welche DNS Server sind am Client hinterlegt? Du verteilst das ganze wahrscheinlich via DHCP, oder? Gruß Sebastian

Wie sieht es mit den Schattenkopieren aus? Die "klassischen" Ordner (Temp. Verzeichnisse etc.) hast du schon durch? Kannst du mal einen Screenshot des TreeSize posten? Was läuft noch auf dem Server? ggf. ein WSUS? Fileserver?

Hi, wurde Treesize "als Administrator" ausgeführt? Normalerweise ist dann der "Verbrauch(er)" sichtbar. Sind auf dem Laufwerk ggf. Schattenkopien aktiv? Gruß Sebastian

Hallo zusammen, wie man in den Hardwareanforderungen von MS zu Exchange 2019 lesen kann, werden 128 GB empfohlen - ist es jedoch (in der Praxis) wirklich erforderlich? Gibt es zwischenzeitlich bereits produktive Systeme, welche mit weniger RAM arbeiten? Wenn ja, welche "Einschränkungen" oder "Auswirkungen" machen sich dabei bemerkbar? Ich weiß, dies ist abhängig von den Umgebungsparametern, wobei man keine pauschalen Aussagen wirklich treffen kann. Aber gerade für kleinere Firmen ist das doch schon eine Hausnummer. Unsere Firma hat (als Beispiel) aktuell einen (virt.) Exchange 2013 im Einsatz, wir planen evtl. kommendes Jahr auf Exchange 2019 umzustellen (da wir auch teils neue Hardware erhalten). Aktuell sind es knapp 30 Mitarbeiter (jeder mit eig. Postfach) + einige "Funktionspostfächer" (z.Bsp.: Rechnung, Auftrag, ...). Die Exchange DB hat aktuell etwas über 43 GB. Also alles überschaubar. Dafür nun eine Exchange VM mit 128 GB RAM hinstellen, wäre schon eine Menge... Gruß Sebastian

Hi, schau mal nach "Split-DNS". Das ist das, was ihr einrichtet solltet. Intern wie extern würdest du dann mit dem externen Namen arbeiten. Intern leitest du im DNS die "externe" Anfragen einfach auf den jew. (int.) Server weiter. Dann kannst du auch ein entsp. öffentl. SSL Zertifikat im Exchange sauber nutzen (die kosten heutzutage wirklich nicht mehr die Welt). Anschließend hast du auch keine Browserprobleme mehr. Gruß Sebastian

Nur um sicher zu gehen - der Server (2019) ist bereits ein Hyper-V Host oder soll zu einem werden (... 1 bis 2 VMs...)? Wenn Fall 1 - dann kein Hyper-V installieren! Zum einen ist Hyper-V auf einem DC (soweit ich weiß) unsupportet, zum anderen sollte der DC dann in einer VM laufen. Es ist ein "No-Go" auf einem Server mit aktiven "Diensten" zusätzlich den Hyper-V draufzupacken. Wenn Fall 2 - dann muss vom Host der DC weg (wie zuvor -> in einer VM). Ist der Server bereits ein Hyper-V Host so ist dieser ein Hyper-V Host - sonst nix anderes (kein Files, kein DC, kein Printserver, ...). Die Lizenzierung würde dann auch nicht mehr passen. Wenn du Hyper-V einsetzen willst, mach eine VM für den DC und eine VM für den Rest (AV etc.). Alternativ dazu noch weitere VMs, wenn der Host es verkraftet und die Windowslizenzen vorhanden sind.