WordPress Blog auf Windows Server – Plugins und Themes Aktualisierungen schlagen fehl

Von Heute auf Morgen hat die Aktualisierung von Plugins und Themes auf meinem WordPress Blog, welcher auf einem Windows Server W2K8 betrieben wird, nicht mehr funktioniert.

Dieses Problem hatte ich nun schon weit über 1 Jahr und konnte keine echte Lösung dafür finden.

Ich hatte zwar eine Interimslösung ermittelt, aber die war wirklich nicht sehr komforrabel.

Als Interimslösung war mir folgendes eingefallen:
Nachdem die Aktualisierung eines Plugins fehlgeschlagen war, musste ich den IIS neu starten und konnte dann das Plugin neu installieren.

Ich sagte ja, nicht wirklich komfortabel

Letzte Woche war ich mit @Sascha unterwegs zu einer Community Veranstaltung in Köln.
Während der Fahrt erzählt er mir von genau dem gleichen Phänomen auf seinem Blog.
Ich sagte ihm, dass ich das gleiche Problem schon seit längerer Zeit auf meinem Blog habe und bisher keine Lösung dafür gefunden hätte.

Ein paar Tage später, während eines Telefonats erzählt mir Sascha das er eine Lösung für sein Problem gefunden hat.
Voller freudiger erwartung habe ich versucht die gleiche Lösung bei mir zu verwenden, musste jedoch feststellen dass bei meiner verwendeten Infrastruktur das Problem mit „seiner“ lösung nicht behoben werden konnte.

Aber …..
Es lag nahe, dass mein Problem im selben Bereich zu suchen war wie Saschas Problem, und es lediglich an den unterschiedlichen Plattformen und Versionen liegt dass nicht exakt die gleiche Lösug bei uns beiden funktioniert.

Hier geht es übrigens zur (Azure) Lösung von Sascha

Ich vermutetet also, dass mein Problem, wie bei Saschas Beitrag beschrieben, auch etwas mit dem Caching von PHP Seiten auf dem IIS zu tun haben könnnte.

Eine Suche in den Diensten meines Windows Server hat gezeigt, dass es tatsächlich einen extra Dienst, den „Window Cache Extension Service“ gibt, der genau für diese Aufgabe zuständig ist.

Ich habe dann einfach diesen Dienst deinstalliert und bingo – mein Problem war nun auch gelöst.

Windows 8 Store Apps (HTML5/JavaScript) – CSS ist nicht gleich CSS

imageBei der Arbeit an einer Windows 8 Store App die ich mit HTML5 und JavaScript realisiere, bin ich auf folgendes Problem gestoßen (welches ich hier bereits auf Facebook gepostet habe):

Doch zuerst einmal ein kurzer Ausschnitt des Markup bei welchem das Problem auftritt:

<body>
	<div id="itemTemplate">
		<figure>
			<img id="profile-image" src="images/smalllogo.png" />
		</figure>
		<div>
			<span data-win-bind="innerText: text">Testen</span>
		</div>
	</div>
</body>

Im zugehörigen Stylesheet sind unter anderem folgende Styles definiert:

figure {
    margin: 0px;   
}

#itemTemplate figure img {
    margin: 30px;
}

So wie die Styles definiert sind, sollte das Image Element mit der ID “profile-image” eine Margin von 30px auf allen Seiten vorweisen.

Das funktioniert auch wenn man es in einem Browser aufruft (Sogar der IE funktioniert hierbei korrekt Smiley ).

imageWenn man diese Formatierung allerdings in einem “HTML5/JavaScript Windows a Store App” (was für ein BegriffTrauriges Smiley ) verwendet, greift der Style “#itemplate figure img” nicht in dem Image Element, welches in dem Figure Element eingebettet ist, sondern die Margin Einstellung des übergeordneten Elementes Figur hebt die Formatierung des darin eingebetteten Image Elementes auf.

Ein erstes kleines Fazit dabei ist, dass man sich nicht darauf verlassen kann, dass der zuletzt definierte Style tatsächlich Verwendung findet.
Wenigstens dann nicht wenn man übergeordnete globale Element Formatierungen verwendet.

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.

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.

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

Welche web_mediumtrust.config greift denn unter dem Net-Framework 3.5

Unter bestimmten Umständen muss man beim Betrieb einer Web Seite die unter Medium Trust betrieben wird Änderungen an der Medium Trust Konfiguration vornehmen.

Die Konfiguration hierfür wird in der web_mediumtrust.config vorgenommen.

Laut dokumentation befindet sich die Datei in folgendem Verzeichnis:

 %windir%\Microsoft.NET\Framework\{Version}\CONFIG 

Doch was ist wenn die Webseite unter NET Framework 3.5 Betrieben wird, da gibt es dieses Verzeichnis erst gar nicht.

