Mike Harder's Blog

Beim Small Business Server 2003 kann es schon mal vorkommen, das wenn man sich anmeldet, einen gleich mal ein paar Fehlermeldungen anspringen, das die Datei mssbsssr.exe einen Fehler verursacht hat und beendet wurde.

Im Eventlog ist dann folgender Eintrag vorhanden:

Event Type:    Error
Event Source:    Application Error
Event Category:    (100)
Event ID:    1000
Date:        29.01.2011
Time:        19:19:35
User:        N/A
Computer:    <computer>
Description:
Faulting application mssbsssr.exe, version 5.2.2651.0, faulting module msvcrt.dll, version 7.0.3790.3959, fault address 0x0003450e.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
Data:
0000: 41 70 70 6c 69 63 61 74   Applicat
0008: 69 6f 6e 20 46 61 69 6c   ion Fail
0010: 75 72 65 20 20 6d 73 73   ure  mss
0018: 62 73 73 73 72 2e 65 78   bsssr.ex
0020: 65 20 35 2e 32 2e 32 36   e 5.2.26
0028: 35 31 2e 30 20 69 6e 20   51.0 in
0030: 6d 73 76 63 72 74 2e 64   msvcrt.d
0038: 6c 6c 20 37 2e 30 2e 33   ll 7.0.3
0040: 37 39 30 2e 33 39 35 39   790.3959
0048: 20 61 74 20 6f 66 66 73    at offs
0050: 65 74 20 30 30 30 33 34   et 00034
0058: 35 30 65                  50e

Mhhh… ist jetzt zwar nicht so schlimm, aber die dauernden Meldungen jeden Tag um 04:30 Uhr sind halt doch nervig.

Abhilfe ist eigentlich schnell geschaffen – einfach die Berichteinstellungen noch einmal neu über den Servermanager einrichten…

Und schon kommt die Fehlermeldung nicht mehr 🙂

In gewissen Konstellationen (Webserver mit Ubuntu und PHP 5.2.4) kann es vorkommen, das die PHP Funktion realpath() eine Fehlermeldung ausgibt. Das liegt an dem Hardened-PHP Project’s Suhosin Patch.

Hierzu einfach die functions.php Datei öffnen (liegt im Verzeichnis wp-includes/) und folgende Stelle suchen:

// this is definitive if true but fails if $path does not exist or contains a symbolic link
if ( realpath($path) == $path )
return true;

und durch folgenden Code ersetzen:

// this is definitive if true but fails if $path does not exist or contains a symbolic link
if ( file_exists($path) == $path )
return true;

Und schon ist die Fehlermeldung weg 🙂

Hier noch die Erklärung/Grund

Meisten ist es so, das man beim Exchange Server einen Smarthost Server einrichtet. Bei den meisten Mailservern sind die SMTP Ports für den öffentlichen E-Mailverkehr und den internen Mailverkehr getrennt.

Der öffentliche Port 25 wird meist mit Anti-Spam Tools / Software gefiltert, sodass es hier bei der Zustellung vom Exchange Server zu Problemen kommen kann. Hierfür verwendet man dann den internen SMTP Port (meist 587 bei Plesk / Qmail Servern). Ist der interne Port nicht bekannt, so muss dieser beim Mailserver Anbieter in Erfahrung gebracht werden.

Anleitung für Exchange 2003:

Als erstes öffnen wir den System Manager des Exchange Servers. Danach erweitern wir den Baum wie auf dem Bild und klicken dann auf Eigenschaften bzw. Properties:

Nun erscheint folgendes Fenster:

Hier Wechseln wir in den Bereich Delivery bzw. Zustellung und wählen dort unten dann Outbound connections bzw. Ausgehende Verbidnungen aus. Im nun erscheinenden Fenster können wir im Feld TCP port dann den gewünschten Port eintragen.

Nun am besten noch den Server neu starten und die Änderungen greifen nun. Es sollte auch reichen, die entsprechenden Exchange Dienste neu zu starten, aber sich ist sicher – außerdem tut ein Reboot immer gut 🙂

Anleitung für Exchange 2007/2010:

Hier ist es nun nicht mehr so einfach, den Port umzustellen – hierzu müssen wir nun auf die PowerShell des Exchange Servers zurückgreifen.

Wir starten nun also die Exchange PowerShell.

Als erstes geben wir den Befehl

Get-SendConnector

ein und anschließend folgenden Befehl:

Get-SendConnector | fl port

Danach sollten wir ungefähr dieses Bild bekommen:

(in diesem Bild ist schon der Port 2525 anstatt Port 25 gesetzt)

Nun setzen wir folgenden Befehl ab:

Set-SendConnector –Identity “Windows SBS Internet Send <Servername>” -Port 587

<Servername> muss natürlich mit dem Namen aus dem Befehl Get-SendConnector ersetzt werden (hier im Bild wurde er unkenntlich gemacht).

Danach kann mit dem Befehl Get-SendConnector | fl port kontrolliert werden, ob der Port geändert wurde. Ist nur ein SendConnectro aktiv, kann alernativ auch folgender Befehl abgesetzt werden:

Get-SendConnector | Set-SendConnector -Port 587

Somit erspart man sich die Angabe der Identity.

Um alle SendConnector Einstellungen anzeigen zu lassen, setzen wir einfach folgenden Befehl ab:

Get-SendConnector | fl

Danach die Exchange-Verwaltungsshell mit „exit“ verlassen und zur Sicherheit den Server neu starten.

Im Eventlog des SBS 2008 erscheint immer eine Eintrag mit der Event-ID 2436, der ungefähr so aussieht:

Event Type: Warning
Event Source: Windows SharePoint Services 3 Search
Event Category: Gatherer
Event ID: 2436
Date:  2/12/2007
Time:  1:50:00 PM
User:  N/A
Computer: <computer>
Description:
The start address <sts3://server.domain/contentdbid={7a7f6b78-5fe1-4c0e-a5f2-956a00cc7f04}> cannot be crawled.

Context: Application ‚Search index file on the search server‘, Catalog ‚Search‘

Details:
Access is denied. Check that the Default Content Access Account has access to this content, or add a crawl rule to crawl this content.   (0x80041205)

Hier ist die Lösung relativ einfach.

Wir öffnen die Registry (Start -> ausführen -> regedit) und gehen in den folgenden Schlüssel:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa

Nun klicken wir mit der rechten Maustaste auf LSA und dann auf Neu -> DWORD und vergeben den Namen DisableLoopbackCheck und geben diesem neuen Element den Wert 1.

Nun gehen wir in den folgenden Schlüssel:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0

Nun klicken wir mit der rechten Maustaste auf MSV1_0 und dann auf Neu -> Wert der mehrteiligen Zeichenfolge und geben diesem dann den Namen BackConnectionHostNames und als Wert geben wir den Hostnamen bzw. die Hostnamen für die Sites ein, die sich auf dem lokalen Computer befinden.

Danach können wir die Registry schließen und den Computer neu starten. Danach erscheint der Fehler im Ereignisprotokoll nicht mehr 🙂

Beim Small Business Server sollte man immer die Festplattenauslastung im Auge behalten.

Des öfteren ist mir nun schon untergekommen, das die SharePoint_Config Datenbank sehr Groß wird.

Hier noch die Original Fehlermeldung von Microsoft:

SBS 2008 BPA Reports that The Windows SharePoint Services configuration databases log file is getting large (currently over 1gb in size)

