> For the complete documentation index, see [llms.txt](https://docs.realmjoin.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.realmjoin.com/de/bereitstellung/infrastructure.md). # Ü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 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](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-Rechenzentren verwendet werden. Jede Woche mittwochs (Pazifische Zeit) wird eine neue XML-Datei mit den neu geplanten IP-Adressbereichen hochgeladen. Neue IP-Adressbereiche werden am folgenden Montag (Pazifische Zeit) wirksam.\ Laden Sie die neue XML-Datei herunter und nehmen Sie vor Montag die erforderlichen Änderungen an Ihrer Site vor. [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 verlinkt 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 allein nach IP-Adressen ist aufgrund von Abhängigkeiten von internetbasierten Diensten wie Domain Name Services (DNS), Content Delivery Networks (CDNs), Zertifikatsperrlisten und anderen Diensten von Drittanbietern 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 dazu führt, dass Netzwerk-Traces oder Firewall-Protokolle Verbindungen zu IP-Adressen anzeigen, die Drittanbietern oder Microsoft gehören, aber auf dieser Seite nicht aufgeführt sind. Diese nicht aufgeführten IP-Adressen, unabhängig davon, ob sie von einem CDN- oder DNS-Dienst eines Drittanbieters oder von Microsoft stammen, 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 Inhaltsauslieferung zu beschleunigen** innerhalb von Unternehmensnetzwerken. Dabei können Windows-Clients heruntergeladene Daten miteinander teilen, anstatt dass jedes Gerät denselben Inhalt immer wieder aus der Cloud abruft. {% hint style="info" %} Für RealmJoin ist BranchCache **standardmäßig aktiviert** sowohl auf CDN- als auch auf Clientseite. {% endhint %} Warum nicht Delivery Optimization verwenden? Dieser Mechanismus unterstützt keine Paketquellen von Drittanbietern. Er funktioniert nur mit von Microsoft gesteuerten Endpunkten (z. B.: Windows Update, Store, M365 Apps oder Intune). Daher setzen wir innerhalb von RealmJoin auf BranchCache, weil es ein **integrierter Windows-Peering-Mechanismus** ist, der mit Inhalten von Drittanbietern funktioniert: * **CDN-seitig**: Es ist standardmäßig aktiviert. Auf Wunsch können wir BranchCache CDN-seitig vollständig deaktivieren (pro Tenant), wodurch die clientseitige Konfiguration irrelevant wird. * Auf der **clientseitig**, ist die Funktion ebenfalls standardmäßig aktiviert. Durch das Setzen von `BranchCache.Mode = "Undefined"` (siehe [Benutzer- und Gruppeneinstellungen](/de/ugd-management/user-and-group-settings.md)), kann dieses Standardverhalten geändert werden. Für bestehende Clients wird die Funktion jedoch nicht aktiv deaktiviert, sobald sie einmal zuvor 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 also nicht durch unterschiedliche VLANs, Subnetze getrennt sein oder durch Geräteisolierung an der Kommunikation gehindert werden. Wir verwenden BranchCache im **Distributed-Cache-Modus**, bei dem jeder Client einen lokalen Cache vorhält und zwischengespeicherte Daten von Peers abruft. Die Option **Hosted-Cache-Modus**, der einen dedizierten Windows Server erfordert und auf Clients über die Richtlinie „Configure Hosted Cache Servers“ konfiguriert wird, ist **nicht unterstützt** von RealmJoin. Wenn ein Clientgerät Softwarepakete zum ersten Mal herunterlädt, werden die Dateien in Chunks unterteilt, die deutlich kleiner als der ursprüngliche Inhalt sind, und auf dem Gerät zwischengespeichert. Wird dasselbe Paket später von einem anderen Clientgerät im selben Netzwerk angefordert, werden Inhaltsinformationen statt des vollständigen Inhalts vom Server heruntergeladen. Die Inhaltsinformationen werden verwendet, um den gewünschten Inhalt auf anderen Geräten im Netzwerk zu lokalisieren. **Client-Peer-Ermittlung** im „Distributed-Cache-Modus“ funktioniert wie folgt: * Ein Client sendet eine Multicast-Anfrage wie „Hat jemand die Content-ID XYZ?“ * Jeder Peer, der das angeforderte Segment enthält, antwortet direkt per Unicast. Anstatt Pakete vom Server herunterzuladen, wird der Inhalt in Form der aufgesplitteten Chunks an 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 auf Microsoft Learn: [BranchCache](https://learn.microsoft.com/en-us/windows-server/networking/branchcache/branchcache) ### RealmJoin-Verbindungsendpunkte RealmJoin verbindet sich über HTTPS mit den folgenden Hosts, die in Ihren Firewall-Einstellungen berücksichtigt werden können: * `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) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.realmjoin.com/de/bereitstellung/infrastructure.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.