Jump to content

Drillsergeant

Members
  • Gesamte Inhalte

    187
  • Registriert seit

  • Letzter Besuch

Profile Fields

  • Member Title
    Member

Fortschritt von Drillsergeant

Rising Star

Rising Star (10/14)

  • Erste Antwort
  • Engagiert
  • Erster eigener Beitrag
  • Eine Woche dabei
  • Einen Monat dabei

Neueste Abzeichen

10

Reputation in der Community

  1. Sicher ist das der Holzweg, aber wie gesagt: man kann nicht immer walten und schalten wie man will ¯\_(ツ)_/¯
  2. Das mag ja alles sein, aber der Schalter "häng den Domainnamen an" oder such die Datei in %userprofile%\.... wäre mal richtig sinnvoll! Die meisten von uns werden mit Variablen arbeiten und es tunlichst vermeiden hard coded einen Pfad zu hinterlegen ;)
  3. @Dukel hat es erfasst, aber scheinbar gibt es keine einfache Lösung @NilsK man kann nicht immer walten und schalten wie man will. Seitens MS sind viele Dinge nicht supportet und trotzdem kann man sie verbiegen. Den Domainnamen an den lokalen Userprofilpfad zu hängen wäre die schmerzfreiste Lösung. Die durchschnittliche Profilgröße beträgt bei uns 100 MB, die bei Gigabit Verbindungen und SSD´s schnell zu laden sind.
  4. Die OST liegt im local Teil des Profils und wird somit nicht synchronisiert. Da Outlook sie ggf. im nicht vorhandenen Ordner erwartet, wird sie eben nicht neu angelegt.
  5. Sorry für die späte Antwort, ich war ein paar Tage bescheiden angebunden. Den Cachemode zu deaktivieren hilft den mobilen Usern leider nicht, die haben nicht immer eine Verbindung zur Verfügung. Die lokal zwischengespeicherten Profile zu löschen kam mir auch schon in den Sinn, so fällt es dem User schneller auf, wenn es unnötig groß ist. In den Jahren der Roaming Profiles lernt man aber auch, das lokale Kopie und Serverkopie weit auseinander laufen können und man ggf. die richtigen Daten löscht. Dann wird es wohl über die Jahre rauseitern...
  6. Den Satz habe ich gestern überlesen, möchte dennoch auf meine Ausgangsfrage zurückkommen: kann man den Domainnamen an die Profilverzeichnisse anhängen? Von den Roaming Profiles komme ich so schnell nicht weg und will es auch nicht so wirklich. Auch wenn es hier und da Kopfschmerzen bereitet.
  7. Die OST Datei liegt auch im Local Teil, aber es ist in der Registry hinterlegt das die Datei in einem gewissen Ordner liegt, den es an einem neuen PC nicht gibt. Profil alte Domain: c:\users\%username% Profil neue Domain (gleicher Rechner): c:\users\%username%.domainname Profil am neuen Rechner oder nach Erstanmeldung an einem Gerät:c:\users\%username% --> und die OST aus Profil neue Domain (gleicher Rechner) wird nicht gefunden
  8. Aber im Servergespeicherten Profil steht, das die Datei unter c:\users\%username.domainname. An einem neuen PC wird das Userverzeichnis unter c:\users\%username abgelegt. Nun erstelle ich am Meetingraum PC oder wo auch immer, eine neue OST und der User kehrt an seinen eigentlichen PC zurück, dann steht wieder der falsche Pfad drin. Deshalb fände ich es eleganter den Domainnamen an das lokal Profilverzeichnis zu hängen.
  9. Hallo zusammen, ich stecke gerade in einer Domainmigration und stolpere über den ein oder anderen Stein. Wir setzen Servergespeicherte Profile ein, die lokal unter c:\users\%username% abgelegt werden. Die Profile aus der neuen Domain werden demnach unter c:\users\%username%.domainname abgelegt. Meldet sich der User an einem neuen PC an, findet Outlook die OST Datei nicht mehr. Gibt es eine Möglichkeit den Domainnamen immer anhängen zu lassen? In den GPO Einstellungen für Benutzerprofile bin ich leider nicht fündig geworden und Google stelle ich scheinbar die falsche Frage. Beste Grüße, Stephan
  10. Entschuldigt die späte Antwort. Es gab ein Problem mit der vorgelagerten ASA, welche den Traffic nicht durchgelassen hat. Danke für die Hilfe. Beste Grüße, Stephan
  11. Hallo Newbie, beide Seiten haben extern eine Cisco ASA und dahinter steht ein Microsoft TMG 2010, wobei die ASA eine VPN Verbindung bereitstellt und die TMG´s ein schlichtes Routing durchführen. Es betrifft alle Endgeräte in Russland :-( Einen Tracert kann ich auf beiden TMG´s laufen lassen, melde mich zurück sobald ich dazu gekommen bin. Gruß Stephan
  12. Hallo zusammen, ich kann momentan meinen Kollegen am entfernten Standort nicht hören, er versteht mich wunderbar. Auf beiden Seiten gibt es einen SRST Router, auf meiner dazu einen Callmanger. Sobald er aus Russland auf meinem Handy anruft, erscheint eine Deutsche Nummer, wie es scheint wird die Nummer ersetzt. In der Regel richte ich nur die Telefone samt dazugehöriger Nummer im Callmanger ein und stehe momentan etwas auf dem Schlauch, kann mir bitte von euch jemand helfen? Beste Grüße, Stephan
  13. Hallo zusammen, es funktioniert :) Ausschlaggebend war das benutzerdefinierte http, sodass der Traffic nicht durch den Webproxy gefiltert wird. Ich war bei "all outbound Traffic" davon ausgegangen, das der Proxy seine Finger nicht im Spiel hat. Danke für eure Unterstützung :thumb1: Schönes Wochenende Gruß Stephan
  14. Wie im letzten Absatz beschrieben, müsste bei meiner Regel jeglicher Traffic durch einen Benutzer der Gruppe "Test VPN Users" authentifiziert werden?! So wie ich die Regel im Screenshot aufgebaut habe, würde ich sie im Normalfall definieren, ohne das DMZ3 zum VPN Client senden darf. Gehen wir davon aus, das die Kamera den Stream nach Aufforderung des Clients auf Port 1756 TCP als Stream über einen belibigen Port schicken möchte, hätte sie keine Chance, da sie sich am TMG authentifizieren muss. Verstehe ich das so richtig? Wenn ja, wie kann ich unterschiedlichen VPN Usern, Zugriff auf bestimmte IP Bereiche gewähren? Die Regel wurde als Access Regel angelegt. Eine Umstellung an der Kamera auf TCP, hat keine Änderung bewirkt. Gebe ich DMZ3 den Zugriff auf Internal nicht frei, bleibt es dunkel. Beste Grüße Stephan
  15. Eine allow Any to Any Regel gibt es nicht, im Handbuch der Kamera ist die IP Kommunikation sehr allgemein gehalten. Im Logging des TMG baut der Client auf Port 1756 TCP eine Verbindung zur Kamera auf, um im Anschluss den Stream via UDP (Port nicht definierbar) zu erhalten. Diese Art der Kommunikation wurde vom Bosch Support so beschrieben, deshalb auch die Regel aus der DMZ in Richtung Internal. Entferne ich die Konfigurierte Testregel, fängt die Default rule (deny all) den Traffic ab. Meine Testregel habe ich nach den ersten Posts folgendermaßen aufgebaut. Allow, All outbound Traffic From: Internal, DMZ3 To: DMZ3, Internal; All Users Entferne ich From: DMZ3 To: Internal aus der Regel bleibt das Bild schwarz, Multicast kommt nicht zum Einsatz. @Daniel: Eine Option nur authentifizierten Traffic über die VPN Regel zu erlauben kann ich nicht finden. Gruß Stephan
×
×
  • Neu erstellen...