NilsK

Moin, ja, das klingt passend. Gruß, Nils

Moin, Firefox benutzen ...? ;) Du kannst den Enterprise-Modus für den IE aktivieren oder die Kompatibilitätslisten pflegen. Oder bei einzelnen Webseiten mit F12 die Kompatibilität gezielt durch Maskierung erzwingen. Meist liegt das Problem nur indirekt am IE11, weil die Browserweichen vieler Webseiten mit dem User Agent String nicht klarkommen (hier liegt dann wieder eine Mitschuld beim IE11, weil er zusätzliche Stolperfallen für solche Browserweichen hat). Meist hilft es dann, den IE anzuweisen, sich als eine ältere Version auszugeben. Manchmal ist es zusätzlich noch nötig, ihn auf die ältere Rendering-Engine umzustellen. Die obigen Hinweise helfen dabei meist. Mit OneDrive kann ich mich an derartige Probleme allerdings nicht erinnern. Das sollte mit dem IE11 auch so funktionieren. Gruß, Nils

Moin, das Problem hatte ich in einer vergleichbaren Situation unter Hyper-V 2008 auch mal. Leider erinnere ich mich nicht mehr genau an das Vorgehen, mit dem wir es gelöst haben. Aber: Hast du schon mal aus der VM die Netzwerkkarte entfernt und eine neue hinzugefügt? Vielleicht sogar besser umgekehrt: Neue Netzwerkkarte zusätzlich dazu. Dann die Konfig der "alten" Karte auf DHCP stellen, sie deaktivieren und die "neue" Karte konfigurieren. Dann die "alte" Karte aus der VM-Konfig entfernen und am Ende aus dem Gerätemanager löschen. Gruß, Nils

Moin, das denkst du ... so haben auch schon mehrere meiner Kunden gedacht und hinterher festgestellt, dass sie eben doch nicht mit ihrer abgeschotteten Klon-Umgebung verbunden waren, sondern mit der Realumgebung. Aber bitte, soll halt jeder aus seinem eigenen Schaden klug werden. Gruß, Nils

Moin, ja, im Kern der Papierkorb. Das ist ja Grund genug. :) Gruß, Nils

Moin, aus Lizenzsicht ist das durchaus nicht unsinnig - aber das hängt vom Szenario ab. Tatsächlich ist dies ein Konstrukt, das vor allem im Hosting virtueller Desktops oft eingesetzt wird. Leider hat Microsoft nämlich die VDI-Lizenzierung so seltsam gebaut, dass man als Hosting-Dienstleister so gut wie keine legale Möglichkeit hat, virtuelle Desktop-Betriebssysteme für Kunden bereitzustellen. Client-Windows kennt nämlich kein SPLA, das dafür nötig wäre. Server-Windows hingegen schon. Soweit als kurze Einschätzung dazu. Konkrete Details zur Lizenzierung müsstst ihr selbst klären. Wenn es allerdings um ein "kleineres VDI-Projekt" für den Eigenbedarf - also nicht für Kunden - geht, dann dürfte es insgesamt sowohl technisch als auch kaufmännisch einfacher sein, mit Client-Betriebssystemen zu arbeiten. Gruß, Nils

Moin, ja, du kannst Domäne und Forest hochstufen. Das geht auch im laufenden Betrieb problemlos. Theoretisch könnte es zwar Applikationen geben, die damit ein Problem haben, aber mir ist noch keine solche real untergekommen. Heikel sind nach meiner Erfahrungen nur sehr neue Exchange-Versionen und sehr neue AD-Betriebsmodi - so wollte Exchange 2010 erst mit bestimmten Patches reibungslos in einer 2012-Domäne arbeiten, als 2012 noch ganz neu war. Aber solche Probleme behebt das Exchange-Team normalerweise nach ein paar Wochen. [Exchange Server-Unterstützbarkeitsmatrix: Exchange 2013 Help] http://technet.microsoft.com/library/ff728623%28v=exchg.150%29.aspx Gruß, Nils

... wir haben uns übrigens nicht abgesprochen. ;) Gruß, Nils

Moin, auch dann benötigst du Windows-CALs. Aber wenn ihr schon eine Domäne habt, sollten die CALs doch ohnehin bereits vorliegen ...? Gruß, Nils

