XP Mode vs. VMware Player
Microsoft macht viel Werbung mit dem XP Mode in Windows 7, doch was ist da dran?
Vor einigen Tagen hat Microsoft-Manager Brandon LeBlanc im Windows Blog angekündigt, dass bei den Anforderungen an die Hardware nachgebessert werden wird. Bisher funktionierte der XP Mode nur, wenn der Prozessor Intels VT- oder AMDs V-Technik unterstützte.
In diesem Artikel wird der Windows 7 XP Mode mit dem VMware Player verglichen, um die Praxistauglichkeit zu testen.
XP Mode
Um den Windows 7 XP Mode installieren und betreiben zu können sind einige Vorrausetzungen nötig. Es wird ein Windows 7 Professional oder höher vorrausgesetzt. Bis zum heutigen Tag muss der Prozessor Intels VT- oder AMDs V-Technik unterstützten, damit die Installation funktioniert.
Wenn diese Vorrausetzungen erfüllt sind, kann der XP Mode runtergeladen und installiert werden. Die Installation selbst besteht aus zwei Teilen, dem Virtual PC und dem Windows XP Image (VHD). Nach der Installation ist der virtuelle XP "Rechner" einsatzbereit, es muss nur noch ein Kennwort für den User festgelegt werden und dann gehts los.
Bei der virtuellen Maschine fällt auf, dass es beim Virtual PC kein Support für 3D Grafik gibt, was ein Nachteil sein kann.
Für den Benchmark Test wurde PassMark 7.0 verwendet. Vor dem Benchmark Test sind die System auf den Patch Stand März 2010 gebracht worden. Der Benchmark Test selbst stolpert über die fehlende 3D Grafikunterstützung und lässt den zutreffenden Test aus. Die Leistung des Virtual PC mit XP Mode liegt bei 282.3 Punkten, was nicht besonders viel ist.
VMware Player
Als Vorraussetzung an das Hostsystem, stellt der VMware Player ungefähr die gleichen Anforderungen wie der Virtual PC von Microsoft. Den VMware Player kann man bei VMware.com kostenfrei runterladen.
Nach der Installation ist allerdings ein Reboot notwendig, da einige virtuelle Hardware Geräte, wie z.B. Netzwerkkarten, installiert werden. Es ist mir leider nicht gelungen die VHD vom XP Mode im VMware Player zu verwenden, da das darin enthaltene Windows XP beim Start im VMware Player eine Aktivierung erfordert, die Microsoft verweigert. VMware schreibt aber auf ihrer Webseite, dass sie mit dem XP Mode kompatibel sind:
Windows XP Mode Compatible
— Import a Windows XP Mode virtual machine using VMware Player 3.0 and run the virtual machine without being prompted to enter a Windows XP license key. VMware Player enables the Windows XP Mode virtual machine to take advantage of more than one processor, render high-end graphics, integrate seamlessly with Unity, and transfer files easily with drag and drop, and shared folders. VMware Player also has the ability to run concurrently with Windows XP Mode.
Darum wird im VMware Player ein neuer Windows XP Rechner aufgesetzt und auf den gleichen Patch Stand gebracht. In dieser VM lieft der Benchmark Test fehlerfrei durch, da der VMware Player eine virtuelle 3D Grafikkarte mitbringt und somit 3D Grafikunterstützung liefert. Das Windows XP kam im VMware Player auf 489.7 Punkte, was deutlich besser ist als der XP Mode.
Fazit
Die beiden Benchmark Ergebnisse sprechen ja schon für sich, aber es gibt einige Detail, die man bei der Wahl beachten muss.
Der XP Mode hat den Vorteil, dass keine extra Lizenz benötigt wird, da die im Produkt enthalten ist. Genau das ist auch der Grund wieso eine Windows 7 Professional oder höhere Version benötigt wird, da Microsoft nur die Business Kunden damit adressiert. Der VMware Player hingegen darf auf allen Versionen von Windows 7 installiert werden, bedarf aber einer extra Windows XP Lizenz für das XP in der VM.
Der VMware Player hat eine 3D Grafikunterstützung, die im Virtual PC leider fehlt. Beide Virtualisierungssysteme unterstützen die Funktion, die Anwendungen in einem extra Fenster darstellen zu können, ohne das die ganze VM angezeigt werden muss, bei VMware Unity genannt.
Der Test wurde auf einem IBM T60 Notebook durchgeführt, was 651 Punkte im Benchmark erreicht.
Alles in Allem ist der Einsatz solcher Virtualisierungssysteme im Businesseinsatz bei mehr als 10 Endgeräte eher unpraktisch, da der Versaltungsaufwand für die virtualisierten XP Systeme sehr groß und auch diese Systeme pflege und Updates benötigen. Da sie nicht permanent laufen und teilweise auch nicht mehr abgeschaltet werden müssen, sondern nur angehalten werden, ist die Pflege nur manuell möglich. Im Businessbereich sollte man sich eher über eine zentralisierte und managebare Lösung gedanken machen.
PowerCLI cmdlets for vCenter Update Manager
Die PowerCLI Update Manager cmdlets sind da!
Laut einem Blogeintrag im PowerCLI Blog, stellt das neue PowerShell snapin die folgenden 13 cmdlets bereit:
Cmdlet Name Cmdlet Description Attach-Baseline Attaches baselines to the specified Template, VirtualMachine, VMHost, Cluster, Datacenter, Folder, and VApp objects. Attaching a baseline to a container object such as a folder or datacenter transitively attaches the baseline to all objects in the container.
Detach-Baseline Detaches baselines from the specified inventory objects. Download-Patch Downloads new patches into the Update Manager patch repository from the enabled patch download sources. Get-Baseline Retrieves the baselines specified by the provided cmdlet parameters.
Get-Compliance Retrieve baseline compliance data for the specified object of type Template, VirtualMachine, VMHost, Cluster, Datacenter, Folder, and VApp. Get-Patch Retrieves all available patches or those specified by the provided cmdlet parameters. Get-PatchBaseline Retrieves all patch baselines or those specified by the provided cmdlet parameters. New-PatchBaseline Creates a new patch baseline. Patch baselines can be applied to either hosts or virtual machines. Depending on the patch criteria you select, patch baselines can be either dynamic or static (fixed). Remediate-Inventory Remediates an inventory object against the specified baselines. Remove-Baseline Deletes the specified baselines from their servers. Before the removal, the baselines are detached from all entities they have been attached to.
Scan-Inventory Scans inventory objects for baselines attached to them. Set-PatchBaseline Modifies the properties of a patch baseline. You can specify explicitly the patches you want to include in the baseline through the IncludePatch parameter. Stage-Patch Initializes staging of patches. Staging allows you to download patches from the Update Manager server to the ESX/ESXi hosts, without applying the patches immediately
Download und mehr Informationen sind hier zu finden: http://communities.vmware.com/
Release Notes gibt es hier: http://communities.vmware.com/docs/DOC-12075
Das online manual gibt es hier: http://www.vmware.com/
Es wird eine Installation von PowerCLI 4 update 1 benötigt, bevor die Update Manager cmdlets installiert werden.
disable Mailbox Script
In vielen Unternehmen wird das Usermanagement von der Unternehmenssoftware (z.B. SAP) zum Teil automatisiert übernommen. Dabei werden die Daten der Mitarbeiter aus der Personalabteilung über die Unternehmenssoftware in das Active Directory eingetragen. Dafür gibt es unter anderem den Identity Manager von Microsoft, was aber nicht jetzt Thema sein soll. Beim Ausscheiden von Mitarbeitern tun sich da unter Umständen aber ein paar Lücken auf die man eigentlich vermeiden will.
In einigen Unternehmen gibt es die Policy, dass die Useraccounts nach dem Ausscheiden deaktiviert aufbewahrt werden und erst nach einer bestimmten Frist (z.B. 90 Tage) gelöscht werden. Wenn ein Useraccount deaktiviert wurde, hat der Mitarbeiter eigentlich kein Zugriff auf Daten und Dienste mehr.
Wenn wir uns in der Situation einmal nur auf Exchange und die User Mailbox konzentrieren, müssen wir leider feststellen, dass die Aussage nicht ganz zutrifft. Der Mitarbeiter hat in der Tat nach seinem Ausscheiden mit deaktiviertem Useraccount kein direkten Zugriff mehr auf seine Mails, aber seine Mailbox existiert weiterhin und stellt den gesamten Funktionsumfang bereit. Hat der Mitarbeiter vor seinem Ausscheiden eine Weiterleitung an eine externe Mailadresse eingerichtet, so erhält er nach dem Ausscheiden auch weiterhin jede interne Mail an seine externe Adresse.
Wie kann das vermieden werden?
Ich haben seit einiger Zeit ein Script im Einsatz, welches alle Mailboxen trennt, dessen Mitarbeiter ausgeschieden sind. Aus der Unternehmenssoftware (z.B. SAP) heraus wird der Account des Mitarbeiters deaktiviert wenn dessen Vertragsverhältnis endet. An jeden 1. des Monats läuft das Script durch und überprüft alle Accounts nach diesen deaktivierten Mitarbeitern. Dazu ist in der Abfrage von "get-qaduser" die zu durchsuchende OU vorgegeben und es werden alle Resource Mailbox (Räume und Geräte) heraus gefiltert. Dieser Filter kann mit der Variable $filter in Zeile 36 beliebig angepasst werden. Bei den zurückgegebenen Accounts wird dann noch geprüft, welcher Account eine Mailbox hat. Dazu habe ich den Wert im Feld "SamAccountName" verwendet und an "get-user" übergeben. Das Ergebnis wird dann dazu verwendet, um mit "disable-mailbox" die Mailbox zu trennen.
Systemvoraussetzungen
Für den Einsatz dieses Scriptes ist die PowerShell und das entsprechende Exchange Management PowerShell Snapin der Serverversion von Nöten. Darüber hinaus wird die Quest ActiveRoles Management Shell for Active Directory 1.3 oder höher benötigt. Dieses Snapin ist noch aus älteren Zeiten, als es noch kein Active Directory Support für die PowerShell von Microsoft gab. Wer eine Domain auf Windows Server 2008 R2 betreibt kann auch das Active Directory Snapin von Microsoft verwenden. Und nicht vergessen, es müssen auch die entsprechenden Rechte vorhanden sein, um eine Mailbox trennen zu können.
Das Script sieht dann so aus:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 | ############################################################## # # # Script to disable all Mailboxes of disabled Useraccounts # # # # Nico Wieczorek 02.02.2009 # # # ############################################################## #First, findout if Exchange Management Shell is loaded: $snapins = Get-PSSnapin |select name $snapincount = 0; $found = $false do { $founDName = $snapins[$snapincount].name switch ($founDName) { "Microsoft.Exchange.Management.PowerShell.Admin" {$found = $True; break} "Quest.ActiveRoles.ADManagement" {$found = $True; break} #Exchange Shell already loaded } $snapincount ++ } while ($snapincount -lt $snapins.Count) $date = ( get-date ).ToString('dd-MM-yyyy') $file = New-Item -type file "E:\Exchange\Scripts\output\$date-DisabledMailbox.csv" -force if ($found -ne $True) { Add-PSSnapin "Microsoft.Exchange.Management.PowerShell.Admin" Add-PSSnapin "Quest.ActiveRoles.ADManagement" } $AllUsers = @() $filter = "(!(|(mailnickname=confroom*)(mailnickname=car*)(mailnickname=handy*)(mailnickname=beamer*)))" $ou = "berlin.testing.local/Accounts" foreach ($objItem in Get-QADUser -Disabled -SearchRoot $ou -LdapFilter $filter) { foreach ($User in Get-User -Identity $objItem.SamAccountName -OrganizationalUnit $ou | where {$_.RecipientType -eq "UserMailbox"}) { $Datenbank = Get-Mailbox -Identity $User.Name Disable-Mailbox -Identity $User.DistinguishedName -confirm:$false $ReturnedObj = New-Object PSObject $ReturnedObj | Add-Member NoteProperty -Name "Nutzer" -Value $User $ReturnedObj | Add-Member NoteProperty -Name "Datenbank" -Value $Datenbank.Database $ReturnedObj | Add-Member NoteProperty -Name "Ablaufdatum" -Value $objItem.AccountExpires $AllUsers += $ReturnedObj } } $AllUsers function sendmail([string] $body) { $SmtpClient = new-object system.net.mail.smtpClient $MailMessage = New-Object system.net.mail.mailmessage $SmtpClient.Host = "mail.testing.local" $mailmessage.from = "exchange@testing.local" $mailmessage.To.add("support@testing.local") $mailmessage.Subject = "Disabled Mailbox Report" $mailmessage.Body = $body $MailMessage.IsBodyHtml = $TRUE $smtpclient.Send($mailmessage) } $AllUsers |export-csv $file -NoTypeInformation $body = "Disabled Mailbox report for $date <br><br><br> folgende Mailboxen wurden deaktiviert: " $bodydetail = $AllUsers |sort-object "Nutzer" |convertto-html $body = $body + $bodydetail sendmail $body |
Aus 2x 2GB RAM werden 3GB
Notebooks wurden und werden seit bestimmt gut vier Jahren mit Hardware-Architekturen gebaut und verkauft, die in den allermeisten Fällen bis zu 4 Gigabyte Arbeitsspeicher zulassen. Das wird dem Käufer zumindest erzählt. Meistens sind nur 1 GB bis 2 GB verbaut, aber aufrüstbar sind die meisten angeblich bis zu 4 GB.
Bisher reichten mir die 1 GB in meinem IBM/Lenovo T60 auch - allerdings fand ich die Verwendung von Windows 7 als 64bit-Version ganz interessant. Und da ein 64bit-OS auch mehr als 3,5 GB adressieren kann, habe ich den aktuellen Preisverfall genutzt und mir spontan 4 GB reingesteckt.
Was ich hätte bleiben lassen können. Im Bios noch als 4 GB erkannt, war mit Windows und Ubuntu Linux dann plötzlich Schluss mit lustig. 3070 MB - mehr war nicht rauszuholen.
Der Hersteller meines Geräts gibt, da habe ich mich nicht getäuscht, offiziell im Datenblatt und auch noch einmal gesondert "up to 4 GB" an. Um auf Nummer Sicher zu gehen habe ich dann auch nochmal die Hotline bemüht - Aussage: muss funktionieren, wenn nicht ist Microsoft schuld. *super*
Aufklärung brachte dann folgendes Posting in einem Forum:
"Maximum memory capacity may require the replacement of standard component with largest supported component available. On ThinkPad systems with an Intel 945GM, 945PM, GM965, or PM965 chipset, even though it is possible to physically install 4GB of memory, the actual amount of memory addressable by an operating system will be limited to 3GB. This limitation does not exist with the Intel GM965 and PM965 with the 64-bit operating systems Windows XP Professional 64-bit and Windows Vista 64-bit Editions."
Auf Deutsch: es ist abhängig vom verwendeten Chipsatz. Da meins einen aus der ersten Auflistung enthält, war der Ofen damit aus.
Das betrifft übrigens nicht nur IBM/Lenovo, sondern z.B. auch HP und sogar MacBooks, die hier ebenfalls bewusst oder unbewusst mit falschen Aussagen werben. Erst bei neueren Modellen wird auf den Missstand hingewiesen (aber erst im vorletzten Absatz des "Kleingedruckten").
Also auch bei aktuellen Modellen lieber zweimal hinschauen.
Windows Updates mittels WuInstall automatisieren
Die Aktualisierung von Windows und Microsoft Software stellt so manchen Administrator vor einige Herrausforderungen z.B. nach der Betriebssysteminstallation das System in einem Rutsch auf den aktuellen Stand zu bringen. Da verspricht das Tool WuInstall der Firma hs²n abhilfe zu schaffen.
Warum WuInstall?
Das Aktualisieren von Windows-Systemen gehört zu den Routineaufgaben eines Administrators, üblicherweise erledigt durch automatisierte Updates mit oder ohne WSUS. Für den User bedeutet die Aktualisierung des Betriebssystems nicht nur am Microsoft Patch Day Verzögerungen: der langwierige Prozess durch sukzessives Abfragen der Windows Updates und oftmals erforderlichen Neustarts stört während der Arbeit. „Unsere Fragestellung war daher: wie kann man den gesamten Update-Ablauf benutzerfreundlicher machen. Mit WuInstall haben wir ein kleinen Tool entwickelt, das diese Anforderungen erfüllt“, so Ing. Markus Huber, Entwickler von WuInstall.
Was ist WuInstall genau?
WuInstall ist ein Kommandozeilen-Tool, mit dem ein Administrator (oder auch ein User) Windows-Updates für eine Workstation kontrolliert über die Kommandozeile durchführen kann, ohne dafür das Windows-GUI benutzen zu müssen. Es ist also ideal für automatisierte Updates oder für User, die das automatische Windows-Update ausgeschaltet haben.
Die Funktionalität ist grob vergleichbar mit dem „apt-get update/upgrade“ Befehl in Linux, für den es bisher kein Windows-Äquivalent gab. WuInstall nutzt die Windows-Update API und sucht auf dem Microsoft-Update Server bzw. auf dem internen WSUS-Server (je nach Systemkonfiguration) nach den momentan verfügbaren Updates für eine Workstation, läd diese herunter bzw. installiert sie bei Bedarf. Der Zeitpunkt wann nach Updates gesucht wird und wann diese installiert werden, kann frei festgelegt werden. Zum Beispiel lässt sich WuInstall beim Login- oder Shutdown Script einbinden, um danach mit einem sicheren PC ungestört arbeiten zu können. WuInstall wird außerdem eingesetzt, um neu aufgesetzte PCs initial auf den neuesten Patch-Stand zu bringen.
Wie sieht das in der Praxis aus?
Wie anfangs schon erwähnt, ist es eine Herrausforderung ein System nach der Installation möglichst in einem Rutsch mit allen nötigen Patches auszustatten und alles automatisiert natürlich. Ich gehe davon aus, dass in Unternehmen heut zu Tage ein Softwareverteilunssystem für die Installation und Pflege von Betriebssystem und Software eingesetzt wird (z.B. System Center Configuration Manager von Microsoft oder Empirum von Matrix42).
Bisher habe ich nach dem Installationsprozess des Betriebssystems erst den WSUS-Client mittels eines kleinen Scripts zum Update seines Kataloges gezwungen.
ForceWSUSUpdate.cmd
====================================================
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | @echo off Echo Erzwingen von automatischen Updates : Echo 1. Stoppen des Automatic Updates Service (wuauserv) net stop wuauserv Echo 2. Löschen des LastWaitTimeout registry key REG DELETE "HKLM\Software\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update" /v LastWaitTimeout /f Echo 3. Löschen des DetectionStartTime registry key REG DELETE "HKLM\Software\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update" /v DetectionStartTime /f Echo 4. Löschen des NextDetectionTime registry key Reg Delete "HKLM\Software\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update" /v NextDetectionTime /f Echo 5. Neustart des Updates Service net start wuauserv Echo 6. Erkennung erzwingen wuauclt /detectnow Echo Der Client prüft nun ob neue Updates vorliegen. |
Quelle: Admin-Tipps.de
Und danach musste ein eigenes VBScript ausgeführt werden, was die GUI Interaktion simuliert und den WSUS-Client dazu bringt alle anstehenden Updates zu installieren. Es kam aber immer wieder vor, dass es Probleme mit dem Windows Script Host gab, weil Nutzer ihn abgeschalten haben oder installierte Anwendungen ihn manipulieren. Leider funktioniert dieses VBScript auch nicht mehr unter Windows 7, was mich auf die Suche nach einer neuen Lösung brachte.
Eher durch Zufall bin ich auf das Tool WuInstall von hs²n gestoßen und erkannte recht schnell das große Potenzial dieses kleinen Kommandozeilen-Tools.
Der einfache Aufruf
WuInstall /install /autoaccepteula
sorgt durch "/install" dafür, dass der WSUS-Client nach neuen Updates sucht, sie herunterläd und dann installiert, sollte ein Update eine EULA Bestätigung verlangen wird mit "/autoaccepteula" diese automatisch ohne Nutzerinteraktion bestätigt. Weitere Switches sind im HowTo von WuInstall dokumentiert. Damit können durch dieses Tool die alten Skripte endlich abgelöst werden.
Lizensierung
Das Tool WuInstall ist in zwei Versionen verfügbar. WuInstall 1.2. PRO ist kostenpflichtig, mit einer Lizenz ist man autorisiert das Tool auf 5 Servern und 50 Workstations zu verwenden, im nicht-kommerziellen Bereich (für öffentliche Institutionen) ist die Anzahl unlimitiert. Die vereinfachte Version 1.1. liegt als Freeware vor.
Feature-Umfang WuInstall 1.2. PRO
Der Hauptvorteil von WuInstall 1.2. PRO gegenüber der Freeware Version ist, dass man Updates filtern kann und entscheiden welche Updates installiert werden sollen, zum Beispiel abhängig von den Severity Levels (critical, important, moderate, low) oder der Klassifizierung (critical updates, updates, update rollups, security updates, service packs, feature packs). Ein weiteres praktisches Feature ist die Suche innerhalb der Updates, zum Beispiel nach Produktnamen. Der Installationsfortschritt lässt sich anzeigen. Der gesamte Prozess kann in Logfiles mitprotokolliert werden. Es besteht die Möglichkeit den WSUS Server zu umgehen, um beispielsweise nach der Verfügbarkeit von einem bestimmten Patch, der noch nicht auf den WSUS Server heruntergeladen wurde, zu suchen. Das automatische bestätigen von EULAs bleibt auch der PRO Version vorbehalten.
Also kurz susammen gefasst, ist das Tool WuInstall eine echte Arbeitshilfe und sein Einsatz ist vielseitig. Ich habe in meinem Praxisbeispiel gezeigt, dass der Einsatz beim Betriebssystem Rollout zum Sicherheits- und Komforgewinn werden kann. Man ist so in der Lage in kürzester Zeit ein System durchgepatched an den Kunden auszuliefern.
alle Mailboxen weg, was tun?
Man stelle sich vor, von einer Minute zur anderen sind alle Postfächer nicht mehr vorhanden. Das klingt nach dem Supergau, aber es muss nicht immer so schlimm sein, wie es auf den ersten Blick aussieht.
Es kann sein, dass durch ein Bedienfehler oder falsches Skript alle Mailboxen deaktiviert oder getrennt werden, aber in der Datenbank noch vorhanden sind. Leider sind in größeren Umgebungen die Mailboxen anfangs (noch) nicht als deaktiviert sichtbar und man fängt an zu glauben, dass die Mailboxen ganz verloren sind. Das ist bei Exchange aber relativ unwarscheinlich, viel realistischer ist die Warscheinlichkeit, dass die Datenbanktransaktion noch nicht vollständig gelaufen ist. Dabei kann es vorkommen, dass nicht alle Mailboxen als getrennt (disconnect) gekennzeichnet werden. Dies kann mittels dem Cmdlet 'Clean-MailboxDatabase' erzwungen werden. Danach sind alle getrennten Mailboxen in der Datenbank auffindbar und man kann sie wieder verbinden.
Sollten durch irgend einen Fehler alle Mailboxen getrennt werden, so kann man mit folgenden Befehlen den Feierabend retten:
Get-MailboxDatabase | Clean-MailboxDatabase $getback = Get-MailboxStatistics -Server <ServerName> | where { $_.DisconnectDate -ne $null } Enable-Mailbox -Identity $getback.DisplayName -Database $getback.Database