Dunkelmann

Freut mich, dass es geklappt hat :)

So schlimm ist es auch nicht. Cluster auflösen und später wieder neu erstellen ist recht zügig erledig. Mit Storage Live Migration kannst Du eventuell sogar die VMs während der Aktion online lassen. Sie sind zwischenzeitlich nur nicht mehr hochverfügbar

Wenn Du am Broker keine Default Collection für die Umleitung eingestellt hast, versucht sich der RDP Client direkt mit dem Broker zu verbinden - einfache Domänen-Benutzer fahren dabei natürlich gegen die Wand Den Gallileo Guide kenn ich nicht, aber er scheint einige Details zu verschweigen :cool: Du kannst es auf drei Arten angehen: Den RD-Web Service installieren und das Portal nutzen oder das WorkRessources-Feed abonieren - so stellt sich MS das Setup vor und so ist es m.M.n. auch am einfachsten für den bequemen Admin :p Auf den Broker eine Default Collection setzen - alle Anfragen an den Broker werden dann dahin umgeleitet. Als Admin musst Du dich dann mit 'mstsc /admin' Switch am Broker anmelden. [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\ClusterSettings] "DefaultTsvUrl"="tsv://MS Terminal Services Plugin.1.OfficeCollection" Beispiel aus meiner Demo-Umgebung. 'OfficeCollection' ist der Name der Sammlung Eine RDP Datei mit den Collection Parameter 'tsv://MS Terminal Services Plugin.1.OfficeCollection' manuell erstellen und verteilen - das macht aber gar keinen Spass :nene:

Hallo, ein Chef der 'um die Ecke kommt' und 'mal eben schnell' sind ungünstige Vorraussetzungen für gute Planung ;) Da wirst Du wohl den Cluster 'kaputtmachen' müssen, wenn kein äquivalenter Ersatz zur Verfügung steht. Die HA VMs aus dem Cluster entfernen und zurück auf die Hosts schieben. Zur Not auf eine externe USB Platte - ist ja nur eine Tesumgebung Sind alle ehemaligen Cluster VMs auf die Hosts verteilt, kannst Du den Cluster sauber auflösen. Kommt das Storage zurück, kannst Du einen neuen Cluster bauen und die VMs wieder hochverfügbar machen

Bei mir sind alle Rollen (Broker, Web, Hosts) getrennt - allerdings noch unter 2012. Die 2012R2 Testumgebung hat mein Kollege am laufen. Da hat er keine Probleme mit der Benutzerzuweisung festgestellt. Grundsätzlich würde ich in umfangreicheren Umgebungen, die Infrastruktur immer von den Session Hosts trennen.

Es wird Alles in der Remotedesktopbereitstellung (meistens auf dem Broker) konfiguriert. Da fügst Du der Sammlung die berechtigten Benutzer hinzu. Auf den einzelnen RDS Hosts musst Du im Prinzip gar keine Infrastrukturparameter mehr konfigurieren. Der Broker kümmert sich um die Verteilung der Einstellungen.

Die Frage ist: vor wem möchtest Du was verschleiern? Danach richtet sich der 'Schutzbedarf'. Auch VPN Anbieter knicken ganz schnell ein wenn bestimmte Stellen um Auskunft bitten.

Moin, in den Eigenschaften der Remotedesktopbereitstellung kannst Du die Zertifikate für die verschiedenen Dienste hinterlegen. Hier ist es ganz gut beschrieben: http://ryanmangansitblog.wordpress.com/2013/03/10/configuring-rds-2012-certificates-and-sso/ Zusätzlich musst Du den Fingerprint per GPO an die Clients verteilen. Adm.Vorlagen - Remotedesktop - Remotedesktop-Client - SHA1 Finger ...

