Dunkelmann

Für 20T€ eine Lösung, die maximal 30 Minuten Downtime bietet ... da kann die GF noch soviel beschließen, das wird nichts.

Moin, Du benötigst am TMG nur eine Regel für 'Intern' an 'Proxy' mit dem entsprechneden Port. Zusätzlich natürlich noch eine Regel, die direkten Internetzugriff für die internen Clients unterbindet damit niemand am Proxy vorbei ins Internet geht. Den Clients muss dann der externe Proxy per WPAD o.ä. mitgeteilt werden. Das Ganze kann möglicherweise etwas aufwändiger werden, da der externe Proxy vermutlich nicht transparent läuft. Manche Programme/Dienste mögen so etwas nicht.

Moin, mir ist der Anbieter fast egal. Hauptsache das Produkt erfüllt möglichst viele oder gar alle Anforderungen und der Preis passt. Erstell Dir ein Lastenheft - sicherlich gibt es noch mehr Anforderungen als nur die Exchange 2013 Unterstützung - und klappere die einschlägen Hersteller ab. Eine Teststellung kann auch nicht schaden wenn es darum geht, die Alltagstauglichkeit zu prüfen.

Moin, gibt es ein Projektbudget? Unterstützt die unbekannte Anwendung HA Mechanismen? Wenn ja welche. Was bedeutet 'nahezu rund um die Uhr' konkret? Technische Lösungen lassen sich viele finden. Ohne finanziellen Rahmen und Kenntnisse der Anwendung sowie der restlichen Infrastruktur und ggf. weiterer Anforderungen ist es nur Kaffeesatzlesen. Vielleicht solltet ihr euch für das Projekt externes Know How einkaufen. Das ist meistens zielführender als eine Diskussion in einem Forum.

Wurden gerade die Produktmanager durchgetauscht oder ist heute der 1. April?

Off-Topic: Hast Du Dir über das Setup keine Gedanken gemacht, bevor Du die Server angeschafft hast? :rolleyes:

Moin, bei Hyper-V Replikation geht es um Site Failover. Das bedeutet es wird entweder komplett im Haupt-RZ oder komplett im Failover-RZ gearbeitet. Für einen Mischbetrieb wie bei Dir angedacht ist Hyper-V Replikation nicht geeignet. Nebenbei gibt es bei SQL einiges zu beachten und Exchange wird in Kombination mit Hyper-V Replikation noch nicht unterstützt. Ein partielles Failover sowie das anschließende Zusammenführen der dann möglicherweise asynchronen Datenbestände müsste rein auf Basis der Anwendung erfolgen. Für Dein Vorhaben würde ich eher redundante Datenverbindungen über unabhängige Carrier (DSL, Kabel, UMTS, LTE usw.) und eine HA Lösung (Hyper-V Cluster und ggf. eine hochverfügbare Applikation) am Hauptstandort empfehlen.

Im Prinzip gibt es diese oder vergleichbare Performance-Werte auch bei Windows. Hier findest Du ein paar nützliche Downloads zum Thema Performance für 2008R2 und 2012: http://msdn.microsoft.com/en-us/library/windows/hardware/jj248719.aspx http://msdn.microsoft.com/en-us/library/windows/hardware/gg463392.aspx

Das sieht nach einer massiven Überbuchung der physischen CPU Kerne aus. Am Besten in den betroffenen VMs. Die CPU bzw. Disk Queue gibt an, wieviele Jobs auf die Ressource warten müssen. Grundsätzlich sind alle Werte größer 1 ein Indikator für einen potentiellen Engpass. Das ist genau das Thema bei einem shared storage. Wiele IOPS kann das Backend maximal bereitstellen (Am Besten hat man eine Messung vor der Inbetriebnahme durchgeführt ansonsten muss man den theoretischen Wert schätzen) und wieviel IOPS werden aktuell genutzt. Ich kenne DataCore zwar nicht, aber jedes vernünftige Backend sollte in der Lage sein, solche Daten zu liefern. Eventuell liegt die Ursache gar nicht bei den RDS Hosts sondern bei einem anderen System, das gerade Amok läuft (SQL, Mail oder auch ein suboptimal konfigurierter AntiVirus). Bei den RDS Hosts tritt lediglich das Symptom der 'Trägheit' auf.

Moin, ich gehe mal von einem nicht verwalteten EFS ohne PKI und definierte Prozesse etc. aus. Eine weitere Annahme ist, das das EFS Recovery Zertifikat niemals gesichert und in einen Tresor verbracht wurde. Das kann ganz übel enden. Du benötigst den privaten Schlüssel eines EFS Data Recovery Agent. In jeder Domäne wird automatisch beim hochstufen des ersten DCs eines erzeugt. Das Zertifikat incl. privatem Schlüssel liegt i.d.R. auf dem ersten hochgestuften DC der Domäne im Zertifikatsspeicher vom 'Administrator'. Gibt es diesen DC noch, ist alles ganz einfach: Als Administrator anmelden MMC Zertifikate öffnen Das EFS Recovery Zertifikat incl. privatem Schlüssel exportieren Auf einer Recovery Station (am Besten ein Standard Domänen Client) das Zertifikat importieren Die verschlüsselten Daten auf die Recovery Station übertragen Daten entschlüsseln Unverschlüsselte Daten prüfen und in der Produktivumgebung bereitstellen Eine Kopie des EFS Recovery Zertifikats an einem sicheren Ort lagern! (Recovery Zertifikat und Daten von der Recovery Station löschen) Fertig! Gibt es den ersten DC nicht mehr, hast Du hoffentlich ein Backup des Servers und die Möglichkeit das Backup in einer vollständig isolierten Umgebung zurückzuspielen und Dir auf diesem Weg Zugriff auf das EFS Recovery Zertifikat zu verschaffen. Ohne Zugriff auf das EFS Recovery Zertifikat hast Du sehr wahrscheinlich keine Chance, in absehbarer Zeit an die Daten zu kommen.

