Überall laufen die Vorbereitungen und Ankündigungen für den Jahreswechsel, Rückblicke gibt es an allen Ecken und Enden. Auch ich habe soeben mal meine Fotos des vergangenen Jahres durchgeschaut, hier meine Favoriten:
weiterlesen… »

Hallo,

seit nunmehr einigen Wochen beschäftige ich mich mit der .NET-Programmierung unter C#. Ich als blutigster C#, .NET oder genereller Programmierneuling tue mich in manchen/vielen Sachen recht schwer, dennoch möchte ich allen, die es interessiert so manch “Errungenschaft” nicht vorenthalten.

Heute: Wie bekomme ich aus dem Active Directory die Email-Adresse zu dem User, der das Formular aufruft.

Als Helfer komtm hier der Directory Searcher zum Einsatz:

Als Erstes, wichtigstes müssen die entsprechenden Using-Direktiven gesetzt werden: 

using System;
using System.DirectoryServices;
using System.Security.Principal;
using System.Web;

In meinem Webform habe ich die Abfrage in den Page_Load Bereich gesteckt, da ja beim Aufbau der Seite das Webform schon ein Stück ausgefüllt werden soll. Die erste Zeile

IIdentity user = HttpContext.Current.User.Identity;

zieht den aktuellen Benutzernamen und übergibt ihn an user.

Auf der nächsten Zeile

string userName = user.Name.Substring(user.Name.IndexOf("\\") + 1);

lege ich eine neue Variable “userName” an und belege diese mit einem Substring. Das ist deswegen notwendig, weil mir unter user mein Login inklusive Domain, also z.B. DOMAIN\USER übergeben wird, ich aber im ADS wenn ich nach DOMAIN\USER suche, nicht fündig werde. Nur USER führt zum gewünschten Ziel.

Nun lege ich noch eine Variable mail vom Typ string an, die ich später verwende.

string mail = "";

Als nächstes wird der Sucher festgelegt

DirectorySearcher search = new DirectorySearcher();
SearchResult result = search.FindOne();

Weiter geht’s. Der Sucher ist gesetzt, ein Filter fehlt noch, ich muss ja sagen, was ich suche:

search.Filter = String.Format("(SAMAccountName={0})", userName);

Außerdem schränke ich die Details der Suchergebnisse noch etwas ein, ich bin ja im Augenblick auf der Suche nach der Email:

search.PropertiesToLoad.Add("samaccountname");
search.PropertiesToLoad.Add("mail");

Und schon kann die Sucherei losgehen:

result = search.FindOne();

Jetzt kann es aber passieren, dass kein Ergebnis gefunden wird, oder dass etwas gefunden wird, aber keine Email-Adresse hinterlegt ist. Für diesen Fall fügen wir noch die folgende Abfrage an:

  if (result != null)
  {
  if (result.Properties["mail"].Count < 1)
  {
  txtbx_gen_mymail.Text = "leer";
  }
  else
  {
  mail = (result.Properties["mail"].Count > 0) ? (string)result.Properties["mail"][0] : "";
  txtbx_gen_mymail.Text = mail;
  }
  }
  else
  {
  txtbx_gen_mymail.Text = "Email for " + user.Name + " could not be found";
  }

Außerdem habe ich im zugehörigen Webform ein Textfeld txtbx_gen_mymail angelgt.

Dieser Code wertet die 3 Fälle wie folgt aus:

1. Objekt gefunden, aber Email-Adresse ist leer: txtbx_gen_mymail bekommt als Inhalt leer

txtbx_gen_mymail.Text = "leer";

2. Objekt gefunden, Email-Adresse ist ausgefüllt: txtbx_gen_mymail wird mit mail belegt

mail = (result.Properties["mail"].Count > 0) ? (string)result.Properties["mail"][0] : "";
txtbx_gen_mymail.Text = mail;

3. Objekt nicht gefunden (result = null): Hinweistext in txtbx_gen_mymail

txtbx_gen_mymail.Text = "Email for " + user.Name + " could not be found";

So, im Großen und Ganzen ist das alles kein Hexenwerk, wenn mal mal durchgestiegen ist. Aber für jeden Anfänger doch eine ziemlich Hürde, bei der ich hoffentlich helfen konnte…

