Windows-Prozessaktivierungsdienst startet nicht – Fehler 6801

Auf einem Windows-Server (in dem Fall ein 2008 R2) mit IIS starteten die IIS-Dienste nicht, da der Windows-Prozessaktivierungsdienst mit folgender Fehlermeldung nicht starten wollte:

„Windows konnte den Prozessaktivierungsdienst nicht sarten – Fehler 6801: Die Transaktionsunterstützung im angegebenen Ressourcen-Manager wurde nicht gestartet oder aufgrund eines Fehlers heruntergefahren“

bzw.:

„Windows could not start the Windows Process Activation Service – Error 6801: Transaction support within the specified resource manager is not started or was shut down due to an error“

Das Problem kann man folgend lösen:

eine Eingabeaufforderung (cmd) als Administrator startet und folgenden Befehl ausführen:

fsutil resource setautoreset true c:\

Danach muss man den Server neu starten – jetzt sollte der WAS (Windows-Prozessaktivierungsdienst) wieder starten – und somit auch die davon abhängigen IIS-Dienste 🙂

Quelle: forum.iis.net

Powershell: Programm oder Skript mit Credentials und „als Administrator“ ausführen

Manchmal muss man unter Windows ein Programm oder ein Skript mit speziellen Credentials ausführen und zusätzlich „als Administrator“ ausführen.

Das funktioniert über die Powershell einfach wie folgt:

$User = "Username"
$Password = "Password" | ConvertTo-SecureString -asPlainText -Force
$MyCredential = New-Object System.Management.Automation.PSCredential($User,$Password)

Start-Process -WindowStyle Hidden powershell.exe -Credential $MyCredential -ArgumentList '-noprofile -command &{Start c:\program\program.exe -Verb RunAs}'

Hier wird eine Powershell.exe mit den angegebenen Username und Passwort ausgeführt (Klartext-Passwörter sind natürlich schlecht – dienen hier nur als Beispiel!) und der Powershell.exe wird das Programm zum ausführen übergeben mit dem Attribut -Verb RunAs dass das Programm „als Administrator“ ausführt.

fertig 🙂

Let’s Encrypt mit NGINX

Ich setze den NGINX ja gerne sowohl als Web Server als auch als Reverse Proxy ein – fast genauso gerne setzte ich mittlerweile die Let´s Encrypt Zertifikate ein.

Hier eine kleine Anleitung wie ich das immer konfiguriere (Webroot unter Ubuntu):

1) Erstellen eines NGINX-Config-Snippet

wir erstellen einen Config-Datei

vim /etc/nginx/snippets/letsencrypt.conf

und dort einfügen (gegebenfalls das Verzeichnis unter root ändern):

location ^~ /.well-known/acme-challenge/ {
default_type „text/plain“;
root /var/www/letsencrypt;
allow all;
}

und mit :wq abspeichern

2) Anpassen der bestehenden NGINX-Konfig

Ich konfiguriere eigentlich meine Webseiten immer als HTTPS-only – das heißt jede Anfrage auf Port 80 (HTTP) auf 443 (HTTPS) umgeleitet.

Da die Domänen-Verifizierung von Let´s Encrypt über einen HTTP Aufruf gemacht wird, müssen wir allerdings hier eine Ausnahme erstellen.

Dazu passen wir unsere Webseiten Konfig an:

vim /etc/nginx/sites-available/meineseite

und fügen unser Snippet mittels include in dem Serverteil für HTTP hinzu:

server {
        listen 80;
        listen [::]:80;

        server_name www.meineseite.de;

	include /etc/nginx/snippets/letsencrypt.conf;

        # Redirect any HTTP request to HTTPS
        location / {
        return 301 https://www.meineseite.de;}

        error_log  /var/log/nginx/meineseite-error.log;
        access_log /var/log/nginx/meineseite-access.log;
}

Im Serverteil für HTTPS braucht hier nichts angepasst werden 🙂

3) Installieren des Let´s Encrypt Clients

Installation unter Debian, Ubuntu, etc:

sudo apt-get install letsencrypt

4) erstellen des root-Verzeichnises für Let´s Encrypt

