cj_berlin

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.

Nicht mit einem Aufruf. Schleife oder Pipeline halt

Nein, das ist im Computer -Objekt nicht vermerkt. Falls Du allerdings Drucker im AD veröffentlichst, könntest Du von dort die Identität des jeweiligen Servers auslesen.

Moin, kommt darauf an, ob es "Merge Replication" ist oder "Transactional Replication": Replication backward compatibility - SQL Server | Microsoft Learn

Na *dafür* reicht Dir ein selbstsigniertes Zertifikat, wenn alle potentiellen Clients im AD sind und diesen in ihren Root Store per GPO reinbekommen.

DAS ist die wichtigste Frage. Beispiel, wann eine CA pro Site durchaus zu überlegen wäre: es wird 802.1X eingesetzt und die eingesetzten Zertifikate sind relativ kurzlebig WAN-Leitungen zwischen den Sites sind manchmal unterbrochen, und zwar so lange, dass die Downtime des WAN durchaus den Renewal-Zeitraum eines 802.1X-Zertifikats überschreiten kann (ich denke da an Schiffe, Ölbohrplattformen an Land oder im Wasser etc.) Sites sind soweit autark, dass auch ohne WAN irgendeine Art sinnvolles Arbeiten möglich ist. inklusive Authentifizierung. Aber in 99% aller typischen Fälle ist es nicht erforderlich und steigert nur den Verwaltungsaufwand unnötig. Wo man sich sehr wohl Gedanken über Verfügbarkeit und Erreichbarkeit machen sollte, ist die Validierung der Zertifikate, also CDP/OCSP.

Moin, meinst Du, Du willst ein Dual Boot-System mit einer TS bauen? Es ist nicht unmöglich, aber...

Gewiss. Aber Du hast noch kein Szenario. Du hast noch nicht einmal den gewünschten Endzustand formuliert, geschweige denn, dass wir den Ausgangszustand kennen würden. Microsoft beschreibt in Learn/Docs mehrere Migrations-Teilpfade, so beispielsweise auch die Profilmigration, die ich oben zitiert habe. Aber es sind immer einzelne Schritte. Diese richtig zu kombinieren - dafür braucht man eben ein "Szenario". Und nein, es gibt kein "One Size Fits All" best practice. Relativ einig ist sich die globale Community darin, dass ein Hybrid Join viele Probleme aufwirft, aber keinen wirklichen Nutzen bringt. Aber auch das ist nur ein Puzzle-Stück von vielen.

Durch welches Protokoll würdest Du dieses für lokale Accounts ersetzen wollen, wenn Du dir was wünschen könntest?

https://learn.microsoft.com/en-us/sharepoint/redirect-known-folders oder USMT. Am besten, Du holst Dir jemanden an die Seite, der sowas schon mal gemacht hat, zumindest für ein Bainstorming. Du musst den gewünschten Endzustand formulieren und, wenn sich das irgendwie machen lässt, sollte dieser kein Active Directory mehr beinhalten. Aber das geht in einem freien, offenen Forum, wo leute in ihrer Freizeit helfen, einfach nicht.

Der Aufhänger war ja, dass sie für fremde-domain.de keinen Proof of Ownership beibringen können (weil Ownership nicht gegeben ist ).

Und? Auch DNS kannst Du unabhängig von der AD-Domäne fahren. Zone mit der "richtigen" Domain anlegen, fertig. Computername: SERVER01.fremde-domain.de DNS Alias: webapps.eigene-domain.de SPN: HTTP/SERVER01.fremde-domain.de (falls Teile des Service intern zwingend den Hostname verwenden wollen) + HTTP/webapps.eigene-domain.de Zertifikat: SAN=webapps.eigene-domain.de

Davon wird nicht nur abgeraten, das funktioniert auch in vielen Szenarien einfach nicht. Aber: Dir geht's doch eigentlich nur um den UPN-Suffix, um den UPN=email setzen zu können. Das kannst Du zum vorhandenen Forest hinzufügen und für die User dort "einfach" ändern. Anführungsstriche können auch weg, wenn Du genau weißt, welche Anwendungen den UPN benutzen und damit angefasst werden müssen

Hat der 2. DC einen Forwarder eingestellt, der ihm erlaubt, Internet-Adressen aufzulösen? Apropos: Moderne Windows-Versionen (seit Windows 7, wenn ichj es richtig im Kopf habe, vielleicht sogar Vista) agieren nicht mehr mit "primärem" und "alternativem" DNS-Server, sondern fragen beide an und verwenden beide Antworten, wenn sie ohne allzu großen zeitlichen Abstand kommen.

Deswegen erlaubt Franky ja auch NTLM auf dem MAPI vDir Auf OutlookAnywhere wiederum nicht, denn das agiert ja als RPC-Proxy.

Oder ich stupse ihn intern an 😎 Darren sagt, schreib support@sdmsoftware.com an.

Doch, ihr wollt die Domain bzw. den Forest neu machen, denn anders wird es nichts. Je nachdem, wie groß das ganze ist, können 3rd Party Tools euch helfen, das relativ geräuschlos über die Bühne zu bringen. Wenn ihr das allerdings noch nie gemacht habt, werdet ihr Schiffbruch erleiden.

Moin, allein schon die Vorstellung, ein Technologiewechsel könnte mich und meinen Job entbehrlich machen, wäre für mich ein Grund, meinen Lebenslauf sofort auf Vordermann zu bringen. Ansonsten, wenn die Leute ohnehin nur Cloud-Dienste nutzen, musst Du die Maschinen aus dem AD raus und ins Azure AD joinen, und die User melden sich ab dann mit ihrem Azure AD Account an. Wie technisch am besten, variiert je nachdem, was für Hilfsmittel Du on prem hast (laut Deinem Post scheinbar keine) und was in O365 vorhanden ist, also welche Lizenzen.

Ja, 4h, und dort ist es auch explizit im FM beschrieben. Deshalb dürfen auch keine Computer- und Service-Accounts in die Protected Users.

Moin, ja, Events zu generieren, die man nicht verarbeitet, ist performance-technisch von Nachteil. Vermutlich auch für euer Audit-Tool...

Moin, wenn man in seiner Härtung so weit gekommen ist, dass die fehlende Granularität bei RPC-Diensten die letzte verbliebene offene Flanke ist, müsste man doch eigentlich genug Zeit übrig haben, um alle Hersteller von Enterprise Firewalls vorzuladen und eine RPC-LAN-Party zu veranstalten, denn nominal kann eine PaloAlto oder eine Fortinet ja durchaus zwischen RPC-Protokollen unterscheiden und Regelwerke auf dieser Grundlage bauen. Wie gut es dann funktioniert, kann man nur selbst beurteilen --> RPC-LAN-Party.

Also bei Umlauten im sAMAccountName kann es schon kritisch werden. Hatte das bei einer Migration - da wurde das Konto des Herrn KÖNIG auf die Frau KONIG gematcht...

Das war aber eine Antwort auf "wie oft", nicht auf "wie" - Letzteres würde mich tatsächlich interessieren 😀