DerOlele

Hallo zusammen, wir haben etwas weiter "Jugend Forscht" gespielt und eine zugehörige sekundäre Zone in den Reverse Lookup Zonen erstellt und dort ebenfalls das Zone Transfers aktiviert. Das hatten wir irgendwie vergessen. Die Namensauflösung funktioniert nun. Wir konnte nun auch den Trust aufbauen. Nochmals danke für Eure Unterstützung. VG Thorsten

Hallo zusammen, sorry für die Verzögerung wegen der gewünschte Antwort. Hatte gestern einen Incident und dieser hatte dann entsprechend vorrang. Hier die Rückmeldung. Hoffe die bringt euch was was....musste das leider teilweise anonymisieren.... Hier nochmals als Text und entsprechend anonymisiert: > 10.10.100.3 Server: DC1.inhouse Address: 10.112.0.51 *** DC1.inhouse can't find 10.10.100.3: Non-existent domain > set type=soa > local.int Server: DC1.inhouse Address: 10.112.0.51 *** DC1.inhouse can't find local.int: Non-existent domain > set type=ns > local.int Server: DC1.inhouse Address: 10.112.0.51 *** DC1.inhouse can't find local.int: Non-existent domain > set type=a > condor.local.int Server: DC1.inhouse Address: 10.112.0.51 *** DC1.inhouse can't find condor.local.int: Non-existent domain > Sorry nochmals für die Verzögerung..... VG Thorsten

Guten Morgen Allerseits! Konnte erst heute Morgen nochmals die Abfragen ausführen, da ich erst heute wieder Online war. Bei allen Abfragen kommt immer die Antwort Non-Existent Domain zurück. Ich frage mich langsam, was hier die Namensauflösung verhindert.....ob hier nicht doch was von der FW blockiert werden könnte und wie ich das herausbekommen kann, damit ich meine Kollegen aus dem Netzwerkbereich um Abhilfe bitten könnte.

oben bereits beantwortet. Aber hier gerne noch einmal: nein, es geht leider nicht. Die Namensauflösung geht nicht: Non-existent Domain

