mwiederkehr

Theoretisch müssten um die 800 MB/s drin liegen, aber ich war mit den 300 MB/s zufrieden in Anbetracht des nicht mehr ganz neuen MSA2052 und RAID 6. Gerne! Die Ports auf den Hosts haben je eine IP und sind "standalone", also nicht in einem Team. Ist eine separate Karte mit vier Ports, also keine virtuellen Adapter mit anderem VLAN oder so. Bezüglich MPIO habe ich gelesen, man solle bei 10 GBit/s Round-Robin ausschalten und auf Failover umstellen. Das dauernde Umschalten zwischen den Verbindungen bringe nicht viel, da 10 Gig den Speicher eh sättige. Ja, das habe ich geprüft. Habe den Test auch von allen Hosts aus auf alle Volumes durchgeführt, immer mit dem Resultat 11.1 MB/s.

Hallo zusammen Es besteht ein Cluster für Hyper-V aus vier ProLiant DL360 Gen10, welche über zwei Cisco-Switches mit 10 GBit/s zum Storage verbunden sind. Dieser besteht aus einem HPE MSA und zwei Huawei OceanStor. Mit dem MSA läuft alles super. Das Kopieren einer grossen Datei auf ein darauf befindliches CSV läuft mit um die 300 MB/s. Der Zugriff auf die Huaweis läuft nur mit exakt 11.1 MB/s. Dies ist von allen Hosts aus der Fall. Die Latenz ist dabei sehr gering (wie zu erwarten bei SSDs) und VMs laufen problemlos (wenn auch mit entsprechendem Zeitbedarf zum Booten). Auf den Switches werden keine Pakete verworfen. Die Ereignisanzeige sagt nichts, auf dem Cluster ist alles grün. Auf den Huaweis wird bei allen Interfaces ein Link mit 10 GBit/s angezeigt. Ich denke, es könnte ein Problem mit MPIO sein. Beim MSA haben alle Ports eines Controllers die gleiche IP-Adresse und der Pfad zum aktiven Controller ist "optimiert". Bei den Huaweis hat jeder Port eine andere IP-Adresse und alle Pfade sind gleichwertig. Dies ist laut Dokumentation jedoch korrekt. Bevor ich mich an die umfangreiche Fehlersuche mache, wollte ich kurz fragen, ob jemandem die 11.1 MB/s bekannt vorkommen? Hatte jemand schon mal ein solches Verhalten? Besten Dank für eure Tipps!

Hallo zusammen Habe für folgendes Problem keine Lösung: in einer RDP-Datei soll die Domain vorgegeben werden, nicht jedoch der Benutzername. Der zuletzt angemeldete Benutzer dürfte schon sichtbar sein, das Kennwort aber nicht gespeichert werden. Das Speichern des Kennworts kann ich per GPO verbieten oder mit dem "Public Mode" in der RDP-Verknüpfung. Aber bei beiden Varianten schaffe ich es nicht, die Domain vorzugeben. "domain:s:domainname" hat keinen Effekt. Eigentlich möchte ich das gleiche Verhalten wie beim guten alten Anmeldebildschirm, den es seit NLA nicht mehr gibt. (Das Deaktivieren von NLA ist keine Option.) Geht das mit Bordmitteln irgendwie? Vielen Dank für eure Tipps!

Funktionieren tut es problemlos, ist aber irgendwie so nicht vorgesehen und muss deshalb über die Registry aktiviert werden: https://ryanmangansitblog.com/2014/01/04/publish-remote-desktop-session-in-a-remote-app-session-collection/

Allenfalls wäre ein spezieller Test-Mailserver eine Option, zum Beispiel smtp4dev. Der braucht keine Installation, nimmt jegliche E-Mails an und stellt sie in einem Webinterface dar.

Das könnte ein Anwendungsfall für Windows Autopilot sein. Damit würde das Gerät bei der ersten Verbindung im Azure AD registriert und der Benutzer müsste sich mit seinem Schul-Account anmelden. Gleichzeitig hätte man es in der Verwaltung von Intune. Voraussetzung ist natürlich, dass die Schule Microsoft 365 nutzt.

Wie Norbert schon geschrieben hat, könnte man es mit der Windows Suche probieren. Einem Kunden, dem das nicht gereicht hat, habe ich Copernic Desktop Search installiert. Nur auf seinem Rechner, da Kleinfirma. Er war begeistert. Die haben auch eine Serversuche: https://www.copernic.com/en/products/search-server/. Laut Website werden bei den Suchresultaten die Windows-Berechtigungen berücksichtigt.