Und das ist eigentlich auch klar, denn der NET Framework 3 und 3.5 sind lediglich Erweiterungen des FW 2. Erst mit dem NET Framework 4.0 wurde ein komplett neuer Framework veröffentlicht.

Und genau das spiegelt sich auch in dem vorhandensein, oder nicht vorhandensein der Config Dateien wieder.

Somit ist die Antwort auf die in der Überschrift gestellten Frage wie folgt:

Die web_mediumtrust.config Datei zur Änderung des Medium Trust verhalten einer unter dem NET Framework 3.5 betriebenen Webseite befindet sich im Verzeichnis

 %windir%\Microsoft.NET\Framework\v2.0.50727\CONFIG 

Übrigens gilt das bisher geschriebene nur für 32 BIT Windows Betriebssysteme, unter einem 64 BIT Betriebssystem findet man die config Dateien unter folgendem Verzeichnis:

 %windir%\Microsoft.NET\Framework64\v2.0.50727\CONFIG 

BlogEngine.NET – Zugriffsstatistiken (Site Stats) einrichten (Google Analytics)

Die BlogEngine.NET 2.0 bietet von Hause aus keine eigene Protokollierung der Webseiten Zugriffe. Das finde ich persönlich auch nicht unbedingt als Nachteil, auch wenn viele andere Blog Engines eine einfache Statistik im Standard bereits beinhalten.

Für die meisten Blog Betreiber wird Google Analytics die erste Wahl wenn es darum geht sich eine Zugriffsstatistik für den Blog einzurichten.

Nachfolgen erkläre ich Schritt für Schritt wie man Google Analytics für einen Blog mit der BlogEngine.NET einrichten kann.

Als erstes müssen wir dazu ein Google Analytics Konto einrichten (Dazu muss natürlich ein Google Konto eingerichtet oder vorhanden sein.).

Hier geht es zu Google Analytics

Entweder man meldet sich mit einem bereits bestehenden Google Konto an, oder man richtet ein neues Google Konto ein.

Nachdem man sich mit seinem Google Account angemeldet hat kann man sich für Google Analytics anmelden.

Nach der Anmeldung geht es an die Eintragung der für die Webseite notwendigen Daten.

Hier werden die Daten der Webseite eingegeben.

Das sollte dann in etwas so aussehen.

Jetzt auf Weiter klicken.

Als nächstes müssen die Kontaktinformationen eingeben werden.

Und wieder auf Weiter klicken.

Nun muss man noch den AGB’S zustimmen und dann auf „Neues Konto erstellen“ klicken.

Fast fertig.

Das Script unter Punkt 2 müssen wir nun noch kopieren und in der BlogEngine einfügen.

Also Script markieren, kopieren und Button Speichern und Fertig klicken.

Nun rufen wir die URL unseres Blogs auf, melden uns an der BlogEngine als Administrator an, rufen dort Settings und dort den Link (Menüpunkt) Custom Code auf.

In das Feld Tracking Script fügen wir nun das Script aus der Zwischenablage ein und speichern die Eingabe.

Ab sofort werden die Zugriffe über Google Analytics erfasst und gespeichert.

Die Informationen stehen nun später zur Ansicht und Auswertung über Google Analytics zur Verfügung

Aber nicht so schnell, das dauer einige Stunden bis sichtbare Daten vorhanden sind, also etwas Geduld und mal einen Tag warten.

BlogEngine.NET 2.0 – Grundinstallation auf einem W2K8 Server (BlogEngine von 0 auf 100)

Heute war es nun soweit, nach langer Zeit habe ich mich dazu entschieden für meinen Blog (Zunächst mal für meinem Englischsprachigen Blog) die BlogEngine.NET als Blog Software zu verwenden.

Ich werde in einer kleinen Reihe mit dem Namen „BlogEngine von 0 auf 100“ über die Installation, die offenen Wünsche, verfügbare Externsions und eventuelle Anpassungen berichten.

Heute beginne ich mit einer ToDo Liste für die Grundinstallation der BlogEngine.NET auf einer Windows 2008 Server Maschine.

Dies soll, wie aus dem Begriff ToDo Liste schon hervorgeht,  keine detaillierte Beschreibung für jeden einzelnen Schritt werden, sondern lediglich ein grobe Aufstellung, welche Schritte man durchführen muss um die BlogEngine zu installieren. Für die detailliertere Informationen zu den einzelnen Schritten gibt es Unmengen an Hinweise im Internet „Google/Bing“ sei dank.

Herunterladen und auspacken

BlogEngine.NET 2.0 (web)

Das ZIP File habe ich auf meinen Server geladen und dort entpackt.

IIS einrichten

Erstellen eines Anwendungspool und sofort die Identität auf Netzwerkdienst geändert. Das wird benötigt um die erforderlichen Rechte auf das Basisverzeichnis legen zu können und um die integrierte Sicherheit mit dem SQL Server zu konfigurieren.