Hallo Habe ich soeben nochmals versucht. Geht leider nicht. Non-existent domain kommt dann zurück. Evtl. wird hier doch noch was geblockt..... Ich hab mal auf meinem DC das Tool PortQuery laufen lassen mit der Zieladresse des DCs in der anderen Umgebung und mit Service to query: Domains and Trusts.... Das Log hängt bei.... also ich seh geradr vor lauter Bäume den Wald nicht mehr, Sorry..... :-( PortQuery_from_10112051_to_10101003_new.txt

Hallo Nils, Vielen Dank für die superschnnelle Rückmeldung. Also ich hatte gestern bereits mal eine Sekündäre Zone neu eingerichtet. Und der Stand war dann heute immer noch der gleiche wie gestern: Da hat sich leider nichts getan. VG Thorsten

Hallo zusammen, benötige hier mal bitte das Schwarm-Wissen. Wir möchten bzw. müssen eine Vertrauensstelleung zwischen zweier Windows Domänen erstellen. Wir, d.h. mein AG und eine neu zugekaufte Firma in Übersee. Verbindungstechnisch sind die beiden Standorte mittels VPN verbunden und die Firewalls haben jeweils für diesen Tunnel zunächst mal "Any" "Any". IP Technisch kann ich die Domaincontroller der neuen Tochter erreichen. Das funktionert. Wenn ich allerdings auf einem DNS Server dann bspw. eine Sekundäre Zone einrichten möchte, so ist dort der Server IP-Technisch erreichbar, der FQDN jedoch nicht auflösbar: Gleiches passiert, wenn ich statt einer Sekundären Zone eine bedingte Weiterleitung einrichten möchte. Zone Transfers sind aktiviert: Firewalls sind deaktiviert (phsische so wie auch Software-FW auf den DCs). VPN funktioniert stabbil.... Jetzt bin ich eben am rätseln wo man noch schauen könnte. In jeweiligen Domänen funktioniert die Namensauflösunge einwandfrei. Würde mich sehr freuen wenn mir hier jemand einen Tipp geben könnte. Vorab schon mal vielen Dank. Beste Grüße Thorsten

Hallo, wir arbeiten auf Grund geringer personalressourcen mit einem Dienstleister zusammen. Wir haben folgenden Sachverhalt: Wie betreiben ins unserer Single Forest Domain eine Exchange Infrastruktur (2016) an zwei Standorten (verschiedene AD-Sites). Unser Dienstleister wurde beauftragt das neues CU Update auf den Exchange Servern einzuspielen. In der AD-Site des Hauptstandortes, wo sich auch der Schema Master befindet, wurde das CU Update ohne Probleme installiert. Es findet ja eine Schema-Erweiterung bei der CU Installlation statt. Diese wird ja auch Domainweit repliziert. Jetzt soll das Exchange CU Update auf dem zweiten Server installiert werden (andere AD-Site), der sich in einer anderen Site als der Schema Master befindet. Hier kommt der Dienstleister und sagt, dass die Schma-Master Rolle nun verschoben werden muss, weil sonst das CU-Update nicht funktionieren würde. Ich widerspreche aber dem Dienstleister. Das CU-Update kann und muss dort ausgeführt werden, auch wenn der Schema-Master sich in einer anderen Site befindet, da das Schema bereits erweitert wurde. Die CU installation muss eben nur ohne diese Prüfungsparameter gesartet werden. Das müsste doch gehen, oder? Hat hier jemand Erfahrung? Möchte dem Dienstleister einfach nicht blind vertrauen - ist zwar schon eine ganze weile her, dass ich selbst Exchange betreut habe, aber bei der Inbetriebnahme des zweiten Exchange Servers in der anderen AD-Site wurde damals auch nicht die Schema-Master Rolle verschoben damit das geht. Das muss doch auch anders gehen, oder? Für Ratschläge bin ich gerne offen.: Vorab schon mal Danke. VG Thorsten

Weil meine "netten" Exchange-Kollegen oft bei neuen Sachen gerne sagen: Das geht nicht.... damit man keine Arbeit hat. Da isses für mich dann meist am einfachsten gleich nen passenden KB Artikel bzw. nen Link mitzuschicken wo das beschrieben ist. Hab selber etwas nachgeschaut und folgendes gefunden: Via ExchangeShell enable ich den User: Enable-MailUser -Identity max.mustermann -ExternalEmailAddress max.mustermann@gmx.de Ist darüber hinaus sonst noch was zu tun? Danke schon mal. VG Thorsten

Hey Hey, Das finde ich einen super Vorschlag. Das wäre ein sauberer und praktikabler weg. Ich hab das mal so meinem Exchange Kollegen mitgeteilt.... Gibt es dazu eine Beschreibung oder ähnliches? Vielleicht ein KB Artikel von MS? Ich befürchte dass meine Exchange Kollegen sagen dass das nicht gehen würde ^^ Wenn ihr versteht was ich meine Möchte die Kuh endlich vom Eis haben. Danke nochmals. VG Thorsten

Hi zusammen! Erst mal Danke. Es gehr darum, dass externe Dienstleister ein AD Konto benötigen (via Citrix einwählen) und dort auf diversen Plattformen ihre Arbeit erledigen. In manchen Tools (z.B. Jira) können Aufgaben verwaltet werden und per mail werden dann die Empängee informiert. Jira nimmt hier bspw. das Feld Mail her. Interne Mail-Accounts will unser Chef auch net, weil kostet ja Geld ^^ Ich finds total blödsinnig. Jedenfalls hab ich keine Lust hier einen Saustall im AD zu bekommen. Darum suche ich schon nach handfesten Argumenten die dagegen sprechen. Der Hinweis mit nicht supported klingt schon mal nicht schlecht. Gibts dazu nen Link? Grundsätzlich möchte ich hier lieber was Nachhaltiges für externe Benutzer als nur was hingepfuschtes. Weil wenn ich das nun zulasse passiert nie wieder was. Schon aus Sicherheitsgründen hätte ich solche User separiert und das nicht nur in einer extra OU. Ich hoffe ihr versteht was ich meine Danke schon mal

Hallo zusammen, ich hab da mal eine Frage an die Community. Im Internet habe ich dazu nichts gefunden. Es geht um das Attributsfeld Mail eines AD Benutzer Objektes. Einige kreative Kollegen wollen dieses Feld bei externen Mitarbeitern (Dienstleister die via Citrix auf irgendwelchen virtuellen Hobel arbeiten) mit einer Mail-Adresse füllen die nicht zu unserer Domäne gehört und auch nicht von unserem Exchange Server verwaltet / akzeptiert wird. Also beispielsweise max.mustermann@gmx.de Wir haben ne 2012er R2 Domäne, Exchange 2016 am laufen. Aussage wie: da passiert doch nix...das kann man ganz easy machen reicht mir hier nicht. Mag sein dass das Feld ohne Exchange Schema Erweiterung bedeutungslos ist...aber ich möchte hier auf Nummer sicher gehen. Hat hier jemand Erfahrung dazu? Am besten ein KnowHow Eintrag oder so etwas....also was handfestes... Danke schon mal. Leider sind diese Diskussionen mehr als "nervig" Dankscheee Thorsten

Hallo zusammen! Erst mal Danke für die Antworten. Ich hatte vergessen zu ergänzen, dass es an den jeweiligen Standorten in CN eigene DCs gibt und diese Standorte natürlich logisch getrennt sind. Sprich unter AD Standorte und Dienste jeweils ein eigener Standort ist. Sorry

Hallo zusammen, ich hab da mal eine Frage an die Community - bin sehr gespannt auf euerFeedback. Kurz erklärt um was es geht. Bis vor einiger Zeit war ich auch für den Bereich Exchange zuständig. Auf Grund von zu vielen Zuständigkeiten habe ich das Thema an einen Kollegen abgegeben. Mein Arbeitgeber kommt Ursprünglich aus der Notes Ecke. Ende 2018 wurde am Hauptstandort und für die Töchter in D eine 2016er DAG mit vier Exchange Servern aufgebaut. Alles nach best practice vorgaben. Läuft einwandfrei. Notes wurde an diesen Standorten abgelöst und gut ist. Jetzt waren eben noch zwei Standorte in China mit Notes übrig. Eine Anbindung und Hosting der Postfächer über die Deutsche DAG viel aus technischen Gründen aus (Latenz, Verbindungsgeschwindigkeit etc.). Die Tests haben damals schon gezeigt dass das nicht geht. Wir haben damals dann ein Konzept erarbeitet und empfohlen eine Hybrid Umgebung aufzubauen. Die Standorte in D OnPrem und die User in China in Cloud. Mittlerweile hat der neue Exchange Verantwortliche anders entschieden und wollte die Variante über die DAG in D umsetzten. Obwohl bereits getestet etc. Aber egal. Manche Leute glauben einem halt nichts... Wie erwartet hats natürlich nicht funktioniert. Nun aber hat der neue Verantwortliche an den beiden Lokationen in China jeweils einen Single Exchange Server installiert und möchte das so betreiben. Alles schön gemeinsam verwaltet - sprich eine Exchange Organisation. Okay. Die AutoDiscover Funktion für Outlook zeigt aber auf die DAG in Deutschland. Mit entsprechenden Auswirkungen wenn in China jemand Outlook startet. Das dauert halt.... DNS Geo Location geht bei uns noch nicht - dafür ist unsere Domäne noch nicht so weit. Ich frage mich mittlerweile ob das ganze Szenario überhaupt supported ist - im Internet hab ich nichts dergleichen gefunden. Der ausgewählte Dienstleister der Unterstützen soll ist auch nicht der wahre Jakob. Redet viel, kann aber nicht viel. Macht halt alles für Geld. Ich war mal so frei und habe ein Schaubild angehängt damit man sich ein Bild davon machen kann. Zur Erklärung noch: Wir haben eine Domäne für die gesamte Firmengruppe. Einen Forest. Keine Sub-Domains. Alle Standorte in D sind via 1 Gbit an den Hautpstandort angebunden. Die Standorte in CN via MPLS nach D. Zentrales MailIn und MailOut geht über den Hautpstandort - MailGateway.... Ich sag schon mal vielen Dank. Bin sehr gespannt auf eure Antworten. beste Grüße Thorsten

Hallo zusammen, ich habe mal eine Frage an die Commuinity - wie ihr das so handhabt. Ich möchte gerne für einen bestimmten Personenkreis, dass die User mit Nachname, Vorname angezeigt werden. Das ist ja in den Attributen der Distiguished Name. Als Beispiel: Mustermann, Max Distingished Name: CN=Mustermann\, max,OU=TestUserr,DC=local,DC=firma Mir ist zwar klar dass hier ein Komma suoptimal ist. Jedoch betrifft dies die Benutzer. Bei AD Gruppen achten wir penibel darauf dass nur zulässige Zeichen verwendet werden...... Bei den Usern sollte das meiner Meinung nach nicht so tragisch sein. Rein optisch gesehen ist das halt schon praktisch, wenn ich die User so anzeigen kann. Wie seht ihr das? Wie handhabt ihr das? Danke + VG Thorsten

Hallo Community! Ich hätte da gerne die Meinung anderer zu einem etwas schwierigeren Thema. Aktuell haben wir in unserer Domäne (2012 R2 Functionlevel) nur LDAP ohne verschlüsselung im Einsatz. Die Windows Anmeldung wird ja mittels Kerberos Tickets abgewickelt. Jetzt kam von einem Kollegen der Einwand das wir schnellstmöglich LDAPS aktiverien sollten weil es ihm gelungen ist, einige Kennwörter im Klartext mitzulesen. Bei den Anmeldevorgängen der Clients in der Domäne ist nicht nicht möglich - vermutlich handelt es sich hier um Drittsysteme die via LDPA bei einem DC Authentifizierungsanfragen absetzten. Jetzt kamen die ersten Rufe auf, die LDAP via TLS fordern. So weit so gut. So weit ich informiert bin, ist ein parallelbetrieb LDAP und LDAPS möglich. Jedoch frage ich nach der Sinnhaftigkeit. Wenn ich beides erlaube und nicht sinningerweise das weniger Sichere LDAP verbiete und LDAPS erzwinge..... Kann, muss aber nicht. Aus Sicherheitstechnischen Gründen wäre es sinnvoller LDAPS zu erzwingen. Explizit geht es um einen Anwendungsfall. Das Produkt NetScaler von Citrix wird aktuell nur mit LDAP genutzt. Jetzt sollen die USER auch von extern die AD-Kennwörter ändern können. Das widerum setzt LDAPS voraus. Über die Sinnhaftigkeit könnte man auch wieder streiten.... ^^ Wie verhält es sich mit alten Betriebssystemen und LDAPS? Unterstützen beispielsweise Windows XP LDAPS via TLS? Habe dazu leider nichts gefunden. Bitte auch keine Dikussion wegen XP - ich hab mir deswegen den Mund auch schon fusselig geredet...aber Produktionsgewerbe ist leider anders als ein schlichtes Office ^^ Was würdet ihr mir empfehlen? Ich sag schon mal Danke! VG Th

OK, dann sinds halt HyperV Hosts. Also nicht jede Anwendung die existiert kann hochverfügbar gemacht werden, nicht jede Applikation lässt sich clustern. Es gibt Produktionsrelavante Anwendungen die maximal virtualisiert werden können - dass ist schon das höchste der Gefühle. Nochmals zur verdeutlichung. Hier handelt es sich nicht um eine Versicherungsklitsche mit 0815 Rechner und ein paar Server. Wir reden hier von einer Umgebung mit mehreren hundert Server und meheren tausend Clients die auf mehrere Kontinente, in verschiedenen Zeitzonen leben. Und einfach mal die Produktion lahmlegen geht nicht. Beispielsweise kann ich die DC's nicht clustern. Ich kann pro Standort mehere DC's zur Verfügung stellen. Sollte einer ausfallen, so suchen sich Rechner ab Win 7 automatisch den nächsten Verfügbaren DC um reibungslos weiter arbeiten zu können. Wenn aber noch ältere Betriebssystem vorhanden sind (WinXP) dann verliert der Rechner sozusagen die Verbindung. Eine Neuanmeldung ist Notwendig. Wie bereits beschrieben sind wir ein produzierende Unternhemen. Dort gibt es viele Produktionsmaschinen, in denen sozusagen noch ein altes OS wie XP läuft. Manche Hersteller bieten nix neueres an (man glaubt es kaum) und andere Produtkionmaschinen sind so zertifiziert und mit dem Stand des OS eingeforen und dürfen nicht verändert werden. Bei Daimler wird sicherlich auch nicht einfach tagsüber gepacht.... Also wie gesagt, der Fokus liegt ganz klar auf Sonntag als Patch Day. Wie das aber sinnvoll gestalten?

Um es nochmals zu verdeutlichen. Mir geht es hier nicht um die Träger-Systeme. Diese wurden bisher besser behandelt als die VM's die darauf laufen. Und ein Reboot eines Trägers tagsüber ist auch in aller Regel ohne weiteres möglich. Es geht eher um die sehr vielen virtuellen Server die auf den Trägern wohnen - das sind ein paar hundert und die sollten auch mal gepatcht werden. Dafür bleibt eben nur der Sonntag.....und mit der Hand am Arm wird das ne Aufgabe bis zur Rente

Hallo zusammen, machen mir gerade Gedanken wie wir unsere Server in dem Unternhemen, in dem ich arbeite, regelmäßig und sinnvoll patchen können. Dazu folgende Infos damit man sich ein besseres Bild machen kann. Ich arbeite in einem global agierenden Unternehmen das Niederlassungen in Deutschland, Ungarn, China, USA und Mexico hat. An allen Standorten wird produziert, in 24 Stunden Schichten und zwar von Montag bis Sonntag um 6 Uhr morgens. Sprich das einzige Zeitfenster um Server zu patchen ist der Sonntag. Einfach unter der Woche geht nicht, da die Server für die Produktion benötigt werden. Ich spreche hier auch von annähernd 450 Server weltweit - die allermeisten virtuell (basierend HyperV Träger/ Cluster). Das Gro der Server befindet sich jedoch am Hauptstandort in D. Jedoch hat jede Niederlassung ein eigenes RZ. Die jüngeren Niederlassungen verfügen schon über geclusterte HyperV umgebungen - die älteren leider noch nicht. Am Hauptstandort gibt es zwei gespiegelte Rechenzentren - mit aufgeteilten HyperV Clustern und einem NetApp MetroCluster als Storage-Unterbau :-) Die Arbeitsplätze werden weltweit mittels FrontRange DSM AdvancedPatchManagement gepacht - das funktioniert auch ganz gut, insbesondere weil auch Produkte von Drittanbietern wie Java, Adobe mitgepacht werden. Jedoch werden die Server nur sehr unregelmäßig gepatcht. Meist nur wenn an einem Server eh etwas zu tun ist. Zwei Mal pro Jahr hat die IT ein Wartunswochenende, wo wir nach Lust und Laune tun können was wir wollen. Meist reicht aber gerade mal die Zeit die HyperV Träger zu patchen.....dann ist Schluss. Ich möchte daher gerne aus Sicherheitsgründen zukünftig die Server (so weit wie möglich) automatisch mittels WSUS patchen lassen. Hier mal meine Gedankengänge 1. automatisches Patchen der DC's - vier Wochen nach dem PatchDay von MS. Bis dahin sollten normalweise alle faulen Patche bekannt sein. Es sind insgesamt 21 DC's. Alle von Hand zu machen geht nicht. Dazu fehlt die Zeit und das Personal. 2. Patchen aller Test-Systeme ebenfalls vier Wochen nach dem MS PatchDay 3. nach weiteren 4 Wochen Patchen der Produktiv-Server mit den verwendeten Patchen unter Punkt 3. Grundsätzlich sollte immer ein zeitversatz von vier Wochen zwischen Erscheinen des Patches und der Installation des Patches bestehen. Das wir hier dringend Handlungsbedarf haben ist uns selbst bewusst. Wir haben aber aktuell leider nicht die notwendigen Ressoucen (Zeit und Personal) um uns händisch um so viele Server zu kümmern. Oder wäre die bessere Alternative gar nicht zu patchen? Das glaube ich nicht ;-) Wir wollen schließlich dadurch auch die Sicherheit erhöhen. Einen aktuellen Virenschutz bringt nur eingeschränkt etwas wenn nicht auch die Sicherheitslücken im Betriebssystem gestopft werden. Wie würdet ihr das machen? Gibt es bei jemanden ähnliche Szenarien? Wie sind die Erfahrungen? Vorschläge? Über eine rege Diskussion zu diesem Thema wäre ich dankbar. VG Thorsten

