Kategorie: Microsoft

Windows Server 2012 R2 – Das kommt im neuen Hyper-V

Veröffentlicht 10. Juni 2013

Nachdem kürzlich für Windows Server 2012 ein R2 angekündigt wurde, gibt es nun auch einige Details zu den Änderungen in Hyper-V. Diese möchte ich hier kurz zusammentragen:

Generation-2-VMs

Es wird eine neue Generation für VMs geben, die verschiedene neue Szenarien unterstützen soll, so z.B. das Booten von iSCSI. Dies wird erreicht, indem hier nahezu vollständig auf Emulation von Hardware verzichtet werden soll. Dies funktioniert allerdings nur mit 64-Bit Client-Systemen und nur mit Windows 8 und dem Server 2012 als Gast.

VM Direct-Connect

Bisher ist für einen direkteren Zugriff auf die VM (inkl. Durchreichen von Laufwerken und Zwischenablage) eine RDP-Verbindung nötig, für die wiederum eine Netzwerkverbindung zwischen Gast und Host nötig ist, mit allen damit verbundenen Sicherheitsrisiken und Konfigurationsaufwänden. Mit Direct-Connect werden diese Möglichkeiten künftig auch mit der klassischen VM-Verbindung möglich sein.

Erweiterte Replikation einer VM

Es soll möglich sein, dass ein Host für eine VM nicht mehr nur Quelle ODER Ziel für die Replikation ist, sondern beides. Damit wird es möglich sein, ein Replikat innerhalb des Unternehmens, ein zweites außerhalb aufzubewahren. Vermutlich wird es auch möglich sein, eine VM direkt an 2 Ziele zu replizieren.

Die Replikation unter Server 2012 lässt lediglich ein Intervall von 5 Minuten zu. Im R2 wird es möglich sein, alternativ auch 30 Sekunden oder 15 Minuten zu wählen – je nach Notwendigkeit und Kapazität. Da nach 12 fehlerhaften Versuchen die Replikation unterbrochen wird, hätte man damit die Möglichkeit, 3 Stunden Downtime zu tolerieren.

Kompression & SMB Direct

Bei der Migration von VMs wird es 2 neue Optionen geben: Kompression der zu übertragenden Daten oder Übertragung via SMB Direct (setzt Netzwerkadapter auf beiden Seiten voraus, die RDMA unterstützen). Microsoft empfiehlt bei 10GBps-Links die Nutzung von RDMA, andernfalls die Kompression. Hierbei muss man natürlich den Einfluss der höheren CPU-Last auf die restlichen VMs beachten.

Online Export & Klonen

In Windows Server 2012 muss eine VM erst heruntergefahren/ausgeschaltet werden, bevor sie exportiert oder mittels SCVMM geklont werden kann. In R2 wird dies nun auch bei laufenden VMs möglich sein, wodurch es auch für Produktivumgebungen interessant wird.

Online-Größenänderung von VHDX

Es soll in Windows Server 2012 R2 möglich sein, eine VHDX während deren Nutzung durch eine laufende VM sowohl zu vergrößern, als auch sie zu verkleinern!

Storage-QoS

Der Windows Server 2012 R2 wird eine Möglichkeit bieten, die IOPS einer VM zu beschränken. Damit kann man eine IO-lastige VM begrenzen, um anderen VMs weiterhin eine akzeptable Datenrate auf dem Storage zu ermöglichen.

Dynamic Memory für Linux-VM

Für supportete Linux-Systeme wird es möglich sein, deren RAM-Zuweisung (wie bisher auch bereits bei Windows-Gast-Systemen möglich) dynamisch zu gestalten. Damit werden z.B. größere Ansammlungen von Linux-(Web-)Servern dynamischer.

Shared VHDX

Für Cluster-Szenarien wird es möglich sein, dass 2 VMs eine gemeinsame VHDX nutzen. Damit entfällt die Notwendigkeit, ein CSV auf iSCSI- oder FibreChannel-Basis einzusetzen.

Schreibe einen Kommentar...

SCCM2012: Durch SEDO dauerhaft gesperrte Tasksequenzen entsperren

Veröffentlicht 31. Mai 2013

