mwiederkehr

Kenne das Problem, habe aber leider keine Lösung dafür. Bei einem Kunden tritt es im Zusammenhang mit Citrix auf, aber anscheinend hat es damit nichts zu tun. Es wird immer die alte Version der Anwendung gestartet, auch alle Benutzer abzumelden, hilft nicht. Es hilft nur ein Neustart der Terminalserver. Merkwürdig ist schon, dass sich eine offene EXE überhaupt austauschen lässt. Das gleiche Szenario mit Windows 10 als Clients funktioniert übrigens problemlos: solange jemand die Anwendung geöffnet hat, kann man sie nicht austauschen und danach haben alle sofort die neue Version zur Verfügung. Das Problem tritt nur auf, wenn die Clients ebenfalls Server sind. Es besteht auch nur per SMB: hält man die EXE lokal auf jedem TS vor, funktioniert es.

Danke, das kannte ich noch nicht! Sieht gut aus, aber ist vom Preis her eher für die "ich mag Microsoft nicht"- als für die "kostenlos"-Fraktion.

Exchange-Alternativen scheitern nach meiner Erfahrung in der Praxis jeweils an "ich will aber mit Outlook arbeiten!!!"-Usern. Und Outlook ist nun Mal kein "Mailprogramm", sondern ein Exchange-Client (sieht man auch an der lausigen und seit Jahren nicht verbesserten IMAP-Implementierung). CalDAV etc. werden nicht unterstützt und müssen mittels Add-ins nachgerüstet werden. Da beginnen dann die Probleme. Der OP sollte sich deshalb zuerst die Frage stellen, ob Outlook für ihn Pflicht ist. Falls ja, kann ich keine Alternative zu Exchange empfehlen.

Letztes Jahr wurde hier das Konzept „SMBv1-Proxy“ diskutiert: https://www.mcseboard.de/topic/218434-windows-2004-smbv1-freigaben-nicht-direkt-ansprechbar/?tab=comments#comment-1404677 Ein Jahr später gab es bei Heise einen Artikel dazu: https://www.heise.de/ratgeber/Upcycling-Raspberry-Pi-als-Bruecke-zu-Altgeraeten-mit-SMBv1-Protokoll-nutzen-6148994.html. Ob hier Leute von Heise mitlesen? Der Inhalt des Artikels entspricht im Wesentlichen dem Konzept der Vorredner. Der Autor geht noch etwas weiter und geht von einem Gerät aus, welches nur SMBv1 anbietet. Den RasPi hängt er dazwischen und trennt so das alte Gerät vom Netzwerk.

Veeam kann das soweit ich weiss nicht von Haus aus. Scale-Out-Repositories können sich über mehrere Disks erstrecken, aber die müssen alle immer online sein. Theoretisch könnte es mit einer Virtual Tape Library wie der von Starwind funktionieren. Veeam sähe dann per iSCSI einen Tape-Loader und jede Festplatte wäre ein Tape. Ansonsten würde ich die Daten so aufteilen, dass ein Job auf eine Disk passt oder die Disks zusammenfassen, sprich auf ein NAS sichern. Falls nur Dateien gesichert werden sollen, könntest Du es mit WinZip oder 7-Zip versuchen. ZIP-Archive konnte man früher auf mehrere Disketten aufteilen.

Ein Grund, weshalb mir bei der Installation von CUs jeweils etwas unwohl ist. In fast jedem CU steckt irgendwo eine Überraschung, bei der man dann froh ist, dank Internet hoffentlich eine Lösung zu finden. So etwas könnte der Installer abfangen und auch gleich beheben, wenn er schon eine Stunde lang PowerShell-Scripts ausführt. Die Wartezeit liegt daran, dass die als Lösung gezeigten Scripts das neue Zertifikat gültig ab "Get-Date" erstellen und das liegt bei uns in der Sommerzeit zwei Stunden in der Zukunft. Mit (Get-Date).AddDays(-1) wäre das neue Zertifikat sofort gültig.

Mit den Parametern "ALLUSER=1 ALLUSERS=1" sollte es gehen (ja, wirklich beide verwenden...). Quelle: https://docs.microsoft.com/en-us/microsoftteams/teams-for-vdi#deploy-the-teams-desktop-app-to-the-vm Updates gehen dann logischerweise nicht mehr und leider gibt es auch für Admins keinen Updater, sodass man bei Erscheinen neuer Versionen die alte Version deinstallieren und das aktuelle MSI installieren muss. Teams wurde von der Hipster-Fraktion bei Microsoft entwickelt und ist im Grunde nur eine in eine EXE verpackte Webanwendung. An Details wie einen vernünftigen Installer denken Web-Entwickler leider nicht.

