mwiederkehr

Wenn man nur die Kosten für CPU, RAM etc. vergleicht, ist lokal immer günstiger als Cloud. Man muss aber die Unterschiede berücksichtigen: einen lokalen Server 1:1 mit einem virtuellen Server in der Cloud zu vergleichen ist nicht fair: man müsste lokal schon zwei Server (und ein SAN etc.) rechnen, um schon nur die Verfügbarkeit angemessen vergleichen zu können. Wie schon geschrieben wurde, sollte der Kunde zuerst seine Anforderungen definieren und danach vergleicht man Lösungen, welche diese Anforderungen erfüllen.

Es geht, macht aber keinen Spass. Habe das im Einsatz beobachten dürfen: Hauptserver steht in Zentrale, Ersatzserver an zweitem Standort, verbunden über ein VPN mit DSL 100/20. Dem Hyper-V sind die Latenzen und auch gelegentliche Unterbrüche egal. Man darf aber nicht meinen, dass man das Replikationsintervall nur ansatzweise einhalten kann. Die Überwachung zeigt folgendes: am Morgen und tagsüber reicht es meist, um innerhalb der 15 Minuten zu bleiben. Wenn ein Benutzer eine grosse Datei (CAD-Plan mit Luftbild zum Beispiel) speichert, verpasst man aber auch mal einen Zyklus. Abends, wenn die Datenbank-Sicherungen geschrieben werden, dauert der Abgleich dann bis in die Nacht. Fazit: An zweitem Standort einsatzbereiten Server vorhalten: Ja. Dem Kunden irgend eine Garantie geben können, ob die Daten darauf 15 Minuten oder einen Tag alt sind: Nein.

Es sind zwei verschiedene Probleme: - Das März 2018-Update löscht auf Windows Server 2008 R2 unter VMware die Netzwerkkarte und erstellt eine neue. Diese ist dann auf DHCP eingestellt. Ein korrigiertes Update gibt es noch nicht, aber ein Script, welches man vor der Installation des Updates ausführen muss. - Wenn ein Update neue Integrationskomponenten enthält, bootet ein Server 2012 R2 mit Exchange unter Hyper-V extrem langsam und es ist keine Netzwerkkarte mehr vorhanden. Nach einem erneutem (langsamen) Reboot werden die Updates rückgängig gemacht und die Netzwerkkarte ist wieder vorhanden. Auch hier gibt es noch kein korrigiertes Update. Es hilft, vor der Installation die Exchange-Dienste zu beenden, zu deaktivieren und erst nach dem Reboot wieder zu aktivieren und zu starten.

