Nomen est Omen – 1. Treffen des .NET Rheinhessen Stammtisch im Restaurant Zwölf Apostel in Alzey

Nicht mal mehr eine Woche, dann findet das 1. Treffen des .NET Rheinhessen Stammtischs statt.

Einzelheiten dazu findet Ihr in meinem ersten Post dazu.

Um diesem Treffen einen angemessenen Rahmen zu geben, haben wir (das sind noch immer Sascha Dittmann und ich Smiley) bei der Auswahl der Lokation selbstverständlich darauf geachtet eine Lokation mit einem würdigen Namen zu finden.

Ich denke dass ist uns gelungen.

Das Treffen findet im Restaurant “Zwölf Apostel” in Alzey statt.

Das Restaurant befindet sich inmitten der Innenstadt, direkt am Gerry Jansen Theater. Parklätze sind nicht direkt vor dem Restaurant vorhanden.

Es gibt jedoch mehrere Parkplätze in der Nähe, siehe nachfolgende Abbildung.

image

image Restaurant Zwölf Apostel

A) Parkplatz am Obermarkt (3 Gehminuten)
B) Parkplatz Ostdeutsche Straße (5 Gehminuten)
C) Parkplätze am Straßenrand Sankt-Georgen-Straße (2 Gehminuten)

Hinweise zu den Parkmöglichkeiten:
In der Sankt-Georgen-Straße sind nur 5 Parkplätze und meisten belegt, doch auf dem Obermarkt sollten eigentlich genügend Parkplätze vorhanden sein.
Sollte am Obermarkt wirklich alles belegt sein, gibt es auf der Ostdeutschen Straße  Ecke Raugrafenstraße einen großen Parkplatz auf dem Abends immer genügend Platz vorhanden ist.

So nun noch einmal alle Fakten im Überblick:

.NET Rheinhessen Stammtisch - XING Gruppe

Mittwoch 19.10.2011 um 18:30 Uhr

Zwölf Apostel
Hellgasse 7
55232 Alzey

Routenplaner

Bis Mittwoch !!

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

Der weiße Fleck muss weg – .NET Stammtisch Rheinhessen

Wenn wir uns anschauen welche Usergroups und Stammtische es in Rheinhessen für Entwickler und Berater rund um das Thema .NET Entwicklung von Windows und Web Anwendungen gibt, sieht man nur eines;

Einen weißen Fleck !!

image

Und dieser Fleck muss weg !! 

Genau das haben wir (wir, das sind Sascha Dittmann und Ich) uns auch gedacht und haben kurzerhand den .NET Stammtisch Rheinhessen gegründet.

UGRheinhessen Top-Logo

Und für wen ist dieser Stammtisch:

Alle, die Interesse an Gesprächen und Erfahrungsaustausch über Themen rund um die Entwicklung im Windows Umfeld (WPF, WCF, REST, WinForms, NT-Services, MVC, Web Apps, HTML5, JavaScript, METRO Apps, Azure, Cloud Computing und alles andere was man sich sonst noch in der Entwicklung vorstellen oder auch nicht vorstellen kann) haben, aus dem Raum Rheinhessen und Umgebung kommen, sind herzlich eingeladen sich unserem Stammtisch anzuschließen.

Wer einen XING Account hat, kann direkt der XING Gruppe beitreten.

Aber natürlich ist es nicht zwingend erforderlich einen XING Account zu besitzen um am Stammtisch teilnehmen zu können.

Anmeldungen zum Stammtisch können auch per Mail an:

info at dotnet-stammtisch-rheinhessen.de

gerichtet werden.

Das erste Treffen, sozusagen, das “Come Together” findet am 19.10.2011 in Alzey statt. Den genauen Ort des Stammtisches werden wir noch rechtzeitig bekannt geben.

Neben dem reinen “Come Together” werden wir, soweit es von Interesse ist über die ersten Erfahrungen mit Windows 8 (sowie das für und wieder der Metro Oberfläche), Visual Studio 11, dem .NET Framework 4.5 also auch über die neuen Sprachfeature von C#5 sprechen.