SEDO (Serialized Editing of Distributed Objects) soll im SCCM2012-Umfeld möglich machen, dass mehrere Admins gleichzeitig arbeiten, ohne sich gegenseitig in die Quere zu kommen. Wenn unter SCCM2007 ein Admin eine Tasksequenz bearbeitet hat, die noch bei einem anderen Admin zur Bearbeitung geöffnet war, dann „gewann“ derjenige, der zuletzt gespeichert hat, was mitunter sehr ärgerlich war.

Unter SCCM 2012 werden nun Tasksequenzen, die zum Bearbeiten geöffnet sind, gesperrt. Diese an sich sehr nützlich Funktion kann aber auch zu einem Problem werden. Die Sperre sollte nach 30 Minuten „Inaktivität“ automatisch aufgehoben werden. Da dies aber ein Vorgang ist, den die SCCM-Konsole durchführt, kann es passieren, das eine gesperrte Tasksequenz dauerhaft gesperrt bleibt, wenn z.B. die Konsole abgestürzt ist.

Für die Sperrung ist die SQL-Tabelle SEDO_LockState zuständig.

Gesperrte Tasksequenzen kann man z.B. mit folgendem SQL-Statement abfragen:

1	SELECT * FROM SEDO_LockState WHERE LockStateID != 0

Das eine Tasksequenz gesperrt ist, wird auch beim Versuch, diese zu bearbeiten angezeigt:

Um nun eine Entsperrung zu erzwingen, ist folgendes SQL-Statement geeignet:

UPDATE [CM_LPZ].[dbo].[SEDO_LockState]
SET [LockStateID] = 0
,[AssignedUser] = NULL
,[AssignedObjectLockContext] = NULL
,[AssignedMachine] = NULL
,[AssignmentTime] = NULL
 
WHERE [LockStateID] = '1'
GO

(das „LPZ“ in „CM_LPZ“ ist durch den Sitecode zu ersetzen)

Aber Achtung: Microsoft unterstützt das manuelle Ändern der SQL-Datenbank nicht – ihr solltet also genau wissen, was ihr da tut!

2 Comments

PowerShell: Alle Windows-Updates automatisch entfernen

Veröffentlicht 21. Mai 2013

Das entfernen ALLER Windows-Updates von Hand ist sehr mühsam. Die PowerShell schafft hier abhilfe. Das folgende kleine Skript ermittelt alle installierten Windows-Updates und entfernt diese der Reihe nach:

$hotfixes = Get-WmiObject -Class Win32_QuickFixEngineering | select hotfixid
 
foreach($hotfix in $hotfixes)
{
    $KBNummer = $hotfix.HotfixId.Replace("KB", "")
    $Kommando = "wusa.exe /uninstall /kb:$KBNummer /quiet /log /norestart"
    Write-Host ("Removing update with command: " + $Kommando)
    Invoke-Expression $Kommando
    While (@(Get-Process wusa -ErrorAction SilentlyContinue).Count -ne 0)
    {
        Start-Sleep 1
        Write-Host "Waiting for update removal to finish ..."
    }
}

Schreibe einen Kommentar...

WSUS offline installieren / Abhängigkeiten automatisch installieren

Veröffentlicht 10. April 2013

Will man den WSUS-Server ohne eine Internetverbindung installieren, ist der klassische Weg über den Server-Manager („Rolle hinzufügen“) nicht geeignet, da dieser die notwendigen Daten aus dem Internet bezieht.

Als Alternative kann man sich das WSUS-Setup bei Microsoft frei herunterladen. Allerdings benötigt dieses einige Rollen und Rollendienste sowie Features, die man nun „von Hand“ installieren muss (Beim Weg über den Servermanager wären sie automatisch mit ausgewählt worden).

Um nun diese Installation der Abhängigkeiten zu vereinfachen, ist dieses kurze PowerShell-Skript geeignet:

1 2	Import-Module ServerManager Get-WindowsFeature OOB-WSUS \| Select -exp DependsOn \| Add-WindowsFeature

Schreibe einen Kommentar...

Speicherhunger der WSUS-Datenbank (WID) begrenzen

Veröffentlicht 2. April 2013

