Auf die Gefahr hin, dass einige Leser diese Seite bereits kennen:
Unter http://itc.napier.ac.uk/e-Petition/bundestag/view_petition.asp?PetitionID=321
kann man noch bis zum 28. November eine Petition zur Änderung des Bundeswahlgesetzes mit dem Ziel der Abschaffung von Wahlcomputern mitzeichnen.
Ich fordere jeden, der die Petition noch nicht unterzeichnet hat, auf dies zu tun, weil es um nicht weniger als den Fortbestand demokratischer Grundprinzipien wie der Wahrung des Wahlgeheimnises und der Überprüfbarkeit von Auszählungen geht.
Dass Wahlcomputer nicht nur theoretisch Angriffsmöglichkeiten auf unser Wahlsystem bieten sondern diese auch ganz praktisch ausgenutzt werden können, wurde in den letzten Wochen sehr anschaulich bewiesen. Eine Chronologie der bisherigen Ereignisse ist bei Florian Holzhauer zu finden.
DonAlphonso schreibt über den aktuellen "Web 2.0"-Hype und die offensichtlichen Probleme, die bei den Unternehmen in diesem Geschäftsfeld zu erwarten sind. Ein lesenswerter Artikel, der versucht hinter die scheinbaren Erfolgsgeschichten zu blicken.
Nachdem das Problem mit dem Einrichten des Exchange-Accounts gelöst war, sollte noch der Outlook Web Access so eingerichtet werden, dass man auch von außen darauf zugreifen kann. Dazu wurde ein zusätzlicher "Virtueller Server" für das HTTP-Protokoll eingerichtet. Merkwürdigerweise ließ sich aber kein SSL-Port angeben. In der IIS-Management-Console konnte man zwar einen SSL-Port angeben, diese Konfiguration wurde aber kurze Zeit später wieder von Exchange überschrieben.
Die Lösung für dieses Problem stand dann wieder einmal in einem Knowledge-Base-Artikel: Es ist nicht möglich den gleichen virtuellen Server für OWA so einzurichten, dass er sowohl mit als auch ohne SSL-Verschlüsselung funktioniert. Deshalb muss man die Einstellung für den "normalen" Port erst löschen, bevor man den SSL-Port angeben kann.
In der Hilfe zu der entsprechenden Einstellung sucht man aber natürlich vergeblich nach einem Hinweis darauf...
Die meisten Web-Entwickler werden die Firefox-Extension FireBug kennen.
Dieses schöne Werkzeug ermöglicht es unter anderen den DOM-Tree eines im Browser angezeigten Dokuments zu inspizieren (und zwar nicht den ursprünglichen HTML-Code, sondern genau den Baum, wie er für die aktuelle Anzeige verwendet wird).
Leider hat dieses Add-On einen kleinen Fehler, der einen aber ziemlich Nerven kosten kann:
So bietet FireBug unter anderem auch die Möglichkeit das XmlHttpRequest-Objekt zu überwachen. Auf diese Weise kann man sich die gesendeten Anfragen und die vom Server kommenden Antworten anzeigen lassen um z.B. JavaScript-Probleme bei AJAX-Anwendungen besser debuggen zu können.
Es trat jedoch das merkwürdige Problem auf, dass, sobald FireBug akiviert war, eine bestimmte AJAX-Anwendung nicht mehr richtig funktionieren wollte: Der Request wurde zwar korrekt gesendet und die Antwort auch empfangen, allerdings wurde der "onReadyStateChange"-EventListener nicht aufgerufen, so dass das Skript die Antwort nicht verarbeiten konnte. Offensichtlich trat dieses Problem mit anderen Applikationen (die genau so funktionieren) aber nicht auf.
Nach viel Herumprobieren stellte sich schließlich folgendes heraus: Der open()-Methode des XmlHttpRequest-Objekts muss als dritter Parameter (Aktivierung des asynchronen Modus) explizit ein "true" übergeben werden. Bei deaktiviertem FireBug oder auch in anderen Browsern funktioniert es auch ohne diesen Parameter, ein Fehler in FireBug scheint aber dafür zu sorgen, dass ohne explizite Angabe das Ereignis nicht mehr korrekt verarbeitet wird. Dies ist insofern ärgerlich, dass die Spezifikationen des XmlHttpRequest-Objekts diesen Paramter nicht als Pflichtparameter betrachten. Bei aktivierter XmlHttpRequest-Überwachung, dürfte also auch so manch andere AJAX-Anwendung nicht mehr richtig funktionieren.
Microsofts Produkte sind dafür bekannt in der Bedienung manchmal einer etwas merkwürdigen Logik zu folgen. So bin ich bei der Einrichtung eines Exchange Servers 2003 in einer bestehenden Active Directory Domain vor einigen Tagen auf das Problem gestoßen, dass sich für einen bestimmten (bereits im Active Directory vorhandenen) Benutzer der Exchange-Account nicht richtig einrichten lassen wollte:
Obwohl ein Exchange-Postfach für diesen Benutzer angelegt war, kam beim Versuch Outlook mit diesem Exchange-Account zu verbinden immer nur die folgende Meldung: "Der Name befindet sich nicht in der Adressliste."
Continue reading "Microsoft-Logik & Exchange-Server"
Die letzten Wochen war es hier ziemlich ruhig. Das lag vorallem daran, dass inzwischen die Vorlesungszeit wieder angefangen hat und ich daher kaum Zeit hatte etwas zu bloggen.
Deshalb werde ich in Kürze einige Artikel zu Themen veröffentlichen, mit denen ich mich in den letzten Tagen und Wochen auseinandergesetzt habe.