Ein interessantes Experiment hat Microsoft veranstaltet. Sie ließen 140 Leute Ihre Meinung über Vista kund tun. Dann setzten sie sie vor den Vista Nachfolger mit Codenamen “Mojave” und ließen die Tester diesen einschätzen. Das Ergebnis: 84% fanden “Mojave” besser als Vista.

Der Clou: Der vorgebliche Vista-Nachfolger ist Windows Vista gewesen…

Somit zeigt sich, dass Vista wahrscheinlich besser als sein Ruf ist, ich nutze es privat seit Anfang des Jahres und bin sehr zufrieden. Hier der Link zur Homeopage des Mojava-Experiments.

Sämtliche Alarmglocken gingen an, als ich mir die Datenbank meines Sharepoints, noch nicht public, aber so gut wie fertig eingerichtet, angschaut habe: 700 MB. Stellte sich mir die Frage: Wieviel geht denn??

Und wieder ein Schock, als ich las, dass die Micrsoft Desktop Engine (MSDE) ein Limit von 5 gleichzeitigen Datenbankzugriffen und 2 GB pro Datenbank hat… Umso erleichtert, als ich auf diesen Artikel stieß, demzufolge die Microsoft-Entwickler bei den WSS3 eine besondere Version der SQL 2005 Engine verwendeten und auf Limitierungen verzichteten.

Wäre also die Frage geklärt, wie weit ich noch machen kann. Aber weiter offen die Frage, wieso die Datenbank so groß ist.. Ganz einfach: Die WSS (keine Ahnung, ob es bei dem MOSS=Microsoft Office Sharepoint Server auch so ist) legen sämtliche Dateien, Anhänge, etc. IN diese Datenbank ab, standardmäig liegt diese unter C:\WINDOWS\SYSMSI\SSEE\MSSQL.2005\MSSQL\Data. Erinnert mich ein bissl an Lotu sNotes, wo auch alle Inhalte in die Dokumentenorientierten Datenbanken abgelegt werden..

Dann schauen wir mal, wie sich das im Laufe der Zeit weiter verhält, vor Allem: Wie sich die Datenbank im Laufe des Wachstums weiter verhält…

Na gut, ich gebe zu es ist ein schlechtes Wortspiel. Aber lieber ein schlechtes als garkeinen Spass..

Kurz zur Vorgeschichte: Auf Arbeit häufen sich immer mehr Dokumentation, Protokolle, Anleitungen, Fehlerlösungen, etc… Selbst die beste Dateiablage vermag es nicht diese Flut an Informationen zu bändigen oder gar schnell und komfortable wieder darauf zuzugreifen.. Also hatte ich die Idee mir die Microsft Sharepoint Services 3.0 genauer anzuschauen. Diese sind, im Unterschied zum Sharepoint Portal Server kostenlos zu Windows 2003 Server downloadbar, und nach 2-3 Beschwerden von der Installationsroutine (.Net-Framework 3.0 sollte installiert sein, ebenso wie die IIS in jungfräulichen Zustand) auch relativ schnell installiert und konfiguriert. Wie bei jeder MS-Anwendung kann man out-of-the-box schon vieles anfangen und anlegen. So kann man problemlos Arbeitsbereiche oder eine Bildbibliothek anlegen. Auch die völlig unkomplizierte Integration ins Active Directory ist ein großes Plus für WSS. Eine der Neuerungen der WSS 3.0 ist das Erstellen von Web2.0-igen Blogs und Wikis.

Ein Blog bietet die Möglichkeit Informationen zu publizieren, auf die andere wiederum zugreifen können. Natürlich gehört hier die Unterstützung von RSS. EIn Wiki, und hier kommt der interessanteste Punkte, kann dazu verwendet werden ohne große Mühen eine große Menge an Informationen abzulegen und zu verknüpfen. Scheinbar ideal für das Anlegen einer Dokumentationsdatenbank.

Doch kurz zurück zu den Sharepoint Services. Durch verschiedene Erweiterungen/Templates ist man in der Lage einen speziellen Workspace für Teams, wie z.B. einen Helpdesk anzulegen, eine Inventar- oder Ressourcenverwaltung aufzubauen, oder ein einfaches Forum hinzusetzen. Alles in Microsoft-Manier mit ein paar Klicks udn fertig ist!!