Die Firewall sollte kein Problem darstellen. Entweder Du betreibst eine virtuelle Firewall, oder Du gehst zu einem Hoster, welcher Firewalls anbietet. Bei Azure kann man sich beispielsweise VPN-Tunnels dazu mieten. Falls Du den Server selbst betreibst, würde ich zu virtuellen Servern raten und nicht die Hardware mieten. Das ist besser bezüglich Ausfallsicherheit. Sowas wie die Hetzner Cloud. Je nach Ressourcenbedarf käme eine gemischte Lösung in Frage: das Büro per VPN angebunden, damit die Terminals direkt auf die Datenbank zugreifen können, das ERP selbst würde über Terminaldienste freigegeben. So könnte man auch von unterwegs arbeiten und der Zugriff wäre wohl schneller, als wenn alle Datenbank-Abfragen über die Leitung gehen. Falls das ERP kein Office benötigt, sollte sich das mit SPLA über einen Dienstleister bezahlbar lizenzieren lassen. (Oder Du hast das entsprechende M365-Abo mit den terminalserverfähigen Office Apps for Enterprise.) Aber, wie von Evgenij schon geschrieben, frag zuerst den Anbieter an. Es tut sich bei vielen Herstellern was. Ich konnte gerade kürzlich bei einem Kunden in der Transportbranche eine neue Lösung einführen, die den Windows-Client beibehält, aber die Datenbank in Azure auslagert. Client installieren, einloggen, fertig. Funktioniert super, der Kunde ist begeistert.

Kompatibilität ist wichtig, aber manchmal ist es gut, einen Schnitt machen zu können und Konzepte, die sich als nicht so gut herausgestellt haben, über den Haufen werfen zu können. Jeder Entwickler schreibt Software, die er zehn Jahre später anders schreiben würde. Bei Windows fällt mir da als erstes RPC ein, oder auch das Handling der Benutzersitzungen. Unter Unix war es noch nie ein Problem, eine Anwendung auf einen beliebigen entfernten Bildschirm zu bringen. Unter Windows brauchte man dafür Citrix. (Unix hat dafür andere Nachteile, das ist nicht der Punkt.) Oder beim IIS hat man gedacht, es sei eine gute Idee, .NET Code direkt in der Request-Pipeline zu verarbeiten. Dann hat man gemerkt, dass das die Installation von neuen Versionen erschwert bzw. Kompatiblitätsprobleme mit sich bringt. Mit .NET Core kann jede Anwendung ihre Runtime mitbringen. Windows ist vielerorts "schlechter" als es sein müsste, weil man kompatibel bleiben will. Ich will es nicht so haben wie man bei vielen Web-APIs sieht: eine Ankündigung, dass in spätestens einem halben Jahr die bisherige API nicht mehr geht und man bitte umstellen soll. Einfach ein /v1, /v2 etc. zu machen geht aber auch nicht beliebig lange, da man alle Versionen warten muss. Wer gerne noch bessere Kompatiblität als bei Microsoft hat, dem kann ich System i von IBM empfehlen. Eine Kundin verkauft das an ihre (immer weniger werdenden...) Kunden und ich konnte kaum glauben, dass man eine dreissig Jahre alte Software, deren Hersteller seit zehn Jahren nicht mehr existiert, einfach ohne Nervenkitzel auf die aktuellste Hardware übertragen kann. In den dreissig Jahren hat sogar die CPU-Architektur gewechselt, war alles kein Problem.

Ja, grundsätzlich schon, aber ich sehe auch für einzelne Anwendungs-Instanzen Vorteile mit Containern. Ich habe die Hoffnung, dass sich so komplexe Installer, welche x Komponenten installieren oder updaten, vermeiden lassen. Aber da ist wohl etwas zu viel Wunschdenken dabei.

Danke für den Link! Hätte in einem MCSE-Forum nicht mit Kennern des CCC gerechnet. Die hohe Quote hat mich sehr überrascht. Ich hätte mit max. 10% gerechnet, zumal alles Ingenieure waren, die zudem ein IT-Reglement unterschrieben haben. Ist schon krass, kurz eine E-Mail zusammenstellen und schon hat man Zugriff auf die E-Mail-Konten von jedem dritten Mitarbeiter. An dem Fall sieht man, dass MFA nicht nur wegen schlechten Passwörtern eine gute Idee ist, sondern auch wegen unvorsichtigen Benutzern.

