Dunkelmann

Moin, wenn's in Richtung Netzwerke gehen soll, wäre vielleicht der Cisco CCNA auch was für Dich.

Moin, baue Dir eine möglichst repräsentative Testumgebung aus VMs oder installiere auf 'Blech' und spiele es einfach mal durch. So mache ich es vor fast jeder Migration. Hier findest Du einige Infos zur Migration auf 2012: http://technet.microsoft.com/de-de/library/jj134039.aspx

Genau. Falls ihr eine interne PKI habt, bietet sich auch ein SAN Zertifikat für die Hosts an. Dann brauchst Du nur einen Fingerprint für alle Session Hosts zu verteilen.

Hast Du die SHA Hashes der Hostzertifikate an die Clients verteilt? Adm.Vorlagen - Windows Komponenten - Remotedesktop - Remotedesktop Client - SHA-1 Finger...

Wie lautet denn 'die Meldung'?

Moin, ich würde es von der Netzwerkgeschwindigkeit und der Transaktionsanzahl abhängig machen. Bei 10 Gbit wäre Shared Nothing Live Migration mein Favorit. Bei nur 1 Gbit und sehr vielen Transaktionen könnte die Live Migration zu einer 'unendlichen Geschichte' werden, da wäre vermutlich eine offline Migration schneller und zuverlässiger. Im Prinzip kann es so ablaufen: Zuerst die VM vom Hyper-V Server auf eine Cluster Node migrieren (online oder offline) und dann über den Cluster-Manager hochverfügbar machen. Etwas Downtime musst Du auch bei Live Migration für die Aktualisierung der Integrationsdienste in Kauf nehmen. Dass könnte eventuell im Zuge der ohnehin bevorstehenden Windows Updates mit erledigt werden. Exchange und Hyper-V Replication wird nicht unterstützt http://blogs.technet.com/b/rmilne/archive/2013/07/29/exchange-and-hyper-v-replica-support.aspx

Moin, hat Dukel richtig vermutet, dass diese Threads zusammenhängen? Falls Du noch Unterstützung benötigst, wäre es hilfreich, wenn Du mal eine kurze Zusammenfassung Deines Projektes geben könntest. Zu schreiben, ich habe Hosts auf denen diese oder jene VMs laufen sollen, ist nett zu wissen - mehr nicht. Definiere erstmal die konkreten Anforderungen und Rahmenbedingungen, dann können wir eventuell auch beurteilen, ob Dein Ansatz praktikabel ist oder nicht. Bitte nicht alles nur häppchenweise preisgeben, oder bist Du Poliker und gestehst nur das, was auch nachgewiesen ist :p

Moin, installiere den Server und BE neu; harke es als lehrreiche und lästige Erfahrung ab. Bei einem Backupsystem möchtest Du nicht in der Datenbank rumwerkeln und riskiren, dass ein Restore im Katastrophenfall nicht funktioniert und der Support Dir nur sagt: "selber schuld, da können wir leider auch nicht helfen." Beim nächsten mal, wo Du es mit unbekannter Software zu tun hast, wirst Du dann den Wert von VMs zu schätzen wissen ;)

:) Danke für die Rückmeldung

Schau Dir mal 'vssadmin Resize ShadowStorage' an. Bisher war ich nur einmal in der Velegenheit, so nah am Limit arbeiten zu müssen. Unter 10% freier Platz auf dem Volume und keine Chance kurzfristig neue Hardware zu beschaffen. Zur Überbrückung habe ich die fixed VHDs in dynamische VHDs umgewandelt. Sehr abartig, aber ein paar Monate musste das System noch so durchhalten Welche Grenze sinnvoll ist, hängt von den Gegebenheiten ab. Bei meinem iSCSI Backend (Hardware VSS) habe ich 25% als Limit definiert. Bei den Hosts mit lokaler Platte habe ich gar keine Anpassungen gemacht, da greifen noch die 10% Default. Ich habe gerade mal auf einem nachgeschaut: Volume Size: 1,4 TB In Use: 950 GB Snapshot Space: 140 MB Es laufen aktuell 6 VMs auf dem System und das Backup macht keine Probleme. Wie fertigst Du jetzt das Backup an? Als komplette Systemsicherung? Wenn ja, könntest versuchen zunächst den Backupjob in SystemState/BareMetal und Applikation (Hyper-V) zu splitten und die VM separat sichern http://blogs.msdn.com/b/virtual_pc_guy/archive/2013/02/25/backing-up-hyper-v-virtual-machines-from-the-command-line.aspx

