NilsK

Macht ja nix. ;) War eigentlich nur Besserwisserei von mir ... :D

Moin, naja, das beschreibt dein Zitat ja durchaus: Das Upgrade-Programm prüft auf Basis der Spezifikationen, und die Schnittstelle, die sich in einer VMware-VM meldet, ist abgekündigt. Also bietet das Programm kein Upgrade an. Da bestünde ja das Risiko, dass der Kunde hinterher ohne funktionierendes Windows da sitzt. Die Installationsroutine selbst wird wahrscheinlich genauer gucken, und sie führt ja eine Neuinstallation durch. Da ist die Risikolage anders. Klappt es denn, wenn du deine VM mit einem Windows-10-ISO aktualisierst? Gruß, Nils

Moin, das kann er auch tun, das Ergebnis ist dasselbe wie bei meinem (schnelleren) Weg. Gruß, Nils

Moin, ganz grob: Wenn es wirklich nur zwei Windows-Server-VMs sind, dann braucht dein Xen-Host eine Lizenz Windows Sever 2012 Standard Eine Lizenz Exchange 2013 Standard Für jeden "natürlichen" User eine Windows-CAL für 2012 (also wohl 70) Für jeden "natürlichen" User eine Exchange-CAL für 2013 (also wohl 70) Da es in deinem Szenario mehr Geräte als User sind, ist vermutlich die User-Lizenzierung günstiger. So "belegt" jeder User eine Lizenz (auch wenn er nicht arbeitet), darf aber mit mehreren Geräten zugreifen. Sofern deine Xen-Umgebung aus mehr als einem Host besteht (als Cluster), muss jeder Host eine Windows-2012-Lizenz haben, und dein Exchange benötigt dann Software Assurance. Gruß, Nils

Moin, hier sind auch Leute, die das schon mal gemacht haben. Und die wissen, dass das nicht "mal eben" zu machen ist und Tipps in einem Forum nicht ausreichen. Daher hast du ja schon mehrfach die Empfehlung bekommen, jemanden dazuzuholen. Gruß, Nils

Moin, ernst gemeint: Wenn es funktionieren soll, dann hol dir jemanden ins Haus, der sich damit auskennt. Profile in einer TS-Umgebung sind die Problemquelle Nr. 1. Man kann da vieles verkehrt machen, was die Schmerzen vergrößert. Zudem wäre auch noch mal das Lastverteilungskonzept zu prüfen. Auch das bietet viele weitere Stolperstellen. Gruß, Nils

Moin, persönlich einen, zumindest monitort der offiziell. :D Allenfalls bei Einsatz von Fine-grained Password Policies lasse ich mich dazu erweichen, dass ein automatisches Lockout für Nicht-Dienstkonten okay sein könnte. Sonst halte ich es für grob fahrlässig. Aber wie du ja schon richtig sagst, das weißt du ja. ;) Gruß, Nils

Moin, da gibt es einige, die du im Web sicher schnell findest. Wie immer, kommt es auch hier auf die Anforderungen an. Gruß, Nils

Moin, gut zu wissen, dieses Detail kannte ich auch nicht. Ist das in allen EAs drin? Mein Hinweis bezog sich vor allem auf den weit verbreiteten Irrglauben, dass man Schulungsrechner allgemein nicht lizenzieren müsse. Da es sich bei einer Schulung zweifellos um einen produktiven EInsatz handelt (und nicht um eine reine Evaluation), ist dafür in der Regel sehr wohl eine Lizenz nötig - nicht nur bei Microsoft, sondern auch bei praktisch allen anderen Herstellern. Gruß, Nils

Moin, hm, das wundert mich. Zumindest bei einer Neuinstallation ist der VMware-Treiber kein Problem unter Workstation 11 (was ja dieselbe Technik sein sollte wie dein Player). Vorher in Workstation 8 lief Windows 10 ebenfalls problemlos, wenn ich den VGA-Treiber weggelassen habe. Ein Upgrade von 8.1 habe ich noch nicht versucht. Vielleicht liegt es auch daran. Wundern tut's mich trotzdem. Gruß, Nils

Moin, davon halte ich "keinen" für die beste Option. Bei 500 fehlgeschlagenen Loginversuchen ohne Erfolg tippe ich dann aber doch auf einen Dienst oder sowas. Die meisten Adminkennwörter in der realen Welt* würden einem einigermaßen engagierten Brute-Force-Angriff nicht so lange standhalten, daher wird es keiner sein. Gruß, Nils

Moin, welche VMware-Version hast du denn? Sonst könntest du den VMware-VGA-Treiber auch deinstallieren, der mitgelieferte funktioniert auch ganz gut, kann aber die automatische Größenänderung meist nicht. Damit sollte das Upgrade dann ja klappen. Gruß, Nils