Als nächstes mit dem IIS Manager eine neue Webseite angelegen, mit dem Root auf das Verzeichnis BlogEngine.Web zeigen lassen.

Rechte vergeben und Konfiguration kopieren

Dem Netzwerkdienst alle Rechte (ja es geht auch etwas kleiner) auf das Root Verzeichnis der Anwendung gegeben.

Da ich die Daten in einer SQL Datebank und nicht in XML Files speichern möchte, sind noch noch folgende schritte notwendig:

Aus dem Unterverzeichnis \setup\SQLServer die Datei SQLServerWeb.config nach web.config umbenennen und die web.config um Rootverzeichnis damit ersetzen.

Siehe auch

Datenbank anlegen und Zugriff einrichten

SQL Datenbank angelegen und auf der neuen DB das MSSQLSetup2.0.0.0.sql script ausführen. Das Script befindet sich im Unterverzeichnis \setup\SQLServer.
Wenn man mit Integrierter Sicherheit arbeiten möchte, nicht vergessen, dem Benutzer Netzwerkdienst Zugriff auf die Datenbank zu geben.

Connection string in der web.config anpassen.

Jetzt kann es eigentlich los gehen, Aufruf der Webseite, vorausgesetzt man hat dazu auch schon die notwendigen DNS Einträge vorgenommen und den richtigen HostHeader im IIS eingetragen.


Reihe: BlogEngine von 0 auf 100

ContextMenuStrip – Dynamisch Separatoren anzeigen oder ausblenden (C#)

In diesem Artikel möchte ich eine Methode vorstellen mit welcher je nach sichtbaren Menüpunkten eines Kontextmenüs die Separatoren zwischen einzelnen Menügruppen angezeigt (visible == true) bzw ausgeblendet (visibel == false) werden.

Schauen wir uns doch zuerst einmal an um was es dabei wirklich geht.

Hier zuerst das Gesamte Menü mit allen Möglichen Menüpunkten.

Dieses Beispiel stellt das Kontextmenü einer Anwendung dar, die verschiedene Kalendereinträge enthalten kann.

Je nachdem welche Art Kalendereintrag (Planung, Anlieferung, Sperrzeit etc.) ausgewählt wurde und welche Berechtigungen ein Benutzer besitzt werden nur bestimmte Menüpunkte aus dieser Gesamtauswahl angezeigt.

Häufig wird das so geregelt, dass man anstelle die Menüpunkte auszublenden diese nur deaktiviert. In diesem Fall ist es dann nicht notwendig sich Gedanken darüber zu machen einzelne Separatoren für eventuell ganz wegfallende Menügruppen zu entfernen.

Nachfolgend nun einige Abbildungen die anzeigen was passiert wenn man die Menüpunkte ausblendet ohne sich um die Separatoren zu kümmern.

Man beachte die vielen direkt aufeinander folgenden Separatoren, Sieht nicht wirklich Professionell aus.

Nun kann man natürlich die Separatoren ebenfalls im Opening Event manuell Sichtbar oder Unsichtbar machen (setzen der Visible Eigenschaft), dass kann aber je nach Komplexität der Menüstruktur sehr schnell sehr mühsam und sehr fehleranfällig werden.

Genau aus diesem Grund habe ich mir hierzu eine Methode erstellt die sich um diese Aufgabe selbstständig kümmert und je nach sichtbaren Menüpunkten die benötigten Separatoren ebenfalls sichtbar oder unsichtbar macht.

Doch bevor ich die Methode zeige, möchte ich zuerst das Ergebnis anhand der nachfolgenden Abbildungen zeigen. Hier nun die korrekt dargestellten Menüs.

Das sieht doch schon viel besser aus !

So nun aber der Quellcode der Methode.

internal static void SetToolStripSeperatorForContextMenu(ContextMenuStrip contextMenuStrip)
{
	bool isVisible = false;
	int seperatorIndex = 0;
	for (int i = 0; i < contextMenuStrip.Items.Count; i++)
	{
		if (contextMenuStrip.Items[i] is ToolStripSeparator)
		{
			contextMenuStrip.Items[i].Visible = false;
		}

		if (contextMenuStrip.Items[i].Available)
		{
			if (seperatorIndex > 0)
			{
				contextMenuStrip.Items[seperatorIndex].Visible = true;
				seperatorIndex = 0;
			}
			isVisible = true;
		}
		if (contextMenuStrip.Items[i] is ToolStripSeparator)
		{
			if (isVisible)
			{
				seperatorIndex = i;
			}
			isVisible = false;
		}
	}
}

Übrigens die Methode einfach am Ende des Opening Event des Kontextmenüs wie folgt aufrufen.

SetToolStripSeperatorForContextMenu(((ContextMenuStrip) sender));

Und fertig.