Dort, wo E-Mail als kritisch angesehen wird, sollte man hinterfragen, ob es sinngemäss eingesetzt wird. Hatte mal so einen Fall, da wurden Daten von einer Disposition per E-Mail an den Zoll geliefert, wo dann automatisch Zolldokumente erstellt und zurückgeschickt wurden. Dies frühmorgens, da ohne diese Dokumente die LKW nicht abfahren konnten. Es kam, wie es kommen musste: SPF nach Migration falsch, Mails kamen nicht an, Firma hat Geld verloren. Danach kam dann raus, dass der Zoll eine Webschnittstelle anbietet und man konnte die Applikation direkt mit der Schnittstelle sprechen lassen. E-Mail ist kein gutes Medium für Maschinen-zu-Maschinen-Kommunikation.

Normalerweise geht man in die Cloud, um sich genau solche Gedanken nicht mehr machen zu müssen. Bezüglich Verfügbarkeit würde ich mir bei Microsoft keine Sorgen machen. Ergänzend sind Mailstore zur Archivierung und Veeam als Backup sicher gute Lösungen.

Da die VHDX noch in Ordnung zu sein scheint, sollte es funktionieren, eine neue VM anzulegen und ihr die Disks anzuhängen. Die hat dann aber eine andere GUID und man muss das Netzwerk wieder konfigurieren und allenfalls gewisse Software wieder aktivieren. Alternativ die VM-Dateien aus einer Sicherung zurückholen und die aktuellen VHDX anhängen. Was auch gehen sollte, ist ein Export der VM. Dabei werden keine Snapshots exportiert. Evtl. reicht es auch, den "Virtual Machines"-Ordner zu kopieren, die VM zu löschen, danach die VM aus der gesicherten Konfiguration zu importieren und die VHDX anzuhängen.

Es gibt von Microsoft das "PST Collection Tool", welches für diesen Zweck entwickelt wurde. Habe es allerdings noch nie eingesetzt.

Da würde ich noch eher einen Versuch mit LibreOffice und eM Client wagen. Zumindest bei LibreOffice kenne ich mehrere Firmen, die damit glücklich sind.

OTRS bringt ohne Zweifel die benötigten Features mit (und noch viel mehr). Da ich aber mit der Weboberfläche nie richtig warm geworden bin, verwende ich lieber Zammad. Das gefällt mir in der Bedienung besser. Es kann übrigens Tickets aus OTRS übernehmen.

Bei Tools, die auf Volume-Ebene verschlüsseln, wirst Du um ein Unmount beim Abmelden nicht herumkommen. Du könntest aber zum Beispiel den schnellen Benutzerwechsel deaktivieren und das Unmounten über ein Abmeldescript automatisieren. Bezüglich Ransomware sehe ich keinen Vorteil: solange das Volume gemountet ist, hat jegliche Software darauf Zugriff.

Kosten tut nur die für Windows kompilierte EXE, für Linux ist es gratis. Aber: es ist eigentlich egal, denn Du kostest mehr. Von daher würde sich wohl auch HelloExchange lohnen. Wenn ich es richtig gelesen habe, kostet Dich das pauschal 349 Euro. Und Du hast Support, so dass Du im Fall der Fälle nicht (mit dem ungeduldigen Kunden neben dran) im Regen stehst.

Da Quelle und Ziel IMAP sprechen, sollte der Umweg über Outlook nicht notwendig sein. imapsync hat mir schon bei vielen Migrationen geholfen. Aber damit lassen sich nur E-Mails übertragen, keine Kalender und Kontakte.

Ich würde mir mal Veeam Cloud Connect anschauen. Da läuft beim Provider auch Veeam und das kann die inkrementellen Dateien integrieren, so dass nicht immer wieder ein "geändertes Fullbackup" hochgeladen werden muss.

In Anbetracht der wenigen Benutzer und hohen Sicherheitsanforderungen, würde ich mir eine Cloud-Lösung offerieren lassen. Evtl. bietet der Hersteller der Praxissoftware das an und sonst gibt es viele Dienstleister dafür. Mit Cloud ist also nicht "ich klicke mir einen Server bei Azure" gemeint. So kannst Du Dich auf Dein Geschäft konzentrieren und musst Dich nicht um Backup, Datenschutz etc. kümmern.

