Wenn der User nur folgende Rechte hat:

• Read
• Distribute
• Delegate
• Create
• Manage Folders

Wenn dieser User dann versucht an dieser Stelle in der SCCM Konsole ein virtuelles Paket zu importieren:

• Computer Management\Software Distribution\Packages

Der Versuch das Paket zu importieren wird mit der Fehlermeldung:

User user does not have sufficient rights

ErrorCode = 1112017920

abgebrochen.

Dieses Problem tritt deshalb auf, weil der SCCM 2007 R2 fälschlicherweise davon ausgeht, dass der User zusätzlich noch das Recht “modify” benötigt.

Um den Fehler zu beheben wurde folgender Hotfix entwickelt, nur ist dieser Hotfix nicht öffentlich abrufbar und muss angefordert werden:

http://support.microsoft.com/?scid=kb%3Ben-us%3B978755&x=13&y=9

• Microsoft Application Virtualization 4.6 is now supported on ConfigMgr 2007 R2 with ConfigMgr 2007 SP2
  • System Center Configuration Manager 2007 R2 with System Center Configuration Manager 2007 SP2 now supports Microsoft Application Virtualization 4.6 Desktop Client and Client for Remote Desktop Services. This client release enables support for Windows 7 and Windows Server 2008 R2 and support for 64-bit operating systems.
  • No software updates are required.
• AMT firmware versions 4.2 and 5.2 are supported on ConfigMgr 2007 SP1 and SP2
  • System Center Configuration Manager 2007 SP1 and SP2 now supports AMT firmware versions 4.2 and version 5.2 with a minimum revision of 5.2.10 with the out of band management feature for both in-band provisioning and out of band provisioning.
  • No software updates are required.
• Windows XP Embedded SP3 is now supported on ConfigMgr 2007 SP2
  • System Center Configuration Manager 2007 SP2 now supports Windows XP Embedded SP3 as a client platform. This does change the Known Limitations for managing Windows Embedded devices.
  • No software updates are required.
• Windows Embedded Point of Sales 1.1 SP3 is now supported on ConfigMgr 2007 SP2
  • System Center Configuration Manager 2007 SP2 now supports Windows Embedded Point of Sales 1.1 SP3 as a client platform. This does change the Known Limitations for managing Windows Embedded devices.
  • No software updates are required.
• Windows Fundamentals for Legacy PCs SP3 is now supported on ConfigMgr 2007 SP2
  • System Center Configuration Manager 2007 SP2 now supports Windows Fundamentals for Legacy PCs SP3 as a client platform.
  • No software updates are required.

Der App-V 4.6 Client für RDS kann direkt auf der Downloadseite von Microsoft heruntergeladen werden.

Nach dem man sich mit seiner LiveID authentifiziert hat, kann man die EULA bestätigen und den Download starten. Wirklich?

Irgendwie fehlt an dieser Stelle wieder eine essentielle Option. Der “Ja” Button ist nicht vorhanden, sodass man im Moment nicht an den Download ran kommt. Sobald es funktioniert, werde ich den Blogeintrag aktualisieren.

(Update)

Nun ist es doch möglich den Button für “Ja” anzuklicken.

Danach noch schnell die persönlichen Daten angeben und schon bekommt man den gewünschten Download angeboten.

Somit stehen einem die neuen Funktionen von App-V 4.6 (endlich) zur Verfügung.

Hierzu muss man am Client folgendes machen:

• Den KMS Setup Key einspielen:

slmgr.vbs /ipk <KmsSetupKey>

• Danach muss man den KMS Client mit dem folgenden Befehl aktivieren:

slmgr.vbs /ato

Es ist auch möglich Einzelhandel Edition (Retail Edition) per KMS zu aktivieren. Hierbei ist natürlich zu beachten, dass diese Systeme auch lizensiert sind. Während der Installation einer Retail Edition muss der Wizard Bereich “Produktschlüssel” übersprungen werden. Nach der fertigen Installation muss man dann noch folgenden Befehl eingeben:

Slmgr.vbs /ipk <SetupKey>

