In einem recht umfangreichen Projekt (C# Windows Forms Anwendung) welches als Datenbank eine MS SQL Datenbank verwendet, musste ich Erweiterungen der Datenbank (zusätzliche Felder) vornehmen.

Da ich diese neuen Felder auch in allen vorhandenen Abfragen ergänzen musste, in welchen ein anders bereits vorhandenes Feld (wir nennen es einfach mal “EinfahrtLKW”) der gleichen Tabelle ausgegeben wird, habe ich nach einer Lösung gesucht um mir alle Abfragen (Views) anzeigen zu lassen, in dem das Feld EinfahrtLKW Verwendung findet.

Um dies zu realisieren habe ich folgende Systemsicht verwendet:

INFORMATION_SCHEMA.VIEW_COLUMN_USAGE

Meine Abfrage sieht dann so aus:

select * from INFORMATION_SCHEMA.VIEW_COLUMN_USAGE where COLUMN_NAME = 'EinfahrtLKW'

Und das Ergebnis sieht dann so aus:

Mit dieser Information habe ich nun die Name der Views, die ich anpassen muss.

Vorwort:

Ich möchte an dieser Stelle jetzt keinen Vortrag über ADS (Alternate Data Streams) im NTFS Dateisystem halten, dazu gibt es bereits eine Fülle von Informationen im Internet, wer hierzu nähere Informationen haben möchte kann diese über eine Internetrecherche mit der SDV (Suchmaschine deines Vertrauens) erhalten.

Hintergrund dieses Beitrags:

In letzter Zeit haben sich die Anfragen bei mir gehäuft, warum nach dem herunterladen aktueller DotNetNuke Versionen (4.9.X und 5.X) von Codeplex und dem anschließenden Entpacken des ZIP Archivs beim Öffnen der Visual Studio Solution ständig die Meldung “Der Projektspeicherort ist nicht vertrauenswürdig” erscheint, obwohl man die Projektdaten auf einem lokalen Laufwerk gespeichert hat und nicht (wo diese Meldung üblicherweise herkommt) auf einem Netzwerklaufwerk.

Zuerst sei einmal gesagt, dass dies weder etwas mit den neuen Versionen, noch mit Codeplex oder DotNetNuke zu tun hat.

Der Grund für diese Meldungen ist, dass beim herunterladen über einen Browser (Früher war das nur wenn man den IE benutzt hat, Heute ist es aber auch mit Firefox so) einer Datei auf ein NTFS Laufwerk sogenannten Alternate Data Streams erzeugt werden, die in diesem speziellen Fall eine unsichtbare Datei [Dateiname]:Zone.Identifier auf dem Laufwerk erstellt und fest verknüpft mit der heruntergeladenen Datei speichert.

Vereinfacht gesagt, teilt diese “unsichtbare” Datei dem Betriebssystem mit “Du Achtung die Datei kommt aus dem Internet und könnte gefährlich sein, gib lieber mal eine Warnung aus”.

Eine der Lösungen (die in diesem Beitrag beschriebene) ist:

Wir löschen die “unsichtbaren” Dateien [Dateiname]:Zone.Identifier.

Seit Vista gibt es zwar für den Kommandozeilenbefehl DIR eine neue Option /R welche diese “unsichtbaren” ADS Dateien anzeigt, aber leider habe ich noch keinen weg gefunden diese mit “Bordmitteln” löschen zu können (Außer die Daten auf ein nicht NTFS Laufwerk zu speichern und anschließend wieder auf das NTFS Laufwerk zu kopieren).

Aber wie so häufig gibt es dafür ein Freeware Tool (sicherlich gibt es auch noch andere, hinterlasst einfach einen Kommentar) welches genau das kann.

Das Programm AlternateStreamView von NirSoft ist so ein Tool (Das übrigens auch unter WIN 7 und da sogar auf X64 funktioniert).

Die Verwendung des Programms ist; denke ich selbsterklären.

Ich habe viele Links zu diesem Thema gefunden, aber leider war keiner dabei der mir wirklich in einem Artikel dazu verholfen hat SpamAssassin in eine hMailServer Installation zu integrieren. Mit ein wenig Recherche und dem guten alten “Try and Error Verfahren” habe ich eine einfache Möglichkeit gefunden SpamAssassin zusammen mit dem hMailServer zu verwenden.

Dieser Beitrag basiert auf den folgend aufgeführten Versionen der Produkte:

• Windows Server 2003 R2 Standard (Sorry kein Download, der muss gekauft werden )
• hMailServer Version hMailServer 5.3.2 - Build 1769 (sollte schon installiert sein)
• SpamAssassin for Win32 command-line tools Version 3.2.3.5 (wird benötigt bitte Herunterladen)
• sa-update Version 3.2.3.3 (wird benötigt bitte Herunterladen)
• RunAsSvc.exe Version 1.6.159.59 (wird benötigt bitte Herunterladen)

Und nun zur Schritt für Schritt Anleitung zur Einrichtung von SpamAssassin zusammen mit dem hMailServer:

1) Herunterladen aller benötigten Programme / Tools.

Siehe oben (SpamAssassin command-line-tools, sa-update ebenfalls ein SpamAssassin Tool und ein Hilfsprogramm um den SpamAssassin Deamon als Dienst unter Windows betreiben zu können.

2) Verzeichnisse erstellen

Wir erstellen 2 Verzeichnisse. das eine für SpamAssassin (z.B. D:\SA) das zweite für unser Tool RunAsSvc (z.B. D:\runassvc)

3) ZIP Archive auspacken

Die beiden SpamAssassin ZIP Archive kopieren wir in das Verzeichnis D:\SA und dort entpacken wir beide Archive, dabei können wir ruhig nach Aufforderung die Datei ssleay32.dll überschreiben, da sie in beiden Paketen in der gleichen Version enthalten ist.

Das Archiv mit dem RunAsScv Hilfsprogramm kopieren wir in das Verzeichnis D:\runasscv und entpacken den Inhalt in diesem Verzeichnis.

4) Registry Eintrag erstellen

Um von SpamAssassin eine Logdatei erstellt zu bekommen müssen wir bevor wir den Dienst einrichten einen Eintrag in die Registry hinzufügen.

Hierzu öffnen wir regedit und erzeugen unter dem Registry Schlüssel

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\

einen neuen Schlüssel mit dem Namen SPAMASSASSIN (oder jeder andere Name, jedoch ist darauf zu achten, dass dieser Name auch beim einrichten des Dienstes verwendet wird).

Unter diesem neuen Schlüssel:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SPAMASSASSIN

legen wir nun eine Neue Zeichenfolge mit dem Namen Application und dem nachfolgenden Inhalt an:

d:\sa\spamd.exe -l -s d:\sa\spamd.log --round-robin

5) Dienst installieren

Nun wechseln wir in das Verzeichnis d:\runasscv und starten dort das Programm RunAsSvc.Exe und füllen das sich öffnende Dialog wie nachstehend abgebildet:

Der Dienst wird nachdem wir unsere Eingaben mit OK bestätigt haben installiert und sofort gestartet.

Eigentlich war das bis auf die Aktivierung des SpamAssassin in hMailServer alles.

Was noch bleibt ist die Aktualisierung des SpamAssassin einzurichten, entweder als geplanten Task oder einem anderen Tool welches Zeitgesteuert Programme ausführen kann.

Der Aufruf zum Update lautet wie folgt:

D:\SA\sa-update.exe --nogpg

-- Hoffe das hilft jemandem weiter --

Abfragen, in meinem Fall einige Views, haben plötzlich anstatt Sekundenbruchteile, Minuten gebraucht um ein Ergebnis zurückzugeben.
Das merkwürdigste aber daran war, wenn ich eine Datenbanksicherung auf einem anderen Server (sehr viel kleineren Server) zurückgespielt habe wurden die Abfragen wie gewohnt schnell ausgeführt.

Also lag die Vermutung nahe, dass es an diesem Server liegen muss und somit habe ich folgendes Versucht:

• Ein Neustart des SQL Server (auch den ganzen Servers) – Kein Erfolg. :-(
• Festplatte des Server defragmentiert (Natürlich vorher den SQL Server Dienst beendet, damit die Datenbankdateien selbst defragmentiert werden konnten) – Kein Erfolg :-(
• Gesamt Konfiguration des Server mit einem Server der schnellere Ergebnisse geliefert hat verglichen (Alles OK) – Kein Erfolg :-(
• SQL Profiler … Nein das ist Unsinn, denn die DB (also das Backup auf einem anderen Server läuft ja bestens) – Also Arbeit gespart

Und dann bin ich auf diese Seite gestoßen und dabei auch auf den alles Entscheidenden Hinweis; die Statistiken.

Ein Aufruf der Gespeicherten Prozedur sp_updatestats hat dann den gewünschten Erfolg gehabt.

Die Abfragen geben nun wieder wie gewohnt schnelle Ergebnisse zurück.

Und falls ich damit niemand anderem helfen kann, so doch sicherlich mir selbst, wenn in einigen Monaten bei einer anderen Datenbank ein ähnliches Problem ansteht und ich dies hier schon wieder vergessen habe, und dann über meinen eigenen Blog Beitrag stolpere.

Bei der Einrichtung des FileZilla FTP Server auf einem Windows Server (2003 oder 2008) kommt es immer wieder zu dem Problem, dass trotz scheinbar richtig eingerichteter Windows Firewall bei Verbindungsaufbau zum FTP Server folgender Fehler im FTP Client angezeigt wird:

Befehl:    MLSD
Antwort:    425 Can't open data connection.
Fehler:    Verzeichnisinhalt konnte nicht empfangen werden

Zuerst aber einmal die Information was mit scheinbar richtig eingerichteter Firewall gemeint ist:

Auf der Registerkarte “Ausnahmen” der Firewall Einstellungen gibt es den Eintrag “FTP-Server” und dieser wird auch meistens richtigerweise aktiviert, so dass der Port 21 über das Netzwerk (LAN, WAN, Internet) erreichbar ist.

Wenn man aber nun mit einem FTP Client versucht eine Verbindung herzustellen, dann kommt eben der weiter oben beschriebene Fehler.

Das Problem liegt daran, dass man zusätzlich zur Freigabe des Port 21 (FTP-Server) auch noch den FTP-Server Dienst freigeben muss damit der Zugriff auf den FTP Server funktioniert.

Hierzu ist noch folgendes Einzustellen:

Register “Erweitert” und dort Einstellungen:

In den Erweiterten Einstellungen ist dann noch der FTP-Server Dienst zu aktivieren.

Mit diesen Einstellungen sollte es dann funktionieren.

Seit ein paar Wochen habe ich eine Logitech MX 3200 Laser Tastatur / Maus Kombination im Einsatz.

Außer der störenden Zoomfunktion am linken Rand bin ich auch sehr zufrieden.

Verzweifelt habe ich nach einer Lösung gesucht diese Zoom Funktion zu deaktivieren und habe nichts gefunden.

Heute bin ich dann durch Zufall auf die Lösung gestoßen.

Hier der Link zur Web Seite mit der Lösung

Besten Dank an Cord-Heinrich Pahlmann

Beim stöbern in meinen SQL Skripten bin ich gerade wieder auf das hier nachfolgend aufgeführte Skript zur Ausgabe der “Größe aller Tabellen einer Datenbank” gestoßen.

Da ich sicherlich nicht der einzige bin, der diese Informationen einer Datenbank hin und wieder benötigt, veröffentliche ich hier das Skript mit der Hoffnung dass es jemand gebrauchen kann.

SET NOCOUNT ON
CREATE TABLE #TableSpace 
(
	Rows int, 
	DataSpaceUsed int, 
	IndexSpaceUsed int
)
DECLARE @TableSpace table
(
	TableName varchar(255),
	Rows int, 
	DataSpaceUsed int, 
	IndexSpaceUsed int
)
DECLARE @Rows int, @DataSpaceUsed int, @IndexSpaceUsed int
DECLARE @TableName varchar(255)
DECLARE Table_Cursor CURSOR FOR
SELECT	user_name(o.uid) + '.' + o.name AS table_name
FROM	dbo.sysobjects o, dbo.sysindexes i 
WHERE	OBJECTPROPERTY(o.id, N'IsTable') = 1 
	AND i.id = o.id 
	AND i.indid < 2 
	AND o.name NOT LIKE N'#%' 
	AND xtype = 'U'
ORDER BY 1
OPEN Table_Cursor
---------------------------------
--Set Data
FETCH NEXT FROM Table_Cursor INTO @TableName
INSERT INTO #TableSpace (Rows, DataSpaceUsed, IndexSpaceUsed)
EXEC sp_MStablespace @TableName
SELECT	@Rows = Rows, 
	@DataSpaceUsed = DataSpaceUsed,
	@IndexSpaceUsed = IndexSpaceUsed
FROM	#TableSpace
INSERT INTO @TableSpace (TableName, Rows, DataSpaceUsed, IndexSpaceUsed)
VALUES (@TableName, @Rows, @DataSpaceUsed, @IndexSpaceUsed)
DELETE FROM #TableSpace
--------------------------------
WHILE @@FETCH_STATUS = 0


    BEGIN
    	---------------------------------
    	--Set Data
    	FETCH NEXT FROM Table_Cursor INTO @TableName
    	
    	INSERT INTO #TableSpace (Rows, DataSpaceUsed, IndexSpaceUsed)
    	EXEC sp_MStablespace @TableName
    	
    	SELECT	@Rows = Rows, 
    		@DataSpaceUsed = DataSpaceUsed,
    		@IndexSpaceUsed = IndexSpaceUsed
    	FROM	#TableSpace
    	
    	INSERT INTO @TableSpace (TableName, Rows, DataSpaceUsed, IndexSpaceUsed)
    	VALUES (@TableName, @Rows, @DataSpaceUsed, @IndexSpaceUsed)
    	
    	DELETE FROM #TableSpace
    	--------------------------------
END

CLOSE Table_Cursor
DEALLOCATE Table_Cursor
DROP TABLE #TableSpace
SELECT * 
FROM @TableSpace
ORDER BY Rows DESC

Über die Herkunft dieses Skripts (ich weiß dass ich zumindest die Idee von irgendwoher hatte) bin ich mir nicht mehr sicher. Eine gerade durchgeführte Recherche im Internet hat mir auch keinen direkten Aufschluss gegeben woher ich das Skript oder die Idee dazu hatte.

Sollte also jemand die Herkunft kennen, bitte einfach per Kommentar posten.

Nachdem ich mich Gestern über das Thema “Ziemlich Sicheres erkennen von SPAM” ausgelassen habe, möchte ich mich Heute, einem mindestens genau so wichtigen Thema, der Virus Erkennung und Abwehr in E-Mails unter Verwendung der hMailServer Bordmittel und lizenzfreien Zusatzprodukten widmen.

Wer den hMailServer einsetzt, wird die Optionen der AntiVirus Einstellungen kennen und sicherlich werden die meisten die einfache Clamwin Integration wählen.

• Clamwin installieren
• Use Clamwin aktivieren
• Auto-detect anklicken

Fertig !

Das ist sicherlich eine gute und einfache Lösung (vor allem ist es eine akzeptable Lösung) wenn auf dem Mail Server wenige Mails (einige Mails pro Stunde) verarbeitet werden. Für Installationen mit höherem Traffic (> 100 Mails/Stunde) stellt diese Installation aber ein echtes Performance Problem dar.

Clamwin benötigt wenn es durch den hMailServer aufgerufen wird um die Mails nach Viren zu untersuchen enorm viel Ressourcen des Computers. Wenn gleichzeitig mehrere Mails im hMailServer eintreffen, werden je nach Einstellungen mehrere Instanzen von Clamwin aufgerufen um die Mails einer Virenprüfung zu unterziehen. Dies führt unweigerlich dazu dass der Server mit nahezu 100% CPU Last nicht mehr viel Luft für andere Aufgaben hat.

Es gibt aber auch hierfür eine Lizenzkostenfreie Lösung und diese arbeitet mit der gleichen Scan Engine wie Clamwin.

ClamAV für Windows in der Variante von SOSDG.

Stand Heute ist die aktuelle Version der SOSDG Variante die 0.95-1, diese Version können wir aber für die Integration mit dem hMailServer “leider” nicht nehmen. Ich hoffe aber, dass bald eine fehlerbereinigte Version folgt, die dann die aktuellste ClamAV Engine einsetzen kann.

Um die Integration mit dem hMailServer zu realisieren müssen wir die Version clamav-0.94-2-1a.exe herunterladen und installieren.

Nachfolgend werde ich den Installationsprozess sowie die notwendigen Einstellungen im Detail erläutern.

Diese Anleitung basiert auf dem englischen Forumbeitrag von “rodolfor” im hMailServer Forum.

Schritt für Schritt Anleitung, oder in 9 Schritten zu einer performanten kostengünstige AntiVirus Lösung für hMailServer)

1. Herunterladen der clamav-0.94-2-1a Version

2. Installieren der clamav-0.94.2-1a Version

a) Setup ausführen

b) Als Installationstyp “Full auswählen (sonst werden benötigte Komponenten nicht installiert)

c) Dann den Setup mit den Standard Werten (am besten auch im Standard Verzeichnis) ausführen.

Zum Ende der Installation startet automatisch die Aktualisierung der Viren Signatur Datenbank.

d) Installation abschließen

3. Konfiguration “c:\clamav-devel\etc\clamav.conf” anpassen.  (Datei c:\clamav-devel\etc\clamav.conf mit einem Texteditor öffnen)

a) LocalSocket /cygdrive/c/clamav-devel/clamd.sock in der Datei suchen (eigentlich Zeile 82)

Diese Zeile durch das voranstellen eines # auskommentieren (siehe nachfolgende Zeile)

# LocalSocket /cygdrive/c/clamav-devel/clamd.sock

 

b) #TCPSocket 3310 in der Datei suchen (eigentlich Zeile 90)

In dieser Zeile das Kommentarzeichen # am Anfang entfernen (siehe nachfolgende Zeile)

TCPSocket 3310

c) Zur Aktivierung der Log Funktion (würde ich unbedingt empfehlen) folgende Einstellung vornehmen

#LogFileUnlock yes in der Datei suchen (eigentlich Zeile 32)

In dieser Zeile das Kommentarzeichen # am Anfang der Zeile entfernen (siehe nachfolgende Zeile)

LogFileUnlock yes

 

4. ClamAV (Hilfs)Dienst installieren