Aber wie das bei einem Stammtisch ist, da ist nichts in Fels gehauen und wenn an dem Abend andere Themen mit wesentlich mehr Aktualität und Interesse von Seiten der Teilnehmen besteht, dann wird eben darüber gesprochen.

Also auf geht’s zum ersten Treffen des .NET Stammtisch Rheinhessen nach Alzey.

Ich freue mich auf euer Kommen.

Und damit wäre auch der Weiße Fleck weg !!

image

Windows 8 – Irrweg oder einfach ein Irrer Weg

Es ist nun eine Woche her (13.09.2011), das Microsoft in Anaheim / Florida auf der “BUILD Windows” das Geheimnis um Windows 8 gelüftet hat.

Nun liegen die Fakten um Windows 8 auf dem Tisch!

  • Doch stehen die Fakten mit der Präsentation von Windows 8 wirklich fest?
  • Was wurde uns eigentlich als Windows 8 verkauft?
  • Worüber freuen wir uns?
  • Worüber ist die eine oder andere Gruppe betrübt?

Um diese Fragen und die meine Wahrheit um Windows 8 zu klären,  müssen wir aber auch die jüngere Vergangenheit vor der Öffentlichen Präsentation von Windows mit einbeziehen.

Denn die eigentliche Geschichte um Windows 8 beginnt bereits einige Wochen vor der BUILD in Anaheim.

Was ist in den letzten Wochen wirklich geschehen:

In den Tagen und Wochen vor der BUILD wurde viel Spekuliert.
Teilweise wurden echte Schreckensszenarien vermittelt.
Leider wurde auch von, sonst sachlich und nüchtern berichtenden Kollegen, mit Meldungen wie den folgenden Schlagzeilen gemacht:

  • HMTL 5 und JavaScript werden zur Standard Sprache zur Entwicklung von Desktop Anwendungen
  • Silverlight wird als Technologie nicht mehr unterstützt
  • Die Zukunft um WPF ist ungewiss
  • .NET wird es nicht mehr geben oder aussterben und damit wird auch C# und VB verschwinden
  • HTML 5 und vor allem JS sind die “must be” Sprachen für jeden Entwickler, sonst ist für Ihn/Sie der Zug abgefahren.
  • …. und ganz vieles Mehr.

Unabhängig davon, ob und wie viel davon tatsächlich irgendeiner Wahrheit nahe kommt, haben all diese Überlegungen und Gerüchte darauf basiert, dass davon ausgegangen wurde,  dass mit Windows 8 direkt von einem Nachfolger des Windows 7 wie wir es Heute kennen, einem reinen Desktopbetriebssystem,  gesprochen wird.

Doch was haben wir auf der BUILD wirklich vorgestellt bekommen?

  • Eine zu groß geratene Ausgabe von Windows Phone WP7
  • Ein neues Tablet Betriebssystem
  • Der Nachfolger des Windows 7 Desktop Betriebssystems

Ein wenig von allem!

Präsentiert hat uns Microsoft natürlich “das Neue”, das was man direkt sieht, das was vollkommen anders ist wie bisher, das was dem aktuellen Trend entspricht, das was Hype verspricht, das was ….

Das was präsentiert wurde, war die “Metro Style Oberfläche”

win8 - metro

Und dieses neue, ist doch genau das, was uns entweder empört oder begeistert hat.

Je nachdem welcher Zielgruppe man angehört, findet man diese Neuerung als “vollkommen abgefahren”, “Super Innovativ”“vollkommen daneben” oder als “Weltuntergang”.

Und ich glaube es gibt mehr Zielgruppen als wir uns das momentan überhaupt vorstellen können.

Allerdings sind die Zielgruppen, die sich bisher mit Windows 8 beschäftigt haben und sich öffentlich darüber geäußert haben, doch eher die aus dem Umfeld derer, welche sich mit der Entwicklung von Software beschäftigen, und für all diese, oder besser gesagt für die meisten von diesen, bedeutet Neuerung und Veränderung natürlich erst einmal die Angst vor Verlust.