Anbei noch die KMS Setup Keys für Windows 7 und Windows Server 2008 R2

• Software Distribution
• OS Deployment
• Software Update Management
• Desired Configuration
• vorhandene Betriebssysteme

Laut Jeff Wettlaufer ist die Installation auch sehr einfach durchzuführen. Dies stimmt auch soweit, wenn man schon einen SharePoint Server laufen hat oder mindestens einen Server hat, auf dem die SharePoint Services laufen. Besonders muss man beachten, das eine MSDN oder SQL Express Version vom SQL Server nicht unterstützt werden. Im Dashboard werden Funktionen des SQL Servers benutzt, die in der freien Version nicht zur Verfügung stehen. Somit muss man mindestens eine verteilte SharePoint Services Umgebung aufbauen, die sich in zwei Bereiche gliedert. Erstens installiert man einen SharePoint Frontend Server und zweitens installiert man die Datenbank für die SharePoint Services in einen Backend SQL Server.Hier bietet sich der SQL Server an, wo auch die Datenbank des SCCM Servers der jeweiligen Primary Site installiert wurde. Beide Datenbanken kann man in die gleiche Instanz auf dem SQL Server installieren.

Anbei schreibe ich eine kurze Zusammenfassung wie man die SharePoint Services und das Dashboard installiert.  Für meine Test habe ich einen dedizierten Windows Server 2008 R2 benutzt, da die SharePoint Services den IIS doch um einige Funktionen erweitern und ich meinen SCCM Server nicht beeinträchtigen wollte.

Als erstes werden folgende Komponenten benötigt:

• nur englische Server Systeme mit US Settings werden im Moment unterstützt
• SharePoint Services 3.0 SP2
• .net 3.5 SP1
• SCCM 2007 SP2 / SCCM 2007 R2 SP2
• Dashboard für SCCM 2007
• User für die SharePoint Services
• User für den lesenden Zugriff auf die SCCM Datenbank

Auf dem Windows Server 2008 R2 habe ich folgende Komponenten installiert:

• IIS 7.5
• .net Framework 3.5 SP1
• SharePoint Services

Danach wurden die SharePoint Services konfiguriert und eine Administrationswebseite eingerichtet.

Hierbei wird als erstes der Namen für die “SharePoint Services” Datenbank angegeben und der User mit dem der SharePoint Services auf diese Datenbank zugreifen kann. Der User braucht in dieser SQL Instanz die folgenden Berechtigungen.

• dbcreator
• securityadmin
• dbo für die SharePoint Datenbank (dies wird automatisch gesetzt)

Nun gibt man noch einen Port für die Administrationswebseite an, sowie das Zugriffsprotokoll.

Wenn man den Wizard dann abgeschlossen hat und die Installation erfolgreich durchgelaufen ist, sollte folgende Seite erscheinen.

Somit kann man sich per Webbrowser auf die Administrationswebseite verbinden. Hierbei muss man in der URL am Ende noch den Port mit angeben. :<Port>

Ab diesem Punkt sollte der Installation des Dashboards nichts mehr im Wege stehen. Somit kann man mit dem Aufruf des MSI beginnen.

-oder-

Hierbei ist es wichtig, dass man die Konsole mit administrativen Rechten aufruft, da ansonsten die Installation im Bereich “Dashboard Framework” fehlschlägt. Selbst das Log vom MSI bringt einen hier nicht weiter! (aber es steht so natürlich im Installation Guide!)

Im Dashboard Setup muss man wirklich nicht viel konfigurieren. Als ersten gibt man den Server und die Datenbank (gegeben falls die Instanz) an und den User mit dem das Dashboard auf die Datenbank lesend zugreifen soll.

Danach muss man nur noch den Datenbanknamen für das Dashboard angeben und einen User angeben, dem diese SharePoint Site gehört.

Sollte man nun alle Informationen richtig eingegeben haben und eine administrative Konsole zur Installation benutzt haben, wird man mit folgender Webseite belohnt. Hierbei muss natürlich auch wieder der Port im URL Aufruf mit angegeben werden.

