Jump to content

jimmyone

Members
  • Content Count

    90
  • Joined

  • Last visited

Community Reputation

10 Neutral

About jimmyone

  • Rank
    Junior Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Hi testperson, erst mal vielen Dank für die Beteiligung an dem Anliegen. Aber die UAC gabs doch 2012 auch schon. Und der Fileserver 2012 verhält sich nicht so wie oben beschrieben. Das wundert mich ein wenig. Ich analysiere das nochmal weiter, was wir auf dem 2012 anders gemacht haben.
  2. Hallo Zusammen, ich habe in meiner DEV oder Demo Umgebung einen Windows Server 2019 Standard installiert. Nun habe ich etwas bemerkt, was ich persönlich so nicht kenne. Lokaler Admin: Im Test für einen zukünftigen Fileserver habe ich ein Testvolume aus unserem Storage angebunden. Im Anschluss habe ich einen Ordner erstellt und habe simuliert, das es sich dabei um das persönliche Verzeichnis eines Mitarbeiters handelt. In this case: Me. Berechtigungen sind folgende: Als Besitzer ist die lokale Administratorengruppe hinterlegt. Im Anschluss habe ich eine Freigabe erzeugt und dann mit meinem Domänen Benutzer den Zugriff und das Handling getestet. Bis hier hin ein normales Verhalten und keine Probleme. Da aber nicht jeder über den lokalen Admin verfügt, sondern es durchaus Gruppen gibt wie die Domänen-Admins oder wie bei uns die Fileserver Admins habe ich diese Gruppen jeweils den lokalen Administratoren hinzugefügt. Naturgemäß war durch den Join zur Domäne die Gruppe Domänen-Admins bereits vorhanden. Nach erneuter Anmeldung an den Server als Mitghlied einer der beiden Gruppen, ob Fileserver Admins oder Domänen-Admins ist egal, hat dieser Benutzer keinen Zugriff auf die Ordner und auch nicht auf seine Eigenschaften. Der Reiter Sicherheit meldet, das keine Lesende Berechtigung vorliegt. Seltsam an der Sache ist, das der angemeldete Benutzer aber Mitglied der loaklen Administratoren Gruppe ist, durch Zugehörigkeit zu einer anderen Gruppe und somit Zugriff haben müsste. Wenn ich nun Zugriff auf den Ordner nehmen will, wird eine Meldung eingeblendet, die mich auffordert "Weiter" zu klicken um hier mit Administratorenrechten zu arbeiten. Klicke ich dann auf Weiter komme ich an den Ordner und seine Inhalte dran. Allerdings wird der Registerkarte Sicherheit mein Benutzer dann als Vollzugriff hinzugefügt. Dieses Verhalten stelle ich so für mich erstmalig fest. Auf meinem aktuellen Fileserver (W2K12) ist das so nicht der Fall. Wenn ich mich dort als Mitglieder einer der beiden Gruppen anmelde ist der Zugriff gewährt ohne Rückfrage und das hinzufügen des Benutzers. Kennt ihr das beschriebene Verhalten? Wir planen den Umstieg von Server 2012 weil Ende 2020 unser Supportvertrag für diese Betriebssystemgeneration ausläuft. Dann liegt natürlich die Idee nahe dies mit dem aktuellen Release zu machen. Mit Server 2016 habe ich das o.a. Verhalten nicht überprüft. Das System hat Stand: 10.0.17763 Grüße Jimmyone
  3. Hallo Zusammen, vielleicht kann hier jemand den richtigen Denkanstoß geben. Exchange 2016 mit dem CU7. Outlook 2013 Konfiguration wie folgt: Im ECP wurde auf dem Freigegebenen Postfach im Bereich Stellvertretung eine AD Gruppe als "Vollzugriff" und dem Recht "Senden als" definiert. Auf dem Postfach selbst eine Gruppe für "nur lesende" Benutzer mit dem Recht Prüfer. Der Benutzer ist nachweislich in der Gruppe die im Vollzugriff der Stellvertretung eingetragen ist. Versucht nun jemand Ordner zu verschieben z.B. "A 2017, B 2017" nach "Kram 2017" , dann erhält er die Meldung: "Der Ordner kann nicht kopiert werden, da er möglicherweise private Elemente enthält." Eine Suche bei MS ergab, es muss eine Berechtigung im Postfach gesetzt werden, die sich "Stellvertretung kann private Elemente sehen" nennt. Dazu muss das Postfach als Profil verbunden werden und das Recht muss über Outlook hinterlegt werden. Link: https://support.microsoft.com/en-us/help/3205975/cannot-copy-this-folder-because-it-may-contain-private-items-error-in Die Lösung ist Ansatz Nummer 3, alles andere ist unpraktikabel. Ich hätte jetzt erwartet, dass an dieser Stelle die über ECP eingetragene Gruppe auftaucht. Stattdessen ist das Objekt leer. Wenn ich da jetzt jede Person einzeln anlegen müsste, geht ja die Grundidee über AD Gruppen verloren. Hat jemand dazu einen schlauen Tipp? Danke! Lieben Gruß Jimmyone
  4. Hallo Zusammen, ich komme nochmal darauf zurück. Ich habe bei Microsoft einen Call geöffnet zu dem Thema. Die Antwort ist irgendwie unbefriedigend. Ich weiß nicht ob der Kollege dort mich nicht verstanden hat (vermutlich dem Name nach Rumäne) oder das Thema tatsächlich so ist. Die Antwort auf die oben gestellte Frage, warum muss ich zusätzlich das Limit eines Default Connectors erhöhen muss, wenn über einen neuen mit höherem MessageRateLimit versendet wird, war die, Mal zusammengefasst: Works as designed in Exchnage 2016. Anbei mal ein Zitat aus der Antwort: Meine Konfig ist meiner Meinung nach in keiner Weise spezifisch. Oder ist ein neuer Connector mit anderem MessageRateLimit so spezifisch das dafür Werte anderer Connectoren angepasst werden müssen? LG Jimmyone
  5. Einen wunderschönen guten Abend, kann jemand von euch ggf. folgendes Verhalten bei einem Exchange 2016 CU7 Version 15.1 ‎(Build 1261.35) bestätigen? Folgender Sachverhalt: Neuer Empfangsconnector. Freigegeben für eine IP innerhalb des Netzes auf einem bestimmten beliebigen Port. Nur für Exchange Benutzer mit Windows Auth und TLS Auth. Bild zu Config der Limits anbei. Verhalten: Nachrichten können über den Connector versendet werden. Limit Einstellungen greifen nicht. Settings des "Client Frontend Servername" werden angewandt. Log meldet Verwendung des "richtigen" neuen Connectors bei Versand über die Applikation. Dienste und Server neu gestartet. Bei Anpassung der Limits des Default und des Default Frontend Connectors auf die gewünschten Werte ist die Versendung nach Maßgabe möglich. Frage: Kann das ggf. jemand bestätigen? ich wundere mich, dass das Transport Log die Nutzung des Connectors meldet und auch die Versendung belegt, die Limits aber vom falschen Connector gezogen werden. LG Jimmyone
  6. Auch wenn das jetzt mal Off-Topic ist: Was bringen denn solch eine Empfehlungen die man immer wieder liest? In der Regel rein gar nichts. Jemand der keine Erfahrung mit dem Umgang und den Projekten hat würde hier nicht nachfragen müssen, wenn die Unternehmen nicht den meiner Meinung nach fatalen Fehler begehen würden und jemandem etwas abverlangen, dass er gar nicht leisten kann. Ganz oft ist: "Such dir einen Dienstleister" für das betreffende Unternehmen schwer machbar insbesondere wenn es kleine Unternehmen sind. Zurück zum Thema: Das Thema scheint nach den vorliegenden Infos kein Exchange Thema zu sein. Wurde an eurem AD DS etwas verändert? Wurden Dateirechte geändert etc. Gibt es Fehlermeldungen im Log des AD? Bist Du dir zum einen wirklich sicher, dass der Benutzer mit dem Du das ganze versuchst auch wirklich die o.a. Berechtigungen hat. Hast Du mal versucht einen zweiten Benutzer mit diesen Rechten zu erstellen? Was passiert, wenn Du AD Objekte ändern willst, z.B. Gruppenmitgliedschaften? Im übrigen stimme ich Norberts Ausführungen zu. Grüße Jimmyone
  7. Welche Berechtigungen hat der ausführende Benutzer? Ich würde das Fehlerlog nochmal bearbeiten und die Klarnamen ggf. herausnehmen.
  8. Guten Morgen Zusammen, ich denke diese Frage lässt sich sehr einfach beantworten und ich vermute die Antwort wird so ausfallen wie ich mir das ganze denke. Sachverhalt: AD Gruppen sind auf Postfächer berechtigt um ein Modell für nur lesende Berechtigungen umzusetzen. Das klappt auch alles ganz wunderbar. Frage: Nicht jeder soll und hat Zugriff auf Exchange. Ich habe bisher die Verteilung in diesen Sicherheitsgruppen selbst vorgenommen über ECP. Reicht es aus, wenn Benutzer über die Anwendung Active Directory Benutzer und Computer den Gruppen hinzugefügt wird? Die Gruppen haben ja bereits alle Exchange Elemente aktiviert insofern gehe ich davon aus das dies reicht. Im Test war es jedenfalls kein Problem aber es könnte sein, dass es hier einen Exchange Experten gibt, der sagt, aus Grund XY kann oder sollte man das nicht machen. Schönen Start in diesen verregneten Tag. Jimmyone
  9. Nein, es war meine Aussage. Da es auch meine Umgebung ist, kann ich sicher sagen, dass kein Cache Mode aktiviert ist. Das ist eine 100% sichere Sache. ;)
  10. Hi, die Version des Exchange lautet: Version 15.1 ‎(Build 1261.35) Der Cache Modus ist deaktiviert weil das eine Vorgabe ist. Argumente für Cache Modus wurden abgeschmettert. Ist mir aber auch egal und für das "spannende" Problem nicht weiter relevant. :) ;) Seltsam finde ich das der Full Client einen Termin meldet aber OWA nicht. "Kennen" also von schon mal gesehen könnte ich das nur andersrum bestätigen. War auch mein Ansatz. Hier gehen leider Realität und so sollte das sein auseinander. Danke für den Tipp bezgl. mfcmapi. Es war Sonntag und ich auf einem Weihnachtsmarkt mit den langweilisgten Menschen die es gibt. :cry: Da habe ich einfach behauptet ich muss mal arbeiten. :p :D :rolleyes: Sorry ich weiß das jede Info von Wert ist die man kriegen kann. Jimmyone
  11. Hallo Zusammnen, in der Umgebung gibt es keinen Cache Modus für Exchange, das heißt die Ansicht ist immer Online. Ich werde mich zurück melden, sobald ich weiß wie sich das System verhält wenn man einen Termin einsetzt. Mir fällt gerade auf, dass ich gestern den wichtigen Hinweis unterschlagen habe, dass es sich bei dem Benutzer um ein Migriertes Postfach handelt, welches von IBM Domino übertragen wurde. Jedoch gab es keinen besonderen Fehler für dieses Postfach. Ist denn der Zugriff auf Inhalte grundsätzlich unterschiedlich zwischen OWA und Outlook? Grüße Jimmyone
  12. Die Anzeige funktioniert auf jedem Client. Nur nicht in owa. Exchange ist auf CU7 Outlook kann ich nicht auswendig sagen zur Zeit. Aber recht aktuell. Wird per WSUS versorgt. Lg Jimmyone
×
×
  • Create New...