Das wurde auch schon versucht. Es kann sehr warhscheinlich gar kein DNS Problem sein, da ja schon die lokale Anmeldung am Server mittels Hyper-V Konsole nicht funktioniert. Nur mittels RDP und IP-Adresse kann man sich mit dem Domänen-Admin anmelden. Lokal nicht. Das ist ja das verrückte.

Hallo zusammen, habe gerade ein sehr seltsames Phnomen. Und zwar wurde mir gerade aus einer Fachabteilung gemdelt, dass deren Server nur per IP-Adresse Remote verwaltet werden kann. Habe das zwar auch erst nicht geglaubt und wollte mich ebenfalls per RDP auf den Server aufschalten. Leider mit Fehler: "Die Verbindung kann nicht hergestellt werden, da es sich bei dem erreichten Remotecomputer nicht um den angegbenen Computer handelt. Dies kann durch einen veralteten Eintrag im DNS-Cache verursacht werden. Verwenden Sie statt des Namens die IP-Adresse des Computers" Pah - Pustekuchen! Beim entsprechenden Server handelt es sich um einen 2012 non R2 Server. Die Namensauflösung funktioniert korrekt. Der DNS löst in beide Richtungen korrekt auf. DNS Cache auch schon gelöscht. Server im DNS neu registriert. Server bereits neu gesartet. Immer noch das gleiche ergebnis. Selbst eine "lokale" Anmeldung mit dem Domänen-Admin am Server über die Hyper-V Konsole schlägt fehl. RDP über die IP mit Domänen-Admin geht aber. Das klingt unglaublich, ist aber leider so. Weiß jemand Rat? Ich hatte auch erste einen falschen DNS Eintrag vermutet. Das wars aber offensichtlich nicht, sonst müsste ja zumidest die lokale Anmeldung mittels Hyper-V Konsole funktionieren. Vorab schon mal Danke! VG Thorsten

