# Überlegungen zur Infrastruktur

## Netzwerk

### Proxys vermeiden

Die Erstbereitstellung benötigt direkten Internetzugang. Kein Proxy wäre ideal, aber ein transparenter Proxy sollte problemlos funktionieren (wenn er wirklich transparent ist). Wenn ein Proxy als Mindestanforderung unvermeidbar ist, müssen die folgenden Dienste/Adressen direkt erreichbar sein:

Für eine Liste der entsprechenden IP-Bereiche klicken Sie auf den folgenden Link:

[Azure-IP-Bereiche und Diensttags – Öffentliche Cloud](https://www.microsoft.com/en-us/download/details.aspx?id=56519)

Diese Datei enthält die Compute-IP-Adressbereiche (einschließlich SQL-Bereiche), die von den Microsoft-Azure-Datencentern verwendet werden. Jeden Mittwoch (Pacific Time) wird eine neue XML-Datei mit den neu geplanten IP-Adressbereichen hochgeladen. Neue IP-Adressbereiche werden ab dem folgenden Montag (Pacific Time) wirksam.\
Laden Sie die neue XML-Datei herunter und nehmen Sie die erforderlichen Änderungen auf Ihrer Site vor, bevor der Montag beginnt.

[Office 365-URLs und IP-Adressbereiche](https://support.office.com/en-us/article/Office-365-URLs-and-IP-address-ranges-8548a211-3fe7-47cb-abb1-355ea5aa88a2)

Dieser Artikel verweist auf eine Datei, die die Compute-IP-Adressbereiche enthält, die Sie in Ihre ausgehenden Zulassungslisten aufnehmen sollten, damit Ihre Computer Office 365 erfolgreich nutzen können.

{% hint style="info" %}
Das Filtern von IP-Adressen allein ist aufgrund von Abhängigkeiten von internetbasierten Diensten wie Domain Name Services (DNS), Content Delivery Networks (CDNs), Certificate Revocation Lists und anderen Drittanbieter- oder dynamischen Diensten keine vollständige Lösung. Zu diesen Abhängigkeiten gehören auch Abhängigkeiten von anderen Microsoft-Diensten wie dem Azure Content Delivery Network, was zu Netzwerkprotokollen oder Firewall-Logs führt, die Verbindungen zu IP-Adressen anzeigen, die Drittanbietern oder Microsoft gehören, aber nicht auf dieser Seite aufgeführt sind. Diese nicht aufgeführten IP-Adressen, sei es von Drittanbietern oder von Microsoft betriebenen CDN- und DNS-Diensten, werden dynamisch zugewiesen und können sich jederzeit ändern.
{% endhint %}

### BranchCache und Geräteisolierung

BranchCache ist eine Windows-Technologie, die darauf ausgelegt ist, **WAN-Datenverkehr zu reduzieren** und **die Bereitstellung von Inhalten zu beschleunigen** innerhalb von Unternehmensnetzwerken. Dies geschieht, indem Windows-Clients heruntergeladene Daten miteinander teilen, anstatt dass jedes Gerät dieselben Inhalte wiederholt aus der Cloud abruft.

{% hint style="info" %}
Für RealmJoin ist BranchCache **standardmäßig aktiviert** auf CDN- und Client-Seite.
{% endhint %}

Warum nicht Delivery Optimization verwenden? Dieser Mechanismus unterstützt keine Paketquellen von Drittanbietern. Er funktioniert nur mit von Microsoft kontrollierten Endpunkten (z. B. Windows Update, Store, M365 Apps oder Intune).

Innerhalb von RealmJoin setzen wir daher auf BranchCache, weil es ein **integrierter Windows-Peering-Mechanismus** ist, der für Inhalte von Drittanbietern funktioniert:

* **CDN-Seite**: Er ist standardmäßig aktiviert. Auf Wunsch können wir BranchCache auf der CDN-Seite vollständig deaktivieren (pro Tenant), wodurch die Client-seitige Konfiguration irrelevant wird.
* Auf der **Client-Seite**, die Funktion ist ebenfalls standardmäßig aktiviert. Durch Setzen von `BranchCache.Mode = "Undefined"` (siehe [Benutzer- und Gruppeneinstellungen](https://docs.realmjoin.com/de/ugd-management/user-and-group-settings)), kann dieses Standardverhalten geändert werden. Für bereits vorhandene Clients wird die Funktion jedoch nicht aktiv deaktiviert, sobald sie zuvor einmal aktiviert wurde. Zum Deaktivieren führen Sie `Disable-BC` auf den gewünschten Geräten aus.

Damit BranchCache wirksam ist, müssen die Clients direkt miteinander kommunizieren können. Sie sollten daher nicht durch verschiedene VLANs oder Subnetze getrennt sein und auch nicht durch Geräteisolierung in der Kommunikation blockiert werden. Wir verwenden BranchCache im **Distributed Cache Mode**, bei dem jeder Client einen lokalen Cache führt und zwischengespeicherte Daten von Peers abruft. Die Option **Hosted Cache Mode**, die einen dedizierten Windows Server erfordert und auf Clients über die Richtlinie "Configure Hosted Cache Servers" konfiguriert wird, wird **nicht unterstützt** von RealmJoin.

Wenn ein Clientgerät Softwarepakete zum ersten Mal herunterlädt, werden die Dateien in Chunks aufgeteilt, die deutlich kleiner sind als der ursprüngliche Inhalt, und auf dem Gerät zwischengespeichert. Wird dasselbe Paket anschließend von einem anderen Clientgerät im selben Netzwerk angefordert, lädt es Inhaltsinformationen anstelle des vollständigen Inhalts vom Server herunter. Die Inhaltsinformationen werden verwendet, um den gewünschten Inhalt auf anderen Geräten im Netzwerk zu lokalisieren. **Erkennung von Client-Peers** im "Distributed Cache Mode" funktioniert wie folgt:

* Ein Client sendet eine Multicast-Anfrage wie „Hat jemand Inhalts-ID XYZ?“
* Jeder Peer, der den angeforderten Abschnitt enthält, antwortet direkt per Unicast.

Anstatt Pakete vom Server herunterzuladen, wird der Inhalt in Form der zerlegten Chunks auf das Clientgerät übertragen. Wenn die angeforderte Software auf mehreren Geräten verfügbar ist, wird die Last zwischen ihnen ausgeglichen.

Weitere Details finden Sie in Microsoft Learn: [BranchCache](https://learn.microsoft.com/en-us/windows-server/networking/branchcache/branchcache)

### RealmJoin-Verbindungsendpunkte

RealmJoin verbindet sich mit den folgenden Hosts (über HTTPS), die in Ihren Firewall-Einstellungen berücksichtigt werden sollten:

* `cdn.realmjoin.com`
* `x1.c.lencr.org`
* `client-api.realmjoin.com`
* `client-api-staging.realmjoin.com`
* `realmjoin-backend.azurewebsites.net`
* `realmjoin-backend-staging.azurewebsites.net`
* `nuget.realmjoin.com`
* `enterpriseregistration.windows.net`
* `gkrealmjoin.s3.amazonaws.com`
* `login.microsoftonline.com`
* `graph.microsoft.com`
* `realmjoinstaticcdn.azureedge.net` (Notifier)