Wenn man Benutzern aus einer AD-Gruppe z.B. Mailboxen erstellen will, geh das super einfach:
Get-ADGroupMember -identity "AD-Gruppe" -Recursive | foreach { get-mailbox -identity $_.samaccountname}
Fertig 🙂
Geht natürlich auch mit z.B. Berechtigungen:
Get-ADGroupMember -identity "AD-Gruppe" -Recursive | foreach { Add-MailboxPermission info -User $_.samaccountname -AccessRights FullAccess -InheritanceType all }
🙂
Wenn man bei einem Exchange mal schnell einen Empfangsconnector übernehmen will, kann man mit dem Befehl
Get-ReceiveConnector "Connector" | Set-ReceiveConnector -RemoteIPRanges (Get-ReceiveConnector "AlterServer\Connector").RemoteIPRangessuper einfach die RemoteIPRanges übernehmen 🙂
Wenn ich eine Maus am Notebook benutze möchte ich das mein Touchpad deaktiviert wird – unter GNOME gibts da aber standardmäßig keine Möglichkeit das in den Einstellungen entsprechend zu konfigurieren.
Allerdings kann man das per gsettings in der Shell setzen:
gsettings set org.gnome.desktop.peripherals.touchpad send-events disabled-on-external-mouseJetzt wird brav das Touchpad deaktiviert wenn eine Maus aktiv ist – und auch brav wieder aktiviert wenn man die Maus absteckt bzw. ausschaltet -> egal ob USB oder Bluetooth 🙂
Um zu checken ob der Wert gesetzt ist:
gsettings get org.gnome.desktop.peripherals.touchpad send-eventsWill man wieder das Standardverhalten wieder herstellen:
gsettings set org.gnome.desktop.peripherals.touchpad send-events enabledQuelle: https://itsfoss.com/disable-touchpad-when-mouse-used/
Wenn man auf einem Windows Server 2016 oder 2019 auf eine WebDAV-Freigabe zugreifen will, muss man ein Feature nachinstallieren das in der Standardinstallation nicht aktiviert ist.
Dazu am besten eine Powershell als Admin starten und folgendes eingeben:
Install-WindowsFeature WebDAV-Redirector –Restart
Jetzt wird das Feature installiert und der Server neu gestartet.
Nach dem Neustart ist ein Zugriff auf die WebDAV-Freigabe (z.B. Nextcloud) möglich
Mit systemd kann man Dienste bei Fehlern automatisch restarten lassen.
Zuerst checkt man welche Konfig-Datei den Dienst steuert – die Datei steht unter loaded:
systemctl status yourdaemon
Hier in dem Beispiel also /lib/systemd/system/nginx.service.
Diese öffnen wir
vim /lib/systemd/system/nginx.serviceUnd fügen unter [service] folgendes ein:
Restart=on-failure
RestartSec=3sDann sieht das folgendermaßen aus:
Danach muss man den Dienst nochmal neu laden
systemctl daemon-reloadQuelle: https://ma.ttias.be/auto-restart-crashed-service-systemd/
Ich hatte den Bedarf für alle Benutzer in einer OU das Passwort zu ändern – das geht super leicht per Powershell:
Get-ADUser -Filter * -SearchBase "OU=ou_name,DC=domain,DC=local" | Set-ADAccountPassword -Reset -NewPassword (ConvertTo-SecureString -AsPlainText "Temp123$" -Force)Einfach die Searchbase und das Passwort anpassen – Fertig 🙂
Quelle: https://enterinit.com
Ich hatte auf einem Exchange-Management-Host das Problem das nach der Installation manche Befehle nicht funktionierten und folgende Fehler geworfen haben:
Der Parameter "RecipientFilter" kann nicht an das Ziel gebunden werden. Ausnahme beim Festlegen von "RecipientFilter": "Die Datei oder Assembly<br>"Microsoft.Exchange.ManagedLexRuntime.MPPGRuntime, Version=15.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" oder eine Abhängigkeit davon wurde nicht gefunden. Das System<br>kann die angegebene Datei nicht finden."oder
Get-CASMailbox : Cannot bind parameter 'Filter' to the target. Exception setting "Filter": "Could not load file or assembly 'Microsoft.Exchange.ManagedLexRuntime.MPPGRuntime, Version=15.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of it\ s dependencies. The system cannot find the file specified."Auf dem Exchange Server direkt trat der Fehler nicht auf.
Die Lösung war relativ simpel:
Man muss nur die Microsoft.Exchange.ManagedLexRuntime.MPPGRuntime.dll aus dem Verzeichnis C:\Program Files\Microsoft\Exchange Server\V15\Bin von einem Exchange Server in das gleiche Verzeichnis auf dem Mangement-Server kopieren.
Danach gingen alle Befehle auch vom Management -Server 🙂
Will man unter Linux (in meinem Fall Debian) iperf3 als Deamon laufen lassen geht das relativ einfach wie folgt:
Erstmal installieren wir iperf3
sudo apt install iperf3
Danach erstellen wir die Service-Datei für den systemd-Deamon:
sudo vim /etc/systemd/system/iperf3.service
Dort kopieren wir folgendes rein und speichern die Datei:
[Unit]Description=iperf3[Service]ExecStart=/usr/bin/iperf3 --server[Install]WantedBy=multi-user.target
Jetzt können wir den Deamon aktiveren:
sudo systemctl enable iperf3
Jetzt können wir den Deamon starten:
sudo systemctl start iperf3
Überprüfen ob der Dienst läuft:
sudo systemctl status iperf3
Jetzt läuft immer der iperf3-Dienst – auch nach Restart des Severs 🙂
Wenn man auf einem Windows-Server – in meinem Fall ein Windows Server 2016 – den NuGet Paketmanager nachinstallieren will – z.B. um die Azure PowerShell-Module zu installieren – schlägt dies seit geraumer Zeit (Seit April 2020) fehl:
Die Fehlermeldung von Install-PackageProvider -Name NuGet lautet:
Install-PackageProvider : Für die angegebenen Suchkriterien für Anbieter „NuGet“ wurde keine Übereinstimmung gefunden.
Der Paketanbieter erfordert das PackageManagement- und Provider-Tag. Überprüfen Sie, ob das angegebene Paket über die
Tags verfügt.
Der Grund ist vermutlich ein „Upgrade“ des Azureedges, der den Lookup-Provider stellt (onegetcdn.azureedge.net/providers). Der Endpunkt lässt seit etwa April 2020 keine TLS1.0 und TLS1.1 Verbindungen mehr zu und wurde auf „TLS1.2 min“ konfiguriert. Die PowerShell (< 14393.3474) spricht per Default aber nur TLS1.1.
Mit folgendem Befehl stellt man die PowerShell auf TLS 1.2 um:
[Net.ServicePointManager]::SecurityProtocol=[Net.SecurityProtocolType]::Tls12
Danach funktioniert die Installation:
Quelle: https://www.zueschen.eu/
Wenn man am Nginx die SSL-Ciphers updatet und danach gehen manche ältere Client-Zertifikate nicht mehr, liegt das daran das auch für die Client-Zertifikate die Ciphers gelten die unter ssl_ciphers konfiguriert sind – und ist das z.B. sha1RSA nicht mehr drin (hoffentlich 😉 ) werden auch Client-Zertifikate die mit sha1RSA nicht mehr akzeptiert.
Im Log taucht dann folgender Fehler auf:
client SSL certificate verify error: (68:CA signature digest algorithm too weak)
und der Client bekommt
400 Bad Request The SSL certificate error
Um das Problem zu lösen muss man @SECLEVEL=0 an seine ssl_ciphers anhängen – z.B. :
ssl_ciphers 'HIGH:!aNULL:!MD5@SECLEVEL=0';Danach werden die Client-Zertifikate wieder akzeptiert – die Sicherheit der eigentlichen SSL-Verbindung ist hiervon nicht betroffen 🙂
Quelle: stackoverflow.com