Wenn man bei Windows Servern nachträglich die Zeitzone ändern möchte, kommt man auf dem offensichtlichen Weg nicht weiter.
Wenn man als Administrator in der Systemsteuerung / Control Panel über Change Timezone die Zeitzone ändern möchte kommt eine Fehlermeldung “Unable to Continue”.
Die Lösung des Problems ist relativ einfach.
Man öffnet als Administrator eine Powershell und ruft das Systemsteuerungselement Datum und Zeit / Date and Time direkt über die Admin-Powershell auf. Dazu gibt man auf der Shell “timedate.cpl” ein.
Jetzt lässt sich die Zeitzone problemlos über “Change Timezone” ändern.
Nachdem ein HP LaserJet Netzwerkdrucker anhand seiner IP-Adresse in Windows erfolgreich installiert wurde, erscheint er als “offline”. Ein Drucken ist nicht möglich.
Grund für dieses Problem war, dass Windows den Druckerzustand anhand von SNMP versucht zu ermitteln. Hier war bei den Drucker Anschlusseinstellungen beim SNMP-Communityname “SET” eingetragen. Diese Communityname war aber nicht mit dem SNMP-Communityname des Druckers identisch. Deshalb konnte Windows den Druckerstatus nicht per SNMP ermitteln und zeigte den Drucker “offline” an.
Als der SNMP-Communityname auf den Standardwert “public” geändert wurde, konnte Windows den Druckerstatus ermitteln und schaltete den Drucker sofort auf “online”.
Es wäre auch möglich gewesen, die SNMP Statusabfrage komplett zu deaktivieren indem die entsprechende Checkbox deaktiviert wird.
Migration einer VM zwischen 2 Hyper-V Clustern ohne dass die VM offline genommen wird. Dabei wird nur der lokale Hyper-V Manager verwendet. Eine System Center Virtual Machine Manager Umgebung ist dafür nicht notwendig.
Wichtig!
Eine Migration einer VM ist nur möglich wenn die VM Version kleiner oder gleich der Version des Ziel-Hyper-V Clusters ist. Wenn die VM einer größere Version als das Zielhyper-V Cluster hat bricht die Migration mit dem Fehler Migration Operation Failed und dem Error Code 32784 ab.
Dies ist dann der Fall, wenn eine VM z.B. mit Hyper-V 2019 (VM Configuration-Version 9) erstellt wurde und auf einen Hyper-V 2016 (VM Configuration-Version 8) migriert werden soll.
Ein Downgrade einer VM Version ist nicht möglich. Eine Notlösung wäre die Erstellung einer neuen VM mit der niedrigeren Version und einhängen der virtuellen Festplatte der VM.
Migrationsablauf
1. Entfernen der VM aus dem Cluster. Im Failoverclustermanager, beim Kontextmenü der VM auf Remove klicken. Die VM wird aus dem Cluster entfernt, läuft aber noch auf dem lokalen Hyper-V Knoten ohne Unterbrechung weiter.
2. Im lokalen Hyper-V Manager im Kontextmenü der VM auf Move klicken.
3. Als Move Type Move the virtual machine auswählen.
4. Als Ziel ein Knoten des Ziel-Hyper-V Clusters auswählen
5. Bei den Move Options Move the virtual machine’s date to a single location auswählen.
6. Beim nächsten Wizard-Schritt muss der Zielordner im Clusterstorage des Ziel – Hyper-V Knotens angegeben werden. Wichtig, hier ist ein dedizierter Ordner für die VM anzugeben, sonst wird die VM direkt im übergeordneten Ordner abgelegt.
7. Falls sich die Namen der logischen Switche bei den Quell und Ziel-Hyper-V unterscheiden, kann es notwendig sein einen virtuellen Switch manuell zuzuordnen.
8. Danach wird die VM im laufenden Betrieb auf den ziel Hyper-V Host migriert.
9. Auf dem Ziel Hyper-V Cluster ist es jetzt noch notwendig die VM in das Cluster aufzunehmen. Dazu ist im Failovercluster Manager unter Roles auf Configure Roles zu klicken. Nicht auf New Virtual Machine.
10. Bei Select Role ist Virtual Machine auszuwählen.
11. Dann kann man aus einer Liste der VMs die sich noch nicht im Cluster die migrierte VM auswählen um diese ins Hyper-V Cluster aufzunehmen.
12. Danach ist die Migration abgeschlossen. Die VM wurde ohne Downtime ins Ziel-Hyper-V Cluster migriert. Eventuell ist die Netzwerkkonnektivität zu überprüfen und anzupassen.
Nach dem Update der TYPO3 Extension news tritt beim Aufrufen des NEWS Backend-Moduls der Fehler:
“The requested resource /web/NewsTxNewsM2/ was not found.”
Erst eine Webrecherche brachte die Lösung für das Problem. Auf der Github Seite der News Extension findet man im Forum den entscheidenden Hinweis:
“For me, fixed the problem by resaving news configuration in Settings > Configure extension.”
Darauf muss man erst mal kommen. Man muss die Einstellungen der News Extension neu abspeichern. Änderungen an den Einstellungen sind dazu nicht notwendig.
Speichern der NEWS Einstellungen
Danach lässt sich das Backend der News Extension wieder ohne Fehler öffnen.
Auf einem Staging Server für das Update von TYPO3 9 auf TYPO3 10 trat bei dem Ausführen von TYPO3 Cli Befehlen der Fehler “The APCu backend cannot be used because apcu is disabled on CLI.” auf.
Um APCu auf der PHP Cli zu aktivieren muss man auf Debian Systemen die Datei /etc/php/7.1/cli/conf.d/20-apcu.ini bearbeiten und die Zeile apc.enable_cli=on hinzufügen.
Danach konnten die TYPO3 Cli Kommandos erfolgreich ausgeführt werden.
Der MariaDB Root User unter einer Debian Installation wurde gelöscht. Daraufhin war kein Root-Zugriff mehr auf die MariaDB Instanz mehr möglich.
Nach einigen Anleitungen die nicht funktioniert hatten, weil sie sich hauptsächlich auf ältere MySQL Versionen bezogen, wurde ich bei dem folgenden Artikel fündig:
Nach dem July Patchday 2021 gab es bei SharePoint das Problem, dass Listen in der Listenasicht nicht mehr dargestellt wurden. Es wurde nur eine leere weiße Seite angezeigt. In der Quellcodeansicht sah man aber, dass der Server doch Content ausliefert, der aber nicht gerendert wird.
Nach einigem Suchen und Testen konnte die “Modern View / Moderne Erfahrung von SharePoint 2019 als Fehlerursache ausgemacht werden. Wenn man bei einer Liste die “Moderne Erfahrung” deaktiviert, wird die Seite wieder richtig gerendert.
Die “Moderne Ansicht/ Moderne Erfahrung / modern experiences / modern View” lässt sich per Powershell auch auf Websitesammlungsebene deaktivieren.
Add-PSSnapin microsoft.sharepoint.powershell -ea 0
$site = Get-SPSite http://siteurl
#Disable modern Lists and libraries for Site Collection
$featureguid = new-object System.Guid "E3540C7D-6BEA-403C-A224-1A12EAFEE4C4"
$site.Features.Add($featureguid, $true)
Nach einem Versions-Update einer SharePoint Umgebung treten beim Erstellen einer SharePoint Webseite mit einem Websitetemplate ein Fehler auf: “Problem beim Anwenden der Webvorlage: Für diese Webvorlage müssen bestimmte Features installiert und aktiviert sein.”
Bei einem Versionsupdate von TYPO3 8 auf TYPO3 9 kann es vorkommen, dass nach dem Update im Backend die Adminwerkzeuge fehlen, obwohl der Benutzer “Adminstatus” besitzt. Unter anderem fehlt der wichtige Menüpunkt / das Icon “Erweiterungen”.
Fehlende Menüpunkte / Icons unter der Kategorie “Adminwerkzeuge”.
Aus welchem Grund auch immer, fehlte dem aus TYPO3 8 nach TYPO3 9 migrierten Admin-User die “System Maintainers”-Berechtigungen. Mit den “System Maintainers”- Rechten wird das Installtool von den bisherigen TYPO3 überflüssig. Die Installtool-Funktionalitäten wandern bei Admin-Usern mit “System Maintainers”-Rechten in das normale TYPO3 Backend.
Um dem Admin-User die “System Maintainers”-Berechtigungen zu geben, muss man noch einmal das Install-Tool bemühen. Unter dem Menüpunkt Settings –> Manage System Maintainers kann man die TYPO3 User auswählen die “System Maintainer” sein sollen.
“System Maintainers”- Verwaltung im TYPO3 Installtool
Nach dem Update von Debian Stretch auf Debian Buster, bei dem auch der IMAP Server Dovecot auf die Version 2.3.4.1 aktualisiert wurde, funktioniert die Authentifizierung nicht mehr. Bei Login-Versuchen sieht man in der Logdatei /var/log/dovecot.log folgende Fehlermeldung:
imap-login: Error: Failed to initialize SSL server context: Can’t load DH parameters: error:1408518A:SSL routines:ssl3_ctx_ctrl:dh key too small
Bei einer Webrecherche ergaben sich schnell einige Fundstellen zu dem Problem:
