mwiederkehr

Herzlichen Dank für eure Tipps! Ist tatsächlich so ein "da steht noch eine Kiste in der Ecke"-Server eines Neukunden. Werde die Exchange-Dienste deaktivieren, die aktuellen Windows Updates sowie .Net 4.72 installieren, nach dem Neustart abwarten, bis der "mscorsvw.exe" fertig ist, die Dienste wieder aktiveren (aber nicht starten) und dann das CU installieren. Nächsten Montag wissen wir mehr.

Hallo zusammen Ein Exchange 2013 (Standalone, keine DAG) mit CU15 soll auf CU23 aktualisiert werden. Laut Supportmatrix müsste man in folgender Reihenfolge installieren: .NET 4.6.2, CU20, .NET 4.7.1, CU22, .NET 4.7.2, CU23, dann optional noch .NET 4.8 Sehr umständlich und ich müsste das nicht mehr öffentlich verfügbare CU20 beschaffen. Bei Microsoft steht folgender Abschnitt auf der Seite mit der Supportmatrix: "Beim Upgrade von Exchange von einem nicht unterstützten Cu auf das aktuelle Cu und kein Intermediate CUS sind verfügbar, sollten Sie zuerst ein Upgrade auf die neueste Version von .net durchführen, die von Exchange unterstützt wird, und dann sofort auf das aktuelle Cu-Upgrade aktualisieren." Auch Frank Carius bestätigt dieses Vorgehen. Es scheint mir logisch, dass es so funktionieren müsste, denn nicht laufende Exchange-Dienste können sich ja nicht an einer falschen Version des .NET-Frameworks stören. Aber zur Sicherheit kurz nachgefragt: Hat das jemand in der Praxis schon mal so gemacht? Vielen Dank für eure Tipps!

Mich hat mal fast der Schlag getroffen, als ich zwecks Servereinbau ins Datacenter gefahren bin, in welchem wir ein paar Racks gemietet hatten. War eigentlich professionell, Diesel, Biometrie etc., aber leider in einem Bürogebäude untergebracht. Auf dem gleichen Stockwerk gab es Bauarbeiten, für die man Wasser gebraucht hat. Irgend jemand vom Betreiber fand es eine gute Idee, den Bauarbeitern die Türen vom Serverraum auf zu machen, so dass sie ihren Wasserschlauch zwischen den Racks hindurch ziehen konnten... Besonders lustig fand ich es bei dem Kunden, bei dem die Server auf einem über die Badewanne montierten Brett standen. Die Toilette daneben war noch in Betrieb, deshalb musste ich immer kurz raus, wenn jemand mal musste. Haartrockner an der gleichen Steckerleiste mit 10A-Absicherung kam auch nicht so gut...

Muss es die Cloud sein? Du könntest sonst ein NAS bei einem Provider mieten. Gibt es mittlerweile sogar virtuell. Dieses könntest Du dann über die Methoden von Synology synchronisieren.

Können das nicht alle? Man muss doch nur auf dem iSCSI-Target "allow multiple sessions" aktivieren? Soweit ich weiss geht es nur mit iSCSI, weil der verwendete SMB-Dienst (Samba) nicht alle benötigten SMB3-Features unterstützt.

Danke für die Rückmeldung! War spannend wie ein Krimi, nur das Ende enttäuscht. Bin aber recht erstaunt. Hatte zwar erst einen solch hartnäckigen Fall und der war mit Exchange, aber dort hat der Support nicht locker gelassen, bis die Fehlerursache bekannt und ein Patch entwickelt war.

Die Dokus sind in diesem Punkt wirklich widersprüchlich. Habe letzten Monat einem Bekannten einen Essentials als Homeserver installiert. Da er keine Domäne wollte, habe ich kein AD installiert. Der Server fährt nicht regelmässig herunter und es gibt auch keine speziellen Meldungen im Event Log. Ich gehe deshalb davon aus, dass die Lizenzprüfung nur stattfindet, wenn die AD-Rolle installiert ist. Evtl. könnte der Server sogar Member einer Domäne sein. Die Verwirrung kommt evtl. von früheren Versionen: bis und mit 2016 kam der Server mit der Essentials-Rolle, die automatisch installiert wurde und eine Domäne benötigt hat. Seit 2019 gibt es diese Rolle nicht mehr.

Bin etwas spät dran, möchte mich aber für eure Unterstützung bedanken und eine Rückmeldung geben. Wenn der WDS nicht antwortet, funktioniert es. Mittlerweile habe ich vom Herstellersupport das Verhalten bestätigt bekommen. Die Geräte lesen nur den ersten DHCPOFFER. Meine Frage, ob das standardkonform sei (in Anbetracht der Tatsache, dass alle anderen Geräte auch den zweiten DHCPOFFER lesen), wurde nicht beantwortet. Anscheinend haben sie nicht viele Kunden mit diesem Problem. Für uns ist es gelöst, indem die UniFi-Geräte eine fixe IP-Adresse zugewiesen bekommen haben.