Genau so ist es, im Zweifelsfall bis zu Freeze des Servers, wenn das Backup zu lange dauert. Ist das der Fall hast vermutlich ein massives Performace Problem beim Backup. Ich habe selten mehr als 5% bis 10% des Volumes als Snapshot Space in Nutzung.

Hallo, das SAP im Internet zu veröffentlichen halte ich für keine gute Idee. Ich vermute anhand Deiner Schilderung mit DSL 16k, dass es ein Latenzproblem ist. Klassische Fat-Client Anwendungen setzen häufig eine ausreichende Bandbreite zwischen Client und Server voraus. Bei typischen Consumer oder einfachen Business DSL Produkten ist das selten gegeben; da ist die Upload Rate (384-768k) häufig der Flaschenhals. Daniels Weg über einen Terminalserver und/oder RWW dürfte am einfachsten sein. http://blogs.technet.com/b/sbs/archive/2009/06/25/sbs-2008-introduction-to-remote-web-workplace.aspx

Du könntest mal in den 'System Volume Information' Ordner schauen. Eventuell liegen dort noch ein paar verwaiste Snapshots. Du hast tatsächlich nichts über den Snapshot Space gefunden? Ich bin entsetzt :shock: Aus dem von mir verlinkten Artikel: Wo wird wohl der 'old state' zwischenspeichert? Du darfst drei mal raten :p

Wo ist denn jetzt das Problem, wenn Du Multicast NLB nutzen kannst? :rolleyes: Hast Du schonmal die MAC Table und ggf. den ARP cache auf den Switches und Routern geprüft?

Moin, die Befehle zeigen Dir grundsätzlich alle Volumes an, egal wie und wo sie eingebunden sind. Weitere Informationen über die Volumes und deren Bereistellungspunkt kannst Du mit 'mountvol /L' oder auch 'Get-Volume | fl' abfragen. Normalerweise speichert der VSS Dienst die Daten (genauer gesagt: Die Blöcke, die sich während des Backupvorgangs ändern) nur solange auf dem Volume bis die Sicherung abgeschlossen ist. Danach wird es wieder bereinigt. Es bleiben keine Daten als Cache o.ä. auf dem Volume zurück. Vermutlich werden entsprechende Informationen in das NTFS Journal geschrieben. Genaueres weis ich aber nicht. Zur Funktionsweise von VSS: http://blogs.technet.com/b/josebda/archive/2007/10/10/the-basics-of-the-volume-shadow-copy-service-vss.aspx

Hallo, die MAC Adresse als Authentifizierungsmerkmal ist nur ein Plazebo und aufwändig in der Pflege sowie leicht zu umgehen. Wenn Du das Thema schon auf Layer 2 angehen möchtest, würde ich 802.1x mit Authetifizierung des Computerkontos (Computerkennwort oder Zertifikat) verwenden. 802.1x lässt sich auch mit NAP kombinieren; z.Bsp. kann der NPS nicht konforme Clients in ein Remediation VLAN schieben.

Hat der Komiker eventuell noch ein 'Verweigern' hinterlassen? Schau Dir mal ein paar beispielhafte Objekte mit 'Get-ACL ... | fl' an.

Moin, Du könntest mal mit 'vssadmin list shadowstorage' nachschauen, wieviel Platz in Gebrauch bzw. reserviert ist. Mit 'diskshadow' und dann 'list shadows all' kannst Du Dir alle Schatten anzeigen lassen.

Moin, ich war bisher noch nicht in der Situation die CAPolicy.inf nachträglich erstellen zu müssen. Es könnte klappen, oder auch nicht. Erstelle die Datei einfach und starte den Dienst certsvc einmal neu bevor Du die Erneuerung des SubCA Zertifikats beantragst. Auf der Root CA solltest Du vor dem einreichen der Erneuerung die definierte Gültigkeit von ausgestellten Zertifikaten prüfen und diese ggf. anpassen. Mit folgenden Befehlen kannst Du Dir die Werte anzeigen lassen: certutil -getreg CA\ValidityPeriodUnits certutil -getreg CA\ValidityPeriod Bei Bedarf kannst Du die Werte wie oben beschrieben mit 'certutil -setreg ...' anpassen. Danach den Dienst neu starten. Ein Backup der beiden Zertifizierungsstellen vor der Aktion kann auch nicht schaden http://blogs.technet.com/b/pki/archive/2010/04/20/disaster-recovery-procedures-for-the-active-directory-certificate-services-adcs.aspx