Moin, eine Schulung ist selbstverständlich produktiver Einsatz. Gruß, Nils

Moin, PST-Dateien auf Netzlaufwerken sind nicht unterstützt. Erfahrungsgemäß kommt es dabei auch tatsächlich sehr schnell zu Problemen. Sinnvoller wäre eine richtige Archivierung mit einem Werkzeug, das dafür gebaut wurde. Gruß, Nils

Moin, ja, das ist die Benutzerkontensteuerung/UAC. [benutzerkontensteuerung (UAC) richtig einsetzen | faq-o-matic.net] http://www.faq-o-matic.net/2008/02/22/benutzerkontensteuerung-uac-richtig-einsetzen/ Abhilfen: Berechtigungen per Kommandozeile setzen in einem CMD-Fenster, das als Admin gestartet wurde, z.B. mit SetACL (separater Download) Berechtigungen mit dem "Mercedes" verwalten, SetACL Studio (kostenpflichtiges Tool) Berechtigungen mit einem Dateimanager bearbeiten, der mit UAC umgehen kann, z.B. Total Commander Übergeordnete Berechtigungen so setzen, dass eine andere Gruppe als "Administratoren" die Berechtigungen verwalten darf (nicht empfohlen) Berechtigungen mit dem vordefinierten "Administrator" bearbeiten (nicht empfohlen) UAC abschalten Gruß, Nils

Moin, ist das der einzige Domänencontroller? Falls nicht, würde ich mir den Umstand nicht machen und mich nur um die Dateien kümmern, die ggf. noch von Interesse sind. Grundsätzlich kann man mit dem Systemstate natürlich schon ein Recovery machen, aber wie es eben beim Recovery so ist ... ... einer der vielen Gründe, warum ich Full-Server-Backups nicht pauschal für die beste Option halte. Gruß, Nils

Moin, was genau habt ihr wo genau abgeschaltet? Gib mal in einem CMD-Fenster ein: net accounts /domain Was kommt zurück? Gruß, Nils

Moin, jein. Rein von der GPO-Verarbeitung ist das richtig. Kennwortrichtlinien gehören trotzdem nur in die DDP, weil es da noch harkodierte Prozesse im AD gibt: [besonderheiten der AD-Kennwortrichtlinie | faq-o-matic.net] http://www.faq-o-matic.net/2010/06/24/besonderheiten-der-ad-kennwortrichtlinie/ Gruß, Nils

Moin, im Grundsatz schon - bei den hier genannten Dimensionen kommen aber schnell noch andere Faktoren hinzu. Einen 50-GB-Brocken etwa kann man in einem Cluster nur dann sinnvoll betreiben, wenn auf den anderen Nodes eben diese 50 GB auch frei bleiben, damit ein Failover funktionieren kann. Da ist man dann schnell bei etwas mehr als "ein paar GB zusätzlich" ... Gruß, Nils

Moin, also ... in der gegebenen Situation braucht es ja erst mal kein VM-Backup vom Host aus, sondern ein Backup von Exchange. Hast du das schon mal vom Exchange-Server aus über Windows Server Backup versucht? Gruß, Nils

Moin, kurz gesagt: Du liegst falsch ... Wenn es wirklich mandantenfähig sein soll im Sinne von "Kunde X darf von Kunde Y nichts wissen", dann muss man das von vornherein so aufbauen. Lass dir gesagt sein, dass der Aufwand sehr groß ist. So groß, dass schon mehrere Kunden, die ich in der Richtung beraten habe, die Projekte abgeblasen haben. [Multi-tenancy in Exchange 2013: Exchange 2013 Help] https://technet.microsoft.com/en-us/library/jj862352%28v=exchg.150%29.aspx Gruß, Nils

Moin, bei Servern dieser Art immer mehrere virtuelle Disks. Hier könnte auch eine Aufteilung in System, Logs und Datenbanken sinnvoll sein. Gruß, Nils

Moin, eine Installation auf eine andere Disk zu übertragen, ist kein Problem, wenn die alte Disk nicht mehr verwendet wird. In dem Fall gibt es ja kein SID-Duplikat. Gruß, Nils

Moin, so ganz trivial ist das allerdings nicht. Wenn man Empfänger ausblendet, kann es Probleme bei der Outlook-Einrichtung geben. Was ist der Hintergrund? Handelt es sich um eine Umgebung mit mehreren Mandanten? Dann müsste man die komplett nach einem ganz bestimmten Verfahren einrichten, das sehr aufwändig ist. Gruß, Nils

Moin, wer sowas (pauschal) empfiehlt, hat das Memory Management von Windows nicht verstanden. Gruß, Nils