Am letzten Wochenende habe ich Windows 10 TR Preview (Windows X) in verschiedenen SBS Umgebungen ausprobiert und dabei folgende Erkenntnis gewonnen:

1. Windows X / Windows Server 2011 SBS Essentials = Connector geht, aber kein Backup (manueller Domain Join)
2. Windows X / Windows Server 2012 (R2) Essentials = Connector geht nicht (aber manueller Domain Join)

Unter Windows Server 2011 SBS Essentials kann also Windows X problemlos in die Domain integriert werden und auch über das Portal ist ein Zugriff möglich. Lediglich das Backup funktioniert nicht.

Für alle höheren Windows Server Essentials Versionen hat der Connector nicht funktioniert und hier muss wohl Microsoft ein Update liefern.

Hier noch ein Screenshot des Windows X PCs im SBS 2011 Dashboard:

Und überhaupt – Windows X finde ich cool das wird was!

Enjoy it, b!

Schon seit langer Zeit bietet Microsoft die Möglichkeit einen Windows Server als Router zu betreiben. Was in “realen” Umgebungen nicht oft genutzt wird, kann in virtuellen Umgebungen sehr sinnvoll sein. Somit habe ich auf jedem von meinen Hyper-V Hosts noch eine VM laufen welche mir verschiedene Subnetze routet – um auch komplexe Netzwerkumgebungen nachstellen zu können. Beim hinzufügen eines weiteren Netzwerkadapters, welcher ein neues IP-Subnetz routen sollte bin ich wieder über den Bug im RRAS gestoßen das ein Adapter nicht erkannt und verwendet wird.

Hier der neue Adapter:

und hier die RRAS welches mir trotz Neustart über den Service Manager noch durch einen Neustart der VM selbst den Adapter ins Routing integrieren wollte:

Die Lösung war letztendlich RRAS zu deinstallieren und wieder neu zu installieren – da es sich bei mir lediglich um LAN-Routing handelt, also keine aufwendigen Konfigurationen notwendig sind, ist das kein Problem.

Falls jemand hier eine bessere Lösung hat – bitte melden

Enjoy it, b!

Mit der Live-Migration zwischen zwei normalen Hyper-V Hosts hat Microsoft eine feine und für kleine Firmen extrem hilfreiche Funktion seinem Hypervisor spendiert. Das Verschieben im laufenden Betrieb funktioniert problemlos für alle VMs (egal ob Windows oder Linux). Allerdings ist mir aufgefallen, dass wenn eine migrierte Linux VM verschoben wird diese nach einem Neustart die IP-Adresse verliert. Der Grund dafür ist, dass die VM selbst eine neue MAC-Adresse zugewiesen bekommt was Linux (Opensuse und SLES) dazu veranlasst einen neuen Netzwerk-Adapter im System zu konfigurieren. Dieses Verhalten lässt sich mit einer statischen Zuweisung der MAC-Adresse für die Linux-VM in den Griff bekommen, dazu ist einfach folgende Einstellung zu machen:

Die Default Einstellung hier ist Dynamic.

Enjoy it, b!

Auf einem Windows Server 2012 R2 (Essentials) bekam ich gestern die folgende Meldung:

Dazu war noch folgende Information in den Backup Details vorhanden:

There is not enough disk space to create the volume shadow copy on the storage location. Make sure that, for all volumes to be backup up, the minimum required disk space for shadow copy creation is available. This applies to both the backup storage destination and volumes included in the backup.
Minimum requirement: For volumes less than 500 megabytes, the minimum is 50 megabytes of free space. For volumes more than 500 megabytes, the minimum is 320 megabytes of free space.
Recommended: At least 1 gigabyte of free disk space on each volume if volume size is more than 1 gigabyte.
Detailed error: Insufficient storage available to create either the shadow copy storage file or other shadow copy data.

Ein Blick in das Diskmanagement des Server zeigte aber, dass keines der Volumes zu wenig freien Platz hatte:

Als nächsten Schritt schaute ich mir das Application Eventlog des Servers an und fand dort folgende Fehlermeldung:

Besonders der Rückgabewert 0x80780119 hat schon einige andere Admins zur Verzweiflung gebracht und deutet eigentlich auf ein Problem resultierend aus zu wenig Platz für ShadowCopies hin, was aber bei diesem Server aus zu schließen war.

Also dachte ich mir, dass eine vorrübergehende Deaktivierung des Windows Recovery Environments (WinRE) das Ausführen des Backups und das anschließende Aktivieren von WinRE einen Versuch wert wären (reagentc /disable bzw reagentc /enable) und in der Tat, mit deaktiviertem WinRE konnte der Server ohne Probleme gesichert werden! Hier nochmals die Schritte im Detail:

1. reagentc /disable
2. Sicherung
3. reagentc /enable

Interessanter Weise laufen nach dieser Maßnahme alle Backups problemlos durch – auch wenn WinRE aktiviert ist. Sprich der oben beschriebene Workaround hat das Problem anscheinend (die letzten 4 Backups waren OK) generell behoben! Ich beobachte die Sache noch weiter und werde auch mal einen Restore machen…

Enjoy it, b!

Während der Neuinstallation eines auf dem Supermicro X10SLM-F Serverboard basierenden Serversystems bin ich über folgende beiden Devices im Geräte-Manager gestoßen:

Beide lassen sich problemlos korrekt installieren, wenn von Intel das aktuelle Intel Chipset Device Software (INF Update Utility) verwendet wird:

https://downloadcenter.intel.com/Detail_Desc.aspx?DwnldID=20775

Das Utility selbst (SetupChipset.exe), einfach als Administrator mit erweiterten Rechten ausführen, die unbekannten Geräte werden dabei selbstständig erkannt und installiert. Lediglich ein Reboot des Servers ist danach notwendig.

Enjoy it, b!

Mit Hyper-V 2012 R2 bietet Microsoft die Generation 2 VMs an. Die Vorteile und eine generelle Übersicht kann man sich hier anschauen: http://technet.microsoft.com/en-us/library/dn282285.aspx

Für mich wiegen die Vorteile wie eine deutlich bessere Performance so stark, dass ich fast nur noch Generation 2 VMs verwende. Dabei ist mir aber eine nicht besonders schöne Eigenschaft des Wizards zum Erstellen der VM aufgefallen:

Der Wizard bietet einem 512MB als Startkonfiguration für den Hauptspeicher an.

Verwendet man diese (egal ob noch Dynamic Memory konfiguriert wird oder nicht) und versucht darin einen Windows Server 2012 R2 zu installieren, so erhält man die interessantesten Meldungen:

• Der Produktkey ist ungültig oder kann nicht validiert werden
• Die Disk ist nicht zur Installation von Windows Server geeignet
• …

Der Grund für dieses Verhalten während der Installation ist folgender. Läuft das Setup von Windows Server, dann ist hier noch kein Dynamic Memory aktiv – sprich, die VM kann nicht mehr Speicher allokieren, als die 512MB welche als Startkonfiguration zugewiesen sind. Setup spuckt aus diesem Grund die interessantesten Fehlermeldungen aus. Lösen lässt sich das Problem einfach dadurch, dass 768MB hier eingetragen werden, und schon kann man das aktuelle Release des Windows Servers problemlos installieren.

Für den späteren Betrieb lässt sich damit durchaus mit 512MB beginnen:

Mit dieser Konfiguration laufen aktuell viele meiner VMs.

Enjoy it, b!

Nix neues, aber immer wieder hilfreich wenn man sie auf die Schnelle braucht:

http://msdn.microsoft.com/en-us/library/aa383500(v=vs.85).aspx

Enjoy it, b!

… hat sich dieser Kunde auch gedacht und den Server mal laufen lassen:

960 Tage sind keine schlechte Zeit – und zur Beruhigung, die Maschine wurde isoliert und ohne Internetzugriff als iSCSI Target betrieben.

Enjoy it, b!

Nachdem nun Windows Server 2012 R2 eine zeit lang auf dem Markt ist und gegenüber der 2012 Version einige interessante Verbesserungen (Export von laufenden VMs) mit sich bringt, stand ich vor der Frage – Upgrade oder Neuinstallation. Da ich auf meinen Server so gut wie keine 3rd-Party Tools installiert habe (außer dem Management der RAID-Controller und ein paar kleineren Utilities). Habe ich mich entschlossen mal einen Upgrade zu probieren und damit es nicht zu einfach wird, gleich mit der GUI-losen Version dem Microsoft Hyper-V Server 2012.

Das Ziel ist es also einen Microsoft Hyper-V Server 2012 auf das aktuelle Release Hyper-V 2012 R2 zu aktualisieren. Ich kann hier gleich vorweg nehmen, es geht – allerdings mit ein paar Dingen auf die man achten sollte.

Hier nochmals die Ausgangslage:

1. Installierter Microsoft Hyper-V Server 2012 mit laufenden VMs
2. Netzwerk-Adapter Team
3. Upgrade erfolgt über eine RDP Session
4. Der Server besitzt eine eingebaute Remote-Management Karte (IPMI) welche über eine extra IP-Adresse erreichbar ist

Als erstes habe ich das ISO Image bei Microsoft herunter geladen (nach c:\temp) und mit PowerShell gemounted:

Mount-DiskImage -ImagePath "C:\Temp\en_microsoft_hyper-v_server_2012_r2_x64_dvd_2708236.iso"

Danach auf das neue Laufwerk gewechselt und den Update-Vorgang gestartet (über eine RDP Session, wohl gemerkt). Das Upgrade verlief ohne Probleme und der Server startete neu, allerdings war er auch nach einigem warten über seine alte IP-Adresse nicht erreichbar.

Ein Blick in den DHCP zeigte, dass beide Interfaces des Servers jeweils eine Adresse vom DHCP-Server bezogen hatten. In Folge des Upgrades war das Team gelöst worden, oder verloren gegangen – und damit auch die Verbindung zum virtuellen Switch.

Eine RDP Sitzung auf eine der im DHCP sichtbaren Adressen funktionierte auf Anhieb und nach Einrichtung des Teams und der Konfiguration des Hyper-V Switches konnte der Upgrade erfolgreich abgeschlossen werden.

Damit solch ein Upgrade problemlos funktioniert ist es notwendig, dass sich der DHCP Server außerhalb des Hyper-V Hosts befindet welcher aktualisiert werden soll. Alternativ ist eine IPMI Netzwerkkarte hilfreich welche einen Konsolenzugang ermöglicht ohne irgendwelche Adressen aus dem DHCP zu fischen.

Abschließend noch zwei Tips:

• Für die PowerShell Anhänger unter uns: Ich kopiere immer die für die Konfiguration des Servers notwendigen Befehle in Form einer Text-Datei nach c:\temp, da die Zwischenablage über IPMI Boards nicht funktioniert.
• Ein lokaler Admin ist ebenfalls hilfreich, wenn der Domain Controller nicht erreicht werden kann (das passiert schnell, wenn ein einziger SBS Server auf einem Host das Kundenszenario darstellt).

Update 2014-04-17:
Ein Kollege hat mich darauf aufmerksam gemacht, dass der \windows.old Ordner nach dem Update noch vorhanden ist und gelöscht werden muss! Dieser verhält sich aber ein wenig zickig, kann aber dennoch wie folgt gelöscht werden:

takeown /F \Windows.old /R /A /D Y
icacls \Windows.old /grant Administrators:(F) /T
rd \Windows.old /s /q

Enjoy it, b!