Jetzt wollte ich gerade einen Einwand verfassen. Über das "history"-Objekt kann man die History (wozu auch die aktuelle Seite gehört) manipulieren. In den Bookmarks würde die "richtige" (also "gefälschte") Adresse landen. Aber wenn man das auf jeder Seite macht, geht bei den Benutzern der Zurück-Button nicht mehr. Ich habe noch nie gesehen, dass jemand die Adresse auf diesem Weg kürzt. Das Verfahren kommt in der Praxis eigentlich nur bei Single Page Apps (wie Angular und Konsorten) zum Einsatz. Dort setzt man dann eine sinnvolle Adresse, weil sonst immer nur "/" stehen würde. Also genau das Gegenteil. Etwas eleganter könnte man es über den Webserver lösen: erkennt diese eine Suchmaschine, lässt er den direkten Zugriff auf die Seiten zu. Kommt ein Benutzer, wird er auf die Hauptseite umgeleitet. Dort bekommt er ein Cookie gesetzt, welches die Umleitungen deaktiviert. Die Links zum Teilen hätten noch einen Parameter "?noredir" oder so dran. Für sinnvoll halte ich das nicht. Erstens kommt es bei den Benutzern wahrscheinlich schlecht an, wenn sie auf "/xy" gehen und dann auf die Hauptseite umgeleitet werden, um die "tollen Angebote" zu sehen. Zweitens fliegt man höchstwahrscheinlich bei Google aus dem Index, wenn sie merken, dass die Benutzer eine andere Seite zu sehen bekommen als ihr Bot.

Das geht bei modernen Browsern mittels JavaScript. Folgenden Code vor dem schliessenden Body-Tag einfügen: <script type="text/javascript"> history.replaceState('', '', '/'); </script> Den Suchmaschinen sollte das egal sein.

Es gilt seit Release 1803. Ich würde dafür nicht zu viel Zeit investieren. Der Nano Server ist ein Nischenprodukt, erst recht, seit er nur noch für Container verwendet werden kann. (Was ich sehr schade finde, denn zumindest als Host für Hyper-V hätte er schon seine Vorteile gehabt.)

Wie Nils schon erwähnt hat, ist der Nano Server nur noch als Container erhältlich. Die Lizenzierung hängt (wie bei allen Containern) von der Art der "Containerisierung" ab: als normaler Container wird keine zusätzliche Lizenz benötigt. Läuft der Container jedoch im Hyper-V Isolation Mode, zählt er als OSE und damit sind bei Windows Standard nur noch zwei Instanzen erlaubt. (Ohne Isolation müssen alle Container die gleiche Version wie der Host haben. Mehr weiss ich darüber leider nicht, da mir noch nie ein Nano Server in freier Wildbahn begegnet ist. Schon Container auf Windows würde ich zu den seltenen Arten zählen. )

Als ich heute die aktuellen "Major Change Notification" durchgelesen habe, habe ich nicht viel erwartet, schliesslich sind die darin angekündigten "Changes" eher selten "Major". Aber die Freude ist gross: Outlook kann in einigen Monaten die Einstellungen und die Signatur in der Cloud speichern. Das bedeutet, dass in vielen kleinen Umgebungen die Notwendigkeit für servergespeicherte Profile wegfällt. Outlook war ja immer ein Hauptargument dafür. Und in grösseren Umgebungen, wo die Signaturen über eine Software gesetzt werden, kann die Software dies nun zentral tun, ohne im Anmeldescript ausgeführt zu werden. Zwei Links dazu: https://office365itpros.com/2020/05/18/roaming-signatures-outlook-for-windows/ https://office365itpros.com/2020/06/04/outlook-cloud-settings/

Das sind schon produktive Umgebungen, aber zehn Mitarbeiter sind da eher das Maximum. Wobei ich bei so kleinen Umgebungen lieber in die Cloud gehe, weil mittlerweile auch kleine Kunden auf eine verfügbare IT angewiesen sind, aber kein Geld für Hardware-Supportverträge etc. haben.

Ergänzend: in kleinen Umgebungen mit nur einem DC ist dessen Erreichbarkeit wichtig. Solange der DC nicht läuft "geht Internet nicht". Wenn also der Anbieter vom ERP nach einem Update den "Alles-in-Einem"-Server neu startet, gehen in dieser Zeit auch Exchange Online, OneDrive etc. nicht, ebenso die Anruferkennung vom CTI-Client. Da werden dann auch in kleinen Umgebungen die Leute schnell unruhig. Und nein, auf den Clients als zweiten DNS den vom Provider eintragen ist keine Lösung. Bei mir ist der DC deshalb immer separat. In ganz kleinen Umgebungen ist es ein physischer Server mit einer VM als DC und einer VM für alles andere. Da gehe ich dann schon Kompromisse ein und trenne nicht Datei- und Druckserver etc. Praktischerweise darf man mit einer Server-Lizenz ja zwei VMs ausführen, so dass man nicht mal mehr bezahlt für den DC.