Insbesondere in kleinen und mittleren Unternehmen läuft der Windows Server Update Service (WSUS) nicht auf einem vollwertigen SQL-Server, sondern auf einer Windows Internal Database, welche bereits Bestandteil des Windows Server 2008 (R2) ist, und somit direkt bei der Installation von WSUS mitinstalliert werden kann.

Das Problem: Wenn es um Arbeitsspeicher geht, verhält sich die WID wie ein „großer“ SQL-Server – sie nimmt was sie bekommen kann.

Dieses Verhalten lässt sich beim regulären SQL-Server u.a. mit dem SQL Server Management Studio beeinflussen. Dieses Programm ist allerdings nicht Bestandteil der WID-Installation.

Die Lösung: Das frei erhältliche SQL Management Studio Express bietet genau diese Möglichkeiten.

Vorgehensweise:

1. SQL Management Studio Express downoaden

http://www.microsoft.com/de-de/download/details.aspx?id=8961

2. SQL Management Studio Express installieren

Ist nicht weiter schwer, einfach den Setup-Assistenten benutzen…

3. Verbindung zur WID aufbauen

Dazu muss das Management Studio u.U. als Administrator ausgeführt werden. Als Verbindungsziel wird

\\.\pipe\mssql$microsoft##ssee\sql\query

verwendet.

4a. Konfiguration mittels T-SQL

Nun müssen folgende beiden T-SQL Abfragen ausgeführt werden:

sp_configure ’show advanced options‘, 1;
reconfigure;
go

„Ausführen“ anklicken

sp_configure ‚max server memory‘, 256;
reconfigure;
go

(Den Wert 256 durch das gewünschte Maximum ersetzen )

„Ausführen“ anklicken

4b. Konfiguration mittels GUI

Rechtsklick auf den obersten Eintrag im Objekt-Explorer, im Kontextmenü „Eigenschaften“ auswählen

Im neu geöffneten Fenster den Bereich „Arbeitsspeicher“ wählen und dort den minimalen und den maximalen Speicherwert eintragen.

Das war es schon gewesen. Evtl. muss die Datenbank neu gestartet werden…

7 Comments

SCCM2012: Content-Prestaging / Vorab bereitgestellte Inhalte

Veröffentlicht 24. März 2013

Oft müssen Content-Daten – z.B. in Form von WIM-Dateien für OSD – von einem Distribution Point (DP) zu einem anderen übertragen werden. Insbesondere bei größeren Dateien kann dies länger dauern, ein Versand der Daten auf dem Postweg wäre schneller.

Für diese Fälle bietet SCCM die Möglichkeit, Inhalte „vorab bereitzustellen“, sie quasi auf einem DP zu exportieren, um sie an einem anderen zu importieren. Hierbei ist zu beachten, dass einen Unterschied macht, ob man den selben Content, den man an einer Stelle exportiert hat an einer anderen importiert, oder den Content mit Hilfe des ursprünglichen (z.B. WIM-)Files neu erstellt. Beim neu erstellen erhält der Content z.B. eine andere ID!

Die notwendigen Schritte sind die folgenden:

1. Content exportieren („Datei für vorab bereitgestellten Inhalt erstellen“)

Dazu muss via Rechtsklick auf den jeweiligen Content die Option „Datei für vorab bereitgestellten Inhalt erstellen“ ausgewählt werden. Nun muss zum einen der Speicherort angegeben werden und zum zweiten der DP, von dem aus die Datei extrahiert werden soll. Am Ende hat man eine PKGX-Datei, eine gepackte Paketdatei. In dieser sind auch die Metadaten des Inhaltes enthalten. Es ist auch möglich, mehrere Content-Dateien in einem gemeinsamen PKGX-File zu exportieren.

2. Content an anderen DP verbringen

Hierzu muss die PKGX-Datei an den DP gebracht werden. Dies kann z.B. via DVD oder USB-Datenträger, aber auch per SMB-Filetransfer erfolgen.

3. DP für vorab bereitgestellten Inhalt aktivieren

Bevor Daten (Content) an einem DP importiert werden können, muss dieser erst für vorab bereitgestellte Inhalte aktiviert werden. Dies geschieht in den Eigenschaften des jeweiligen DPs:

4. Content importieren

