s.k.

Hi, Also ich hab jetzt nicht wirklich verstanden, was Du erreichen möchtest, aber ich vermute, dass es Dir generell um zentrale Administrierbarkeit geht. Für letzteres gibt es bei Sonicwall das GMS. Siehe E-Class Lösungen - Richtlinien und Verwaltung - SonicWALL, Inc. Gruß s.k.

Hallo, So richtig hast Du es scheinbar noch immer nicht verstanden. Die CA hat doch überhaupt keinen Einfluss darauf, wer ihr per Default vertraut. Dieses (Vorschuß-)Vertrauen muss sie sich erst verdienen! Wenn einer CA aufgrund wirtschaftlicher oder politischer Einflussnahme grundsätzlich vertraut würde, böte dies aufgrund der Mißbrauchsmöglichkeiten berechtigter Weise Grund für Verschwörungstheorien...Jeder kann eine CA aufmachen und anderen Zertifikatsdienste verkaufen. Erst Ihre Marktdurchdringung/Bekanntheit, ggf. ihre öffentliche Akkreditierung, ihre Policy und vorallem Ihr Verhalten sollte dazu führen, dass sie von verbreiteten Systemen als bekannt und grundsätzlich vertrauenswürdig eingestuft wird. Dein Fehler war also, sich bei der Auswahl der CA nicht über deren Akzeptanz informiert zu haben! Schön wäre es! Das Debian-Debakel hat uns doch u.a. knallhart vor Augen geführt, dass dies in der Regel eben nicht der Fall ist. Siehe Im Zugzwang | heise SecuritySpätestens mit diesem Umstand fällt die Vertrauenswürdigkeit das "Zertifikatsbusiness" wie ein Kartenhaus in sich zusammen. Die einzige CA, der man vertrauen darf, ist eigentlich die eigene... Gruß Steffen

Hallo, Da Deine Tolopogie offenbar gänzlich verschieden ist, erscheint es mir wenig hilfreich, diesen Thread zu kapern! Ohne wirst Du nicht weit kommen.Zu Fragen der Cisco-Konfiguration solltest Du besser einen Thread im Cisco-Subforum erstellen. Gruß s.k.

@michlG: In dem von Dir genannten Link ist von AD weit und breit nichts zu sehen. Da wird einfach per Radius (IAS) gegen die lokale Benutzerdatenbank des WHS authentifiziert. Sofern die EULA das Nachinstallieren und Nutzen des IAS nicht ausdrücklich untersagt, dürfte das lizenzrechtlich in Ordnung sein. Gruß s.k.

Hallo Gerre, Das Kopieren erfolgt von WLAN zu WLAN? Dann rechnen wir mal... Der Router kann zwar WLAN nach dem N-Standard mit einer theoretischen Bruttodatenrate von 300MBit/s, die Funkzelle schaltet jedoch mind. auf "G" mit max. 54MBit/s brutto herunter, da sich mind. ein G-Client in die Zelle eingebucht hat. Die praxistypische Nettodurchsatzrate liegt in diesem Modus unter guten Bedingungen bei ca. 20-22Mbit/s. Siehe Wireless Local Area Network ? Wikipedia Da sich zwei in die selbe Funkzelle eingebuchte Clients miteinander "unterhalten" und die Funkzelle ein shared Medium ist, halbiert sich dieser Wert auf ca. 11MBit/s. Das ist der Wert, der realistischer Weise beim Datentransfer zwischen den beiden WLAN-Stationen zu erzielen ist. Dein letzter Messwert: 1,4MByte/s mal 8 Bit ergibt: 11,2 MBit/s ... :eek: :shock: ... :D :cool: Gruß Steffen

Das bezieht sich auf die Online-Angebote "live@edu" - nicht auf die Softwarelizenzen. Niemand wird gezwungen, live@edu zu nutzen - genauso wie man die anderen Datenkraken wie Google & Co nicht nutzen musss. Gruß Steffen

Nicht alle. Siehe LDAP://Yusufs.Directory.Blog/ - Die Infrastrukturmaster der Anwendungsverzeichnispartitionen Gruß Steffen

