Hope This Helps

Ich erhalte in letzter Zeit gehäuft die Meldung, dass Benutzer Dateien sperren, aber ein falscher Name bei der Sperre angezeigt wird.

Als Beispiel zur Erklärung:

Herr X öffnet eine Excel-Datei und erhält die Meldung, dass Herr Y die Datei bereits geöffnet hat. Herr Y hat diese Datei aber nicht geöffnet, sondern Herr Z. Trotzdem wird Herr Y als sperrender Benutzer angezeigt!

Warum der falsche Name?
Wenn man eine Office-Datei öffnet, dann wird im gleichen Verzeichnis eine temporäre Datei mit einer „~“ vorweg erstellt (z.B.: ~$Mappe1.xlsx). Darin wird festgehalten, welcher Benutzer die Datei geöffnet hat. Normalerweise sollte die „~“-Datei nach dem schließen automatisch gelöscht werden, was augenscheinlich aber nicht immer funktioniert und die Datei bleibt erhalten. Beim nächsten Öffnen kann keine NEUE „~“-Datei erzeugt werden und die Benutzerinformationen bleiben bestehen. Wenn jetzt ein anderen Benutzer die Datei öffnen will, werden die veralteten Informationen angezeigt.

LÖSUNG: Wenn man die „~“-Datei löscht, dann werden die Informationen beim nächsten Öffnen wieder richtig angezeigt.
Schaut man mal in die „~“-Datei mit einem Editor rein, dann sieht man, dass hierin der bearbeitende Benutzer vermerkt ist. Auffällig ist meiste das veraltete Erstellungsdatum. Generell könnte man auf seinem Fileserver nach solchen Dateien suchen und alle, die älter als zwei Tage sind löschen!

Bei Outlook erhält man beim Weiterleiten einer Mail den folgenden Hinweis angezeigt und alle externen Bilder werden nicht angezeigt:

Externer Inhalt ist in sicheren Mails nicht zulässig

Wenn man sich die Mail genauer anschaut, dann ist diese digital signiert (Bei uns war es eine DHL-Mail). Nach etwas Recherche hat sich herausgestellt, dass es kein Bug ist sondern eine Sicherheitsfunktion von Outlook 2010 - 2016. Diese Funktion wurde per Update im November 2018 eingeführt und aktiv genommen. Hintergrund ist die Ausnutzung der Efail-Schwachstelle.
Genaueres könnt Ihr hier nachlesen: Outlook: "Externer Inhalt ist in sicheren Mails nicht zulässig" - BornCity
Leider gibt es aktuell keine GPO-Vorlage um das abzuschalten. Ich habe diese jetzt in einer GPO per Registrykey behoben. Hierzu muss man folgenden Regkey setzen:

Path: HKEY_CURRENT_USER\SOFTWARE\Policies\Microsoft\Office\xx.0\Outlook\Security
Valuename: DisallowSMIMEExternalContent
Valuetyp: REG_DWord
Value: 0

Office-Versionsnummern xx: 14 = Office 2010, 15 = Office 2013 und 16 = Office 2016
Quelle: Outlook for Windows blocking external content by default

Obwohl ich die Proxy-Funktion der SOPHOS SG135 nicht verwende oder lizensiert habe, meldet sich plötzlich das System und ist der Meinung, das ein Zertifikat ablaufen würde. Folgende Mail habe ich hier erhalten:

1 certificate(s) will expire within the next 30 days:
Proxy CA

--
System Uptime : 0 days 12 hours 12 minutes
System Load : 0.35
System Version : Sophos UTM 9.500-9

Please refer to the manual for detailed instructions.

Wie kann das sein? Welches Zertifgikat ist das hier genau? Ist es doch das SSL-VPN-Zertifikat?
Man kann das genau identifizieren mit den nachfolgenden Schritten:

1.) Man schaut mittels WINSCP auf die Sophos unter /var/log/fallback.log und sucht den Timestamp, an dem die Nachricht generiert wurde. Das sieht dann in etwa so aus:

2017:05:10-09:17:01 SOPHOS_UTM [daemon:info] notify_expiring_certs.pl: INFO - certificate REF_CaMatCukLghXvygo2 will expire
2017:05:10-09:17:01 SOPHOS_UTM [daemon:info] notify_expiring_certs.pl: INFO - notified about 1 certificates, which will expire