Zugegebenermaßen möchte ich eigentlich nach wie vor die bestehende Domäne Hochstufen. Jedoch möchte mein direkter Kollege die Variante mit neuer Domäne und alte Domäne als Subdomäne. ich bin mir halt nicht sicher ob das technisch geht....habe soetwas noch nie gemacht. Sprich ein DC basierend auf W2K12 R2, Domänenfunktionsebene 2012 R2 der dann aber auch die alte "Subdomäbne" bedienen kann.... Ich will ja primär alle alten DC's los werden, weil der Extended Support im nächsten Jahr für dieses Betriebssystem enden wird. Wenn ich die bestehende Domäne hochstufen will brauche ich ein paar tatsächliche Show-Stopper (technisch) die gegen eine Supdomäen bzw. eine Vertrauensstellung zur alten Domäne sprechen. Habe natürlich auch schon an externe Dienstleister gedacht. Aber mein Kollege sträubt sich da sehr und so lange mein Chef kein Machtwort spricht sind mir die Hände gebunden....ausser ich kann natürlich sagen dass es technisch aus dem und dem Grund nicht geht und wir deswegen doch einen Dienstleister brauchen. Schwierig....sehr schwierig.

Erst mal vielen Dank für die Antworten. Da wir sehr viele Altlasten haben in unserer Domäne und diese voraussichtlich nicht so einfach beseitigen werden können, habe ich mir überlegt sozusagen auf der grünen Wiese eine neue Domäne zu erstellen (2012 R2), diese zu konfigurieren und dann zur alten Domäne eine Vertrauensstellung herzustellen (wenn das so richtig heisst). Alternativ dachte ich da auch die alte Domäne als Sub-Domäne laufen zu lassen. Die Frage die mich bezüglich einer solchen Lösung beschäftigt ist, ob das ganze technisch geht. Also sprich wenn die neue Domäne die Funktionsebene 2012 R2 hat und die alte eben 2003 ob das mit dem Trus geht bzw. ob überhaupt die alte als Subdomäne aufgenommen werden kann, sollte diese Möglichkeit gewünscht werden. Ich finde leider nicht viele Infos dazu.

