NilsK

Moin, vielen Dank, aber mit deiner Antwort hast du gerade belegt, warum man 1. uralte Threads in Ruhe lässt und 2. keine Threads kapert. Was du beschreibst, ist sicher interessant (wenn auch nicht neu), hat aber mit dem Thema des Threads leider nichts zu tun. Also, schön, dass du uns gefunden hast, aber nächstes Mal bitte einen neuen Thread erzeugen. Danke. Gruß, Nils

Moin, konvertieren kann man nicht. Und SSD kann natürlich "Bumms" geben, aber ohne Planung sollte man einen Host natürlich nicht sizen. Insofern wundere ich mich über die Reihenfolge: erst beschaffen, dann planen? Ist ja nicht so, dass man beim Sizing nichts falsch machen könnte ... Gruß, Nils

Moin, verteilt der ESX zufällig eine falsche Zeit? Gruß, Nils

Moin, dann bleibt noch die Frage nach der Definition von "Schädling" ... :D Es gibt ganze Regionen auf der Welt, wo man mit Tape nichts wird, weil die z.B. aufgrund der Luftfeuchtigkeit zu schnell vergammeln. In solchen Regionen gibt es durchaus auch lebendes Krabbelvieh, das die Daten zwar nicht ausspioniert, aber durchaus nachhaltig schädigt. Gruß, Nils

Moin, ja, aber auch dann wirken sich Gruppenmitgliedschaften nicht in der angefragten Weise aus. :D Gruß, Nils

Moin, deine erste Frage verstehe ich nicht. Zu deiner zweiten Frage: Es zählt ausschließlich der Speicherort des Benutzerkontos. [Die Anwendung von Gruppenrichtlinien steuern | faq-o-matic.net] http://www.faq-o-matic.net/2014/04/07/die-anwendung-von-gruppenrichtlinien-steuern/ Gruß, Nils

Moin, wäre es in deinem Szenario nicht einfacher, in einer Schleife alle Datenbanken des Servers, der leergeräumt werden soll, auf den anderen zu verschieben? Dann liest du einfach alle Datenbanken des betreffenden Servers aus und lässt die verschieben. Und noch einfacher dürfte es per Maintenance Mode gehen. [Exchange 2013 Maintenance mode - Exchange World - Site Home - TechNet Blogs] http://blogs.technet.com/b/nawar/archive/2014/03/30/exchange-2013-maintenance-mode.aspx Gruß, Nils

Moin, OK, wenn ich hier dauernd als Bezugspunkt genommen werde, dann eben noch eine Antwort. Warum überhaupt Backup auf Festplatten? Tape-Backups haben eine Reihe von Eigenschaften, die in der hier diskutierten Situation von Vorteil wären. Ein vernünftiges Backup muss nicht fünfstellig kosten. Vierstellig ist aber in den meisten Unternehmen schnell erreicht und selten unangemessen. Ein SAN ist nicht (primär) für Backups da, sondern meist völlig oversized dafür. Wenn es aber Festplatten sein sollen, muss das System schon eine hohe Zuverlässigkeit haben. Ein Backup-Device, das man zwischendurch abschaltet, muss zuverlässig dann laufen, wenn es gebraucht wird. Backups neigen dazu, schon mal eine ganze Zeit zu laufen. Sie laufen auch zwischendurch mal länger als üblich. Eher ungünstig, wenn dann das Device abschaltet. Gesparte Stromkosten stehen nie in einem sinnvollen Verhältnis zum Risiko eines Datenverlusts. Die Datensicherung gehört zu den wichtigsten Assets eines Unternehmens. Das muss sich im Budget widerspiegeln. Wer das Backup vom Backup her plant, plant von der falschen Seite her. Man muss vom Recovery her planen. So, darf ich jetzt raus? Danke. Gruß, Nils

Moin "finace23", so leicht lässt sich das nicht bewerten. Solche Fragen sind für ein Forum nicht geeignet. Ich illustriere das mal mit einer Analogie: Deine Frage entspricht in etwa der Frage "was ist besser, ein 3er-BMW oder ein Mercedes Sprinter?" Gruß, Nils

