PowerShellAdmin

Moin, ich habe hier ein tolles Problem - oder auch nicht. Das Ganze ist etwas umfangreicher und nicht per Get-ADGroupmember sondern via .NET gelöst. Das Problem tritt aber bei beiden Abfragen aus, daher habe ich das mal vereinfacht. Ich habe diverse Domänen und kann untereinander zugreifen. Beispiel a)in Domäne 1 ist eine Gruppe - Typ:domainlocal- diese enthält Mitglieder direkt aus Domäne 2 => klappt Beispiel b)in Domäne 1 ist eine Gruppe - Typ:domainlocal- diese enthält eine Gruppe -Typ:Global- aus Domäne 2 mit Mitgliedern aus Domain 2=> Rekursion klappt Beispiel c)in Domäne 1 ist eine Gruppe - Typ:domainlocal- diese enthält die generische Gruppe Domain Users aus Domäne2 mit Mitgliedern => Rekursion klappt NICHT wieso ?... :( Eine Abfrage direkt innerhalb der Domäne gegen die Gruppe Domain Users funktioniert, nicht aber über kreuz. VG Admin Also die Gruppe "Domain Users" ist nicht im Memberof Attribut eingetragen sondern unter primarygroup. Man kann also innerhalb der Domäne die Gruppe abfragen - aber nicht über kreuz. Habe das Problem erstmal umgangen, falls jemand eine Lösung hat, würde die mich aber dennoch interessieren.

Arraylist, Eigenes PsObject Der Skript ist nur ein logisches Beispiel. Du initialisierst einmalig die Arrayliste. Anschließend befüllst du die Liste mit den einzelnen Zeilen in einer Foreach Schleife. Dafür wird in jedem Schleifendurchlauf ein Objekt initialisiert und der Liste hinzugefügt. Der Code ist unvollständig und mehr ein logisches Biespiel - aber das kriegst du ja hin :) #initialisiert die Arrayliste $txt_lines=New-Object System.Collections.ArrayList foreach($line in $txt) { #initialisiert ein PS Object $line= New-Object PSObject -Property @{ OwnerGroup=$line.ownergroup OwnerNode=$line.ownernode } #fügt die Zeile zur Liste hinzu $txt_lines+=$line }

Vielleicht habe ich mich ja falsch ausgedrückt. Es gibt diverse Domänen/Organisationen A ist die Konfigurationsdomäne, B,C,D usw die jeweiligen Standorte. Innerhalb der Organisation A benötigt man einen Benutzer, welche lesenden AD Zugriff auf B,C,D hat. Hier würde mich die beste Möglichkeit interessieren. VG Admin

Moin, ich habe eine Umgebung, welche sich aus diversen Domänen zusammen setzt. So habe ich eine "Konfigurationsdomäne" - Domäne A, dadrunter fallen nun diverse Standorte (eigenständige Domänen) -Domäne B (entspricht einem belibiegen Standort) Die Vertrauenseinstellungen zwischen A und B sind bidirektional (Transitive) mit einer selektiven Authentifizierung. Um von Domäne A mit User A auf Domäne B zuzugreifen, muss ich diesen Benutzer zuerst innerhalb der Domäne B Berechtigen. Ich habe nun innerhalb der Domäne B auf einen DC den User A lesen & authentifzieren berechtigt - Ich kann auch erfolgreich nun Abfragen aus der Domäne A und mit dem User A gegen die Domäne B ausführen. Aber... so wie ich das sehe, müsste ich diesen Benutzer auf allen DC berechtigen - auf allen Standorten. Wie kann ich das besser lösen, so dass ich den User nur einmalig berechtigen muss ? Sinn ist ein Service-Account, welcher auf der Konfigurationsdomäne aus Sicherheitsgruppen die jeweiligen Benutzer der unter Organisationen ausgibt - Also ein Serviceaccount der Domäne A, der in Domäne B lesen darf. VG & Danke Admin

