NilsK

Moin, na endlich ... ;) Die Frage, was ein System denn leisten soll, ist natürlich vor der Beschaffung zu beantworten. Hier ist (dem Eingangsposting nach) anscheinend ein klassicher Fall von "erst kaufen, dann denken" - System gekauft, das derzeit völlig überdimensioniert ist, weil es "vielleicht später noch mehr machen soll" - aber keiner hat sich überlegt, was für ein "Mehr". Und wenn der Fall dann da ist, reicht das Monstersystem plötzlich trotzdem nicht. Erzähle mir bitte keiner, dass man mit einem KMU-Kunden keine Betrachtung über Anforderungen machen könne - kann man sehr wohl. Gruß, Nils

Moin, das hat er doch geschrieben ... und dass in seinem Fall das Problem durch Updates verschwand. Ist das bei euch schon getestet worden? Gruß, Nils

Moin, es geht hier auch nicht um das Sammeln als solches, sondern darum, dass Windows 10 die Datenübertragung schlampig absichert. Mit Mitteln, die in vielen Unternehmen bereits vorhanden sind, kann man den Traffic abhören. Gruß, Nils

Moin, eieieiei, ihr rührt hier aber Dinge zusammen ... Vielleicht sollte DaFlo doch noch mal genauer sagen, was er eigentlich wissen will. Derzeit entspricht die Diskussion in etwa der Frage "Ist ein Diesel was Gutes?" mit diversen Detailantworten ohne Zusammenhang. ;) Und die gesicherten VMs in Windows Server 2016 sind keine Universallösung, sondern für Hosting gedacht. Die hier erwähnten Szenarien passen dazu gar nicht. Gruß, Nils

Moin, Norbert hat dir alles Nötige erklärt. Mehr würde der MS-Support mit Sicherheit auch nicht machen, denn zaubern können die auch nicht, und die Situation ist auch nicht so kritisch, dass man da den Zauberkoffer rausholen müsste, um so zu tun, als würde man zaubern. Du hast einen oder zwei kaputte DCs, das AD läuft aber noch. Also keine Krise. Ruhe bewahren und strukturiert vorgehen. Bei Bedarf einen kundigen Dienstleister dazuholen. Gruß, Nils

Moin, Blinde benötigen aber etwas anderes. Und dafür ist Cortana nun mal nicht gebaut worden. Gruß, Nils

Moin, da Edge ausdrücklich für den Tablet-Betrieb gebaut wurde, ist es in der Tat wahrscheinlich, dass da was anderes hakt. Gruß, Nils

Moin, na, nur weil ich mal eine Größenordnung daneben liege ... ;) Danke für die Korrektur, Nils

Moin, OK, das ist klar - der LDAP-Pfad muss schon richtig sein. C:\system32 wäre ja auch keine korrekte Angabe. ;) Danke für die Rückmeldung, Nils PS. Wenn du sowieso Excel verwendest ... aber lassen wir das.

Moin, auf keinen Fall irgendwas am Teaming drehen, solange Hyper-V läuft! Dass das Problem dadurch nicht verschwindet, ist klar. Da nicht auszuschließen ist, dass das Teaming falsch eingerichtet wurde, würde ich an deiner Stelle die Hosts komplett neu installieren und dabei minutiös auf die richtige Reihenfolge chten. Die findest du hier beispielhaft beschrieben: [How-To: Netzwerkkarten Teaming mit Hyper-V - Server Talk by Michel Luescher] http://www.server-talk.eu/2009/12/02/how-to-netzwerkkarten-teaming-mit-hyper-v/ Gruß, Nils

Moin, sicher gibt es dazu auch eine Fehlermeldung, oder? Dann müssen wir hier vielleicht weniger Rätsel raten. Zudem könntest du die eingelesenen Werte auf der Kommandozeile ausgeben. So etwas wie falsche Umlaute oder anders fehlerhaft eingelesene Werte fällt dann meist schnell auf. Gruß, Nils

Moin, und: Ist beim Einrichten des Teaming die richtige Installationsreihenfolge eingehalten worden? Bei 2008 R2 war das ein kritischer Faktor. Wäre zar ausgesprochen seltsam, wenn sich das erst nach so langer Zeit äußert, aber die Symptome passen dazu. Was hat sich gegenüber vorher geändert? Irgendwelche Konfigurationen an den Switches anders? Gruß, Nils

Moin, Daten bearbeiten an mehr als einer Stelle ist immer problematisch, selbst wenn eine Software das "eigentlich" kann. In vielen Fällen ist es ein guter Ausweg, die Anwender "zu den Daten zu holen", was per Terminalserver (ja, ich weiß, das heißt jetzt RDS) meist gut geht. Dann brauchen keine Daten übers Netz, es gibt eine zentrale Backup-Instanz usw. Gruß, Nils

Moin, sprich mit dem Trainingscenter. Das ist der einzig sinnvolle Weg. Was MOC usw. betrifft: Hier kommt es darauf an, wie dir das verkauft wurde. Wenn dir ein MOC-Originalkurs verkauft wurde, gehört dazu ein Original-MOC-Ordner, kein Buch. Aber ein Original-MOC ist auch nie im Leben 20 Tage lang. Das klingt mir dann eher nach einer "Maßnahme", und da gelten selbstverständlich andere Bedingungen als bei einem kommerziellen Standardkurs. Ich hab sowas früher auch vereinzelt gemacht - an ein reinrassiges MOC-Programm ist da aus verschiedenen Gründen nicht zu denken. Muss aber nicht schlimm sein, denn ein längerer Kurs hat ja auch seine Vorteile. Trotzdem muss die Qualität natürlich OK sein - ob sie das ist oder nicht, können wir nicht beurteilen. Die Bilder lassen jetzt erst mal nichts Schlimmes befürchten, da sieht halt nur die Handschrift nicht so toll aus. Gruß, Nils