Hallo, Also ehrlich, wenn ein Lieferant nicht in der Lage wäre, mir das Gerät den Anforderungen meiner Umgebung entsprechend vorkonfiguriert anzuliefern, dann wäre allein das schon der Grund, den Automaten nicht zu kaufen. :mad: Nun zu Deinem Problem: An Eurer Umgebung würde ich nur wegen einer Teststellung rein gar nichts ändern. Schon gar nicht "Hals über Kopf" eine neue Firewall kaufen, ohne vorher die Anforderungen genau spezifiziert zu haben! Wenn der Automat nicht mit einer passenden IP-Adresse kommt, dann muss sie halt passend gemacht - sprich: übersetzt ("genattet") - werden. Also einfach einen NAT-Router zwischen Eurer Netz und den Automaten schalten und "aus die Maus". :D Ohne NAT ginge es freilich auch, dann ist allerdings das Eintragen einer (Rück-)Route im Netgear erforderlich. Der benötigte zusätzliche Router kann ein 20EUR Heim-Router sein oder ein ausrangierter PC mit Windows, Linux oder einer der vielen vorgefertigten Firewalldistries (z.B. m0n0wall, pfSense). Selbstverständlich muss der Automat die Router-IP als Standardgateway sowie einen erreichbaren DNS-Server eingetragen haben bzw. diese Änderungen müssen möglich sein. Dies gilt aber in jedem denkbaren Lösungszenario... Gruß Steffen

Hallo, da das Lesen dieses Threads mir gerade ein Déjà-vu bereitet hat, hab ich mir mal erlaubt, die FoSu zu quälen. Und siehe da: http://www.mcseboard.de/active-directory-forum-79/probleme-replikation-gpos-vpn-156634.html http://www.mcseboard.de/windows-server-forum-78/verdrehungen-domaene-148031.html http://www.mcseboard.de/windows-server-forum-78/userenv-1053-a-156581.html Viel scheint in verstrichenen Zeit ja nicht erreicht worden zu sein. :rolleyes: Insbesondere vor dem Hintergrund dieser Threads würde ich nicht - wie von Satan offenkundig gewünscht - unbedingt sofort mit dem Finger auf den Firewalladmin zeigen. Selbstverständlich könnte es (zumindest auch) an instabilen oder ausgelasteten Internetzugängen, an fehlerhaften passiven und aktiven Komponenten oder an einer nicht optimal aufeinander abgestimmten Konfiguration der VPN-Endpunkte liegen. Wahrscheinlicher erscheint mir jedoch, dass Design- und Implementierungsfehler im Windows/AD- und Applikationsumfeld für die genannten Probleme verantwortlich sind. An unserer USG300 terminieren die VPN-Tunnel für derzeit knapp 40 Standorte mit Endgerätezahlen zwischen 2 und 40 Clients. Die meisten Firewalls unserer Außenstellen sind wie die ZW2Plus im vorliegenden Thread (noch) ZyNOS-basiert. Und dennoch läuft hier alles perfekt. Ich käme allerdings auch nie auf die Idee, über die VPN-Tunnel den Außenstellen einen Fileserverzugriff per CIFS bereitzustellen. Dafür ist das Protokoll zu ineffizient und reagiert zu nikelig auf hohe Latenzen. Bei den typischen Internetbandbreiten verdirbt dies dem User nun wirklich jeglichen Spaß an der Arbeit. Soetwas hält man besser lokal oder greift per TS darauf zu. Im Wesentlichen gehen bei uns über die VPN-Tunnel nur Protokolle für Infrastrukturdienste (DNS, LDAP etc.) und Replikationsverkehr. An Kleinstandorten ohne eigenen DC halt Anmeldeverkehr (ohne servergespeichertes Profil) und ICA (Seamless Applications). Auf diese Weise habe ich auch im vollem Betrieb nur wenig Traffic auf den Tunneln und auch konstante Pingzeiten von um die 30ms zu allen Außenstellen. Wenn ich aber abends gelegentlich "dicke" Installationsdateien für unsere Softwareverteilung rüberschiebe, dann habe ich selbstverständlich auch hohe und schwankende Ping-Zeiten sowie Timeouts. Wenn sich Clients von Kleinstandorten über ein Site-to-Site-VPN an einen entfernten DC anmelden sollen, muss man halt beachten, dass diese 1. den richtigen DNS-Server verwenden und 2. die Erkennung langsamer Verbindungen abgeschaltet ist. Aber diese Hinweise sind ja in den obigen Threads bereits gegeben und hoffentlich beachtet worden... Wie LukasB würde ich dennoch zunächst damit beginnen, durch Messungen zu Leerlaufzeiten (z.B. mit Netio) sowie durch entsprechendes Firewallmonitoring die Verbindungsqualität und -kapazität über die Tunnel hinweg zu ermitteln. Erst wenn man diese mögliche Ursache ausgeschlossen hat, würde ich mich der Fehlersuche auf höheren Layern zuwenden. Möglicherweise wäre es auch erhellend, auf der USG ein Trafficcapture zu ziehen und mit Wireshark auszuwerten. Da sieht man dann mal im Detail, wer mit wem was spricht... Gruß Steffen

