Baramundi, VPN vs. IEM?
Hallo erstmal an alle hier im Forum,
als blutiger Anfänger in Sachen baramundi ist die Lernkurve recht steil.
Ich habe mal eine Frage, welche mich bei der Planung eines baramundi PoC beschäftigt.
Folgende Konstellation:
Meine eigentliche Frage ist, wie sollte man nun die Anbindung der Kunden (DIP) vornehmen.
Ich hätte jetzt als erstes an ein VPN gedacht, habe dann aber über das baramundi IEM gelesen und frage mich nun worin die Unterschiede sowie vor/Nachteile bestehen.
Hat vielleicht jemand Erfahrungen mit baramundi?
als blutiger Anfänger in Sachen baramundi ist die Lernkurve recht steil.
Ich habe mal eine Frage, welche mich bei der Planung eines baramundi PoC beschäftigt.
Folgende Konstellation:
- Es sollen zukünftig via baramundi mehrere Kundenumgebungen mit Microsoft Updates versorgt werden.
- Die Kunden haben keine eigenen baramundi-installationen, sondern sollen jeweils nur via DIP angebunden werden.
- Im Rechenzentrum steht dafür dann baramundi Server, Management und SQL Datenbank bereit (man könnte jetzt auch sagen, baramundi in der Cloud. Am Ende aber nichts anderes wie in Firmenstrukturen mit mehreren Standorten)
Meine eigentliche Frage ist, wie sollte man nun die Anbindung der Kunden (DIP) vornehmen.
Ich hätte jetzt als erstes an ein VPN gedacht, habe dann aber über das baramundi IEM gelesen und frage mich nun worin die Unterschiede sowie vor/Nachteile bestehen.
Hat vielleicht jemand Erfahrungen mit baramundi?
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 1414660744
Url: https://administrator.de/forum/baramundi-vpn-vs-iem-1414660744.html
Ausgedruckt am: 23.12.2024 um 05:12 Uhr
7 Kommentare
Neuester Kommentar
Ich arbeite seit einigen Jahren in der Firma mit baramundi und betreue da auch mehrere Standorte mit. Allerdings nutzen wir baramundi etwas anders, als es empfohlen ist, von daher ist dieser Kommentar primär ein Erfahrungsbericht als ein zielgerichteter Beitrag zu deinem Problem.
Wir haben bei jedem Standort DIPs eingerichtet, nutzen allerdings nicht den baraDIPsync-Dienst. Die Kollegen in den anderen Niederlassungen nutzen zum Teil nur einige der Programme wie an unserem Hauptstandort und unsere Direktverbindungen zwischen den Standorten eignen sich nicht so sehr, um darüber mehrere GB an Daten abzugleichen. Daher kopieren wir die neuen Programme für die Standorte quasi händisch rüber. Falls in deinem Fall die Standorte gut untereinander verbunden sind, solltest du dir den Sync durchaus anschauen.
Bei IEM läuft alles über die reguläre Internetanbindung via https . Je nach Netzwerkkonfiguration ist der Internetgateway bei jedem Standort sowohl für die Clients als auch die Serveranbindungen derselbe oder unterschiedlich.
Falls du also eine Direktverbindung der Standorte einrichten kannst, die nicht über das Internet geroutet wird, dann nutze ruhig den DIP-Sync mit untereinander erreichbaren Standort-Netzwerken.
Wenn aber nur Internet zur Verfügung steht, wirst du nicht um IEM herumkommen.
Zu den Microsoft Updates empfehle ich dir persönlich, einen dedizierten WSUS bereitzustellen und die Clients auf diesen zu konfigurieren. Du kannst dann aber baramundi für das Reporting verwenden, da du über spezielle Jobs dann den Updatestand von Clients wahlweise mit Windows Update oder einem konfigurierten WSUS abgleichen kann. In jedem Fall nimmt baramundi bei Ausführung über den jeweiligen Client Kontakt zur Updatequelle auf, mit der sich der Client auch verbindet und führt dort den Abgleich durch.
Im Ergebnis siehst du dann in baramundi für jeden Client alle verfügbaren Updates und deren jeweiliger Status (installiert/fehlend/verzögert/...).
Baramundi bietet zwar selber auch eine Möglichkeit, als Updatequelle zu fungieren. Wir hatten das auch zuerst eingesetzt, allerdings haben die ein komplett eigenes Benennungsschema ausgedacht, wodurch du erst nach einigen Klicks herausfindest, welches KB das eigentlich ist. Außerdem bremst auch das den Server aus, wenn baramundi nicht nur Software und Konfigurationen verteilt, sondern auch noch die Updateverteilung komplett übernimmt. Das würde auch vor allem bei mehreren Standorten noch komplexer werden, da die Updates dann alle vom primären DIP verteilt werden, bzw. bei Einrichtung des DIP-Sync würde das zusätzlich die Verbindung belasten.
Wir haben bei jedem Standort DIPs eingerichtet, nutzen allerdings nicht den baraDIPsync-Dienst. Die Kollegen in den anderen Niederlassungen nutzen zum Teil nur einige der Programme wie an unserem Hauptstandort und unsere Direktverbindungen zwischen den Standorten eignen sich nicht so sehr, um darüber mehrere GB an Daten abzugleichen. Daher kopieren wir die neuen Programme für die Standorte quasi händisch rüber. Falls in deinem Fall die Standorte gut untereinander verbunden sind, solltest du dir den Sync durchaus anschauen.
Bei IEM läuft alles über die reguläre Internetanbindung via https . Je nach Netzwerkkonfiguration ist der Internetgateway bei jedem Standort sowohl für die Clients als auch die Serveranbindungen derselbe oder unterschiedlich.
Falls du also eine Direktverbindung der Standorte einrichten kannst, die nicht über das Internet geroutet wird, dann nutze ruhig den DIP-Sync mit untereinander erreichbaren Standort-Netzwerken.
Wenn aber nur Internet zur Verfügung steht, wirst du nicht um IEM herumkommen.
Zu den Microsoft Updates empfehle ich dir persönlich, einen dedizierten WSUS bereitzustellen und die Clients auf diesen zu konfigurieren. Du kannst dann aber baramundi für das Reporting verwenden, da du über spezielle Jobs dann den Updatestand von Clients wahlweise mit Windows Update oder einem konfigurierten WSUS abgleichen kann. In jedem Fall nimmt baramundi bei Ausführung über den jeweiligen Client Kontakt zur Updatequelle auf, mit der sich der Client auch verbindet und führt dort den Abgleich durch.
Im Ergebnis siehst du dann in baramundi für jeden Client alle verfügbaren Updates und deren jeweiliger Status (installiert/fehlend/verzögert/...).
Baramundi bietet zwar selber auch eine Möglichkeit, als Updatequelle zu fungieren. Wir hatten das auch zuerst eingesetzt, allerdings haben die ein komplett eigenes Benennungsschema ausgedacht, wodurch du erst nach einigen Klicks herausfindest, welches KB das eigentlich ist. Außerdem bremst auch das den Server aus, wenn baramundi nicht nur Software und Konfigurationen verteilt, sondern auch noch die Updateverteilung komplett übernimmt. Das würde auch vor allem bei mehreren Standorten noch komplexer werden, da die Updates dann alle vom primären DIP verteilt werden, bzw. bei Einrichtung des DIP-Sync würde das zusätzlich die Verbindung belasten.
Jetzt im Nachhinein stellt sich mir auch die Frage, ob du baramundi nur zur Updateverteilung einsetzen willst oder auch für die Verteilung von Software und Konfigurationen. Denn vor allem das zweite ist die große Kernkompetenz von baramundi, Updates sind da eher nice-to-have. Wenn du da also baramundi nur wegen der Updates einführen willst, ist das IMHO mit Kanonen auf Spatzen zu schießen. Dann lieber jedem Standort einen WSUS spendieren.
Klar, bei solchen komplexen Abhängigkeiten hilft der WSUS einem nicht wirklich weiter. Und ich will baramundi das Patchmanagement auch nicht schlecht reden, denn es funktioniert durchaus recht gut.
Unsere Anforderungen waren da wesentlich flacher, da war uns das mit baramundi etwas zu unübersichtlich.
Unsere Anforderungen waren da wesentlich flacher, da war uns das mit baramundi etwas zu unübersichtlich.
Moin,
Gruß,
Dani
Ich könnte mir in diesem Fall also vorstellen einfach Site-to-Site VPN zum Kunden aufzubauen.
frag doch einmal deine Kunden, ob das überhaupt möglich ist. Könnte mir gut vorstellen, dass der eine oder andere kein VPN Tunnel möchte oder umsetzen kann. Daher beziehe deine Kunden ein bevor du überhaupt über eine Umsetzung nachdenkst.Gruß,
Dani