cj_berlin

vor 2 Minuten schrieb fynn.pf:

Ich habe jetzt herausgefunden, dass Remote-Desktop nur mit der IP und nicht mit dem Hostnamen/Domain funktioniert, kann man da eventuell das Problem schon eingrenzen???

 

Das Problem aus Deinem OP nicht, aber offensichtlich kommt noch hinzu, dass die Namensauflösung in diesem Konstrukt nicht so funktioniert wie von Dir erhofft.

Wie wäre es, wenn Du mit ein paar Konkretika hilfst?

• bei welchem Hoster liegt das ganze?
• welche Domain/Hostname, wo kommt der her?
• welche Fehlermeldung kriegst Du?

vor einer Stunde schrieb NorbertFe:

Aber gerade bei Domain members wird der dhcp dahingehend überschätzt. Das regelt seit Vista alles nicht mehr der dhcp Client sondern der DNS Client. ;)

...und in dem typischen "Notebook in einem Bürohochhaus"-Szenario (jede Stunde Netzwerkwechsel, weil pro Etage andere IP-Subnetze gelten) funktioniert es auch bei modernen Betriebssystemen eher bescheiden. DHCP hingegen trägt jedes Mal schön die in diesem Augenblick aktuelle Adresse ein.

Und um die Reverse-Auflösung kümmert sich der DNS Client kein Bisschen, wie auch schon der DHCP-Client vor ihm - es gibt aber tatsächlich noch Produkte, die sie brauchen, und Kunden, die sie wollen.

Vermutlich liegt es daran, dass nicht alle Ports hin zu diesem Server offen sind. Wie greifst Du denn darauf zu? VPN? Oder geht direkt RDP aus dem Internet?

Re DHCP: Erschwerend kommt hinzu, dass nur die Kombination "Windows DNS + Windows DHCP" es Dir ermöglicht, bei dynamisch vergebenen IPs zuverlässig A- und PTR-Records zu erstellen, zu aktualisieren und zu löschen.

Das ist das, was ich eingangs mit VLANs und IP-Helpern meinte  

vor 2 Minuten schrieb Dukel:

Manche machen das so professionell, dass sie das kommerziell anbieten. Nennen sich IT Dienstleister.

...doch auch diese beherrschen nicht die Kunst der Gedanken-Osmose.

@JoVo59 Du musst Deine Anforderungen so präzise beschreiben, dass daraus klar wird, *was* gemacht werden muss. Im Prinzip musst Du daraus der besorgten Userin eine erschöpfende Antwort auf die Frage geben können, was sie genau auf dem neuen System machen kann und was nicht. Und wenn Du soweit bist, wirst Du feststellen, dass der größte Teil des Aufwandes - den Dir aber niemand abnehmen kann, außer vielleicht Dein Vorgesetzter - bereits erledigt ist. Für den Rest kannst Du dann die zuhauf im Internet vorhandenen Tutorials auf Deine Anforderungen projizieren.

vor 15 Minuten schrieb testperson:

warum installierst du einen Broker und machst dann "DNS Round Robin"?

 

 

Weil das unter 2008R2 so war  

vor einer Stunde schrieb soulseeker:

Kann ein 10Gbit SFP+ Kupferport denn überhaupt 10 Mbit aushandeln?

Es ist nicht generell ausgeschlossen (z.B. MikroTik-Module können das). Aber  verlassen würde ich mich, wie die Vorredner schon sagten, nur auf die Aussage des Herstellers. Dabei geht es tatsächlich sowohl um das SFP-Modul als solches als auch um den Switch.

vor 4 Minuten schrieb Dukel:

Oder man nutzt einen Alias (ab jetzt, wenn noch nicht passiert) für die Server.

Das musst Du jetzt bitte erklären. Die Config ist doch trotzdem an den Maschinennamen gebunden und muss umgeschrieben werden, wenn sich dieser ändert...

Moin,

wenn die Signierfunktion bei beiden CAs bereits auf SHA256 oder höher upgedated wurde und es Dir um das reine Betriebssystem-Upgrade geht, ist es wurscht, in welcher Reihenfolge Du das machst. Ich würde immer mit der Root anfangen, aber das wäre in diesem Fall keinem technischen Grund geschuldet, sondern der Gewohnheit.

Falls die Issuing CA kurzlebige Zertifikate per Autoenrollment ausstellt (Stichwort 802.1X) solltest Du die Downtime für diesen Anwendungsfall ankündigen, denn Deine Migration wird viel geschmeidiger, wenn die 2019er Maschinen die Computernamen der alten Server erben.

Moin,

wenn es um die Erreichbarkeit von draußen geht, muss *jemand* auf öffentliche IP-Adressen hören. Klar geht einiges - aber nicht alles! - mit NAT, aber bereits beim Reverse Proxy muss doch dieser ein Bein im "großen Schwarzen" haben.

Daher gibt es so etwas wie "private DMZ", die oft private IP-Adressen haben und mit dem Internet nur über NAT/PAT verbunden sind, und "öffentliche DMZ", wo die einzelnen Hosts tatsächlich öffentliche IP-Adressen haben.

