ugg.li Schnelle Hilfe für schnelle Admins
Nicht immer schön, aber effektiv. Schnelle Hilfe für schnelle Admins.
Ein Kunde (liebe Grüße!) hat mich soeben auf diese großartige Windows 10+ Tastenkombination hingewiesen:
STRG + WIN + Q
Die Kombination öffnet sofort die Windows Remotehilfe.
Damit können Benutzer einem Admin Zugriff auf den PC gewähren, Dateien kopieren und so weiter. Wie eine kostenlose Alternative zu TeamViewer, die sowiso ins System eingebaut ist 🙂
Man speichert „jahrelang“ Excel-Dateien auf dem Netzlaufwerk, hat dort jede Menge Links auf andere (Netzwerk-)Dateien gesetzt alles funktioniert wunderbar. Doch plötzlich gibt es beim Klick auf die Links nur noch Fehlermeldungen, nicht geht mehr.
Es erscheint statt der Dokumente ein „Sicherheitshinweis“ und vermeldet „Office hat ein potentielles Sicherheitsrisiko erkannt“. Außerdem sei „Dieser Speicherort ist möglicherweise nicht mehr sicher“.
Vorweg: Links in Excel-Dokumenten zu anderen Dokumenten sind (außer in Web- oder SharePoint Dateien) nicht absolut. Die Links bleiben also nicht bei dem was man manuell hinterlegt, sondern werden „verwaltet“. Excel versucht anhand eines Regelwerkes die Links „funktional“ zu halten und ändert beim Speichern gerne „mal eben“ alle Links des Dokumentes entsprechend ab.
Das „Regelwerk“ das Excel nun dazu nutzt ist zum Glück ganz gut dokumentiert:
https://support.microsoft.com/de-de/topic/beschreibung-der-linkverwaltung-und-speicherung-in-excel-46628e8d-2cd6-db5f-3474-f8d7144b09d6
Ein wahrscheinliches Szenario das wir schon öfter gesehen haben könnte also zum Beispiel so aussehen:
Das, also der „Link-Verlust“ (das Phänomen nennt sich neudeutsch auch „Link-Loss“) passiert immer wenn:
In diesen Varianten findet Excel keinen Referenzort der Datei mehr zum relativen Pfad des geöffneten Dokumentes und ändert aus „Sicherheits- und Komfortgründen“ alle Pfade. Allerdings erst beim speichern, solang das Dokument noch geöffnet ist, ist die „zukünftige“ Änderung nicht sichtbar.
Es gibt keine „richtige“ Lösung. Links in Excel-Tabellen sind supergefährlich. In dem Moment in den Man Daten (wie z.B. Links) in einer Tabellenkalukation verwendet, ist etwas schief gelaufen, Daten verwaltet man in Datenbanken (z.B. Access).
Aber: man kann das Problem etwas einzuschränken. Das geht natürlich auch per GPO.
Excel (und alle anderen Office-Apps) speichern alle 10 Minuten die aktuellen Dateien. Das ist auch sehr gut so, denn wenn eine Office-App mal abstürzt oder der Datei-Handle verloren geht (Standy, Docking-Station, WLAN-Wechsel, Windows-Updates, USB-Stick Backup, Netzwerktrennung …) wird man ja von der „letzte bekannte Version“ begrüßt. Selbige kommt genau daher.
Nach der Durchführung eines In-Place-Upgrades von Windows Server 2016 oder 2019 auf 2022 oder Server 2025 hat der gute alte IIS SMTP Dienst scheinbar ein ernstes Problem: Er stürzt mit einem Fehler ab wenn an eine E-Mail über diesen versenden will. In manchen Fällen erfolgt der Crash auch schon beim einfachen start des SMTPSVC.
Im Ereignisprotokoll (Anwendungsprotokoll) gibt es auch sofort den dazu passenden Fehler:
Name der fehlerhaften Anwendung: inetinfo.exe, Version: 10.0.20348.1, Zeitstempel: 0x20d57e42
Name des fehlerhaften Moduls: SMTPSVC.dll, Version: 10.0.20348.1, Zeitstempel: 0xba4e29ad
Ausnahmecode: 0xc0000005
Fehleroffset: 0x0000000000059abb
ID des fehlerhaften Prozesses: 0x850
Pfad der fehlerhaften Anwendung: C:\WINDOWS\system32\inetsrv\inetinfo.exe
Pfad des fehlerhaften Moduls: C:\WINDOWS\system32\inetsrv\SMTPSVC.dll
[...]
Wir wissen zwar das der IIS6 „deprecated“ ist, haben aber keine Erklärung für Microsofts offensiver „Your Problem“ Haltung zu dieser oftmals vitalen Windows-Komponente.
Es gibt schliesslich einen Haufen guter Gründe, weiterhin ein internes SMTP-Relay zu betreiben. ERP-Software muss in aller Regel Mails versenden, Scanner-Systeme, Alarmmelder und Maschineninformationen wollen Kontakt halten. Kaum eines dieser Systeme beerrscht die sichere Authentifizierung, noch weniger eines möchte man sowas für den Versand ins Internet lassen.
Der Trick ist einfach: man muss einfach vor dem Upgrade ein Backup der IIS-Site machen und nach dem Upgrade widerherstellen. Dann läuft alles wie gewohnt und weiterhin geschmiert. Der Grund ist unsinniges Update-Gefummel in der IIS-Metabase, die sich aber erledigt hat wenn man seine alte (fehlerfreie) Version einfach weiterverwendet.
Die CMD-Shell „Als Administrator“ öffnen
%windir%\system32\inetsrv\appcmd.exe ADD BACKUP %computername%Die Backup-Dateien landen sofort in diesem Pfad:
%windir%\system32\inetsrv\backup\%computername%
Die Backup-Dateien gehen wärend des Upgrades zwar nicht verloren (aber paranoide Admins wie wir kopieren den Inhalt des Verzeichnisses natürlich an einen sicheren Ort).
Auch nach dem Update wird die CMD-Shell „Als Administrator“ benötigt:
%windir%\system32\inetsrv\appcmd.exe RESTORE BACKUP %computername%Außerdem stellt das Setup den IIS SMTP Dienst auf den manuellen Start um, was nach Server-Neustarts zu Kopfkratzen führen könnte. Der Dienst sollte also möglichst wieder automatisch starten:
sc config smtpsvc start=auto
sc start smtpsvcUnd schon funktioniert der SMTP-Server auch unter Windows Server 2022 wieder.
Ein Ressourcenpostfach (z.B. Shared Mailbox) ist in Exchange Online mit „AutoAccept“ (automatische Zusagen, AutomateProcessing) konfiguriert, damit der Kalender Besprechungsanfragen bestätigt.
Die Besprechungsanfragen werden auch korrekt automatisch angenommen. Der Besprechungsbetreff wird im Postfach des Organisators auch angezeigt.
Aber alle anderen Benutzer (mit Berechtigungen auf dem Postfach) sehen statt des Besprechungsbetreffs nur den Namen des Organisators.
Dies ist das Standardverhalten von Exchange Online (und Exchange seit 2010) und seither irritierend. Das passiert immer dann, wenn AddOrganizerToSubject und/oder DeleteSubject auf True festgelegt sind.
Aktuelle Einstellung anzeigen:
Get-CalendarProcessing -Identity <RESSOURCE> | fl *subject*Einstellungen ändern:
Set-CalendarProcessing -Identity <RESSOURCE> -DeleteSubject $false -AddOrganizerToSubject $falseDeleteSubject: Soll der Betreff entfernt werden? (true=ja)
AddOrganizerToSubject: Soll der Name des Organisierenden den Betreff ersetzen? (true=ja)
Manchmal muss man wissen, wie viele Nachrichten an einen bestimmten Empfänger gesendet wurden. Zum Beispiel „Wie viele Nachrichten wurden in den letzten 24 Stunden an dieses Postfach gesendet?“.
Das ist leider nicht ganz so einfach, weil Get-MessageTrace nur 1000 Zeilen ausgibt. Man kann das Commandlet zwar mit -PageSize 5000 etwas tunen, aber wenn es um mehr Nachrichten geht, muss man die abzufragende Zeit eingrenzen und addieren.
Wenn man erst mit Import-Module ExchangeOnlineManagement das Exchange Online PowerShell-Modul importiert hat und sich via Connect-ExchangeOnline auch verbunden hat, kann man Nachrichen auflisten und zählen:
Get-MessageTrace -PageSize 5000 -RecipientAddress [email protected] -Start ((get-date -hour 0 -Minute 0 -Second 0).adddays(-1)) -End (get-date -Hour 0 -Minute 0 -Second 0) | Measure-Object