Hallo, falls Du noch irgendwo einen alten IPv4 Router herumliegen hast, könntest Du zum Testen diesen einmal anstelle des jetzigen einsetzen. Egal ob die Internetverbindung damit klappt oder nicht. Es wäre eine Möglichkeit das Problem einzugrenzen und den Server vielleicht wieder in Spur zu bringen. Das Exchange nicht rund läuft dürfte mit der 'faulen' IPv6 Konfiguration zusammenhängen - Gateway und 2 verbindungslokale Adressen.

Moin, wenn Du einen Lehrgang mit Trainer buchst, kann schnell ein 4 bis 5 stelliger Betrag zusammenkommen. Im Selbststudium ist es deutlich preiswerter. Eine Prüfung direkt über Prometric gebucht kostet € 150,- .Wenn Du über ein Testcenter buchst, ggf. etwas mehr. Manchmal bieten MS und Prometric auch Prüfungsbundels an (z.B. 3 zum Preis 2). Für ein Buch würde ich rund € 50,- rechnen. Für die meisten Grundlagenprüfungen reicht ein einfaches virtualisierungsfähiges System. Viele Inhalte lassen sich mit VMs nachstellen. Selbst einen kleinen Hyper-V Cluster kann man z.B. mit VMWare virtuell nachbauen. Eventuell kannst Du Deinen Arbeitgeber auch überreden, die Hardware für einen Trainingsumgebung zu beschaffen. Ein paar gebrauchte Server, Switches und ggf. ein kleines Storage können sich bereits nach dem ersten eingesparten Lehrgang rechnen.

Moin, neben XP Fans 'Gateway' sehe ich 2x IPv6 verbindungslokale Adresse:

Natürlich ist so etwas möglich, es müssen nur alle beteiligten Komponenten korrekt konfiguriert sein :cool: Es könnte ein DNS Problem sein, es könnte ein Routing Problem sein, es könnte ein Problem mit einer Firewall sein ... es könnten auch die Mondphasen sein. Etwas mehr Informationen zur Umgebung könnten auch hilfreich sein. Mit 'ich will von Netz A über Netz B nach Netz C' lässt sich leider nicht viel anfangen.

Moin, es gilt als Best-Practice, die Root CA und ggf. die Policy CA offline zu betreiben. Lediglich die Issuing CAs - die CAs, die die Zertifikate an Entitäten ausgeben - sollten online betrieben werden. Der Hintergrund ist ganz simpel: Eine Online CA kann wie jedes andere System, das permanent Online ist, einfacher kompromittiert werden, als ein System, dass nur ein bis zwei Mal im Jahr von 3 Leuten für 60 Minuten eingeschaltet wird. Je nach Umfang der PKI kann eine kompromittierte Root oder Policy CA einen erheblichen wirtschaftlichen Schaden verursachen und/oder ein erhebliches Sicherheitsrisiko für das Unternehmen darstellen. Buchtip: Brian Komar - PKI And Certificate Security Und das hier: http://blogs.msdn.com/b/nickmac/archive/2011/10/19/deploying-and-managing-pki-inside-microsoft.aspx

Moin, mir fällt dazu nur das DNS Debug Log ein. http://technet.microsoft.com/en-us/library/cc776361%28v=WS.10%29.aspx Das Debug am Besten auf eine separate VHD oder in einen Ordner mit Quota. Eventuell kannst Du dieses Skript auf Deine Bedürfnisse anpassen: http://gallery.technet.microsoft.com/scriptcenter/Filter-DNS-Debug-Log-75ccc153#content

Moin, wenn es nicht unbedigt VMWare als Hypervisor sein muss, könntest Du den kostenlosen Hyper-V Server von Microsoft nehmen. Der beinhaltet das gewöhnliche Windows Server Backup. Wenn ihr bei Stifter-Helfen bezugsberechtigt seit, könntest Du für wenig Euros einen Windows Server Standard bestellen. Damit könntest Du zur Administration die GUI nutzen. Vielleciht auch System Center Standard bestellen und den Microsoft DPM als Backuplösung nutzen. Server Standard und System Center Standard gibt es als Förderberechtigter für rund € 100,- (incl. 2 Jahre SA). Eine bessere Infrastruktur bekommst Du nirgentwo sonst für den Betrag ;) Wenn Du schon dabei bist, die IT etwas aufzuräumen, würde ich empfehlen, das Backupsystem auf eigener Hardware zu betreiben. Es ist selten eine gute Idee, Backup- und Produktivsystem auf ein und der selben Physik zu betreiben. Wenn die Hardware kaputt geht, ist auch das Backup futsch.

