Ich habe meinen seit gut 6 Jahren laufenden Small Business Server 2003 auf Windows Small Business Server 2008 Premium umgestellt. In diesem Zuge sind mir ein paar Dinge aufgefallen welche ich in kommenden Blogs posten werde. Starten möchte ich mit einen Problem welches sich nach der Migration eingestellt hat.

Der SMTP Service des Small Business Servers wurde von bisher genutzt, um Meldungen von Hardware zu versenden. z.B. sind Raid-Controller, aber auch Router, USVs und verschiedene Switches in der Lage basierend auf Ereignissen Emails zu versenden. Unglücklicher Weise kann in der Konfiguration oftmals kein Benutzer bzw. eine entsprechende Verschlüsselung angegeben werden. Das Device geht davon aus, dass der SMTP-Server die Mail ohne eine Prüfung annimmt, was unter dem SBS 2008 nicht mehr so ohne weiteres funktioniert.

Um diese Funktionalität wieder bereit zu stellen muss ein zusätzlicher Receive Connector im Exchange erstellt werden, und das geht wie folgt:

1. Start der Exchange Management Console
2. Öffnen von Microsoft Exchange/Server Configuration/Hub Transport
3. Wechsel in das Fenster Receive Connectors
4. Rechte Maustaste und aus dem Kontext Menü New Receive Connector … wählen
5. Als Name habe ich Windows SBS Hardware Monitoring gewählt
6. In den Properties unter Network stehen dann die IP-Adressen der Hardware Devices unter der Option Receive mail from remote servers that have these IP addresses:

   

7. Zusätzlich muss noch die Authentification angepasst werden, da die Hardware in der Regel (leider) keine Authentifizierungsmechanismen unterstützt habe ich alle leer gelassen

   

8. Zum Schluss noch als Permissions Groups Anonymous users ausgewählt und die Sache mit OK bestätigt
9. Damit das nun funktioniert muss noch in der Exchange Management Shell (Powershell) folgender Aufruf abgesetzt werden:

   Get-ReceiveConnector "Windows SBS Hardware Monitoring" | Add-ADPermission -User "NT AUTHORITYANONYMOUS LOGON" -ExtendedRights "ms-Exch-SMTP-Accept-Any-Recipient"

So, nun meldet die Hardware wieder artig was im Netz so vorsich geht 🙂

Cheers, b!

In meinem Kleinst-Rechenzentrum (KRZ) laufen 2 Server zur Virtualisierung mit Hyper-V R2. Der eine mit Microsoft Hyper-V Server R2, der andere mit Windows Server 2008 R2 Standard. Der Microsoft Hyper-V Server R2, hat einen deutlich geringeren “Footprint” als ein normaler Windows Server da ihn einige Dinge wie z.B. der Windows Explorer (lokale grafische Oberfläche), Internet Explorer, etc. fehlen.

Hier der Link zu Microsoft und dem Hyper-V R2 Server: http://www.microsoft.com/germany/server/hyper-v-server/default.mspx

Eine Abfrage der Systemlaufzeit mit psinfo.exe aus der Sysinternals Suite hat gezeigt, dass beide Server seit 66 bzw. 67 Tagen am laufen sind – also nicht neu gestartet werden mussten. Was mich dahin überrascht, da vergleichbare Windows Server 2003 basierende Systeme durch die häufigen Updates öfters einen Neustart durchführen müssen. In diesem Blogeintrag werde ich nun in losen Abständen die System Uptime beider Server veröffentlichen – um ein Gefühl dafür zu bekommen ob sich der geringere Footprint des Microsoft Hyper-V Servers R2 gegenüber den Windows Server 2008 R2 Standard bzgl. der Updates positiv auswirkt.

Hier also die Stände:

20.01.2010, 05:56

   1: System information for \jura:

   2: Uptime:                    66 days 16 hours 8 minutes 18 seconds

   3: Kernel version:            Hyper-V Server, Multiprocessor Free

   4: Product type:              Server

   5: Product version:           6.1

   1: System information for \cnoc:

   2: Uptime:                    67 days 8 hours 13 minutes 18 seconds

   3: Kernel version:            Windows Server 2008 R2 Standard, Multiprocessor Free

   4: Product type:              Server

   5: Product version:           6.1 