Angst vor Verlust, Angst davor dass Wissen das man sich Jahrelang angeeignet hat, nicht weiter verwenden zu können.

Und wenn ich mir das anschaue, was Microsoft uns auf der BUILD als WIN 8 präsentiert hat, dann habe ich als Entwickler von Business Anwendungen (Egal ob als Web Anwendung, Desktopanwendung oder im Backend als Server Anwendung) im ersten Moment auch diese Angst (ganz kurz) verspürt.

Doch als analytischer Mensch lässt man sich natürlich nicht von einem Schauer der einem über den Rücken läuft lähmen und man beginnt die Sache, in diesem Fall Windows 8, mit dem notwendigen Abstand und der notwendigen Sorgfalt von den verschiedensten Seiten zu betrachten.

Ich habe die letzte Woche genutzt um mir Windows 8 genauer anzuschauen und mir Gedanken über die Auswirkungen von Windows 8 auf meinen Job als Entwickler zu machen.

Nachfolgend hierzu meine Gedanken und Thesen.

Metro Style Apps

Metro Style Apps sind nur auf Geräten mit Touch Bedienung sinnvoll einzusetzen.

Microsoft hat als Vision, dass es in Zukunft nur noch Geräte mit Touch Interface geben wird, und daher auf jedem Gerät Metro Style Apps sinnvoll eingesetzt werden können. Dem möchte ich auch nicht wiedersprechen, doch denke ich nicht, dass wir diese Zukunft noch dieses Jahrzehnt erleben werden.

Metro Style Apps werden für mich, meinen Job und meine Kunden mit oder ohne Windows 8 (damit meine ich die nächsten 2 – 3 Jahre) noch nicht wirklich eine entscheidende Rolle spielen.

Metro Style Apps werden weder Heute noch Morgen (mal schauen was übermorgen geschieht und ob dann noch jemand von Metro Style Apps spricht) als Ersatz für Rich Client Desktop Anwendungen im Büro und Produktionsstätten geeignet sein.

Wenn solche Art von Apps überhaupt für Rich Client Anwendungen eingesetzt werden sollten, wird das sicherlich noch bis Ende des Jahrzehnts und darüber hinaus dauern.

Um es nicht später zu vergessen:

Einen Wunsch an Microsoft bezüglich Windows 8 und der Metro Style Oberfläche hätte ich aber schon:

Hallo Microsoft, lasst bei der Installation von Windows 8 per Option entscheiden, welchen Desktop man als Standard verwenden möchte, den Metro Style oder den Standard Desktop  (WIN 7 Like)

Und eines noch Microsoft, solltet Ihr auf die Idee kommen, die in der Windows 8 Preview vorhandenen Möglichkeit, durch Änderung eines Registry Eintrags ein “Windows 7 Like” Startmenü zu bekommen, aus dem Final Release von WIN 8 gänzlich zu entfernen, sage ich euch mit WIN 8 ein zweites VISTA voraus (auf  jeden Fall auf Desktop PCs)

win8 - api

WinRT

Mit der WinRT stellt Microsoft den zentralen Baustein für die neue Metro Style Oberfläche zur Verfügung.

WinRT wird nicht als zusätzlicher Framework sondern als integraler Bestandteil des Betriebssystems betrachtet.

Ob WinRT wirklich eine Lösung oder mehr ein Problem ist, wird sich im Laufe der Zeit zeigen.
Ich finde es, Stand Heute sehr gewagt mit WinRT auf eine Technik wie COM (auch wenn es ein objektorientierter modernerer Ansatz ist) zurückzugreifen, die man vor fast 10 Jahren, aus guten Gründen, durch die .NET Technologie abgelöst hatte.
Einzig die Tatsache dass es in WinRT außer den WinRT eigenen DLLs keine gemeinsamen Bibliotheken gibt lässt mich hoffen, dass es kein zweite DLL Hölle geben wird.

Wer in Manage Code C# oder VB Metro Style Apps schreiben will muss sich im klaren sein, dass man dabei starken Beschränkungen unterliegt, da die WinRT nur eine Teilmenge der .NET Klassen zur Verfügung stellt.