Hierzu öffnet man ein DOS (Kommando) Fenster.

Wechselt in das Verzeichnis C:\clamav-devel\thirdparty\runclamd

Gibt den Befehl runclamd –install ein und führt diesen aus

Wenn der Befehl erfolgreich durchgeführt wurde, gibt der Server im DOS Fenster “service installed” zurück.

Nun schließen wir das DOS Fenster

5. ClamAV (Hilfs)Dienst einrichten und starten

In den installierten Diensten suchen wir nun den Dienst Run Clamd

Öffnen das Eigenschaften Fenster

Und stellen den Starttyp für den Dienst von Manuell auf Automatisch

Nun starten wir den Dienst (dieses mal mit der Hand) beim nächsten Start wird er Automatisch gestartet.

6. Beheben von Zugriffproblemen der Log Datei

Wer möchte kann kann versuchen nun schon die Log Datei clamd.log im Verzeichnis C:\clamav-devel\log zu öffnen. Es wird schnell klar dass es nicht geht. Klar wird man denken, der Dienst greift ja darauf zu und deshalb ……
Nein das ist es nicht, wir haben übrigens in der Konfiguration Schritt 3c dem Program gesagt, dass wir die Log Datei lesen wollen. Also das Problem liegt nicht daran dass die Datei geöffnet ist, sondern (und da habe ich eine ganze Zeit suchen müssen) daran, dass die Zugriffsrechte für diese Datei etwas merkwürdig gesetzt sind.

Schauen wir uns doch mal die Rechte für diese Datei an:

Ich bin übrigens als Administrator an diesem System angemeldet, und trotzdem kann / darf ich die Rechte hier nicht ändern.

Es gibt aber einen ganz einfachen Trick wie wir hier weiterkommen. Hierzu betätigen wir den Button Erweitert und dort den Reiter Besitzer:

Hier sehen wir,dass der Besitzer das System ist. Das werden wir nun einfach ändern, indem wir den Besitzer ändern auf “Administratoren".

Wenn wir nun alle Rechte Fenster geschlossen und das Fenster der Dateiberechtigungen noch einmal öffnen:

Können wir auch das Lesen Recht für Jeden (oder wie auch immer) setzen (Und danach auch die Log Datei öffnen).

7. ClamAV in hMailServer eintragen und aktivieren

Nun müssen wir die nachfolgenden Einstellungen im hMailServer Administrations Tool im Bereich Anti-Virus vornehmen

Auf der Karteikarte External Virus Scanner nehmen wir folgende Einstellungen vor:

• Use external scanner (aktivieren)
• Im Feld Scanner executable wird "C:\clamav-devel\bin\clamdscan.exe" --no-summary --stdout "%FILE%" eingetragen (Mit den “)
• Im Feld Return Value wird 1 eingegeben

8. Automatische Aktualisierung der Virus Signaturen einrichten

Einrichten eines geplanten Task für die Datei C:\clamav-devel\bin\freshclam.exe. Zum Beispiel Alle 2 Stunden

9. Tests

Zum Abschluss sollte man noch testen, ob alles einwandfrei funktioniert. Hierzu möchte ich zwei Beispiele geben, um den Viren Scanner und die Implementierung im hMailServer zu testen

Scanner testen

In einem geöffneten DOS Fenster gibt man die folgende Befehlszeile ein und führt sie aus:

"C:\clamav-devel\bin\clamdscan.exe" --no-summary --stdout "C:\clamav-devel\test\clam-nsis.exe"

Wenn der Scanner richtig installiert ist wird nach dem ausführen des Befehls die folgende Antwort im DOS Fensters zurückgegeben:

 

Integration testen

Um die Mail Integration zu testen schickt man ein E-Mail mit der Datei C:\clamav-devel\test\clam-nsis.exe als Anhang an eine bekannte (eigene) E-Mail Adresse.

Wenn die Integration erfolgreich war, dann solle der Anhang von ClamAV über den hMailServer herausgefiltert werden.

Nachdem die beiden Tests durchgeführt sind, sollte man noch das Protokoll C:\clamav-devel\log\clamd.log anschauen. Dort sollten auf jeden Fall Protokolleinträge für die beiden Test aufzufinden sein.

Ich habe seit vielen Jahren den hMailServer in verschiedenen Installationen, sowohl als eigenständigen E-Mail Server als auch im Zusammenspiel (als ESMTP Server) mit MS Exchange Server, im Einsatz. In kleinen und mittleren Betrieben ist hMailServer sicherlich eine günstige (da Lizenzkostenfrei) alternative zu einem hochpreisigen Produkt wie dem Microsoft Exchange Server. Vor allem dann, wenn es hauptsächlich um E-Mail geht und die Groupware Funktionen eines Exchange Server nicht benötigt werden.

Wobei ich gleich hier erwähnen möchte, dass die hier beschriebene Version des hMailServer über IMAP nun auch öffentlichen Ordner zur Verfügung stellt.

Nun aber zum eigentlichen Thema dieses Beitrags,:

“Ziemlich” Sicheres erkennen von SPAM !!!

In der heutigen Zeit ist das Thema SPAM so aktuell wie noch nie.

Ich persönlich erhalte täglich zwischen 300 und 1000 SPAM Mails (Das liegt sicherlich auch daran, dass ich schon seit über 20 Jahren mit teilweise den gleichen E-Mail Adressen arbeite).

Auch wenn es mittlerweile sehr gute SPAM Filter gibt, so kann man doch meistens die als SPAM erkannten Mails nicht einfach löschen, da hier und da doch einmal ein E-Mail welches man benötigt vom SPAM Filter als SPAM erkannt wird.

Was bleibt ist, die SPAM Mails in einen Ordner umzuleiten und diese bevor man sie löscht zu überfliegen um die eine oder andere “normale” Mail auszusortieren bevor man die “richtigen” SPAM Mails löscht.

Wenn man nun aber, wie ich bis zu 1000 SPAM Mails am Tag erhält, dann ist das fast ein Tagfüllender Job, vor allem dann, wenn man E-Mails zeitnahe bearbeitet.

Wenn man doch nur mehr Zuverlässigkeit in der Erkennung der SPAM Filter erreichen könnte !!!

Man kann !! (wenn man den hMailServer einsetzt)

Und das ganze auch noch vollkommen ohne zusätzliche Kosten mit den Bordmitteln von hMailServer, ohne zusätzliche Installation eines weiteren SPAM Filters wie Beispielsweise SpamAssassin.

Nun aber zur Theorie und der Praxis:

Der in hMailServer integrierte SPAM Filter besteht aus mehreren Komponenten:

Zuerst sind sind das die “einfachen” SPAM Test varianten:

• Verwendung SPF (nicht sehr aussagekräftig da noch viele dieses Feature nicht nutzen)
• HELO Prüfung (lest selber wie zuverlässig diese Prüfung ist)
• DNS-MX Record (eigentlich sollte den jeder haben, aber auch hier würde ich nicht sehr viel Aussagekraft bescheinigen)
• DKIM-Signatur (meiner Meinung nach noch nicht verbreitet genug um aussagekräftig zu sein)

Auch wenn diese einfachen SPAM Test verfahren im einzelnen nicht sehr viel Aussagekraft haben, so kann doch das auftreten mehrerer dieser Testergebnisse ein zusätzliches Merkmal zur Erkennung von “echter” SPAM sein.

Wie man schon auf der obigen Abbildung erkennen kann ist jedem der Testverfahren ein Score zugeordnet. Dieser Score wird noch eine entscheidende Rollen in diesem Beitrag spielen. Mehr dazu später.

Nu gibt es außer den einfachen Tests noch weitere SPAM Erkennungsverfahren:

Neben den für diesen Beitrag nicht relevanten Verfahren des Grey- und Whitelisting  widmen wir den beiden SPAM Erkennungsverfahren die für diese Beitrag relevant sind:

• DNS Blacklist
• SURBL Server

DNS Blacklist

DNS Blacklist Server sind im Prinzip Server die Listen von IP Adressen enthalten die als Herkunft von zweifelhaften Mails bekannt sind.

Man kann unter hMailServer mehrere solcher DNS Blacklisten einrichten.

Ich habe hier die beiden oben dargestellten Blacklist Server eingerichtet.

Man kann bei jedem der Blacklist Server wieder einen Score vergeben (mehr dazu später):

SURBL Server

Wie bei den DNS Blacklisten kann man bei den SURBL Servern auch mehrere einrichten. Wie aus der nachfolgenden Abbildung zu sehen ist, begnüge ich mich mit einem:

Und wen wundert es, wenn ich sage, man kann jedem SURBL Server wiederum einen Score zuweisen kann.

Nun möchte ich nicht auf die Arbeitsweisen der einzelnen SPAM Prüfverfahren eingehen, dafür kann man die Links verwenden und von Menschen die wirklich was davon verstehen die Einzelheiten zu den einzelnen Verfahren nachlesen.

Jetzt aber endlich zum Thema “SPAM score” auf das ich im gesamten Verlauf des Beitrags schon mehrfach hingewiesen habe.

Auf der Einstiegsseite des Anti Spam Konfiguration des hMailServer finden wir unter anderem den folgenden Eintrag:

Die einzelnen Testverfahren besitzen jeweils einen score, der von hMailServer beim durchlaufen der SPAM Filter zu einem Wert (dieses SPAM mark treshold) addiert werden.

