Jump to content

4zap

Members
  • Gesamte Inhalte

    292
  • Registriert seit

  • Letzter Besuch

Reputation in der Community

13 Neutral

1 Benutzer folgt diesem Benutzer

Über 4zap

  • Rang
    Member
  1. Da bin ich ganz bei dir. Aber manche Entscheidungen vom Management setzt man um, da nutzt kein Diskutieren mehr. Die sind da absolut beratungsresistent. Bei Outlook2016 reicht es wenn ich in die Reg ein paar Keys reinschreibe und der Mailabruf erfolgt dann tatsächlich erst nach Ablauf der gesetzten Zeit. Die GPO schreibt folgendes in die Client reg um den Mailabruf alle 6h auszuführen (falls mal jemand danach suchen sollte)
  2. Hi ich soll einer AD Gruppe per GPO den Mailabrufintervall zentral steuern, d. h. diese Gruppe soll nur alle 6h in Outlook Emails empfangen. Zu allen anderen Zeiten sollen die Emails nicht automatisch eintrudeln. Eine ADMX Vorlage für Outlook2016 hab ich nicht finden können. Mit Procmon hab ich versucht die Reg Änderungen zu erfassen die erfolgen wenn ich das in Outlook selbst ändere, aber da sieht man den Wald vor lauter Bäumen nicht mehr. Hat das schonmal jemand umgesetzt und kann mir Tipps geben? Entweder schreib ich die Werte in der Registrierung um oder es gibt eine ADMX Vorlage, das war zumindest der Plan. (Config: Office365 und Outlook 2016, AD in Azure und onprem) Danke und Grüße Rainer
  3. Huhu kurze Info zum Build 1803. Wir haben den gestern schon über den Business Channel eingespielt bekommen. Offiziell sind wir noch auf 1709. Frisch deployte Win10 Enterprise Maschinen mit 1709 holten sich gestern die 1803 ab, versuchten die Installation und machten dann einen Rollback zu 1709. Es bleiben aber diverse 1803 Steuerungselemente in Windows hängen. Das heißt Installation von Language Packs sind nicht mehr möglich, der Installer kommt nicht mehr klar und so einige andere Geschichten. DAbei ist 1803 noch nichtmal final...also noch beta soweit ich das sehen konnte. Seid vorsichtig mit 1803.... testen ist erstmal angesagt.... am besten erstmal Tee trinken und abwarten mit Upgrade.
  4. Hallo Norbert danke, ticket läuft bereits. Werde berichten worans lag.
  5. Huhu Konstellation Office365 und lokales Outlook2016. über das O365 Portal richten wir für diverse User Vollzugriff auf andere Postfächer ein (Postfachstellvertretung für Urlaubsvertretung etc.). Das Postfach erscheint dann im Outlook nach ein paar Minuten nach Outlook Neustart. Entfernt man den Vollzugriff im O365 Portal von diesen Konten bleibt das Konto als Eintrag aber im Outlook 2016 weiter sichtbar. Ich hab zwar keinen zugriff, kann die Ordnerstruktur nicht mehr erweitern, aber bei mir stapeln sich inzwischen die Postfächer links in der Postfachliste von Outlook. Ich sehe immer noch alle Postfächer, die verschwinden nicht mehr. Stellvertreter bin ich schon lange nicht mehr dafür. Per PS hab ich alle Postfachberechtigungen abgefragt, dort sind keine Stellvertretungen mehr zu sehen. Scheint also ein Bug zu sein. Weiß da jemand wie ich die Postfächer da wieder "unsichtbar" mache? Danke und Gruß
  6. 80% dieser Art von Problemen sind DNS basiert. Die DC's müssen sich sehen können und DNS muss beidseitig in beiden Netzen funktionieren. Trust wird verweigert wenn die Hostnamen bzw. die netbios namen der DC's gleich sind. (was häufig vorkommt). Normalerweise kommt beim Herstellen des Trust die Login Afbrage für den anderen Domänenadmin. Wenn der schon nicht erscheint und der RPC Fehler ausgegeben wird ist es meistens ein DNS oder Firewall Problem. DNS läuft bei unseren Trusts über bedingte Weiterleitung im DNS...
  7. Firewall bei IPSec/IKEv2 Ports aufmachen bzw. weiterleiten. 4500, 500, 50, 51 (glaub ich für ipsec) dazu nehmen.... wenn du einen RRAS betreibst müssen die ports zu diesre IP geforwarded werden. Am Server müssen die ports auch offen sein.... sonst kommten die Verhandlungen über den Tunnel nicht zum Ende.
  8. Hallo Nils, ist ne firmenpolitische Entscheidung, muss ich so akzeptieren. AD FS hat auch Nachteile... Das Azure hat mich gerettet. Der Gastzugriff auf die Services funktioniert auch in der Art wie wir das brauchen. Ist etwas mehr Verwaltungsaufwand aber die Funktion am Ende ist ähnlich und da wird eh jetzt fast zu 100% in der Cloud unterwegs sind passt das so. Ziel erreicht.
  9. Das wäre mögich aber damit werden die mit AaD Connect nicht in Azure repliziert, das war mein Ziel dahinter. Ich hab diverse Unternehmes Apps erstellt die im Office Portal publiziert sind, darauf wollte ich Zugriff gewähren ohne einen ext. AD Account erstellen zu müssen. Auf der anderen SEite müssen brauchen wir die Zugriffsberechtigung auf diverse Sharepoint Instanzen in Asien von unserem Partnerunternehmen. Ist leider ein hybride Struktur, beim Partner etwas mehr als bei uns. Wir könnten evtl. die Azure ADs verheiraten, aber AD FS ist nicht gewünscht. Wie ich das jetzt hinkriegen soll weiß ich jetzt auch nicht. :(
  10. Danke Nils, das hab ich mir schon gedacht. Schade....
  11. Hai musste mal wieder zwei ADs verheiraten. Diesmal bin ich aber "ausgerutscht", d. h. was wir erreichen wollten geht nicht. Ich kann User aus der trusted Domäne B zu unseren lokalen Gruppen an Domäne A hinzufügen. Das geht nur auf lokaler Ebene. Bei globalen oder universellen Gruppen geht die Zuweisung nicht. Ich kann die User aber aus Domäne B für die Clients im AD berechtigen. Die sind ja auch nicht lokal, die replizieren sich ja auch über die DC's über den globalen Katalog. Es ging eigentlich darum User aus der Domäne B globalen GRuppen zuzuordnen. Egal wie ich das verschachtele, sobald ich das versuche heißt es immer das ich die Mitglieder nicht hinzufügen kann. Um mein Ziel zu erreichen müsste ich eigentlich jetzt eine übergeordnete Gesamtdomäne erstellen und bei Domänen als Subdomänen aufnehmen. Das ist aber juristisch nicht möglich, die Möglichkeit fällt weg. Kennt jemand einen Weg User aus Domäne B über den Trust zu globalen Sicherheitsgruppen in Domäne A hinzuzufügen`? Ich vermute nicht... aber ich hab noch Hoffnung. viele Grüße
  12. Recht hast du, ich wollte dann nur noch erwähnen das man einen frischen Client erst Domain joinen kann wenn der DNS "nur" auf den eigenen DC zeigt. Da hilft eine manuelle Netzwerkkonfig am Client vorab. Das war das einzige wirkliche Problem was dort je aufgetreten ist.
  13. Das geht durchaus. Die Netzwerkkonfiguration an den DC's und an den Clients ist aber entscheidend für die reibungslose Funktion. Domain join mal einen Client, da gehts schon los. Da muss man nur darauf achten das lokal DNS richtig konfiguriert ist an den Clients. DHCP macht der DC aus Domäne A DNS machen beide DC's aus A und B Clients aus Domäne A verwenden DNS von DC A Clients aus Domäne B verwenden DNS von DC B Da muss der lokale DNS je nach Lage hart in Reg vom Client gepresst werden, klassenbasiertes DHCP würd hier evtl. noch Sinn machen. Zwei Domänen in einem Subnet bedeutet meist zwei kollaborierende Firmen auf einer Etage und die wollen meist auch quer Zugriff auf Ressourcen beider Domänen. Ein AD Trust macht manchmal Sinn, muss aber nicht zwingend sein.
  14. Alles was ich sehen kann über die PS Abfrage das noch S-1-5-21 .... Zugriff darauf hat. Scheint ein gelöschter exadmin zu sein. Müsste jetzt suchen um den zu identifizieren... Ich stehe nirgendwo mehr als FullAccess oder SendAs drin. Komische Sache das..... ich öffne mal ein Ticket beim Support.
  15. Richtig, aber nur wenn privater Emailverkehr innerhalb des Firmenaccounts erlaubt ist und nicht explizit untersagt wird. Wenn man das im Arbeitsvertrag schon ausschließt darfst du mit den Firmen Emails machen was du willst....
×