Im Verlauf einer Migration von SBS2003 nach SBS2008 habe ich vergessen das DFS zu migrieren. Das wäre verhältnismäßig einfach gewesen, da dazu lediglich folgende Schritte notwendig sind:

1. Auf dem neuen SBS 2008 ein Verzeichnis für einen DFS Root anlegen. z.B. D:DFSRootsdfs
2. den SBS 2008 der bestehenden DFS Topologie als weiteren DFS Server hinzufügen und fertig

Aber wie schon gesagt, habe ich vergessen … Danach wollte ich nun auf dem neuen SBS2008 ein DFS in der Domain anlegen welches den gleichen Namen hat und habe folgende Fehlermeldung bekommen:

Im DFS Management selbst dazu ebenfalls die gleiche Meldung wenn ich mich auf den DFS Namespace verbinden wollte. Also muss der “alte” DFS Namespace noch irgendwo rumgeistern. Das ganze läßt sie durch die Verwendung von ADSIEDIT und DFSUTIL in den Griff bekommen.

Dazu einfach folgende Schritte durchführen:

1. Auf dem SBS2008 ADSIEDIT starten und auf den Default Naming Context verbinden
2. Nun folgenden Pfad im Schema durchgehen DC=Domain, DC=Tld und CN=System, CD=DFS-Configuration und dort den alten DFS Namespace Eintrag löschen. Bei mir war das CN=DFS…
3. Da der SBS in der Regel als Single DC betrieben wird, braucht man auf eine Replikation keine Rücksicht zu nehmen
4. Nun noch mit DFSUTIL noch die Caches löschen:

   dfsutil cache domain flush
   dfsutil cache referral flush
   dfsutil cache provider flush

So, nun läßt sich der DFS Namespace wie gewollt anlegen.

Cheers, b!

Nach einer Umstellung von SBS2003 auf SBS2008 ist mir aufgefallen, dass NEU angelegte Benutzer (die nach der Umstellung angelegt wurden) nicht im Globalen Adressbuch (Global Address Book) von Outlook auftauchen. Einer Kontrolle des “Microsoft Exchange Address Book Providers” Eintrags in Outlook zeigte, dass der Pfad für den aktuellen Server nicht auf den FQDN des Servers zeigt sondern auf ein lokales Verzeichnis:

Der Pfad läßt sich übrigens mit Copy+Past aus dem Menü kopieren und danach über den Explorer oder an der Eingabeaufforderung öffnen. Folgt man diesem Pfad gelangt man in ein Verzeichnis welches eine Kopie der GAL enthält welche um Datum der Umstellung her rührt.

Schließt man Outlook und benennt die Dateien um, so wird beim nächsten Start von Outlook der Eintrag korrekt angepaßt (wie im nächsten Bild zu sehen):

Der Eintrag ist übrigens über das Adressbuch/Extras/Optionen erreichbar.

Cheers b!

Da der SBS2008 nicht mehr auf 32Bit sondern (zum Glück) nur noch auf 64Bit geliefert wird, stellt einen die Installation von Druckern nun vor neue Herausforderungen. Unter einem 64Bit Windows Betriebssystem, muss nämlich zuerst ein 64Bit Druckertreiber installiert werden und danach (da die Clients in der Regeln noch 32Bit sind) das entsprechende 32Bit Pendant dazu.

Ich hatte kürzlich das Problem mit einem neu erworbenem Lexmark x544 XL dahin gehend, dass beim hinzufügen des 32Bit Druckertreibers folgender Dialog erschien:

An dieser Stelle wird bei weitem nicht irgendein Medium (sprich DVD oder CD) von Windows Server 2008 angefordert, sondern einfach nach der NTprint.inf gesucht! Diese ist bei Lexmark im 32Bit Treiber auch mit dabei, allerdings nicht im Verzeichnis des Treibers selbst sondern in diesem Fall (und das ist oft bei anderen Lexmark Druckern auch so) in einem i386 genannten Unterverzeichnis. Wird auf dieses im Dialog verwiesen lässt sich der 32Bit Treiber problemlos nachinstallieren.

Hier die beiden Pfade des entpackten Treibers:

Verwendet wurden übrigens diese beiden folgenden Pakete, wobei der 64Bit Treiber als erstes installiert wurde (es ist ja auch ein 64Bit Server):

• Lexmark_X543_X544_X546_ACB_Win_32_PCL_XL_Emul.exe
• Lexmark_X543_X544_X546_ACB_Win_64_PCL_XL_Emul.exe

Was am Ende noch den Hinweis übrig lässt, dass die Treiber gleich bzgl. der verwendeten INF Datei sein müssen. Findet man übrigens bei Lexmark Deutschland (http://www.lexmark.de) nicht das passende Treiber-Paar, so lohnt sich ein Blick über den Teich: http://www.lexmark.com … da wird ihnen geholfen J

Cheers, b!

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

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:

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

Cheers, b!

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

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!

Für die SBS Migratoren, welche einen bestehenden Small Business Server 2003 auf 2008 umziehen müssen gibt es von Microsoft eine gut gemachte Demo.

http://www.microsoft.com/downloads/details.aspx?FamilyID=31D3F757-9118-4F12-9DB2-296C4729CD5E&displaylang=en&displaylang=en 

Cheers, b!

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!