Update 25.01.2010, 05:57 – so schnell kann es gehen …

   1: System information for \jura:

   2: Uptime:                    71 days 16 hours 20 minutes 56 seconds

   3: Kernel version:            Hyper-V Server, Multiprocessor Free

   4: Product type:              Server

   5: Product version:           6.1

   1: System information for \cnoc:

   2: Uptime:                    1 day 14 hours 45 minutes 10 seconds

   3: Kernel version:            Windows Server 2008 R2 Standard, Multiprocessor Free

   4: Product type:              Server

   5: Product version:           6.1 

Update: 09.02.2010, 16:10 – ok, letzten Dienstag war Patchday mit 5 Fixes … das war es dann auch für die Hyper-V Maschine

   1: System information for \jura:

   2: Uptime:                    88 days 2 hours 9 minutes 56 seconds

   3: Kernel version:            Hyper-V Server, Multiprocessor Free

   4: Product type:              Server

   5: Product version:           6.1

… dann habe ich den Server wegen der notwendigen Sicherheitsupdates neu gestartet.

Cheers, b!

oder: where the rubber meets the ground …

Mit Windows Server 2008 R2 hat Microsoft Verbesserungen in der Energieverwaltung (Powermanagement) des Betriebssystems vorgenommen. Weitere Informationen dazu gibt es hier: http://www.microsoft.com/windowsserver2008/en/us/r2-management.aspx

Nun werden in letzter Zeit viele Messungen und theoretische Annahmen zu diesem Thema getroffen. Doch wie heißt es so schön: Grau ist alle Theorie … 🙂

Im Zuge des ohnehin notwendigen Upgrades meiner beiden Hyper-V Server auf Hyper-V R2 habe ich die verwendete Leistungsaufnahme vor dem Upgrade (Windows Server 2008) und nach dem Upgrade (Windows Server 2008 R2) beobachtet. Als grober aber in diesem Fall durchaus sachdienlicher Indikator über eine verringerte Leistungsaufnahme hat mir meine USV gedient. Diese liefert zwar nur “ganzzahlige” Werte, aber diese dafür im Minutentakt.

Die Ausstattung der Server lassen wir mal an dieser Stelle außer Acht. Wichtig ist aber, dass unter Windows Server 2008 die gleiche Anzahl der virtuellen Maschinen in Betrieb waren wie nach dem Upgrade auf Windows Server 2008 R2.

Das Ergebnis lässt sich recht einfach darstellen:

Windows Server 2008: 700W, 23% Auslastung der USV (18 laufende VMs)

Windows Server 2008 R2: 500W, 21% Auslastung der USV (18 laufende VMs)

Interessant war für mich noch, dass wenn ich z.B. 4 VMs gleichzeitig starte die Auslastung auf 600W hoch geht und sich danach (da die VMs meistens wenig zu tun haben) auf die überwiegend vorhandenen 500W einregelt.

Cheers, b!

p.s.: Als Betriebssystem wurde immer Microsoft Hyper-V Server bzw. nach dem Upgrade Microsoft Hyper-V Server R2 verwendet!

Mit Windows 7 (Windows Server 2008 R2 und Microsoft Hyper-V Server R2 eingeschlossen), besteht die Möglichkeit ein Betriebssystem anstatt von einer physikalischen Festplatte aus einer VHD (Virtual Hard Disk) zu starten.

Da ich einen kleinen Testcluster mit Windows Server 2008 R2 habe und mir das ständige Hantieren mit Festplatten zum ausprobieren von Betriebssystemen sparen wollte dachte ich mir, einfach nochmals zwei weitere OSe von VHD zu starten (booten).

Die Ausgangslage ist also Windows Server 2008 R2 Enterprise Editon installiert auf einer 250GB großen Festplatte. Als Wunschkonfiguration stelle ich mir folgende Kombination vor:

1. Windows Server 2008 R2 Enterprise Edition (Festplatte)
2. Microsoft Hyper-V Server 2008 R2 (VHD) – Cluster Node (mit 15GB VHD)
3. Microsoft Hyper-V Server 2008 R2 (VHD) – Stand alone (mit 15GB VHD)

