Wie bereits bekannt, gab es seit einiger Zeit eine Schwachstelle in der _layouts/help.aspx (Security Advisory 983438), welche durch den morgigen Patchday behoben wird! Zu dieser Schwachstelle gab es einen Demo Exploit, welcher die Verwundbarkeit aufzeigt.

Durch die zehn Security Bulletins werden insgesamt 34 Sicherheitslücken in Windows, Internet Explorer, Office und SharePoint gestopft. Der Patchday ist am morgigen Dienstag (08.06.2010).

Hier geht’s zur Microsoft Security Bulletin Advance Notification for June 2010.

Google erfasst seit einigen Jahren unter dem Namen “StreetView” viele Daten von Städten aus aller Welt. Dabei wurden beispielsweise Bilder für eine 3D Fahrt durch die Umgebung gemacht, welche z.B. in Google Maps genutzt werden. Jeder hat sicherlich schon einmal etwas von den kleinen bunten Autos gehört, welche regelmäßig durch Datenschützer angeprangert werden, weil sie eine Einschränkung im Persönlichkeitsrecht sehen.

Seit einiger Zeit sammelt Google jedoch nicht nur reine Bilddaten, sondern verbindet diese Fahrten, um unter anderem auch noch WLAN Netze zu erfassen. Bisherige Informationen durch Google bestätigen das sammeln von Daten über öffentliche Hotspots, deren SSID öffentlich sichtbar ist. Hier sollten nur die SSID und die MAC Adresse gespeichert werden und dies auch nur während der Kartografierung und nicht als reine “Dateneinsammlungstour”. Es wurde eine Aufklärung seitens des Hamburgischen Beauftragten für Datenschutz und Informationssicherheit nötig welche dann ergab, dass eben nicht nur die SSID und MAC Adressen gesammelt wurden, sondern komplette Mitschnitte der Daten im jeweiligen öffentlichen – nicht verschlüsselten – Netzwerk.

Da viele unbedarfte Anwender, einen Router den sie vom Provider bekommen nicht weiter konfigurieren, sollten sie eventuell wissen, dass Google mit den gesammelten Daten z.B. alle URLs, die während des Vorbeifahrens aufgerufen wurden, ebenfalls durch den Mitschnitt des gesamten sogenannten Payload erfasst hat. Einfach alles was zu diesem Zeitpunkt eine Last im Netzwerk verursacht hat, findet sich dort wieder. Streamingdaten, Gespräche vom Messenger usw…

Im Google Blog wird geschrieben, dass diese Art der Erfassung bisher noch nicht aufgefallen sei und man sich dafür entschuldige. Ab sofort werden auf allen StreetView Fahrten bis auf Weiteres keine WLAN Daten mehr gesammelt. Ferner noch wird eine externe Firma beauftragt, die die erfassten Daten und die Erfassungssoftware auswerten soll, damit man die Änderungen entsprechend implementieren kann. Die internen Abläufe werden nach diesem Fehler auch umgestellt, um aus diesem Fehler für die Zukunft zu lernen.

Es ist eine Sicherheitslücke im SharePoint 2007 und WSS 3.0 bekannt geworden, die es einem Angreifer erlaubt, sich erweiterte Rechte durch eine Cross Site Scripting Attacke zu verschaffen.

Microsoft ist dieser Bug seit dem 12. April 2010 bekannt und es wird bereits an einen Fix gearbeitet. Dieser dürfte dann hoffentlich spätestens am 11. Mai (nächster Patchday) erscheinen.

Um den Zugriff über die Kommandozeile auf die help.aspx bis zum fertigen Patch zu unterbinden, schreibt René Hézser in seinem Blog, folgendes:

cacls "%ProgramFiles%\Common Files\Microsoft Shared\Web Server Extensions\12\TEMPLATE\LAYOUTS\Help.aspx" /E /P everyone:N

cacls "%ProgramFiles(x86)%\Common Files\Microsoft Shared\Web Server Extensions\12\TEMPLATE\LAYOUTS\Help.aspx" /E /P everyone:N

cacls ist ein Microsoft Kommandozeilen Tool, welches die Zugriffskontrolllisten (ACL – Access Control List) anzeigt, oder sie verändert.

Als ich heute eine neue Solution für ein Visual Webpart erstellt habe musste ich leider feststellen, dass Visual Studio 2010 noch einen kleinen Bug beinhaltet.

Ich habe den Namespace geändert, jedoch wurde nach dem Deployment die Fehlermeldung “Webpart ist not registered as save” angezeigt, da als SafeControl Eintrag für die web.config immer noch die Endung “…mynamespace.VisualWebpart1” verwendet wurde.

Der Grund ist die *.spdata des Usercontrols, die nicht automatisch aktualisiert wird:

Der Assemblyname ist hierbei mit einer Variablen hinterlegt, der Namespace ist jedoch hart kodiert und wird nicht automatisch angepasst. Nach der manuellen Anpassung muss die Solution geschlossen, neu geöffnet und kompiliert werden. Im Anschluss daran kann ein neues Deployment oder auch Debugging erfolgen, dann funktioniert alles wie gewünscht.

Unter SharePoint 2010 ist es nun möglich, eigene Pages für bestimmte Events zu hinterlegen. Dies geht über die SPCustomPage Enumeration:

Die neue Page kann über ein Webapplication Feature per FeatureReceiver zugewiesen werden.

    const string ErrorPage = "/_layouts/CustomEventPages/error.aspx";

    public override void FeatureActivated(SPFeatureReceiverProperties properties)

    {

        SPWebApplication webApp = properties.Feature.Parent as SPWebApplication;

        if (webApp != null)

        {

            if (!webApp.UpdateMappedPage(SPWebApplication.SPCustomPage.Error, ErrorPage))

            {

                throw new Exception("Neue Fehlerseite konnte nicht registriert werden!");

            }

            webApp.Update(true);

        }

    }

Hierbei wird nun eine neue Errorpage gesetzt, die zusätzliche Informationen für den Anwender oder ein eigenes Layout beinhalten könnte.

Heute morgen noch konnte man es durch einen kleinen Hinweis auf der Twitter Seite von WGS erahnen, nun bin ich bereits am herunterladen der öffentlichen BETA der 2. Version des Windows Home Servers.

Die Neuerungen werden auf den “großen” Seiten von WGS, HSB und natürlich im Windows Home Server Blog detailliert erläutert. Hier eine kleine Übersicht:

- Überarbeitung der Remote Access Webseite (Bereiche können per Drag’n’Drop angeordnet werden, Streaming von vielen Dateitypen ist möglich, das Layout hat eine Ähnlichkeit mit der Windows Live Seite)
- Die Konsole (neu Dashboard) wurde vom Design verändert
- Es gibt ein Launchpad, worüber die wichtigsten Funktionen wie Backups, Shared Folders oder das Dashboard schnell vom Client aus aufgerufen werden können

Im Dashboard ist auf dem ersten Register nun eine Übersicht, in der offene Aufgaben gelistet werden (ähnlich wie beim anmelden auf einem Windows Server 2008). Was beim Design - für Benutzer der 1. Version - auffallend ist: der kräftige Blauton ist überwiegend durch Silber oder helle Töne ausgetauscht worden. Insgesamt wirkt es in sich aber schlüssig und ich kann gar nicht mehr warten, bis der Download endlich fertig ist… hmm noch 90 Minuten

Ich habe eine kleine Kurzdoku für die Konfiguration des Add-Ins erstellt. Hoffe es hilft jemanden ein bisschen weiter.

Andreas M. hat einen Entwickler Tipp online gestellt, in dem er die Kommunikation zwischen den Settings und dem eigentlichen Add-In beschreibt. Benutzt wird hierbei ein einfacher Eventhandler, der beim Commit ausgelöst wird.

The easiest way to accomplish this is by using a singleton object which provides the necessary means of communication.

Now there’s two things left to do: First we need to subscribe to the ChangeNotifier’s Changed event in our console tab and second we have to call the Notify() method (which will fire the Changed event) from our settings tab when setting changes are committed.

Dieser Tipp kann benutzt werden, um Änderungen an den Einstellungen zu erkennen und im Add-In sofort zu reagieren.

Wenn ich an meine ganzen Versuche zurück denke… oje… der Weg ist einfach klasse!!

Es ist vollbracht und die neue Version steht zur Verfügung. Directory Watcher v1.1

Falls bereits die Version 1.0 installiert war, bitte vor dem Update erst die alte Version deinstallieren!!!

If you already have the version 1.0 installed, please uninstall the old version first

Ich bedanke mich bei allen wartenden und vor allem bei allen, die kräftig Feedback gegeben haben.
Ich denke, dass ich genug Anregungen in die aktuelle Version mit aufgenommen habe und hoffe, dass es euch gefällt.

Fehlermeldungen oder allgemeine Kommentare könnt ihr wie immer gerne hier hinterlassen.

Microsoft.Office.Server dll zum Projekt hinzufügen, diese ist zu finden unter "\Common Files\Microsoft Shared\Web Server Extensions\12\ISAPI\".

Die Logfiles liegen im Verzeichnis \Common Files\Microsoft Shared\Web Server Extensions\12\Log\. Um ins Logfile zu schreiben dann folgendes benutzen:

Microsoft.Office.Server.Diagnostic.PortalLog.LogString("Exception – {0} – {1} – {2}",

"Meine tolle Nachricht", ex.Message, ex.StackTrace);