testperson

Wer ist denn der Provider? Vermutlich leitet der nichts weiter, da der MX Record im öffentlichen DNS auf eure feste IP zeigt. Daher teste doch mal von extern, ob du per telnet <öffentliche IP> 25 # oder telnet <A-Record auf den euer MX zeigt> 25 auf der Firewall oder ggfs. auf dem Exchange landest.

OT: Da Versicherungen im Allgemeinen ja keine barmherzigen Samariter sind, würde ich alleine aus dem Zitierten genügend Gründe lesen, dass in den meisten Fällen nicht reguliert wird. :) Ein Blick in die Policen würde vermutlich weitaus mehr Gründe liefern. Wenn ich die Beiträge, die bei unseren Kunden aufgerufen wurden, noch richtig im Kopf habe, bleibt da auch nicht viel anderes übrig. Bei einem Kunden musste ein von der Versicherung zertifizierter Dienstleister sogar rauskommen und mit dem ITler bzw. uns als IT-DL das System prüfen und abnehmen. Was dann geschah, nennt man in Köln "Klüngel" und beinhaltete eine wunderschöne Werbeveranstaltung. ;) BTT: Für die Home-Office-Kennwort-Wechsel-Problematik: Auf regelmäßige Änderungen des Kennwortes verzichten. :)

Hi, ich würde das Aufgebaute erstmal wieder abschalten und mir ganz schnell Hilfe holen. Mal abgesehen davon, dass man auf einem Root Server keinen Virtualisierungs-Host betreibt, wie steht es mit Backup (und Restore)? Was machst du wenn der Server ausfällt? Wie ist das lizenziert? Um das halbwegs in den Griff zu kriegen: Zum vorhandenen externen vSwitch einen neuen internen vSwitch erstellen "Firewall Appliance mit VPN Funktion" installieren und das externe Interface mit dem externen vSwitch verbinden / internes Interface mit dem internen vSwitch verbinden Auf dem externen vSwitch Interface der Firewall eine MAC mit öffentlicher IP nutzen / auf dem internen Interface private IP Adresse nutzen VMs mit privaten IPs austatten und vom externen vSwitch trennen und an den internen vSwitch verbinden VPN konfigurieren und verbinden Auf der Firewall eingehend alles (außer VPN) blocken Zugriff aus dem Büro / von zu Hause per VPN über die Firewall Gruß Jan

Hi, als erstes würde ich am Notebook Firmware und Treiber auf den aktuellsten Stand updaten. Danach weiter sehen. Gruß Jan

Ja klar, aber ich finde den Preis i.O. für Support und Updates und ich muss nicht "alles" selber zusammensuchen und "scripten" / planen etc. Im Worst-Case waren es $60 für ein bisschen "Spielen".

Für die WSUS Wartung habe ich mir heute mal WAM von AJTek gönnen lassen. Mal schauen, wann ich zum spielen testen komme. :) Auf der Website finden sich übrigens auch Best Practices sowie generelle / weitere Infos zum WSUS.

Das dauert ein wenig. Beschleunigen kannst du das durch Neustart der Transport Dienste. Hat das Senden / Empfangen denn noch funktioniert während / nachdem du von 2010 -> 2016 migriert hast?

An welcher Stelle bist du denn? 2010 -> 2016 oder schon 2016 -> 2019?

Hi, was findet sich denn in den SMTP Logs auf dem Exchange? Protokoll-Logging aktivieren (und Logs finden): https://docs.microsoft.com/en-us/exchange/mail-flow/connectors/configure-protocol-logging?view=exchserver-2019 Gruß Jan

Hi, wenn "kein / minimales Budget" da ist, würde ich als erstes mal nach RPO (Wie viel Datenverlust ist akzeptabel) / RTO (Wie lange darf das System ausfallen) fragen. Also ab wann der Strick um den Hals eine Überlegung sein könnte. Gruß Jan P.S.: "Das AD" setzt sich bei 40 Mitarbeitern hoffentlich aus mindestens zwei DCs zusammen (die natürlich nicht auf dem gleichen HyperV laufen sollten).

Nur so zur Vorsicht: Und BTW: In PowerShell wäre es wohl noch einfacher (und zur Not kann man in einer Batch auch einfach die PowerShell.exe mit Command starten). # https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.management/start-process?view=powershell-7 Start-Process ... -Wait

(Normale) User sollen mit administrativer Shell hantieren?

