5
DNS-Suffixe via lmhosts
Hallo zusammen,
ich habe folgendes Problem:
In unserer Umgebung gibt es mehrer AD´s
bsp:
server1.dom1.de
server2.dom2.de
client.clientdom.de
nun war es bisher so, daß wir bei unseren Clients in den DNS-Settings die suffixe
dom1.de
dom2.de
clientdom.de
de
eingetragen haben. Dies haben wir nur auf den Admin-Arbeitsplätzen gemacht, weil es halt nervig ist, dauern den FQDN mittippen zu müssen.Die Domänen-Namen sind in Wirklichkeit länger und abstrakter, ich darf sie halt nicht öffentlich machen
Nun wurden über Policies für ALLE Clients in der clientdom.de die Suffixe vorgegeben....bsp:
clientdom.de (brauchen wir ja damit unser ClientAD sauber läuft
)
app.de (beispielzone für im DNS registrierte Applikation, bsp browserbasierte)
Leider können die AdminPC´s nun die servernamen der dom1.de und dom2.de nicht auflösen, ohne den kompletten FQDN händisch zu tippen...weil die Policies die lokalen Einstellungen der Admin-Clients überschreiben.
Wie kann ich nun trotzdem eine lokale Lösung für meine Clients erreichen?
lmhosts? Wie müssten ggfs. die Einträge lauten?
Grüße und Dank vorab!
Chakoe
ich habe folgendes Problem:
In unserer Umgebung gibt es mehrer AD´s
bsp:
server1.dom1.de
server2.dom2.de
client.clientdom.de
nun war es bisher so, daß wir bei unseren Clients in den DNS-Settings die suffixe
dom1.de
dom2.de
clientdom.de
de
eingetragen haben. Dies haben wir nur auf den Admin-Arbeitsplätzen gemacht, weil es halt nervig ist, dauern den FQDN mittippen zu müssen.Die Domänen-Namen sind in Wirklichkeit länger und abstrakter, ich darf sie halt nicht öffentlich machen
Nun wurden über Policies für ALLE Clients in der clientdom.de die Suffixe vorgegeben....bsp:
clientdom.de (brauchen wir ja damit unser ClientAD sauber läuft
)app.de (beispielzone für im DNS registrierte Applikation, bsp browserbasierte)
Leider können die AdminPC´s nun die servernamen der dom1.de und dom2.de nicht auflösen, ohne den kompletten FQDN händisch zu tippen...weil die Policies die lokalen Einstellungen der Admin-Clients überschreiben.
Wie kann ich nun trotzdem eine lokale Lösung für meine Clients erreichen?
lmhosts? Wie müssten ggfs. die Einträge lauten?
Grüße und Dank vorab!
Chakoe
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 122747
Url: https://administrator.de/forum/dns-suffixe-via-lmhosts-122747.html
Ausgedruckt am: 06.04.2025 um 18:04 Uhr
5 Kommentare
Neuester Kommentar
Wie wäre es denn einfach für die Admin PCs eine eigene OU mit der man denen das Problem erschlägt?
Servus,
ganz ehrlich - das macht man mit dem DNS /DHCP oder Per Policy.
Aber da du nicht schreibst - wer welche Policy auf welchem Server OS wo eingerichtet hat...
Fragst du am besten den, der das eingerichtet hat
Gruß
ganz ehrlich - das macht man mit dem DNS /DHCP oder Per Policy.
Aber da du nicht schreibst - wer welche Policy auf welchem Server OS wo eingerichtet hat...
Fragst du am besten den, der das eingerichtet hat
Gruß
Also:
es sind alles 2003-AD´s mit 2003er Servern und XP Clients.
Über die Möglichkeit einer zusätzlichen OU für Admin-Clients wird momentan beraten.
Aber:
Gäbe es noch eine andere Möglichkeit? Kann man in der LMHOSTS derartige Einträge generieren,
daß es die Einträge in der DNS-Suffix-Liste adäquat ersetzen kann?
Grüße
es sind alles 2003-AD´s mit 2003er Servern und XP Clients.
Über die Möglichkeit einer zusätzlichen OU für Admin-Clients wird momentan beraten.
Aber:
Gäbe es noch eine andere Möglichkeit? Kann man in der LMHOSTS derartige Einträge generieren,
daß es die Einträge in der DNS-Suffix-Liste adäquat ersetzen kann?
Grüße
Servus,
Gegenfrage(n)
Oder andersherum, kennst du den Unterschied zwischen Toyota und DNS?
Pfusch am Bau wird von mir nicht unterstützt.
Wenn schon keine eigene OU - keine Ahnung - warum man da erst noch "beraten" muß - dann
Gruß
Gegenfrage(n)
- wer hat euch den auf die Idee mit LMhosts gebracht?
- und was hat der gelernt?
Oder andersherum, kennst du den Unterschied zwischen Toyota und DNS?
Pfusch am Bau wird von mir nicht unterstützt.
Wenn schon keine eigene OU - keine Ahnung - warum man da erst noch "beraten" muß - dann
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Searchlist
sollte dann ja für einen Admin mit den nötigen rechten auf HKLM kein Ding sein.weil die Policies die lokalen Einstellungen der Admin-Clients überschreiben.
den letzten beissen die Hunde, und wer sagt, das die Policy der letzte ist?Gruß
Hi,
genau da sind unsere bisherigen Einstellungen (vor der Einführung der Policy) ja gesetzt....
Zieht aber nicht mehr. Ersichtlich beim ipconfg /all
Also scheint die Policy ja tatsächlich zu überschreiben.
Grüße
genau da sind unsere bisherigen Einstellungen (vor der Einführung der Policy) ja gesetzt....
Zieht aber nicht mehr. Ersichtlich beim ipconfg /all
Also scheint die Policy ja tatsächlich zu überschreiben.
Grüße