und was spricht gegen eine globale Trap ? Try Catch macht ja eher sinn, wenn man an diversen Stellen Fehler abfangen möchte und womöglich Customerrors aufbauen will. Will man hingegen nur schauen ob der Skript lief und welcher Fehler auftrat, dann würde ich eine Trap nutzen. Der Trap fängt sämtliche Fehler im gesamten Skript - nicht nur in einem Bereich ab. Hier ein schönes Beispiel aus dem Buch "Windows Power Shell 3.0" von Tobiass Weltner (leicht angepasst) Zur Erklärung - der untere Skript ließt den Ursprung der letzten Fehler und ruft dann ein Template auf und gibt so eine detaillierte und gut formatierte Meldung aus - auch ins Logfile. Den Code solltest du dir in den Skriptheader einfügen. #Variable mit Pfad zu Logdatei $log_file="c:\powershell.log" #Hier die eigentliche Fehlerbearbeitung trap { $line=$_.InvocationInfo.Line $sriptname=$_.InvocationInfo.ScriptName $linenumber=$_.InvocationInfo.ScriptLineNumber $lineoffset=$_.InvocationInfo.OffsetInLine $message=$_.Exception.Message $time=get-date() $user=$env:USERDOMAIN+'\'+$env:USERNAME $template=@' ##.##.##.##.##.##.##.##.##.##.##.##.##.##.##.##.##.##.##.##.##.##.##.##.##.##.##.##.##.##.##.##.##.##.# Scripterror in "{0}" at {1} in line {2} column {3}: Exception: "{4}" Commandline: {5} Run as: {6} ##.##.##.##.##.##.##.##.##.##.##.##.##.##.##.##.##.##.##.##.##.##.##.##.##.##.##.##.##.##.##.##.##.##.# '@ $message=$template -f $scriptname,$time,$linenumber,$lineoffset,$message,$line,$user $message>>$log_file #beendet den Skript mit einer Fehlerrückgabe exit 1 }

Gerne - übrigens hat sich die Abfrage bei 27.000 Benutzern (in 10 Gruppen verteilt) und 3 Attributen von 25 auf 6 Minuten reduziert. Die Questmodule haben die Anfrage verlangsamt - Daher bin ich auch kein Freund von 3. Anbieterlösungen (außer es muss sein). Hoffentlich findet der Nächste dann die Lösung :) - Mit weniger Googelei VG Admin

Also ich verstehe diese Verweigerung nicht, PS ist das aktuelle Werkzeug für administrative Verwaltungsaufgaben - kann aber auch viel mehr und steigt im Nutzungsumfeld erheblich. Die Aufgabe schreit also schon nach einer PS Lösung. Einfache CSV Datei erstellen, in der PS wird diese eingelesen und umgesetzt - verstehe das grade nicht so ganz - Im Zweifel an einen Dienstleister abtreten. Batch oder sonstiger Skript machts auch nicht einfacher und den großteil der Anforderung kannst du recht einfach per PS abbilden. PS: Hier kannst du ja mal die einzelnen CMDs testen - Yusuf hat da eine schöne Liste. http://blog.dikmenoglu.de/ADPowerShell+Befehle.aspx

So ein kleines Feedback, ich hatte das Ganze zwischenzeitlich via diverser Schleifen und QAD-Getgroupmember gelöst. Es gibt diverse Alternativen, aber diese sind "scheiße", sobald man mit mehreren Domänen arbeitet und zumeist ziemlich unschön. Nun habe ich doch eine Lösung gefunden, die ähnlich wie get-adgroupmember arbeitet - ohne Limitierung, dazu rekursiv und auch durch diverse Verschachtelungen keine Probleme zeigt. Toller Nebeneffekt - das Ding ist ziemlich performant und kann in der PowerShell nativ ausgeführt werden - .NEt3.5 Code Quelle: http://stackoverflow.com/questions/8055338/listing-users-in-ad-group-recursively-with-powershell-script-without-cmdlets?rq=1 Kommentar von Shay Levy #This will get all members of the domain Administrators group, including nested members (requires .NET 3.5). $Recurse = $true $Group ='Samaccountname der Gruppe' Add-Type -AssemblyName System.DirectoryServices.AccountManagement $ct = [System.DirectoryServices.AccountManagement.ContextType]::Domain $group=[System.DirectoryServices.AccountManagement.GroupPrincipal]::FindByIdentity($ct,$Group) $group.GetMembers($Recurse)| select EmailAddress, Distinguishedname, Givenname, Surname