Für den Import gibt es keine GUI, dies muss über Kommandozeile erfolgen. Dazu verwendet man extractcontent.exe aus dem BIN-Verzeichnis der SCCM-Installation. Mit dem Schalter /p wird das Paket angegeben, /s sorgt dafür, dass bereits vorhandener Content übersprungen wird.

Nun steht der Content am entfernten DP zur Verfügung!

2 Comments

SCCM2012: Fehler 0x80070002 während OSD / PXE

Veröffentlicht 13. März 2013

Mal wieder ein Fehler, den ich hier festhalten möchte, obwohl diesmal recht trivial.

Während einer PXE-gestützten Betriebssysteminstallation (OSD) trat nach der Partitionierung und Formatierung der Festplatte der Fehler 0x80070002 auf:

Ein Blick in das Log-File war leider nur mäßig hilfreich:

Da der nächste Schritt, der nun also nicht erfolgreich bearbeitet wurde, das Kopieren der WIM-Datei gewesen wäre, vermutete ich ein Problem beim Zugriff auf dem DP, und meine Vermutung fand ihre Bestätigung:

Es war einfach kein Network Access Account (Netzwerkzugriffskonto) angegeben!

Dies lässt sich recht einfach erreichen, ich denke die Bilder sind aussagekräftig genug:

UPDATE: Ich habe eben festgestellt, dass dieser Fehler auch trotz korrekt konfiguriertem NAA auftreten kann. In meinem Fall war die Fehlerursache dann auch eine ganz andere: Es fehlte einer Bedingungen für Distribution Points, nämlich die „Windows-Authentifizierung“ des IIS!

Die vollständigen Vorbedingungen lassen sich im Übrigen hier nachlesen: http://technet.microsoft.com/en-us/library/gg682077.aspx#BKMK_SupConfigSiteSystemReq

Schreibe einen Kommentar...

SCCM2012: CcmSetup failed with error code 0x80004005 bzw. 0x800b0101

Veröffentlicht 12. März 2013

Ich hatte heute mal wieder ein kleineres Problem mit dem SCCM 2012 SP1, das sich wie folgt äußerte:

Auf einem Windows 7 Client wollte ich per Push-Installation den CM-Client installieren. Dies schlug jedoch mehrfach fehl, obwohl auf den ersten Blick alles in Ordnung war. Im Logfile unter C:\Windows\ccmsetup\Logs war zu lesen:

[LOG[Couldn't verify 'C:\windows\ccmsetup\MicrosoftPolicyPlatformSetup.msi' authenticode signature. Return code 0x800b0101]LOG]!><time="15:09:23.921-60" date="03-12-2013" component="ccmsetup" context="" type="3" thread="1600" file="util.cpp:1236">
[LOG[A Fallback Status Point has not been specified. Message with STATEID='316' will not be sent.]LOG]!><time="15:09:23.921-60" date="03-12-2013" component="ccmsetup" context="" type="1" thread="1600" file="ccmsetup.cpp:9428">
[LOG[InstallFromManifest failed 0x80004005]LOG]!><time="15:09:23.921-60" date="03-12-2013" component="ccmsetup" context="" type="3" thread="1600" file="ccmsetup.cpp:7086">
[LOG[CcmSetup failed with error code 0x80004005]LOG]!><time="15:09:23.921-60" date="03-12-2013" component="ccmsetup" context="" type="1" thread="1624" file="ccmsetup.cpp:10544">

Insbesondere dieser Eintrag machte mich etwas stutzig:

Couldn’t verify ‚C:\windows\ccmsetup\MicrosoftPolicyPlatformSetup.msi‘ authenticode signature. Return code 0x800b0101

Nach kurzer Suche war die Fehlerquelle gefunden: Ich hatte das erste RTM-Release vom SCCM2012SP1 installiert. Hier gibt es ein Problem mit Zeitstempeln digitaler Signaturen. Daher wurde am 25.01.2013 ein Re-release des SP1 veröffentlicht. Mit diesem wäre der Fehler nicht aufgetreten.

Es gibt aber auch eine andere Lösung, ohne den SCCM neu installieren zu müssen: Microsoft hat in der KB einen entsprechenden Artikel samt passendem Hotfix veröffentlicht:

http://support.microsoft.com/kb/2801987/de

Der Direktlink zum Hotfix:

http://hotfixv4.microsoft.com/ConfigMgrV5/sp1/ConfigMgr_2012_SP1_CU0_KB2801987_ENU/05.00.7804.1108/free/457899_ENU_x64_zip.exe

Hinweis zu den ISOs:

mu_system_center_2012_configuration_manager_and_endpoint_protection_with_sp1_x86_x64_dvd_1360357

-> Das ist das erste Release (RTM) – fehlerhaft

mu_system_center_2012_configuration_manager_and_endpoint_protection_with_sp1_x86_x64_dvd_1565907

-> Das ist das bereinigte Re-Release

Schreibe einen Kommentar...

SCCM2012: Fehler beim Installieren einer neuen Primary Site in bestehender Hierarchie

Veröffentlicht 9. März 2013

Folgender Fehler ist mir heute begegnet, als ich einen weiteren Server als Primary Site zu einer bestehenden SCCM-Hierarchie hinzufügen wollte:

Der Fehlertext lautet: „Der Benutzer, der Setup ausführt, muss am zentralen Zielverwaltungsstandort über die RBA-Sicherheitsrolle „Infrastrukturadministrator“ oder „Hauptadministrator“ verfügen. Überprüfen Sie, ob der Benutzer über die richtige Rolle verfügt.“

Die englische Fehlermeldung hierzu lautet: „The setup login user does not have sufficient permission to configure replication with specified central administration site“

Da der User bereits vorher an einem anderen Standort zu Installation problemlos genutzt wurde und auch über die Hauptadministrator-Rolle („Full Administrator“) verfügte, musste es ein anderes Problem sein.

Nach einigen Tests und Recherchen konnte ich den Fehler finden und beseitigen. Die beiden Standorte (Standort der CAS und Standort der neu zu installierenden Primary Site) sind über Site-to-Site-VPNs mit Hilfe vom ISA-Server bzw. Forefront TMG verbunden. Hier gibt es eine Filter-Regelung namens „Strikte RPC-Einhaltung erzwingen“ („Enforce strict RPC compliance“):

(Zu finden unter „Webzugriffsrichtlinie“ / „RICHTLINIE“ / „Protokolle“ / „Filterung“ / „RPC-Protokoll konfigurieren“)

Nach dem ich diese Option auf beiden Seiten deaktiviert und die VPN-Verbindungen neu aufgebaut hatte, ließ sich die neue Primary Site problemlos installieren, da nun DCOM-Traffic zulässig war.

Schreibe einen Kommentar...

SCCM2012: Fehler beim Setup – SQL-Server Name muss mit dem Namen in „sys.servers“ übereinstimmen

Veröffentlicht 7. März 2013

Wenn man auf einem Server bereits den SQL-Server installiert hat und nun vor der Installation des System Center 2012 Configuration Manager den Hostnamen dieses Servers ändert, kommt es am Ende des Setup-Assistenten zu einem Fehler. Der deutsche Fehlertext lautet:

Der beim Setup angegebene SQL Server-Name muss mit dem Namen in „sys.servers“ des SQL Server-Computers übereinstimmen.

Dieses Fehler lässt sich recht leicht beheben. Dazu muss zuerst die SCCM-Instanz deinstalliert werden.

Danach muss folgende Query im SQL Server-Manager ausgeführt werden:

EXEC sp_dropserver "ALTER_HOSTNAME"
GO
EXEC sp_addserver "AKTUELLER_HOSTNAME", "local"
GO

Den „alten“ Hostnamen kann man auch dem Setup-Log unter c:\ConfigMgrSetup.log entnehmen. Dort findet sich eine Meldung in etwa wie folgt:

ERROR: SQL server’s Name ‚[ALTER_HOSTNAME]‘ in sys.servers does not match with the SQL server name ‚[NEUER_HOSTNAME]‘ specified during setup. Please rename the SQL server name using sp_dropserver and sp_addserver and rerun setup. $$<Configuration Manager Setup><03-07-2013 22:07:09.409-60><thread=364 (0x16C)>

Nach dem Ausführen der Query im SQL Server-Manager muss der Server neugestartet werden. Danach kann das SCCM-Setup erneut durchgeführt werden.

Schreibe einen Kommentar...