Hallo EvoIT, mein Statement bezog sich lediglich auf die sehr generalisierte Aussage von Gulp. In Deinem Fall ist die Konstellation eine etwas andere: Die VPN-Tunnel terminieren am Windows-Server - nicht am Lancom-Router. Demzufolge kann der Lancom - genau wie die Router im Internet - nicht das Problem sein, weil er ohnehin nur Unicast-Pakete mit verschlüsseltem Payload sieht. Auch der Windows-Server fungiert hier - bezogen auf die Kommunikation zwischen LAN und VPN-Clients - nicht als Router, denn die VPN-Clients erhalten ja eine IP-Adresse aus dem LAN-Subnetz zugewiesen. Er verhält sich aber auch nicht wie eine normale Bridge. Ich hatte das vor Jahren mal mit einem Win2000 Server näher untersucht: Die VPN-Clients werden im LAN auf Layer 2 mit der Mac-Adresse des VPN-Servers angesprochen - der Server macht also für die VPN-Clients ProxyARP. Lange Rede, kurzer Sinn - konkret bedeutet dies, dass es nur 2 denkbare Fehlerquellen gibt: 1. das WOL-Paket geht Client-seitig nicht den Weg in den Tunnel 2. der Server leitet das WOL-Paket nicht wie gewünscht weiter Um ersteres auszuschließen, habe ich soeben von meinem Notebook mit XPpro einen L2TPoverIPSec-Tunnel zur Firewall in meinem HomeOffice aufgebaut und testweise mit verschiedenen Tools Magic Pakets durchgeschickt. Im Firewall-Log konnte ich alle erzeugten Pakete sehen - und zwar sowohl limited als auch directed brodcasts. Demzufolge kann es nur am Windows-Server liegen! Nun müsste nur noch geklärt werden, ob und ggf. wie man dessen diesbezügliches Verhalten abweichend steuern kann. Auf die Schnelle hab ich leider nichts ergoogeln können... Gruß Steffen

Diese Aussage stimmt so einfach nicht. Mit einem WOL-Tool, welches directed broadcasts erzeugt, geht es sehrwohl. Das Problem ist nur, dass heutzutage die meisten Router diese Pakete aus Sicherheitsgründen (zumindest per default) nicht mehr weiterleiten.Siehe http://www.mcseboard.de/windows-forum-security-47/wake-on-lan-firewall-118655.html Gruß s.k.

Bist Du Dir sicher, dass es sich (ausschließlich) um Echo Requests handelt? ICMP dient dem Austausch einer ganzen Reihe von Informations- und Fehlermeldungen. Vielleicht gibt es in Eurem Netzwerk schlicht ein Problem, welches diesen "Gesprächsbedarf" auslöst?Also bitte den genauen Typ und Code angeben oder den Trafficmitschnitt irgendwo hochladen und hier verlinken! Gruß Steffen

Hallo Edgar, mein vorstehendes Posting hast Du gelesen? Hat sich mit der Antwort von WindowsBetatest überschnitten... Deine Szenarien 1-3 sind m.E. unter Einhaltung Deiner Vorgaben/Rahmenbedingungen (nur) mit den 1700er HPs nicht umsetzbar. Bei Szenario 4 sollte es kein Problem sein, einen NAT-Router für 50EUR dazwischen zu setzen. Gruß Steffen