Die meisten meiner Kunden nutzen nur den Filter von Exchange Online. Der funktioniert sehr gut, es rutscht wenig durch und es gibt sehr selten False Positives. Microsoft hat den Vorteil, durch die Menge empfangener E-Mails Anomalien schnell feststellen zu können. Sie können dann auch rückwirkend E-Mails aus Postfächern löschen. Durchrutschen wird überall etwas. Ich habe kürzlich für einen Kunden eine Phishing-Kampagne gefahren. Ganz simpel, gültige Domain mit SPF, Name vom Geschäftsführer und dessen Signatur, Text sinngemäss „wegen eventueller Umstellung zurück ins Homeoffice bitte hier klicken und Zugangsdaten eingeben“. Fazit: 80% haben den Link geklickt und 30% ihre Zugangsdaten eingegeben… Gegen zielgerichtete Kampagnen ist wohl jeder Filter ziemlich machtlos.

Vielen Dank für eure Antworten! Von Interesse könnten die verbesserten Container-Features sein, wobei das mehr Wunschdenken ohne konkretes Datum ist, denn ich habe bis jetzt noch keine als Container verfügbare KMU-Software gesehen. Und ich habe mich noch nicht eingelesen, ob man die Container dann direkt auf den Nodes oder mit Nested Virtualization auf Container-Host-VMs laufen lässt. Wie dem auch sei, wenn ich den aktuellen Liefertermin für die Hardware anschaue, wird Windows Server 2022 wohl schon nicht mehr neu sein, wenn ich loslegen kann...

Das Argument „in ein paar Jahren Windows Server upgraden“ würde ich nicht als relevant einstufen, denn der Exchange 2019 ist früher aus dem Support als Windows 2019 (zumindest, wenn man den Extended Support einbezieht). Du wirst 2025 eine Migration durchführen müssen, aber nicht, weil Du Windows 2019 verwendet hast. Ich habe noch nie bei einem Exchange ein OS-Upgrade durchgeführt und weiss nicht mal, ob das unterstützt wäre (wohl eher nicht). Für Exchange ist das Betriebssystem sowieso nur Plattform. Ausser dem IIS braucht er nichts davon, eine neuere Version brächte also keine Verbesserungen. Die Version des Betriebssystems ist dort wichtig, wo man dessen Features braucht: DC, Fileserver, Remotedesktop etc.

Hallo zusammen Demnächst darf ich einen neuen Hyper-V-Cluster bauen. Der Kunde beschafft Lizenzen für 2022 Datacenter und CALs sind für Hyper-V ja keine notwendig. Die Hardware ist unterstützt für 2022, die Backupsoftware (Veeam) ebenfalls. Von daher könnte ich Server 2022 installieren. Aber soll ich? Einerseits sollte man davon ausgehen können, dass eine freigegebene Serverversion stabil genug läuft für den Produktiveinsatz. Andererseits sind die Vorteile bei Hyper-V im Vergleich zu Server 2019 nicht so gross, um viel zu riskieren. Andererseits scheint es von 2019 zu 2022 kein so grosser Schritt zu sein wie von 2008 auf 2012, sodass sich die Fehler in Grenzen halten dürften. Wie macht ihr das? Setzt ihr neue Versionen sofort nach Veröffentlichung ein oder wartet ihr „das erste SP“ ab, wie einem früher geraten wurde?

Ich weiss nicht, wofür ihr Acrobat verwendet, aber von meinen Kunden sind viele auf PDF-XChange umgestiegen, seit Adobe auf das Abo-Modell gewechselt hat. Darunter auch Ingenieurbüros, welche komplexe, aus dem CAD erstellte PDFs bearbeiten. Habe bislang nur Gutes gehört: günstig, schnell, läuft auf Terminalserver. Evtl. wäre das mal eine Evaluation wert?

Meine Kunden setzen Duo ein. Bisher gab es trotz um die 300 damit abgesicherten Konten kaum Supportfälle. Und wenn, dann nur "habe neues Smartphone, bitte neue Registrations-SMS auslösen", die App selbst läuft stabil.

Stimmt, PowerShell-Scripts können signiert werden. VB-Scripts übrigens auch.

Robocopy auf ein Netzlaufwerk beim Abmelden wäre möglich.

Mit "Get-FileHash" bekommst Du in der PowerShell den SHA256-Hash des Scripts. Wie Du diesen in Kaspersky auf die Whitelist setzt, weiss ich nicht.

Normalerweise hat man folgende Möglichkeiten, eine Datei zu bestimmen bzw. freizugeben: - Pfad und Dateiname ⇒ unsicher, wenn Benutzer Schreibzugriff auf Datei hat - Prüfsumme ⇒ muss bei jeder Änderung an der Datei nachgeführt werden - Signatur ⇒ benötigt ein Code-Signing-Zertifikat und Scripts selbst können nicht signiert werden (man kann sie aber mit py2exe in eine EXE-Datei umwandeln und diese dann signieren) In Deinem Fall wäre eine Freigabe über Pfad oder Prüfsumme wohl am praktikabelsten.

