Archiv » Mai, 2014 «

16 | 05 | 2014

FSRM Remove-* Cmdlets in Skripten

Geschrieben von um 14:37 Uhr

Seit Server 2012 hat der File Server Resource Manager (FSRM) auch eine PowerShell-Automatisierungsschnittstelle bekommen. Diese ist mindestens genauso mächtig wie die GUI, die offizielle Liste gibt es im TechNet.

Fängt man an, FSRM mit diesen Cmdlets zu automatisieren, stößt man sehr schnell auf das folgende störende Phänomen: sobald ein Remove- Cmdlet aufgerufen wird, erscheint eine Frage (Shell) bzw. ein Pop-Up (ISE) mit der Bitte, die Löschoperation zu bestätigen:

In der Dokumentation wid auf den Parameter -Confirm verwiesen, dieser kann jedoch nicht verwendet werden, um die Bestätigung abzuschalten, da er keine Werte akzeptiert. Insofern ist dieser Parameter derzeit ziemlich nutzlos.

Abhilfe schafft der asynchrone Aufruf der Lösch-Cmdlets mit Hilfe des -AsJob Parameters:

Möchte man sicher gehen, dass die Löschung tatsächlich stattgefunden hat, kann man mit Get-Job den Abschlussstatus abfragen und schließlich mit dem entspechenden Get-FSRM*-Cmdlet das Nicht-Vorhandensein des soeben gelöschten Objektes überprüfen.

Happy Scripting!

 

 

 

Tags » , , , , , «

+

14 | 05 | 2014

Unterwegs mit Hyper-V: mobil ins Internet

Geschrieben von um 16:24 Uhr

Hat man einen Laptop, der sich aufgrund der technischen Daten als Virtualisierungshost eignet (so z.B. hier ein DELL Precision M4800 mit einem i7 und 32 GB RAM), und ist man dann auch noch als IT-Experte in verschiedenen Projekten unterwegs, so liegt es nahe, in Bezug auf die Arbeitsumgebung genauso zu verfahren als wenn man einen Server hätte: Auf dem Host (d.h. Hardware des Notebooks) möglichst keine Anwendungssoftware, sondern lediglich Gerätetreiber zu installieren, und seine Büroumgebung – neben den ganzen Projektmaschinen – innerhalb  einer VM zu betreiben. Möchte man gleichzeitig das Prinzip „practise what you preach“ respektieren, bleibt einem nicht viel übrig als auf Hyper-V zu setzen. Zum Glück bietet Hyper-V für Windows 8.1 (auf einen einzelnen Host bezogen) nahezu die gleichen Funktionen wie das im Server 2012 R2, daher kann man das Client-Betriebssystem nehmen und bzgl. Treiber auf der sicheren Seite sein.

In einem Punkt offenbart sich die Feature-Parität des Client- zum Server–Hyper-V allerdings sehr schnell als Fluch statt Segen: Nämlich im Umgang mit Geräten, die ein typischer Server nicht hat. Und während der WLAN-Adapter durchaus als Uplink an den vSwitch „angeschlossen“ werden kann (hier übrigens im Gegensatz zum Server-Hyper-V, da geht es nicht ohne Tricksen), ist es bei der UMTS-Karte schon schwieriger, denn diese präsentiert sich dem System als ein Dial-Up-Adapter und nicht als Netzwerkkarte:

UMTS-Karte in einem Laptop

Solche Adapter stehen als Uplink zum vSwitch nicht zur Verfügung:

Auswahl an NICs

Was also tun? Eine gern genommene Variante ist es freilich, auf den UMTS-Chip ganz zu verzichten und einen Taschen-Hotspot zu verwenden. Ich habe sogar so ein Ding und verwende es gelegentlich auch. Aus zwei Gründen wollte ich jedoch den Onboard-UMTS-Chip nutzen können:

  • die SIM-Karte im Laptop (für die mein Arbeitgeber bezahlt) ist „micro“, der mobile Hotspot möchte aber eine normale SIM, für die bezahle ich aber selbst 😉
  • Manchmal möchte man eben einfach nur ein Gerät dabei haben, zumal es ja entsprechend ausgerüstet ist.

Zur Hilfe kommt hier ein Windows-Feature aus dem „Home User-Bereich“, das man als Experte schon oft belächelt hat: Inernet Connection Sharing. Funktioniert in diesem Fall aber einwandfrei und macht nichts kaputt. Und das geht so:

1. Einen neuen Virtual Switch vom Typ „Internal“ anlegen. Auf diesen haben standardmäßig sowohl die VMs als auch der Host Zugriff:

2. Dann schalten wir auf dem UMTS-Adapter das ICS ein und definieren als das zu bedienende Heim-Netzwerk den neuen vSwitch:

Jetzt müssen nur noch die VMs, die den Zugang über UMTS brauchen, auf den WWAN-vSwitch umgestellt werden:

Et voila!

 

Tags » , , , , «

6

10 | 05 | 2014

Exchange DAG-Member und vMotion/Live Migration

Geschrieben von um 8:06 Uhr

Gestern Abend, in der Diskussionsrunde nach dem Treffen der Berliner Windows Server UG, fiel aus einem in der Szene sehr respektierten Mund der Satz (sinngemäß): „Man darf Exchange 2013-Server verschieben, aber nur mit LiveMigration, also nur auf Hyper-V“. Dies hörte sich nicht richtig an, also habe ich nachgelesen (Ausgangspunkt war dabei TechNet). Tatsächlich ist folgendes der Fall:

  • Man kann DAG-Member im Betrieb verschieben, allerdings nicht erst seit 2013, sondern bereits ab 2010SP1
  • Wichtig für den Support ist nicht der Hypervisor (solange er Teil der Virtualisierungsinitiative ist), sondern das Verfahren. Es darf nämlich kein Zustand der VM auf die Festplatte zwischengespeichert werden. Somit sind neben LiveMigration auch vMotion und XenMotion qualifiziert und vermutlich auch weitere Verfahren, nicht jedoch z.B. Quick Migration
  • Support für das Verfahren wird vom Hypervisor-Hersteller bereitgestellt. VMware pflegt dazu das Best Practices-Dokument https://www.vmware.com/files/pdf/Exchange_2013_on_VMware_Best_Practices_Guide.pdf . Sicherlich gibt es auch ein ähnliches Dokument von Citrix, wenn ich es finde, poste ich den Link hier. Wichtig dabei ist, dass die Elastizität des Clusters etwas erhöht wird, um Spontanfailover während einer vMotion/LiveMigration zu vermeiden.

Bleibt also noch die meistgehasste Frage, nämlich nach der Lizenzierung eines solchen Verfahrens. Hier gilt (s. offiziellen Guide) das Übliche:

  • VL mit SA = Mobilität innerhalb der Farm
  • VL ohne SA = 90-Tage-Bindung an die Hardware
  • Retail oder OEM = keine Mobilität

Die Sinnhaftigkeit der Virtualisierung von DAG-Membern ist freilich nicht Gegenstand der Diskussion 😉

Tags » «

+