NilsK

Moin, ach ja, stimmt, die Methode hatte ich vergessen. Dabei ist aber zu beachten: Das muss man vor der Installation des Betriebssystems machen. Nachträglich, so wie man das früher gemacht hat, ist es nicht mehr supportet. Es gibt eine ganze Software-Industrie, die sich um den Profil-Murks herum gebildet hat. Wobei noch niemand den Stein der Weisen gefunden hat, Einschränkungen haben alle. Gruß, Nils

Moin, das ist bei Servern mit so vielen "Wenns" und "Abers" verbunden, dass man das i.d.R. nicht macht. Die meisten Hersteller supporten das auch nicht. Um was für Software geht es denn? Gruß, Nils

Moin, Moooooment ... hier scheinen mir zwei Dinge durcheinander zu gehen. Problemlos möglich (naja, relativ) ist es, einem User ein servergespeichertes Profil zu geben. Damit kann derselbe User sich an verschiedenen Rechnern anmelden und hat überall seine Einstellungen. Ein vorhandenes Profil zu kopieren und einem anderen User unterzujubeln oder zum Default-Profil zu erklären, geht ganz schnell schief und ist auch seit Jahren nicht mehr von Microsoft supported. Das war unter NT4 (meine ich) mal eine Empfehlung, seither aber nicht mehr. Der empfohlene (und meines Wissens einzig supportete) Weg ist, dass jeder User ein "frisches" Profil bekommt und dieses per GPO, GPP, PowerShell, DSC usw. angepasst wird. Ja, das ist umständlich und aufwändig. Und ja, die ganze Profil-Chose hat Microsoft ganz gründlich versaubeutelt. Da man aber erfahrungsgemäß mit allen Basteleien an der Stelle früher oder später ein Problem bekommt, sollte man das wissen. Gruß, Nils

Moin, richtig, das geht nicht. Allenfalls kannst du das Inplace-Update innerhalb der Gen-1-VM machen. Generell rät man bei Servern aber von Inplace-Updates ab. Der schnellere Zugriff per virtuellem SCSI wird häufig missverstanden. Zum einen sind es "bis zu" 40 Prozent, nicht pauschal. Und zum anderen bezieht sich das auch nur auf die Bootdisk, die bei Gen-1 ja per virtuellem IDE angebunden ist. Daten-Disks kann (und sollte) man auch in Gen-1 als vSCSI einrichten. In dem Fall ist kein nennenswerter Unterschied in der Performance zu erwarten. Auch generell gilt, dass Gen-2-VMs nicht pauschal "besser" oder "performanter" sind als Gen-1-VMs. In den meisten Situationen wird man in der Praxis keinen Unterschied bemerken. Gruß, Nils

Moin, bei sechs Knoten sollte es problemlos sein, die alle nacheinander zu patchen. Also erst einen patchen und den Reboot abwarten, erst danach den nächsten patchen. Mit CAU habe ich in der Praxis auch sehr durchwachsene Erfahrungen gemacht. Bei einer 6-Host-Umgebung dürfte sich der Aufwand nicht lohnen, das zu troubleshooten. Vielleicht ein PowerShell-Skript bauen, das jeden Host evakuiert, patcht, nach dem Reboot grundlegend prüft und dann mit dem letzten weitermacht. Man könnte sogar soweit gehen, dass man ganz am Ende die "Normalverteilung" der VMs wiederherstellt. Gruß, Nils

Moin, komplexe Software? Dass es Fehler gibt, wundert mich überhaupt nicht. Eher der Umgang damit. Und hier die heise-Meldung dazu: http://www.heise.de/newsticker/meldung/Windows-10-Upgrade-Bitlocker-und-Hyper-V-im-Konflikt-3298106.html Gruß, Nils PS: ja ...

Moin, danke! :D Gruß, Nils