Hallo zusammen, ich bin seit ca. zwei Jahren Admin in einem größeren Unternehmen. Der Betriebsmodus unserer Domäne ist derzeit noch folgender: Domänenfunktionsebene: Windows Server 2003 Gesamtstrukturfunktionsebene Windows 2000 In der letzten Abteilungsbesprechung habe ich angemerkt, das wir hier mal etwas machen sollten. Wenn möglich die Domäne hochstufen. Am bestene auf die aktuelle Version - zumindest jedoch mal auf 2008 R2. Wir sind im produzierenden Gewerbe (Elektroindustrie) tätig und haben leider auch noch zwangsweise einige alte Prüfmittelsysteme am laufen (Windows 2000 und NT4). Den Einwand meiner Kollegen konnte ich bei NT4 noch entrkräften, da ich wusste dass es in einer 2008 R2 Domäne die Möglichkeit gibt für NT4 Maschinen entsprechend die Sicherheitseinstellungen anzupassen. Hier der Passenden Artikel dazu: http://support2.microsoft.com/kb/942564/en-us Jedoch haben wir noch eine kleineres, aber dennoch heftiges Problem. Wir haben noch einige DOS Prüfmittelrechner (bitte nicht lachen) für sehr alte Produkte die hin und wieder benötigt werden. Diese schreiben nach dem Prüfvorgang Dateien auf ein Share im Netzwerk. Eine Ablösung dieser alten DOS-Rechner findet nicht statt, da man diese teilweise noch benötigt....Updaten ist auch nicht mehr möglich, da die Prüfmittelprogramme nur für DOS Verfügbar sind.... Jetzt befürchte ich nun, das eine Hochstufung unsere Domäne zumindest an den DOS Rechner scheitern wird. Hat jemand mir tipps für diese Problematik bzw. so etwas schon mal erlebt? Gibt es evtl. Drittanbietertools? Ist eine 2012 Domäne damit für immer gestorben? Wäre euch Dankbar für Hinweise. Ein Kollege von mir schiesst da leider immer quer.... VG Thorsten