SBS2008: Event ID 17137 im Application-Log

Im Application-Log meines SBS2008 hatte ich folgende Einträge, welche ich einer genaueren Betrachtung unterzogen habe:

image

Ein wenig Recherche im Internet ergibt recht schnell, dass auf der jeweiligen Datenbank die Option Auto Close auf False gesetzt werden muss, damit diese Meldung nicht mehr erscheint.  Die Quelle (Source) welche diesen Eintrag verursacht ist die Windows Internal Database, welche seit Windows Server 2008 vorhanden ist und unter dem SBS2008 für die Bereitstellung einer Reihe von Datenbanken verwendet wird (WSUS, Sharepoint, …).

In meinem Fall konnten die beiden folgenden Datenbanken mit der Meldung in Verbindung gebracht werden:

  1. ShareWebDB
  2. SharePoint_AdminContent_d4e397f2-a27a-48a0-a628-d25db6672bab

Die Änderung der Option kann über das SQL Server Management Studio Express erfolgen, damit man sich aber auf die Windows Internal Database verbinden kann ist es wichtig folgenden String als Servername anzugeben: \.pipeMSSQL$MICROSOFT##SSEEsqlquery

Der Verbindungsdialog sieht damit wie folgt aus:

image

Danach kann in den Eigenschaften (Properties) die Option entsprechend gesetzt werden:

image

Cheers, b!

Powershell Support für Notepad++

Seit dem Release v5.6 besitzt Notepad++ (http://notepad-plus.sourceforge.net/de/site.htm) Support für Powershell.

image

Hier noch der Auszug aus dem Change.log von Notepad++

Notepad++ v5.6 new features and fixed bugs (from v5.5.1) :

1.  Add languages encoding – …
2.  Add auto-detection of HTML and XML files encodings.
3.  Add COBOL, D, Gui4Cli, PowerShell and R language support.
4.  Add Marker Jumper feature (Jump down/up : Ctrl+Num/Ctrl+Shift+Num).
5.  Add indent guide line highlighting for html/xml tags.

Damit sind alle Windows internen Skriptsprachen abgedeckt:

  • Command Line Scripts (cmd, bat)
  • VBScript und Jscript
  • Powershell

Enjoy it, b!

SBS2008: Meine Hardware versendet keine Mails mehr

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:

    image

  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

    image

  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!

Wer sagt den “einen Windows Server muss man oft rebooten”…

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!

Hyper-V Monitor als Windows Gadget

Um meine Hyper-V Umgebung im Auge zu behalten bin ich auf folgendes Gadget gestoßen http://mindre.net/post/Hyper-V-Monitor-Gadget-for-Windows-Sidebar.aspx

Das Gadget kann mehrere Hyper-V Server und die darauf vorhandenen VMs darstellen und (falls aktiviert) die VMs auch starten, stoppen, usw. Darüber hinaus werden für jeden Hyper-V Server die noch verfügbaren Speicherressourcen dargestellt und für die VMs selbst der CPU Verbrauch. Mit der aktuellen Version 5 sind folgende neue Funktionen hinzugekommen:

  • Es wird der Verkauf der CPU Nutzung pro VM angezeigt
  • Wake on LAN support
  • VM RDP (bei Windows Server 2008 R2 als Host)
  • Multilanguage Support

Damit Wake on LAN funktioniert muss noch auf eine Freeware DLL verwendet werden welche unter http://www.depicus.com/wake-on-lan/wake-on-lan-com.aspx erhältlich ist.

Weitere Infos, gibts wie schon oben gepostet auf der Homepage des Autors.

Cheers, b!

image

Erfahrungsbericht: Windows Server 2008 R2 Power Consumption

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!

Boot from VHD mit Windows Server 2008 R2

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!

Umzug der SQL Datenbank von WSUS 3.0

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!

Nikon ViewNX und Windows 7 – das Kontextmenü läßt sich nicht konfigurieren

Mit der Umstellung von Windows Vista auf Windows 7 habe ich auch Nikon ViewNX (1.4.0) als Standard Bildbetrachter für Nikon RAW Dateien eingeführt. Nikon ViewNX bietet über ein Kontextmenü die Weiterverarbeitung von Dateien mit beliebigen definierbaren Anwendungen an. Neben Nikon Capture NX, dass wenn es schon vorhanden ist automatisch eingebunden wird können noch Programme wie Adobe Photoshop usw. konfiguriert werden.

Zur Konfiguration dient dazu im Kontextmenü die Option “Register”, worauf sich ein Dialog öffnet welche wie folgt aussieht:

image

Im Normalfall muss sich nun durch anklicken der Option ”Add …” ein weiteres Kontektmenü öffnen welches Anwendungen vorgibt und zusätzlich durch einen Dateidialog weitere hinzufügen läßt. Das funktioniert allerdings nicht in der Kombination Windows 7 und Nikon ViewNX. Das Anklicken der Option bleibt schlicht weg ohne Aktion.

Ändern läßt sich dieses Verhalten dadurch, dass Nikon ViewNX im Windows XP SP2 Kompatibilitätsmodus betrieben wird. Dieser wird wie folgt konfiguriert.

Auswahl von Start/All Programs/ViewX/ViewNX mit der rechten Maustaste und hier die Option Properties auswählen. Nun kann unter dem Reiter Compatibilitz der Windows XP (Service Pack 2) Kompatibilitätsmodus ausgewählt werden, zusätzlich unter Verwendung hinreichender Administrativer Berechtigungen auch für alle Benutzer durch die Option Change settings for all users für alle Benutzer.

Danach funktioniert der Dialog ohne Probleme ….

image

Update 1 vom 27.11.2009:

Gestern hat Nikon die Version 1.5.0 von ViewNX herausgebracht, welche auch Windows Vista x64 unterstützt. Insofern habe ich es “gewagt” diese Version auch unter Windows 7 x64 in Einsatz zu bringen. Das oben beschriebene Verhalten ist nicht mehr vorhanden – die Anwendung funktioniert wie erwartet. Also, ASAP updaten ….

Cheers, b!