Hallo Edgar, Möglicherweise weil Dir meine hiesigen Ausführungen noch im Gedächtnis sind?http://www.mcseboard.de/windows-forum-lan-wan-32/richtet-man-vlan-157336.html http://www.mcseboard.de/windows-forum-lan-wan-32/vlan-d-link-dgs-1248t-155307.html Jain:1) Mit einem anderen Switch ginge es sehrwohl auf Layer 2 (siehe oben). Der von Dir eingesetzte HP-Switch kann dies laut Handbuch jedoch nicht. 2) Wenn Variante 1 nicht geht, muss man halt auf Layer3 arbeiten - sprich: die VLANs müssen sich in unterschiedlichen IP-Netzen befinden und dazwischen muss gerouter sowie (um Deinen Anforderungen hinsichtlich Trennung zu entsprechen) per ACL gefiltert werden. Dafür könnte der Router - sofern unterstützt - mit taggt Frames arbeiten. Das spart physische Interfaces. Kann er dies jedoch nicht, muss er mit je einem physischem Interface mit beiden VLANs (untaggt) verbunden sein. Sollte der vorhandene Router weder das eine noch das andere hergeben und eine Neuerwerbung keine Option sein, könntest Du auf pfSense, M0n0wall & Co zurückgreifen. Gruß Steffen

Ersteres.Autonegotiation ist ein Verfahren zur Erkennung und Aushandlung von Linkspeed und Duplexmode. Wenn man die Parameter fest einstellt, findet kein Autonegotiation mehr statt. Da dies bei 1000Base-T jedoch zwingend erforderlich ist, kann man die Einstellungen für Gigabit im Umkehrschluß auch nicht fest vornehmen. Es ist also ganz normal, dass Du diese Einstellung nicht angeboten bekommst. Bevor der Einwand kommt: Freilich gibt es Switches und z.T. auch (Server-)NICs, welche eine Einschränkung auf z.B. nur Gigabit zulassen. Hier wird jedoch nicht "hartverdrahtet", sondern es erfolgt weiterhin Autonegotiation - nur das Verhalten bei der Aushandlung ändert sich. Diese Geräte offerieren und akzeptieren bei der Aushandlung nur die vom Admin vorgebenen Einstellungen (ggf. halt nur eine). Gruß s.k.

Daran, dass 1000BaseT nach Spezifikation zwingend Autonegotiation voraussetzt/erfordert. Gruß Steffen

Hallo, Diese Konfig würde ich in diesem Fall nicht wählen. Hier ist eher KB-3018 einschlägig (Finger weg von den Wizards!). Auf einer Seite ist mangels fester IP-Adresse natürlich mit einem DynDNS-Service zu arbeiten. Bei gegenwärtigem Firmwarestand ist es das "A und O", daran zu denken, dass der Traffic zusätzlich per Policyroute in den Tunnel geschoben werden muss. Das vergessen die meisten Ein- oder Umsteiger. Q2/Q3 kommt ZLD2.2x - da ist dies dann nicht mehr (zwingend) erforderlich. Neben einer neuen, Ajax-basierten GUI und vielen weiteren Verbesserungen, wurde auch der gesamte Packet Flow tiefgreifend überarbeitet... ;) Gruß Steffen

Naja, die eigentliche Kernfrage war m.E.: Daraus habe ich implizit herausgelesen, dass die Besucher ihre eigenen mobilen Geräte verwenden. Des Weiteren nahm ich an, dass die Gäste nach Möglichkeit nicht nur zeitlich eingeschänkten Zugang, sondern auch keinen oder zumindest reglementierten Zugriff auf interne Ressorcen haben sollten. Vielleicht kann ja Thomas seine Anforderungen nochmal genauer darlegen... ;) Gruß Steffen

Hallo Zahni, Radius allein ist keine Lösung, sondern stets nur ein Element dessen - auch in Deinem Link. Dort geht es - wenn ich das richtig überflogen habe - um 802.1X mit (P)EAP. Beim Einsatz von verwalteten Notebooks ist das klasse, jedoch für Notebooks von Dritten aufgrund der clientseitig erforderlichen Einstellungen m.E. nur bedingt zu gebrauchen. Siehe diese Diskussion: http://www.mcseboard.de/government-53/laptop-schulnetz-155880.html Um Gästen einen zeitlich befristeten (Internet-)Zugang zu verschaffen, ist ein nicht oder nur mäßig gesichertes WLAN mit zusätzlicher webbasierter Authentifizierung sowohl für den Admin als auch den Gast der einfachste und zweckmäßigste Weg. Nicht umsonst funktionieren alle Hotspots auf diese Weise. Auch hier kann fürs AAA natürlich Radius verwendet werden. An unserem Gymnasium docken wir die Webauthentifizierung beispielsweise über einen IAS ans AD des pädagogischen Netzes an, damit der dortige Informatiklehrer die Accounts fürs WLAN verwalten kann. Gruß Steffen

