AFM_Adm

Traffic ist TCP auf Port 443, verhält sich auch ähnlich mit Intune. Der Windows 11 Client baut ein Großteil der Verbindungen zu MS Cloud (Azure) über den Proxy auf, ein kleiner Teil versucht direkt raus zuquatschen. Solange dieser Traffic nicht erlaubt ist, kriegt der Client auch keine Softwarepakete von Intune.

vor einer Stunde schrieb Gu4rdi4n:

Ich nehme mal an ihr nutzt SSL inspection?

Das ist nicht supported von Microsoft soweit ich weiß.

 

https://learn.microsoft.com/en-us/mem/intune/fundamentals/intune-endpoints?tabs=north-america

Danke für den Hinweis, aber nein machen wir für die genannten FQDN's nicht. Aber selbst wenn, dann würde der Traffic nicht sauber durch den Proxy durch gehen, aber würde ja nicht erklären, wieso Anfragen vom Client zum Teil ja erst garnicht auf dem Proxy ankommen, sondern versuchen direkt Richtung Internet zu quatschen. Oder was ist dein Ansatz?

Moin zusammen,

wir nutzen einen Proxy für den Zugriff Richtung WAN. Nun soll auf den Windows 11 Clients Intune, Azure Virtual Desktop etc. genutzt werden. Der Proxy ist in den Systemeinstellungen vom Windows 11 Client hinterlegt.

Generell wird der Proxy auch verwendet, dass sieht man im Log, jedoch versucht der Client bestimmten Traffic direkt Richtung Azure Cloud zu schicken über die Firewall.

Habt ihr Erfahrung mit Intune, Azure Virtual Desktop und Proxy, wie kann ich den Client dazu bringen, den gesamten Traffic Richtung Proxy zu schicken? Oder ist dies nativ in den Services, etc. zu tief verankert, dass es nicht möglich ist einen Proxy dafür zu nutzen?

Wie ich herausgefunden habe wurde dies zum 01.10.2022 für alle Tenannten aktiviert: Azure Security Defaults (msxfaq.de)

Am 21.10.2022 um 12:57 schrieb Squire:

Was spricht dagegen eine Policy auf Deinen Firewalls zu setzen, dass die Clients mit den DCs an Standort A und B wechselseitig reden dürfen?

Hätte doch auch den Vorteil, dass die Clients bei Ausfall des DCs am Standort immer noch mitspielen dürfen. Nebenbei (1 DC pro Standort finde ich etwas dünn - abhängig von der Anzahl der User ...)

 

Was mir noch einfällt ... ich denk mal Dein DC an Standort A hält die PDC Rolle ... manche Vorgänge am Client erfordern eine Verbindung zum PDC. Deshalb .. lass die Clients mit dem DC am Standort A reden

 

Aus verschiedenen Gründen sollen nur die DC's am eigenen Standort verwendet werden.

Am 21.10.2022 um 18:35 schrieb cj_berlin:

Welche? Ich habe Umgebungen, wo Clients noch nie einen schreibbaren DC gesehen haben, vom PDCe ganz zu schweigen.

Was bei DFS-N sein kann, ist, dass es im "Consistency Mode" konfiguriert ist (Default-Einstellung). Du brauchst den "Scalability Mode".

Danke für den Tipp. Aber geht es bei dem "Scalability Mode" nich darum, dass die DFS-Stammserver den DC am gleichen Standort nutzen oder was hat dies mit den Clients zu tun?

Moin zusammen,

wir bekommen seit ein paar Tagen die Aufforderung wenn man sich an Microsoft365 anmeldet, MFA einzurichten und das man hierzu 14 Tage Zeit hat. Bewusst aktiviert haben wir dies nicht, wird anscheinend durch MS erzwungen. An Sich ist MFA ja auch eine tolle Sache, nur haben leider nicht alle User ein Smartphone.

Welche Möglichkeiten habe ich, wie löst ihr das? Durch Whitelisting, etc.?

