Hope This Helps

Problem:
Wer kennt das nicht...ein VSS Writer steht nach dem Backup mit einem Fehler im System und Sie können den Server nicht neu starten, da dieser in Verwendung ist!

Lösung:

1.) Überprüfen Sie mit folgendem Befehl, welcher Writer im Fehler-Status ist:

vssadmin list writers

2.) Hier finden Sie alle VSS Writer und unter Status sollte "Stabil" stehen, ansonsten hat dieser einen Fehler
3.) Folgenden Dienst müssen Sie neu starten um den entsprechenden Writer wieder in den Status "Stabil" zu bekommen
(Achtung: Die Dienste sind in Englisch und könnten von Ihren Namen abweichen)


Quelle: datto: How to resolve VSS writer errors without rebooting (VShadow)

Problem:
Die Exchange-Konfigurations-Website (https://mailserver.domain.tld/ecp) ist ja sowohl extern als auch intern erreichbar, wenn man nicht den Luxus eines Reverse-Proxy besitzt. Ich habe immer ein etwas schlechtes Gefühl, wenn meine Exchange-Konfiguration von extern erreichbar ist. Vor allem, wenn z.B. ein IT-Kollege im Zorne ausscheidet und alle Passwörter hat und mir dadurch theoretisch die Datenbank einfach löschen könnte. Da ich keinen Reverse-Proxy besitze musste ich eine andere Lösung finden.

Überlegungen:
Es gibt ja die Möglichkeit die ECP-Admin-Webseite abzuschalten, was das Ganze zwar sicher macht, aber auch nicht mehr administrierbar!
Zuerst wollte ich einfach auf dem IIS die "Einschränkungen für IP-Adressen und Domänennamen" aktivieren. Das löst das Problem mit dem externen Zugriff, hat aber den Nachteil, dass die Benutzer über OWA auch nicht mehr Ihr Konto verwalten können um z.B. den Abwesenheitsassistenten zu aktivieren (Teil des ECP). Also...nur begrenzt gut.
Microsoft selbst sagt, dass man einen zusätzlichen CAS-Server aufsetzen soll, der nur intern erreichbar ist und auf dem externen den Admin-Zugang deaktivieren soll. Leider fehlen mir hierzu die Ressourcen und in kleinen und mittelständigen Unternehmen ist das "a little bit too much"

Lösung:
Die Lösung liegt darin, dass man eine neue ECP-Webseite anlegt und diese im IIS auf eine zweite Netzwerkkarte im Exchange bindet. Die IP-Adresse der neuen Netzwerkkarte ist nur intern erreichbar, wohingegen die "alte" Netzwerkkarten-IP extern erreichbar ist.

Folgende Vorgehensweise zur Lösung:
1.) Fügen Sie dem Exchange-Server eine zweite Netzwerkkarte hinzu.

2.) Vergeben Sie eine neue IP-Adresse für diese Karte und deaktivieren Sie "Diese Verbindung im DNS registrieren", damit der Exchange nicht über mehrere IP-Adresse im DNS erreichbar ist.

3.) Tragen Sie im DNS-Server den FQDN für die neue Webseite mit der neuen IP ein (z.B. ecp.demo.local) - das wird später Ihre URL für den Aufruf werden.

4.) Erstellen Sie auf dem Exchange-Server eine neues Verzeichnis "c:\inetpub\wwwroot2"

5.) Erstellen Sie im IIS eine neue Website und verweisen Sie auf den zuvor erstellten wwwroot2-Ordner und benennen Sie diese z.B. als "ECPIntern"

6.) Binden Sie die neu erstellte Webseite mit Port 80 (http) und Port 443 (https) an die neue, interne IP-Adresse

7.) Erstellen Sie ein neues ECP Virtual Directory mit dem folgenden Befehl (bitte entsprechend anpassen):

New-EcpVirtualDirectory -Server ServerName -WebSiteName "ECPIntern" -InternalUrl "https://eac.demo.local/ecp"

8.) Jetzt benötigen wir noch ein neues OWA Virtual Directory (bitte entsprechend anpassen):

New-OwaVirtualDirectory -Server ServerName -WebSiteName "ECPIntern" -InternalUrl "https://eac.demo.local/owa"

9.) Jetzt müssen wir noch den Admin-Zugriff auf der "alten" IP-Adresse deaktivieren:

Set-ECPVirtualDirectory -Identity "ServerName\ecp (default web site)" -AdminEnabled $false