Moin, um die Datenbanken selbst wiederherstellen zu können, benötigst du zunächst nur Backups der Datenbanken. Die master-Datenbank zu sichern, ist in erster Linie dann interessant, wenn man ein vollständiges Recovery des ganzen SQL Server ausführen möchte. Für diesen Fall ist besonders relevant, dass in der master-DB alle Logins stehen (also die User auf Server-Ebene). Außerdem sind in der master-DB auch alle produktiven Datenbanken verzeichnet. Stellt man eine einzelne gesicherte Datenbank auf einem anderen SQL Server wieder her, dann gibt es - je nach Berechtigungsmodell - evtl. zunächst Zugriffsprobleme, weil die User innerhalb der Datenbank keinen Logins auf Serverebene zugeordnet sind. Das kann man korrigieren, aber dazu muss man natürlich wissen, wie die Zuordnung aussehen muss. Dieser Vorgang ist einfacher, wenn man ausschließlich mit Windows-Logins arbeitet. Die msdb-Datenbank ist eine reine Verwaltungsdatenbank, die in den meisten Umgebungen eher unkritisch ist. Sie enthält z.B. die Backup-Historie aller Datenbanken, aber auch Jobs des SQL Server Agent usw. Wenn man mit dem Agent arbeitet, sollte man msdb also auch sichern. Ebenso, wenn man die produktiven Datenbanken mit komplexeren Verfahren sichert (z.B. kombiniert Full, Differential und Log Backup), denn dann benötigt man die Historie, um ein gezieltes Restore zu machen. Die Model-Datenbank ist eine Vorlage für neue Datenbanken. Da man die i.d.R. nicht anpasst, braucht man sie auch nicht zu sichern. Gruß, Nils

Moin, gibt es im Eventlog der VM und des Hosts Meldungen, die mit dem Problem zu tun haben könnten? Gruß, Nils

Moin, Norbert hat schon Recht. Du solltest dir jemanden dazuholen. Am Ende sparst du damit ganz sicher. Gerade wenn Fragen wie ActiveSync, Außenanbindung, Terminalserver usw. ins Spiel kommen, gibt es doch schon eine ganze Menge, was man falsch - oder zumindest nicht so gut - machen kann. Und ein Tipp dazu: Nimm niemanden von dem Lizenzhändler, der dir die simplen Fragen nicht beantworten kann ... Gruß, Nils

Moin, für 20 User benötigst du 20 CALs für Windows und für Exchange. In deiner Liste sind 40 Windows-CALs, die dürften nicht nötig sein, 20 reichen ja. Die Exchange-Enterprise-CAL benötigst du nur für einige Zusatzfunktionen wie das Exchange-eigene Archiv, Unified Messaging und zentrale Ordnerverwaltung. Nutzt du diese Funktionen nicht, kannst du die Enterprise-CAL weglassen. Office wird pro Arbeitsplatz lizenziert. In der Exchange-CAL ist Office bzw. Outlook nicht enthalten. Gruß, Nils

Moin, geht hier problemlos ... (OL 2013 gegen Ex 2010). Gruß, Nils

Moin, ja, dieses Vorgehen würde vermutlich am wenigsten Ausfallrisiko und am wenigsten Downtime erzeugen. Gruß, Nils

Moin, nein, wann genau die Anmeldung geöffnet wird, ist noch nicht bekannt. Ich gehe aber davon aus, dass wir hier zu den ersten gehören, die davon erfahren. :) Gruß, Nils

Moin, du hast "im Prinzip" Recht. Allerdings sind in der DDCP bereits Überwachungseinstellungen definiert, sodass ein separates GPO dort u.U. nicht die Ergebnisse erzeugt, die man haben möchte. Um den Artikel aufzurufen, suche ich immer nach "dandelions vcr" ;) [Dandelions, VCR Clocks, and Last Logon Times: These Are a Few of Our Least Favorite Things - Hey, Scripting Guy! Blog - Site Home - TechNet Blogs] https://blogs.technet.com/b/heyscriptingguy/archive/2010/01/27/dandelions-vcr-clocks-and-last-logon-times-these-are-a-few-of-our-least-favorite-things.aspx Gruß, Nils

Moin, da es hier zumindest in der Beschreibung etwas durcheinander geht, fangen wir erst mal mit den Basics an: [Die Anwendung von Gruppenrichtlinien steuern | faq-o-matic.net] http://www.faq-o-matic.net/2014/04/07/die-anwendung-von-gruppenrichtlinien-steuern/ Du sagst, "seit einiger Zeit" würden keine GPOs "mehr" angewendet. Es hat in derselben Konstellation also mal funktioniert? Wenn ja, was hat sich seither geändert? Sind evtl. Berechtigungen an GPOs oder an AD-Objekten geändert worden? Hat es Änderungen in der Infrastruktur gegeben? Die fehlerhafte Standortangabe, die du erwähnst, kann bedeutsam sein, muss sie aber nicht. Finden sich in den Eventlogs der DCs und der Clients Hinweise auf AD-, DNS- oder GPO-Probleme? Gruß, Nils