Hallo Thomas, Dir auch frohe Weihnachten! MultiSSID- und VLAN-Unterstützung sollte heutzutage eigentlich jeder halbwegs brauchbare Accesspoint können.Das von mir dargestellte Szenario haben wir an unseren städtischen Schulen realisiert. Dort sind die Kosten natürlich ein dominierendes Kriterium. Wobei ich hierunter nicht nur die Anschaffungs-, sondern vorallem auch die Implementierungs- und Folgekosten subsummiere. Um die Gebäude und den Campus jeweils weitgehend komplett auszuleuchten, benötigen wir zwischen 5 und 20 APs pro Schule. Für einfaches Roullout und zentrale Administration suchten wir deshalb von Anfang an nach einer Controller-Lösung. Nach einigen Teststellungen und auch zwei Produktivinstallationen mit Aruba/Netgear und Lancom haben wir uns letztendlich wieder für Zyxel entschieden (NWA-3160/3166/3500). Diese Geräte bieten zwar nicht die Funktions- und Debugtiefe professionellerer Geräte, sind dafür aber sehr einfach zu administrieren, sehr preiswert und erfüllen dennoch unsere funktionalen Anforderungen. Ich schrieb "wieder", weil wir bereits seit Jahren an den Schulen die Firewalls von Zyxel ("ZyWALL") einsetzen. Die Switches müssen natürlich VLAN nach dot1q unterstützen.Firewallseitig gibt es normalerweise keine besonderen Anforderungen, weil die meisten WLAN-Controller-Lösungen die vorgeschlagene webbasierte Authentifizierung bereits integriert haben. Wir machen es halt an der Firewall, weil die genannten Zyxel-APs dies leider nicht können. Stattdessen routen wir den Traffic der Gäste-WLANs komplett über VPN ins Rathaus und dort über eine Zywall USG, welche Captive Portal und Contentfilter bereitstellt, ins Internet. Wenn Du eine Lösung ohne Controller wählst, wirst Du die webbasierte Authentifizierung vermutlich ebenfalls auf andere Weise realisieren müssen. Sofern die vorhandene Firewall dies nicht bereits bietet, lohnt ein Blick auf die kostenfreien Firewall-Distries M0n0wall und pfSense. Nett ist auch die Lösung "G-4100" von Zyxel: Da ist ein kleiner Bondrucker dabei, mit dem man einfach auf Knopfdruck einen Ausdruck mit (zeitlich eingeschränkten) Zugangsdaten erzeugt und dem Gast aushändigt. Gruß Steffen

Hallo Thomas, Wir verwenden Accesspoints mit Multi-SSID-Unterstützung. Die Gäste buchen sich halt in ein separates (logisches) WLAN ein. Je nachdem, aus welchem WLAN man kommt, taggt der Accesspoint die Frames zum kabelgebundenen Netzwerk hin mit unterschiedlichen VLAN-IDs, so dass die Switching-Infrastruktur Freund und Feind unterscheiden kann. Das Gäste-VLAN wird bis zur Firewall geführt. Diese gestattet den (Internet-)Zugriff aber erst nach vorheriger Authentifizierung des Benutzers (Captive Portal). Die entsprechenden User-Infos werden momentan noch auf der Firewall gepflegt - kann man aber auch per Radius oder LDAP aus einer externen Quelle holen. So könnte man das Ganze auch mit OTP-Token kombinieren. Gruß Steffen

Geht es nun konkret (und ausschließlich) um die Installation vom Adobe Reader?Dafür gibt es von Adobe den Customization Wizard, welcher ein MST gemäß den eigenen Präferenzen erstellt. Die Deinstallation von Vorversionen ist eine mögliche Option. Siehe Adobe - Acrobat Developer Center - Enterprise deployment Gruß sk

