mwiederkehr

Beide Varianten haben Vor- und Nachteile: Wenn Du die PST-Dateien bei Microsoft hochlädst, musst Du eine Mapping-Datei erstellen. Bei nur ganz wenigen Benutzern ist man über Outlook schneller. Der Import erfolgt sehr schnell, aber er startet nicht sofort, sondern erst, wenn Microsoft Kapazität dafür hat. Ich habe auch schon über zwölf Stunden gewartet, bis es los ging. Im Outlook kannst Du dank Cache-Modus das PST sehr schnell importieren, aber der Upload im Hintergrund kann dann länger dauern. Das Problem dabei: wenn Outlook am hochladen ist, zeigt es keine neu eintreffenden E-Mails an. Wenn der Upload lange dauert, kann das für die Benutzer mühsam sein. Ich mache es deshalb je nach Kunde unterschiedlich. Sind es nur maximal fünf Benutzer und die Postfächer sind nicht allzu gross, importiere ich direkt im Outlook und lasse die Rechner über Nacht laufen. Sind es mehr Benutzer, lasse ich den Import über Microsoft laufen.

Sobald sich der Kunde als Admin angemeldet hat, kann er tun, was er möchte. Das Logging muss vorher passieren. Vorschlag: Beim Login des Benutzers läuft ein Script ab, welches folgendes erledigt: 1. Aufruf einer Website (eures Monitorings) in der Form "logger.aspx?kunde=meier". Diese Daten könnt ihr speichern und euch alarmieren lassen. So müssen keine E-Mail-Zugangsdaten hinterlergt werden. 2. Für den Fall, dass der Kunde den Internetzugang blockiert hat: Erstellung einer Logdatei an einem schwer auffindbaren Ort. Für die Paranoiden: mit Zeitstempel in der Vergangenheit. Alternativ ginge auch ein Key in der Registry. 3. Ganz wichtig: das Script löscht sich nach der Ausführung selbst.

Software, die aktiviert werden muss, eignet sich meist nicht, um geklont zu werden. Das Problem wird evtl. nicht sysprep sein, sondern die sich ändernde Hardware. Die Lösung muss man mit dem jeweiligen Hersteller suchen. Bei Microsoft heisst sie KMS, andere Software kann man auf Netzwerklizenzierung umstellen...

Du könntest sogar den SQL Server auf dem Linux des NAS installieren. Seit Version 2017 gibt es ja eine Linux-Version davon.

Hat wie von euch beschrieben problemlos funktioniert. Besten Dank!

Wie Nils schon geschrieben hat, lässt sich das nicht zuverlässig mit den vom Dateisystem bereitgestellten Informationen lösen. Es sollte sich aber einigermassen leicht umsetzen lassen mit einer kleinen Datenbank. Falls Du ein Script willst, könntest Du PowerShell nehmen und die Daten in einer SQLite-Datenbank ablegen: In einem ersten Schritt geht das Script alle Dateien durch und trägt die, die noch nicht in der Datenbank vorhanden sind, ein mit Dateiname und aktuellem Datum. Dann sucht es in der Datenbank alle Dateien, die schon länger als X Tage da sind und löscht diese sowohl auf dem Dateisystem als auch in der Datenbank.

Du musst das AD-Attribut "msExchangeMailboxGuid" der synchronisierten Benutzer ausschliessen, damit bei Office 365 ein Postfach erstellt wird. Siehe https://mikeparker365.co.uk/2016/01/07/how-to-filter-out-msexchmailboxguid-from-aad-connect-sync/.

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.