Moin, meine Güte, einen Mangel an Sturheit kann man dir nicht anlasten. "Geändert" wurde weder bei "Windows.old" noch beim "Bootvorgang" etwas. Wie nun schon mehrfach dargelegt, ist "Windows.old" ein einfaches Ordnerbackup - genauer: ein umbenannter Ordner. Da es in diversen Konfigurationen eines lauffähigen Systems Verweise auf den Systemordner gibt, werden diese natürlich nicht mehr funktionieren, wenn der Ordner plötzlich anders heißt. Ebenso würde es keine funktionsfähige Registry geben, versuchte man, das Windows aus "Windows.old" zu starten. Muss es auch nicht, denn - falls das bislang noch nicht erwähnt wurde - es handelt sich dabei ja auch nicht um ein lauffähiges Betriebssystem. Der Bootloader wird beim Upgrade (was technisch eine Neuinstallation ist) schlicht ausgetauscht. Er startet Windows 10, nicht Windows 7. Und ja, der Bootloader könnte auch Windows 7 starten, wenn es sich um ein Dual-Boot-System handelte. Vielleicht ist auch dies bislang unerwähnt geblieben, aber nach einem Upgrade hat man kein Dual-Boot-System. Gruß, Nils

Moin, <OT> jaja, die Backlinks ... auch so ein Weirdness-Thema. Mehr als eine Handvoll davon ist nur zur Hälfte implementiert ... </OT> Gruß, Nils

Moin, in Redmond ist es jetzt 07:20 Uhr morgens. Gruß, Nils

Moin, das ist stark anzunehmen, quasi wie immer. :D In diesem Fall abet trotzdem nicht zu verstehen: Dem Forenbeitrag von Microsoft nach zu urteilen, handelt es sich eigentlich um ein Problem von DeviceGuard, also quasi der Kombination von Hyper-V und dem TPM-Chip. Da hätte man schon mal auf einen Zusammenhang zu Bitlocker kommen dürfen ... Es bleibt spannend. Gruß, Nils

Moin, hm, du hast Recht. Grmpf, wieder mal ein Beispiel, wo die Exchange-Leute meinen, das AD ein bisschen anders nutzen zu müssen, als es das Design vorsieht. Keine Ahnung, vielleicht sollten die mal was in ihrer Ernährung umstellen oder so. Der positive Effekt: Das ist ein weiterer Eintrag für meine Sammlung "Active Directory Weirdness". :D Gruß, Nils

Moin, das Domänenproblem kann ich nicht bestätigen. Hat hier problemlos geklappt, auf mehreren Rechnern, auch wenn der Rechner während des Upgrades nicht im Firmen-LAN war. Bezüglich des Upgrade-Fixes: Am Anfang des Upgrades versucht das Setup noch Updates abzurufen, das wird dann vermutlich notwendig sein. Vielleicht bauen sie auch parallel einen Patch, den man vor dem Upgrade einspielen muss. Gruß, Nils

Moin, ... ist das panne ... Gruß, Nils

Moin, der Parameter heißt "ComputerName", er ist vermutlich nicht für IP-Adressen vorgesehen. Er erwartet den Namen des Rechners, der ins AD aufgenommen werden soll. Da du das Skript allerdings wohl auch auf dem Rechner ausführst, der gerade installiert wurde, kannst du den Parameter auch einfach weglassen, denn der lokale Computer wird als Standard genommen. Das ist natürlich auch eine Aussage, mit der man wenig anfangen kann ... versetz dich mal in die Rolle eines Supporters, was fragt der wohl als nächstes? ;) Gruß, Nils

Moin, oh, zum Verwirren halten Gruppenrichtlinien nun wirklich einiges in petto! :D Gruß, Nils

Moin, die beiden Artikel beantworten allerdings die Frage nicht. Wenn mehrere GPOs an dieselbe OU gebunden sind, dann greift (im Fall widersprüchlicher Einstellungen) die Priorität der Verknüpfungen. Das lässt sich in der GPMC an der Reihenfolge der GPO-Links ablesen: Je höher das GPO in der Liste steht, desto höher die Priorität. Hier gilt dann der Merkspruch von Mark Heitbrink: Es ist wie beim Sport, der Sieger steht oben auf dem Treppchen, Platz 1 gewinnt. Also: Das GPO, das weiter oben steht, "überschreibt" mit seinen Einstellungen die GPOs, die weiter unten stehen (weil er dier "Last Writer" ist, wie Sunny schon sagte). Gruß, Nils