Aber nicht den Weg über ein eingebettetes Skript, oder? :confused: An das MST-File werden keine Parameter übergeben. Ein MST-File enthält lediglich die gewünschten Änderungen gegenüber einem Ausgangs-MSI-File. Bei der Installation werden das MSI und das MST gemeinsam angewendet und ergeben so den gewünschten Zustand. Das "T" in MST steht für "Transform"! Hier ist beschrieben, wie man dies per Skript oder per Gruppenrichtlinie anwendet: Admins-Tipps.net - Anleitungen für ein Unattended-Setup des Adobe Acrobat Reader 6.01 Und hier findest Du übrigens den Schalter fürs Logging, wonach Du ja in einem anderen Thread gefragt hast: http://www.winfaq.de/faq_html/Content/tip2000/onlinefaq.php?h=tip2032.htm Das MST-File kann man selbst erstellen - z.B. mit Orca oder dem bereits genannten Advancedinstaller. Viele Hersteller liefern auch gleich ein produktspezifisches Tool mit, womit man sich komfortabel ein MST-File entsprechend seinen Wünschen erstellen kann. Statt ein MST zu verwenden, könnte man sich alternativ auch ein neues MSI-File mit den gewünschten Änderungen basteln, denn in einem MSI-File kann man - wenn man weiss, was man tut und die richtigen Tools verwendet - nach Herzenzlust herumeditieren. Gruß sk

Aus meiner Sicht _ist_ das eine Verteilung über GPO, denn den SSS-Interpreter startest Du sinnvoller Weise über eine Gruppenrichtlinie bei Start des PCs. Insofern wäre der Auftrag erfüllt... ;) Mit Advanced-Installer (Free Windows Installer - MSI Installer Tool) kann man MSIs bauen und darin über "custom actions" zu gewissen Zeitpunkten z.B. ein Batch-Skript an die cmd.exe übergeben. Andere Tools sollten das eigentlich auch können.In Spezialfällen ist ein solches Vorgehen sicherlich sinnvoll. Ich nutze dies beispielsweise bei einigen Paketen, um nach der Deinstallation Verzeichnisse/Dateien zu löschen, die sonst verwaist übrig bleiben würden, weil sie erst bei Nutzung des Programms erzeugt werden und deshalb dem (De)Installer nicht bekannt sind. Für Dein Anliegen erscheint mir dieser Weg aber generell nicht sinnvoll, weil zu aufwändig. Schließlich muss dies für jedes Programm individuell programmiert und ins MSI eingebaut werden. Wenn man das ordentlich machen möchte (Berücksichtigung ggf. diverser Eventualitäten, Auswertung der Returncodes etc.), ist dies nicht mehr ganz trivial! Mich würde interessieren, ob Dein "Auftraggeber" bereits für sich diesen Weg so geht (Einbau ins MSI-File) und Du nun durch Eigenrecherche auf die gleiche Lösung kommen sollst oder ob er Dich auf einen Weg angesetzt hat, von dem er lediglich glaubt, dass er exisitent und geeignet wäre. Ich vermute letzteres. Wenn dem so ist, würde ich ihm die (m.E. besseren) Alternativen zumindest auch aufzeigen. Sollte hingegen ersteres der Fall sein, dann wäre es schön, wenn Du nach Auflösung des Rätsels an dieser Stelle darüber berichten würdest. Gruß Steffen

Hallo, worum muss das Prüfen auf Vorversionen, Deinstallation usw. ins MSI-File integriert werden? Ist es nicht sinnvoller, die "Softwareverteilung" übernimmt diesen Part? Was für eine Softwareverteilung nutzt ihr denn? Gruß Steffen Nachtrag: ok. Hab jetzt Deine vorhergehenden Threats gelesen. Offenkundig habt Ihr keine professionelle SW-Verteilung im Einsatz, sondern verteilt MSIs per GPO. Vermutlich wollt oder könnt Ihr - wie wir - dafür kein Geld in die Hand nehmen. Weil ich spezielle Anforderungen habe und es auch gerne einfach mag, nutzen wir das freie "Smart Software Synchronisation" (http://www.smart-software-synchronisation.de/index.php/Hauptseite), für dessen Bedienung wir eine eigene Weboberfläche programmiert haben. Vielleicht ist SSS ja auch etwas für Euch? Damit kann man problemlos auf vorhandene Installationen prüfen, Vorversionen automatisch deinstallieren, Abhängigkeiten zwischen Softwarepaketen definieren und vieles mehr. Die Erstellung von Log-Files ist natürlich auch dabei. Es gibt zwar wesentlich mächtigere und dennoch kostenfreie Opensource-Lösungen als SSS (z.B. OPSI, OCS oder das sehr ähnliche WPKG), aber m.W. nichts was so genial einfach ist.