Erst wenn die Summe der Score aus den einzelnen Testverfahren diesen Schwellwert (hier sind es 5) übersteigen wird die Mail als SPAM gekennzeichnet.

Unabhängig dieser Kennzeichnung wird aber der Score (Summe aller SPAM Score der Prüfverfahren welche die Mail als SPAM identifiziert haben) auch als X-Header in das E-Mail eingefügt.

Dieser X-Header lautet: X-hMailServer-Reason-Score

Dieses Header kann man mit den meisten E-Mail Programmen aber auch direkt mit dem Regelassistent des hMailServer abfragen.

Und genau hierdurch haben wir eine einfache Möglichkeit mit hoher Genauigkeit SPAM Mails erkennen zu können..

Am besten veranschauliche ich das an einem Beispiel:

Eine eingehende Mail wird von hMailServer empfangen und wird durch die “einfachen” SPAM Tests durchlaufen.

Daraus resultiert ein SPAM core von 2 weil kein die HELO Prüfung fehlgeschlagen ist.

Nun wird der DSN Blacklist Test durchlaufen und auf dem Server bl.soamcop.net wird die IP Adresse des Absender gelistet, dadurch wird der Score um 3 erhöht. Somit ist der SPAM score nun 5.

Als nächstes erfolgt der SURBL SPAM Test und auch dort wird der Mail Inhalt als mögliche SPAM Mail erkannt was den SPAM core noch einmal um 3 erhöht. Das bedeutet der SPAM core ist nun 8.

Nun, da ich ein Kriterium an der Hand habe um “sichere” SPAM Mails von “eventuellen” SPAM Mails unterscheiden zu können kann ich ein weiteres Feature des hMailServer verwenden um Mails mit einem SPAM Core > X direkt zu löschen.

Dies kann ich, mit dem ebenfalls im hMailServer direkt enthaltenen Regelassistenten, welcher unter dem jeweiligen Account des Benutzer (Im Administrationstools zu finde ist, einfach bewerkstelligen.

Hier richte ich eine neue Regel mit den nachfolgenden Kriterien ein:

Bei den Aktionen wird Delete E-Mail ausgewählt.

Ich habe zusätzlich noch ein “Stop Rule Processing” verwendet, damit nach dem löschen der Mail nicht noch versucht wird weitere Regeln zu durchlaufen. (Ist ja keine Mail mehr vorhanden )

Nach diesem Prinzip kann man natürlich ohne Grenzen andere Regeln definieren, wie das verschieben von Mails in einen speziellen IMAP Ordner die manuell geprüft werden müssen usw.

Die X-Header die von hMailServer eingefügt werden können alternativ auch von Mail Clients (z.B. Thunderbird, Outlook usw.) zur Ausführung von lokalen Regeln und Skripten verwendet werden.

Übrigens: Die hier beschriebenen Feature sind enthalten im hMailServer Version 5.1.2

Bei meinem Dell Notebook “Precision M90” ist plötzlich folgendes Problem aufgetreten:

Nach dem Start des Rechners fährt Windows XP SP 3 ganz normal hoch, jedoch die Netzwerkverbindung über WLAN wird nicht hergestellt.

Das Taskleistensymbol der Intel PROSet/Wireless Netzwerkkarte verbindet sich nicht mit einem der vorkonfigurierten Profile sondern bleibt gelb (nicht verbunden).

Ich öffne also die Steuerung der Intel PROSet/Wireless und sehe das einige WLAN Netzwerke vorhanden sind, auch mein WLAN im Büro.

Ich markiere also das gewünschte Netzwerk und betätige den Button “Verbinden”.

Aber anstelle die Verbindung herzustellen, öffnet sich das Eigenschaft Fenster des ausgewählten Profils, mit dem Profil-Namen und der SSID den Netzwerkes usw. Ich denke, OK, dann gebe ich die Daten halt noch mal ein bzw. bestätige die Daten und speichere das Profil noch einmal. Aber genau dabei tritt das Problem auf.

Ich bekomme eine Meldung:

Klar ist das Profil schon vorhanden, und ja ich möchte das existierende Profil überschreiben, beim verwenden des vorhandenen Profils ist ja irgendein Problem aufgetreten (denke ich zu diesem Zeitpunkt jedenfalls noch).

Also auf ”Ja” geklickt und …. schon ist das nächste Problem da !

Ein Profilkennwort

Ich habe gar kein Kennwort !!!!!

Bei weiteren Versuchen das System irgendwie auszutricksen kommt es dann auch mal zu folgender Meldung

Nach vielem hin und her, habe ich dann versucht was geschieht, wenn man sich mit einem anderen Benutzer (oder einen neuen) Benutzer an diesem Rechnern anmeldet. Und siehe da, das (mein) Problem muss wohl irgend etwas mit meinem auf diesem Rechner gespeicherten Profil zu tun haben.

Ich suche also unterhalb von meinen persönlichen Daten in “C:\Dokumente und Einstellungen\[USERNAME]\Anwendungsdaten\” nach dem möglichen Speicherort der Profileinstellungen meiner Intel PROSet/Wireless Karte und werde schnell im Unterverzeichnis “Intel” fündig.

Nachdem ich noch die DAteiberechtigungen geprüft habe aber dabei auch nicht wirklich ein Problem feststellen kann, entschließe ich mich dazu das Verzeichnis Intel einfach zu löschen und hoffe dass ich danach so vorgehen kann als wenn ich bei einem neuem Benutzer die Konfiguration durchführe, und ich sollte damit recht haben.

Das Löschen des Verzeichnis C:\Dokumente und Einstellungen\[USERNAME]\Anwendungsdaten\Intel wobei [USERNAME] für den jeweiligen Benutzernamen steht, brachte den gewünschten Erfolg und ich konnte die neuen Profile einfach wieder anlegen.

Natürlich hatte ich das Verzeichnis bevor ich es gelöscht hatte, erst einmal gesichert, man weiß ja nie !

Ich bin mir nicht sicher wodurch dieses Problem entstanden ist und war bisher auch nicht in der Lage dieses Problem zu reproduzieren, aber eventuell hilft diese Beschreibung ja doch jemand anderem bei der Problembehebung.

Nachdem ich einige Aufräumarbeiten in den Inhalten meiner OneNote Notizbücher durchgeführt hatte, war mir aufgefallen dass die Dateigröße der einzelnen OneNote Dokumente (*.one Dateien) trotz nun erheblich weniger Inhalten noch immer unverändert groß waren.

In meinem speziellen Fall der “Nicht abgelegten Notizen” führte das zum Beispiel dazu, dass obwohl nun keine Notiz mehr enthalten war, die Dateigröße noch immer über 9 MB betragen hat.

Nachdem ich weder in der OneNote Hilfe noch im Internet auf Anhieb fündig geworden bin (ich hatte nach komprimieren bzw. verkleinern von OneNote Dokumenten gesucht), habe ich die Optionen von OneNote durchsucht und bin in der Kategorie “Speichern” dann doch noch fündig geworden.

“Dateien optimieren”

Dieser Begriff war mit bisher neu und da ich sicherlich beim nächsten mal wieder nicht weiß das mit Dateien optimieren, komprimieren gemeint ist, erstelle ich diesen Blog Beitrag.

Als Gedächtnisstütze sozusagen

Und wieder einmal bin ich darauf reingefallen!

Vor fast einem Jahr habe ich diesen Beitrag "Windows XP - Suche in Dateien - Ohne Ergebnis" verfasst und, dachte; so nun vergesse ich das nicht wieder.

Hab ich eigentlich auch nicht.

Nur wusste ich nicht, dass auf einem Windows 2003 Server das gleiche Problem existiert; tut es aber.

Heute Morgen wollte ich in einem Verzeichnis auf einem W2K3 Server Dateien nach einem darin enthaltenen String durchsuchen.

Also F3 gedrückt, den String, in diesem Fall eine Zahlenfolge, eingegeben, Suchen angeklickt.

Nach einigen Sekunden. immerhin waren ein paar Tausend Textdateien in diesem Verzeichnis, erhalte ich als Rückmeldung, dass keine Dateien gefunden wurden, die meinen zu suchende Zeichenfolge enthalten hat.

Da ich mir aber ganz sicher war das es mindestens eine Datei geben musste, habe ich mich mit dieser Information nicht zufrieden gegeben. Und da ich Remote auf der Maschine war, habe ich mir das Verzeichnis kurzerhand gezippt und über einen FTP Server schlussendlich auf meine lokale Workstation heruntergeladen, um dem Problem lokal weiter auf den Grund zu gehen.

ZIP File in ein Unterverzeichnis entpackt um die Detailsuche zu beginnen, vorher aber noch einmal (quasi zur Kontrolle):

F3, Suchstring eingegeben, Suchen angeklickt .....

Was ist denn nun los, da bekomme ich doch glatt 3 Dateien angezeigt.

Und genau, indem Moment, wo ich sehe welche Dateierweiterungen diese Dateien haben, fällt mir mein Beitrag von vor einem Jahr wieder ein.

Genau: Windows XP, und wie ich nun feststellen muss, auch Windows 2003 Server ignorieren bei der Suche alle Dateien, welche Sie nicht kennen. Dass sind Dateien mit unbekannten Dateierweiterungen (Extension). In diesem Fall handelt es sich eigentlich um Dateien mit der Endung txt. Allerdings werden in dem Verzeichnis Dateien archiviert und wenn eine Datei bereits vorhanden ist, dann wird diese nicht überschrieben (es sollten alle Versionen einer Datei erhalten bleiben), sondern es wird die Dateierweiterung als Zähler verwendet so wird zum Beispiel aus test.txt text.tx0 und dann test.tx1 usw.

Dabei werden Dateierweiterungen erzeugt die Windows in dem Fall Windoofs nicht kennt.

Doch es gibt Abhilfe (genau wie unter Windows XP). Man kann in der Registry einen Eintrag abändern (oder falls er nicht existiert, in einfach neu anlegen).

Der Eintrag lautet:

FilterFilesWithUnknownExtensions

und befindet sich im Registry Schlüssel:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ContentIndex]