$user_attribut = [ADSI]"LDAP://CN=$user_nachname\, $user_vorname,$user_ouPath" #CN Name muss \ enthalten, ansonsten wird der Name falsch aufgelöst $user_attribut.put("msNPAllowDialin","TRUE") #setzt die Property $user_attribut.setInfo() #schreibt die Daten in die Benutzerinfo Also ich habe ein Powershellskript der umfangreich Benutzer anhand eine Workflows anlegt. Hier mal ein Beispiel für ADSI. Eigentlich super einfach (sogar besser als mit PS - weil man halt alle Attribute setzen kann - in dem Fall VPN Flag) In der 1. Zeile wird der LDAP Verbindung aufgebaut In der 2. Zeile setzt man das jeweilige Attribut In der 3. Zeile wird die Änderung "gespeichert" Die 2. Zeile kannst du unendlich kopieren und gleich mehrere Attribute setzen, sobald .setinfo ausgeführt ist, sind alle Attribute gespeichert. PS: Mein Skript zum Anlegen der Benutzer hat kommentiert 700Zeilen - hier sind diverse Funktionen und Fehlerbearbeitung eingebaut, da kommt man ganz schnell "groß" raus :) Als Schnittstelle ist eine DB im SQL Server, hier werden die Daten ausgelesen und anschließend wird ein Flag gesetzt. Edit: Das Attribut kannst du dir auch per AD-MMC einfach raussuchen (erweiterte Ansicht freischalten ) - Dort auf das Register Attribute wechseln und suchen (;

Hallo Martin, mit Get-ADGroup kann ich allerdings keine rekursive Verschachtelung abbilden. Allerdings habe ich nun konzepttechnisch festgestellt, dass dies überhaupt nicht notwendig ist und ich dies über verschachtelte Schleifen doch abbilden kann (meine Beschreibung obig von der Verschachtelung stimmt so also nicht). Hatte mich jetzt sogar mit QAD an eine Lösung getastet, werde aber womöglich doch auf Get-ADGroup. Teste das erstmal mit den QAD Queries und anschließend mit den Get-ADGroup. Technisch liegt die Begrenzung wohl an der Konfiguration der DC - man kann wohl das Limit erhöhen (für alle DC der jeder betroffenen Organisation notwendig). http://technet.microsoft.com/en-us/library/dd391908%28WS.10%29.aspx Das ist allerdings ausgeschlossen .... Bis Dato habe ich immer auf QAD CMDlets verzichtet, hoffe das klappt jetzt auch noch - Immerhin sind diese von der Performance schlecht und zumeist unnötige 3. Tools :/. Gerade Performance ist ein wichtiger Aspekt, da man umfangreiche AD Queries je nach Technik 20 oder auch nur 30 Sekunden dauern können - mit dem selben Ergebnis ;) Kleines Feedback, Get-ADGroup ist leider nicht geeignet. Ich arbeite mit Domain Local Gruppen, darunter liegen Globale Sicherheitsgruppen in den jeweiligen Organisationen. On the fly kann man das so leider nicht umsetzen. Ich nehme an das geht auch, soweit man je Get-ADGroup die DC definiert. Ich bin gespannt wie sich die QAD Lösung mit den Schleifen am Ende schlägt, mein Verdacht ist, dass die zusätzlichen Abfragen kaum ins Gewichtfallen, da die eigentliche Verzögerung bei der AD Query ist.

Moin zusammen, ich habe ein Problem mit der Abfrage Get-ADGroupMember -> Size Limit exceeded -> Die Gruppen können > 5000 Mitglieder haben. Zur Situation, ich habe in einer OU diverse Gruppen in Domäne 1. Diese Domäne 1 ist quasi die übergeordnete Organisation für die Konfiguration. Je Gruppe sind aus 7 Standorten (ebenfalls eigene Domänen mit Vertrauenseinstellungen verbunden) gleichnamige Gruppen zugewiesen und innerhalb dieser Gruppen liegen an den Standorten direkt oder indirekt die User. Das Problem: Ich habe eine einfache Abfrage im Skript an zwei Stellen und hier macht mit Get-ADGroup ärger. $winUserList = Get-ADGroup -identity "Gruppenname" -properties Members -recursive # | Get-ADUser -Properties * Beispiel - die Abfrage wird nur auf die Gruppe in der Konfigurationsdomäne gestartet, hier können die Mitarbeiter effektiv durch diverse Gruppenhierachien verteilt liegen. Testgruppe@Hauptdomäne ->Testgruppe@Standort1 ->Mitarbeitergruppe@Standort1 ->User1 ->UserN... ->Testgruppe@Standort2 ->Mitarbeitergruppe@Standort2 -User10 -UserN... ->Buchhaltunggruppe@Standort2 -User20 -Usern.. Als Alternative hatte ich nun - das stimmt allerdings auch noch nicht, da hier Benutzer mehrfach vorhanden sein können. $grp = Get-ADGroup "Gruppenname" -properties Members $winuserList= $grp.members |Get-ADGroupMember -Recursive |Get-ADUser -Properties userprincipalname, givenname, surname, EmailAddress Allerdings besteht das Problem ja weiterhin, wenn die Untergruppe > 5000User hätte Sollte ich auf die QAD Addins ausweichen ?- Laut Inet kann man das Limit hier festsetzen. Allerdings setze ich ungern auf fremde Lösungen. VG Admin

Hallo, anhand des Threads sollte man eigentlich sehen, dass wir uns vor einigen Wochen für Eset entschieden haben. Dazu kommt, dass Kaspersky Internetsecurity 2012 keine Enterpriselösung ist, daher nur bedingt für kleiner Firmen geeignet. Als kleines Feedback, Eset hat bis jetzt keine Probleme gemacht. Mit der Performance bin ich sehr zufrieden und die verteilte Installationen laufen auch sehr rund. Trotz unserer umfangreichen Benutzung an den Clients, kam es bis jetzt zu keinen wirklichen beschwerden. Von der P/L ist es meiner Meinung nach das "rundeste" Produkt. Das Einzige was man bei Eset beachten sollte, dass die Einrichtung sehr umfangreich ist. In kleineren Firmen würde ich mir womöglich das einfachere Trendmicro oder alternativ die Standalone Version von Eset nutzen (habe ich bei einer Firma mit 5 Arbeitsplätzen gemacht) VG :)

Ich habe 2 Updateprofile, als Standard wird der Unternehmensrepository genutzt. Die Tasks sind alle konfiguriert und funktionieren, in und außerhalb vom Unternehmen. Das Updaten durch das manuelle Ausführen des Benutzters gibt allerdings eine Fehlermeldung (außerhalb des Unternehmens). Wo liegt die Konfiguration für das manuelle Update - erkennt er hier nicht auch direkt das primäre und sekundäre Profil ?

Also bis jetzt gibt es sonderbarerweise keine Beschwerden über Eset. Das Ganze läuft auf mehreren Clients, wo neben Windows & Office auch einige Tools wie VS 2010, MS SQL, VMWARE Server etc laufen - alles problemfrei. Noch nicht ganz zufrieden bin ich mit der Einrichtung aufm File und Terminalserver - Da muss ich nochmal nachbessern (Punkte wie Ondemandscan aufm TS unterbinden oder die Reinigungsroutinen aufm Fileserver richtet auswählen) TrendMicro war sehr angenehm in der Installation und Einrichtung. Allerdings scheint der AV Schutz ja nicht so gut zu sein, jedenfalls laut heise.

Ja macht einen guten Eindruck, die Policies muss man halt verstehen - ist nicht immer so ganz eindeutig. Aber ansich ein tolles Produkt, aufgrund der vielen Möglichkeiten. Man kriegt halt nicht alles in den ... geschoben ;) Die Lizenz ist übrigens bereits gekauft - 3Y ! Edit: Habe in der Policy vom Client die Konfig ausgelesen und die default TasksIDs angeschaut und anschließend die Tasks selbst neu erstellt mit der ID - So sind die standard Tasks nicht doppelt bzw klar definiert.

Ach iDiddi das ist perfekt, habe es gleich mal eingerichtet - so macht das sinn. So nebenbei war ich irretiert, da Clienttasks nicht syncronisiert wurden - aber da gibts ja die Option => Clienttask löschen :) Jetzt trage ich nur die standard Prüftasks nach.

