SugarSync – Windows 7 64 BIT Explorer friert ein und stürzt ab

Bevor ich zum eigentlichen Problem mit SugarSync und dem Explorer Absturz komme möchte ich kurz Beschreiben wie und warum ich zu SugarSync gekommen bin.

Meine Geschichte zu SugarSync

imageVor einigen Wochen, eigentlich sind es schon Monate her, bin ich auf das Synchronisations Tool SugarSync aufmerksam geworden.

Dieses Tool stellt ähnliche Funktionalitäten wie die Dropbox oder Live Mesh zur Verfügung.

Da ich sowohl Dropbox als auch Live Mesh einsetze, und das nicht weil ich gerne mehrere Tools für ein und denselben Zweck einsetze, sondern weil jedes der Tools ein Alleinstellungsmerkmal hat, dass ich benötige musste ich beide verwenden.

Alleinstellungsmerkmal Dropbox (gegenüber Live Mesh)

imageBei der Dropbox war das Alleinstellungsmerkmal die Möglichkeit “Public Links” erstellen zu können, die man einfach weiter geben kann, damit ein anderer sich die mit dem “Public Link” verknüpfte Datei herunterladen kann.

Alleinstellungsmerkmal Live Mesh (gegenüber Dropbox)

imageBei Live Mesh, ist es die Möglichkeit beliebige Ordner aus dem Dateisystem in die Synchronisation aufzunehmen und mit beliebigen Ordner auf anderen Geräten synchronisieren zu können.

SugarSync Alleinstellungsmerkmal (gegenüber Live Mesh und Dropbox)

SugarSync, kann sowohl “Public Links” erstellen, als auch beliebige Ordner des Dateisystems synchronisieren. Damit würden meine beiden speziellen Anforderungen von einem Tool erfüllt werden und ich müsste nicht auf mehrere Tools zurückgreifen.

Nach der Installation – der erste Start

Nachdem ich also überzeugt war, dass ich durch SugarSync die beiden Produkte Live Mesh und Dropbox ersetzen zu können, habe ich SugarSync auf 4 Geräten installiert.

  • 2 Geräte mit Windows 7 64 Bit
  • 1 Gerät mit Windows 7 32 Bit
  • 1 Gerät mit Windows XP 32 Bit

Auf 3 der 4 Geräte funktionierte alles wie erwartet, auf dem 4ten Gerät, das leider mein aktueller Entwicklungsrechner (Windows 7 64 Bit) war, trat das folgende Problem auf:

Der Versuch, nachdem der Rechner neu gestartet wurde, ein Windows Explorer Fenster zu öffnen führte dazu, dass dieses einfriert und nach einigen Sekunden abstürzt.

Neben dem Absturz des Explorer Fenster wurden auch einige Programme aus der Symbolleiste beendet:

clip_image002

Da ich mir nicht erklären konnte warum dieses Problem auftritt, ich aber sicher war, dass ich nicht der einzige sein kann, der dieses Problem hat, habe ich eine Mail an den Support geschrieben, und gehofft, der würde mir eine Antwort geben können.

imageDie Support Odyssee

Am 26.10.2011 habe ich dann eine ausführliche Beschreibung meines Problems per E-Mail an den Support gesendet.
Da SugarSync (sowohl das Produkt als auch die Webseite) auch auf Deutsch verfügbar ist, hatte ich ohne groß darüber nachzudenken, dass E-Mai in Deutsch geschrieben.

Am 01.11.2011 habe ich dann eine Nachricht vom Support erhalten (in Englisch), dass Sie das Ticket geschlossen haben, da ich mich nicht weiter gemeldet habe. Erstauntes Smiley

Am 02.11.2011 erhalte ich dann aber ein Mail vom Support, indem Sie mir erklären, dass ich doch bitte mein Problem in Englisch an sie senden soll, da der Support nur in English gegeben werden könnte.

Ich hatte in den folgenden Tagen wenig Zeit und habe mich daher erst wieder am 23.11.2011, nun in Englisch, an den Support gewendet und mein Problem in einer ausführlichen Mail beschrieben und darum gebeten mir mitzuteilen, wie man ein Error Logging einschalten könnte, damit ich mehr Informationen zu dem Problem liefern könnte.

Immerhin habe ich nun am gleichen Tag eine (automatisierte) Antwort bekommen, dass meine Mail angekommen sei und sich “ASAP” jemand um mein Problem kümmern würde.

Am 01.12.2011 (ist das ASAP) erhalte ich dann eine Mail, dass sie sich überhaupt nicht vorstellen können wie das Problem auftreten könnte, sie aber gerne mal Remote auf meinen Computer schauen würden um das Problem zu analysieren.

Ich habe dann kurz geantwortet, dass ich davon keinen Gebrauch machen möchte. Damit war klar ich werde das Problem selbst angehen, sobald ich etwas Zeit dafür habe.

Die Zeit war Reif für eine Analyse

imageDa ich SugarSync auf verschiedenen Rechnern installiert und das Problem in dieser Art nur auf einem Rechner aufgetreten ist, habe ich zuerst versucht die Besonderheit dieses Rechners zu ermitteln.

Hierbei habe ich festgestellt, dass ich einen Rechner mit exakt den gleichen installierten Programmen habe, auf dem das Problem nicht auftritt. Der einzige Unterschied, der Rechner auf dem es läuft ist ein 32 Bit Windows.

Also tritt das Problem vermutlich nur auf einem 64 Bit System auf.

Einer der installierten Rechner auf dem es läuft ist ein Windows 7 64 Bit Rechner. Dann vergleiche ich doch mal die darauf installierten Programme.

Bei Durchsicht der installierten Programme bekomme ich relativ schnell eine Ahnung woran das Problem liegen kann.

imageAuf dem Rechner mit dem Problem ist neben SugarSync auch TortoiseHg installiert, das ist auf dem anderen Windows 7 64 Bit Rechner nicht (mehr) installiert.

Ich möchte kurz erklären warum meine Vermutung relativ schnell in diese Richtung ging:

Das Stichwort lautet: Overlay Icons.

Sowohl TortoiseHg als auch SugarSync verwenden Overlay Icons um den Dateistatus im Windows Explorer darstellen zu können.

