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/

VMWare: Backup beschädigt Datenbanken (Exchange, SQL, ActiveDirectory)

Ich hatte bei einem Kunden das Problem, dass in schöner Regelmäßigkeit die Exchange-Datenbanken, SQL-Datenbanken und auch die Datenbanken des ActiveDirectorys auf den Domain-Controllern, die in VMs unter VMWare liefen, nach der Sicherungen (in meinem Fall mit Veeam) Fehler aufwiesen – oder teilweise sogar ganz defekt waren.

Nach ewiger Sucherei stellt sich heraus: Die eingesetzte VMWare-Version (vSphere 6.0) hatte ein schwerwiegendes Problems mit dem CBT Treibern – betroffen waren Oracle, SQL, AD und Exchange Datenbanken. Hier auch ein Thread zu dem Thema.

Die Lösung ist hier ganz simpel: Update der VMWare-Umgebung (mindestens) auf das Update 1b – den dort ist der Bug behoben.

Seitdem keine Problem mehr 🙂

Windows: Event 2103 – AD-Datenbank wurde anhand eines Verfahrens nicht unterstützte Wiederherstellung wiederhergestellt

Ich hatte in einem AD das Problem, dass nach einem Restore aus einem Snapshot die Domain Controllern die Anmeldung der User verweigerten und auch untereinander nicht mehr replizierten. Im Eventlog wurde folgender Fehler protokolliert:

Ereignistyp: Fehler
Ereignis Quelle: NTDS Allgemein
Ereigniskategorie: Steuerung
Ereignis-ID: 2103
Beschreibung: Die Active Directory-Datenbank wurde anhand eines Verfahrens nicht unterstützte Wiederherstellung wiederhergestellt. Active Directory können Benutzer anmelden, während das Problem weiterhin besteht. Als Ergebnis wurde der Netlogon-Dienst angehalten. Benutzer Aktion Siehe vorherige Ereignisprotokolle Einzelheiten. Weitere Informationen finden Sie im Hilfe- und Supportcenter unter http://support.microsoft.com.

Und bei der Replikation wurde die Fehlermeldung (z.B. bei repadmin /showrepl)

Der Quellserver nimmt keine Replikationsanforderung entgegen

ausgegeben.

Das ganze Problem wurde verursacht, dass durch die nicht unterstützte Wiederherstellung – in meinem Fall ein Snapshot – die Datenbank der Active Directorys auf Not Writeable gesetzt wurde.

Das ganze wieder ans laufen bekommt man wenn man in der Registry auf dem DC unter

HKLM\System\CurrentControlSet\Services\NTDS\Parameters

den Wert „Dsa Not Writable“ von 4 auf 0 setzt.

Dazu legt man noch einen REG_DWORD “Ignore USN Rollback” an und setzt den Wert auf 0

Danach muss man den Server neustarten.

Damit die Replikation wieder sauber funktioniert muss man auf allen DC-Servern die Befehle

repadmin /options “ServerName” -DISABLE_OUTBOUND_REPL
repadmin /options “ServerName” -DISABLE_INBOUND_REPL

ausführen – wobei „ServerName“ mit dem jeweiligen lokalen Servernamen des DCs ersetzten.

Jetzt sollte eigentlich alles laufen.

Falls allerdings die Replikation noch nicht funktioniert – oder andere Fehler im Eventlog protokolliert werden – kann noch ein Reset des Passwortes des Computerkontos der Domaincontroller nötig sein.

Das macht man auf den DCs folgendermaßen (am besten davor einen Reboot machen):

netdom resetpwd /server:anderer_dc /userd:domain\administrator /passwordd:*

Danach den Server rebooten.

Jetzt sollte es wirklich wieder laufen 🙂

Quelle: hyper-v-server.de

NGINX: ReverseProxy für MAPI over HTTP, EAS und OWA

Ich habe ja mal hier beschrieben wie man einen NGNIX-ReverseProxy für EAS (Exchange ActiveSync) und OWA (OutlookWebApp) konfiguriert.

Mit Exchange 2013 wurde MAPI over HTTP eingeführt und spätestens mit Exchange 2016 wird dieses Protokoll für die Verbindung mit Outlook verwendet. Mit wenig Aufwand kann man jetzt den NGINX auch dafür verwenden um externe Outlooks anzubinden – egal ob Outlook 2010, 2013 und auch das neue Outlook 2016.

Damit das sauber – auch über Autodiscover (wichtig für Outlook 2016) – funktioniert sind folgende Vorarbeiten zu beachten:

1) Autodiscover konfigurieren

Ich empfehle die URLs der Virtuellen Verzeichnisse und von Autodiscover auf einen DNS-Namen zu setzten der intern und extern auflösbar ist – z.B. outlook.domain.de und autodiscover.domain.de.

Die URLs am Exchange kann man folgendermaßen am Exchange über die Exchange Management Shell konfigurieren:

Set-OWAVirtualDirectory –Identity „OWA (default web site)“ -ExternalURL „https://outlook.domain.de/OWA“
Set-OWAVirtualDirectory –Identity „OWA (default web site)“ -InternalURL „https://outlook.domain.de/OWA“

Set-OABVirtualDirectory –Identity „OAB (default web site)“ -ExternalURL „https://outlook.domain.de/OAB“
Set-OABVirtualDirectory –Identity „OAB (default web site)“ -InternalURL „https://outlook.domain.de/OAB“

Set-ECPVirtualDirectory –Identity „ECP (default web site)“ -ExternalURL „https://outlook.domain.de/ECP“
Set-ECPVirtualDirectory –Identity „ECP (default web site)“ -InternalURL „https://outlook.domain.de/ECP“