Mich interessierte aber der Gedanke des Wikis. Es ist schnell eingerichtet, die Bedienung ist intuitiv und schnell erlernbar. Ein Verweis auf eine neue Seite, udn damit verbunden auf diese neue Seite lässt sich denkbar einfach umsetzen: Das gewünschte Thema einfach in je zwei [[eckige Klammern]] setzen und schon ist ein Link gesetzt. Klickt man auf diesen so kann man auf den neuen Beitrag zugreifen. Doch etwas fehlte mir: Für die Erstellung von Dokumentationen sind Bilder im Text unerlässlich: Dies ist über die WSS jedoch nur durch den Umweg “Bild in Fotobibliothek hochladen und dann entsprechend (per Hand) verlinken” möglich, das direkte Hochladen und Einfügen in den Text ist leider nicht möglich.

Also begab ich mich auf die Suche nach einer Möglichkeit, wie dies im Sharepoint (doch noch) zu realisieren sei. Ich stieß dann auch auf ein sog. Webpart, welches es ermöglicht/ermöglichen soll, soetwas umzusetzen. Leider bekam ich diesen Webpart weder durch die Herstelelranleitung noch durch Microsft Technet zum Laufen. Anstelle des funktionierenden Webparts erhielt ich nur eine Fehlermeldung, die mir klar und deutlich sagte: “Fehler beim Einbinden des Webparts” Vielen Dank!!

ALso ging es weiter.. Nicht nur andere Mütter haben hübsche Töchter, es gibt auch noch andere, und mit Sicherheit leistungsfähigere Wiki-Engines. Ein Artikel im tecChanel stellte eine nette Übersicht dar. Für mich steht fest: Open Source, kostenlos soll es sein. Zur Auswahl stehen nach einiger Recherche und verschiedenen Live-Demos:

MediaWiki: Die wahrscheinlich größte und verbreitetste Wiki-Plattform. Sie wird bei Wikipedia eingesetzt, ist schnell, einfach zu installieren und stabil. Außerdem ist sie übersichtlich udn leicht erlernbar. Einziger Haken: Es gibt keinen WYSIWYG-Editor (WYSIWYG = What You See Is What You Get => Das Erstellen und Editieren erfolgt ohne Eingabe von Formatierungsbefehlen, ähnlich wie es der Nutzer von Word gewohnt ist), eine Anforderung, die ohne jedes Wenn-und-Aber erfüllt werden muss!!! Ich kann es keinem User antun, dass er/sie anfangen muss spezielle Befehle zu lernen..

TWiki: Wirbt selbst und wird alles Enterprise-Wiki beworben. Auf den ersten Blick also optimal?! Wieder verschiedene Foren udn Artikel durchgeschaut: Es ist nicht ganz einfach zu installieren, es ist sehr sehr mächtig, wagt schon den Schritt zum CMS (Content-Management-System) ist aber nahezu optimal an Unternehmensbedürfnisse angepasst. Nachdem ich ca. 30 Minuten lang versucht habe das Paket unter einem WAMPP-Server zu installiern, stieß ich dann auf der Herstellerseite auf ein Windows-Standalone-Installationspaket. Klasse!!! Installiert, gestartet, läuft!! Die Versprechungen udn Stimmen waren nicht untertrieben: Es ist sehr sehr mächtig und komplex. Vorteil: Der WYSIWYG-Editor ist standardmäßig aktiviert. Zumindest in der Live-Demo funktionierte er genau so, wie es mir gewünschte habe. In der von mir installierten Testumgebung dann leider nichtmehr. Da mein Testsystem aber inwzischen doch ziemlich vermurkst war, habe ich das erstmal darauf geschoben und es wieder runtergeschmissen. Unter den VMWare Virtual Appliances stieß ich dann aber auf eine fertige, vorgefertigte und funktionstüchtige Virtuelle Maschine, welche genau den Zweck erfüllt: Ein fertiger, vorkonfigurierter und dennoch anpassbarer, voll funktionsfähiger (inkl. WYSIWYG) TWiki-Server