Moin, so ohne Weiteres (leider) erst mal gar nicht. Die administrativen Zugriffe, die dich interessieren, kannst du in der Default Domain Controllers Policy im Computerzweig definieren. Die Protokolleinträge finden sich dann im Security-Eventlog des jeweiligen DC. Wohlgemerkt: Jedes einzelnen DC; um eine Gesamtansicht zu erhalten, musst du also alle DCs überprüfen. Zusätzlich stehst du dann noch vor dem Problem, dass das Security-Eventlog sehr unübersichtlich ist, weil zu einem einzelnen Zugriff oft zahlreiche Einträge gehören. Das musst du dann also auch noch auswerten bzw. filtern. Seit Windows Server 2008 kannst du dann noch das erweiterte Logging aktivieren und so die Detailtiefe erhöhen - du siehst dadurch z.B. bei Änderungen den "alten" und den "neuen" Wert. Auch das richtet man in der DDCP ein, allerdings an etwas anderer Stelle. Lösen musst du dann in jedem Fall das Log Management - also die Datenmenge und die Auswertung. Hierzu gibt es auch kommerzielle Werkzeuge. Gruß, Nils

Moin, mal ganz nebenbei gefragt: Mit was für Lizenzen arbeitest du denn da? Und wer nutzt das Ganze hinterher? Gruß, Nils

Moin, vor allem musst du dich von dem Gedanken verabschieden, dass die virtuellen Netzwerke in Hyper-V so funktionieren würden wie in VMware Workstation. Die Szenarien für beide Produkte sind völlig unterschiedlich. Ein vSwitch in Hyper-V hat auch keine IP-Adresse. Ebenso verteilt er keine IP-Adressen an Gäste und führt keine Adressübersetzung und kein Routing durch. Die Konfiguration, die in dem oben verlinkten Video gezeigt wird, ist für Heim- oder Testnetzwerke machbar, in der professionellen Serverwelt lässt man sowas bleiben. Gruß, Nils

Moin, darüber hinaus erscheint es mir etwas unortrhodox, ausgerechnet Management und Live Migration zu koppeln. Das Management-Netz nutzt du, um die Hosts zu verwalten sowie für deren Anbindung an AD und WSUS. Die Live Migration hingegen findet nur zwischen den Hosts statt, da willst du normalerweise möglichst wenig anderen Traffic. Ohne näher draufgeschaut zu haben, käme mir als Skizze Folgendes in den Sinn: Team 1: VM-Netz, vSwitch drauf, keine Konfig im Management-OS 2 Karten ohne Team, aber mit MPIO für das SAN (vermutlich iSCSI) - i.d.R. alles außer IP abschalten, eigenes iSCSI-Netz, kein Routing, kein DNS/WINS 2 Karten oder ein Team für Cluster, CSV und Live Migration - Protokollbindungen weitgehend belassen, aber ein eigenes Netz und i.d.R. kein Routing, kein DNS/WINS 1 Karte oder Team für Management - normale Konfiguration Das Management-LAN zu separieren, ergibt nur dann Sinn, wenn es auch tatsächlich ein separates Management-LAN gibt. Das ist in vielen mittleren Umgebungen nicht der Fall - dann könnte man das Management über dasselbe Netz laufen lassen wie die VMs. Denkbar wäre auch ein großes Team aus sechs Karten für VM, Cluster und Management mit mehreren vNICs in der Parent Partition und Separation über VLANs und Bandbreiten-Garantien (geht nur per PowerShell). Das iSCSI würde ich auch in dem Fall über zwei separate Karten mit MPIO laufen lassen. Gruß, Nils

Moin, ja, aufnehmen kannst du den Server. Und ja, du kannst ihn hinterher auch hochstufen. Die nötigen Schritte dazu führt der Server-Manager automatisch aus (Schema erweitern, Forest und Domäne anpassen). Den Betriebsmodus kannst du aber erst dann hochsetzen, wenn die 2003-DCs deinstalliert sind. Gruß, Nils

Moin, mal ganz abgesehen davon - wie willst du denn die Daten auf den NAS-Büchsen synchron halten? Mir scheint das doch noch nicht recht durchdacht ... Warum nicht die User zu den Daten holen statt die Daten zu den Usern? Mit einer Terminalserverumgebung lässt sich die Arbeit evtl. über beide Standorte gut zentralisieren. Gruß, Nils

Moin, prima, danke für die Rückmeldung! Gruß, Nils