Moin, schon den Excel-Link oben gelesen? Das ziehe ich in fast allen Situationen einer langen Schleife vor ... Gruß, Nils

Moin, da Rechner heute nur noch selten "nackt" ausgeliefert werden bzw. das Betriebssystem nur selten wirklich gar nichts mit den Komponenten anfangen kann, dürfte die Installationsreihenfolge der Treiber heutzutage nur noch selten eine Rolle spielen. Die von Günter angegebene Reihenfolge ist schon plausibel, weil ein Rechner evtl. ohne Chipsatztreiber instabil läuft - die Zeit will man also kurz halten. Tatsächlich halte ich es aber für übertrieben zu behaupten, dass es irgendwie "schädlich" wäre, eine andere Installationsreihenfolge vorzunehmen. Bei Markenrechnern überlasse ich diese Aufgabe auch den Update-Tools der Hersteller, das ist mittlerweile zuverlässig und bequem. Gruß, Nils

Moin, sagen wir es deutlich: Nein, so ohne Weiteres geht das nicht. Das geforderte Verfahren würde auf jeden Fall Anpassungen an der Datenbank voraussetzen, weil eine Merge-Replikation erforderlich wäre. Anderenfalls wäre bei Verbindungsunterbrechung kein Arbeiten auf beiden Seiten möglich. Gruß, Nils

Moin, csvde ist zum Inportieren von Usern in Wirklichkeit nicht geeignet. Das liegt daran, dass man damit kein Kennwort setzen kann. Allerhöchstens könnte man also ein deaktiviertes Objekt erzeugen, das man dann hinterher auf anderem Wege mit einem Kennwort versehen und aktivieren müsste. Auch sonst ist csvde für Importe nicht gut geeignet, weil es eben sehr hakelig ist. Zum Export manchmal nützlich, aber nicht zum Erzeugen von Objekten. Wie Daniel schon sagt, gibt es mittlerweile ja aber auch viele Alternativen; die csvde-Beispiele in der Literatur kommen meist noch aus Windows-2000-Zeiten. Nimm PowerShell, die ds*-Tools, AdMod ... und wenn es um viele User geht, schau dir dies an, das erspart dir viel Skriptlogik, wenn du ein wenig mit Excel umgehen kannst: [Excel: Admins unbekannter Liebling | faq-o-matic.net] http://www.faq-o-matic.net/2008/01/19/excel-admins-unbekannter-liebling/ Gruß, Nils PS. In deinem Beispiel problematisch: Die Umlaute, der fehlende Objektstatus "deaktiviert" und das "memberOf". Also eine ganze Menge.

Moin, nein, dafür ist Cortana nicht gedacht. Ich glaube auch nicht, dass sie in die Richtung entwickelt wird. Nach allem, was man derzeit so liest, will man sie vielleicht auch lieber abschalten ... Gruß, Nils

Moin, das könnte dem Hersteller durchaus um die Ohren fliegen: [Windows 10: Gefährlicher Zertifikats-Wirrwarr | iX] http://www.heise.de/ix/meldung/Windows-10-Gefaehrlicher-Zertifikats-Wirrwarr-2776810.html Gruß, Nils

Moin, isses. Gruß, Nils

Moin, probier mal dies. [Zeitsynchronisation der Domäne - w32time - Zeitserver per GPO - Gruppenrichtlinien by Mark Heitbrink] http://www.gruppenrichtlinien.de/artikel/zeitsynchronisation-der-domaene-w32time-zeitserver-per-gpo/ Gruß, Nils

Moin, ja, genau deshalb meinte ich ja, dass der VMM viel zu komplex ist, wenn es nur um diese Anforderung geht. ;) Gruß, Nils

Moin, meines Wissens kann man den Standard nicht ändern. Denkbar wäre ein PowerShell-Skript, das der Support zum Erzeugen des Verteilers nutzt. Teil 2 ist leider so, kann man meines Wissens ebenfalls nicht ändern. Gruß, Nils

Moin, ergänzend dazu: Dein geplantes Vorgehen wird nicht funktionieren. Exchange ist von der konkreten Domäne abhängig. Am sinnvollsten ist es, die bestehende Domäne beizubehalten. Anderenfalls gibt es sehr viel Arbeit und sehr viel Unterbrechung für die Anwender. Prinzipiell ginge das so: Server mit dem neuen Betriebssystem als Mitglied in die Domäne aufnehmen. AD vorbereiten (Schema, Forest). Für die Anwender ergibt sich keine Änderung. Den neuen Server zum DC hochstufen. Den alten DC herunterstufen, dann aus dem AD entfernen. Fertig. Soweit das Prinzip. Im Detail wird man noch einiges prüfen und so, aber im Wesentlichen wäre man damit in ein, zwei Tagen durch. Im anderen Fall müsstest du eine Cross-Forest- bzw. Cross-Org-Migration für Exchange machen. Sehr großer Aufwand. Zudem müsstest du alle Ressourcen der Altdomäne in die neue bringen. Noch größerer Aufwand. Und kaum ohne Downtime hinzubekommen. Gruß, Nils