Wenn es ausschließlich um die Sicherheitszonen-Zuordnung geht, ist es egal, aus welchem Pool die IP-Adressen der DMZ-Hosts kommen, solange es nicht LAN ist und die Firewalls korrekt konfiguriert sind. Aber wenn man z.B. multitier-Anwendungen in der DMZ hat, dann sieht man häufig den Frontend-Tier in der öffentlichen DMZ, während Applikations- und Datenbank-tier in einer privaten DMZ sind.

Wenn ich das beeinflussen kann: Hashregeln, d.h. konkrete Executables explizit berechtigen.

Hast Du die Möglichkeit, da ein Gerät reinzubringen, das noch nie an diesem Netz dran war und schauen, ob das einen Lease kriegt? Er fordert ja scheinbar eine bestimmte Adresse an, das wäre also eine Verlängerung. Die kann ihm der Windows-DHCP natürlich nicht bieten.

Falls der DHCP-Server virtuell ist: Einfach noch eine VM am gleichen vSwitch. Dann wäre die Physik ja außen vor.

Wie @Nobbyaushb richtigerweise schrieb: auf der SOPHOS nach Möglichkeit nicht Bereiche, sondern den gesamten DHCP-Dienst deaktivieren, denn ein aktiver Dienst ohne Bereiche antwortet ja auch mit nem NACK.

Hmmm.

• Der Bereich ist aktiviert?
• DHCP-Policies sind keine am Start?
• Leases mit dem Namen BAD_ADDRESS zu sehen? (das wäre ein Hinweis auf Kollisionserkennung)

DHCP sollst Du auf DCs grundsätzlich nicht betreiben  Ist zwar nicht ganz so schlimm wie Print Server, aber dennoch eher zu vermeiden.

vor 1 Minute schrieb Nobbyaushb:

Ergänzend - warum ist im Titel 3ter DHCP drin?

das heißt wohl "Drittanbieter"  

Moin,

es ist "rogue DHCP", nicht "rough".

Bekommt der Windows-DHCP denn überhaupt Anfragen? (Wireshark + Debug Log des DHCP)

Moin,

ich würde einen DC nicht gern umbenennen. Wenn Du durchgehend Redundanz haben willst, einfach den zusätzlich DC3 installieren und nach Abschluss der Maßnahme wieder entfernen. Und die Bestands-DCs herunterstufen, aus AD entfernen, Replikation und KCC abwarten, nachbereinigen und dann den 2019er DC gleich in der richtigen Kombination aus Name und IP hochstufen.

vor 17 Minuten schrieb zahni:

Das soll Netdom wohl machen.

Dann kontrolliere es doch  

Moin,

wenn 's am rogue DHCP liegt, siehst Du es in den Logs am DHCP-Server . Aber was einfacheres: Habt ihr mehrere VLANs in eurem Netz und wohin zeigen die IP-Helper in diesen VLANs? Oder ist es so ein Mini-LAN, in dem alle Adressen aus demselben Segment sind, und in diesem Segment stehen dann auch die SOPHOS und der neue DHCP Server?

vor 3 Stunden schrieb testperson:

Anstatt die User maximal einzuschränken bzw. alles was dich stört auszublenden / zu verbieten würde ich "nur" auf App Locker setzen. Vorgeben würde ich auch nur das wirklich Benötigte.

So isses. AppLocker oder, besser noch, WDAC und genau wissen, wie man den Server im Zweifel schnell neu macht.

Die Diskussion "Monster-VM" vs. "viele kleine Monsterchen-VMs" würde ich bei 10 Usern, ehrlich gesagt, nicht führen. Denn auch in einer Umgebung mit 1000 Usern würde eine "kleine Monsterchen-VM" vermutlich für mehr als 10 User auisgelegt werden.

vor einer Stunde schrieb dieter_e:

Würde das so funktionieren?

Moin,

nein, würde es nicht. Mir würden außer "unsupported" und "wird nicht funktionieren" noch mindestens drei Gründe einfallen, warum man es lassen sollte  

Und Postfächer einzeln zu migrieren verursacht Null Downtime für die User, im Gegensatz zu dem, was Dir vorschwebt. "Einzeln" bedeutet ja dank PowerShell nicht, dass man sie auch einzeln anfassen muss  

Ja, die Vorlage heißt auch 'Machine':

'Computer' ist nur ihr Künstlername...

vor 41 Minuten schrieb Clawhammer:

der CA hängt 10min in der Vergangenheit.

 

Somit ist keine Kerberos-Authentifizierung Richtung CA möglich  

vor 42 Minuten schrieb Clawhammer:

... manuel kann ich die Zeit auch nicht einstellen O.o

...und warum nicht?

Moin,

meine Erfahrung sagt: Entweder zwei Monate oder zehn Jahre, Platten ausgenommen. Nach drei Jahren tauschst Du die Lüfter, nach weiteren drei Jahren die Netzteile...

Will damit sagen: Es wird eher passieren, dass keine der benötigten Software mehr dieses Modell unterstützt, als dass der Server wirklich stirbt.