Hi, ich glaube das was du vor hast, habe ich mal mit VBScript erledigt und in der Batch dann per cscript / wscript ausgeführt. Generell wäre die Frage, warum Batch und nicht PowerShell? 'VBS Option Explicit 'Variabeln deklarieren Dim objWSH,objWMI,objWMIService,Proc,P,Weiter 'Erstellen der Objekte Set objWSH = CreateObject("WScript.Shell") objWSH.Run "<Pfad_zur_EXE>.exe", , true 'Hier geht es erst weiter wenn das Programm beendet wird Gruß Jan P.S.: Das habe ich irgendwann mal gefunden und benutzt.

Hast du dir die Ereignisse auch durchgelesen? Liefert eines deiner Ereignisse evtl. schon eine Lösung?

Hi, schau ins Eventlog "Anwendungs- und Dienstprotokolle" -> "DFS-Replikation" bzw. auch in "Directory Service". Gruß Jan

Es sind max. ein bis zwei Hände voll. Da ist es halt praktisch, dass viele unserer Kunden so oder so alle eine Smartcard von DATEV haben, mit der man das eben umsetzen kann. Ein Kunde testet das grade mit RCDevs und Softtoken.

Dem kann man ja mit einem zweiten Faktor (Smartcard / Yubikey / Token) entgegen wirken. Ebenfalls gibt es Möglichkeiten zu überwachen, von wo eine Anmeldung versucht wird / erfolgt. Sollten bei einer Behörde dann Anmeldeversuche / Anmeldungen aus China o.ä erfolgen, dann ist wohl was faul im Staate Dänemark Deutschland. ;)

Und dann kommt die "Duo Bypass App" um die Ecke: https://blog.workinghardinit.work/2019/11/13/the-darwin-award-with-mfa-push-notifications/ oder der User bestätigt eben jede Anfrage :-D

Hm.. RTFM? https://docs.microsoft.com/en-us/microsoftteams/teams-for-vdi https://docs.microsoft.com/en-us/microsoftteams/msi-deployment

Halt stopp. ;) Nils' hat es oben eigentlich schon angemerkt. Die MAC Adresse ändert sich nicht bei / nach der Livemigration sondern erst wenn die VM danach neu gestartet wird. "Abgestimmt" sind die nur mit SCVMM und MAC address pools. Ansonsten generiert der Host die: https://support.microsoft.com/en-us/help/2804678/windows-hyper-v-server-has-a-default-limit-of-256-dynamic-mac-addresse

Das ist jetzt auch kein wirklich sachdienlicher Hinweis, aber nutze jetzt die Chance und dokumentiere das, was du wie auch immer jetzt aufspürst. Generell: Dokumentation. ;) Ebenfalls für die (nahe* not foreseeable) Zukunft: Wenn du alle LDAP-anfragenden System gefunden hast, prüfe, welche der Systeme unverschlüsseltes / -signiertes LDAP sprechen und konfiguriere auf secure LDAP / LDAPs um: https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/ADV190023 * Der Artikel wurde scheinbar erneut angepasst und aus der 2ten Jahreshälfte 2020 wurde die nicht absehbare Zukunft.

Ja klar, allerdings sollte dann auch eine entsprechende Ansage ohne 2FA helfen. ;) Natürlich kann man Ansagen mit was Neuem einfacher verargumentieren wie etwas zu ändern, was doch schon immer so gehandhabt wurde.

Hi, für die Zukunft könnte man auch einen Loadbalancer für solche LDAP Anfragen implentieren. Dann hast du immer nur eine IP / einen Namen und tauscht dahinter einfach die Server-Objekte aus. (Laut Microsoft ist das allerdings unsupported: https://social.technet.microsoft.com/wiki/contents/articles/33547.load-balancers-and-active-directory.aspx) Gruß Jan

Meinst du, derjenige der seine Account-Daten weitergibt, wird dann nicht bei 2FA auch den Code weitergeben bzw. blind alles absegnen? Da müsste der 2te Faktor ja schon SmartCard / Yubikey o.ä. sein, was man aber auch weiterreichen kann. Sowas lässt sich vermutlich nur organisatorisch und mit Konsequenzen abschaffen.

Hi, schalte für die VM doch testweise einmal bei den Integrationsdiensten den "Datenaustausch" aus. ;) Generell würde ich beim Hersteller nicht lockerlassen und auf Lösung bzw. Unterstützung bestehen. Gruß Jan