sudo mkdir -p /var/www/letsencrypt/.well-known/acme-challenge

Ich vergebe auch noch entsprechende Rechte (meistens läuft der NGINX ja als www-data User bzw. der User ist in der www-data-Gruppe)

sudo chown -R www-data:www-data /var/www/letsencrypt

5) NGINX reload

sudo systemctl reload nginx

6) Let´s Encrypt Client auführen

letsencrypt certonly –webroot -w /var/www/letsencrypt -d www.meineseite.de -d meinerseite.de –email email@meineseite.de –agree-tos

mittels -d domain.tld können noch weitere Domains – falls benötigt – hinzugefügt werden und unbedingt die Email nicht vergessen anzupassen!

Falls alles geklappt hat werden jetzt die Zertifikate ausgestellt – zu finden sind die Zertifikate unter /etc/letsencrypt/live/www.meineseite.de

7) HTTPS-Konfig anpassen

Jetzt müssen wir noch die neuen Zertifikate in die HTTPS-Konfig hinzufügen

vim /etc/nginx/sites-available/meineseite

und die Zertifikate angeben

ssl_certificate /etc/letsencrypt/live/www.meineseite.de/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/www.meineseite.de/privkey.pem;

mit :wq speichern – und wir sind fast fertig 🙂

8) Renew automatisieren

Die Let´s Encrypt Zertifikate haben die Einschränkung, dass sie nur 90 Tage gültig sind. Man kann hier aber über einen cron-job Abhilfe leisten:

sudo crontab -e

und die folgenden Zeilen hinzufügen

30 2 * * 1 /usr/bin/letsencrypt renew >> /var/log/le-renew.log
35 2 * * 1 /bin/systemctl reload nginx

so wird automatisch das Zertifikat verlängert und die Konfig des NGINX aktualisiert

9) fertig 🙂

Quellen:
letsencrypt.org
GitHub

Upgrade VMWare ESXi über die CLI

Will man einen ESXi-Host updaten oder z.B. von 6.0 auf 6.5 upgraden, kann man das ganz einfach wie folgt über die CLI erledigen:

1) SSH-Dienst auf dem Host starten

Entweder im Web Client unter Aktionen – Dienste – Secure Shell (SSH) aktivieren

ssh-aktivieren-webclient

oder im vSphere Client wie hier beschrieben

2) Anmeldung über SSH

3) Firewall für HTTP freischalten

esxcli network firewall ruleset set -e true -r httpClient

4) Upgrade-Paket suchen – hier als Beispiel die Version 6.5

esxcli software sources profile list -d https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml | grep -i ESXi-6.5

(Für andere Versionen einfach bei dem grep die entsprechende Version abändern)

Dann bekommt man folgende Anzeige

ssh-upgrade-paket-finden

5) Upgrade ausführen

esxcli software profile update -p ESXi-6.5.0-4564106-standard -d http://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml

(Für andere Versionen einfach die entsprechende Version abändern)

Nach dem erfolgreichen update sieht man folgendes

ssh-upgrade-beendet

6) Nestarten

reboot

fertig 🙂

Windows 10 kann auf NetApp Cifs Freigaben nicht zugreifen

Ich hatte das Problem dass ein neuer Rechner mit Windows 10 nicht auf Cifs-Freigaben auf einem NetApp-Filer zugreifen konnte. Der alte Trick mit dem Ausschalten des „Sicheren Aushandeln“ – der Secure Negotiaten – funktionierte nicht mehr…

Lösung:

Auf der NetApp (per SSH) folgenden Befehl ausführen:

options cifs.smb2.signing.required on

Danach funktionierte der Zugriff reibungslos 🙂

In eigener Sache: Serverumzug

Ich habe meine WordPress-Installation auf einen neuen Server umgezogen – inklusive upgrade der Software -> neueste Ubuntu-Version, MariaDB statt MySQL, PHP7 statt PHP5, neueste nginx-Version inkl. benutztung von neuen Features, etc…

Es sollte alles funktionieren – falls nicht bitte hier einen kurzen Kommentar rein – Danke 🙂