MediaWiki lies mich aber nicht in Ruhe, hatte ich doch früher schonmal den Versuch unternommen ein Wiki auf dieser Basis aufzusetzen, ein Projekt, welches leider im Sande verlaufen ist… An und für sich ist die Software ideal, bietet sie doch eine vertraute Umgebung. Einzig und allein das Manko des WYSIWYG-Editors inkl. Bildupload sollte doch umsetzbar sein?! Selbst bei Mediawiki setzt man sich schon mit diesem Thema auseinander, ein Projekt MediaWiki&FCKEditor gibt es bereits. Dieser Editor lässt sich auch problemlos einbinden, JUCHU ich habe einen WYSIWYG-Editor im Media-Wiki, der FCK-Editor bietet auch die Möglichkeit Bilder DIREKT in den Beitrag hochzuladen und einzubinden.. Leider erscheint an der Stelle, wo ein Bildupload sein sollte, nur ein Kreuz und “Preview”-Text.. Mal schauen, ob das Problem noch gelöst werden kann.. Ich bleibe dran…

So, genug für heute damit. Ich lasse das jetzt erstmal setzen und werde mich morgen oder Dienstag weiter mit dem Thema beschäftigen.

… Gmail/Googlemail von Microsoft kreiert worden wäre…

Auf diese Frage versucht Philipp Lessen eine Antwort zu liefern. In englischer Sprache zwar, aber dennoch sehr sehr ansprechend…

Aus der aufgeräumten, schnellen Oberfläche wird so ganz schnell ein Klickibunti Outlook-Klon… Gleichermaßen interessant und witzig…

Hier der Link

Zitat “derStandard.at”:

IT bis zum Burnout - Stress killt die Arbeitnehmer

Studie: IT-Spezialisten weisen viermal häufiger Stress-Symptome auf als der Durchschnitt der befragten Arbeitnehmer

Leiden Sie unter chronischen Schlafstörungen, kommt es bei Ihnen vermehrt zu Sodbrennen oder leiden Sie gar unter Gastritis? Fühlen Sie sich erschöpft und können Sie trotzdem schwer abschalten? Eine aktuelle Studie des Instituts für Arbeit und Technik (IAT) aus Gelsenkirchen (Deutschland) zeichnet ein wenig schmeichelhaftes Bild der IT-Branche, wie das Branchenportal ZDnet berichtet. Dabei wurden dezidiert Projektmitarbeiter unter die Lupe genommen.

Top und Flop

Demnach bietet das Arbeitsfeld der IT-Fachleute zwar viel Abwechslung bei überdurchschnittlich hohen Gehältern, gleichzeitig weisen Projektmitarbeiter aber auch viermal häufiger als der Durchschnitt der deutschen Beschäftigten Symptome massiven Stresses auf. Dauern diese Phasen der permanenten Müdigkeit, Magenbeschwerden und Schlafstörungen länger als acht Wochen, führen sie laut den Studienleitern zu einer Häufung chronischer Erschöpfung - einem Frühindikator des Burnout-Syndroms.

Was passiert?

Entwickelt sich diese Phasen so zu einem nachhaltig andauernden Zustand, kommt es schließlich zum Burnout. Diese chronische Erschöpfung körperlicher und psychischer Reserven bringt komplette Energielosigkeit, Demoralisierung, Gleichgültigkeit und Zynismus mit sich. In schlimmen Fällen dauert die vollständige Genesung mehrere Monate. Neben den körperlichen Beeinträchtigungen kommt es bei dauerhafter Überarbeitung auch zur Vernachlässigung sozialer Kontakte und im extremsten Fall zur Isolation.

Laut der Studie zeigen 40 Prozent der befragten IT-Projektmitarbeiter entsprechende Indikatoren und rund 30 Prozent haben dabei Probleme sich zu erholen.

(Link zum Artikel)

Ich würde gerne zu diesem Beitrag was hinzufügen. Diese folgende Tatsache erlebe ich gerade am eigenen Leibe: Microsoft ruft dazu noch Depressionen herver. Ihre Fehlermeldungen wirken gar demotivierend. Schaut selbst:

nicht nicht nicht nicht, jetzt bin ich traurig