NilsK

Moin, was heißt ? Du machst Dauerping, der schlägt 20 Minuten fehl, dann geht es? Was die Netzwerkkarten betrifft: Einen solchen virtuellen WLAN-Adapter legt Windows m.W. nur auf Anforderung an. Da muss es also eine Komponente oder Konfig geben, die das bewirkt, vielleicht ein Haken im Treiber-Setup. Wenn dem so ist, schalte die Funktion mal ab. Das sieht mir zumindest nach einem Verdächtigen aus. Wie ist die Bindungsreihenfolge der Netzwerkadapter? Unter Windows 7 spielt die noch eine Rolle. Vielleicht versucht WIndows erst vergeblich, über nicht funktionierende Adapter zu sprechen. Gruß, Nils

Moin, was meinst du mit ? Willst du eine VM installieren, die DC ist? Dann geht das rein technisch schon, den Host in die Domäne der VM aufzunehmen. Ob es sinnvoll ist, steht auf einem anderen Blatt. Gruß, Nils

Moin, äh - nein. Ein DC mit einem neuen OS hebt immer das Schema an. Ein "Level" der Datenbank gibt es nicht, schon deshalb nicht, weil ja jeder DC seine eigene Datenbank hat. Und natürlich können ältere DCs mit einem neueren Schema arbeiten. Kann es sein, dass du hier den Betriebsmodus und das Schema verwechselst? Gruß, Nils

Moin, wenn ihr sowieso neu installieren wollt, dann baut eine neue VM. Eine vorhandene VM neu zu installieren, ist nicht sinnvoll. Der Eintrag "file" wird bei der Installation des Betriebssystems automatisch gesetzt. Da du Secure Boot aktiviert hast, lässt Hyper-V da auch nichts anderes zu und entfernt die anderen Einträge daher. Grundsätzlich sollte es möglich sein, die Bootreihenfolge nachträglich mit Set-VmFirmware zu definieren - aber wie gesagt, sinnvoller ist es, eine neue VM zu erzeugen. EDIT: Insbesondere wenn die VM repliziert ist, würde ich keine Neuinstallation machen. Das reduziert den Aufwand nun wirklich nicht. Gruß, Nils

Moin, warum hast du einen "Microsoft Virtual WiFi Miniport Adapter" mit derselben MAC-Adresse wie der WLAN-Adapter? Ist der Rechner als virtueller Hotspot eingerichtet? Verschwindet das Problem, wenn du das abschaltest? Ich bin mir nicht sicher, meine mich aber zu erinnern, dass das mal eine experimentelle Funktion war, die oft nicht ordentlich arbeitet. Gruß, Nils

Moin, der Teil "Supported Active Directory environments" in der Supportability Matrix (https://technet.microsoft.com/en-us/library/ff728623(v=exchg.150).aspx) bezieht sich darauf, dass Exchange einen solchen DC erreichen können muss. Es dürfen andere DCs in der Umgebung existieren. Analog gilt das ja auch für RODCs, die in der Einleitung erwähnt werden: Exchange kann mit denen nicht sprechen, aber es darf welche geben. Die Schemaerweiterung ist in keinem Fall ein Problem (sonst gäbe es auch eine Tabelle dazu), denn praktisch alle Änderungen dort erweitern das Schema nur (nur in wenigen Fällen ändern sich Eigenschaften bestehender Objekte, die dann aber nicht zu Problemen führen sollten). Es geht eher um Funktionen, die die neueren DCs nicht oder in anderer Weise bereitstellen, sodass Exchange sie nicht versteht. Es sollte also gehen. Ob man in Exchange tatsächlich in dem Fall einen DC direkt eintragen muss, kann ich nicht sagen. Gruß, Nils

Moin, vielleicht irgendeine Extension im Explorer, die beim Zugriff von selbst etwas macht? Gruß, Nils

Moin, das klingt, als fehle der Private Key. Gruß, Nils

Moin, nur Nano unterliegt der CBB-Politik (Current Branch for Business), muss also alle paar Monate aktualisiert werden. Das geschieht im Unterschied zum Client aber nicht automatisch. Nano eignet sich also nur für kurzlebige Systeme. Gruß, Nils

Moin, in Beitrag #8 war ein Artikel verlinkt, der die Hintergründe gut darstellt. War mir in dem Detailgrad auch nicht bekannt. Da ich aber kaum noch NetApp-Kunden betreue, kommen mir NFS-Datastores auch nur noch selten unter. http://www.mcseboard.de/topic/208895-exchange-2010-iscsi-vs-nfs/?do=findComment&comment=1318413 Gruß, Nils

Moin, eine saubere Lösung wirst du nicht ohne die IT der Organisation hinbekommen. Sprich mit denen, um zu einem funktionierenden Konstrukt zu kommen. Jeder Workaround, der die vorgegebenen Strukturen irgendwie umgeht, fällt dir schnell auf die Füße - so auch der Domainsuffix per GPO, das ist immer wieder eine Fehlerquelle. Gruß, Nils

Moin, warum dieser Ton? Und: Das ist doch in diesem Thread bereits diskutiert und belegt worden. Wir müssen das ja nicht wiederholen - nachlesen reicht. :D Gruß, Nils

Moin, vielleicht eine falsche bzw. ungünstige Bindungsreihenfolge bei den Win-7-Clients? Ich meine, dass Windows 7 da noch mehr Abhängigkeiten hat als die jüngeren Systeme. Gruß, Nils

Moin, naja, eben nicht. Es ist für Exchange dann ja nun mal nicht supportet. Das habe ich in diesem Thread ja auch gelernt. ;) Gruß, Nils