Aber es ist relativ einfach, das Datenbank Logfile wieder in seine Schranken zu weisen:
declare @ConfigDB varchar(255);
declare @ConfigDBLog varchar(255);
declare @ConfigDBCmd varchar(255);
select @ConfigDB =  name from sys.databases where name like 'SharePoint_Config_%';
set @ConfigDBCmd = 'BACKUP database [' + RTRIM(@ConfigDB) + '] to disk=''C:\_maintenance\tmp\sharepoint_config_before.bkf''';
execute(@ConfigDBCmd);
set @ConfigDBCmd = 'use [' + RTRIM(@COnfigDB) + ']';
execute(@ConfigDBCmd);
set @ConfigDBCmd = 'BACKUP LOG [' + RTRIM(@ConfigDB) + '] WITH TRUNCATE_ONLY';
execute(@ConfigDBCmd);
set @ConfigDBCmd = 'use [' + RTRIM(@COnfigDB) + ']';
execute(@ConfigDBCmd);
select @ConfigDBLog =  name from sys.database_files where name like 'SharePoint_Config%_log';
set @ConfigDBCmd = 'use [' +  RTRIM(@ConfigDB) + '] DBCC SHRINKFILE([' + RTRIM(@ConfigDB) + '_log],1)';
execute(@ConfigDBCmd);
set @ConfigDBCmd = 'BACKUP database [' + RTRIM(@ConfigDB) + '] to disk=''C:\_maintenance\tmp\sharepoint_config_after.bkf''';
execute(@ConfigDBCmd);
go
Den Code oben einfach kopieren und per Notepad als sharepoint_config_logshrink.sql im Ordner C:\_maintenance abspeichern. Ich erstelle hier immer ein Unterverzeichnis in C:\ mit dem Namen „_maintenace“. In diesem Ordner gibt es dann noch einmal einen Ordner „tmp“.

Dann öffnen wir die Eingabeaufforderung mit Administrationsrechten (rechte Maustaste -> Als Administrator ausführen) und setzen folgenden Befehl ab:

sqlcmd -S \\.\pipe\mssql$microsoft##ssee\sql\query -E -i c:\_maintenance\sharepoint_config_logshrink.sql

Danach ist die Logfile Datenbank wieder um einiges kleiner 🙂

Meistens gibt es dann auch das Logfile der Datenbank „ShareWebDb“, welches ebenfalls viel zu Groß ist.

Hier führen wir die gleichen Schritte wie oben aus, nur verwenden wir folgendes SQL Script:
declare @ConfigDB varchar(255);
declare @ConfigDBLog varchar(255);
declare @ConfigDBCmd varchar(255);
select @ConfigDB =  name from sys.databases where name like 'ShareWebDb%';
set @ConfigDBCmd = 'BACKUP database [' + RTRIM(@ConfigDB) + '] to disk=''C:\_maintenance\tmp\webdb_before.bkf''';
execute(@ConfigDBCmd);
set @ConfigDBCmd = 'use [' + RTRIM(@COnfigDB) + ']';
execute(@ConfigDBCmd);
set @ConfigDBCmd = 'BACKUP LOG [' + RTRIM(@ConfigDB) + '] WITH TRUNCATE_ONLY';
execute(@ConfigDBCmd);
set @ConfigDBCmd = 'use [' + RTRIM(@COnfigDB) + ']';
execute(@ConfigDBCmd);
select @ConfigDBLog =  name from sys.database_files where name like 'ShareWebDb_log';
set @ConfigDBCmd = 'use [' +  RTRIM(@ConfigDB) + '] DBCC SHRINKFILE([' + RTRIM(@ConfigDB) + '_log],1)';
execute(@ConfigDBCmd);
set @ConfigDBCmd = 'BACKUP database [' + RTRIM(@ConfigDB) + '] to disk=''C:\_maintenance\tmp\webdb_after.bkf''';
execute(@ConfigDBCmd);
go
Den Code oben einfach kopieren und per Notepad als sharewebdb_logshrink.sql im Ordner C:\_maintenance abspeichern.

Der Befehl für die Eingabeaufforderung lautet dieses mal nun:

sqlcmd -S \\.\pipe\mssql$microsoft##ssee\sql\query -E -i c:\_maintenance\sharewebdb_logshrink.sql

Danach ist auch diese Datenbank wieder auf eine normale Größe geschrumpft.

Da gerade bei einem Kunden die Problematik auftauchte, das beim Versenden von HTML Newslettern, die T-Online Empfänger, welche Ihre E-Mails mit der T-Online Software abrufen, nur eine leere E-Mail angezeigt bekommen, will ich euch nicht auf die Folter spannen und des Rätsels Lösung preis geben:

Bei dem HTML Inhalt kann zwar CSS verwendet werden, darf aber nicht im Header enthalten sein.

Es muss immer direkt am Element über das Attribut style=““ definiert werden.

Also anstatt <table class=“meineklasse“> muss es so programmiert werden:

<table style=“meine CSS Definitionen“>

Und schon kommen keine leeren E-Mails mehr an 🙂

Beim Small Business Server 2008 sind die Ordnerumleitungen soweit schon eingerichtet, allerdings werden die Daten auf die lokale Systempartition des Small Business Servers verlinkt.

Da ich ein Freund von „sauberen“ Systempartitionen bin und manche Benutzer in den Eigenen Dateien viel zu viel „Müll“ speichern, kann es schon mal vorkommen, das die Systempartition voll läuft. Um das zu verhindern, verschieben ich die Ordnerumleitungen immer auf die Datenpartition.

Der Small Business Server hat hier einen Assistenten, allerdings ist der gut versteckt.

Hierzu sind folgende Schritte durchzuführen:

• Ausführen der „Windows SBS Console“
• Wechseln in den Bereich „Datensicherung und Serverspeicher“
• Hier dann in den Bereich „Serverspeicher“ wechseln
• Auf der rechten Seite gibt es nun die Links für „Freigegebene Benutzerdaten verschieben“ und „Daten aus „Umgeleitete Benutzerdokumente““
• Diese beiden Assistenten dann ausführen und die als neues Laufwerk im Assistenten die Datenpartition auswählen

Danach sind die Order verschoben und die Systempartition kann nicht mehr so leicht voll laufen.

Auf einem klassichen Small Business Server 2008 ist der WSUS Content direkt auf C:\ eingerichtet.

Da meist auch noch eine Daten Partition vorhanden ist, verschiebe ich den WSUS Content gerne immer auf diese Partition, damit die Systempartition nicht voll läuft.

Das Tool zum „moven“ des Content ist schon vorhanden.

Dann auf der Datenpartition einen Ordner WSUS erstellen, dann die Eingabeaufforderung öffnen und in den Ordner „C:\Program Files\Update Services\Tools“ wechseln und dann folgenden Befehl absetzen:

wsusutil.exe movecontent E:\WSUS C:\WSUSLogfile.txt

Danach wird sämtlicher Content verschoben. Der alte Content bleibt noch am alten Speicherort und kann dann, nachdem die Funktionalität des WSUS überprüft wurde, gelöscht werden. Wurden schon Updates heruntergeladen, kann der Verschiebevorgang durchaus viel Zeit in Anspruch nehmen.

Ich habe als Datenpartition das Laufwerk E:\ verwendet. Der Parameter C:\WSUSLogfile.txt wird benötigt – hier wird das Logfile des Vorgangs geschrieben.

Habe demletzt einen HP Proliant ML110 G6 installieren dürfen. Da ich bei Servern immer ein RAID verwende, war dem hier auch so.

Also 2te Platte einbauen, im BIOS die RAID Funktionalität einschalten und dann das RAID 1 konfiguriert. Klappte alles soweit wunderbar.

Also weiter im Text – installiert werden sollte eine Microsoft Small Business Server 2008… DVD rein und booten.

Wie bei HP-Branded Software üblich, wird über das BIOS geprüft, ob es auch ein HP Server ist. Dies leif soweit auch ohne Probleme durch und er fing an, die Installation vorzubereiten – und dann der Fehler:

SBSBIOSLOCK
could not find the media

SBSBIOSLOCK ??? Die Überprüfung war doch schon fertig?!

Erst mal Dr. Google fragen…

Das war mal ernüchternd – kaum nützliche Informationen gefunden, also erst mal ins HP Forum gehen und da etwas stöbern – aha ich bin nicht der einzige mit dem Problem 🙂

Was hier im Forum an Vorschlägen gemacht wurde, war echt haarsträubend!!!

Dabei ist die Lösung so simpel:

Durch das einschalten der RAID Funktionalität wird das DVD-Laufwerk im späteren Verlauf der Installation nicht mehr erkannt, da es ebenfalls per SATA angeschlossen ist.

Also einfach ein DVD Laufwerk per USB anschließen und von dort installieren, oder über PXE den Server ausrollen.

Da ich glücklicherweise ein USB DVD-Laufwerk rumliegen hatte, von dem aus installiert und alles lief wunderbar.