Infrastrukturelle Überlegungen

Netzwerk

Proxies vermeiden

Die anfängliche Bereitstellung benötigt direkten Internetzugang. Ideal wäre kein Proxy, aber ein transparenter Proxy sollte gut funktionieren (wenn er wirklich transparent ist). Falls ein Proxy unvermeidbar ist, müssen mindestens 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 Dienst-Tags – Public Cloud

Diese Datei enthält die Compute-IP-Adressbereiche (einschließlich SQL-Bereiche), die von den Microsoft Azure-Rechenzentren verwendet werden. Jede Woche (mittwochs, Pazifik-Zeit) wird eine neue XML-Datei mit den geplanten IP-Adressbereichen hochgeladen. Neue IP-Adressbereiche treten am folgenden Montag (Pazifik-Zeit) in Kraft. Laden Sie die neue XML-Datei herunter und nehmen Sie die notwendigen Änderungen auf Ihrer Seite vor, bevor der Montag eintritt.

Office‑365-URLs und IP-Adressbereiche

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

Die Filterung allein nach IP-Adressen ist aufgrund von Abhängigkeiten zu 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. Diese Abhängigkeiten umfassen auch Abhängigkeiten von anderen Microsoft-Diensten wie dem Azure Content Delivery Network und können in Netzwerktraces oder Firewall-Protokollen Verbindungen zu IP-Adressen Dritter oder Microsofts zeigen, die nicht auf dieser Seite aufgeführt sind. Diese nicht aufgeführten IP-Adressen, sei es von Drittanbieter- oder Microsoft-eigenen CDN- und DNS-Diensten, werden dynamisch zugewiesen und können sich jederzeit ändern.

BranchCache und Geräteisolation

BranchCache ist eine Windows-Technologie, die dazu entwickelt wurde, WAN-Verkehr zu reduzieren und die Inhaltsbereitstellung zu beschleunigen innerhalb von Firmennetzwerken. Sie ermöglicht es Windows-Clients, heruntergeladene Daten miteinander zu teilen, anstatt dass jedes Gerät denselben Inhalt wiederholt aus der Cloud herunterlädt.

Für RealmJoin ist BranchCache standardmäßig aktiviert auf CDN- und Client-Seite.

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 verlassen wir uns daher auf BranchCache, weil es ein in Windows integrierter Peering-Mechanismus ist, der für Inhalte von Drittanbietern funktioniert:

• CDN-Seite: Es ist standardmäßig aktiviert. Auf Anfrage können wir BranchCache auf der CDN-Seite vollständig deaktivieren (pro Mandant), wodurch die Client-seitige Konfiguration irrelevant wird.

• Auf der Client-Seiteist die Funktion ebenfalls standardmäßig aktiviert. Durch Setzen von BranchCache.Mode = "Undefined" (siehe Benutzer- und Gruppenrichtlinien), kann dieses Standardverhalten geändert werden. Für bereits vorhandene Clients wird die Funktion jedoch nicht aktiv deaktiviert, sobald sie zuvor aktiviert wurde. Um sie zu deaktivieren, führen Sie Disable-BC auf den gewünschten Geräten aus.

Damit BranchCache effektiv ist, müssen die Clients direkt miteinander kommunizieren können. Sie sollten also nicht durch verschiedene VLANs, Subnetze getrennt oder durch Geräteisolation in der Kommunikation blockiert sein. Wir verwenden BranchCache im Distributed Cache Mode, bei dem jeder Client einen lokalen Cache pflegt und gecachte 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 von RealmJoin nicht unterstützt .

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

• Ein Client sendet eine Multicast-Anfrage wie "Hat jemand Content-ID XYZ?"

• Jeder Peer, der das angeforderte Segment besitzt, antwortet direkt per Unicast.

Anstatt Pakete vom Server herunterzuladen, wird der Inhalt in Form der zerteilten Chunks an das Client-Gerät übertragen. Wenn die angeforderte Software auf mehreren Geräten verfügbar ist, wird die Last zwischen diesen verteilt.

Für weitere Details siehe Microsoft Learn: 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 (Benachrichtigungsdienst)