Ubuntu 16.04: apt-get hat Probleme mit IPv6

Wenn ich auf einem Ubuntu 16.04 Server apt-get update oder auch apt-get upgrade ausführe, bleibt es beim abrufen der Paketquellen über IPv6 einfach hängen:

root@ubuntu:~# apt-get update -y
OK:1 http://de.archive.ubuntu.com/ubuntu xenial InRelease
OK:2 http://de.archive.ubuntu.com/ubuntu xenial-updates InRelease
OK:3 http://de.archive.ubuntu.com/ubuntu xenial-backports InRelease
0% [Verbindung mit security.ubuntu.com (2001:67c:1560:8001::14)]

aptgetipv6

Lösen kann man das Problem wenn man IPv4 enforced:

apt-get -o Acquire::ForceIPv4=true update
apt-get -o Acquire::ForceIPv4=true upgrade

Alternativ kann man das auch persistent einstellen:

echo ‚Acquire::ForceIPv4 „true“;‘ | tee /etc/apt/apt.conf.d/99force-ipv4

Danach kann ich einfach wieder ganz normal apt-get update ausführen 🙂

root@ubuntu:~# apt-get update
OK:1 http://security.ubuntu.com/ubuntu xenial-security InRelease
OK:2 http://de.archive.ubuntu.com/ubuntu xenial InRelease
OK:3 http://de.archive.ubuntu.com/ubuntu xenial-updates InRelease
OK:4 http://de.archive.ubuntu.com/ubuntu xenial-backports InRelease
Paketlisten werden gelesen... Fertig

aptgetipv4

Microsoft: KB3159398 macht Probleme bei der Gruppenrichtlinenverarbeitung

Das KB3159398, dass über Windows Update zur Zeit verteilt wird, ändert ein wenig die Art und Weise wie die Sicherheitsfilterung bei der Gruppenrichtlinienverarbeitung funktioniert.

Das kann zu Problemen führen, wie z.B.:

– Laufwerke werden nicht mehr gemappt
– Desktop-Symbole für Verknüpfungen werden nicht mehr sauber angezeigt
– Diverse Gruppenrichtlinien (z.B. Druckerzuweisungen, etc) funktionieren nicht mehr

Das Problem liegt an einem fehlendem Lese-Recht des Authentifizierte Benutzer (Authenticated Users) unter Delegierung, dass durch den Patch jetzt allerdings benötigt wird.

In dem KB dazu hat Microsoft das Problem auch beschrieben:

Known issues

MS16-072 changes the security context with which user group policies are retrieved. This by-design behavior change protects customers’ computers from a security vulnerability. Before MS16-072 is installed, user group policies were retrieved by using the user’s security context. After MS16-072 is installed, user group policies are retrieved by using the machines security context. This issue is applicable for the following KB articles:

3159398 MS16-072: Description of the security update for Group Policy: June 14, 2016
3163017 Cumulative update for Windows 10: June 14, 2016
3163018 Cumulative update for Windows 10 Version 1511 and Windows Server 2016 Technical Preview 4: June 14, 2016
3163016 Cumulative Update for Windows Server 2016 Technical Preview 5: June 14 2016

Symptoms

All user Group Policy, including those that have been security filtered on user accounts or security groups, or both, may fail to apply on domain joined computers.

Cause

This issue may occur if the Group Policy Object is missing the Read permissions for the Authenticated Users group or if you are using security filtering and are missing Read permissions for the domain computers group.

Resolution

To resolve this issue, use the Group Policy Management Console (GPMC.MSC) and follow one of the following steps:
– Add the Authenticated Users group with Read Permissions on the Group Policy Object (GPO).
– If you are using security filtering, add the Domain Computers group with read permission.

Lösung: Die Authentifizierten Benutzer manuell mit dem Lese-Recht bei den Delegierungen hinzufügen

AuthUsersGPO

Es gibt auch hier ein Script dass das automatisch macht.

Empfehlenswerter Artikel zu lesen: http://www.gruppenrichtlinien.de/artikel/sicherheitsfilterung-neu-erfunden-ms16-072-patchday-14062016/