Seit ich mit Windows 10 arbeite, verwende ich den mitgelieferten PDF-Drucker. Hatte noch keine Probleme damit, aber habe auch keine speziellen Anforderungen. Um CAD-Dateien nach PDF zu exportieren, hatten wir früher den Acrobat, weil die Gratistools überfordert waren. Seit einigen Jahren unterstützt AutoCAD aber den direkten Export nach PDF, was auch tadellos funktioniert.

Im Event Log steht ein entsprechendes Ereignis. Es soll jedoch auch über eine API gehen: https://community.spiceworks.com/topic/2147508-powershell-get-client-ip-in-rds

Mir sind beim Controller-Neustart einer MSA2040 nach einem Firmware-Update die LUNs weggebrochen von den zwei per SAS angeschlossenen ProLiant DL360 Gen8 mit ESXi 5.x. Der Support meinte dann, Multipath über SAS funktioniere nicht bei ESXi. Habe aber nicht genauer nachgeforscht, da das die einzige solche Konfiguration war.

Es gab mal Angriffe, bei denen der Schlüssel durch Mitlesen der Kommunikation auf dem LPC-Bus ausgelesen werden konnte. Trivial ist das aber nicht. Wer ganz auf Nummer sicher gehen will, verwendet zusätzlich zum TPM eine PIN.

Du könntest nicht die EXE der Anwendung freigeben, sondern ein Script, welches die Client-IP prüft und die Anwendung nur startet, wenn die Client-IP aus einem internen Netzwerk kommt. Das wäre einigermassen "sauber". Du könntest auch das Web Interface anpassen und gewisse Icons nicht anzeigen lassen je nach Client-IP. Da muss man dann einfach aufpassen bei Updates. Oder, wenn es nicht sehr sicher sein muss: das Web Interface um ein JavaScript ergänzen, welches die Client-IP prüft und bei externen Benutzern das Icon für die Anwendung ausblendet. Das kann dann aber jeder umgehen, der sich ein bisschen mit JavaScript auskennt.