Der dword Wert muss von 0 auf 1 umgestellt werden, und ab sofort durchsucht Windows auch Dateien, deren Dateierweiterung es nicht kennt. OK, das ganze hat auch einen Hasenfuß, es werden nun auch Binäre Dateien durchsucht und wenn man ganze Festplatten durchsuchen will, dann dauert nactürlich die Suche viel Länger, da alle Dateien und nicht nur die Dateien durchsucht werden, welche Windows bekannt sind.

Aber was nutzt eine schnelle Suche wenn man nicht sicher sein kann, dass das Ergebnis auch richtig ist.

So und nun mal gespannt. wann ich das nächste mal auf diese Falle hereinfalle.

Wer kennt das nicht, mal schnell eine Abfrage auf eine SQL Datenbank mit dem Microsoft SQL Server Management Studio gemacht, Ergebnis der Abfrage markiert und dann mit Copy / Paste das Abfrageergebnis einfach in Excel eingefügt.

Soweit geht das auch ohne Probleme. Störend dabei ist nur, dass die Spaltenüberschriften (Spaltenheader) nicht mit kopiert werden und man diese wenn man sie benötigt manuell übertragen muss.

Wenn man das Ergebnis mit Copy / Paste als Text in einen Texteditor einfügt, sind die Spaltenheader übrigens vorhanden.

Das kann aber auch in Excel so sein.

Das Microsoft SQL Server Management Studio besitzt einen Optionsschalter mit dem man dieses Verhalten steuern kann.

Der Optionsschalter befindet sich wie nachfolgend dargestellt unter Extras --> Optionen

Man muss einfach nur das Häkchen bei der Option:

Spaltenheader beim kopieren oder Speichern der Ergebnisse einschließen.

setzen und schon wird auch der Spaltenheader kopiert.

Übrigens kann man das Verhalten beim einfügen in einen Texteditor genau so steuern, nur da ist die Default Einstellung eben; das Häkchen ist gesetzt (siehe Abbildung).

Windows XP (Bei der Professional Version ist das wenigstens so) bietet Anwendungen die Möglichkeit Benutzernamen und die zugehörigen Passwörter für Netzwerkressourcen und Web Seiten zu speichern.

Die entsprechenden Einstellungen hierzu findet man unter:

Systemsteuerung --> Benutzerkonten --> Erweitert --> Kennwörter Verwalten

Diese Funktionalität ist, wenn man nichts an den Standard Einstellungen von Windows XP ändert nach der Installation aktiviert.

In der ersten Abbildung sehen wir das Fenster zur Verwaltung der "Gespeicherten Benutzernamen und Kennwörter" wenn diese Funktionalität aktiviert ist und bereits Benutzernamen für Netzwerkressourcen gespeichert sind.

Da diese Funktionalität in einer Standard Installation aktiviert ist, führt dies dazu, dass man eigentlich gar nichts darüber weiß wie man diese Funktionalität ein bzw. ausschalten kann. Wenn nun diese Einstellungen durch irgend etwas verändert wird ohne dass man sich dessen bewusst ist, dann wundert man sich darüber warum man nun nach jedem Neustart des Rechners beim Zugriff auf Netzwerkressourcen den Benutzernamen und das Passwort eingeben muss.

In meinem Fall kann ich nachvollziehen durch welches Ereignis das Problem entstanden war!

Ich hatte zu Testzwecken eine Software zur Anonymisierung von Internet Zugriffen installiert (Gott sei Dank nur auf einem Testsystem).

Diese Software hat, neben unzähligen anderen Einstellungen in der Registry, auch diese Einstellung um die es in diesem Beitrag geht einfach verändert. Diese Veränderten Einstellungen wurden weder Dokumentiert, Protokolliert, noch bei der Deinstallation dieser Software wieder in den ursprünglichen Zustand zurück gesetzt. Aber gut das ist ein anderes Thema.

Rein sachlich betrachtet ist einfach nur eine Einstellung der Lokalen Sicherheitsrichtlinie "Netzwerkzugriff: Speicherung von Anmeldeinformationen oder .NET Passports für die Netzwerkauthentifikation nicht erlauben" geändert worden.

In der zweiten Abbildung sehen wir übrigens wie sich diese Einstellung auf das Fenster zur Verwaltung der Gespeicherten Benutzernamen und Kennwörter auswirkt:

Der Button "Hinzufügen" ist gar nicht mehr vorhanden, es sind keine Benutzernamen in der Listbox vorhanden und dadurch sind auch die Button "Entfernen" und "Eigenschaften" deaktiviert.

Um die Einstellung wieder zu berichtigen müssen wir unter:

Systemsteuerung --> Verwaltung --> Lokale Sicherheitsrichtlinie --> Lokale Richtlinien --> Sicherheitsoptionen

Die Einstellung "Netzwerkzugriff: Speicherung von Anmeldeinformationen oder .NET Passports für die Netzwerkauthentifikation nicht erlauben" von Aktiviert auf Deaktiviert umstellen (siehe nachfolgende Abbildung):

Jetzt noch den Rechner neu starten, fertig!

Um Missverständnisse zu vermeiden möchte ich zuerst klarstellen dass ich kein Hardware Profi bin. Und so soll dieser Beitrag vor allem auch dazu Dienen, dass ich mich in einigen Monaten wieder daran erinnere was ich selbst getan habe um mein Problem, was ich nun beschreibe zu beheben.

Einer meiner Server (ich nenne ihn immer "den Alten" muss schon lange ausgetauscht werden, aber er läuft und läuft und ...), ein Fujitsu Siemens ist mit einem Adaptec 2100 Ultra Wide Raid Controller ausgestattet. In diesem Rechner werden 3 Hot Swap Festplatten im Raid-5 betrieben.

Nun ist, aus welchen Gründen auch immer bei einer der Festplatten die Rote Betriebsleuchte, oder soll ich besser sagen Störungsleuchte angegangen. Ich weiß aus der Vergangenheit (hatte das vor ca. einem Jahr schon mal) dass dies geschehen war, weil die Festplatte nicht mehr Synchron mit den anderen Festplatten war.

Nun habe ich gedacht, dass ich beim letzten mal dem Raid Controller per Software gesagt habe, dass er die abgehängte Festplatte wieder synchronisieren soll. Aber meine Suche nach der Software mit der ich dem Controller dieses gesagt haben wollte, konnte ich einfach nicht finden, vermutlich gibt es eine solche Software, aber es geht eben auch ohne.

Nachdem ich aber die Software einfach nicht finden konnte, habe ich aber doch noch Glück gehabt und habe mich kurz darauf daran erinnert was ich das letzte mal bei einem solchen Problem gemacht hatte. Übrigens ist das genau der Grund warum ich es dieses mal aufschreibe, ich möchte das nächste mal einfach meine eigenen Notizen lesen und wissen was ich zu machen habe.

Hier nun kurz und amateurhaft die Beschreibung dessen was ich gemacht um die abgehängte Festplatte im Raid wieder zu synchronisieren.

Ich habe einfach die Festplatte aus dem Einschub herausgezogen (während des Betriebs, sind ja Hot Swap Festplatten), und dann nach einer kurzen Zeit (1 Minute) die Festplatte wieder in den Einschub gesteckt. Nach einigen Sekunden hat der Controller erkannt das ich eine Festplatte in den Einschub geschoben habe und sofort hat der Controller angefangen die Festplatten zu synchronisieren (Rote und Grüne Lampen haben wild geblinkt).

Nach ca. 24 Stunden (können auch einige Stunden weniger gewesen sein, habe nicht die ganze Nacht vor dem Rechner verbracht) hat das wilde Blinken der Roten und Grünen Lampe aufgehört, die Rote Lampe ist danach ausgegangen und die Grüne Lampe blinkt nun wieder rhythmisch mit den Grünen Lampen der beiden anderen Festplatten.

Wie ihr, anhand meiner recht amateurhaften Beschreibung von blinkenden Grünen und Roten Lampen der Festplatten, feststelle könnt bin ich nicht der Hardware Profi, aber das habe ich einleitend ja bereits erwähnt.

Aber wer weiß, eventuell geht es ja jemand der auch kein Hardware Profi ist mal genau so und stolpert über diesen Beitrag und die Informationen hier können Ihm/Ihr helfen das System wieder Normal Betreiben zu können.

Anregungen und Vorschläge wie man es besser (anders) hätte machen können dürfen natürlich gerne als Kommentar hinterlassen werden.