Moin, nur so viel, dann ist in diesem Thread für mich Schluss: Ausgangspunkt einer Backup-Strategie muss immer die Frage nach dem Recovery sein. Was muss in welcher SItuation in welcher Qualität wiederherstellbar sein? Ergänzender Hinweis dazu: Eine Antwort wie "alles, und zwar so schnell wie möglich" hilft hier nicht weiter. Und: In den meisten Unternehmen will man sich auf sein Backup verlassen können. Heimanwender-Techniken wie USB (oder auch SOHO-NAS-Geräte) sowie selbst gebastelte Sicherungsverfahren passen dazu so wenig wie übertriebene Knauserigkeit. Wenn die Daten so wenig wert sind, dass man sie wegen ein paar Cent auf der Stromrechnung in Gefahr bringt, dann braucht man sie auch gar nicht zu sichern. So, damit bin ich dann raus. Gruß, Nils

Moin, guter Hinweis, danke. Schon bezeichnend, dass der Artikel, der eine der wichtigsten aktuellen Funktionen für Unternehmen beschreibt, aussieht wie eine Hobby-Webseite aus den frühen Neunzigern ... Gruß, Nils

Moin, das Problem ist: Wie das Upgrade in Unternehmen laufen soll, ist immer noch völlig unklar. Irgendwann soll es mal ein "Windows Update for Business" geben, aber wie so vieles im Zusammenhang mit Windows 10 existiert auch dies nur als Ankündigung. Ebenso soll es eigentlich mal ein Verfahren ähnlich dem Patching geben, damit nicht immer eine Neuinstallation gemacht wird. Auch da: Nix Genaues. Für Enterprise scheint momentan sogar nur ein manuelles Upgrade per ISO zu funktionieren. LTSB ist nicht nur teurer, sondern auch eingeschränkt. Das würde ich mir also schon überlegen, ob da insgesamt ein Vorteil besteht. Wäre ich Admin in einer Firma, würde ich aufgrund all dieser Unklarheiten mit dem Umstieg auf Windows 10 noch warten, bis der Hersteller sich endlich mal bequemt, dazu Klartext zu reden und die nötigen Komponenten bereitzustellen. (Ganz nebenbei ist die Lizenzfrage für Volume-Lizenzen auch noch nicht ausreichend geklärt.) Gruß, Nils

Moin, die Einträge stehen nicht in der Registry. Wenn überhaupt, findest du sie in der Konfigurationsdatei der VM. Aber lass da die Finger von, du machst es dann nur noch schlimmer. Wie du ja jetzt hoffentlich weißt, sollte man bei einem komplexen System wie Hyper-V nicht einfach irgendwo rumwurschteln. (Das wäre bei vSphere übrigens nicht anders, nur falls jetzt jemand Schnappatmung bekommt.) Mach es so, wie Norbert sagt. Falls Export nicht geht, mach aus der laufenden VM heraus ein Backup und stelle das auf einer neuen, ordentlich konfigurierten VM wieder her. Gruß, Nils

Moin, schau noch mal genau hin. Du bekommst genau die Daten, die du laut deinem ersten Posting willst, und zwar in der zweiten Spalte. Das Nachbearbeiten mit Excel dürfte auch für Anfänger weniger als fünf Minuten dauern. Du kannst aber natürlich weitermachen, nur solltest du dann langsam mal anfangen, die Hinweise, die man dir gibt, für eine ordentliche Recherche zu verwenden. Ich kann mir beim besten Willen nicht vorstellen, dass man zu "Rekursion" im Zusammenhang mit Scripting und Funktionen nichts findet. Wir sagen dir gern, wie du auf dein Pferd kommst. Aufsteigen und reiten müsstest du dann aber selbst. Gruß, Nils

Moin, falls der erste von dir zitierte Passus (3d in deinem Zitat) in allen Varianten der Lizenzbestimmungen steht, dürfte das Szenario aber hinhauen: Dort wird das physisch installierte Windows ja nicht verwendet, sondern nur das virtuelle von dem Boot-Stick. Da der Boot-Stick selbst ein Linux bootet, läuft dann exakt eine Windows-Instanz (die in der VM). Wenn dann das physische Windows wieder läuft, gibt es das virtuelle nicht mehr. Das sollte also passen. Aber: Ich denke, das geht nur, wenn auf dem Rechner eine Windows-Lizenz vorliegt, die der von dem Boot-Stick entspricht. Downgrade-Rechte dürfte ein Privatrechner mit seiner Lizenz wohl kaum haben. Und bei Rechnern ohne Windows fehlt die Lizenz gleich ganz. Aus Lizenzsicht würde ich daher die Finger davon lassen. BYOD ist eben in der Regel nicht günstiger, sobald bestimmte Anforderungen gelten. Gruß, Nils