Moin, für NLB muss auf jeden Fall MAC Spoofing für die VM erlaubt sein. NLB erstellt eine virtuelle MAC Adresse für die Teilnehmer. Multicast NLB hat ein paar Tücken - der Switch und andere Netzwerkkomponenten müssen mitspielen. Unicast IP und Multicast MAC Adresse gefällt manchen nicht. Bei Hyper-V kommt ggf. noch erschwerend hinzu, dass beim Einsatz vom Host-Teaming der Hash-Modus am Switch explizit konfiguriert werden muss. Vielleicht helfen die Troubleshooting Guides weiter - sind zwar etwas älter, aber die Probleme mit NLB sind im Prinzip noch die gleichen: http://technet.microsoft.com/de-de/library/ff849728.aspx https://www.microsoft.com/en-us/download/details.aspx?id=17436

Aber auch sehr gut. Meiner Meinung nach ist es eins der besten Bücher von MS Press. Es gibt zwar hier und da kleine 'Schönheitsfehler', aber mit dem Hintergrundwissen, das man durch das Buch erhält, kann man die dann auch erkennen. Das das Buch Server 2008 behandelt ist kein großes Problem, es hat sich kaum etwas relevantes geändert. Eine PKI plant man für 10 oder mehr Jahre, da sind die paar Euros gut angelegt.

Hallo, grundsätzlich ist das kein Problem. Du kannst über Deine PKI Zertifikate ausstellen für wen Du möchtest. Der Client muss Deiner Root CA vertrauen. Dadurch sind alle Abkömmlinge automatisch auch vertrauenswürdig. Du musst das Root Zertifikat in den Speicher für 'Vertrauenwürdige Stammzertifirungsstellen' importieren. Machst Du es im Computerkontext, gilt es für alle Benutzer des Clients, machst Du es im Benutzerkontext, gilt es nur für den aktuellen Benutzer. In einer fremden Domäne kannst Du das Root Zertifikat auch per GPO verteilen lassen. Zusätzlich müssen die Sperrlisten am Client verfügbar sein. Bei dem TLG Beispiel bedeutet es, dass 'www.contoso.com/pki' im simulierten Internet - oder wo auch immer der Client sich gerade befindet - verfügbar sein muss. Falls Du tiefer in das Thema einsteigen möchtest, empfehle ich Dir 'Brian Komar - PKI And Certificate Security'

Bei MPIO werden mehrere Pfade zu einem Target aufgebaut. Bricht ein Pfad weg, läuft die Kommunikation über die verbleibenden Pfade weiter. Wie es genau zu konfigurieren ist, kann ich nicht sagen. Ich habe kein Qnap zur Hand Das Qnap bietet vermutlich keine Integrationstools oder ein DSM an, also musst Du MPIO von Hand einrichten. Im Absatz 'Script Example ...' sollte alles relevante stehen http://blogs.msdn.com/b/san/archive/2012/07/20/managing-mpio-with-windows-powershell-on-windows-server-2012.aspx Wenn MPIO für iSCSI konfiguriert und aktiviert ist, sollte jeder Target nur noch ein mal auftauchen.

Moin, wie die iSCSI Ziele aufgeteilt werden hängt grundsätzlich von Storage und Workload ab. Ich tendiere dazu mehrer 'kleine' Ziele anstelle eines großen zu verwenden. Die 'kleineren' können dabei mehrere TB groß sein. Zum Hintergrund: Eine einzelne LUN/Volume ist wieder ein Single Point of Failure - genau das soll in einer HA Umgebung vermieden werden. Ich habe mehr Steuerungsmöglichkeiten bei der Lastverteilung. Es gibt eine theoretische Größenbeschränkung durch das Format der Partionstabelle und des Dateisystems. Wenn ich mich richtig erinnere liegt das NTFS Limit bei 256TB.

AFAIK kann es nur eine Partitionsverschlüsselung geben. Die zu schützenden Daten müsste er dann zusätzlich in einem verschlüsselten Container auf der Partition ablegen. Es gibt durchaus Anwendungsfälle für geschachtelte Verschlüsselung - auch ohne Aluhut. Bsp: Ein Firmenlaptop mit zentraler Verwaltung der Verschlüsselung incl. Recovery. Eventuell habe ich darauf Daten, die nicht für den Recovery-Admin bestimmt sind. Off-Topic: Bitte nicht die Untoten beschwören :D