Moin, du benötigst im Prinzip ein Hub-Spoke Setup für das VPN. Der Einwahlpunkt ist der Hub, Dein Client und die anderen Standorte die Spokes. Wie es in Deinem Fall zu konfigurieren ist, hängt von der eingesetzten VPN Hard- und/oder Software ab. Auf die schnelle mal ein Beispiel für Cisco ASA: http://security-planet.de/2013/11/29/cisco-asa-vpns-spoke-to-spoke-traffic-via-hub/

Moin, habt ihr vorm Erstellen des Clusters alle Test durchgeführt und waren diese auch erfolgreich? Welche Fehler oder Warnungen gibt es aktuell bei der Clustervalidierung? Haben alle Nodes Zugriff auf das Volume, ist shared access aktiviert? Gibt es AntiMalware auf den Nodes? Wenn ja: rückstandsfrei deinstallieren. Ist die Backuplösung Cluster-tauglich? Seit 2008 hat sich beim Quorum nicht so viel geändert: http://technet.microsoft.com/en-us/library/cc770620%28v=WS.10%29.aspx http://www.aidanfinn.com/?p=10311 Eventuell hilft es, die Quorum Konfiguration noch mal durchzugehen, eventuell auch mit einem 'frischen' Volume ein neues Quorum erstellen. PS: Beim Quorum verzichte ich grundsätzlich auf Laufwerkbuchstaben oder Pfade - so kann es wenigstens nicht ausversehen im Explorer 'missbraucht' werden.

Bei RDS wird mittlerweile auch eine BYOD-Architektur von Microsoft präferiert - egal ob man es mag oder nicht. Die verfügbaren Ressourcen werden als Feed vom WebAccess Server bereitgestellt und können von den Benutzern aboniert werden. Sie erscheinen dann unter Windows 8 als Kachel oder bei Windows 7 unter 'RemoteApp und Desktopverbindungen' im Startmenü. Im Dialog des Remotedesktop Clients sind die sammlungsspezifischen Optionen nicht verfügbar. Sie stehen aber in den rdp Dateien. Möchte man einen eher klassischen Ansatz fahren, kann man - dem Broker eine default Farm mitgeben, mit der sich die Clients verbinden sollen sofern nicht anderes angegeben wird. - die RDP Dateien extrahieren und z.b. per GPP an die Anwender verteilen und sich so den Weg über das Abo sparen

Das Storage ist derzeit per iSCSI über 2 dedizierte 10Gbit NICs angebunden. Bis zum nächsten Hardwarezyklus in ca. 2 Jahren soll das Storage autark bleiben. Was danach kommt bestimmt - wie fast immer - der Preis. Das mit den QoS per SCVMM hatte ich mir auch überlegt. Allerdings haben wir im Backend nicht so viele QoS Änderungen ... und wenn, dann wäre schon bei der Planung etwas ganz schön schief gelaufen ;) Beim VMM ist es etwas lästig mit dem sukzessiven Aufbau des Datacenter-Teams, das lässt sich nicht so schön einfach skripten. In meiner Testumgebung hat sich der ganze Deploymentprozess deutlich beschleunigt, seitdem ich mit Teaminterfaces arbeite und die Hosts erst an den VMM bringe nachdem die Netze stehen. Momentan sehe ich hier eher den Vorteil bei der schnelleren und einfacheren Bereitstellung, aber ich lasse mich gerne vom Gegenteil überzeugen. :cool:

Unter 2008R2 war ein Setup mit NLB und ggf. Dedicated Redirector üblich. Seit 2012 ist ein Setup mit Broker und Sitzungssammlungen der bevorzugte Weg. Besonders für große Umgebungen mit separatem SQL Backend und Broker im Cluster ist das Model dem 2008R2 Ansatz überlegen. Falls Du Zweifel hast, baue einfach mal eine 2008R2 Umgebung und eine 2012R2 Umgebung nach und verfolge die Kommunikation mit dem Netzwerkmonitor oder Wireshark.

Moin, warum nutzt Du noch NLB unter Server 2012R2? Nebenbei hat Multicast NLB auch so seine Tücken (Unicast IP und Multicast MAC Adresse gefällt nicht jedem Switch) Seit Server 2012 laufen die Verbindungen zentral auf dem Broker auf und werden von dort auf die Hosts in der Sitzungssammlung verteilt. Es soll sich i.d.R. kein Client mehr direkt mit den Hosts verbinden. Schau Dir mal den TLG an: http://blogs.technet.com/b/tlgs/archive/2012/08/10/spotlight-on-the-new-remote-desktop-services-in-windows-server-2012-tlg-stack.aspx

Moin, für mein neues Hyper-V Setup möchte ich separate Teams für VM Traffic (Tenant) und Management Traffic (Datacenter) einsetzen. Das Setup soll der angehängten Grafik entsprechen. (Quelle: http://blogs.technet.com/b/keithmayer/archive/2013/04/04/build-a-private-cloud-foundation-networking.aspx ) Für das Tenant-Team ist soweit alles klar: Ein Team bilden und einen vSwitch erstellen. Beim DataCenter-Team bin ich noch unentschlossen, welchen Weg ich bevorzugen soll: Mit virtual Switch Ein Team, virtual Switch und virtuelle NICs je VLAN für das Host OS Mit Team Interfaces Ein Team und ein Team Interface je VLAN Beide Setups habe ich schon in meiner Testumgebung nachgestellt, sie funktionieren. Bei Variante 1 könnte ich die Hostkonfiguration incl. QoS Policies per SCVMM vornehmen; Variante 2 kann ich per PowerShell automatisieren. Derzeit würde ich Variante 2 mit Teaminterfaces bevorzugen, da der Overhead des vSwitches wegfällt und die Konfiguration per Powershell während der Hostinstallation unkompliziert und flott läuft. Gibt es bei den Szenarien noch weitere Aspekte, die das ein oder andere Setup bevorzugen oder die mir bei meinen Tests nicht aufgefallen sind? :)

Moin, versuch mal das Root Zertifikat im Base64 Format an das Android zu übertragen. Manche Systeme haben mit DER Probleme. Wenn Du Benutzerzertifikate nutzt und es auf einem Gerät funktioniert, sollte mit der Vorlage und dem Zertifikat alles ok sein. Eventuell hilft es, auf dem NPS den MS Netzwerkmonitor zu installieren und zu prüfen in welcher EAP-Phase es hängt oder ob es andere Auffälligkeiten gibt. Das NPS Log ist zum debug nicht wirklich zu gebrauchen.

Moin, ein Default Profile auf einem Server wird wie beim Client über sysprep und CopyProfile-Switch angelegt: http://technet.microsoft.com/en-us/library/hh825135.aspx Beim Mandatory Profile (verbindlich) sieht es genauso aus: http://technet.microsoft.com/de-de/library/gg241183%28v=WS.10%29.aspx http://msdn.microsoft.com/en-us/library/windows/desktop/bb776892%28v=vs.85%29.aspx

Der Schritt von Eval nach Full ist afaik auch ein Editionsupgrade. Wenn die Version nicht als Target gelistet ist, habe ich auch leider keine Idee mehr :confused: . (Außer Neuinstallation, aber das willst Du vermutlich vermeiden)