Moin, gestern Abend ist mir eingefallen, dass du das auch viel einfacher machen kannst. Lass das AD die Arbeit machen, es kennt ja alle OUs. Geht sogar ganz ohne PowerShell: Exportieren aller OUs per csvde.exe in eine Textdatei: csvde -f OUs.txt -r "(objectClass=organizationalUnit)" -l canonicalName Erste Spalte entfernen, Suchen & Ersetzen, um das passende Format zu erhalten (z.B. in Notepad oder in Excel) ggf. danach noch Ordnen in der richtigen Reihenfolge (mit SORT, per Excel oder wie auch immer) Gruß, Nils

Moin, bessere NAS-Geräte können auch als Schmalspur-SAN arbeiten und iSCSI-Targest anbieten. Die behandelt der zugreifende Server dann wie lokale Laufwerke und kann sie auch für WSB nutzen. Wenn die Anforderung aber lautet, dass die Backups verschlüsselt sein sollen, dann müsste es schon ein hochwertiges SAN sein. Ich bleibe dabei, dass bei den genannte Anforderungen simple und billige Lösungen ausscheiden. Gruß, Nils

Moin, das ist so nicht (ganz) richtig. Durch die Integration mit DHCP kann man das lösen, allerdings sind die Einträge der Nicht-AD-Clients dann nicht gesichert. Siehe mein oben verlinkter Artikel (der auf eine ähnliche Diskussion hier im Board zurückgeht). Gruß, Nils PS. Ich sehe es richtig, dass dem Link niemand gefolgt ist, obwohl ich ihn schon zweimal angegeben habe?

Moin, die Suche nach "powershell script launcher" bringt einige viel versprechende Fundstellen. Gruß, Nils

Moin, ich muss mich korrigieren. Tatsächlich kann man auch unter Hyper-V in Grenzfällen besseren Durchsatz erreichen, wenn man mehrere virtuelle SCSI-Controller einrichtet. Aufgrund diverser Optimierungen unter der Haube ist das allerdings nur relevant, wenn man IOPS-Anforderungen im hohen sechsstelligen Bereich oder darüber hat. Gruß, Nils

Moin, und danach noch Liegestütze, oder? ;) Gruß, Nils

Moin, deine Rekursion ist nicht richtig. Die Funktion muss per Parameter eine Start-OU als DN bekommen. Sie liest dann alle Unter-OUs aus. In einer Schleife ruft sie für jede Unter-OU sich selbst auf und übergibt den DN der jeweilogen Unter-OU als Parameter. Das Hauptskript ruft nur einmal die Start-OU auf. Den Rest macht die Funktion per Rekursion. Gruß, Nils

Moin, ich kann dazu nur beitragen, dass ich seit Windows 8 die Zuordnung von Standarddruckern als sehr instabil und unvorhersagbar erlebe. Das ist leider mit Windows 10 auch noch so. Möglich, dass das auch im Server so ist, ist ja derselbe Code. Gruß, Nils

Moin, vielen Dank. Anmerkungen zu deinen technischen Annahmen: 4-CPU-Maschinen sind sehr rar. Der Normalfall sind 2-CPU-Maschinen mit hoher Core-Zahl. Eine Ausstattung mit 4 CPUs à 4 Cores wird man praktisch nie antreffen. Selbst dann wäre aber zu berücksichtigen, dass pro CPU mindestens 8 Cores lizenziert werden müssen (siehe FAQ), da dürfte deine Berechnung also nicht hinhauen. Und: Im FAQ steht ausdrücklich: Das Kumulieren wird also weiter möglich sein. Gruß, Nils

Moin, so war es seit Jahren kommuniziert worden, ja. Es hatte da kurz nach dem Erscheinen von Hyper-V im Jahr 2008 Unklarheiten und, soweit ich mich erinnere, auch eine Korrektur der PURs gegeben, die dann das oben skizzierte Ergebnis hatte. Hintergrund ist im Wesentlichen, dass in genau dem Szenario, das du beschreibst, Hyper-V sonst auf dem Markt keine Chance gehabt hätte. Gruß, Nils