Wäre lustig, wenn es nicht traurig wäre: ein Kunde hatte im Datacenter den Storage auf No-Name-Eigenbau-Servern. Habe ihn vor zwei Jahren überzeugt, auf HPE MSA umzustellen. Wegen Zuverlässigkeit und Stabilität. Klar, schon einiges teurer, aber dafür ist nie was. Richtig gut ging es mir, als ich ihm erklären musste, dass Updates der Disk-Firmware beim MSA ein Offline-Vorgang sind. m(

Ohne Shared Computer Activation: die Lizenz wird vom Benutzer abgezogen, der Office 365 installiert (oder das erste mal startet). Danach ist es aktiviert und kann von allen Benutzern des Rechners verwendet werden. Von solchen mit eigenem Office-365-Konto und solchen ohne Ofice-365-Konto. Die Lizenz wird erst deaktiviert, wenn man das Gerät aus dem Portal entfernt. Pro Benutzer können fünf Rechner aktiv sein. Mit Shared Computer Activation: Jeder Benutzer muss sich am Office 365 anmelden. Benutzer ohne Office-365-Konto können es nicht nutzen. Dafür zählt es nicht zum Limit mit den fünf Rechnern dazu. (Ist ja logisch, es wird ja eben gerade nicht für den ganzen Rechner aktiviert, sondern nur für die Benutzersitzung.) Ich habe SCA bis jetzt nur auf Terminalservern im Einsatz gesehen. Aber hier könnte es auch sinnvoll sein. So musst Du nicht überlegen, auf welchem Rechner Du welches Konto für die Aktivierung genommen hast und es können auch keine Lizenzverstösse durch nicht lizenzierte Benutzer vorkommen.

Nein, meiner Erfahrung nach nicht. Wenn Office 365 auf einem Rechner installiert ist, kann (nicht darf) es auch von Benutzern (zB. dem Admin) verwendet werden, die selbst kein Office-365-Konto haben. Das "Lizenz-Konto" ist unabhängig vom "Gebrauchs-Konto" für E-Mail, OneDrive etc.

Wenn wirklich die gleiche Person (nicht ein generischer Benutzer) an 15 Rechnern arbeitet, sollte es gut mit mehreren Lizenzen lösbar sein. 3x E3 oder 1x E3 und 2x Business. Der Benutzer, den man für die Installation von Office verwendet, muss nicht mit dem Benutzer identisch sein, der Outlook etc. dann verwendet. Man kann die Lizenz gut auf "user_erweiterung1@domain.de" aktivieren und im Outlook dann "user@domain.de" als Konto einrichten.

Evtl. ist https://guacamole.apache.org/ was für Dich. Damit musst Du RDP nicht nach aussen öffnen und könntest per VNC auf Linux zugreifen. Unterstützt auch Zwei-Faktor-Authentifizierung.

Habe mal kurz nachgeschaut auf zwei Exchange 2016: bei beiden kommt nur AUTH PLAIN. Ich vermute der Exchange 2016 kann kein NTLM über POP3. Kann Deine Anwendung kein Plaintext-Login?

Der Task wird nicht mehrmals gestartet, sondern er bleibt aktiv. So werden Änderungen laufend synchronisiert. Erst wenn der MX umgestellt ist und einige Zeit vergangen ist, löscht man den Task. Wie es mit PTA aussieht weiss ich nicht. Beim Abgleich des Kennwort-Hashes (PHS) sollten vorhandene Benutzer erkannt und ihr Passwort aktualisiert werden.

Haben auch viel von Unifi im Einsatz. An Orten mit alten APs auch Switche wegen dem Passiv-PoE. Der Controller läuft auf einer gehosteten VM für mehrere Kunden. Habe mich kürzlich vom Verkäufer überreden lassen und drei Aruba Instant On APs bestellt. Bin recht begeistert. Die Umgebung lässt sich tatsächlich in fünf Minuten einrichten und es sind praktische Zusatzfunktionen wie NAT und DHCP vorhanden. Auch soll das Client Steering besser sein (identisch mit den teureren Modellen von Aruba). Mal schauen, ob das die Zukunft ist. Wäre nicht schlecht, alles von Aruba zu haben.

Früher haben wir bei preis-sensitiven Kunden Switches von Netgear eingesetzt. Da ging hin und wieder mal ein Netzteil kaputt, häufiger aber hängten sie sich komplett auf. Wobei "häufig" hier "alle paar Monate einmal" heisst, schon nicht "jede Woche". Seit mindestens zehn Jahren setzen wir auf HPE / Aruba und seither gab es fast keine Probleme mehr. Einmal ist bei einem neuen Switch nach ein paar Tagen ein Port ausgestiegen und einmal hat einer nach ca. sieben Jahren den Geist aufgegeben. HPE hat sich an die lebenslange Garantie gehalten und ein Ersatzgerät geschickt. Sie hatten tatsächlich noch das gleiche Modell an Lager. Ich mag an den Geräten von HPE, dass sie sich sowohl per Web-Interface als auch per Kommandozeile konfigurieren lassen. Aber das werden Geräte anderer Hersteller mittlerweile wohl auch bieten.

In einem ersten Schritt würde ich mal prüfen, ob die vorhandenen Ressourcen ausgelastet sind. Wenn die Software fast keine Diskzugriffe macht, bringen auch die schnellsten SSDs nichts. Und auch wichtig: läuft die Berechnung auf einem oder auf mehreren Cores? Falls sie auf einem Core läuft, wird eine neue CPU mit möglichst hohem Takt sehr wahrscheinlich eine Verbesserung bringen. Ansonsten eine neue CPU mit vielen Cores. Kannst Du die Berechnung testweise auf einem aktuellen Arbeitsplatzrechner laufen lassen? Das gäbe mal einen Anhaltspunkt. Hatte kürzlich so einen Fall und war erstaunt, dass das mooresche Gesetz immer noch zu gelten scheint: eine nicht parallelisierbare Datenbankabfrage dauerte auf einem Xeon von 2015 eine Minute und 40 Sekunden, auf einem Arbeitsplatzrechner mit i7 8700 nur noch 20 Sekunden.

Von aussen muss das Archivierungssystem ja nur auf Port 25 erreichbar sein. Und von innen greifen die Clients darauf zu, es muss selbst wahrscheinlich keine Verbindungen aufmachen können. Das heisst, es wäre in der DMZ gut aufgehoben. Oder Du stellst einen einfachen SMTP-Proxy in die DMZ. hMail, Postfix oder nginx (der kann aber keine E-Mails zwischenspeichern, falls das Archiv mal nicht verfügbar ist).

Exchange Online kann Journaling, die Einschränkung ist nur, dass die Journal-Adresse extern sein muss. Einzurichten ist das im EAC unter der Compliance-Verwaltung, Menüpunkt "Journalregeln". Du kannst also (lokal oder in der Cloud) einen hMail oder Postfix hinstellen, welcher eine Kopie aller E-Mails erhält und dem Archivierungssystem per POP3 zur Verfügung stellt.