AVG loszuwerden, ist so eine Sache - da muss man kreativ sein :) Habe analog zu Dokumentation von ESET (AVG Remover 2012) das ganze auf den 2013er angepasst. Per Autoit wird der Remover per ESET Paket verteilt - der PC startet automatisch neu. Daher habe ich eine Shutdownabort.bat ("shutdown -a") noch abschließend eingefügt Werde jetzt noch versuchen das Ganze nach x32 und x64 festzustellen - was ist da der einfachste Weg ? Der untere Paket - ich habe mir das zurecht gefummelt - funzt immerhin aufn x64 System. Teste es mal auf einer x32 Möhre. Edit: Hinweis - sollten im DNS Server verwaiste Einträge sein - z.B. 2 auf eine IP, so kann es vorkommen, dass der Client sich nicht verteilen lässt. Dim $OSArch = @OSArch Switch $OSArch Case "X64" Run("avgremover2013x64.exe") If WinWait("AVG Remover - Warning", "This application", 30) Then ControlClick("AVG Remover - Warning", "This application", 6) EndIf Run("shutdownabort.bat") Case Else Run("avgremover2013x32.exe") If WinWait("AVG Remover - Warning", "This application", 30) Then ControlClick("AVG Remover - Warning", "This application", 6) EndIf Run("shutdownabort.bat" EndSwitch

Hi iDiddi, ja das kann sein, da ich noch andere Sachen immer wieder aufn Tisch habe, geht da mal was unter. Edit: Unter Serveroptionen/Updates aktiviere ich den UpdateMirror inkl. http(s) und setze den Intervall auf 60Minuten. -Die Option verzögerte Updates (12H) klingt recht spannend, so kann man größeren Problemen bei Updates aus den Weg gehen... Nachteil ist aber, dass man durch neue Viren angreifbar wäre ... Nun wechsel ich in den Reite erweitert und setze in der Policy unter Updates die Option für die PCU Pakete (German 32/64bit EAV ausgewählt) - damit wäre der Mirror eingerichtet (Windowsfirewall sind die Ports freigegeben). Der Client ist doch ein anderes Thema, dort kann ich ja einen Updatetask einrichten und ein Profil. Innerhalb des Profils kann ich wieder die ESET User und Kennwort eintragen und im Profil die Serverauswahl eingeben - hier steht "automatisch", dazu gibt es auch einen Bereich Lan ... Bedeutet dies nicht, dass wenn er auf automatisch ist, von alleine den lokalen Http(s) Server verwendet und nur dann wechselt ? 2. Ich kann in der Client Policy einen Updatetask einrichten, der alle N Minuten ein Update fährt und auch "verzögerte" Updates ausführt. Das scheint aber überflüssig, da in der Clientansicht und Tasks bereits 2 Updatetasks vorhanden sind - und daher kommen auch meine Fragen - war / ist mir noch nicht ganz klar und das steht im Administrationguide unter Updates auch nicht weiter beschrieben. Das sieht für mich wie abhänige Standard Tasks aus. Im Userguide im Bereich Clients konnte ich auch nur eher eine schematische Erklärung, als eine Erklärung der einzelnen Policies finden. Hier ist die Konfiguration des Clients

Danke für die Info zu SSL - benötige das erstmal auch nicht - hat mich halt interessiert :) Wegen ESET - Das System habe ich jetzt schonmal produktiv vorbereitet mit extra angelegten Userkonten und diese via GPO als lokalen Admin verteilt (Firewall Ports geöffnet und einfache Freigabe deaktiviert)- Die Verteilung klappt schon wie gewünscht,super und ohne weiteres eingreifen wie Kennwort. Jetzt stehen für mich erstmal 2 wichtige Punkte auf der Liste: -Updates: In den Serveroptionen sind diese aktiviert, außerdem habe ich die im Konfigeditor auch für die EEA Pakete aktiviert - Der Server hat also aktuelle Signaturen und Pakete. In der Client Policy lege ich dann einen Task für die Updates an - funktioniert auch und trage nochmal die Zugangsdaten ein (wunder mich etwas) oder ? Wie richte ich denn z.B. Notebooks ein, diese sollen innerhalb der Firma mit dem Repository updaten und außerhalb via Internet ? -Programmdeinstalltion AVG - SO wie ich das sehe muss ich das ins Paket einpflegen - da mache ich mich jetzt ran (habe nen älteres Dokumentation)

Danke für euer Angebot - werde ich bestimmt drauf zurück kommen... Sehe ich das eigentlich richtig, dass Eset -Falls SSL Scan aktiv- ein eigenes Zertifikat zwischen schaltet, sobald man die SSL Überprüfung aktiviert ? Wie funktioniert das genau, wird dort ein teil des Traffics entschlüsselt vom Scanner und dann via richtigen Zertifikat weitergereicht ? Achja ist der Einsatz überhaupt sinnvoll ...