Moin, zeigt sich die Verzögerung auch bei interner Namensauflösung? Kannst du mal ein ipconfig -all von einem "schnellen" und von einem "langsamen" Client posten? Gruß, Nils

Moin, da hast du natürlich Recht. Sehr sozial gedacht. Gruß, Nils

Moin, ja, ziemlich genau so verlaufen die Diskussionen üblicherweise. Da ich allerdings gar nichts beweisen muss, müssen wir das auch nicht fortführen. Ich weise nur auf meine Erfahrung mit "sowas" hin - ist ja weder mein "Backup" noch mein System. Gruß, Nils

Moin, wie - und so ein Satz von dir? :D Ein Kennwort gehört nicht in ein Skript. Auch nicht verschleiert. Und auch nicht, wenn der User aufs AD "nur" Leserechte hat. Wenn ein CSV-Export erzeugt wird, klingt das für mich nach einer einmaligen Sache. Auch wenn dafür ein Remotezugriff nötig ist, braucht das Kennwort für sowas nicht im Skript zu stehen - man könnte es bei der Skriptausführung anfordern und gesichert übergeben. Gruß, Nils

Moin, kann man so machen - aber wenn ihr sowieso mit einem CSV arbeitet, warum exportiert ihr die Daten nicht einfach an der Quelle? Das ist viel einfacher, und ihr braucht keinen Useraccount, dessen Kennwort ihr in einem Skript im Klartext hinterlegt. Gruß, Nils

Moin, der TO berichtet von Problemen. Und sowas höre ich immer wieder, dabei erstaunlich oft in NetApp-Umgebungen. Ich glaube auch, dass die Tolles können. Möglicherweise ist es auch der Umgang der Admins damit. Jedenfalls erlebe ich zu oft Probleme mit solchen Sicherungsmethoden, als dass ich ihnen einfach so vertrauen würde. Daher meine Predigt. ;) Gruß, Nils

Moin, ja, nachdem ich ausdrücklich nach dem Hintergrund gefragt habe. Sehr wahrscheinlich nicht. In demselben MSDN-Artikel, den du zitiert hast, steht auch drin, dass Gen-2 eigentlich keine messbaren Vorteile hat. Leg also eine neue Gen-1 an, kopier die VHD-Datei und häng sie an. Für die Übertragung der Freigaben mit Berechtigungen kannst du einen Registry-Export nutzen. Ja, das mag sein. Wir wollen niemandem zu nahe treten - wenn du dir den Verlauf der Diskussion aber mal ansiehst, wirst du feststellen, dass es nicht ganz einfach war, überhaupt den Hintergrund herauszubekommen und dir zu vermitteln, dass deine Annahmen nicht überall zutreffen. Also fürs nächste Mal: Gleich sagen, worum es geht. Und für uns: Geduld bewahren. ;) Gruß, Nils

Moin, und was hat das mit dem eigentlichen Punkt zu tun, dass du eine Datendisk von einer Gen-1-VM problemlos als Datendisk an eine Gen-2-VM ankoppeln kannst? Konvertier sie halt und fertig. Meinst du, dass es irgendwen hier voranbringt, wenn du jetzt mit solchen Nebenfragen ablenkst? Bin dann mal raus, Nils

Moin, wir haben das in den vergangenen Wochen mehrfach hier diskutiert. Schau dir die einschlägigen Threads einfach an. Meine kurze Antwort: Sie sind nicht sinnvoll und waren es nie. Gruß, Nils

Moin, derartige konzeptionelle Fragen eignen sich nicht für ein Forum. Dafür sollte man sich Zeit nehmen (und ggf. ein bisschen Geld investieren), um es in Ruhe zu entwickeln. Wenn es sich bei beiden Netzen um Testnetze handelt (und nicht um produktive Daten), ist das erst mal im Grundsatz OK. Wenn das eine ein Test- und das andere ein Produktionsnetzwerk wäre, sollte man sich über den Grad der Kopplung bzw. Trennung ein paar Gedanken mehr machen. Gruß, Nils

Moin Nuncic, vielen Dank für den wertvollen Einblick! Gruß, Nils