Würde auch zu einer Gateway-Lösung raten. Die Verwaltung ist einfacher und die Handhabung ebenfalls. Man will normalerweise keine verschlüsselten Mails in Benutzerpostfächern, da es die Archivierung erschwert. Kenne eine Firma, die SEPPmail (https://www.seppmail.ch) einsetzt. Das kann verschlüsseln und signieren. Die Zertifikate kann es direkt bei einer CA anfordern, wenn das erste Mail verschickt wird. Preislich weiss ich nicht wie es aussieht, kann mir aber vorstellen, dass sich die CAs die "Managed PKI"-Lösung gut bezahlen lassen.

Evtl. trägt Windows die Werte im SYSTEM-Kontext ein? Sonst könnten Benutzer ohne Adminrechte ja kein Auto-Login konfigurieren. Löscht man die Werte beim Abmelden, kann der User zwar immer wieder Auto-Login konfigurieren, aber es hat keinen Effekt, da die Werte beim Neustart weg sind.

Auf https://support.microsoft.com/de-ch/help/324737/how-to-turn-on-automatic-logon-in-windows steht, wo in der Registry die Login-Informationen hinterlegt werden. Man könnte per GPO diese Werte beim Herunterfahren löschen.

Das Thema Rufumleitung haben wir mit der VoIP-App der Telefonanlage gelöst: Die Hotline-Nummer geht auf eine Rufgruppe. Die Mitarbeiter haben auf ihrem Smartphone die App installiert. Damit können sie sich selbst der Rufgruppe hinzufügen bzw. ausklinken. Gleichzeitig können sie damit den Kunden über die Geschäftsnummer zurückrufen, so dass er danach nicht ihre private Nummer hat. (In unserem Fall ist die Anlage von Mitel, aber das sollte mittlerweile jeder Anbieter können.)

Man unterscheidet bei der Portkonfiguration eines Switches zwischen tagged und untagged VLANs. untagged: Der Switch entfernt die VLAN-ID von ausgehenden Paketen und fügt sie ankommenden Paketen hinzu. An diese Ports schliesst man Geräte an, auf denen man keine VLAN-ID konfigurieren will. Ein Port kann nur ein VLAN als untagged zugewiesen haben. tagged: Der Switch nimmt nur Pakete an, die eine VLAN-ID tragen, welcher dem Port zugeordnet ist. Ein Port kann mehrere VLAN-IDs zugewiesen haben. An solche Ports schliesst man Geräte an, auf denen man VLANs konfiguriert: Access Points, Firewalls oder andere Switches. Ein Beispiel für Deine Umgebung: Du hast bis jetzt keine VLANs und möchtest ein Gäste-WLAN auf VLAN 10 einrichten, welches über einen separaten Router ins Internet geht. Dafür richtest Du auf dem Access Point VLAN 10 ein und weist es der SSID des Gästenetzes zu. Auf dem Switch lässt Du beim Port des Access Points das Default VLAN als untagged und fügst VLAN 10 als tagged hinzu. Auf dem Port, an welchem der Router fürs Gästenetzwerk angeschlossen wird, konfigurierst Du VLAN 10 als untagged.

Ich würde das aktuelle Konzept grundsätzlich in Frage stellen. Nicht die technischen Details, sondern die Art, wie ihr Kunden betreut. Wenn ich es richtig verstehe, ist euer Geschäft die Entwicklung und der Vertrieb von Software. "Historisch gewachsen" habt ihr bei Kunden die komplette Systembetreuung übernommen. Du bist der einzige Systemtechniker in der Firma. Den Server wirst Du wieder hinbekommen, da habe ich keine Zweifel. Aber was ist, wenn Du im Urlaub bist und bei einem anderen Kunden etwas ist? Sind eure Kunden nicht regional sehr verteilt? Wenn die Systembetreuung eher lästige Pflicht als Tagesgeschäft ist, würde ich davon wegkommen. Ihr könntet euch ein grosses, deutschlandweit tätiges Systemhaus als Partner ins Boot holen. Oder aber, ihr bietet eure Software aus der Cloud an, in Zusammenarbeit mit einem Provider. Entweder nur eure Software und für den Rest schaut der Kunde selbst, oder gleich das ganze Paket mit Office etc. Die Hardware kann sich der Kunde dann bei seinem Lieferanten vor Ort beschaffen, Windows mit RDP-Client reicht. Habe solche Umstellungen schon häufiger begleiten dürfen und es waren eigentlich immer alle Beteiligten zufrieden. Der Software-Anbieter kann sich auf sein Kerngeschäft konzentrieren und der Kunde bekommt eine gute Lösung mit monatlichen Kosten und ohne lokalen Server. Wirtschaftlich muss das für euch nicht schlechter sein: entweder ihr verkauft die Cloud-Lösung dem Kunden, oder der Provider verrechnet es und bezahlt euch eine Provision. Du wärst dann für die Koordination des Supports und die Planung der Migrationen zuständig, aber hättest keine Verantwortung mehr für (alte) Hardware zu tragen.

Ohne Smarthost muss der Sendeconnector die Mails direkt an den jeweiligen Zielserver senden. Damit diese die Mails annehmen, müssen einige Bedingungen erfüllt sein: - Die IP muss einen Reverse-Eintrag im DNS enthalten. - Der Exchange muss sich mit dem Namen melden, der im DNS eingetragen ist, nicht mit seinem internen Hostnamen. - Der Reverse-Eintrag sollte gewisse Zeichenfolgen (wie "dyn", "dsl" etc.) nicht enthalten. Im Idealfall richtet einem der Provider einen benutzerdefinierten Eintrag ein, zum Beispiel "mail.domäne.de". - Die IP darf nicht auf einer Blacklist (RBL) stehen. Das sollte sie eigentlich nicht, wenn darüber noch nie Spam verschickt wurde. Nur leider tragen gewisse Provider alle IPs von DSL-Zugängen in Blacklists ein und entfernen sie nur auf Anfrage. - Port 25 muss ausgehend offen sein. Je nach Provider und Abo muss man das freischalten lassen. Mails ohne Smarthosts zuzustellen geht zweifellos, ist aber die letzten Jahre immer aufwändiger geworden. Es kann sich deshalb trotz vorhandener fixer IP lohnen, bei einem Anbieter einen Smarthost zu buchen sowie vielleicht gleich noch einen eingehenden Spamfilter. (Oder man zieht gleich Office 365 in Betracht.)

Ich denke da kommt ihr nicht an SPLA vorbei. "Normale" Lizenzen gehen auf keinen Fall, wenn fremde Firmen auf der Plattform arbeiten. Microsoft CSP ist wie "testperson" schon geschrieben hat ein Modell zur Bestellung und Verrechnung von Office 365 (und soweit ich weiss auch Azure). Windows müsstet ihr über SPLA lizenzieren, Office ginge dann mit Office 365-Lizenzen (Vorsicht: nicht alle Pläne gehen auf Terminalservern). Das Office auch über SPLA zu nehmen ist aber evtl. günstiger. SPLA ist keine Hexerei: kompetenten Partner suchen, Vertrag abschliessen und dann jeden Monat den Lizenzbedarf melden. Die Software ist nicht anders, es sind nur andere Keys.

Hatte mit einem Exchange 2010 SP1 und Clients mit Apple Mail mal ein ähnliches Problem. Damals ist allerdings nicht das Postfach grösser geworden, sondern die Datenbank für öffentliche Ordner. Die Ursache war ein Bug in Exchange in Kombination mit Apple Mail: auf dem öffentlichen Ordner war eine Quota gesetzt, die erreicht war. Apple Mail hat das irgendwie nicht erkannt und immer wieder versucht, ein Dokument in den öffentlichen Ordner zu laden. Der Exchange hat das dann wegen der überschrittenen Quota nicht akzeptiert, aber trotzdem in der Datenbank gespeichert. Die Lösung war die Installation von SP3, seither ist Ruhe. (Apple Mail zeigt immer noch nicht an "Quota erschöpft", sondern lädt das Dokument alle paar Minuten hoch, aber der Exchange reserviert keinen Speicher mehr dafür.)

Bei uns hatten zwei virtuelle Server mit Windows Server 2008 R2 automatische Updates aktiviert und nach dem Reboot war bei beiden eine neue Netzwerkkarte drin, die auf DHCP stand. (Die VMs laufen auf ESXi.) Zusätzlich hatte einer der beiden Server gestern Nachmittag einen Bluescreen, was auch eine der beschriebenen "Nebenwirkungen" des Updates ist. Würde also noch warten mit der Installation. Bin gerade etwas entsetzt, dass ein so gravierender Bug nicht schon Microsoft bei den Tests aufgefallen ist. Verwenden die nur Hyper-V im Labor?

Folgendes hat bei mir funktioniert: - Kontodaten eintragen, beim SMTP Server einen unerreichbaren Server eintragen oder einen mit aktivierter Authentifizierung. - "Weiter" klicken. - Der Test bleibt nun entweder hängen oder fragt nach einem Benutzernamen und Kennwort. => Im Hintergrund ist das Konto schon eingetragen, bei einem Fehler wird es allerdings wieder gelöscht. - Deshalb während dem Test die outlook.exe im Task-Manager abschiessen. So bleibt das Konto drin. Anschliessend kann es ohne weitere Tests bearbeitet werden.

Für eine einmalige Sicherung käme auch Disk2VHD in Frage. Das funktioniert ohne Neustart und macht ein Image des Servers. (Allerdings unkomprimiert, da es eigentlich ein P2V- und kein Backuptool ist.)

Wenn man nur einen Server betreibt, würde ich die Domäne weglassen. Also nur RDS installieren, kein DC. Mit der Lizenzierung ist es nicht so einfach. Wenn Du einen virtuellen Server mietest, muss die Lizenz zwingend vom Provider kommen (SPLA). Wie es bei der Miete eines physischen Servers aussieht, weiss ich leider nicht. SPLA geht auf jeden Fall, habe aber auch schon gelesen, dass man da eigene Lizenzen einsetzen darf. Die Lizenzen dürfen aber nicht gemischt werden, also nicht Windows von Dir gekauft und RDS-CALs per SPLA von Strato gemietet. Für den Zugriff gibt es mehrere Möglichkeiten. RDP selbst verschlüsselt die Daten schon, man braucht also nicht zwingend ein VPN. Wenn Du den Zugriff auf Port 3389 auf gewisse IP-Adressen beschränken kannst, wäre das am einfachsten. Geht das nicht, würde ich das RD-Gateway installieren, evtl. mit Zweifaktor-Authentifizierung. RDP direkt offen ins Internet will man normalerweise nicht. Mir sind zwar in letzter Zeit keine Lücken bekannt, durch die jemand ohne Passwort Code auf dem Server ausführen konnte, aber die ganze Welt kann Passwörter durchprobieren. Braucht es doch ein VPN, könnte man IPSec auf dem Server einrichten, das ist nicht so unsicher wie PPTP. Ist aber nach meiner Erfahrung etwas ein Gebastel (jedenfalls für Site2Site), so dass ich eher Hyper-V aktivieren und in einer VM eine Firewall-Distribution laufen lassen würde. Oder Du gehst zu einem Provider, der das VPN für Dich terminiert. Ganz allgemein würde ich mir überlegen, ob Du einen physischen Server brauchst. Da musst Du für Updates sorgen, im Fehlerfall die Sicherung zurückspielen etc. Viele Anbieter bieten mittlerweile vServer explizit als Terminalserver an. Dort bezahlst Du dann einen fixen Betrag pro Benutzer und hast den Server, die Lizenzen, Updates und Backup inklusive.

Ich würde auf der Firewall routen. Ist ja wohl nicht viel Traffic und so sparst Du Dir die Eintragung einer zusätzlichen Route auf den Geräten. (Oder allenfalls die Route auf der Firewall und dem Switch einrichten, wobei die Firewall den Clients per ICMP direkt den Switch als Gateway angeben kann.) Noch eine Anmerkung zur Grafik: ich würde wenn immer möglich vermeiden, die Rechner über die Telefone anzuschliessen. Manche Telefone bieten nur 100 Mbit/s und wenn das Telefon neu startet, verliert der Rechner kurzzeitig die Netzwerkverbindung.

Würde ebenfalls eine Migration auf Server 2016 bevorzugen, wenn man schon grössere Umstellungen macht. Die Profile sollten sich aber trotzdem den Benutzern in der neuen Domäne zuweisen lassen. Folgendes muss erfüllt sein: - Dateien: Benutzer hat Vollzugriff, Besitzer ist Benutzer oder "Administratoren" (nicht "Administrator"!) - Registry: Benutzer hat Vollzugriff auf alle Schlüssel (kann man mit Regedit anpassen: ntuser.dat laden und konfigurieren) Ich verwende jeweils den User Profile Wizard, der macht das automatisch.

Seit der "Next Gen"-Client erschienen ist, hatte ich keine Probleme mehr. Habe auch Kunden mit grösseren Ablagen, also über 50'000 Dateien. Jedoch arbeitet kein Kunde mit Mac. Nur etwas ist noch mühsam: wenn mehrere Benutzer an der gleichen Datei arbeiten, wird diese bei Konflikten ohne Rückmeldung als "Datei-$computername.xy" gespeichert. Die Benutzer merken das teilweise nicht und arbeiten am nächsten Tag an der alten Datei weiter...

Defekte Geräte äussern sich häufig durch Fehler in den Portstatistiken des Switches. In einem geswitchten Netz sollten die Zähler "TX Error" und "RX Error" auf 0 stehen. Allerdings sollte ein defektes Gerät nicht das ganze Netzwerk beeinträchtigen.

Vielen Dank für die Antworten! Es scheint also keine eierlegende Wollmilchsau zu geben, die mir bisher entgangen ist... Die Signaturen waren nur ein Beispiel, es gibt noch diverse andere Software, deren Einstellungen die Benutzer gerne an andere Rechner mitnehmen.

Ja, das ist möglich. Es kann sinnvoll sein, grosse oder wenig genutzte Datensätze auf günstigeren Speicher (SAS statt SSD) auszulagern: - vertikale Partitionierung: Wenn ein System zu jedem Produkt ein Bild in der Datenbank speichert, kann man diese Spalte in eine separate Datei auslagern (bzw. die Tabelle mit ID und Bild). - horizontale Partitionierung: Alle Datensätze mit Datum von mehr als einem Jahr in der Vergangenheit kommen in eine andere Datei. Muss aber sagen, dass ich einen solchen Fall in der Praxis noch nie hatte. Einerseits ist auch schneller Speicher nicht mehr so teuer oder man macht das Tiering direkt auf dem SAN.

Ja, genau den Agent meinte ich. Ich sichere jeweils ins Veeam Repository, da sich der Auftrag dann über die Veeam-Konsole überwachen lässt. Muss man von der Boot-CD aus den Host wiederherstellen, kann man über die Freigabe auf dem NAS direkt auf das Backup zugreifen (ist ein separates Verzeichnis im Repository).

Wo man Veeam installiert, ist teilweise eine Frage der "Philosophie": viele "Puristen" installieren grundsätzlich nichts auf dem Host. Ich sehe das nicht ganz so eng und unterscheide je nach Grösse der Infrastruktur: bei kleinen Installationen (ein oder zwei Hosts) installiere ich Veeam direkt auf einem Host. Aus dem einfachen Grund, dass man bei einem Totalausfall nach der Wiederherstellung des Hosts gleich mit dem Restore der VMs beginnen kann und nicht erst eine VM mit Veeam installieren muss, um Zugriff auf die Backups zu haben. In grösseren Umgebungen (mehrere Hosts, Cluster) bevorzuge ich einen dedizierten Backupserver. Früher habe ich NAS-Volumes per iSCSI angebunden. Heute nehme ich SMB, da es bei modernen NAS kaum mehr einen Unterschied gibt in der Performance und SMB einfacher in der Handhabung ist. Die Hosts sichere ich mittels dem kostenlosen Veeam Agent. Das kann direkt in ein Veeam-Repository sichern.

Wenn man Robocopy mit einem Tool für Schattenkopien kombiniert, kann man geöffnete Dateien sichern: https://rakhesh.com/windows/how-to-backup-open-pst-via-robocopy/ Wie konsistent derart gesicherte gemountete Veracrypt-Container sind, ist eine andere Frage...