In  der Anwendung's Ereignisanzeige (Application Event log) erscheint immer wieder mal der folgende Eintrag wenn ich den Rechner (Dell Notebook Precision M65 ) hochfahre.

Trotz dieser Meldung scheint zwar alles zu funktionieren, aber da ich Fehlermeldungen nicht wirklich spannend finde, habe ich nach der Ursache gesucht.

Nach ersten Google Sitzungen scheint es ganz verschiedenen Meldungen und Lösungsansätze um diese Fehlermeldung zu beheben.

Nun möchte ich in diesem Beitrag eigentlich gar nicht über die Behebung oder nicht Behebung dieses Fehlers reden, sondern über einen, durch den Versuch dieses Problem zu beheben, selbst erzeugten anderen Fehler berichten.

In einem der Hinweise wodurch dieser Fehler entstehen kann und was man dagegen unternehmen kann, wurde berichtet, dass man in der Registry einen Eintrag zu dem nachfolgend abgebildeten Schlüssel hinzufügen soll.

Es handelt sich dabei um den Schlüssel: DisableDHCPMediaSense.

Den man in der Registry unter Arbeitsplatz\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters als DWord Eintrag mit dem Wert 1 hinzufügen soll.

Das habe ich dann auch getan, und konnte danach einfach weiterarbeiten. Ein Anruf von einem Kollegen hat mich beschäftigt so, dass ich die Änderung in der Registry erst einmal vergessen hatte. Ich konnte auch noch am gleichen Abend zu Hause in meinem WLAN und am nächsten Tag wieder im Büro über das Netzwerk arbeiten.

Als ich dann aber am nächsten Abend zu Hause den Notebook hochgefahren habe, bekommt der WLAN Adapter plötzlich keine IP Adresse über DHCP vom Router zugewiesen.

OK; kann j mal passieren habe ich gedacht un habe zuerst vermutet der Router spinnt, also Router neu gestartet...  nichts, geht nicht, keine IP für meinen Notebook.

Einen anderen Rechner (Notebook meiner Gefährtin) eingeschaltet, IP Adresse erneuern lassen..., geht.

An meinem Rechner hin und her gemacht , Release IP (ipcionfig /release) Renew IP (ipconfig /renew), mit Mühe bekomme ich mal eine IP Adresse dann wieder nicht.

Dann fällt mir ein: Kurz vor dem Problem hatte ich das SP1 für Office 2007 installiert, sollte das an meinem Problem schuld sein (Vorab schon mal- Nein das Office Service Pack war nicht schuld.)?

Wie sieht es denn mit den Treibern für die WLAN Karte aus, solle das SP irgendwie meine WLAN Treiber.... eigentlich haben die nicht mit... zu tun. Aber es gibt einen aktuelleren Treiber und es wird auch empfohlen diesen zu installieren, wenn ich auch nicht ermitteln kann was dieser neue Treiber für Probleme beheben soll. Aber wer weiß eventuell hat ja doch der SP von Office... (Nein wirklich nicht, wir wissen ja schon der SP war nicht schuld).

Nach ... na ja es war schon einiges länger als eine (einige) Stunde(n), rufe ich Regedit auf um irgend etwas zu kontrollieren und ....!? Da sehe ich doch meinen letzten Eintrag den ich gemacht habe (das ist etwas mehr als 48 Stunden her gewesen) "DisableDHCPMediaSense = 1".

Hm, könnte dieser Eintrag .... (Auch hier schon mal vorab, ja der Eintrag war es)?

Und plötzlich war "fast" alles klar.

Der Lease (die Zeit die der Router erst einmal die IP Adresse für einen bestimmten Rechner reserviert) war nach 48 Stunden abgelaufen.

Wegen des Eintrags in der Registry (auch wenn ich nicht genau verstanden habe was dieser Eintrag bewirken soll) hat mein Rechner keine neue IP Adresse vom Router (DHCP im Router) angefordert, oder der Router hat wegen des Eintrags irgend etwas falsch verstanden und hat deswegen keine neue IP Adresse an den Rechner gesendet.

Wer da was nicht getan hat ist aber auch irrelevant, Fakt ist das mein Rechner keine IP Adresse vom DHCP des Router's bekommen hat und deshalb keine  Netzwerkverbindung herstellen konnte.

Nachdem ich den Eintrag in der Registry auf 0 gestellt habe, hat wieder alles einwandfrei funktioniert.

Bis auf mein Problem Event ID 1054, weshalb ich ja zum Test den Eintrag in die Registry gemacht hatte.

Ich habe dieses Problem nicht akribisch analysiert und ich kann nicht sagen ob dieses von mir beschrieben Problem nur in meinem System oder auch auf anderen Systeme Auftritt, ich schreiben diesen Beitrag um mich selbst daran zu erinnern und eventuell hat ja irgend jemand mal ein ähnliches Problem und stolpert dann genau über diesen Beitrag.

Manchmal sind die Kausalitäten eben nicht so einfach zu erkennen.

In diesem Beitrag geht es um die Einrichtung des Open Source Zugriffsstatistik Tool AWStats in Verbindung mit DotNetNuke.

Systemvoraussetzungen

Zuerst einmal die Voraussetzungen die erfüllt sein müssen, damit man dieses Analyse Tool zusammen mit DotNetNuke einsetzen kann:

• PERL Erweiterungen müssen installiert und aktiviert sein
• Internet Log Dateien im IIS müssen aktiviert sein oder/und
• In den Systemeinstellungen in DotNetNuke muss als Protokollspeicher das Dateisystem gewählt sein (siehe nachfolgende Abbildung)
  
  

Verwendung des IIS Protokolls

Wenn man das Protokoll des IIS verwenden möchte dann sollte man die nachfolgenden Einstellungen dazu verwenden:

Um den Speicherort der Log Dateien zu ermitteln (ja den brauchen wir später) genügt ein Klick auf Eigenschaften:

Dort können wir sehen wo die Log Dateien abgelegt werden und wie sie benannt werden. In unserem Hier abgebildeten Beispiel ist das:

Allgemeine Verzeichnis für Protokolle des IIS D:\Logs und das Unterverzeichnis in dem die Log Dateien dieses web abgelegt werden hat hier den Namen W3SVC1338318087. Also lautet der Zugriffspfad zu den Protokollen D:\Logs\W3SVC1338318087. Darin werden die Logdateien vom IE erstellt.

Verwendung des DotNetNuke Dateisystem Protokolls

Um die Einstellungen in DotNetNuke vornehmen zu können muss man sich als Systemadministrator (Host) anmelden. Dann muss man zunächst in den Systemeinstellungen kontrollieren ob, und gegebenenfalls die Einstellungen korrigieren, das überhaupt eine Loginformation erzeugt wird.

Um überhaupt eine Protokollierung der Seitnaufrufe in DotNetNuke zu aktivieren, müssen die beiden Einstellungen wie folgt vorgenommen werden:

Im Feld Protokollzeitraum muss mindesten der Wert 1 (1 Tag) angegeben werden damit ein Protokolleintrag erstellt wird.
Wenn der Wert 0 eingegeben wird, wird das Protokoll deaktiviert (es geschieht also gar nichts, weder in einem Datenbank noch in einem Dateisystem Protokoll).

Im Feld Protokollgröße sollte für normal stark frequentierte Seiten einfach eine 1 eingetragen werden, bei stärker frequentierten Seiten (> 500000 Zugriffe / Monat) sollte man mit höheren Werten experimentieren. Eine 0 in diesem Feld führt ebenfalls dazu dass keine Zugriffsprotokollierung erfolgt.

Um nun die Protokollierung in einem Format zu speichern, welches  von AWStats verwendet werden kann um die Zugriffsstatistik zu erstellen, muss noch die Einstellung Portalprotokollspeicher auf Dateisystem eingestellt werden.

Hinweis zur DotNetNuke Einstellung bzw. der Übersetzung der Einstellung

An dieser Stelle möchte ich einen Hinweis auf eine nicht richtig verstandene (übersetzte) Einstellung geben. Dazu schauen wir uns einen Teilbereich der Systemeinstellungen, einmal im Original (in  Englisch) an,  und einmal in der Deutschen Übersetzung:

Hier zuerst der Ausschnitt der Einstellung im Original:

Und hier in der Übersetzung:

Aus dem englischen "Site Log Buffer (Items)" wird Protokollgröße (Einträge).

Protokollgröße impliziert, dass man mit dieser Einstellung die Größe oder Anzahl der Einträge in der Protokolldatei einstellen würde.

Dem ist aber nicht so.

Mit dieser Einstellung gibt man vor ob die Daten des Protokolls gepuffert (Schreibvorgang erst nach Anzahl Einträgen durchführen) oder ungepuffert (nach jedem Eintrag sofort in die Log Datei schreiben) geschrieben werden. Außerdem führt ein Eintrag von 0 dazu dass die gesamte Protokollierung deaktiviert wird.

Technisch könnte man die Einstellungen wie folgt definieren:

• 0 bedeutet Protokollfunktion ist ausgeschaltet
• 1 ungepuffert (Protokoll wird bei jedem Eintrag sofort geschrieben) [Eventuell Performanceproblem bei Seiten mit vielen Zugriffen]
• > 1 Anzahl Einträge die gepuffert werden bevor ein Schreibzugriff stattfindet.