Wie sich nachfolgend herausstellen sollte, liegt tatsächlich das Problem an der Verwendung dieser Overlay Icons.

Die Lösung (vorübergehend auf jeden Fall)

Sowohl TortoiseHg als auch SugarSync bieten die Möglichkeit die Darstellung der Overlay Icons ein und ausschalten zu können.

Man kann eine der beiden Overlay Icon Anzeigen deaktivieren, und das Problem tritt nicht mehr auf. (Ich werde natürlich dieses Problem nun an SugarSync melden, damit sie das Problem aktiv angehen können, mal schauen ob und wann das dann geschieht)

Hier die Einstellungen die man ändern muss damit die beiden Produkte nebeneinander auf dem gleichen Rechner funktionieren.

Entweder dieses Option ausschalten (SugarSync):

SNAGHTML6d562c

Oder diese hier (TortoiseHg) ausschalten:

SNAGHTML6e7984

Und nun mal schauen ob der “Live Test” mit SugarSync meine Bedürfnisse ganz befriedigen kann und ich dann in naher Zukunft die beiden anderen Produkte ganz von meinen Rechnern entfernen kann.

PHP Debugging für .NET Dummies (IIS – WordPress – PhpStorm – Xdebug)

Vor einigen Tagen stand ich vor der Aufgabe im Zuge eines kleinen Projektes eine Verbindung zwischen der .NET und der PHP Welt herstellen zu müssen.

Als .NET Entwickler bin ich es eigentlich gewohnt mit Visual Studio zu arbeiten. Auch wenn man nicht immer mit VS super zufrieden ist, kann man damit aber doch ganz ordentlich Entwickeln. daher war es mir  wichtig auch für diesen PHP Ausflug zuerst einmal eine “gescheite” Entwicklungsumgebung für dieses Projekt aufzubauen.

Da ich neben ReSharper (Visual Studio Plugin) bereits WebStorm (beides Erstklassige Produkte von JetBrains) einsetze war für mich sehr schnell klar, dass als PHP IDE PhpStorm vom gleichen Hersteller zum Einsatz kommen soll.

Unter einer “gescheiten” Entwicklungsumgebung verstehe ich ab er als minimale Anforderung:

  • Einen guten Editor (IDE) (Am besten Syntax highlighting)
  • Einen ordentlichen Debugger (Am besten in der IDE integriert)

Mit PhpStorm habe ich die “gute”  IDE bereits ausgewählt.

Das Problem des integrierten Debugger kann ich aber weder mir PhpStorm noch mit einer anderen mir bekannten Entwicklungsumgebung für PHP direkt und einfach lösen.

Um PHP zu debuggen gibt es eine Extension mit der Bezeichnung “Xdebug”,  die direkt zusammen mit PHP arbeitet und in der PHP.INI konfiguriert werden muss.

Und genau diese Konfiguration und Einrichtung ist mir als .NET Entwickler irgendwie nicht wirklich einfach von der Hand gegangen.

Die Konfiguration von Xdebug in PHP war noch recht einfach und auch ganz ordentlich dokumentiert. Wie man jedoch aus der IDE (PhpStorm) Breakpoints setzen und den Debugger nutzen kann, dass blieb zuerst ein Buch mit vielen Siegeln.

Über die Konfiguration von PHP und Xdebug auf einem IIS unter Verwendung von PhpStorm, gab es eigentlich keine oder nur unvollständige Anleitungen (oder ich habe sie einfach nicht gefunden).

Nun aber genug der Vorreden, ab hier geht es nun um die Beschreibung (Schritt für Schritt Anleitung) wie man auf einem Windows Rechner eine komplette Entwicklungsumgebung für PHP einrichten kann, mit der sogar ein .NET Entwickler etwas anfangen kann 🙂 .

Systemumgebung, Programme, Voraussetzungen:

  • Windows 2008 R2 Server (Windows 7 mit installiertem IIS würde auch funktionieren)
  • WordPress (Oder jede andere PHP Anwendung wie z.B. Joomla)
  • imagePhpStorm 3.X
  • Xdebug (Debugger Tool für PHP)

Installation / Überprüfung IIS

Benötigt wird ein IIS 7 oder 7.5 (kein IIS Express).

Unter dem W2K8 geht das einfach indem man die Serverrolle Webserver (IIS) auswählt und installiert.

image

Es werden keine speziellen Rollendienste benötigt, also einfach nur auf Weiter und Installieren klicken bis die Installation abgeschlossen ist.

image

WordPress (und alle benötigten Komponenten installieren)

Der einfachste Weg um ein Produkt wie WordPress auf einem Windows Rechner zu installieren ist sicherlich die Verwendung des Web Plattform Installer (Der übrigens auch in WebMatrix integriert ist).

Der Web Plattform Installer stellt selbst fest welche Komponenten auf dem Rechner vorhanden sind und welche installiert werden müssen um das ausgewählte Produkt verwenden zu können.

Hier kann man dem Web Plattform Installer herunterladen

Also Web Plattform Installer herunterladen und aufrufen (installieren).

Nach der Initialisierung geben wir im Suchfeld “WordPress” ein und bestätigen die Eingabe mit der Enter Taste.

Nun wählen wir WordPress in der gewünschten Sprache aus und betätigen den Button hinzufügen.

image

Wenn man nun auf Installieren klickt werden die folgenden Tools und Produkte installiert.

image

Während der Installation müssen wir noch folgende Angaben machen:

image

Da ich eine Entwicklungsumgebung aufbauen möchte, werde ich MySQL auf dem lokalen Rechner installieren lassen. (Weiter klicken)

Nun bekommt man noch mal alle zu installierenden Produkte angezeigt und wird aufgefordert den Lizenzbedingungen zuzustimmen.

image

Jetzt muss noch ein root Passwort für die MySQL Installation angeben werden:

Beim Weiter Klicken, geht die Installation schon los.

Die Installation kann je nach Internet Geschwindigkeit unterschiedlich lange dauern, da während der Installation die aktuellen Pakete heruntergeladen und installiert werden.

Bei DSL 16000 und einem Rechner mit I7 Prozessor dauert die Gesamte Installation 3 – 5 Minuten.