So ein kleiner Nachtrag, der Support hat sich telefonisch gemeldet. War sehr positiv überrascht, da sich viel Zeit genommen wurde - Außerdem wurde auch explizit der AV Produkt empfohlen anstatt das größere Security Produkt aufgeschwatzt. Vertrieb geht übrigens auch direkt über Datsec - so werde ich das dann auch machen => Wird Eset

Also der Erstvertrieb war via Datsec - hat sich da leider alles gezogen, anschließend habe ich von Bürozentrum oder so ähnlich den Trialkey und das Angebot erhalten. Auf meine weiteren Anfragen wurde dort nicht geantwortet. Zum Support - Ich habe heute um 16:30 eine Anfrage via Supportformular eingereicht - war wohl nicht verkehrt. Bereits um 17:45 habe ich eine ausführliche Antwort - nicht machinell - auf die möglichen Ursachen und Links zu den passenden Knowdlege Artikeln bekommen => Das war jetzt wirklich unkompliziert :) Nutzt von euch eigentlich einer die Securityvariante ? Außer den Contentfilter,Spamschutz und die Firewall habe ich da jetzt keine Vorteile gefunden - Und hier hätte ich eigentlich lieber ne nen Proxy oder Bridge für :) Der Webfilter - wie Kermit erwähnte- ist ja in der AV drinne.

So Sophos aufgrund der Userlizenzierung ist, fällt es erstmal raus. Auch interessant - der Vertriebler i.A. von Sophos macht Aussagen wie: Sophos findet das eh nicht raus; Da habe ich mal gearbeitet und die interessiert das nicht... Ich nenne jetzt mal nicht die Firma und den Ansprechpartner (Stichwort Verleumdnung) - aber sowas habe ich bis jetzt vom Vertrieb noch nicht erlebt. Die Installation vom Mgmt hat mir sehr gefallen und die Rezensionen über den scheinbar guten Support hatten doch das Interesse geweckt. - Da ich aber aufgrund der Userlizenzierung mit den etwa 3x Kosten rechnen muss, ist es erstmal raus. Trend Micro macht einen guten Eindruck - außer an meiner Win8 Mühle, der Support ist aber auch freundlich und ist derzeit am Problem dran. Jetzt interessiert mich vorallem wie ist eure Erfahrung mit Eset - Ich hatte hier zu Beginn direkt schlechte Erfahrung gemacht (muss ja nix heißen) - Meine Anfrage ging an Datsec und ist dort erstmal 10Tage gewesen - Trotz zwischenzeitigen Anruf - Dann bekam ich erst meinen Trialkey und Angebot - von einer weiteren Firma die nicht auf Email antwortet und deren Positionen "User-Cals" schreibt, obwohl es Devicecals sind - Nicht sehr seriös wie ich finde .... Auch finde ich keine Supporthotline bei Eset - Scheinbar läuft das über Datsec (hier geht nur der AB dran).

Laut Vertrieb hat Sophos die Lizenzierung von Device auf User dieses Jahr umgestellt. Das wäre natürlich sehr unvorteilhaft - warte jetzt nochmal auf verbindliche Infos :/

Oder ich mich ungünstig ausgedrückt :) Es ist zum Haare raufen.... Kaspersky scheint aber im Punkte Erkennungsrate und Bereinigung sehr positiv hervorzustechen - Preislich auch eher die günstigste Alternative. Trend Micro hat die schlechten Entfernungsroutinen und zur Erkennung kann ich jetzt auch nicht soviel finden - Laut Cunsumerclienttest bei Chip ist die Erkennung aber wirklich sehr dürftig. Habe hier mittlerweile meine 3 Evaluierungsumgebung, Trend Micro ist durch - Bin ja ansich sehr zufrieden. Kaspersky und Eset laufen - Kaspersky habe ich noch nicht im Detail angeschaut, aber die Verteilung inklusive Entfernung der alten Trendmicro Clients ging wunderbar. Dazu kommt, dass man zu Sophos immer wieder exzellente Bewertungen ließt und sehr guten Support - Das macht mich jetzt doch neugierig ;) Aller guten Dinge sind 3 4 ....