Nun aber zurück zu dem eigentlichen Thema dieses Beitrags "Wie richte ich AWStats zusammen mit DotNetNuke ein".

Nachdem die Einstellungen, wie hier beschrieben, vorgenommen wurden, wird das Zugriffsprotokoll nun im Dateisystem und nicht mehr in der Datenbank erstellt. Die Protokolle werden im Unterverzeichnis Logs des jeweiligen Portal Root Verzeichnisses angelegt (Beispiel wenn DotNetNuke auf C:\DotNetNuke installiert ist, dann findet man die Log Dateien für da Portal 0 (wenn man keine abweichen Benamung vorgenommen hat) im Verzeichnis C:\DotNetNuke\Portals\0\Logs). Diese Information benötigen wir später zur Konfiguration von AWStats.

Einrichtung und Konfiguration AWStats

AWStats kann komplette mit Source direkt von hier herunter geladen werden (Bitte das ZIP File herunterladen).

Die Beispiel Konfigurationsdateien für DotNetNuke kann man hier herunter laden:

Jetzt entpackt man das AWStats Archiv und kopiert alles aus dem Unterverzeichnis wwwroot ist in das Root Verzeichnis von DotNetNuke, das sind folgende Verzeichnisse.

Danach entpackt man die Dateien aus dem Konfigurationsarchiv direkt in das cgi-bin Verzeichnis.

Und jetzt sind noch folgende Anpassungen an den Konfigurationsdateien vorzunehmen:

Falls man den Namen der Konfigurationsdatei awstats.www.myDomain.de.conf nicht ändert, muss man in der Batch Datei Updatestats.bat keine Änderungen vornehmen. Wenn man die Konfigurationsdatei aber umbenennt, muss man den Namen in der Batch Datei anpassen.

Also die Zeile perl awstats.pl -config=www.MyDomain.de -update, so anpassen, dass der Name der Konfigurationsdatei richtig angegeben ist.

Die Konfigurationsdatei ist schon soweit vorbereitet, dass man lediglich für die Einrichtung mit der DotNetNuke Protokoll Datei die Herkunft der Protokolldateien, also den richtigen Pfad eintragen muss. Dazu öffnet man die Datei awstats.www.myDomain.de.conf mit einem Texeditor und sucht folgende Stelle:

LogFile="C:\DotNetNuke\Portals\0\Logs\ex%YY-6%MM-6%DD-6.log"

Hier ersetzt man nun den Teil  C:\DotNetNuke\Portals\0\Logs der Pfadangabe mit dem Pfad den wir aus unserer Installation ermittelt haben.

Nun sucht man den Eintrag:

SiteDomain=www.schelian.de und ersetzt www.schelian.de mit dem Namen der Domain für den AWStats eingerichtet werden soll.

Wenn man das Protokoll vom IE anstelle des DotNetNuke Protokolls verwenden möchte, muss man zusätzlich zum eben genannten Eintrag noch den Parameter LogFormat ändern.

Dazu sucht man den nachfolgenden Eintrag in der Konfigurationsdatei:

LogFormat="date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) sc-status sc-substatus sc-win32-status"

und kommentiert ihn durch voranstellen eines # aus.

Anschließend entfernt man das Kommentarzeichen am Anfang der folgenden Zeile.

#LogFormat="date time s-sitename s-computername s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs-version cs(User-Agent) cs(Cookie) cs(Referer) cs-host sc-status sc-substatus sc-win32-status sc-bytes cs-bytes time-taken"

So dass diese Zeile gültig ist.

Nun richtet man im Windows Zeitplandienst (Scheduler) noch eine Aufgabe (Task) ein der Alle 6 Stunden die Batch Datei Updatestats.bat ausführt.

Damit ist die Einrichtung von AWStats soweit abgeschlossen, dass AWStats die Protokolldateien analysiert und umfangreiche Statistiken erstellt.

Anzeige der Statistiken

Was nun noch fehlt ist der Aufruf (die Anzeige) der Statistik.

Wenn die Domain www.mydomain.de heißt, dann lautet der Aufruf zur Anzeige der Statistik www.mydomain.de/cgi-bin/awstats.pl.

Noch ein Hinweis zum Schluss:

Sollte man bereits alte Protokolle haben, welche man durch AWStats abarbeiten lassen möchte, so kann ich hier auf einen früheren Beitrag hinweisen, der sich genau mit diesem Thema befasst.

Hier der Link zum Beitrag: http://blog.schelian.de/2005/02/06/AwstatsAlteLogDateienEinlesen.aspx

Das Problem äussert sich wie folgt:

Im IE auf den Download Link einer Datei geklickt. Danach öffnet sich das hier abgebildete Fenster. Dann auf den Button Speichern geklickt, es öffnet sich das Fenster um "eigentlich" das Verzeichnis auswählen zu können, wo die Datei gespeichert werden soll. Es kommt aber nicht mehr dazu dass man eine Auswahl treffen kann, denn .....

Das war's, jetzt geschieht nichts mehr, keine Auswahl.

Im Taskmanager einfach nur die Meldung "Keine Rückmeldung", den Task beenden kann man auch nicht (wenigsten nicht beim ersten mal).

Das ganze geht dann einige Minuten so und wenn man lange genug Geduld hat .....

Ich hatte Sie nicht, aber wer hat schon die Geduld Minutenlang darauf zu warten das ein Fenster sich überlegt doch noch weiter zu arbeiten.

Nachdem dieses Problem Heute zum wiederholten mal (2 oder 3 mal) aufgetreten ist und ich die ersten male nicht so genau wusste wo ich ansetzen sollte und vor allem sich das Problem wieder von selbst gelöst hatte, ist mir Heute als das Problem wieder aufgetreten ist plötzlich einfach klar gewesen, was das Problem sein muss (und auch war).

Ich hatte zuvor im Büro auf einem UNC Pfad (Netzwerklaufwerk) eine Datei beim Download gespeichert. Bin dann zu Hause mit meinem Notebook (ohne eine VPN Verbindung zum Büro herzustellen) ins Internet gegangen und wollte eine Datei herunterladen, mit dem hier beschriebenen Ergebnis.

Aber wie bereits gesagt, dieses mal, war mir sofort klar was geschehen war, der IE speichert den zuletzt gewählten Speicherort beim Download einer Datei (in der Registry). Der von mir zuletzt verwendete Speicherort war aber dieses Netzwerklaufwerk, dass ohne VPN Verbindung von zu Hause aus nicht verfügbar ist.

BINGO !!

Nun versucht der IE, mit unglaublicher Hartnäckigkeit aber genau zu diesem Speicherort eine Verbindung herzustellen, natürlich Erfolglos da das Netzwerk ja nicht erreichbar ist.

Ich weiß gar nicht ob das bei früheren Versionen des IE auch schon so war, aber beim IE7 ist es auf jeden Fall so.

Sollte jemand das Problem haben, kann er, wenn er es früh genug merkt, dadurch beheben einfach in der Registry folgenden Eintrag manuell zu ändern:

In der Registry heißt der Schlüssel wie folgt:

HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Download Directory

Einfach als Wert C:\ eintragen (oder jeden anderen existierenden Pfad) und dann reagiert der IE wieder ganz normal beim Klick auf den Speichern Button.

Vor einigen Wochen habe ich mein neues Notebook "DELL PRECISION M65" in Empfang und auch in Betrieb genommen. Das Teil nennt sich Mobile Workstation und ich bin mit der Leistung des Gerätes auch ziemlich zufrieden.

Wenn da nicht.... !

Ja wenn da nicht das Problem mit den langen lade und Speicherzeiten für Dokumente auf Netzwerklaufwerken aufgetreten wäre.

Nun ist es, wenigstens bei mir ist es so, dass ich mittlerweile die meisten Dokumente auf meinem Notebook pflege und diese dann entweder auf irgend ein Web lade, oder diese bei mir im Büro auf ein Netzwerk synchronisiere. 

Das geschieht meistens nicht so, dass ich darauf warte und mir die Verarbeitungszeiten dabei schmerzlich bewusst werden, sondern während ich andere wichtige Dinge mache, Kaffe holen, etwas Esse, mit meiner Liebsten Telefoniere oder ähnlichem.

Durch diese Arbeitsweise ist mir das hier beschrieben Problem zwar von Anfang an aufgefallen, aber die Notwendigkeit zur raschen Analyse des Problems war nicht so groß, da ich im Gegensatz zu früher, viel weniger direkt Dokumente von einem Netzwerklaufwerk öffne, bearbeite und wieder speichere.

Aber eben nur weniger und nicht gar nicht mehr vorhanden, und so ist mir immer wieder aufgefallen, dass ich nachdem ich mit dem "neuen" Notebook gearbeitet habe, elend lange lade und Speicher Zeiten hatte.
Vor allem bei Office Dokumenten hat das speichern eines einseitigen Word Dokuments auf dem Netzwerklaufwerk schon gerne 30 - 40 Sekunden gedauert.

Also habe ich dann doch etwas intensiver nach dem Problem gesucht.

• Eine Internet Recherche hat nicht wirklich was ergeben.
• Die Vermutung dass es sich um ein Problem der Netzwerkkarte und oder des Funk Netzes handelte hat sich auch als falsch erwiesen.
• Und dann bin ich mehr oder weniger durch Zufall auf die Ursache meines Problems gestoßen.