Moin, ah, prima, dann geht das ja doch direkter. Ich konnte gestern meine Test-VM nicht starten, um das zu probieren. ;) Ist aber trotzdem der canonicalName. :D Gruß, Nils

Moin, das ist nicht der distinguishedName, sondern der canonicalName. Und das wiederum ist ein Constructed Attribute, nach dem sich nicht suchen lässt - oder nicht ohne Weiteres. Wenn "Quick and Dirty" reicht, findest du hier eine sehr simple Funktion, die den canonicalName in einen DN übersetzt (mit einfachem Replace - nicht elegant, aber geht). Mit dem DN kannst du dann den User raussuchen und dessen mail-Attribut auslesen. http://poshcode.org/512 Keine Ahnung, warum Microsoft in dem Exchange-Attribut den canonicalName speichert, mit dem man effektiv kaum was anfangen kann. Moin Nobby, das träfe dann zu, wenn er die E-Mail-Adresse auswerten wollte. Er hat aber nun mal nach ForwardingAddress gefragt ... Gruß, Nils

Moin, oha, danke für die Aufklärung. Ich hatte "users" in dem Kontext sozusagen als funktionale Bezeichnung verstanden, nicht im sinne von "konkrete Personen". Gruß, Nils

Moin, irgendwie belegst du gerade ausgiebig, warum der DC nicht mit anderen Funktionen kombiniert gehört. Warum man solche Diskussionen nur immer wieder führt ... und wo ist das Popcorn? Aber bitte, du kannst das auch weiter als "einen neuen Motorblock verkaufen" einordnen. Gruß, Nils

Moin, spätestens nach so einem Vorkommnis sollte die Bereitschaft, ca. 1000 Euro inkl. Lizenz zu investieren (oder bei VM-Einsatz: nicht mal das) durchaus gegeben sein. Und deine Ausführungen, was einen guten Admin ausmache, nehme ich angesichts des hier Diskutierten eher mit Staunen zur Kenntnis. Vor allem den Arroganzgehalt. Gruß, Nils

Moin, gut, aber nur weil ich auch was von dem Popcorn will: Windows.old ist kein bootfähiges Betriebssystem. Es handelt sich um ein Ordnerbackup der Dateien, die beim Upgrade ausgetauscht wurden. Das ist nur deshalb da, damit man das Upgrade rückgängig machen kann. Man kann die dort liegenden Betriebssystem-Fragmente nicht booten. Selbst wenn man das durch viel Gebastel hinbekäme, ist es nie so gedacht gewesen, und es wird mit größter Sicherheit kein stabil laufendes System dabei entstehen. Wenn du ein Dual-Boot-System willst, dann musst du eins ausdrücklich installieren. Durch den Upgrade-Vorgang entsteht kein Dual-Boot-System. Schön, dass du dich jetzt nebenbei über den Windows-Bootvorgang informiert hast. Das nützt dir für dein Vorhaben aber nicht. Gruß, Nils PS. Ist ja Sommerloch, da gibt es auch schon mal Wiederholungen.

Moin, und wo wir dabei sind und es noch niemand ausdrücklich gesagt hat: Künftig den DC von anderen Rollen trennen. Ein DC ist ein DC und nur ein DC. Ein Fileserver ist ein Fileserver. Dass das auch in möglicherweise kleineren Umgebungen wichtig ist, erfährst du gerade. Gruß, Nils

Moin, prima. So als Tipp für die Zukunft: In einer Baumansicht ist es meist problemlos möglich, die Zweige zu öffnen und nachzusehen. Gerade beim ADSI Editor ist das, wie du merkst, oft auch sehr erhellend. Gruß, Nils