zahni

Solange der Hypervisor eine von MS unterstützte Third-Party Lösung ist, hast Du keine Probleme. Und Citrix sollte dazu zählen. Ich habe gestern auch einen Case bei MS aufgemacht, damit ein manueller Kernel-Dump aus einer VMWare-VM analysiert wird. Wird haben da so ein seltsames Problem. Allerdings "bedienen" wir uns hier aus einem Premier-Vertrag unserer "Mutter". Jetzt können sich VmWare und MS ihre Case-Id's gegenseitig... ;)

Hast Du etwa aktive Snapshots auf den VMs? Die hat man in produktiven Umgebungen nicht. Niemals. Die nutzt man nur kurzzeitig, wen man weis, dass man es machen kann, oder zum Backup Ausgenommen sind spezielle Lösungen wie VMWare View. Die Lösung weis dann aber auch was sie macht ;) Vor der Migration des Hypervisors ist es dringend zu empfehlen, alle Snapshots zu löschen, besonders jene, die auch den CPU-Status/RAM enthalten.

Um sie z.B. an einer zentralen Stelle zu pflegen. Das machen wir schon ewig so und funktioniert auch unter 2010. Hier werden sogar Verzeichnisse als Reiter angezeigt und es werden Reiter ausgeblendet, wenn sich im Verzeichnis keine geeignete Vorlage befindet (z.B. nur Excel) oder der User keine Leserechte im Verzeichnis hat. BTW. Bei 2010 und höher müsste man sogar eine SharePoint-Lin einbinden. Habe ich aber nicht probiert. Das Problem des TO meiner Meinung nach wirklich, dass er es mit der Normal.dot machen will.

Was hast Du denn für CAL? Device oder User? Und für welche Version?

Also Gruppenvorlagen dürfen natürlich in einer Freigabe auf einem Server liegen. Nur eben nicht die Normal.dotm, da Word hier zur Laufzeit reinschreibt. Diese das wird exklusiv persönlich vom jeweiligen Benutzer verwendet und wird im Userprofil oder im festgelegten Ort für "Benutzervorlagen" gespeichert. Hierbei sollte es sich um ein Laufwerk/Verzeichnis handeln, dass exklusiv vom User verwendet wird.

Bei "bei mir" reduziert sich der RAM-Verbrauch mit dem Update deutlich.

Hängt Euch einen 2 TB USB-Stick dran. Dan müsst Ihr nie wieder einen Gedanken an Eure Daten verschwenden ;)

Wo hattest Du nochmal Probleme?

Du sollst einfach prüfen, Ob Du im Netz einen Loop hast. Das doch nix mit der Software zu tun, sondern mit der Verfolgung der Kabel. Oder Deine Switche helfen dabei. Oder eine Fachfirma...

Wo habe ich das geschrieben?

http://de.wikipedia.org/wiki/Switching-Loop

Vermutlich liegt es an "Windows Server 2012 R2 Datacenter - Testversion" Probiere es mit einer Vollversion.

Hier gäbe es noch eine Anleitung: https://msdn.microsoft.com/de-de/library/cc645923.aspx

Übrigens scheint es heute eine Update zu geben, dass die Probleme mit dem Update Client beheben soll: https://support.microsoft.com/en-us/kb/3050265

Und hoffentlich hast Du Dir keinen Loop gebaut. Leg doch mal die ganzen Tools beiseite und erstelle einen vernünftigen Netzplan. Bei Wireshark muss man schon ein wenig wissen, was dort passiert.

Das kann durchaus sein. Viele DB-Systeme schreiben Queries intern sowieso um, sol lange das Ergebnis sich nicht ändert und der andere Weg performanter ist.

Und nun lies nochmal die Anforderungen des TO. Er will nach Datum löschen. Der PK-Index bringt also nichts. Hast Du ja jetzt auch festgestellt.

Ich vermute mal, dass Du nach Nested Sets suchst: http://www.klempert.de/nested_sets/ http://de.wikipedia.org/wiki/Nested_Sets Edit: Oder: select id from table where user = 'user1' and id not in vater

Spontan: select id from table where id not in vater "not in vater" kann auch durch ein Sub-Select ersetzt werden.

Hallo und willkommen im Forum. Ein Join auf der gleichen Tabelle? Was soll eigentlich als Ergebnis rauskommen?

Dann überlege Dir mal, wie dieser PK ermittelt wird und ob ein sprechender Delete-Befehl performant ist.

Ein PK ist sicher aus Design-Gründen immer zu empfehlen. Mit der Performance hat er aber nur indirekt etwas zu tun. Auf einem PK wird immer vom System ein Index angelegt. Wenn Du aber z.B. gefiltert nach einem Datum einen Datensatz löschen willst, nützt Dir dieser Index überhaupt nichts. Der würde nur helfen, wenn DU z.B. delete from mytable where PK=12345; ausführen willst. Besser ist es, die Queries zu analysieren und dazu passende Indizes zu erstellen. Das macht der Entwickler. Wenn der es nicht kann, bleibt es am DBA hängen ;) Bei MS SQL hilft Dir der "Database Engine Tuning Advisor"

Der "Remaining Activation Count" hat damit nichts zu tun. Das die die Zahl der verbleibenden "Rearms", die offensichtlich erschöpft ist. Für den Rest: Nun, MS könnte anhand des MAKs den echten Besitzer ermitteln. Der Rest geht in Richtung Rechtsberatung, was wir hier nicht leisten können und dürfen. Hast Du mit PayPal gezahlt? Dann versuche über diesen Weg Dein Geld zurückzubekommen. Wenn der Verkäufer es möchte, kannst Du Ihm seine Lieferung natürlich zurückschicken ;)

Das ist normal. Für den Built-In User "Administrator" ist UAC deaktiviert. Zum bei dem Rest rollen sich mit die Fußnägel... ;)

Aber dann kannst Du endlich mal Deine Probleme lösen. Es gibt auch Firmen, die das können. Man muss nicht alles selber machen.