Nächster Stop Webseite für WP konfigurieren:

image

Da ich WordPress nur in der Entwicklungsumgebung aufrufen und nicht von extern zugänglich machen möchte, lasse ich die Einstellungen wie vorgegeben. Das führt nach der Installation dazu, dass die Seite unter localhost/wordpress erreichbar sein wird.

Noch ein Stop Datenbank erstellen

image

Datenbank auswählen / erstellen und Root Passwort

image

Da wir MySQL gerade erst installiert haben, müssen wir natürlich eine Neue Datenbank erstellen.

Im Eingabefeld (roter Pfeil(, müssen wir das Root Passwort eingeben, dass wir während der Installation von MySQL vergeben haben.

Datenbankbenutzer / Passwort eingeben

image

Die Einträge mit den grünen Pfeilen müssen wir nicht anpassen.

In den Feldern mit den roten Pfeilen muss nun noch ein Kennwort für den Datenbank Benutzer eingegeben werden. Das muss nicht, kann aber das gleiche wie das Root Passwort sein (aber bitte nur auf lokalen Entwicklungssystemen, sonst sollten die Datenbank Passwort nicht dem Root Passwort entsprechen)

In allen weiteren Felder müssen keine Eingaben gemacht werden.

image

image

Damit sind nun WordPress und alle benötigten Tools und Programme installiert.

WordPress sollte nun schon funktionieren, also testen wir es mal.

Browser öffnen und localhost/wordpress eingeben.

image

Am besten geben wir gleich die notwendigen Daten für WP ein, so dass wir später direkt auf die Homepage von WordPress und nicht mehr auf die Admin Setup Seite geleitetet werden.

Beim nächsten Aufruf sollte das so aussehen:

image

Xdebug installieren

Nun müssen wir die Xdebug Extension installieren.

Wie wir weiter oben sehen wurde PHP in der Version 5.2 installiert, also müssen wir nun auch die Xdebug Version für PHP 5.2 herunterladen und installieren.

Aber Achtung es gibt 2 verschiedene Varianten:

Eine Thread sichere und eine Nicht Thread Sichere (nts), für die Installtion auf dem IIS muss die nts Variante verwendet werden.

Hier geht es direkt zum Download xdebug version 2.1.2 für PHP 5.2 Not Thread Safe

Die Extension besteht lediglich aus einer DLL Datei mit dem Namen:

php_xdebug-2.1.2-5.2-vc6-nts.dll

Nachdem man die Datei heruntergeladen hat muss diese in das Ext Verzeichnis von PHP kopiert werden.

Bei einer Standardinstallation auf einem W2K8 Server (64 BIT) findet man das Ext Verzeichnis unter folgendem Pfad:

C:\Program Files (x86)\PHP\v5.2\ext

Als nächstes muss die PHP.INI angepasst werden um die Debugger Extension verwenden zu können

Die PHP.INI befindet sich im Verzeichnis:

C:\Program Files (x86)\PHP\v5.2

Also öffnen wir die PHP.INI mit einem Texteditor und fügen folgende Einträge hinzu:

[xdebug]
zend_extension = "C:\Program Files (x86)\PHP\v5.2\ext\php_xdebug-2.1.2-5.2-vc6-nts.dll"
xdebug.remote_enable = On
xdebug.remote_host = "localhost"
xdebug.remote_port = 9000
xdebug.remote_handler = "dbgp"

Eigentlich ist es gleich an welcher Stelle diese Einträge hinzugefügt werden, aber wer sich gerne strikt an Vorgaben hält, kann die Einträge direkt unter dem folgenden Eintrag einfügen, dann funktioniert es auf jeden Fall.

image

Nun speichern wird die PHP.INI und müssen noch den IIS Neu starten:

Entweder über die Konsole “Internetinformationsdienste (IIS)-Manager

oder über die Kommandozeile:

net stop WAS (zum stoppen des IIS)

und dann

net start W3SVC (um den IIS wieder zu starten.)

Später (nachdem wir PhpStorm installiert haben und damit auch einen brauchbaren Editor  zur Verfügung haben)  prüfen wir auch noch ob die Extension richtig eingerichtet wurde.

PhpStorm installieren

PhpStorm gibt es in einer 30 Tage Trial Version, wer also keine Lizenz besitzt kann sich  erst einmal 30 Tage lang anschauen ob im PhpStorm das Geld, was es kostet, wert ist (Ich denke dass ist es auf jeden Fall, ein tolles Produkt wie eigentlich alle Produkte von JetBrains. Nein ich bekomme keine Prozente 🙂 )

Den Download gibt es hier: http://www.jetbrains.com/phpstorm/download/

Nachdem herunterladen installieren wir PhpStorm einfach mit allen Standardeinstellungen.

WordPress Projekt in PhpStorm einrichten

Nun öffnen wir PhpStorm und wählen die nachfolgende Option aus:

Create New Project from Existing Files

image

Das Szenario: Lokaler Web Server und Source Code unterhalb des Web Root passt genau für unser vorhaben.

image

Nun wählen wir das Root Verzeichnis (Nicht das WordPress Verzeichnis auswählen) des Default WEB unseres localhost aus.

image

Jetzt geben wir dem Projekt Server noch einen Namen (z.B. MyLocalServer)

image

In nächsten Schritt (Siehe Abbildung oben) geben wir nun die Projekt URL unserer WordPress Installation an.

Und haben damit das Projekt eingerichtet (Wie man auch in der folgenden Abbildung sehen kann).

Xdebug überprüfen

Wir öffnen die Datei index.php aus dem Root Verzeichnis unserer WordPress Installation im PhpStorm Editor.

Dort fügen wir die Funktion phpInfo() direkt nach dem Kommentar ein und speichern die Datei ab.

image

Nun öffnen wir den Browser und geben localhost/wordpress ein. Wenn anstelle der normalen WordPress Startseite diese PHP Info Seite angezeigt wird, haben wir bis hierhin schon mal alles richtig gemacht.

image

Um die Prüfung von Xdebug durchführen zu können, benötigen wir den Source Code der im Browse dargestellten phpinfo Seite.

Dazu lassen wir uns den Quelltext der Seite anzeigen, markieren den gesammten Quelltext, kopieren diesen in die Zwischenablage, und öffnen anschließend folgende Webseite:

http://xdebug.org/find-binary.php

image

Dort wo der rote Pfeil hinzeigt fügen wir dann den in der Zwischenablage befindlichen Quelltext ein und betätigen anschließend den “Analyse my phpinfo() output” Button.

Wenn Xdebug richtig installiert ist, sollte das Ergebnis wie folgt aussehen:

image

Wenn Xdebug nicht richtig installier ist, sollte man überprüfen, ob die Pfadangabe und der Dateiname der Xebug DLL in der PHP.INI richtig angegeben sind.

PhpStorm für das Debugging konfigurieren

image

Wir öffnen den Dialog “Edit Configurations”

image

Nun fügen wir eine neue Konfiguration hinzu:

image

Eine PHP Web Application Konfiguration

image

Im Feld unnamed geben wir unserer Konfiguration einen Namen. Zum Beispiel IIS.

Dann müssen wir einen Server auswählen (da wir aber noch keinen Konfiguriert haben, müssen wir zuerst einmal einen neu anlegen).

Hier Dialog zum einrichten eines neuen Server öffnen:

image

Dann im Dialog auf das + um einen neuen Server anzulegen:

image

Hier der bereits ausgefüllte Dialog:

image

Eingabe bestätigen und anschließend folgende Eingaben noch ergänzen, siehe Beschreibung unterhalb der Abbildung.

image

Der Konfiguration einen Namen geben (z.B. LocalIISWordPress)

Und die StartUrl um WordPress ergänzen, so dass der korrekte Link (http://localhost/wordpress) unter der Start URL angezeigt wird.

Das sollte dann so aussehen:

image

Dann bestätigen wir auch diesen Dialog

Und wenn wir nun auf den RUN Button drücken ….

image

Sollte sich der Default Browser mit der WordPress Seite automatisch öffnen.

Eigentlich sollte das setzen von Breakpoint nun auch schon funktionieren, probieren wir das doch mal indem wir einen Breakpoint auf die Zeile phpinfo() setzen die wir in der index.php eingefügt haben.

image

Einen Breakpoint kann man übrigens ganz einfach dadurch setzen, indem man mit der Maus an die Stelle klickt auf die der Rote Pfeil zeigt.

Und wenn wir nun anstelle des RUN Button, den DEBUG Button drücken …..

image

Richtig, der Programmablauf bleibt am Breakpoint stehen und wartet darauf das wir den Programmablauf fortsetzen.

So und nun viel Spaß beim PHP Debugging.

Google + – Anwendungsfall Logbuch

Ich möchte Heute darüber schreiben wie man Google + “sinnvoll als Logbuch” und nicht nur ausschließlich dafür nutzen kann, um Informationen mit bestimmten Kreisen oder der Öffentlichkeit zu teilen.

Seit einigen Woche kann man auch

In Google+ suchen

Es gibt zwar keine #HashTags aber eigentlich sind diese auch gar nicht unbedingt notwendig, es geht auch ohne, wie wir gleich sehen werden.

Ich möchte bestimmte Ereignisse auf Google+ hinterlegen, diese je nach Art des Ereignisses, entweder mit bestimmten Leuten oder der Öffentlichkeit teilen, oder einfach nur für mich zur späteren Erinnerung festhalten.

Natürlich gehe ich an dieser Stelle davon aus, dass Google meine Daten nur denjenigen Zugängig macht, denen ich es erlaube (Circles), und auch sonst nichts mit meinen Daten anstellt, was ich nicht möchte (Die Hoffnung stirbt ja bekanntlich zuletzt Smiley ).

Aber das ist ein anderes Thema, dass ich hier nicht weiter vertiefen möchte. Wer also gar kein Vertrauen oder einfach nur zu viel misstrauen hat, soll halt keine Daten G+ anvertrauen. Und besser gar nichts im Internet haben, vor allem nicht auf Facebook, aber dass ist auch ein anderes Thema.

So nun aber zur Auflösung wie ich G+ als Logbuch verwende:

Als erstes muss ich mir ein Kürzel für mein Logbuch ausdenken, und zwar eines, dass vermutlich nicht sehr häufig in meinen anderen Beiträgen vorkommt. Das kann auch der Begriff “Logbuch” sein, wenn man nicht in allen Beiträgen über Logbücher schreibt.

Dann erstellt ich die Beiträge die in meinem Logbuch erscheinen sollen im Format:

image

Nun kann ich den Beitrag für beliebige Kreise freigeben und ihn teilen.

Wie kann ich nun aber Logbuch Einträge erstellen, die nur für mich (und Google Smiley ) sind?

Ich erstelle mir einen Kreis, zum Beispiel den Kreis “Privat”  und füge keine Personen in diesem Kreis hinzu.

image

Somit habe ich einen Kreis den ich zum Teilen von Nachrichten verwenden kann, dessen Nachrichten aber nur ich lesen kann.

Nun sind alle Vorbereitungen getroffen um Logbuch Einträge erstellen zu können die entweder nur von mir oder auch von bestimmten Kreisen gelesen werden können.

Aber was wäre ein Logbuch wenn man die Einträge eines Logbuchs nicht auch Chronologisch anzeigen lassen könnte, und nur meine Logbuch Einträge.

Dazu kommt nun die Google+ Suche ins Spiel.

In das Suchfeld gebe ich das Logbuch Kürzel zusammen mit meinem G+ Profilnamen bzw. meinem Nachnamen ein, also für mein Logbuch sieht das so aus:

image

Nachdem man die Suche das erste mal ausgeführt hat, bietet G+ einem an, dass man diese Suche speichern kann.

image

Und das machen wir auch.

Wenn man eine Suche speichert wird einem zum Wideraufruf der Suche ein Link auf der linken Seite unterhalb der Stream Auswahl angezeigt, diesen kann man dann jederzeit verwenden um sich sein Logbuch anzeigen zu lassen.

image

So und nun viel Spaß mit dem G+ Logbuch

BlogEngine Update 2.5.0.X auf 2.5.011 – Datenbank Update notwendig

Heute Morgen wollte ich „schnell“ meinen BlogEngine betriebenen Blog auf http://blog.schelian.com mit der neuen Version 2.5.0.11 aktualisieren.

Diese Version ist die erste, welche eine komplette Gallery Integration (Installation, Update und löschen) von Paketen enthält.

Da ich einige persönliche Änderungen der BlogEngine vorgenommen habe, musste ich zuerst eine Verschmelzung (Merge) der Original Version 2.5.0.11 mit meiner lokale geänderten Version, die aber schon auf dem Code Version 2.5.0.10 basiert, vornehmen.

Der Merge konnte ohne manuelle Nacharbeiten einfach so durchgeführt werden.

Nach der Aktualisierung meins lokalen Quellcodes habe ich in Visual Studio 2010 einen kurzen Testlauf durchgeführt (mit XML Provider) und konnte keinen Fehler feststellen.

Nun habe ich mein NANT Skript aufgerufen, was mir aus der lokalen Version ein Package zur Aktualisierung meines Servers erstellt.

Das dabei erstellt ZIP File mit der Version 2.5.0.11 (in meiner angepassten Version) dann auf den Server hochgeladen und im Root Verzeichnis der BlogEngine entpackt (natürlich nicht ohne vorher eine Datensicherung durchgeführt zu haben).

Nun den Blog aufgerufen und…..

…. auf den ersten Blick war alles in Ordnung, nur auf den zweiten Blick leider nicht.

Beim Aufruf der Seite Plugins gab es eine Fehlermeldung die sich in weitestem Sinne um folgenden Aufruf gedreht hat.

BlogEngine.Core.Packaging.PackageRepository.GetPackage

Eine kurze Recherche hat das gezeigt, dass das Problem dadurch entsteht, dass diese Methode versucht auf eine Tabelle im SQL Server zuzugreifen, die es „noch“ gar nicht gibt.

Da auf der Codeplex Seite keine Hinweis auf ein erweitertes Datenbankschema zu finden war, hatte ich auch nicht nach einem Skript zur Aktualisierung der Datenbank gesucht.

Es gibt aber tatsächlich ein Script, allerdings mit dem merkwürdigen Zukunftsweisenden Namen „MSSQLUpgradeFrom2.5to2.6„, also einer Aktualisierung die erst beim Update der BE von 2.5 auf 2.6 notwendig sein soll.

Aber gut, es ist nun mal so, dass folgendes Script schon bei einem Update einer Version 2.5.0.X auf 2.5.0.11 notwendig ist:

SET CONCAT_NULL_YIELDS_NULL, ANSI_NULLS, ANSI_PADDING, QUOTED_IDENTIFIER, ANSI_WARNINGS, ARITHABORT ON
SET NUMERIC_ROUNDABORT, IMPLICIT_TRANSACTIONS, XACT_ABORT OFF
GO

--
-- Create table "dbo.be_Packages"
--
CREATE TABLE dbo.be_Packages (
  [PackageId] nvarchar(128) NOT NULL,
  [Version] nvarchar(128) NOT NULL
)
GO

--
-- Create table "dbo.be_PackageFiles"
--
CREATE TABLE dbo.be_PackageFiles (
  [PackageId] nvarchar(128) NOT NULL,
  [FileOrder] int NOT NULL,
  [FilePath] nvarchar(255) NOT NULL,
  [IsDirectory] bit NOT NULL
)
GO

Nachdem ich diese Skript auf der Datenbank ausgeführt habe, war der Fehler behoben und das Update auf Version 2.5.0.11 erfolgreich abegschlossen.

Office365 – Primäre Mail Adresse ändern (für den Administrator Account) – Powershell

Nachdem ich im ersten Teil über die Einrichtung eigener Domains für die Nutzung unter Office365,  und im zweiten Teil über Einrichtung von E-Mail Adressen von eigenen Domains,  berichtet habe, geht es nun darum, die primäre Absenderadresse des
Exchange Postfachs ändern zu können.

Und zwar unter den Umständen, dass man nur einen Office365 Account hat und für diesen natürlich auch gleichzeitig der Administrator dieses Accounts ist.

Mit den Bordmitteln von Office365 und der Administrationswebseite ist dies nämlich nicht möglich.

Da sich der Exchange Server aber durch die Windows Powershell steuern lässt, können wir über diesen Weg all die Dinge tun, die uns die Webseite zur Administration nicht im Dialog zur Verfügung stellt.

Ich versuche diese Beschreibung so zu gestalten (Schritt für Schritt). dass auch Leser, die sich mit der Powershell nicht auskennen, die Einstellungen vornehmen können. Ich hoffe das gelingt mir.

Die Windows Powershell ruft man wie folgt auf:

Start Menü –> Programme–> Zubehör –> Windows Powershell –>

Dort dann mit der rechten Maus auf Powershell klicken und „Als Administrator ausführen“

Als erstes müssen wir prüfen, ob die Berechtigungen für die Powershell so eingerichtet sind, dass sie ausreichen um eine Remote Verbindung zum Office365 (Remote Exchange Server) herstellen zu können. Im Standard dürften die Berechtigungen nicht ausreichen und wir müssen diese Berechtigung dann entsprechend anpassen.

Aber eins nach dem anderen.

Prüfen der aktuellen Powershell Berechtigung:

In die Powershell geben wir den nachfolgenden Befehl in die Kommandozeile ein und betätigen dann die Eingabetaste.

Get-ExecutionPolicy

Unbedingt darauf achten, hier ist kein Leerzeichen im Befehl enthalten, es handelt sich im ein Wort.

Wenn vorher noch keine Änderungen an den Berechtigungen der Powershell vorgenommen wurden, sollte folgende Systemantwort zurückgegeben werden „Restricted“:

Wenn anstelle „Restricted“, „RemoteSigned“ oder „Unrestricted“ zurückgegeben wird, sind die Berechtigungen bereits ausreichend und man kann den nächsten Schritt überspringen.

Setzen der Powershell Berechtigung (nur wenn notwendig)

Der nachfolgende Befehl wird in die Powershell eingegeben und mit der Eingabetaste bestätigt.

Set-ExecutionPolicy RemoteSigned -Force

Eigentlich sollte der Befehl ohne Probleme ausgeführt werden, und es sollte keine Fehlermeldung ausgegeben werden. Zur Sicherheit prüfen wir das noch einmal mit dem Befehl: „Get-ExecutionPolicy

Nun sollte der Rückgabewert wie folgt aussehen:

Powershell Remote an Office356 anmelden

Nachdem wir nun die Berechtigungen geprüft bzw. gesetzt haben, müssen wir nun die Powershell Remote an Office365 anmelden.

Hierzu geben wir den nachfolgenden Befehl in die Powershell ein und bestätigen wie immer mit der Eingabetaste:

$LiveCred = Get-Credential

Nun sollte sich ein Anmeldebildschirm wie nachfolgend öffnen.

In den Dialog muss man nun die Anmeldeinformationen für seinen Office365 Account eingeben und mit OK bestätigen.

Powershell Session mit Office365 (Exchange Server) herstellen

Als nächstes müssen wir eine Powershell Session mit dem Exchange Server von Office365 herstellen. Hierzu muss man den nachfolgenden Befehl in die Powershell eingeben:

$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell/ -Credential $LiveCred -Authentication Basic -AllowRedirection

Wie immer mit der Eingabetaste bestätigen. Dann sollte eine Meldung wie die nachfolgende in der Powershell zurückgegeben werden.

Powershell Commands importieren (Damit die Powershell Exchangich sprechen kann)

Um in der Powershell die Exchange Kommandos verwenden zu können ist es notwendig die Befehle zu importieren.

Das geht mit der Eingabe des nachfolgenden Befehls in die Powershell:

Import-PSSession $Session –AllowClobber

Nachdem man diesen Befehl wie immer mit der Eingabetaste bestätigt hat, sollte eine, der folgenden Abbildung entsprechenden Rückmeldung, ausgegeben werden.

Damit sind nun die Vorbereitungen abgeschlossen und wir können endlich an die eigentliche Aufgabe gehen:

Wie war die noch mal ? 🙂

Ach ja richtig wir wollten die Primäre E-Mail Adresse des Exchange Postfachs ändern.

Ändern der primären E-Mail Adresse

Um die Primäre E-Mail Adresse zu ändern, müssen wir folgenden Befehl in die Powershell eingeben:

Set-Mailbox [Office365Benutzernamen] -EmailAddresses SMTP:[myPrimary@mail.de], [meineAktuelleMail@onmicrosoft.com]

Hier die Syntax dieses Befehls:

  • [Office365Benutzernamen] steht hier als Platzhalter für den Office365 Benutzeraccount (der wird und kann nicht geändert werden, ist also der Benutzername)
  • [myPrimary@mail.de] steht als Platzhalter für die E-Mail Adresse die nun die primäre E-Mail Adresse sein soll.
  • [meineAktuelleMail@onmicrosoft.com] steht als Platzhalter für die aktuelle primäre E-Mail Adresse (bei der ersten Änderung ist das gleich mit dem Benutzernamen)

Und hier auch noch ein Beispiel:

Set-Mailbox max@musterman.onmicrosoft.com -EmailAddresses SMTP:max@musterman.de, max@musterman.onmicrosoft.com

Session schließen

Und ganz zum Ende müssen wir dafür sorgen, dass die Powershell Session wieder geschlossen wird.

Dies geht mit der Eingabe des folgenden Befehls in die Powershell:

Remove-PSSession $Session

Das sollte unbedingt gemacht werden, da es sonst bei mehrfachem herstellen einer Session und nicht korrektem Schließen dazu kommen kann, dass keine neue Session mehr geöffnet werden kann, Max Session überschritten.

(Ich glaube der Wert liegt zwischen 3 und max 5 Session)

So und nun viel Spaß mit Office365 und der eigenen E-Mail als primären E-Mail Adresse.

Welche Mail Adresse die Primäre ist, kann man übrigens in den E-Mail Optionen des Exchange Servers kontrollieren.

Wie das geht kann man in dem bereits oben erwähnte Beitrag nachlesen

https://blog.schelian.de/2011/08/office365-einrichtung-mail-adressen-bei-verwendung-eigener-domain/

Office365 – Einrichtung Mail Adressen bei Verwendung eigener Domain

Nachdem ich im Beitrag https://blog.schelian.de/2011/08/office365-eigene-domain-nutzen-ohne-die-microsoft-dns-server-zu-verwenden/ darüber berichtet habe, wie man eigene Domains in Office365 einrichtet, könnte man diese Artikel auch mit folgenden Titel überschreiben:

Domain ist auf Office365 eingerichtet, was nun, wo bleiben meine Mails?

Um Mails einer eingerichteten Domain auch empfangen zu können, muss man die Mail Adressen die verwendet werden sollen, erst in Office365 oder konkreter gesagt im Exchange Online Postfach konfigurieren.

Die nachfolgenden Screenshots zeigen den Weg zu den Einstellungen.







Wenn wir es bis hierher geschafft haben, können wir mit der eigentlichen Konfiguration beginnen.

Mit „Hinzufügen“ öffnen wird den folgenden Dialog zur Eingabe einer neuen Mail-Adresse:

In der Combo Box, rechts vom @ wählen wir die Domain aus für die eine Mail Adresse erstellt werden soll, links vom @ geben wir die Mail Adresse für die ausgewählte Domain ein die für das ausgewählte Postfach erstellt werden soll.

Fertig !!! Man könnte auch sagen:

Eine neue Mail Adresse ist geboren 🙂

Sofort nach der Einrichtung werden Mails mit der angegebenen Adresse im ausgewählten Postfach entgegengenommen.

Leider ist es nicht Möglich (wenigstens nicht wenn man ein P1 Konto) hat die Primäre Mail Adresse des Postfach an dieser Stelle zu ändern.

Wie man dies doch machen kann, werde ich in einem der folgenden Beiträge dieser kleinen Artikelserie Office365 zeigen.

Aber nun erst mal viel Spaß mit Office365 und der E-Mail Adresse der eigenen Domain.

SQL Server – Nach Neuinstallation SQL Server Express auf Dev Rechner Fehler mit DateTime Formaten

Ich will hier kein riesen Fass zum Thema SQL DateTime Formate aufmachen, dazu gibt es schon ganz viele Fässer im Internet, die das ganz ausführlich beschreiben.

In erster Linie geht es mir in diesem Artikel darum, mir selbst eine Nachricht zu hinterlassen, was ich beim nächsten mal machen muss, wenn ich ein solches Problem nochmal habe.

Eventuell hilft der Artikel auch mal jemand anderem, der das gleiche Problem hat, wie das, welches ich nun kurz beschreibe.

Hier nun das Problem:
Nach der Einrichtung eines neuen Entwickler Rechners, natürlich mit ein wenig aktuelleren Programmversionen als es auf dem bisherigen Rechern der Fall war, bekomme ich beim Versuch eine Windows Forms Anwendung[*1] aus Visual Studio heraus zu Debuggen Fehlermeldungen, wenn ich auf die lokale Datenbank die ich auf einem SQL Server Express 64 BIT, auf dem Rechner installiert habe, zugreifen möchte.

Das Programm läuft jedoch einwandfrei wenn ich Remote auf einen anderen SQL Server zugreife.

Da ich die lokale Datenbank aus einem aktuellen Backup des Servers erstellt habe auf dem es per Remote Zugriff keine Problem gibt, schließe ich schon mal aus das meine Datenbank selbst das Problem ist.

Die Fehlermeldung lautet wie folgt:

{„Bei der Konvertierung eines varchar-Datentyps in einen smalldatetime-Datentyp liegt der Wert außerhalb des gültigen Bereichs.“}

Probleme mit der Konvertierung von DateTime Werten, deutet auf ein Problem mit falschen Formaten hin. Die Standard Formate sind abhängig von der verwendeten Sprache.

Auf dem Rechner habe ich entgegen der bisherigen Installationen eine englische SQL Server Express Version installiert und nicht wie sonst einen deutsche Version.

Sowohl auf dem Produktionsserver des Kunden als auch auf meinem „echten“ Server ist aber der SQL Server als Deutsche Version installiert.

Soll das mein Problem sein? (Und es soll sich heraus stellen, dass mein Problem wenigstens damit zusammenhängt)

Mit dem Befehl

SELECT @@LANGUAGE

kann man die aktuellen Spracheinstellungen der aktuellen Verbindung abfragen.

Die Abfrage auf meinem lokalen SQL Express Server ergibt als Antwort English.

Eine Abfrage auf den „echten“ SQL Servern ergibt jeweils Deutsch.

Bingo, da liegt das Problem. Doch wie kann ich das ändern, bzw. was ich muss ich da überhaupt ändern.

Ich muss die Standard Sprache (Default Language) des SQL Login (Benutzer) ändern.

Das kann am einfachsten über die Login Eigenschaften mit dem SQL Server Management Studio machen.

Nun möchte ich aber vermeiden, dass beim nächsten Benutzer den ich anlege wieder die „für mich“ falsche Standardsprache des Benutzers hinterlegt wird.

Die Standardsprache kann man ebenfalls mit dem SQL Server Management Studio ansehen und auch ändern.

Hierzu öffnet man die Server Eigenschaften indem man im SQL Server Management Studio im Object Explorer auf dem Knotenpunkt des Server mit der rechen Maus das Kontextmenü öffnet und dort das Eigenschaften (Property) Fenster öffnet.

Und dort stellen wir die Default Language von English auf German um. Und schon wird beim nächsten Benutzer den man anlegt die „richtige“ Standardsprache für den Benutzer hinterlegt.

Natürlich kann man auch diese Einstellungen per SQL Befehle ausführen, aber wie ich bereits am Anfang sagte, ich möchte hier kein Riesen Fass öffnen, und es gibt ganz viele die sich mit dem SQL Server besser auskennen als ich.

Eventuell ist ja ein Leser des Berichtes so SQL fit und kann die SQL Befehle oder einen direkten Link zu den Befehlen als Kommentar hinterlassen.


[*1] ja die gibt es noch und diese von der ich hier sprechen ist auch schon einige Jahre alt, bzw, wird seit Jahren immer weiter entwickelt

Office365 – Eigene Domain nutzen ohne die Microsoft DNS Server zu verwenden

Nachdem (fast) jeder über Office365 spricht, habe ich mich dazu entschlossen, wenigstens in einem größeren Testbetrieb zu versuchen Office365 für meine Mail und Lync Aufgaben zu verwenden.

In dieser Artikel (Serie) werde ich Stück für Stück über die Fallstricke und Problem die dabei auftreten berichten.

In diesem ersten Artikel geht es um die Verwendung einer eigenen Domain.

Aber eben nicht wie es sich Microsoft vorstellt, sondern so wie ich es zur Umsetzung meine Anforderungen benötige. Und dazu gehört auf jeden Fall „nicht“, dass ich die gesamte Domain in Microsoft Hand und deren DNS Server übergeben möchte.

Nachdem man den die Domain Verifizierung durchgeführt hat, möchte Microsoft, dass man als Primärem und Sekundären DNS Server für sein Domain die beiden nachfolgenden Server angibt

  • ns1.bdm.microsoftonline.com
  • ns2.bdm.microsoftonline.com

Damit würde man aber die komplette DNS Verwaltung nur noch über die Office365 Verwaltung vornehmen können.

Man könnte dann über den Verwaltungsbereich –> Domänen –> DNS-Manager zwar weitere Host (A) und CNAME Einträge anlegen, doch was ist wenn man das nicht möchte und eigentlich nur die Mail (Exchange) und eventuell den Lync Dienst aus Office365 verwenden möchte.

Und genau dass möchte ich aber nicht, da ich all meine Domains auf meinen eigenen DNS Servern verwalte und das möchte ich auch für die Domain, welche ich als Mail Domain für Office365 verwende, in Zukunft weiter tun.

Also muss eine andere Lösung her, und diese sieht wie folgt aus:

Man verfährt zuerst einmal wie es Microsoft vorgibt und zwar bis an die Stelle, wo Microsoft einen dazu auffordert den primären und den sekundären DNS Server seiner Domain an die beiden Microsoft Server zu übergeben.

Anstelle die Kontrolle komplett an Office365 zu übergeben ändern bzw. erweitern wie lediglich die Einträge unseres aktuell verwendeten DNS Server wie folgt:

Für Mail Funktionalität an Office365 zu übergeben benötigt man folgenden Einträge:

MX-Eintrag:

SPF-Eintrag (Sender Policy Framework)

CNAME-Eintrag

Und wer auch den Lync Service nutzen möchte, der benötigt noch folgende zusätzlichen Einträge:

SRV-Eintrag _sip

SRV-Eintrag _sipfederationtls

Nachdem diese Einstellungen im DNS Server vorgenommen wurden, werden die Mails für die Domain ihrportal.de an Office365 gesendet und man kann mit der Domain auch den Lync Service verwenden.

Nicht vergessen, darf man aber, in der Verwaltung von Office365 noch die E-Mail Adressen dem Benutzer als zusätzliche E-Mail Adresse einzurichten.

Ich kann schon mal hier nachfolgende Stichworte erwähnen, bei welchen gleich die nächsten Probleme enstehen.

  • Primäre Mail Adresse
  • Sende Als

Aber dazu später sicherlich noch mehr.


Mehr aus der Serie Office365

Einrichtung Mail Adressen bei Verwendung eigener Domain

SQL Server Management Studio – Select Top X und Edit Top X Beschränkung

Im Microsoft SQL Server Management Studio (SQL Server 2008) werden im Kontextmenü zu Tables (Tabellen) und Views (Sichten) die beiden nachfolgenden Funktionen angeboten:

  • Select Top 1000 rows (Oberste 1000 Zeilen auswählen)
  • Edit Top 200 rows (Oberste 200 Zeilen bearbeiten)

Über den Sinn oder Unsinn warum man in einer View die Möglichkeit der Bearbeitung angeboten bekommt, möchte ich an dieser Stelle nicht weiter sprechen.

Nun ist es aber so, dass mich, diese Einschränkung stört!

Wenn ich eine Tabelle oder Sicht angezeigt bekomme,  möchte ich diese mit allen Datensätzen und nicht nur mit den ersten 1000 angezeigt bekommen.

Das gleich gilt übrigens auch für die Bearbeitung.

Nun gibt es, „Microsoft sei Dank“ die Möglichkeit, diese Einschränkung in den Optionen zum SQL Server Management Studio einstellen zu können.

Diese Option finden wir unter:

Tools -> Options -> SQL Server Object Explorer

oder für die eingefleischten Deutsch Programm Anwender:

Extras -> Optionen -> Objekt-Explorer von SQL Server

Dort finden wir  unter Table and View Options (Tabellen- und Sichtoptionen)

Die beiden Einträge:

Englische Version Deutsche Version

Nun kann man diese Werte beliebig ändern.

Oder wenn man wie ich keine Einschränkung haben möchte (alle Datensätze), kann man den Wert 0 eintragen.

Dann sieht das Kontextmenü wir folgt aus:

The URL ‚….. for Web project ‚….‘ is configured to use IIS Express as the web server but the URL is currently configured on the local IIS web server.

Die komplette Fehlermeldung die ich erhalten habe lautet wie folgt:

20110622 - IIS Express

Auch wenn dieser Fehler bei arbeiten an einem DotNetNuke Modul aufgetreten ist, kann dieser Fehler in jedem anderen Web Projekt unabhängig von DotNetNuke auftreten.

Was war geschehen.

Ich habe ein laufendes Projekt, von einem Windows 7 Rechner mit Visual Studio 2010 auf dem auch der IIS7 installiert ist, in ein Mercurial Repository gespeichert, und dann später auf einem zweiten Rechner geklont um auf diesem anderen Rechner einige Änderungen vornehmen zu können.

Nach dem Klonen des Projekts musste ich, da der Rechner auf dem ich den Klone erstellt habe, keinen IIS sondern nur den IIS Express installiert hat die Projekteigenchaften dahingehend ändern, dass das Projekt mit dem IIS Express funktioniert.
Was übrigens auch kein Problem war und einwandfrei funktioniert hat.

Bereits zu diesem Zeitpunkt hatte ich mir tatsächlich schon überlegt, ob es zu Problemen führen könnte, wenn ich das Projekt später wieder eingecheckt und dann auf dem ursprünglichen Rechner aktualisiere. Bin aber, da ich neben dem echten IIS auch den IIS Express auf dem ursprünglichen Rechner installiert habe zu der Überzeugung gekommen, dass es keine Probleme geben dürfte, was sich, wie man hier lesen kann nicht bewahrheitete.

Einige Wochen später, natürlich hatte ich mittlerweile vergessen, dass ich eine Umstellung von IIS auf IIS Express vorgenommen hatte, habe ich das Projekt aus dem Mercurial Repository auf dem ursprünglichen Rechner wieder ausgecheckt, bzw. eigentlich nur aktualisiert.

Und nachdem ich mit Visual Studio das Projekt geöffnet habe, kam es zu dem oben beschriebenen Fehler.

Mit der Fehlermeldung konnte ich erst überhaupt nichts anfangen. Dann fiel mir aber ein das ich ja diese IIS Express Änderungen an dem Projekt machen musste um es auf dem auf dem anderen Rechner zum laufen zu bekommen.

Das eigentliche Problem bei diesem Fehler ist, dass sich das Visual Studio Projekt nicht mehr öffnen lässt und daher auch keine Einstellungen geändert werden können. So dass man nicht einfach die Verwendung des IIS Express wieder ausschalten kann. (Ich hätte natürlich händig auch den IIS Express konfigurieren können, das hätte vermutlich auch geholfen)

Ich habe dann folgende Lösung entdeckt, und möchte diese für mich und gegebenenfalls auch für andere die ein solches Problem haben hier veröffentlichen, damit man,  wenn ein solches Problem wieder auftritt diese Lösung wieder finden kann und nicht wieder nach einer Lösung suchen muss.

So nun aber zur eigentlichen Lösung des Problems:

In der Konfigurationsdatei [Projektname].vbproj.user befindet sich unter der Region PropertyGroup folgende Einstellung:

<PropertyGroup>
       <UseIISExpress>true</UseIISExpress>
</PropertyGroup>

Diese Einstellung ändert man auf false, speichert die Datei, macht ein Reload der Projektdatei.

Und fertig.