cj_berlin

Moin, sorry, wenn ich nicht den gesamten Roman gelesen habe und die Antwort da bereits enthalten war, aber eine solche Aktion ist bei vSphere in mindestens drei Logs enthalten, und in mindestens einem davon steht auch, wer sie ausgelöst hat, und mit etwas mehr analytischem Geschick kann man sogar eruieren, von welcher Quell-Adresse und mit welchem Client die dazugehörige Verbindung hergestellt worden ist...

Moin, ob's zu Problemen führt, kommt darauf an, ob - und wo - der Name benutzt wird Wenn Die Domain (und speziell der betroffene User) mit O365 synchronisiert ist, ist dann erst mal das OneDrive weg, kommt aber irgendwann wieder. Eventuell. Für reinen Windows-Betrieb ist es wurscht. Ob irgendeine Applikationen bei der ersten Anmeldung den UPN speichert und ihn dann erwartet, können wir nicht wissen. Tatsächlich sogar an der GUID, wie ich unlängst lernen durfte

Moin, meistens ist so etwas darauf zurückzuführen, dass die virtuelle Netzwerkkarte darunter sich soweit geändert hat, dass sie als neu erkannt wurde. Ist denn die gesamte Konfiguration (wie Du im Text schreibst) oder nur der Default Gateway (wie Du im Betreff schreibst) verloren gegangen?

Moin, das Standardwerk von Thomas Stensitzki umfasst 851 Seiten; Du wirst es uns nachsehen müssen, dass wir es hier nicht referieren. Wichtige Stichworte sind: Autodiscover DNS Resource Records Virtual Directories SAN-Zertifikate Das Standardwerk im Web ist MSXFAQ von Frank Carius, für TLDR-Admins wäre das Web eines anderen Frank wohl eher geeignet. Wenn Du konkrete Fragen hast, wird Dir hier gern geholfen

Das ist korrekt und wäre *vor der Maßnahme* auch mein Rat gewesen. Nun ist der Server aber schon gelaufen, und neben der aktualisierten Config im AD sind möglicherweise auch schon neue Elemente in den Datenbanken. Das Wiedereinschalten der Hyper-V-VM wird also möglicherweise auch nicht nur Regenbogen und Einhörner produzieren.

Schaut mal, ob der Converter die NICs ordentlich bereinigt hat (Stichwort devmgr_show_nonpresent_devices)

Da sage ich nur, iexpress,exe - der Klassiker seit Windows NT (gefühlt)

Moin, wenn Dein Postfach auf einem lokalen Exchange liegt, ist es das erwartete Verhalten.

Moin, das *ist* die Out-Of-The-Box-Konfiguration für Domain Member

Könnte es sein, dass die Verbindung über FQDN einfach per Kerberos abgesichert ist, und die Zertifikate keine Rolle spielen?

Sagt die Meldung beim Aufruf über IP, dass der Name nicht stimmt?

reg add "HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client" /v "AuthenticationLevelOverride" /t "REG_DWORD" /d 0 /f würde für diesen Effekt sorgen

Ich kenne das mit Prinzipalen aus einem anderen Forest, die dort deaktiviert wurden, danach wieder aktiviert, seit der Aktivierung jedoch keine Verbindungen zu dem betrachteten Forest aufgenommen hatten. Aber auch nur vereinzelt.

Moin, entscheidend ist ja nicht, ob das Device AD-Mitglied ist oder nicht, sondern ob die User sich dort mit dem AD- oder mit dem Azure AD-Konto anmelden. Wenn das AD-Konto verwendet wird, ist das Kennwort immer eine Option. Vermutlich könnte man sie irgendwie tottreten, aber vermutlich wäre der Preis dafür auch der Verlust einer möglichen lokalen Anmeldung im Troubleshooting-Fall.

...aber nur mit dem Client/Agent, der auf jede Maschine drauf müsste, zumindest innerhalb eines IP-Segments. Zwei in unterschiedliche Zonen gesteckte NICs in einer Maschine sind das Gegenteil von Netztrennung, das ist Netzbrückung. Jeder Pentester kriegt bei sowas gleich feuchte Augen. Ich würde hier die Windows-Firewall ins Gespräch bringen wollen, und zwar ausgehend von der Annahme, dass die schützenswerten Dinge ein recht modernes Windows-OS haben und die Firewall somit gut funktioniert, also besser als auf XP Dann beschränkst Du mit Policies, wer MIT dieser Maschine kommunizieren darf und auf welchen Protokollen, also nur Inbound Rules. Damit ist es egal, ob in einem Segment oder über Segmentgrenzen hinweg.

Das musst Du aber nur Inboud setzen, nicht Outbound

Execution Policy ist *kein* Sicherheitsfeature. Es ist nur ein Anti-Schludrigkeitsfeature.

https://www.itxperience.net/en/recreating-the-public-folder-hierarchy-active-directory-with-adsiedit/ oder so - dies nicht als Anleitung, nur als Pointer...

Dann: gutes verifiziertes Backup ADSIEdit Beten

Dann lege mal eine neue PFMailbox an (die dann eine sekundäre Hierarchie kriegt) und sage Get-Mailbox -PublicFolder | Update-PublicFolderMailbox -InvokeSynchronizer

Moin, hast Du die öffentlichen Ordner von Exchange 2010 denn migriert?

Den Gateway-Eintrag gibt es aber nur in DHCPv4, nicht in DHCPv6. Daher sind die RAs auch so wichtig.

Das ist nicht korrekt. In der IPv6-Kommunikation spielt der Router immer eine Rolle.

Moin, machst Du stateless oder stateful DHCPv6? Und ist der Router auch derselben Meinung, sprich, schickt er in seinen RAs den O-Flag oder den M-Flag? Und welche Konfiguration in Bezug auf IPv6 hat der DNS-Server? Und wenn Du sagst, dass "Ping auf die IPv4-Adresse geht", meinst Du ping A.B.C.D oder ping -4 A.B.C.D ? (Und falls stateful, warum eigentlich?)

Erahnen wolh eher, denn die beiden IPCONFIG-Listings sind identisch. EDIT OK, doch nicht ganz. Dennoch: Was Du mit NSLOOKUP versuchst, ist ja nur Reverse Lookup, und auch das nur labherzig, denn Du stellst den Abfragetyp ja nicht auf PTR um. Reverse-Auflösung ist fast nie wirklich notwendig, Ausnahmen bestätigen durch ihre Seltenheit die Regel. Da bin ich bei Jan: Welches Problem versuchst Du zu lösen? Bedenke: NSLOOKUP ist nicht identisch mit Namensauflösung, sonst hieße es NAMERESOLVE.