Bekommt ihr auch seit ein paar Tagen die Aufforderung zur Einrichtung? Leider finde ich keine Ankündigungen dazu.

vor 17 Stunden schrieb daabm:

 

Ich versuch's noch mal: Was _genau_ versuchen sie zu erreichen?

Domain based DFS? Beide DCs als Namespace-Server? Target-Shares in beiden Standorten vorhanden und verfügbar? Fragen über Fragen

Du hast Fragen, Du suchst Lösungen. Dann mußt Du auch Input liefern.

Moin, Domain Based DFS - Ja. Beide DC's als Namespace-Server - Ja. Target-Shares - jeweils nur die Shares am eigenen Standort verfügbar.

vor 32 Minuten schrieb teletubbieland:

Naja, unter Active Directory Standorte und Dienste. Ob Du die IP Bereiche getrennt hast.

Ja, es gibt zwei Standorte mit den entsprechenden Subnets.

vor 21 Stunden schrieb teletubbieland:

Hast Du denn die Standorte im AD auch getrennt ?

 

Wie meinst du das?

vor 19 Stunden schrieb daabm:

 

Was _genau_ versuchen sie zu erreichen? Also welcher Prozess auf dem Client versucht welchen Dienst auf dem DC zu erreichen?

Und wIe gesagt, AD ist nicht DNS. AD ist site aware, aber DNS nicht.

Zum DC Locator: https://techcommunity.microsoft.com/t5/ask-the-directory-services-team/domain-locator-across-a-forest-trust/ba-p/395689

Da steht zwar auch noch "across forest trust", aber die Grundlagen sind auch dabei.

Es geht um Zugriff auf ein Filesystem per DFS und muss daher die Domäne auflösen können.

vor 9 Minuten schrieb NilsK:

Moin,

 

ich habe das Problem jetzt nur halb durchdrungen, vermute aber, dass du das Automatic Site Link Bridging abschalten musst.

 

Gruß, Nils

 

Dies würde doch nur Sinn machen, wenn die DC's sind nicht direkt erreichen könnten bezgl. Replikation?

Moin zusammen,

folgende Problemstellung habe ich (vereinfacht dargestellt):

2 Server-Netze (Standort A und B mit jeweils 1 x DC), 2 Client-Netze (Standort A und B). Die Server-Netze können untereinander kommunizieren, die Client-Netze nur mit dem Server-Netz am gleichen Standort.

Bei der Namens-Auflösung der Domäne beispiel.local im Client-Netz B, gibt der DC im Server-Netz B, beide DC's wieder (den von Standort A und von Standort B), kann den DC an Standort A aber nicht erreichen. AD Sites und Services ist konfiguriert und den entsprechenden Subnetzen der richtige Standort zugewiesen. Mit "nltest /dsgetsite" getestet wird auch der korrekte Standort angezeigt auf dem Client.

Die Clients am Standort B versuchen aber immer den DC am Standort A zu erreichen. Was für Lösungsmöglichkeiten gibt es hier?

Am 20.5.2022 um 15:12 schrieb teletubbieland:

Bevor hier Niemand antwortet...

Ich habe das Problem umschifft, indem ich bei Notebooks keine Ordnerumleutung mache und den Usern klar mache, dass Sie Daten, die sie überall haben wollen, eben auf dem Netzwerk ablegen sollen (User Home).

 

 

Was machst du mit dem Desktop, etc.? Was machen die Notebook-User, wenn diese Offline arbeiten wollen?

Am 20.5.2022 um 15:51 schrieb testperson:

Hi,

 

wäre evtl. OneDrive eine Option für euch? Alternativ hol die User zu den Daten und nicht die Daten zu den Usern -> Remote Desktop Bereitstellung.

 

Gruß

Jan

Und für Desktop, etc.? Klappt nicht offline oder?

vor 23 Stunden schrieb Sunny61:

Auch wenn es schon länger her ist, wir arbeiten mit Ordnerumleitungen und Offline Dateien. Für verschiedene Fileserver bietet sich DFS an.

