Moin, da ich anhand anderer Beiträge mittlerweile alle Probleme in der Domäne gefixed habe, fehlt nur noch der Aufbau einer neuen Zertifikatsstelle mit Windows Server. Die „alte“ aktuelle ist nicht mehr wirklich funktionsfähig.
Nun die Frage, wie entferne ich die alte sicher? Passiert dann was? Was für Zertifikate muss die neue bereitstellen?
Irgendwie per auto enrollment Kerberos für die DCs? Und weiter?
Habe das noch nie gemacht. Kann ich was kaputt machen? So das nix mehr geht?
Ich tippe auf Sonderzeichen im Namen. Hatte ich schon öfter. Meistens kann man es umbenennen. Einfach sicher gehen das alle Zeichen ersetzt wurden. Ansonsten per CMD löschen
Ist wahrscheinlich die Ansicht noch nicht aktualisiert ... ... kann, häufiger bei Netzwerklaufwerken, vorkommen.
- F5 zum manuellen neu laden - Im Task.Nager den Explorer beenden 7nd neustarten - bei NetzwerkLW auf dem Server nachsehen, z.B. über Netzwerke 8im Explorer
spätestens nach einem Neustart sollte das aktuell sein ...
klappt denn das löschen über cmd mit "rmdir c:\users\justm\Musik\Axwell" ?
Falls nein, was sagt ein cmd "attrib c:\users\justm\Musik\Axwell" zu den Attributen des Ordners?
Wenn der Ordner nur nicht mehr sichtbar sein soll(macht aber wenig Sinn, nimmt ja Platz weg) Rechtsklick auf den Ordner -> Eigenschaften im Reiter Allgemein unten versteckt anhaken -> ok. Das funktioniert aber nur wenn du versteckte Dateien nicht unter den Ordneroptionen von Windows anzeigen lassen hast. Standardmäßig werden versteckte Dateien und Systemdateien aber ausgeblendet.
Ich will dieses Verzeichnis entfernen, Windows hat da jedoch andere Pläne! Kann ich das Verzeichnis irgendwie löschen beziehungsweise nicht mehr sichtbar tun? Weiß allerdings nicht mehr, wie ich das angestellt habe 😅!
Mal per Konsole in den Container verbinden und während des versuchten Zugriffs auf die GUI die Logs kontrollieren, checken ob der GUI Prozess überhaupt läuft und aus dem Container Testweise auch mal raus pingen
/container shell [find hostname="pihole"]
Ansonsten auch mal mit dem Sniffer des Mikrotik kontrollieren ob der Webzugriff überhaupt zum Container durchkommt, wenn ja, wird es eher ein Berechtigungsproblem im Container sein, die gibt es gerne mal nach Upgrades, und dann hilft immer das Neuerstellen des Containers.
je nachdem was du willst - du kannst natürlich z.B. Bluetooth-Beacons verwenden und da schon recht genau die jeweilige Distanz zum Beacon erfassen. Jetzt wäre also MEIN Ansatz das ich verschiedene Mitarbeiter frage ob die an einem Test teilnehmen würden. Die bekommen irgendein Mobil-Tel mit ner App die eben genau diese Beacons erfasst in die Tasche (oder ans Handgelenkt,... was auch immer). Wenn jetzt ein Weg umsonst war müssen die nur "BS-Weg" antippen (Bush Weg ;) ). Da du ja die Zeit hast weisst du dann ggf. schon warum die dahin gegangen sind.
Du kannst das ganze über div. Möglichkeiten machen - RFID (sehr kurze Distanzen), BT-Beacon (schon etwas längere distanzen),... Und du brauchst am Ende somit nur gucken wie weit die Distanz von verschiedenen Beacons war um zu wissen wo der Mitarbeiter war.
OB dir das am Ende weiterhilft - ich glaube eher weniger.... Denn je nachdem was dein Ziel sein soll wird es technisch unmöglich das rauszufinden. Denn: Ist ein Weg jetzt überflüssig weil ein Mitarbeiter ggf. ins falsche Regal-Abteil gegangen ist? Das heisst ja nicht das der WEG falsch war, es war nur einmal zu früh abgebogen ODER ggf. hat der Mitarbeiter aus dem letztem Auftrag noch im Kopf gehabt das der da was nachschauen wollte... Technisch wirst du also da keine sichere Lösung haben - Wege aufzeichnen würde darüber aber halt gehen.
wenn einmal eine Auditpolicy konfiguriert wurde und jetzt plötzlich die Anmeldung ewig dauert hört es sich für mich leicht nach einem Speicherplatzproblem an, haben die DCs genug Platz? Ansonsten
An einem der Clients nach dem Kabeltrick mit der Anmeldung und danach wieder eingestecktem Kabel unter cmd ein "gpresult -h gpos.html" absetzen warten bis die html erzeugt wurde und dann mit "start gpos.html" die Datei öffnen. Das Standardprogramm für html sollte dann die Liste der angewandten und abgelehnten Gpos anzeigen.
Hierüber dann prüfen welche Gpo es sein könnte, anhand der angewandten Gpos, auch hilft die Ereignisanzeige, die sollte einen Fehler ausgeben unter "System" zum Zeitpunkt der Anmeldung.
Die Ereignisanzeige der DCs auch entsprechend prüfen.
Der Container läuft auf einem RB5009/USB-Disk Die Stable Version 7.16.1 ist drauf. Hab die Config mit und ohne VLAN ausprobiert. Die IP 172.17.0.2 für PiHole ist von allen Devices , egal wo aus dem Netzwerk pingbar, nur das WebGui läuft nicht. NAT und Firewall-Regeln sind eingestellt, im LogFile gibt es keine Fails, alles ist successfully started....
Werde am WE mal den Container neu anlegen... danke für den Tipp
Da ich man mittlerweile nicht mehr einfach zurück auf stable 7.15.3 kann, weil stable mittlerweile 7.16.x ist, scheue ich mich noch, es wieder zu versuchen, bis ich eine Idee habe, wonach ich dann schauen soll. Weil meine Familie in der Zeit mit betroffen ist.. mieser WAF und DAF (wife and daughters :D) Werde es am WE dann wohl wieder versuchen, deine Tipps prüfen und Config exportieren. Da es bei Dir funktioniert, ist es wohl machbar und schafft Zuversicht. Bin allerdings kein Experte und kämpfe durchaus mit den Tiefen eines MT. Und beim letzten Versuch habe ich nach langen Nacht mit probieren und ohne Schlaf aufgegeben.
Container neuanlegen ist ein guter Gedanke, allerdings hat es nichts gebracht, das hatte ich bereits versucht.
Container geht nach Update auf 7.16.x nicht mehr. Weder pihole, noch mosquitto.
Kann ich nicht bestätigen. Sowohl Mosquitto als auch ein pihole laufen nach Upgrade auf 7.16 vor Wochen und auf 7.16.1 einwandfrei in ihren VLANs!
Welche Hardware?
Connectivity via Container-Shell und ip a und Ping auf relevante IPs gecheckt?
Export der Mikrotik Config und Ausgabe der NIC Config im Container wären hilfreich fürs Debugging.
Ansonsten hilft bei Container-Problemen das Neuanlegen des Containers in den meisten fällen. Konfiguration hat man ja meist eh in separaten Mounts abgelegt so daß das Neuanlegen fix erledigt ist.
Container geht nach Update auf 7.16.x nicht mehr. Weder pihole, noch mosquitto.
Nach dem Update starten beide Container scheinbar normal, aber irgendwie isoliert:
Das Webfrontend von pihole ist nicht mehr erreichbar, und der Container hat kein DSN Outbound.
Ich sehe Pakete in FW und DSTNAT, aber überhaupt nicht in SRCNAT.
Die Shell ist erreichbar und z.B. "pihole -d" sieht ok aus, bis auf fehlendes DNS (wie im LOG bereits beim start).
Ähnlich bei mosquitto: Läuft, aber MQTT Explorer kann nicht connecten. Alles andere funktioniert (VLAN, USB-Drive, CAPsMAN,...)
Zurück auf "stable" 7.15.3 laufen beide Container wie bisher und seit Monaten völlig problemlos
Irgendwelche Ideen, was sich in >= 7.16.x geändert haben könnte (Bridges, VLAN, DNS, Container,..), dass dieses Verhalten der Container erklären könnte? Habe schon Stunden experimentiert und mir gehen die Ideen aus. Nach was sollte ich schauen?
Danke für jeden Hinweis, um endlich mit funktionierenden Containern auf 7.16 zu gehen - nicht zuletzt für das nette mDSN-feature...
dann hatte ich wohl gestern nur Glück, dass keine eigenen Transport-Regeln in meinem Exchange 2019 existierten oder könnte es sein, dass es dort welche gab und diese sind jetzt weg?
nee, da ist nix weg... ich tippe auf, du hattest keine! also, wenn da regeln wären, würden die irgendwann nach 10 Minuten nicht mehr greifen! ein Neustart des EX-Transports bringt für 10 Minuten linderung...
Auf alle Fälle läuft bei mir alles, wie es sollte - habe zumindest nichts anderes bemerkt.
Prima..
PS: Nachrichtenfilter werden bei mir im Symantec Messaging Gateway eingerichtet, speziell SPAM und AV-Filter.
200-300 Meter gelten immer nur unter Laborbedingungen ohne Störungen, Reflektionen, Fremdsender, etc. Und als Gegenstelle einen ebenso optimalen Sender und kein Smartphone mit Mini-Antenne. Also Bedingungen, die Du nur irgendwo in der Wüste findest :-P 40 Meter sind hier schon recht gut, ich hätte jetzt weniger geschätzt.
Laut Beschreibung sollte die Reichweite des APs im 2,4GHz Band bei rund 200 - 300 Meter liegen. Allerdings bricht bei meinem Smartphone die Verbindung bereits nach ca. 40 Meter (Sichtlinie) ab.
Wahrnehmen wird das Smartphone das WLAN wahrscheinlich auch noch über größere Entfernungen, aber es wird keine Verbindung mehr retour zusammenbringen.
Muss man etwas spezielles Einstellen oder ist die Angabe von 200 Meter einfach übertrieben?
Kanalbreite bei 2,4GHz auf 20MHz runterstellen bringt eventuell noch was. Überschneidungen bei den Kanälen benachbarter WLANs wirst du dir ja angeschaut und vermieden haben.
Das Wireguard Tutorial zu der Thematik hast du genau gelesen und entsprechend umgesetzt?? 🧐 Merkzettel: VPN Installation mit Wireguard Was das Proxmox Netzwerk Handling der Firewall anbetrifft auch hier und hier.
Grob zu den Fehlern im o.a. WG Setup:
Völlig FALSCHE interne WG IP Adresse im Server! Dort hast du unsinnigerweise eine Netzwerk IP angegeben statt einer Host IP. Siehe dazu Adressierungshinweise im o.a. Tutorial!! Lesen hilft wirklich!
Port 5000 ist ein weltweit fest registrierter IANA Port. Sowas zu verwenden ist gelinde gesagt für einen Netzwerk Admin wie dich nicht Gentlemen like! Hier solltest du dich immer an die von Wireguard propagierten Ephemeral Ports im Bereich 49152–65535 halten! Wie oben und im Tutorial schon gesagt ist der Listen Port am Client nicht erforderlich sondern einzig nur auf der Serverseite!
PostUP, Table usw. Kommandos gehören da nicht rein.
Zusätzliche Preshared Keys sind überflüssig wenn man schon mit Keys arbeitet.
Die MTU ist im Default 1420 so das dein höherer Eintrag eher kontraproduktiv ist und entfernt werden sollte.
Keepalive muss nicht so hart sein, 25 Sek. tun es auch
Zum Rest hat Kollege @150940 oben schon alles gesagt. Korrigiere das und halte dich bitte genau ans Tutorial was alles haarklein auch für Laien erklärt, dann kommt das auch sofort zum Fliegen!
Die Server Config in den Client importieren zu wollen ist ja wohl nicht dein Ernst 😂?! Also erst mal ne vernünftige Client-Config erstellen und die Server Config fixen, dann klappt's auch mit der Nachbarin.
Bin bei einem OEM (im Broadcom Jargon "VAO - Value Added OEM") tätig.
Blöde Frage:
Zitat von @Roland567: Wir im öffentlichen Gesundheitswesen müssen halt noch wirklich auf's Geld schauen. Und wie oben geschrieben, werden wir wohl auch gut mit der Standard Version klar kommen.
Dürft ihr denn überhaupt vSphere Standard kaufen? Je nach Einordnung in Broadcoms Kundensegmentierung seid ihr doch gezwungen VCF bzw VVF zu lizenzieren.
Wir als OEM können Standard und Enterprise Plus jedenfalls generell nicht mehr anbieten. Besten Dank Brdcm... 😤
ich habe einen TP-Link Omada EAP610-Outdoor, AX1800 Accesspoint für einen Außenbereich auf einem Mast montiert. Laut Beschreibung sollte die Reichweite des APs im 2,4GHz Band bei rund 200 - 300 Meter liegen. Allerdings bricht bei meinem Smartphone die Verbindung bereits nach ca. 40 Meter (Sichtlinie) ab. Es sind in der Umgebund noch weitere W-LAN Netzwerke vorhanden.
Das 5GHz Band wurde beim TP-Link Omada vorerst mal deaktiviert.
Muss man etwas spezielles Einstellen oder ist die Angabe von 200 Meter einfach übertrieben?
... Ein zusätzliches c ändert nur die Fehlermeldung insofern, .....
Ich habe das so gelöst, dass ich in dem Pfad, indem die *.xlam Datei liegt, eine Kopie der *.xlam erstellt habe, und bei der Kopie den ersten Buchstaben weglösche. (aus administrator.xlam wird dministrator.xlam) geht bei mir tadellos
Kann ich nicht bestätigen, hier ist es egal was für zusätzliche Files drin liegen wird eh nur nach *.MP3 Endungen gefiltert ... Bei dir passieren echt merkwürdige Dinge😀. Me out.
"Gute Systeme"...was kann ich mir darunter jetzt vorstellen?
Cisco Catalyst, Ruckus ICX, Juniper, Extreme & Co. Die NetGear und TP-Link Fraktion natürlich nicht. Ist doch immer die gleiche Netzwerk Leier.
Dann müsste SwOS das ja eigentlich auch können
Wie denn?? SwitchOS kann rein gar nichts an Layer 3 Funktionen außer dem Management IP Zugriff. Sieht man ja auch im Setup wo sämtliche L3 Funktionen erwartungsgemäß fehlen.
Hallo Zusammen, ich brauche mal wieder einen Rat von euch. Ich habe folgende Konstellation:
OPNSense FW - PromoxVE - Debian (wireguard)
Den Weg aus dem Netz über das WAN der OPNSense mit dem Port und der IP zum Debian Wireguard Server mit Webif. Zum Test scanne ich den QR Code mit dem Smartphone und das Telefon steigt mit einer Fehlermeldung aus.
18 Gig wäre ein reiner "Phantasiewert", denn das Hashing (egal was) bestimmt ja immer nur auf welchem physischen Memberlink eines LAGs eine Session gelegt wird. Da die physische Link Speed durch die Ethernet Infrastruktur immer fest vorgegeben ist ist die unveränderlich. Ein physischer 10Gig Link kann also technisch niemals auf 18 Gig "hochgetaktet" werden. Die Daten der Session fliessen also imemr nur mit 10Gig.
Sorry - ich hätte ein wenig weiter ausholen müssen: Zwei 10G im LACP, ein 40G QSFP+ auf der Gegenseite. Logisch, dass ein 10G Link nicht mehr als 10G kann
LACP LAGs haben durch die unterschiedliche Address Entropie egal ob L3 oder L2 nie eine homogene Auslastung. Das wird umso schlechter je weniger Attribute in die Hash Berechnung einfliessen. Gute Systeme nutzen die Adresse, die VLAN ID (sofern vorhanden) und den TCP/UDP Port. Das erhöht die Granularität bei der Verteilung.
"Gute Systeme"...was kann ich mir darunter jetzt vorstellen? ;) Dass ein Linux Kernel das höchstwahrscheinlich besser kann, als das etwas halbherzige Teaming von Microsoft wäre jetzt z.B. etwas, was ich mir darunter vorstelle...
Kann SwOS denn überhaupt Layer 2+3 oder wirklich nur simples Layer 2?
Das ist eine gute Frage! In der regel ist es so das reine L2 Switches nichts von höherliegenden Layern "kennen", sie "sehen" also immer nur auf Layer 2 also Mac Adressen. Ein Port ASIC solch einfacher Switches müsste also deutlich tiefer ins Paket sehen als nur den einfachen L2/Mac Header. Ein Feature was oft ausschliesslich bei Premium Switches gegeben ist das solche ASICs in der Entwicklung deutlich teurer und aufwendiger ist was im LowBudget Bereich rein nach Preis kaufender Clientel so gut wie nie gefordert ist. Sofern der SwitchOS MT also keine Auswahloption beim LAG Hashing Algorithmus hat kannst du zu 90% davon ausgehen das er auch nur L2 macht. Weitere Infos zur LAG Thematik, wie immer, HIER.
Naja - laut Wiki kann der CRS326-24S+2Q+mit RouterOS Hardware Layer3 Offloading. Dann müsste SwOS das ja eigentlich auch können...aber ich finde da keine Infos oder ich hab sie übersehen...bzw. ich finde auch generell keine Infos darüber, selbst im Mikrotik-Forum ist der Info-Gehalt relativ dürftig...
So, ich habe die FLAC-Dateien (Ordner) herausgenommen, nun hat das funktioniert. Alle MP3-Dateien enthalten nachkontrolliert Genre-TAGS.
Sollte nicht der „.mp3“-Filter das überspringen????
Doch das tut er mit dem Filter korrekt, aber wahrscheinlich sind da mp3 Files dabei bei der denen der MS Filter die Tags nicht extrahieren/interpretieren kann und dann leer sind, kann man aber ausfiltern indem du die Zeile so schreibst
Gibt es hierzu von jemandem einen Lösungsansatz? Haben genau das gleiche Problem. Sobald der SEP Client auf den Systemen ist geht nichts mehr. Besonders auf den Hyper-V Servern ist die Performance so schlecht, dass das Gruppenrichtlinien Update abbricht. Ein Feature des SEP kann es nicht sein, da wie bereits in dem Post beschrieben alle AV Features deaktiviert sind.
Doch doch. ich hab in mein Quellverzeichnis $sourceroot = "d:\Musik\Alben“ Ordnerweise Alben mit MP3-Dateien gefüllt. Je Album ein Ordner, in dem sich dann die MP3-Dateien Befinden. In den Unterordnern befanden sich weitere Unterordner (leer, namens „CD1“), die ich nun gelöscht habe. Fehlermeldung bleibt. Es gibt einige Alben in FLC, die sollte aber bei dem angewendeten Filter „.mp3“ nicht stören.
18 Gig wäre ein reiner "Phantasiewert", denn das Hashing (egal was) bestimmt ja immer nur auf welchem physischen Memberlink eines LAGs eine Session gelegt wird. Da die physische Link Speed durch die Ethernet Infrastruktur immer fest vorgegeben ist bleibt diese unveränderlich. Ein physischer 10Gig Link kann also technisch niemals auf 18 Gig "hochgetaktet" werden. Die Daten der Session fliessen also immer nur mit 10Gig von einem Port zum anderen. Durch den LAG kommt es aber zu einer Verteilung auf die einzelnen Memberlinks und damit zu einer Verteilung der Auslastung an sich. 802.3ad basierte LACP LAGs haben durch die unterschiedliche Address Entropie, egal ob L3 oder L2, nie eine homogene Auslastung. Das wird umso schlechter je weniger Attribute in die Hash Berechnung einfliessen. Gute Systeme nutzen die Adresse, die VLAN ID (sofern vorhanden) und den TCP/UDP Port. Das erhöht die Granularität bei der Verteilung.
Kann SwOS denn überhaupt Layer 2+3 oder wirklich nur simples Layer 2?
Das ist eine gute Frage! In der Regel sieht es in der Realität so aus das reine L2 Switches nichts von höherliegenden Layern "kennen". Sie "sehen" also immer nur auf den Layer 2, also Mac Adressen. Ein Port ASIC solch einfacher Switches müsste also deutlich tiefer ins Paket sehen als nur den einfachen L2/Mac Header um L3 Informationen der Frames auswerten zu können. Ein Feature das solche ASICs in der Entwicklung deutlich teurer und aufwendiger werden lässt und was oft ausschliesslich bei Premium Switches gegeben ist. Im LowBudget Bereich rein nach Preis kaufender Clientel aber so gut wie nie gefordert bzw. verbaut ist. Man erkennt es daran das auch bei reinen L2 Switches eine Auswahloption des Hashing Algorithmus gegeben ist. Sofern der SwitchOS MT also keine Auswahloption beim LAG Hashing Algorithmus hat kannst du zu 90% davon ausgehen das er auch nur L2 macht. Weitere Infos zur LAG Thematik, wie immer, HIER.
Dann hast du wohl keine Unter-Ordner in dem Verzeichnis, das Ding sortiert ja Ordner anhand deren erster MP3 Datei ein keine MP3 Dateien separat . Klappt hier wie gesagt im Test einwandfreie, ansonsten passieren bei dir merkwürdige Dinge wenn sich da Dinge von selbst ändern. Mal nen Malware scan machen.
Dort hast du unsinnigerweise eine Netzwerk IP angegeben statt einer Host IP. Siehe dazu Adressierungshinweise im o.a. Tutorial!! Lesen hilft wirklich!