Moin, die ersten Verdächtigen neben der RAM, CPU Auslastung und HDD Antwortzeit wären bei mir IOPS Disk Queue CPU Queue

Die nicht benötigten NICs lassen sich auch deaktivieren ;)

Als Ergänzung zu Nils: Bei meiner letzten Prüfung war bei den Fragen mit Mehrfachauswahl keine Anzahl mehr vorgegeben. Es konnte jede Anzahl von 0 bis n die richtige Lösung sein. Viel Erfolg :thumb1:

Moin, vielleicht hilft Dir der IPD (Infrastructure Planning and Design) für ADDS einige Fragen zu klären bzw. erstmal die Fragen zu finden, die geklärt werden sollten. http://technet.microsoft.com/library/cc196387.aspx Je nach Qualität des Externen, kann dann in einer Diskussion der für Euch beste Ansatz erarbeitet werden.

Sofern der Client der CA vom Essentials vertraut, kannst Du die Zertifikate für fast alle Anwendungsfälle nutzen.

Moin, das 'minimale Kennwortalter' steht per default auf 1 Tag ;)

Moin, Du kannst Dir auch über die CA vom Essentials ein Zertifikat erstellen. Das Root Zertifikat der Essentials CA muss dann nur noch in die 'vertrauenswürdigen Stammzertifizierungsstellen' des Clients importiert werden.

Aktionismus ist kein guter Ratgeber, wenn es um Sicherheit geht. Es gibt defacto keine Möglichkeit, den Zugriff auf den PSK zu unterbinden. PSK ist unsicher 'by design'. Du kannst lediglich den Zugriff auf Control Panels, RegEdit, usw. sperren. Den Durchschnittsanwender wirst Du damit vielleicht beeindrucken. Jemanden mit einer Motivation, den PSK in Erfahrung zubringen jedoch nicht.

Moin, hast Du schonmal einen Blick in das Log vom DPM Agent auf dem SQL Server geworfen? Eventuell ist Deine Synchronisierungsfrequenz zu hoch - bei einem 15 Minuten Intervall und großen DBs muss die Infratruktur auch in der Lage sein, die Last zu bewältigen. Anti Virus etc. hast Du hoffentlich für die Benutzung auf einem SQL angepasst, bzw. gar nicht installiert.

Moin, Vernünftige APs kaufen.

Moin, eventuell helfen die Account Lockout Tools weiter: http://www.microsoft.com/en-us/download/details.aspx?id=18465

Moin, um den PC in WSE Domäne aufzunehmen, musst Du auf dem Client im Browser http://[MeinServer]/connect aufrufen und den Assistenten ausführen. ([MeinServer] ist natürlich der Name Deines Servers)

Hast Du schonmal daran gedacht, den VMM auf einem eigenen Server zu betreiben? Ich hatte bei mir auch verschiedene Probleme als ich den VMM auf dem Cluster, den der VMM verwalten soll, betreiben wollte. Nach einigen Versuchen es zum Laufen zubringen habe ich aufgegeben und einen unserer physischen DCs plattgemacht und den VMM auf dem Blech installiert.

Hallo, das das CSV gar nicht erreichbar ist, finde ich sehr ungewöhnlich. Du könntest mal die Clusterprüfung aus dem VMM heraus anstoßen, vielleicht bringt das neue Erkenntnisse. Im VMM kannst Du Standardpfade für die Platzierung der VMs vorgeben. Wenn man ohne Storageintegration arbeitet, geht das meines Wissens nach nur in den Eigenschaften der einzelnen Hosts. Dort können die Volumes definiert werden, die für die Plazierung verfügbar sind, sowie die Pfadvorgaben. http://technet.microsoft.com/en-us/library/gg610556.aspx http://technet.microsoft.com/en-us/library/gg610696.aspx Wenn Du keine 'Clouds' definiert hast, musst Du jedesmal diese Angaben machen. Hast Du 'Clouds' definiert, bedient sich der VMM aus dem Ressourcenpool der Cloud ohne dass weitere Interaktionen notwendig werden. Selbst wenn Du keine große Umgebung hast, solltest Du wenigstens ein oder zwei Clouds anlegen. Damit wird vieles vereinfacht. Wenn Dein Storage einen Provider für den VMM bereitstellt, solltest Du es machen. Zwingend erforderlich ist es aber nicht.

Hallo, ich bin bisher noch nicht auf die Idee gekommen, auf dem CSV manuell weitere Unterordner anzulegen. Klappt es, wenn Du die VM direkt im Stammverzeichnis des CSV erstellst?