Dinge wie direkte Dateizugriffe, Zugriffe aufs Dateisystem oder auch zugriffe auf eine Datenbank wie SQL oder andere sind nicht direkt möglich.

Um Beispielsweise auf eine Datenbank zugreifen zu können muss man sich zuerst einen Web Service erstellen, den man dann über die WinRT aufrufen kann.

Damit die Metro Style Apps immer den Eindruck hervorrufen dass Sie auf Benutzereingaben sofort reagieren, wurde in der WinRT darauf geachtet, dass alle Aufrufe die im allgemeinen länger als 50 ms dauern Asynchron aufgerufen werden.

.NET (C# 5 und VB)

.NET ist also noch nicht tot.

Neben Metro Style und dem damit zusammenhängenden WinRT wurde auch am .NET Framework gearbeitet.

Das .NET Framework 4.5 wird zusammen mit Windows 8 ausgeliefert (gibt es aber auch für Windows 7).

Zusammen mit dem Framework gehen auch die Managed Code Sprachen C# und VB in die nächste Versionsrunde.

  • C# 5.0
  • Visual Basic 11.0

Die umfangreichste Erweiterung der Sprachen besteht wohl in der Implementierung der await und async Schlüsselwörter und der damit einhergehenden Vereinfachung der Asynchronen Programmierung.

Die Zukunft von .NET dürfte wohl für die nächsten Jahre zumindest für “echte” Desktop Anwendungen” sowie natürlich für Web und Backend Anwendungen, gesichert sein.

HMTL 5 und JavaScript

Weder HMTL 5 noch JavaScript, und auch nicht die Kombination der beiden Sprachen, sind eine Erfindung von Windows 8.

Jedoch wird diese Kombination sicherlich nicht nur für die Web Entwicklung immer interessanter und wer sich bis Heute nicht damit beschäftigt hat, ist sicherlich gut beraten sich mit diesem Thema in näherer Zukunft auch ein wenig auseinanderzusetzen.

Ganz sicher dann, wenn man nicht nur Backend Programmierung betreibt.

Silverlight

Meiner ganz persönlichen Meinung nach, sieht die Zukunft von Silverlight nicht so rosig aus. Ich denke dass Silverlight mittelfristig zu den Klassischen Verlierern zählen wird und weder weiter entwickelt noch auf ewig weiter unterstützt werden wird.

Rich Web Applikationen können mit anderen Technologien wie HTML 5 zusammen mit JS auf der Client Seite erstellt und zusätzlich noch durch MVC oder ähnliche Technologien (evtl. auch mal durch node.JS) Serverseitig unterstützt werden.

Wenn man sieht, dass der IE10 in der Metro Style Variante keine Add Ins und somit kein Silverlight und kein Flash mehr unterstützt, muss man nur 1 und 1 addieren um sich über die Zukunft on SL seine Gedanken machen zu können.

Mein Tipp: Wenn du merkst, dass du ein totes Pferd reitest, steig ab!

Resümee und Weisheiten

Die Suppe wird nie so heiß gegessen wie Sie gekocht wird.
.NET lebt auch nach Windows 8 weiter, wir müssen nicht alle sofort nur noch HTML 5 und JS Programme schreiben

Der Markt und die Akzeptanz regelt im allgemeinen ganz viel alleine (Siehe VISTA), also wenn Windows 8 letztendlich wirklich nur per Touch ordentlich zu bedienen sein wird, dann wird es vermutlich ein Tablet OS aber kein Nachfolger für Windows 7

Warten wir mal ab wie Windows 8 in der Final Release dann wirklich auf den Markt kommt.

Eines habe ich übrigens vergessen, und das ist der bisher positivste Aspekt des neuen Windows:

Windows 8 startet um ein vielfaches schneller als jede andere Windows Version die es bisher gab.

Abschließen möchte ich, auch wenn dies kein Bericht über ein Fußballspiel war, mit den Worten eines großen Deutschen Fußballers:

Nach dem Spiel ist vor dem Spiel!

Freuen wir uns schon mal auf die Gerüchte und Aufregung um Windows 9.

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

Python leicht zu durchschauen – These oder Wirklichkeit ?

Gestern Abend habe ich (als .NET Programmierer) mir einen Vortrag über Python, eine der neuen Hype Sprachen, angeschaut.

Hiefür vielen Dank an Rainer Schuster, der im Rahmen des wöchentlichen ONLINE Stammtisches der .NET Online Usergroup, diesen Vortrag gehalten hat.

Ich hatte mich mit dieser Programmiersprache bisher noch gar nicht auseinander gesetzt, so dass ich mir, nachdem ich mit den gestrigen Vortrag angesehen habe, heute noch ein wenig mehr Informationen besorgt habe um evtl. den Hype um diese Sprache besser verstehen zu können.

Vorweg, kann ich schon mal sagen, dass mir das nicht gelungen ist, und ich nicht verstehen kann, was an einer interpretierten Sprache ohne Verwendung von Klammern so viel besser sein soll, als bei anderen Sprachen die nicht interpretiert werden müssen, und Ihre Konstrukte mithilfe von Klammern darstellt.

Auf diesen Satz mit den Klammern komme ich weil unter anderem über Python folgendes Gesagt wird:

Leicht zu durchschauen

Python hat noch einen weiteren, für Anfänger interessanten Aspekt: Die Syntax der Sprache wird weniger von Klammern als von Zeilenumbrüchen und Tabulatoren bestimmt. Man erkennt schnell, wie das Programm aufgebaut ist und gewinnt auch bei Programmen anderer Entwickler schnell einen Überblick.

Was ist denn an diesem Quellcode leichter  zu verstehen:

for i in range (10):
 print i
 print "zähle noch
for i in range (10):
 print i
print "Hallo"

Als an diesem (Beipiel C# Code)

for (int i = 0; i < 10; i++)
{
    Console.Write(i);
    Console.Write(@"Zähle noch")
}
for (int i = 0; i < 10; i++
{
    Console.Write(i);
}
Console.Write(@"Hello World");

OK OK OK,

das ist nicht alles, Python ist (Hier Argumente von Python Jüngern):

  • Open Source
  • Auf einigen (vielen) Plattformen (darunter auch ein paar exotische) verfügbar
  • Von vornherein auf Objektorientierung ausgelegt (Welchen Vorteil das auch immer mit sich bringen soll)

Auf der anderen Seite muss man doch aber auch ganz klar sehen, wen Python als Platzhirsch ansieht:

Das sind PHP und Pearl, nicht gerade die klassischen .NET Sprachen

Ist Python also die Sprache der Zukunft für uns .NET Entwickler?

Ich denke nein.

Es wird zwar gesagt, man kann mit Python alle arten von Programmen schreiben kann, das wird wohl auch nicht falsch sein.

Aber möchte ich demnächst

  • Desktop Applikationen
  • Web Portale
  • Web Services
  • Windows Dienste
  •  WP7 Apps
  • Android Apps

mit Python entwickeln.

Ich denke, dass ich das nicht möchte. Mir graust sogar davor wenn mir jemand sagen würde er hätte vor mit Python (einem Interpretativen Sprache) einen Windows Dienst, einen Mail Server oder einen Web Service zu schreiben.

Ich bin mir nicht sicher und es lässt Platz für Spekulationen und vermutlich auch für heiße Diskussionen , aber ich denke, dass Python wohl eher im nicht Windows Umfeld seinen rechten Platz hat.

Ich möchte zum Schluss noch eines anmerken:

Auch wenn .NET in den nächsten Jahren an Gewicht verlieren, und das ganze mehr in Richtung HMTL 5, 6 oder 7 zusammen mit JavaSript oder was für einer, mehr oder weniger funktionalen oder prozeduralen Sprache schwenken könnte, werde ich als heutiger .NET Entwickler vermutlich eher in diesen heute noch nicht endgültig abzuzeichnenden Bereich, als zu Python wechseln.