phatair
-
Gesamte Inhalte
505 -
Registriert seit
-
Letzter Besuch
Beiträge erstellt von phatair
-
-
vor 4 Minuten schrieb NilsK:
keine Sammel-Accounts für die Administration. Niemals. Auch keine Sammel-Accounts für Dienste. Alles, was hohe Berechtigungen braucht, wird mit personalisierten bzw. dedizierten Accounts gemacht. Diese Accounts sind nur für die administrative Arbeit bzw. zur Anmeldung von Diensten, für nichts anderes. Jeder Admin hat separat einen normalen User-Account für die alltägliche nicht-administrative Arbeit.
So machen wir das auch bei den Clients, nur muss das jetzt noch auf die Server ausgeweitet werden.
Dienste sind auch alle mit separaten Accounts versehen (beginnen z.B. immer mit svc-<name des dienstes>
vor 4 Minuten schrieb NilsK:Domänen-Admins nur zum Verwalten der Domäne, also nur in Ausnahmefällen. Auch die normale User-Administration oder das Aufnehmen von Rechnern ins AD braucht keine Dom-Admin-Rechte.
Wir haben die personalisierten Admin Accounts berechtigt bestimmte Dinge in den ausgewählten OUs zu machen (z.B. Objekte zu löschen oder PCs aufzunehmen). Das müsste hoffentlich passen.
-
vor 22 Minuten schrieb testperson:
schau dir das (und den Link dort) mal an: https://www.mcseboard.de/topic/214871-admin-für-software-installation-client-pcs/?do=findComment&comment=1371787
In die entsprechenden Gruppen packst du dann die personalisiertern Admin (oder Sammel) Accounts.
Das klingt sehr interessant - werde ich mir mal genauer anschauen. Danke für den Tip!
vor 23 Minuten schrieb testperson:P.S.: LAPS kann man machen, muss man aber nicht. LAPS speichert die Kennwörter halt im Klartext im AD. Ggfs. ist AdmPwd.E (https://www.admpwd.com/) eine Alternative.
Hm...heißt das, jeder der lesenden Zugriff auf das AD hat kann die Passwörter auslesen? AdmPwd.E klingt auch interessant und ist preislich auch fair. Werde ich mir auch mal anschauen. Das Programm scheint sich in die AD einzuklinken - ändert das auch was am AD Schema oder kann das Probleme beim AD Upgrade machen?
vor 21 Minuten schrieb RolfW:Ihr habt nur ein AD und eine Firma?
Ja, wir haben nur eine AD/Domäne.
vor 25 Minuten schrieb RolfW:Ich würde für jeden Admin ein persönliches Konto erstellen und für die Workstation einen generellen Admin, der lokal Admin ist, aber in der Domäne nur Benutzer. Wenn Du dann noch möchtest, könntest Du für die DomAdmins noch einzelne persönliche Konten erstellen.
So ähnlich haben wir es eben für die PCs gemacht. Jeder Admin hat einen normalen Account und einen Account der auf den PCs in der lokalen Admin Gruppe ist. Einen generellen Account haben wir nicht, damit es besser nachvollziehbar ist, wer was gemacht hat. Die Frage ist, ob dann für ausgewählte Kollegen ein persönlicher Domänen Admin Account erstellt wird oder wir hier den Standard Domänen Admin verwenden.
-
Guten Morgen,
ich möchte bei uns in der Firma die Verwaltung der Admin Accounts überarbeiten.
Im Moment arbeitet die IT Abteilung mit 2 Accounts ( einen normalen Benutzer Account für die tägliche Arbeit und einen Admin Account der nur genutzt wird, wenn erhöhte Berechtigungen verwendet werden).
Beides sind AD Accounts.
Wir haben uns bei der Verwaltung der Admin Accounts bei den PCs an dem Beitrag vom Mark orientiert (https://www.gruppenrichtlinien.de/artikel/verwaltung-der-lokalen-administratoren/)
Auf allen PCs werden per GPO die Mitglieder aus der lokalen Administratoren Gruppe geschmissen und eine "Workstation-Admin" Gruppe hinzugefügt. In dieser sind dann die Admin Accounts der IT Abteilung.
Somit können wir mit unseren Admin Accounts alles an den PCs machen, benötigen keinen Domänen Admin und es ist sichergestellt das auch sonst kein anderer Admin vorhanden ist.
Auf den Servern sieht es im Moment noch anders aus. Hier arbeiten wir immer mit dem Domänen Admin Account. Das würde ich aber gerne ändern, da auch hier keine Notwendigkeit besteht.
Nun könnte ich das genau so durchführen. Wir fügen auf den Servern eine weitere Gruppe (z.B. Server-Admins) der Administratoren Gruppe hinzu. Alle darin enthaltenen Admins können auf den Servern arbeiten.
Bisher war es oft so, dass bestimmte Programme offen waren und jeder Admin diese gleich nutzen konnte. Das würde dann natürlich wegfallen, da jeder mit seinem eigenen Account arbeiten würde.
Die andere Lösung wäre, man erstellt z.B. einen Server Admin Account und dieser wird auf allen Servern in die Administratoren Gruppe aufgenommen und man arbeitet mit diesem.
Die lokalen Administratoren Accounts möchte ich über Microsoft LAPS verwalten. Das Passwort des Domänen Admin Accounts wird dann nach der Änderung geändert und nur noch für notwendige Tätigkeiten genutzt (von ausgewählten IT Kollegen).
Wie macht ihr das den mit den Servern und den Admin Accounts?
- persönliche Admin Accounts?
- einheitlicher Admin Account?
- lokalen Admin Account?
- andere Lösung?
Vielen Dank schon mal für eure Gedanken.
Gruß
-
Hat wunderbar funktioniert. Danke!
Wenn man keine eigene CA im LAN hat, ist das wahrscheinlich die einzige Möglichkeit interne Web Verbindungen mit einem Zertifikat zu versehen.
Macht es dann Sinn ein Wildcard Zertifikat für lokale Anwendungen zu erstellen oder lasst ihr diese einfach über SelfSigned Zertifikate laufen?
-
Hallo zusammen,
wir haben 2 IIS Server bei uns im LAN laufen. Diese stellen Webdienste zur Verfügung, die ich gerne per SSL absichern möchte.
Wir haben noch keine eigene interne CA und ich sehe in den nächsten Monaten auch keine Kapazität das umzusetzen.
Meine Idee wäre jetzt gewesen, über eine CA wie Geotrust ein SAN Zertifikat zu kaufen. Wir haben eine öffentliche Homepage und diese Domain ist identisch zu unserer internen Domäne (öffentlich domain.de, intern intern.domain.de).
Wenn ich ein SAN Zertifikat auf domain.de ausstelle, kann ich ja dieses Zertifikat für unseren internen IIS verwenden (z.B. server.intern.domain.de).
Seht ihr hier irgendwelche Probleme?
Ich habe auch mit dem Gedanken gespielt, das Ganze über Lets Encrypt zu machen. Aber hier komme ich nicht weiter und mir fehlt die Zeit mich weiter einzulesen.
Wenn das wie oben beschrieben funktionieren sollte, wäre das der schnellere und einfachere Weg (natürlich auch kostenpflichtig).
Vielen Dank schon mal für eure Hilfe.
Gruß
-
Hi Dukel,
danke für den Tip. Ich habe nun für die Default Web Site eine Umleitung festgelegt. Nach einigen Tests funktioniert es jetzt auch.
Ich musste beim Umleitungsverhalten die Option "Anforderungen zu Inhalt in diesem Verzeichnis (nicht in Unterverzeichnissen) umleiten" aktivieren und den Statuscode auf Dauerhaft(301) setzen.
Wenn ich den Haken bei der "Anforderungen zu Inhalt in diesem Verzeichnis (nicht in Unterverzeichnissen) umleiten" nicht setze wird die URL mehrmals hinten angehängt und nichts funktioniert.
Aus http://Anwendung wird dann http://server/Anwendung/Anwendung/Anwendung/Anwendung usw.
Wenn ich die Hilfe zu der Option richtig versehe, wird die Umleitung dann auch für jede Unterordner angewendet.
Verstehe ich jetzt irgendwas komplett falsch oder kann man die Konfig so umsetzen?
-
Hi mwiederkehr,
danke dir. Das Problem ist, die Webseite besteht aus 2 Anwendungspools - kann ich da genau so verfahren?
- Eine neue Webseite erstellen (die benenne ich wie ich möchte)
- Dieser Webseite beide Anwendungspools anhängen
- Bindung für die neue Webseite erstellen und den gewünschten Namen verwenden
- DNS Eintrag erstellen
-
Hallo zusammen,
wir setzen bei uns im internen LAN einen Win Server 2012R2 mit IIS ein. Über diesen wird eine Software für die Fertigung realisiert.
Nun ist diese Software im Moment über die URL http://<Server-Name/Anwendungsname> aufrufbar. Ich möchte aber die Webseite über http://<Anwendungsname> erreichbar machen.
Irgendwie stehe ich auf dem Schlauch und ich bin auch kein großer IIS Experte. Ich komme einfach nicht dahinter wie ich das ändern kann (muss man hier über die Bindungen im IIS arbeiten?).
Ein DNS Eintrag (CNAME) von <Anwendungsname> -> <IP des Servers> funktioniert nicht, da dort nur die IIS Seite erscheint. Ich muss die Webseite zwingenden über <Server-Name>/Anwendungsname aufrufen.
Kann mir jemand einen Tipp geben, wie ich es hinbekommen?
Im Moment sieht es so aus http://server/meine-Anwendung funktioniert. Ich möchte aber die Seite über http://meine-Anwendung aufrufen können.
Vielen Dank schon mal.
Gruß
-
Jep, also es ist so. Auch der Organisator sieht dann im Kalender des Raumpostfaches nur noch den Namen des Organisators.
Den Betreff sieht man nur noch im eigenen Kalender. Macht so ja auch nur Sinn - trotzdem gut zu wissen :)
-
Ich teste das am Montag mal und schreibe das Ergebnis hier rein. Vielleicht interessiert es ja noch jemanden.
-
Jap, dass ist richtig.
Ich bin aber auf dem Heimweg, sitze im Zug und dachte ich Frage einfach mal.
Ich würde auch gerne wissen, ob das der richtige Weg ist. Ich mache sonst nicht viel bei uns am Exchange und sichere mich gerne etwas ab bevor ich irgendwelche Befehle eingebe :)
Wenn ich am Montag keine Antwort habe, teste ich es selber und Antworte mir hier selber ;)
-
Hallo zusammen,
wir verwenden noch Exchange 2010 SP3 und ich würde gerne in den Raumpostfächern den Betreff ausblenden und den Organisator anzeigen lassen.
Nach kurzer Recherche im Internet gebe ich dazu ja folgenden Befehl ein:
Set-CalendarProcessing -Identity <RESOURCEMAILBOX> -DeleteSubject $True -AddOrganizerToSubject $True
Damit würden dann der Betreff durch den Organisator ersetzt werden. Die Standard Berechtigung auf den Raumpostfächern ist "Standard" -> Frei/Gebucht-Zeit, Betreff, Ort
Das müsste dann ja soweit passen.
Den Betreff des Termins sieht dann auch der Organisator nur noch in seinem eigenen Kalender, im Kalender des Raumpostfaches sieht er ihn nicht mehr. Richtig?
Vielen Dank.
Gruß und ein schönes Wochenende!
-
Ok, ich bin mit den Gedanken wohl noch in 2018 - Sorry.
Die Meldung war nicht von Windows, sondern kam von ZenWorks. Wir haben letztes Jahr die Lizenz verlängert und hatten vergessen im System eine Lizenz zu aktualisieren.
Hat sich somit erledigt.
-
Hallo zusammen,
wir imagen bei uns alle neuen PCs mit Windows 10. Bisher wurde hier Windows 10 Pro 1703 verwendet. Es handelt sich dabei um eine VL Pro Version. Das Iso wurde aus dem MS VLSC geladen.
Wir erstellen für die Iso eine unattended.xml, es wird von der ISO+XML gebootet und das Base Image eingerichtet. Danach mit Sysprep finalisiert und ein Base Image erstellt.
Dann wird das ganz mit einem Tool (Novell ZenWorks und Imaging Toolkit) per PXE verteilt.
Die Windows Aktivierung findet über einen KMS statt (Server 2012R2) und der KMS Server + Win 10 Client KMS Key wird im Image verteilt.
Das hat mit der 1703 Version wunderbar funktioniert. Nun mussten wir auf 1803 updaten und dazu wurde wieder ein neues Image für neue PCs erstellt. Gleiches Vorgehen wie bei der 1703 Version.
Das ganze wurde Ende Oktober gestartet und jetzt erhalte ich beim Imagen (und dem ersten Start von Windows) folgende Meldung:
ZitatEvaluation license expired on December 18, 2018.
Program will exit
Warum das auf einmal? Ich dachte durch das Sysprepen wird der Aktivierungszeitraum auf Anfang gestellt und außerdem gebe ich ja im Image den KMS Server + Key mit.
Beim 1703 Image hat das ja auch problemlos funktioniert.
Muss ich auf dem KMS Server noch irgendwas nachziehen? Wir haben bestehende 1703 Win 10 PCs auf Win 10 1803 upgedated und diese werden einwandfrei über den KMS aktiviert).
Ich wüsste nicht das ich irgendeine Evaluierungsversion genutzt habe. Es war die offizielle Win 10 1803 Pro Iso aus dem VLSC.
Für Hilfe wäre ich sehr dankbar. Bin gerade etwas ratlos...
-
Hallo zusammen,
mich würde mal eure Meinung zu folgender "Problematik" interessieren.
Im Moment setzen wir per GPO die Word und Excel Einstellungen so, dass vertrauenswürdige Dokumente und Speicherorte deaktiviert sind.
Alle Dateien die Makros beinhalten, werden mit deaktivierten Makros gestartet und der User muss über den gelben Button erst zustimmte, dass diese ausgeführt werden.
Das muss jedes mal beim öffnen der Dateien gemacht werden, ganz egal ob die Dateien im LAN liegen oder von Extern stammen.
Auf Grund der aktuellen Entwicklung von Emotet usw. werden wir jetzt Makros aus unsicheren Quellen (Internet, Mail Anhang, usw) komplett blockieren, so dass diese Makros gar nicht mehr ausgeführt werden können.
GPO -> Ausführung von Makros in Office-Dateien aus dem Internet blockieren
Weiß jemand, woran Microsoft das fest macht, ob eine Datei aus dem Internet stammt und somit unsicher ist?
Nun versuche ich die ganze Richtlinie etwas zu überdenken.
Macht es vielleicht Sinn die Netzlaufwerke als vertrauenswürdige Speicherorte zu definieren, damit hier die Makros gleich aktiviert werden (und die User nicht immer erst auf den gelben Button klicken müssen).
Oder sollte man den Usern die Möglichkeit geben Dokumente als vertrauenswürdig hinzuzufügen?
Mein Gedanke ist, dass es irgendwann zur Routine wird den gelben Button zu drücken, wenn alle Dateien immer und immer wieder diese Aufforderung benötigen.
Das ist dann natürlich auch nicht sonderlich hilfreich.
Wenn man allerdings vertrauenswürdige Speicherorte angibt, ist hier natürlich gleich alles aktiviert und es gibt gar keine "Warnung".
Wie habt ihr das bei euch gelöst?
Wäre für Tipps sehr dankbar.
Gruß
-
Genau so läuft es bei uns auch.
Die neuesten ADMX Templates verwenden wir im Central Store und bearbeiten die GPOs immer über das entsprechende OS.
Am 9.11.2018 um 16:48 schrieb NorbertFe:Nein, das hätte nicht sein können, weil per default keine Prüfung erfolgt, auf welches os ein gpo angewandt wird.
Genau das hat sich ja in dieser Diskussion für mich geklärt.
-
Hm... weiß nicht genau was du jetzt meinst.
Die GPO Einstellung schreiben meist in HKLM oder HKCU einen Wert z.B. Reg_SZ oder DWORD.
Nach deiner Erklärung werden diese Werte, also z.B. ein DWORD, auch geschrieben, wenn die GPO eigentlich nicht für die Windows Version geeignet ist.
"Alte Windows" Versionen lesen diesen Wert, in diesem Falle ein DWORD, nicht aus und somit ist diese Einstellung aus der GPO auch nicht wirksam. Neuere Windows Versionen lesen den Wert, also das DWORD, aus und somit ist auch die Einstellung aus der GPO wirksam.
Diese Info finde ich ganz hilfreich und ich glaube nicht das ich eine unpassende Vorstellung von Registry-Keys habe. Vielleicht habe ich mich nur falsch ausgedrückt..
Es hätte ja auch sein können, dass dieses DWORD gar nicht in die Registry geschrieben wird, wenn die Windows Version unpassend ist.
Danke - dir ebenso ein schönes Wochenende.
-
Richtig, hatte ich ja erwähnt.
Für mich ist es nur gut zu wissen, dass die Registry Keys trotzdem erstellt werden. Wer weiß ob einem dies doch mal irgendwie in die Suppe spuckt und dann ist diese Info Gold wert :)
-
Hi Nils,
danke - so habe ich mir das auch vorgestellt.
Ich sehe nur ein Problem (das aber schon sehr konstruiert ist). Wenn dieser Wert in der Registry erstellt wird und man z.B. über eine GPO oder ein anderes Programm wie z.B. SCCM oder ZCM diesen Wert abprüft um davon z.B. auf die Windows Version zu schließen, könnte es zu Problemen kommen. Aber das ist wie gesagt schon sehr konstruiert und wird in der Realität nicht vorkommen.
Aber es ist gut zu wissen, dass die Regedit Einträge geschrieben und nicht ignoriert werden, wenn sie nicht für die Windows Version gemacht wurden.
Ich werde dann weiterhin nur 2 Win 10 GPOs haben - eine für User Einstellungen und eine für Computer Einstellungen.
-
Hallo zusammen,
wir setzen bei uns im Unternehmen noch Windows 10 1703 ein. Da diese Version ja EoL ist, updaten wir die Clients jetzt Stück für Stück auf Version 1803. Hier setzen wir auch neue GPOs ein, die nur für diese Version angewendet werden können.
Ich bin mir nun unsicher ob ich diese Einstellungen einfach in einer Windows 10 GPO vereinen kann und diese allen Win 10 Geräten zuweise, ganz egal ob Sie noch 1703 oder schon 1803 sind, oder ob ich eine extra Richtlinie für 1803 erstelle und diese z.B. per WMI Filter oder Sicherheitsgruppe nur den PCs mit der neuen Win 10 Version zuweise.
Weiß jemand ob es Probleme macht wenn einer Windows 10 1703 Version auch Richtlinien für Windows 10 1803 zugewiesen wurden. Ignoriert der PC einfach die Einstellungen oder schreibt er diese trotzdem und es kann zu einem möglicherweise ungewolltem Verhalten kommen?
Danke euch schon mal.
Gruß
-
Hi Sunny,
die Anpassung des Startmenüs machen wir im Moment in der 1703 schon genau so.
Xbox wird in "Programme hinzufügen und entfernen" angezeigt. Hier schaue ich dann aber noch mal genauer nach.
Den Rest werde ich einfach per ZCM oder GPO wieder anpassen. Unnötige Arbeit die einem MS da aufbürdet, aber gut... was will man machen.
Jetzt muss erstmal der AV aktualisiert werden, der scheint noch nicht wirklich mit der 1803 kompatibel zu sein
Danke für eure Hilfe. Ich denke das müsste aber so ganz gut klappen.
-
Danke Sunny.
So ganz ist mir die ganze Geschichte noch nicht klar.
Laut mehreren Infos im Netz passiert bei einem inplace Upgrade eine Neuinstallation. Hat man in der Ursprünglichen Installation z.B. einige Apps gelöscht, werden diese nach dem inplace Upgrade wieder vorhanden sein.
Wir haben wie gesagt einige Anpassungen im Base Image vorgenommen. Unter anderem wurden einige Apps entfernt.
Ich habe nun auf einem Test PC mit Win 10 1703 einmal das inplace Upgrade mit dem Befehl
\\Server\Share\setup.exe /auto upgrade /DynamicUpdate disable gestartet. Das ganze hat ca. 15 Minuten gedauert. Danach war der PC auf Version 1803. Die von uns entfernten Apps waren aber weiterhin nicht da (Ausnahme Paint3D - bin mir aber nicht sicher ob es das überhaupt schon in der 1703 gab). Auch sonst wurde alles behalten.Bin erstmal positiv überrascht - traue dem ganzen aber noch nicht so ganz.EDIT: 2 Kleinigkeiten sind mir noch aufgefallen. z.B. wurde die OneDrive Verknüpfung im Startmenü erstellt obwohl OneNote noch gelöscht ist. Ebenso wird XBOX als installiert aufgeführt aber ist nirgends zu finden. Beides waren Apps dir wir im Base Image gelöscht hatten. -
Jetzt habe ich noch eine blöde Frage zur WIM Datei.
Sehe ich es richtig, dass ich am besten ein Base Image erstelle (im Audit Mode) und mein Image soweit anpasse. Wenn ich damit fertig bin erstelle ich mit dem DISM Befehl die WIM Datei und tausche die gegen die install.wim im original 1803 ISO aus.
Mit dem angepassten Base Image (nach dem ich Sysprep laufen lassen habe) kann ich dann neue PCs imagen. Mit der WIM Datei kann ich das inplace Upgrade durchführen.
-
Alle Clients neu installieren wäre doch etwas schwierig. Wir haben zwar "nur" 140 PCs aber es ist doch auf einigen PCs individuelle Software vorhanden. Daten liegen aber keine auf den PCs - die liegen alle im Netzwerk.
Wir imagen die PCs zwar über Zenworks und die Installation würde somit schnell ablaufen, aber es wäre einiges an Nacharbeit zu tun.
WSUS läßt sich einfach schlechter kontrollieren. Über eine GPO und ein scheduled Task wäre das Update wahrscheinlich einfacher an kleine Gruppen zu verteilen.
Hatte dazu bei administrator.de eine gute Idee gesehen
ZitatSo, noch mal ein abschließender Nachtrag:
Setup-Task "1607_upgrade" per GPO verteilen. Task läuft als Systemkonto. Trigger ist "Bei Systemstart". Aktion des Tasks ist eine Batch mit
Super, so funktioniert es.
Ich habe für uns den Batch allerdings leicht geändert:Den Link zu Gruppenrichtlinien schaue ich mir mal an - danke!
EDIT: Die Idee von Mark geht ja genau in diese Richtung mit Task und Batch Datei.
Wenn ich es richtig verstehe, ändert er aber die install.wim ab. Diese ändert er mit MDT und entfernt z.b Apps usw. Ist das richtig?
Wir haben das bei unserem Base Image über Zenworks bzw. Imaging Toolkit gemacht. Für das Inplace Upgrade sollte das dann aber ausreichen. Ich muss halt nur die gleichen Apps entfernen wie im Base Image auch. Hoffe ich verstehe das so richtig.
Was sich MS bei diesen kurzen Laufzeiten gedacht hat ist mir ein Rätsel. Wir sind zu 2 in der EDV und müssen jetzt fast jedes Jahr ein neues Update ausrollen. Das fängt schon bei Inkompatibilitäten beim AV an und hört bei komplexen CAD Rechnern auf. So wirklich weiß ich noch nicht, wie wir das sauber in den Griff bekommen sollen.
Verwaltung der Admin Accounts in der IT Abteilung
in Active Directory Forum
Geschrieben
Ja, wir sind ein kleines IT Team (3 Leute - 50 Server - 200 AD User)
Wir haben schon eine grobe Aufteilung, aber Clients macht bei uns jeder. Auf einige Server müssen wir alle mal schauen, andere wiederum nur ausgewählte Kollegen. Die AD macht eigentlich nur einer.
Das dachte ich mir dann schon so, klingt am vernünftigsten aber natürlich auch am "Aufwendigsten". Aber Sicherheit geht immer etwas zu lasten von Komfort und hier muss dann jeder wohl seine Prioritäten legen.
Unterschiedlich - die AD Verwaltung (DNS, User, Computer, DHCP, usw.) läuft eigentlich über die Admin PCs. Dort sind die RSAT Tools installiert und wir öffnen diese mit unserem persönlichen Admin um die Arbeiten durchzuführen. Das müsste so ja ok sein, oder ist es besser sich mit seinem persönlichen Server Admin per RDP auf den jeweiligen Server zu schalten und dort die Arbeiten auszuführen?
Auf den Servern waren dann meistens Anwendungen offen, für die es keine "Remote Verwaltungskonsolen" gab und man eben direkt auf den Server arbeiten musste. Nichts zwingendes und eben nur Komfort. In Zukunft müsste man das eben erst noch öffnen, wenn man sich mit seinem persönlichen Server Admin Account angemeldet hat.
Ich tendiere jetzt zu folgender Lösung
3 Accounts - normaler User, einen AD Admin und einen Server/Client Admin. Bin noch etwas unentschlossen ob wir wirklich die harte Grenze zwischen Server und Clients ziehen müssen.
Ich muss mir auch noch den Link von testperson anschauen (
)