Damit das klappt sind folgende Schritte notwendig:

1. Nach einlegen der Microsoft Hyper-V Server 2008 R2 DVD ist es notwendig, sobald der Installationsbildschirm erscheint, eine Eingabeaufforderung zu öffnen, was mit Shift+F10 passiert. Es ist übrigens gleichgültig zu welchem Zeitpunkt das passiert, nach meiner Erfahrung sollte man das Setup soweit vorantreiben bis die Option zur Auswahl des Tastatur-Layouts durchlaufen ist (dann hat man nämlich die richtige Sprache eingestellt und kämpft nicht mehr mit den Sonderzeichen herum). Selbst wenn der Auswahldialog zur Installation auf den Datenträger kommt, kann immer noch mit Shift+F10 die Eingabeaufforderung geöffnet , die VHD erstellt und dann mit Refresh/Aktualisieren im Auswahlmenü angezeigt werden.
2. In diesem schwarzen Fenster legt man nun (abhängig wo die Boot VHDs liegen sollen) das entsprechende Verzeichnis dazu an. Da ich nicht zu den “Rootinstallierern” gehöre, sollen die VHDs unter Users\Public\vboot liegen und den Namen der darauf zu installierenden Server erhalten.
3. Achtung: Das sonst als Laufwerk C: sichtbare SystemDrive wird von Diskpart als Laufwerk D: angezeigt, da die seit Windows 7 vorhandene 100MB große System Reserved Partition den Bezeichner C: erhält. Nachher ist natürlich wieder alles wie es war – aber die VHDs müssen nun eben auf D: und nicht auf C: angelegt werden.
4. Nachdem nun die Eingabeaufforderung (oder der Command Prompt) geöffnet ist erstellen wir als erstes das für die VHDs vorgesehene Verzeichnis

   md d:\users\public\vboot

   und rufen im Anschluss diskpart auf. Im nun folgenden “interaktiven” Modus von Diskpart erstellen wir eine fixed VHD von 15GB mit folgendem Befehl:

   create vdisk file=d:\users\public\vboot\clabhv11.vhd type=fixed maximum=15000
   
   da das erstellen einer fixed Disk mit diskpart seine Zeit dauert, kann hier auch zu einer Alternative gegriffen werden: das VhdTool von Chris Eck

   http://code.msdn.microsoft.com/vhdtool

   damit erstellt man eine VHD alternativ mit folgendem Aufruf:

   VhdTool.exe /create „d:\users\public\vboot\clabhv11.vhd“ 16106127360

   und binden diese VHD in das Auswahlmenü zur Installation ein, bzw. als Bootoption in die Boot Configuration Database (BCD)

   select vdisk file=d:\users\public\vboot\clabhv11.vhd
   attach vdisk
   

5. Diese Disk wählen wir dann zur Installation des Microsoft Hyper-V Server R2 aus. Dabei erscheint folgende Meldung:

   Windows cannot be installed on this disk. (Show details)

   welche wir geflissentlich übergehen 🙂

Eigentlich sind wir nun fertig, allerdings gibt es noch ein paar kosmetische Dinge welche getan werden sollten um das Arbeiten zu erleichtern.

• Setzen der auf der Festplatte befindlichen Windows Server 2008 R2 Installation als Default beim Systemstart

  C:\Users\xxx>bcdedit /default {identifier der Windows Server 2008 R2 EE Installation}

• Umbenennen des Eintrags zum booten des Microsoft Hyper-V R2 Cluster Nodes

  C:\Users\xxx>bcdedit /set {current} description „Microsoft Hyper-V Server 2008 R2 – Cluster“

Für die Standalone-Installation des Microsoft Hyper-V Servers 2008 R2 wiederholen wir die Prozedere.

Cheers, b!

Der Umzug erfolgt auf dem gleichen Server in eine andere Instanz: Migration von der internen Datenbank auf einen SQL Server

Neulich habe ich festgestellt, dass auf meinem Small Business Server 2003 (SBS) der WSUS (Windows Server Update Service) die Windows Internal Database verwendet. Also eine separate SQL Instanz extra für diesen Dienst ausgeführt wird. Da auf dem SBS ohnehin eine SQL Server 2005 Instanz ausgeführt wird, habe ich mich kurzer Hand entschlossen die WSUS Datenbank dorthin zu migrieren. Dazu waren folgende Schritte notwendig:

1. Stopp folgender Dienste (in der Services.msc oder mit net stop)

   Update Service
   Windows Internal Database

2. Kopieren der SUSDB.mdf und SUSDB_log.ldf aus dem WSUSUpdateServicesDbFiles Verzeichnis in das Data-Verzeichnis der SQL 2005 Installation. In meinem Fall war das

   xcopy D:\Apps\WSUS\UpdateServicesDbFiles\SUSDB* “D:\Apps\SQL Server\MSSQL.1MSSQL\Data” /v

3. Anfügen der SUSDB im SQL Server 2005 Management Studio Express durch einen Klick mit der rechten Maustaste auf Datenbanken und Anfügen hier dann die SUSDB.mdf auswählen
4. Öffnen des Registry Editors und ändern des folgenden Eintrags:

   HKLM\SOFTWARE\Microsoft\Update Services\Server\Setup\SqlServerName

   auf den neuen Datenbank-Server. In meinem Fall war das die Instanz I01 auf dem gleichen System, somit also

   %computername%\I01

5. Nun einfach wieder den WSUS (Update Service) starten
6. und zum Abschluss über die Systemsteuerung/Software die Windows Internal Database deinstallieren

Habe fertig 🙂 Ich bin mir nun nicht 100% ob das ein von Microsoft unterstütztes Vorgehen ist, hat bei mir aber ohne Probleme funktioniert. Experimente erfolgen natürlich immer auf eigenes Risiko.

Cheers, b!

Man geht ja mit der Zeit, und so habe ich den Entschluss gefasst meinen Desktop Rechner (Dell Dimension 9200 mit Intel P965 Chipsatz) auf Windows 7 x64 Ultimate umzustellen. Die Installation verlief an sich problemlos, nach knapp einer Stunde stand das neue Windows 7 System bereit zur Anmeldung.

Ein obligatorischer Check im Gerätemanager offenbarte ein “Unkown Device” mit der Device Instance ID “ACPIAWY0001”.

1. Mein erster Versuch war einfach das Gerät zu deinstallieren, leider ohne Erfolg – nach einem Scan for Hardware changes im Device Manager war der Eintrag wieder da
2. Der nächste Schritt war die Suche nach einem gültigen Treiber in Windows Update – leider auch ohne Erfolg
3. Als nächsten Schritt habe ich dann mein Verzeichnis mit Windows Vista und Windows Server 2008 Treibern durchsuchen lassen aus dem sich normaler Weise mein Windows Deployment bedient – und siehe da: auf einmal hatte ich einen AMD AwayMode Treiber auf meinem Intel Rechner installiert ?!

Hier ein kleiner Beweis, dass ich keine Märchen erzähle 🙂 – man beachte oben die Intel Core2 CPU und unten, der AMD AwayMode Treiber

Nun war ich der Meinung, dass ich ein Problem haben könnte. Folglich habe ich mich an die Analyse des AMD Treiber Pakets gemacht und in der Tat, in der AMDAway.inf findet sich die passende Device ID … zu meinem Intel Board, bzw. dessen Unknown Device. Im nun folgenden Code einfach nach ACPIAWY0001 suchen 🙂 bzw. Zeile 32 anschauen.

  19: [Manufacturer]

  20: %AMD_MFG% = AWAY_MODE,NTamd64

  25:  

  30: [AWAY_MODE.NTamd64]

  31: %*pnpffff.DeviceDesc% = NULL_DRIVER, *pnpffff

  32: %*pnpffff.DeviceDesc% = NULL_DRIVER, ACPIAWY0001

  33:  

  34: [NULL_DRIVER]

  35:  

  36: [NULL_DRIVER.Services]

  37: AddService = , %SPSVCINST_ASSOCSERVICE%                 ; null service install

  38:  

  39: [Strings]

  40: AMD = "AMD"

  41: AMD_MFG = "AMD"

  42: *pnpffff.DeviceDesc = "AMD AwayMode"

  43:  

  44: ;*******************************************

  45: ;Handy macro substitutions (non-localizable)

  46: ;*******************************************

  47: SPSVCINST_ASSOCSERVICE = 0x00000002

  48:  