Wie sind deine Erfahrungen hinsichtlich Offline Dateien, klappt das zuverlässig?

vor 21 Stunden schrieb daabm:

Wieso netlogon.log? Zitat: "Note The log file can be found at: %windir%\debug\usermode\fdeploy.log" - ob das noch stimmt, weiß ich nicht mal Wir nutzen FR schon lange nicht mehr.

Und ja, geht auch ohne die FR-GPO-Einstellungen zu verwenden. Steht sinngemäß in meiner Blog-Serie von oben, mußt nur die Reg-Werte passend setzen.

Was nutzt ihr statt Folder Redirection denn?

Clients sind aktuelle Windows 10 Systeme mit Patches. Serverseitig Windows Server 2016 mit aktuellen Patches.

Hallo zusammen,

wir nutzen zur Zeit servergespeicherte Profile, da die User öfters die Arbeitsplätze bzw. Rechner wechseln und damit die Notebook-User ihr Profil Offline dabei haben. Leider sind bei Nutzung der servergespeicherten Profile die Anmeldezeiten durch den Sync sehr lang und gibt es hin und wieder auch mal Probleme damit.

Die Alternative von MS sind ja Ordnerumleitungen. Hierbei hätten wir aber zwei Herausforderungen: 1. Nutzung offline bei den Notebooks bzw. im Homeoffice bevor die VPN-Verbindung steht. 2. Haben wir mehrere Standorte und mit standortbezogenen Fileservern, auf die dann die Ordnerumleitungen zeigen müssten. Wenn die User dann an den verschiedenen Standorten sind, hätten sie verschiedene Profile.

Wir löst ihr diese Herausforderungen oder gibt es für das Szenario ein Best-Practice Ansatz? 

vor 15 Minuten schrieb testperson:

Und die SMTP Logs vom Exchange und Smarthost schweigen?

Im SMTP Log vom Exchange steht nur folgendes:

250... Recipient ok,
DATA,
"354 Enter mail, end with '.' on a line by itself",
*,,"HandleError has encountered a suspicious connection reset from a remote, non-mailbox transport server."
-,,Remote

vor 30 Minuten schrieb testperson:

Hi,

 

nimmt der lokale Exchange die Mail nicht von eurem vorgeschalteten Postfix an oder wird er die Mail nicht beim Smarthost los? Ich würde dann zusätzlich im SMTP Log vom Postfix oder eben Smarthost nach weiteren Infos suchen.

Spontan:

• Ist auf dem Exchange ein AV installiert, der im SMTP Traffic rumpfuscht?
• Ist eine Firewall dazwischen, die im SMTP Traffic rumpfuscht?

Gruß

Jan

Doch genau, der lokale Exchange nimmt die Mail vom Postfix an und wird sie dann beim Smarthost nicht los und hängt in der Queue vom lokalen Exchange. Im Log vom Exchange finde ich auch nur den Fehlercode den ich im ersten Post geschrieben habe.

Auf dem Exchange sind nur die MS-Boardmittel, keine 3rd-Party Tools oder Scanner installiert. Firewall prüft zwar den Verkehr, aber habe in den Logs nichts gefunden und testweise die Security-Features deaktiviert gehabt ohne Erfolg.

Die externen E-Mails werden in der DMZ vom einem Postfix angenommen und anschließend an den internen Exchange 2016 weitergeleitet. Für einen bestimmten Adressraum (Subdomain) werden E-Mails per Smarthost an ein anderes internes System (TK-Anlage) weitergeleitet.

Dies funktioniert auch wie im Eingangspost beschrieben seit Jahren ohne Probleme, nur bei externen E-Mails die ihren Ursprung von Office365 (Exchange Online) haben, gibt es diese Probleme.

Moin zusammen,

ich habe ein Problem das E-Mails die von externen Absendern von Exchange Online (Office 365) rein kommen und per Smarthost an ein anderes internes System weitergeleitet werden mit folgenden Fehler in der Queue auf unserem lokalen Exchange 2016 (aktuelle Patches) liegen bleiben:

3;2;[{LED=450 4.4.318 Connection was closed abruptly (SuspiciousRemoteServerError)};{MSG=};{FQDN=};{IP=};{LRT=}];0

Dies passiert nur von externen Absendern die Exchange Online nutzen, ich habe dies selbst nachgestellt mit einem Office 365 Testaccount und konnte das Problem nachvollziehen. Von anderen externen Absendern, z.B. Freemailer, etc. tritt das Problem nicht auf.

Hatte jemand von euch schonmal das Problem in Verbindung mit Exchange Online Absendern bzw. hat eine Idee oder einen Tipp?

vor 13 Stunden schrieb NorbertFe:

Vielleicht, weils bei mir eben nicht nachvollziehbar ist ;) Wie du siehst, ist da nix grau. Außer ich hab jetzt das Problem komplett falsch verstanden.

 

Und alle diese Räume hab ich erst am Freitag bei uns angelegt. Da ist also "keine" Sonderbehandlung über die Jahre passiert.

Werden bei dir die Räume als verfügbar gekennzeichnet? Siehe rechter Teil von meinem Screenshot.

Ist wohl ein bekanntes Problem laut MS. Es wundert mich aber, wieso ihr keine Probleme damit habt!?

https://docs.microsoft.com/de-DE/outlook/troubleshoot/calendaring/no-available-rooms-for-meeting-outside-working-hours

Ich habe mal noch ein bisschen getestet, leider ohne Erfolg. Das einzige was wirklich hilft ist die Arbeitszeit im persönlichen Kalender zu ändern.

Anbei mal ein Screenshot, der Raum ist in diesem Beispiel nur bis 13.00 Uhr reservierbar, er wird in der Kalenderansicht auch ab diesem Zeitpunkt ausgegraut dargestellt, ist laut der Raumliste aber verfügbar. Und ab 17.00 Uhr taucht er nicht mehr auf als verfügbarer Raum in der Raumliste auf, außer ich ändere meinem persönlichen Kalender die Arbeitszeit z.B. auf 18.00 Uhr, dann kann ich diesen Raum bis 18.00 Uhr buchen.

Das Verhalten in OWA ist identisch, daher schließe ich Outlook als Problem jetzt auch mal aus.

vor 2 Minuten schrieb Nobbyaushb:

Wenn sich das Verhalten nicht geändert hat müsste man jetzt in die Tiefe gehen - ich bin mir nicht sicher, ob das über das Forum klappen kann

 

Und ja, das DeleteSubject hat nichts mit dem Verhalten zu tun, wir haben aber Displays von TouchOne draussen vor den Türen und da muss man das setzten
(empfehle ich sonst immer....)

 

Ja, ok für so Displays sollte man das aufjedenfall machen :)

Danke schonmal für die Hilfe! 

Wie gesagt, ich kann das Verhalten ändern, wenn ich die Arbeitszeit in den Kalenderoptionen meines persönlichen Kalenders ändere. Dafür müsste ich jetzt aber die Arbeitszeit von allen Usern per Powershell ändern. Ich kann mir vorstellen das es "leichte" Irritationen auslöst, wenn ich jetzt die Arbeitszeit der User im Kalender ändere.

vor 49 Minuten schrieb tesso:

Hast du händisch mal eine längere Zeit eingegeben?

Wo meinst du?

vor 1 Stunde schrieb Nobbyaushb:

Baue mal Testweise einen Raum/Ressource mit Autoaccept - würde mich jetzt direkt interessieren, ob der Fehler weg ist.

Per Default ist ja DeleteSubject auf True, das braucht man aber z.B.

Ich hänge mal den Output von unserem Konf-1 anonymisiert an (ich hoffe, nix vergessen...)

konf1.txt 3 kB · 3 downloads

Das Verhalten hat sich mit AutoAccept nicht geändert.

Was meinst du mit DeleteSubject? Das sollte doch mit diesem Problem nicht zu tun haben, da es dabei ja um die Anzeige des Betreffs im Kalender geht.