Ab heute liefert Microsoft das sogenannte April-Update für Windows Server 2012 R2 und Windows 8.1 aus. Abonnenten des MSDN konnten das Update (welches aus insgesamt 6 Paketen besteht) schon seit letzter Woche herunter laden, der Rest wird das Paket über Windows Update oder einen WSUS angeboten bekommen.

Die Installation des Downloadpakets aus dem MSDN kann besonders einfach über folgendes Script erfolgen:

@echo off

set log=%windir%\Temp\update-windows-server-2012r2.log

echo.
echo Windows Server 2012 R2 Update Pack (April 2014) starts to install
echo Windows Server 2012 R2 Update Pack (April 2014) starts to install >%log%
echo.
echo  1. Package KB2919442
start /wait Windows8.1-KB2919442-x64.msu /quiet /norestart >>%log%
echo RC=[%ERRORLEVEL%], start /wait Windows8.1-KB2919442-x64.msu /quiet /norestart >>%log%
echo.
echo  2. Package KB2919355
start /wait Windows8.1-KB2919355-x64.msu /quiet /norestart >>%log%
echo RC=[%ERRORLEVEL%], start /wait Windows8.1-KB2919355-x64.msu /quiet /norestart >>%log%
echo.
echo  3. Package KB2932046
start /wait Windows8.1-KB2932046-x64.msu /quiet /norestart >>%log%
echo RC=[%ERRORLEVEL%], start /wait Windows8.1-KB2932046-x64.msu /quiet /norestart >>%log%
echo.
echo  4. Package KB2937592
start /wait Windows8.1-KB2937592-x64.msu /quiet /norestart >>%log%
echo RC=[%ERRORLEVEL%], start /wait Windows8.1-KB2937592-x64.msu /quiet /norestart >>%log%
echo.
echo  5. Package KB2938439
start /wait Windows8.1-KB2938439-x64.msu /quiet /norestart >>%log%
echo RC=[%ERRORLEVEL%], start /wait Windows8.1-KB2938439-x64.msu /quiet /norestart >>%log%
echo.
echo  6. Package KB2949621
start /wait Windows8.1-KB2949621-v2-x64.msu /quiet /norestart >>%log%
echo RC=[%ERRORLEVEL%], start /wait Windows8.1-KB2949621-v2-x64.msu /quiet /norestart >>%log%
echo.
echo Windows Server 2012 R2 Update Pack (April 2014) installation finished!
echo Windows Server 2012 R2 Update Pack (April 2014) installation finished! >>%log%
echo Press any key to reboot
pause >NUL
shutdown -r -t 0

Das Script erzeugt ein Log-File unter c:\windows\temp\update-windows-server-2012r2.log welches die Rückgabewerte der Installer enthält:

Windows Server 2012 R2 Update Pack (April 2014) starts to install 
RC=[2359302], start /wait Windows8.1-KB2919442-x64.msu /quiet /norestart 
RC=[3010], start /wait Windows8.1-KB2919355-x64.msu /quiet /norestart 
RC=[3010], start /wait Windows8.1-KB2932046-x64.msu /quiet /norestart 
RC=[3010], start /wait Windows8.1-KB2937592-x64.msu /quiet /norestart 
RC=[3010], start /wait Windows8.1-KB2938439-x64.msu /quiet /norestart 
RC=[-2145124329], start /wait Windows8.1-KB2949621-v2-x64.msu /quiet /norestart Windows Server 2012 R2 Update Pack (April 2014) installation finished!

Eine List mit Rückgabecodes des Installers ist hier vorhanden: http://support.microsoft.com/kb/304888/de

Sowohl der erste als auch der letzte Patch in der Liste waren auf dem System schon vorhanden – daher der vom Installer abweichende Rückgabe-Code.

[Update 1]
Wenn das Paket herunter geladen wurde, muss kontrolliert werden ob es als kritische Datei identifiziert wird. Das erfolgt über die Eigenschaften explizit für jedes der 6 Pakete:

Enjoy, it!