Ich hatte meinen Notebook natürlich gleich mit einiger Software bestellt. Der Unter Windows XP laufende Rechner hat dabei natürlich auch einen Virenscanner und sonstige Sicherheitssoftware erhalten.

Ich hatte mich dabei, zum ersten mal für McAfee und das Security Center entschlossen, vorher war ich immer mit Norton unterwegs. Und genau mit dem McAfee Security Center hängt auch mein Problem zusammen.

Es gibt da unter Virenschutz den Echtzeit-Scanner und dort die Option "Netzlaufwerke überprüfen". Dies ist sicherlich sinnvoll, aber in meinem Fall ist diese Option genau das Problem. Und da ich auf meinem Dateiserver einen eigenständigen Virenscanner laufen habe bin ich in der Lage auf diese Option zu verzichten.

Nachdem ich diese Option deaktiviert habe, kann ich wieder mit gewohnter Geschwindigkeit Dateien aus dem Netz laden und auch wieder speichern.

Installiert habe ich übrigens die folgende Version des Security Center's

Seit einiger Zeit arbeite ich sehr zufrieden mit einem DELL Notebook (Precision M65). Nachdem ich einige Webseiten auf DotNetNuke (DNN) 4.X umgestellt, und dabei auch den Editor von FTB auf FCK gewechselt habe, bin ich aber auf ein Phänomen gestoßen, dass mich fast zur Verzweiflung getrieben hat.

Zuerst dachte ich ja, es würde an DotNetNuke und- oder an dem FCK Editor liegen, denkste!

Aber zuerst schildere ich doch mal kurz das Problem:

Wenn man einen neuen Text erstellen oder einen vorhandenen Text in DotNetNuke bearbeiten möchte, wird die Bearbeitungsseite mit einem FCK Editor angezeigt. In diesem Editor gibt es nun verschiedene DropDown Listen (ComboBox):

• Stil
• Format
• Schriftart
• Größe

Wenn ich nun eine dieser DropDown Listen verwenden wollte, dann wurde der Inhalt der Auswahlliste nicht korrekt dargestellt, siehe nachfolgende Abbildung:

Das führt dazu dass man eigentlich die Texte nicht richtig formatieren konnte und war frustrierend. Ich habe zwischenzeitlich nur noch Firefox als Browser eingesetzt da dieses Problem mit Firefox nicht aufgetreten ist sondern lediglich mit dem IE (Internet Explorer) sowohl in der Version 6 wie auch in der Version 7.

Ich möchte an dieser Stelle auch keine Diskussion lostreten wie:

"Der Firefox ist doch sowieso besser..."

Ich und meine Kunden verwenden nun neben dem Firefox halt auch den IE und damit sollte auch eine Web Anwendung wie DotNetNuke oder ähnliche bedient werden können.

Da ich nicht ausschließlich, aber doch den größten Teil meiner Arbeit auf meinem Notebook verrichte, bin ich dann aber vor einigen Tagen mehr durch Zufall gerade nachdem ich wieder mal über diesen Bug gefrustet war, auf einem anderen Rechner auf meine Web Seite (bei der ich gerade das Problem mit meinem DELL Notebook hatte) gegangen, weil ich einen Text ändern musste.

Und was musste ich feststellen:

Kein ComboBox Probleme, die Fenster werden alle wunderbar dargestellt.

Was war anders ?

Ich habe das dann mit mehreren Rechner und verschiedenen Versionen des Betriebssystems, Browsers und so weiter ausprobiert.

Irgendwie hat sich das ganze immer wieder auf meinen DELL Notebook konzentriert und mit "allen" anderen Rechner gab es das Problem nicht.

Nein ich war nicht gewillt wegen dieses Problem meinen DELL Notebook einfach noch mal neu zu installieren (Eine Entwicklermaschine, klar geht ja auch in zwei Minuten). Googlen hat auch nicht geholfen, nicht nur dass diesen Problem scheinbar nur auf dem DELL Notebook aufgetreten ist, nein es schien als gäbe es das Problem wirklich nur bei mir.

Aber gut genug geredet (geschrieben) hier nun die Lösung meines Problems:

Bei meinem Dell Notebook gibt es in der Taskleiste das Symbol Dell QuickSet

Ein Klick auf dieses Symbol öffnet ein Kontextmenü:

Und hier gibt es das Menü Skalierung des Internet Explorers, und diese Option ist im Standard aktiviert und führt genau zu den von mir in diesem Artikel beschriebenen Problemen.

Also einfach diese Option deaktivieren und das Problem mit den falsch dargestellten DropDown Listen ist aus der Welt geschafft.

Hier ein einfaches SQL Skript um doppelte Datensätze in einer Tabelle zu finden und anzeigen zu lassen.

Im Beispiel gehen wir von folgenden Informationen aus:

Die Tabelle in der Datenbank heißt: Products

Das Referenzfeld in der Tabelle heißt: productcode

SELECT productcodes, COUNT(productcode) AS NumOccurrences
FROM Products
GROUP BY productcode
HAVING ( COUNT(productcode) > 1 )

Angezeigt bekommt man alle productcodes der Datensätze die mehr als einmal in der Tabelle vorhanden sind.

Bei der Standard Installation von MSDE wird wenn nicht extra per Parameter angegeben die MSDE Instanz mit Integrierter Sicherheit installiert.

Wenn man nun aber gemischte Sicherheit benötigt gibt es eigentlich nur die Möglichkeit die MSED zu deinstallieren und noch einmal mit dem Parameter SECURITYMODE=SQL zu installieren.

Es gibt aber eine Möglichkeit die MSDE Konfiguration nachträglich per Änderung der Registry zu ändern.

WARNUNG: Bevor Sie die Registry ändern sollten Sie unbedingt vorher eine Datensicherung der Registry anlegen.

Bevor Sie die Änderungen in der Registry vornhemen sollten Sie die SQL Dienste beenden.

Um den Registry Editor zu öffnen gehen Sie wie folgt vor.

Im Startmenu wählen Sie ausführen und geben dort regedit ein und bestätigen die Eingabe mit OK .

Im Registry Editor suchen wir nun den Schlüssel:

Wenn Sie eine Standard Instantz erstellt haben:

• HKEY_LOCAL_MACHINE\Software\Microsoft\MSSqlserver\MSSqlServer\

Wenn Sie eine benannte Instanz erstellt haben:

• HKEY_LOCAL_MACHINE\Software\Microsoft\Microsoft SQL Server\Instance Name\MSSQLServer\

Im rechten Fenster suchen Sie nun den Schlüsseleintrag LoginMode und ändern den Wert von 1 auf 2 ab.

Nun starten Sie die SQL Dienste neu.um die neue Konfiguration zu übernehmen

Wer das Internet Statistik Tool Awstats einsetzen möchte wird in vielen Fällen mit dem Problem konfrontiert, dass man bereits vorhanden Log Dateien des Internet Server einlesen möchte um eine Statistik zu bekommen die nicht erst beginnt wenn man das Awstats Tool installiert hat.

Das Problem was sich hierbei ergibt, ist, dass Awstats chronologisch die Daten einlesen muss und nicht nachträglich mit alten Log Informationen gefüttert werden kann.

Um Daten einzulesen verwendet Awstats sie Syntax:

awstats.pl -config=www.domain.de -update

mit einem zusätzlichen Parameter -LogFile ist es möglich die einzulesende LogDatei anzugeben, die Syntax sieht dann wie folgt aus:

awstats.pl -config=www.domain.de -LogFile=C:\Logs\WS1212121\ex050202.log  -update

Damit könnte man nun die Dateien manuell in der chronologischen Reihenfolge einlesen.

Ein sehr mühsames vorgehen.

Eine wesentlich einfacherer Methode ist es da schon eine Batch Datei zu erstellen die das automatisch macht.

Erstellen Sie also eine Batch Datei mit folgenden Inhalt:

for %%x in (D:\Logs\W3SVC1003470241\*.log) do perl awstats.pl -config=www.domain.de LogFile=%%x -update

Sie müssen natürlich in der Datei die Pfade und Konfiguration gegen Ihre ersetzen.

Nun führen Sie die Batch Datei aus und es werden alle vorhandenen Log Dateien chronologisch verarbeitet.

Outlook XP (Office 10) ermöglicht es das Outlook sobald es minimiert wird, es als Symbol im Tray- Bereich anzuzeigen.

Hierzu muss ein undokumentierter Eintrag in der Registry gemacht werden.

Und so geht es:

Start Sie das Programm regedit.exe

Navigieren Sie nun zum Schlüssel:

HKEY_CURENT_USER\Software\Microsoft\Office\10.0\Preferences

Fall der Schlüssel MinToTray noch nicht existiert müssen Sie diesen erstellen. Hierzu klicken Sie mit der rechten Maustaste in das rechte Fenster und wählen aus dem Kontextmenü Neu - DWORD-Wert.

Geben Sie nun als Schlüsselwert MinToTray ein (auf genaue Schreibweise achten).

Nun doppelklicken Sie den Eintrag MinToTray und ändern den Wert von 0 auf 1.

Um die Änderungen zu aktivieren müssen Sie Outlook beenden und neu starten.

Schlüsselwerte:

0 = Outlook wird nicht in die Tray minimiert
1 = Outlook wird nach dem mminimieren in der Tray angezeigt.