Ab diesem Punkt kann man dann anfangen die Webseite seinen Anforderungen anzupassen. Dafür das dieses Produkt noch im Betastadium ist, läuft es recht stabil und bittet sehr viele nützliche Anzeigen.  Es lohnt sich also dieses Produkt in einem Testlab ausgiebig zu testen!

Wenn dies  in einer größeren Umgebung nicht schon schwer genug wäre, dürfen bestimmte Sitecodes nicht benutzt werden. Da der SCCM/SMS für die Struktur im Dateisystem viele Ordner anlegt und auch schon bestimmte Ordner nach einem Muster benennt, fallen ein paar Namen raus.

Folgende Ordner dürfen nicht benutzt werden, da ansonsten ein reibungsloser Betrieb nicht gewährleistet werden kann:

• CON
• PRN
• AUX
• NUL

Im R2 vom SCCM 2007 sind noch ein paar Namen dazu gekommen:

• OSD
• FCS
• SRS

Wirklich immer? Nein, es kommt manchmal vor, dass sich der Client trotz funktionierender KMS Umgebung nicht aktivieren kann.  Ein Kollege von mir, wurde an einem Rechner mit dieser Fehlermeldung begrüßt:

Da die Maschinen alle per SCCM 2007 SP2 betankt wurden, konnte man davon ausgehen, dass die Software (incl. OS) auf allen Maschinen gleich war. In der Testphase gab es auch nur 4 Rechnertypen, diese hatten bis jetzt auch keine Probleme. Der KMS konnte gleichzeitig aber andere Maschinen aktivieren. Wo sollte dann das Problem liegen?

Auch konnte man den Rechner nicht von Hand per Kommando gegen einen KMS Server aktivieren. Der Versuch mit:

wird mit der folgenden Fehlermeldung quittiert:

Auch ein Auslesen der KMS Client Informationen per folgendem Befehl zeigte keine Auffälligkeiten:

Der Lizensierungsmodus stand auf KMS und der Host hatte noch 30 Tage zum Aktivieren. Des Weiteren konnte man auch noch zwei Mal die Aktivierung des Clients verschieben:

Um zu überprüfen, ob es sich um ein valides Betriebssystem handelt, wurde das “Microsoft Genuine Advantage Diagnostic Tool” heruntergeladen und installiert. Nach dem Test stellte sich heraus, dass es doch kein valides Betriebssystem ist?! Alle Rechner wurden per SCCM mit der gleichen Testsequence betankt, trotzdem verhalten sie sich in diesem Fall völlig unterschiedlich. Wie kann dies sein?

Zum Glück kann man das Ergebnis des “Microsoft Genuine Advantage Diagnostic Tool” in eine Textdatei exportieren. Dort sieht man im Bereich “OEM Activation 2.0 Data”, dass nicht alles wie gewünscht geprüft werden konnte. Der ominöse “Windows marker” konnte nicht ausgelesen werden. Wozu wird dieser Marker den überhaupt benötigt? Damit OEM Hersteller sich in Ihren Fertigungsanlagen keine eigene KMS Infrastruktur aufbauen müssen, gibt es ein bestimmtes Abkommen zwischen den OEM Herstellern und Microsoft. Die OEMs erweitern Ihre BIOS Systeme um ein bestimmtes Feld. Dieses lautet “Software Licensing table” In diesem werden die benötigten “Windows marker”  Daten eingetragen. Hierdurch weiß der KMS Dienst dann, das er sich auf einem OEM System bewegt und verhält sich dementsprechend.

In diesem Fall war es dann so, dass zwar der “Software Licensing table” vorhanden war, aber die Daten in dem Feld waren entweder korrupt oder gar nicht vorhanden. Im Log stand dann folgender Eintrag:

Also wurde schnell ein BIOS Update gemacht. Dadurch wurde der “Software Licensing table” mit den benötigten OEM Informationen gefüllt. Das Ergebnis des “Microsoft Genuine Advantage Diagnostic Tool”  lieferte dann folgendes Ergebnis im Log:

Zwar kann immer noch nicht die Version ausgelesen werden (oder diese soll nicht mehr angezeigt werden?), aber die Fehlermeldung ist weg. Danach ließ sich der Rechner auch ohne Probleme aktivieren. Auch nach einer automatisierten Neuinstallation funktionierte die Aktivierung wie gewohnt. Der Fehler ist auch reproduzierbar. Sobald die alte Firmware eingespielt wird, kann der Rechner nicht mehr aktiviert werden.

Somit steht es wieder mal fest. In der IT ist alles gleich, nur manches ist gleicher…

Anbei noch die Inhalte der zwei verschiedenen Pakete:

• ICP1:English, French, German, Japanese, Spanish

• ICP2:Chinese (Simplified), Chinese (Traditional), Czech, Danish, Dutch, Finnish, Greek, Hungarian, Italian, Korean, Norwegian, Polish, Portuguese, Portuguese (Brazil), Russian, Swedish, Turkish

Als wir den Fehler genauer analysiert hatten, konnten wir folgendes festhalten:

• Der IIS auf einem der Windows 2008 Server lief nicht mehr wie gewünscht.
• Eine Umkonfiguration schien auch keinen Erfolg zu versprechen.
• Es waren einige Dienste auf diesem System vom IIS abhängig.

Somit haben wir uns darauf geeinigt, die abhängigen Dienste zu entfernen und danach den IIS  (incl WebDav) zu entfernen. Im Nachgang haben wir den IIS wieder installiert und die Dienste wieder installiert.

Einen schönen Effekt hatten wir hierbei auch noch. Der Neustart der Maschine dauerte immer 20 Min!  Erst als wir WebDav entfernt hatten, dauerte der Rebbot nur noch 20 sec. Nachdem das WebDav wieder drauf war, änderte sich die Rebootzeit wieder auf 20 Min.

Um 21:00 Uhr waren wir dann endlich fertig und hatten alle Test erfolgreich abgeschlossen. Wirklich alle Tests? Wir hatten vergessen, dass man einen Client per Push auf einen Windows 7 Client bringen müsste.

Am Folgetag wurde dieses im Tagesgeschäft vom Kunden automatisch probiert und funktionierte leider nicht wie gewohnt. Nach dem wir den Fehler dann eingegrenzt hatten, stellten wir fest, dass die IIS Settings nicht richtig konfiguriert waren. Im Log auf dem SCCM erschien nämlich folgende Fehlermeldung, wenn man versucht den Client per Push zu installieren:

Genau zu diesem Problem gibt es schon einen KB Artikel. Den der ApplicationHost.config Datei fehlt ein Eintrag für den Policy Bereich. Ohne diesen Eintrag werden folgende HTTP Komandos vom IIS abgewiesen:

Wir haben dann die Konfigurationsdatei von einem anderen SCCM Server kopiert und auf diesem Server ersetzt. Danach haben wir den IIS Dienst einmal durchgestartet und das Problem war verschwunden. Nun können auch die SCCM Clients wieder per Push Verfahren installiert werden.

Bei der Installation des vCenters wird automatisch ein Zertifikat installiert, welches für die Kommunikation zwischen dem vSphere Client und dem vCenter benötigt wird. Auch für die Kommunikation mit den ESX Servern wird dieses benutzt. Dieses Zertifikat hat aber mehrere Nachteile:

• Es ist ein selbstgeneriertes OpenSSL Zertifikat
• Es kann dadurch nicht erfolgreich validiert werden
• Die User bekommen bei der Verbindung mit dem vSphere Client eine Warnmeldung
• Das Zertifikat läuft nach 2 Jahren ab.

Somit sollte man dieses Zertifikat gegen ein vertrauenswürdiges Zertifikat tauschen. Wenn man schon eine Windows PKI im Haus hat, kann man diese gerne zum Ausstellen des Zertifikates benutzen. Da man das vCenter wahrscheinlich über einen Alias aufrufen möchte und nicht über den Hostnamen, sollte man direkt ein “Subject Alternative Names”(SAN) Zertifikat ausstellen. Somit kann man mit einem Zertifikat mehrere SSL Verbindungen signieren. Somit sind z.B. folgende Urls mit einem Zertifikat valide:

• vcenter.domain.tld
• host.domain.tld
• host2.domain.tld
• vcenter
• host
• host2

Wie geht man aber vor, um das Zertifikat zu erstellen?

1. Man installiert sich auf einem Rechner openssl für Windows. Dies muss nicht der vCenter Server sein!
2. Dann erstellt man sich eine conf Datei mit allen benötigten Einstellungen. Eine Beispieldatei füge ich am Ende des Beitrages an. Die Datei lautet hierbei “vm_labor.conf”
3. Nun erzeugt man sich einen privaten “RSA Generalschlüssel” für seine Zertifikate.
   

   openssl genrsa 1024 > rui.key

4. Als nächstes wird die Zertifikatanforderung erstellt.
   

   openssl req -new -key rui.key -nodes -out rui.csr -config vm_labor.conf

5. Dann verbindet man sich mit dem Webenrollment Service der Zertifikatsstelle. (z.B. https://domaincontroller/certsrv)
6. “Request a certificate” and “submit an advanced certificate request”
7. Submit a certificate request by using a base-64-encoded CMC or
   PKCS #10 file, or submit a renewal request by using a base-64-encoded
   PKCS #7 file”
8. Den Inhalt der “rui.csr” in das Feld “Saved Request:” kopieren. Hierbei ein Template auswählen welches für SAN Zertifikate konfiguriert ist.
9. Je nach Template muss die Anforderung noch in der Zertifikatstelle freigegeben werden.
10. Das generierte Zertifikat herunterladen. Hierbei “Base 64 encoded” auswählen.
11. Das Zertifikat muss umbenannt werden, da eine andere Dateiendung benötigt wird!
    

    Es muss “rui.crt” heißen.

12. Jetzt muss eine Zertifikatscontainerdatei erstellt werden und mit einem Passwort geschützt werden.
    

    openssl pkcs12 -export -in rui.crt -inkey rui.key -name vcenter.labor.local -out rui.pfx

13. Die erstellten Dateien (rui.key , rui.crt und rui.pfx) müssen nach
    

    “%ALLUSERSPROFILE%\Application Data\VMware\VMware vCenter\SSL\”

    auf den vCenter Server kopiert werden. Hierbei werden die Originale überschrieben.

14. Im Arbeitsverzeichnis vom vCenter
    

    “%ProgramFiles%\VMware\Infrastructure\vCenter Server”

    ruft man vpxd mit dem Parameter –p auf. Damit wird die Datenbank mit dem neuen Zertifikat initialisiert. An dieser Stelle muss dann nochmals das Passwort für die Zertifikatscontainerdatei eingegeben werden. Siehe Punkt 12.

15. Im Anschluss muss der vCenter Dienst einmal durchgestartet werden. Somit wird das neue Zertifikat an den SSL Port des Apache Servers gebunden.
16. Da die Kommunikation zwischen den ESX Servern und vCenter per Zertifikate verschlüsselt wird, muss das neue Zertifikat noch den ESX Servern bekannt gemacht werden. Dafür müssen die ESX Server einmal vom vCenter getrennt werden und danach wider verbunden werden. Somit wird die Verbindung mit dem neuen Zertifikat neu verschlüsselt.

Somit hat man das neue Zertifikat im vCenter eingebunden und die User werden beim verbinden mit dem VI Client nicht mehr mit einer Warnmeldung begrüßt. Ich weiß auch, dass der Aufwand sehr hoch ist um diesen “Fehler” zu beheben, aber man sollte die User soweit wie Möglich für Zertifikatsfehler sensibilisieren. Umso mehr Zertifikatsfehler ein User wegklickt umso mehr steigt die Wahrscheinlichkeit, dass dieser User keine Warnung mehr beachtet und ein leichtes Ziel für Phishing-Attacken werden kann.

vm_labor.conf