Wichtig ist hier die angegebene REF_xxxxxxx, die man sich kopiert.

2.) Von der UTM-Shell aus gibt man dann den folgenden Befehl ein:

cc get_affected_objects REF_CaMatCukLghXvygo2

Wobei die REF_xxxxxx die vorher kopierte ist!

3.) Das nun angezeigte REF_Objekt nortiert man sich und geht in die Web-Konsole der UTM unter Support -> Advanced -> Resolve REF_ und gibt hier das REF_Objekt an und erhält den Namen des Zertifikats zurück.

Sollte es sich wirklich um das PROXY CA-Zertifikat handeln, dann kann man dieses ganz einfach in der Web-Konsole unter Network-Protection -> Filtering Options -> HTTPS CAs erneuert werden.

Wenn man diese Funktion aber NICHT lizensiert hat, dann kann es trotzdem sein, dass die UTM das Zertifikat anmahnt und das kann sehr nervig sein. Ich habe hier nur eine Lösung gefunden und die ist nicht schön, funktioniert aber!

1.) Man meldet sich auf der Web-Konsole an
2.) Man navigiert zu Web Protection -> Filtering Options -> HTTPS CAs

Jetzt kommt der Trick:
Man klickt nochmals auf den Reiter "HTTPS CAs" und nun ist der Button "Regenerate" für einige sekunden klickbar. Schnell klicken und das war es schon! Nicht schön, funktioniert aber!

Quelle: Sophos UTM: Certificate expiry notification

Problem:
Ich habe bei einem Client entweder neue Kontakte importiert oder aber Kontaktordner aus öffentlichen Ordnern eingehängt. Dabei markiert Outlook alle Kontakte "fett" als nicht gelesen. Es ist nun sehr mühsam alle Kontakte zu öffnen um die Makierung zu entfernen.

Lösung:
Gott sei Dank gibt es Schnell Tasten!! Folgende Abfolge markiertalle Kontakte als gelesen:

- Klicken Sie auf Konakte und in den betroffenen Ordner
- Hier wählen Sie mittels STRG+A alle Kontakte an
- Nun drücken Sie STRG+Q um alle Kontakt als gelesen zu makieren
- FERTIG!

Ich bin hier bei unserem Windows 10 Rollout auf einen interessanten Bug (Feature?) bei der Windows-Aktivierung gestoßen.
Einige Rechner melden, dass Windows NICHT aktiviert wäre und man bitte die Internetverbindung prüfen soll.

Nach Proxy rein/raus und Firewall auf/zu hat sich hier nichts getan.
Scheinbar ist hierfür die GPO „keine Verbindungen mit Windows Update-Internetadressen herstellen“ schuld, die eigentlich den DualScan unterdrücken soll.
Bevor ich jetzt aber die ganze GPO gleich anpasse, habe ich nur den Reg-Key am Rechner gedreht und siehe da, schon ließ sich Windows aktivieren.
Warum das aber nicht bei allen Windows 10 Maschinen passiert? Keine Ahnung!
Den Reg-Key hierfür findet Ihr wie folgt:

Pfad: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate
Name: DoNotConnectToWindowsUpdateInternetLocations
Wert: 1 = Kein Zugriff auf MS (GPO default) / 0 = Zugriff auf MS

Problem:
Einige meiner Server 2016 melden beim Suchen nach Updates die Fehler 0x8024500C oder 0x8024401c. Scheinbar aber nicht alle? Die Server beziehen Ihre Updates von meinem WSUS 3.0 auf einem Server 2008R2.

Lösung:
Um das Problem zu lösen benötigt man einen Microsoft-WSUS-Patch, der unter KB4039929 geführt wird. In den Release Notes des Patches findet sich auch genau die Problembeshreibung:

WSUS update metadata processing can cause clients to time out and return a 0x8024401c error.

Nachdem ich diesen auf meinem WSUS 3.0 installiert hatte, haben die Server 2016 schön brav wieder Ihre Updates abgeholt!
Die neue WSUS Serverversion lautet: 3.2.7600.283
Quelle:
Microsoft Support: An update to improve the performance of update metadata processing on Windows Server Update Services
Microsoft Technet: High CPU/High Memory in WSUS following Update Tuesdays