ugg.li

Problem

Man möchte einen Webserver hinter einem IIS als „Frontend“ Reverse Proxy via ARR (Application Request Routing) betrieben und dem IIS das SSL-Offloading überlassen.

Der reverse Proxy ist schnell eingerichtet, aber wie vermeidet man, das ein ACME-Tool (beispielsweise win-acme) an der Validierung des Zertifikates scheitert, weil der IIS die Requests an /.well-known/acme-challenge/* ebenfalls an den Webserver weiterleitet?

Lösung

Man verwendet verschiedene Regeln um das zu verhindern. Entweder erstellt man diese im wundervollen IIIS GUI oder bearbeitet die zugehörige web.config:

<configuration>
    <system.webServer>
        <rewrite>
            <rules>
                <clear />


<!-- Letsencrypt-Ausnahme -->
                <rule name="LetsEncryptException" stopProcessing="true">
                    <match url=".well-known/acme-challenge/*" />
                    <conditions logicalGrouping="MatchAll" trackAllCaptures="false" />
                    <action type="None" />
                </rule>


<!-- Redirect auf HTTPS -->
                <rule name="Redirect-HTTPS" stopProcessing="true">
                    <match url="(.*)" />
                    <conditions logicalGrouping="MatchAll" trackAllCaptures="false">
                        <add input="{HTTPS}" pattern="^OFF$" />
                    </conditions>
                    <action type="Redirect" url="https://DEINEDOMAIN.COM/{R:1}" appendQueryString="false" redirectType="Found" />
                </rule>


<!-- Redirect root "/" in Verzeichnis (oft hilfreich bei Tomcat Apps) -->
		<rule name="redirect-to-subdir" stopProcessing="true">
			<match url="^$" />
			<action type="Redirect" url="https://DEINEDOMAIN.COM/DEINVERZEICHNIS/WHATEVER" />
		</rule>


<!-- Reverse Proxy -->
                <rule name="ReverseProxy" stopProcessing="false">
                    <match url="(.*)" />
                    <conditions logicalGrouping="MatchAll" trackAllCaptures="false" />
                    <action type="Rewrite" url="http://INTERNERSERVER:8059/{R:1}" />
                </rule>


            </rules>
        </rewrite>
    </system.webServer>
</configuration>

Problem

Verwendet man mehrere OneDrive-Konten auf einem Computer, kommt es gelegentlich zu diesem Fehler, wenn man Dateien aus dem „zweiten“ OneDrive Ordner öffnet. Die Meldung kommt immer, unabhängig ob man die Dateien „on demand“ nutzen möchte oder vollständig synchronisiert hat.

Ihre Änderungen können nicht hochgeladen oder heruntergeladen werden, weil ihre zwischengespeicherten Anmeldeinformationen abgelaufen sind.

Wenn man sich dann anzumelden versucht, wie von Excel so prominent vorgeschlagen, erhält man die Fehlermeldung:

Leider ist an diesem Computer bereits ein anderes Konto aus Ihrer Organisation angemeldet.

Lösung

Das Problem sind die Office-Apps, die direkt versuchen mit dem angemeldeten Benutzer in das „fremde“ OneDrive zu schreiben. Das schlägt natürlich fehl, aber Office ignoriert hier scheinbar (äußerst penetrant) die erfolgte und korrekte Einrichtung als zweites OneDrive.

Glücklicherweise kann man dem OneDrive Client abgewöhnen, die Office-Apps zu konfigurieren. Die Option ist nur etwas seltsam benannt.

OneDrive-Symbol > Einstellungen > Office > „Office-Dateien, die ich öffne, mit Office-Anwendungen synchronisieren“ abschalten

Und schon funktrioniert der Zugriff wieder fehlerfrei – es ist nicht einmal ein Neustart notwendig (außer von den Office-Apps).

Allerdings gehen durch diese Umstellung die synchronen Online-Features verloren, wie die gleichzeitige Bearbeitung einer Datei durch mehrere Benutzer oder das automatische Online-Speichern.