Set-WebServicesVirtualDirectory –Identity „EWS (default web site)“ -ExternalUrl „https://outlook.domain.de/ews/exchange.asmx“
Set-WebServicesVirtualDirectory –Identity „EWS (default web site)“ -InternalUrl „https://outlook.domain.de/ews/exchange.asmx“

Set-ActiveSyncVirtualDirectory –Identity „Microsoft-Server-ActiveSync (default web site)“ -ExternalURL „https://outlook.domain.de/Microsoft-Server-ActiveSync“
Set-ActiveSyncVirtualDirectory –Identity „Microsoft-Server-ActiveSync (default web site)“ -InternalURL https://outlook.domain.de/Microsoft-Server-ActiveSync

Set-ClientAccessServer -AutoDiscoverServiceInternalUri „https://autodiscover.domain.de/Autodiscover/Autodiscover.xml“

Im Zertifikat des Exchanges müssen natürlich auch diese beiden DNS-Namen stehen – in diesem Beispiel also outlook.domain.de und autodiscover.domain.de.

Im internen DNS und im externen DNS müssen die beiden DNS-Namen strong>outlook.domain.de und autodiscover.domain.de eingetragen werden – im internen DNS direkt auf euren Exchange-Server und im externen auf die öffentliche IP des ReverseProxys.

2) IIS am Exchange konfigurieren

Damit über den ReverseProxy z.B. auch der Abwesenheitsassistent (Out of Office) und die E-Mail-Infos funktionieren, muss am IIS des Exchanges im EWS die Standardauthentifizierung aktiviert werden:

EWS-Standardauth-aktivieren

3) NGINX-Konfig

Die Grundinstallation ist ja schon hier beschreiben.

Für mein Beispiel muss das Zertifikat für den NGINX muss outlook.domain.de und autodiscover.domain.de enthalten. Der interne Exchange ist hier im Beispiel der exch2016.test.local.

Hier ist dann die Konfig für den ReverseProxy:


#Abschnitt 1
server {
        listen       80;
        server_name outlook.domain.de autodiscover.domain.de;

        # Redirect any HTTP request to HTTPS
        return 301 https://$server_name$request_uri;

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

#Abschnitt 2
server {
        listen       443;
        server_name outlook.domain.de autodiscover.domain.de;

        # Enable SSL
        ssl                     on;
        ssl_certificate         /etc/nginx/certs/cert.crt;
        ssl_certificate_key     /etc/nginx/certs/cert.key;
        ssl_session_timeout     5m;

        # Set global proxy settings
        proxy_read_timeout      360;

        proxy_http_version 1.1;
        proxy_pass_request_headers on;

        proxy_pass_header       Date;
        proxy_pass_header       Server;

        proxy_set_header        Host $host;
        proxy_set_header        X-Real-IP $remote_addr;
        proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header        Accept-Encoding "";

        more_set_input_headers 'Authorization: $http_authorization';
        proxy_set_header Accept-Encoding "";
        more_set_headers -s 401 'WWW-Authenticate: Basic realm="exch2016.test.local"';

        location /owa           { proxy_pass https://exch2016.test.local/owa; }
        location /EWS          { proxy_pass https://exch2016.test.local/EWS; }
        location /Microsoft-Server-ActiveSync { proxy_pass https://exch2016.test.local/Microsoft-Server-ActiveSync; }
        location /mapi           { proxy_pass https://exch2016.test.local/mapi; }
        location /rpc           { proxy_pass https://exch2016.test.local/Rpc; }
        location /OAB            { proxy_pass https://exch2016.test.local/OAB; }
        location /autodiscover           { proxy_pass https://exch2016.test.local/autodiscover; }

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

Damit hab ich ein Outlook 2016 an einen Exchange 2016 angebunden. Alles funktioniert – auch der Abwesenheitsassistent 🙂

Hilfreiche Quellen:
FrankysWeb
blog.kempkens.io

Exchange: Umlaute werden in Abwesenheitsnachricht nicht richtig angezeigt

Ich hatte bei einem Exchange 2013 das Problem, dass Umlaute in Abwesenheitsnachrichten (Out of Office) bzw. Automatischen Antworten nicht dargestellt wurden – diese wurden mit einem ? ersetzt. Das sah dann so aus:

OOFUmlaute

Ich habe das Problem damit behoben, dass ich den ContentType der RemoteDomain auf dem Exchange von MimeText auf MimeHTMLText mittels der Exchange Management Shell umgestellt habe:

get-remotedomain | set-remotedomain -ContentType MimeHtmlText

Danach waren alle Umlaute in den Automatischen Antworten und Abwesenheitsnotizen (OOF halt 😉 ) wieder richtig

OOFUmlauteOOF

Quelle: TechNET

Exchange 2013 CU11: Server nicht verfügbar in der Powershell

Nach der Installation von Exchange 2013 CU11 hatte ich das Problem, dass z.B. bei der Powershell-Abfrage Get-ExchangeServer nur noch alle alten Server mit Exchange 2010 angezeigt werden. Auch Server mit Exchange 2013 die noch keinen CU11 installiert hatten wurden nicht mehr angezeigt. Somit war die Exchange-Verwaltungsshell ziemlich nutzlos….

In der ECP (Exchange Administrative Center) auf dem Exchange 2013 mit CU11 jedoch wurden alle Server richtig angezeigt und man konnte auch Einstellungen, etc bearbeiten und auch ändern.

Um das Problem zu beheben und wieder muss folgendes ausgeführt werden:

1) Im Exchange Administrative Center das Postfach des Administrators auf den neuen Exchange 2013 CU11 verschieben

2) Auf dem Exchange 2013 CU11 in der Regisry unter HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\ WSMAN\Client\ConnectionCookies die Einträge löschen (falls dort welche vorhanden sind)

Danach geht wieder alles in der Exchange-Verwaltungsshell 🙂

Quelle: TechNet