Cybquest

Da sich bei dem Class-B-Netz die vorderen 2 Oktette ja nicht ändern sollten, hast mit der 252 ja 6 Bits für Subnetze, also 63 mögliche. Diese "-2"-Geschichte betrifft eigentlich den Hostanteil.

$CsvFile = "C:\D_LW.csv" $Path= "D:\" "Path;Identity;Rights" | Out-File $CsvFile Get-ChildItem $Path -Recurse | where {$_.PsIsContainer} | foreach{ $FullName = $_.FullName $ACLs= @((Get-ACL $_.FullName).Access) | sort $ACLs | Where-Object {$_.IsInherited -eq $false} | foreach{ $Identity=$_.IdentityReference $FileSystemRights=$_.FileSystemRights "$FullName;$Identity;$FileSystemRights" | Out-File $CsvFile -Append } } Zum Testen bei Path evtl erst mal nicht gleich mit D:\ anfangen sondern ein Verzeichnis. Könnte sonst recht lange laufen...

Da das Script rekursiv durch die Verzeichnisse läuft, könntest ja als Pfad einfach z.B. D:\ angeben. Dann noch bissle umbauen, dass da nicht für jeden Pfad ne CSV-Datei erzeigt wird und beim "acl.access" ins Where noch die IdentityReference filtern auf Deine Gruppe... Allerdings würde ich an Deiner Stelle tatsächlich einfach mal alles auslesen in eine große CSV und dann mit Excel-Bordmitteln darin nach Deinen Gruppen suchen...

Hast Du irgendwo noch eine Länderspalte, nach der Du filtern kannst, ob tschechisch oder französisch? Dann könntest Du ja mit ner expressionbased Collation und nem Union Select die Ergebnisse verknüpfen...

Oder mittels "Pivot" mit nem Year(Tanken.Datum) als Spaltenkopf... http://technet.microsoft.com/de-de/library/ms177410(v=sql.105).aspx

Ich würde sagen, das liegt an der Codepage. Vermutlich hast Du die Standardcodepage 1252 (Latin/ANSI), bräuchtest für Tschechisch aber die 1250. Hier'n Link: http://technet.microsoft.com/en-us/library/ms190920(v=sql.105).aspx

Ach, noch zu Deiner Wette: Dein Admin hatte Recht ;-)

Gibt's bei Dir nur die 2 Rechner? Dann wären unterschiedliche Netzmasken sinnlos. Ansonsten: So wie ich's beschrieben hab. Warum der eine den anderen NICHT sieht, müsste man ermitteln. Ich würde da eher auf Firewall o.ä. tippen. An den Router (bzw. Default-Gateway) wird geschickt, wenn der Netzanteil des Rechners, der da angepingt werden soll, nicht übereinstimmt (Bsp. bei dem mit der 24er Maske, alle, die eben nicht die 1 im 3. Oktet haben)

Der mit der 24er Maske "sieht" nur die, bei denen der Netzanteil ("Netz-ID") gleich ist. Da das bei dem anderen in Deinem Beispiel der Fall ist, müsste er den sehen. Der mit der 16er Maske sieht zusätzlich noch alle, die sich auch im 3. Oktet unterscheiden! (also 192.1.1.x - 192.1.254.x)

Die "Netz-ID" gibt's ja in dem Sinne nicht. Ist ja dennoch nur ein Teil der IP-Adresse. Der Rechner entscheidet anhand der IP und der eigenen Netzmaske ja nur, ob ein anderer in seinem Netz zu sein scheint, oder er das Paket an einen Router schicken soll. Der mit der 16er Netzmaske weiß ja z.B. nicht, dass der andere ne 24er Maske hat. Eigentlich müssten beide davon ausgehen, dass sich der jeweils andere im gleichen Netz befindet.

Mit einem "BEGIN BACKUP" wird die DB quasi angewiesen, nichts mehr aus dem Transaktionsprotokoll in die DB zu schreiben bis zum "END BACKUP". Daher ist es vorteilhaft, die Sicherungen nicht zur Volllastzeit zu machen, da sonst die TP schnell wachsen können.

Kannst gpresult ja auch mit Parameter /S und /USER aufrufen und das entspr. System sowie den User angeben. Ggf. per Script in ner Schleife, vorher noch den jeweils angemeldeten Benutzer ermitteln...

Wo kommen die Vorlagen her? Vielleicht einfach mal den ursprünglichen Entwickler kontaktieren?

Müssen die 3 Namen direkt untereinander stehen? Ansonsten kannst ja 3 Queries nacheinander auf die Tabelle laufen lassen, erst Name1/Vorname1, dann Name2/Vorname2... Mittelfristig sollte man sich das Datenmodell evtl. dennoch mal überdenken? Beim Thema "Normalisierung - Auflösung von Iterationen" hat da wohl mal einer geschwänzt ;-)

Auf dem Webserver wird ein CMD-Script die Seite dynamisch erstellen. Wie auf anderen das PHP oder ASP-Scripte machen. Zurück kommt HTML-Content.

Lies doch einfach mit "Select * From Tabelle Order by Objekt, Position" aus, dann ist es wurst, wie es mal in der Tabelle stand, es kommt passend sortiert zurück.

DEINE Aussage ist leider falsch! Nicht dem VLAN wird die IP zugeordnet, sondern der Switch bekommt in diesem VLAN eine IP-Adresse.

Wie gesagt, die IPs sind auf Endgeräten, nicht auf Switchports! Wenn ein VLAN auf dem Switch ne IP hat, ist diese über alle Ports, die in dem VLAN sind, erreichbar. Wie NeMix schrieb: Stell Dir das VLAN einfach als eigenen Switch im Switch vor...

Die VLANs haben keine IP-Adresse, sondern die Endgeräte und ggf. der Switch selbst. Über welchen Port Du die Switch-IP pingst, ist in der Regel egal. Der Switch kann, muss aber nicht, in jedem VLAN eine eigene IP haben. Wenn ein VLAN sich über mehrere Switche erstrecken soll, müssen diese VLANs auf den Uplink-Ports getagged werden. Der Unterschied zwischen tagged und untagged ist soweit klar?

Evtl. könntest Du hier auch besser eine der REGEXP_... Funktionen nutzen (z.B. REGEXP_REPLACE ;)) http://docs.oracle.com/cd/B19306_01/server.102/b14200/functions130.htm ... quatsch... wie komm ich'n jetzt auf ORACLE? ;-) ... aber ich könnte mir vorstellen T SQL bietet da auch was!

Prima :)

Ein "SELECT REPLACE(Telefonnr, ' ', '') AS TelOhneLeerzeichen FROM ..." könnte gehen.

Ich denke, wenn Excel auf der CNC läuft, sollte Access Runtime auch funktionieren. Du könntest ja eine einfache Anwendung mit einem Formular für die Arbeitsvorbereitung erstellen und eine weitere Anwendung für den Produktionsleiter. Dort könnten dann auch die Auswertungen rein oder Abfragen, die dann ggf. auch sehr einfach nach Excel exportiert werden könnten zwecks grafischer Aufbereitung. Evtl. solltest Du Dir einfach mal Access ansehen um selbst feststellen zu können, wie schnell man damit brauchbare Ergebnisse erzielen kann.

Ach, Du meintest nur das Frontend...

Gegen Excel spricht, dass Du deshalb hier einen Thread aufmachen musstest ;-)