Interessant war aber für mich der begleitende Text in der Readme.rtf

“To install the Null INF, copy the installation files to a temporary directory, then use the “Device Manager” to perform an "Update Driver" operation as follows.”

Es handelt sich um einen Null Treiber also einen Treiber der nichts macht außer dieses “Unknown Device” aus dem Device Manager zu entfernen. Nun kam ich auf die Idee, dass es sowas ggf. auch von Intel geben könnte. Eine Suche in meinem Treiber Installationsverzeichnis brachte dann einen zweiten Treiber zum Vorschein, welcher ebenfalls die entsprechende Device ID hatte, es ist der Intel QRT Driver. Ein Blick in die iqrt.inf ergab, dass auch hier ein entsprechender Eintrag vorhanden ist.

  18: [Manufacturer]

  19: %INTEL% = IntelDevice, NTamd64

  20:  

  21: [IntelDevice]

  22: "Intel(r) Quick Resume Technology(r) Driver" = IqrtInstall, ACPIAWY0001

  23:  

  24: [IntelDevice.NTamd64]

  25: "Intel(r) Quick Resume Technology(r) Driver" = IqrtInstall, ACPIAWY0001

(diese inf habe ich unten abgeschnitten ….)

Also habe ich den Intel Treiber dem Device als Update angeboten, welcher auch problemlos installiert wurde. Der Grund wieso bei mir zuerst der AMD Treiber verwendet wurde ist recht einfach – das Verzeichnis mit dem AMD Treiber liegt alphabetisch vor dem mit dem Intel (A vor I) und somit wurde der erste beste (von der ID her passende) genommen.

Nach einiger Recherche im Internet (Bing liefert hier übrigens die besseren Ergebnisse als Google), habe ich herausgefunden das Intel sowie auch AMD auf die PC Hersteller verweisen um diese(n) Treiber zu bekommen. Hier also im Download Bereich nach einem geeigneten Treiber suchen.

Cheers b!

Jedesmal wenn ein Update mit WISO Sparbuch 2009 ansteht bekomme ich folgende Fehlermeldung:

“Lizenzdaten konnten nicht auf Ihrem System geschrieben werden. Bitte überprüfen Sie Ihre Benutzerrechte und melden Sie sich gegebenenfalls als Administrator an.”

Die Behebung des Problem verlief wie folgt:

Da ich die Anwendung mit “als Administrator ausführen” also mit sog. elevated Rights gestartet hatte, dachte ich mir – OK, melde Dich einfach als Administrator an. Leider der selbe Fehler …

Ein Anruf bei der Buhl-Data Hotline ergab, dass mein Rechner “verkonfiguriert sei” und ich diesen neu Installieren muss, dann tut es auch. Für die Kosten der Hotline bekommt man übrigens bei Amazon schon das eine oder andere MP3 File im Download. Die Wartezeit sowohl in der Hotline als auch bei einer Anfrage per Mail liesen mich daran zweifeln das die Steuererklärung dieses Jahr noch fertig wird 😉

Da eine Neuinstallation nicht in Frage kam (meine Systeme laufen generell von der Erstinstallation ab mehrere Jahre) habe ich mit dem Prozess Monitor von Sysinternals mein Glück versucht.

Ein direkter Aufruf ohne Installation ist über http://live.sysinternals.com/procmon.exe möglich, alternativ natürlich das ganze Paket unter http://technet.microsoft.com/de-de/sysinternals/bb896645.aspx runterladen.

So, also den Process Monitor gestartet und danach den Update für das WISO Sparbuch 2009 und siehe da, der Process Monitor zeigte folgende Einträge:

Access denied (Zugriff verweigert) auf das C:\ProgramData\Buhl Data Service GmbH Verzeichnis. In der Tat, auf dieses Verzeichnis hatte nicht einmal der Administrator Zugriff. Also habe ich die lokale Gruppe der Administratoren darauf mit Vollzugriff (Full) berechtigt und seit dem klappts auch mit dem WISO Sparbuch 2009 wieder.

So jetzt muss ich die Steuer machen …. aber das ist ein anderes Thema.

b!