Beamforming (je nach Hersteller manchmal anders bezeichnet) können mittlerweile so ziemlich alle Geräte. Aruba und Ubiquiti auf jeden Fall. Aber ich würde mir nicht zu viel davon versprechen. Wenn der Empfang so schlecht ist, dass Beamforming, also das gerichtete Signal auf einen Client, einen wirklichen Vorteil verspricht, montiert man besser zusätzliche APs. In sehr dichten Netzwerken kann eine durch Beamforming mögliche niedrigere Sendeleistung ein Vorteil sein, aber das sind auch Ausnahmen. Ich habe vor mittlerweile fast zehn Jahren einmal das Netzwerk für ein grosses Areal aufgebaut. Das WLAN hat eine spezialisierte Firma gemacht, die machen nur Funk. Die haben Ruckus verwendet und der Techniker hat mir gesagt, alles andere sei „Spielzeug“. Ruckus hat seinen Ruf also ziemlich sicher nicht zu Unrecht. Aber ich bezweifle, dass die Vorteile heutzutage in einem Netzwerk normaler Grösse spürbar sind. Wenn ein Kunde von mir ein besseres WLAN wünscht, ist das eigentlich nie wegen mangelnder Signalstärke, sondern wegen ungenügendem Roaming (Verbindungsabbrüche), gewünschten Zusatzfeatures (Login per SMS) oder Wunsch nach höherer Performance (Wi-Fi 6). Wi-Fi 6 ist aus meiner Sicht ein Muss, auch wenn man die Performance (noch) nicht benötigt. Dann reichen auch APs mit Giga-Ethernet und es müssen nicht die teureren mit 2.5G sein. Wi-Fi 6 bietet neben der Performance noch viele weitere Verbesserungen. Beim Roaming merkt man die Unterschiede zwischen den Herstellern am besten. Ganz einfache Geräte haben einfach alle die gleiche SSID und das gleiche Passwort. Der Client schaut dann selbst, zu welchem AP er sich verbindet. Bessere Modelle können die Clients steuern. Die APs wissen voneinander, wer welchen Client mit welcher Signalstärke sieht. So erkennen sie frühzeitig, dass sich ein Client von AP A in den Empfangsbereich von AP B bewegt und können ihn (falls es der Client unterstützt, wieder ein anderes Thema...) entsprechend steuern. Bei Aruba (evtl. auch bei anderen Herstellern, aber von Aruba weiss ich es) geht das so weit, dass auch die Auslastung des APs in die Berechnung mit einbezogen wird. Kommen nach der Pause 200 Schüler durch die Türe, hat der vorderste AP viel zu tun mit WPA-Handshakes. Andere APs merken das, sehen gewisse Clients auch und teilen dem vordersten AP mit "ich sehe Clients X und Y". Der AP lehnt diese Clients dann ab, wodurch sie sich mit dem hinteren AP verbinden. Aber eben, ein schönes Beispiel, macht sich gut auf Marketing-Folien, aber in der Praxis kommen dann halt doch selten 200 Leute gleichzeitig durch die Türe.

Anfügen möchte ich noch Zammad, ein Fork von OTRS mit moderner GUI. Und Jitbit, welches mit .Net und SQL Server läuft und sich so auch in Umgebungen betreiben lässt, in denen kein Linux vorhanden ist.

Ok, dann zuerst Exchange 2016. Ich arbeite schon seit Version 5.5 mit Exchange, aber ein Guru wie andere hier bin ich nie geworden. Bin heute noch bei jedem CU etwas angespannt. Vielen Dank auf jeden Fall für eure Antworten!

Nach meinen Informationen ist der Exchange 2010 als Produkt selbst nicht mehr unterstützt, dies betrifft jedoch nicht den Einsatz in Hybridkonfigurationen. Dann wäre folgendes Vorgehen möglich? HCW auf Exchange 2010 installieren alle Mailboxen verschieben SCP entfernen, Autodiscover über Exchange Online Exchange 2016 installieren HCW auf dem Exchange 2016 installieren Exchange 2010 deinstallieren Mir erscheint das weniger risikobehaftet als wenn ich an der lokalen Installation etwas anpassen muss, solange dort noch Mailboxen laufen. (Die Umgebung ist seit mehreren Jahren unbetreut und ich habe etwas Bedenken, dass da unschöne Sachen auftauchen.)