10.) Ich habe mir jetzt noch über den Exchange ein neues SSL-Zertifikat ausgestellt, dass den FQDN der neuen ECP-Webseite beinhaltet und dieses im IIS an die neue ECP-Webseite gebunden um SSL-Fehler im Browser zu unterdrücken (Zertifikat per GPO ausstreuen)

HINWEIS AM RANDE: Die neue Konfiguration kann bis zu 30 Minuten dauern, bevor der Admin-Zugriff auf die alte ECP-Webseite nicht mehr funktioniert. Also bitte Geduld haben oder Server neu starten!

Quellen für die Lösung:
anexinet: Disable External Access of the Exchange Admin Center

erstmal für alle die mosquitto nicht kennen das ist es : mosquitto.org

erstmal installieren wir alles was wir benötigen

sudo apt install mosquitto mosquitto-clients

nach der Installation aus den Debian Paketen liegt ein funktionierendes mosquitto auf der Platte nur ist es nicht sicher konfiguriert. Um es noch ein bisschen mehr abzusichern sollte man an den Configfiles etwas schrauben.

Hier ist meine mosquitto.conf diese liegt unter /etc/mosquitto/

pid_file /var/run/mosquitto.pid
persistence true
persistence_location /var/lib/mosquitto/
persistent_client_expiration 7d
connection_messages true
log_dest syslog
log_timestamp false
log_type error
log_type warning
log_type notice
log_type information
port 1883
max_connections -1
allow_anonymous false
use_identity_as_username false
password_file /etc/mosquitto/users
acl_file /etc/mosquitto/roles
include_dir /etc/mosquitto/conf.d

Als erstes legen wir einen Benutzer für mosquitto an.

touch /etc/mosquitto/users ; mosquitto_passwd /etc/mosquitto/users BENUTZERNAME

Jetzt brauchen wir die Rechte der User

touch /etc/mosquitto/roles ; vi /etc/mosquitto/roles

Hier ein Vorschlag für die roles, der Benutzer monitor hat alle rechte während der Benutzer clmon nur schreiben darf.

user monitor
topic write /mqtt/#
topic read /mqtt/#

user clmon
topic write /mqtt/#

Zum testen der konfig bieten sich die beiden tools mosquitto_sub und mosquitto_pub an.

Subscribe

mosquitto_sub -u USERNAME -P PASSWORD -t "/mqtt/#"

Publish

mosquitto_pub -h localhost -u USERNAME -P PASSWORD -t "/mqtt/test/" -m "TESTNACHRICHT"

Quelle : Mosquitto Dokumentation

erstmal was ist Influx db eigentlich : Influxdb

Um eine InfluxDB absichern zu können muss als erstes ein Benutzer mit Admin Rechten angelegt werden, BEVOR man Auth aktiviert.

Anlegen eines Admin Users :

CREATE USER admin WITH PASSWORD 'SECUREPASSWORD' WITH ALL PRIVILEGES

Überprüfen / Anzeigen der User geht mit dem Befehl :

SHOW USERS

bzw für die Rechte

SHOW GRANTS FOR admin

Jetzt muss die Authentifizierung aktiviert werden. Dazu muss die Konfiguration unter /etc/influx/influx.conf angepasst werden.
Hier mal der entscheidende Block (Ohne Kommentare)

[http]
   enabled = true
   bind-address = ":8086"
   auth-enabled = true
   access-log-path = "/var/log/influxdb/access.log"
   write-tracing = false
   pprof-enabled = false
   https-enabled = false
   https-certificate = "/etc/ssl/influxdb.pem"

Ab jetzt könnt ihr euch mit dem folgenden Befehl verbinden

influx -username admin -password SECUREPASSWORD -database DATABASENAME

was auch funktioniert ist mit dem Befehl

influx

die cli starten und dann mit dem Befehl

auth

die Authentifizierung einleiten.


Weitere Standardbefehle

InfluxDB Datenbanken anzeigen :

SHOW DATABASES

InfluxDB Datenbank anlegen :

CREATE DATABASE "DATABASENAME"

InfluxDB User anlegen :

CREATE USER dev WITH PASSWORD 'SECUREPASSWORD'

InfluxDB Rechte vergeben auf Datenbank :

GRANT (READ,WRITE,ALL) ON DATABASENAME TO dev

Quelle : InfluxDB 1.5 documentation