Schlagwort-Archive: IIS

Auswahl des Portalsystem und Installation DotNetNuke & Joomla

Für einige Webseitenprojekte habe ich einige Zeit nach einem Portalsystem gesucht. Zunächst hatte ich mich eigentlich für joomla entschieden, doch so recht kam ich nicht zurecht, dass mag aber auch an mangelnder Zeit liegen.
Nun kommen doch einige Webprojekte auf mich zu und ich musste mich nun für ein Portalsystem entscheiden. Aufgrund der Tatsache, dass ich zu großen Teilen Windows-Maschinen betreue und fit werden muss in Powershell habe ich mich für DotNetNuke entschieden. Zum einen ist die Community ausreichend groß und zum anderen basiert das System auf den Sprachen die ich erlernen muss. So bleibe ich zunächst bei einer einheitlichen Sprache und kann mich darauf konzentrieren und spätere Anpassungen werden mir so sicherlich leichter fallen.
Die Installation verlief durch den Webbrowserbasierte Installationsroutine sehr einfach und dazu gibt es eigentlich keine weiteren Worte zu verlieren. Die Verbindung zum SQL-Server war auch unspektakulär.
Einzig sind im Vorfelg einige Vorkonfigurationen vorzunehmen.
So wurde zunächst ein Service-Account im AD angelegt. Diesem Server-Account wurde Ändernde-Rechte auf dem DotNetNuke-Verzeichnis gewährt. Außerdem wurde eine Datenbank im SQL-Server angelegt und als Besitzer ebenfalls der Service-Account zugewiesen.
Im IIS wird die Seite als Application ausgeführt. Auch hier wurden Typischerweise die Rechte vom Service-Account übernommen.
Nach durchführen dieser Konfigurationsschritte war das Starten der Installationsroutine ein Kinderspiel. Diese macht zunächst ein Check, ob alles entsprechend korrekt konfiguriert wurde und die entsprechenden Rechte gesetzt sind, also keine Panik, sollte etwas nicht passen, so wird einem dies von der Installationsroutine mitgeteilt.
Nachtrag:
Aufgrund der doch eher unübersichtlichen Webkonfiguration bei DotNetNuke habe ich im letzten Moment doch noch einen Schwenk nach Joomla gemacht. Nach einem Tag Einarbeitung und ein weiteren Tag Websiteerstellung muß ich meine Aussage zurück ziehen. Zunächst war die Einarbeitung doch sehr einfach und die Ergebnisse die bereits nach kurzer Zeit Erzielbar sind, sind mehr als nur Zufriedenstellend.

Exchange 2010 SP1 OWA Mails lassen sich nicht löschen – Behoben

Nun ist das Update einige Tage vorrüber und leider hat sich doch ein Fehler nachdem Updateprozess gezeigt. Zum einen wird in der Ereignisanzeige folgender Fehler:
System EventID 3 – WebHost konnte eine Anforderung nicht verarbeiten
Anwendung EventID 108 – Outlook Web App konnte aufgrund eines Konfigurationsfehlers keine Verbindung zu den Exchange-Webdiensten herstellen. Antwortcode = ‚500‘.
Es lassen sich keine Mail mehr in OWA löschen. Sobald versucht wird zu löschen oder zu verschieben, wird folgende Fehlermeldung angezeigt:

Exchange 2010 OWA Fehler

Das Problem besteht bei mir nur in OWA. OWA-Light ist davon nicht betroffen. Nach einigen Recherchen habe ich zunächst das SSL-Zertifikat Testweise erneuert und mir die konfigurierten HTTP-Weiterleitungen im IIS angesehen und rekonfiguriert. Doch der Fehler blieb bestehen. So habe ich mir erstmal angeschaut, wie die Konfiguration vom https://www.testexchangeconnectivity.com betrachtet wird und dieser hatte auch einige Einstellungen zu bemängeln.
Danach habe ich ein wenig innerhalb von Technet recherchiert und bin dabei über folgenden Thread gestoßen,Microsoft Technet Forum
Zunächst wurde hier als Lösung angegeben, dass man die web.config unterhalb von (Standardkonfiguration) C:Inetpubwwwroot umbennen soll, z.B. in web.config.old.

Doch dies half bei mir nicht. Der Fehler blieb identisch. Einige passten auch die REchte an, doch dies würde ich aufgrund von Sicherheitsüberlegungen, nicht empfehlen. So fand ich noch einen Tipp, in dem angegeben wurde, dass in der IIS-Konfiguration die Bindungen der „Default Web Site“ entfernt werden sollen, wenn diese einen Hostnamen enthalten.
Nachdem ich dies probierte, konnte ich wieder ohne Probleme Mails löschen und verschieben. Eine erneute Prüfung mit https://www.testexchangeconnectivity.com zeigte auch keine Fehler mehr an.

Also, aufrufen von IIS-Manager und unter der „Default Web Site“ rechts auf „Bindungen“ und bei den Einträgen schauen, ob dort Hostheader angegeben sind (gilt für Port 80). Sollten welche angegeben sein, so können diese Einträge entfernt werden. Danach sollte die komplette Funktionalität von OWA gewährleistet sein. Der Fehler liess sich bei mir nachstellen. Sobald ich ein Eintrag zu den Bindungen hinzugefügt wurde, war die Funktionalität von OWA nicht mehr gewährleistet.

IIS 7 / 7.5 Hosting mehrere SSL-Seiten auf einer IP

Mit dem Webservern kann man auf Port 80 mehrere Domänen auf einer IP-Adresse, anhand des Hostnamen, hosten. Dies ist allerdings bei HTTPS-Verbindungen schwierig, da der Hostname ja durch das Zertifikat bereits ausgestellt wird und mehrere Hostnamen nicht zusammen mit einem Port und einer IP laufen können.
Es gibt allerdings einen Weg, wie man mehrere SSL-Verbindungen mit einem Webserver und einer IP realisieren kann.

Vorraussetzungen:

  • Ein Wildcard-Zertifikat (*.domain.de)
  • IP-Adresse für das Hosting mehrere Webseiten
  • Min. 2 Webseiten auf Port 80 mit Hostnamen (SSL-Hostname wird nachgetragen)

Um das ganze nun zu realisieren:

  • Eine Commando-Zeile mit administrativen Rechten aufrufen
  • Ins Verzeichnis C:WindowsSystem32inetsrv wechseln
  • Folgendes Kommando eingeben (ersetzen von {Sitename}, {IP} und {Hostheader} mit den gewünschten Werten)
    • appcmd set site /site.name:{SITENAME} /+bindings [protocol='https',bindingInformation='{IP}:443:{HOSTHEADER}']
    • appcmd set site /site.name:IIS Seitenname /+bindings.[protocol=’https‘,bindingInformation=’*:80:www.domain.de‘]
  • Zertifikat im IIS Manager prüfen, kann geändert werden, allerdings kann der Hostheader nicht angepasst werden

Mit diesem wenigen Handgriffen könnt ihr nun mehrere Webseiten, über HTTPS, auf einem Webserver zugänglich machen.

Um eine bestehende SSL-Verbindung zu ändern:

  • appcmd set site /site.name:{SITENAME} /bindings.[protocol='https',bindingInformation='{IP}:443:{HOSTHEADER}'].bindingInformation:{NEWIP}:443:{NEWHOSTHEADER}
  • appcmd set site /site.name:“Default Web Site“ /bindings.[protocol=’https‘,bindingInformation=’10.0.1.100:443:web1.f1nalbyte.de‘].bindingInformation:*:443:web1.f1nalbyte.de

siehe auch: http://www.sslshopper.com/article-ssl-host-headers-in-iis-7.html oder http://toastergremlin.com/?p=308

Installation von Galleryserverpro

Nach einiger Recherche für ein Galleryalternative zu Tinywebgallery bin ich auf Galleryserverpro gestossen. Im Gegensatz zu Tinyweb basiert Galleryserverpro allerdings auf .Net und MS SQLLite / MS SQL Server und benötigt den IIS 6.0/7.0 oder höher als Webserver.

Nach dem ich mir die Demo angeschaut habe, hat mir das ganze einfach besser gefallen, als die bisherige Tinywebgallery. Ausserdem hatte ich mit den bisherigen Bildern von unserem Urlaub immer wieder Probleme. So habe ich mich entschieden heut Galleryserverpro zu installieren. Leider machte der IIS 7.5 ein wenig ärger und lies mich nur mit ein wenig Aufwand ein seperate Serviceaccount für den Application Pool angeben. So musste ich letztendlich den ehemaligen SPS Farmadmin Account verwenden, dieser scheint im System mehr Rechte zu haben. Das werde ichaber noch ändern, habe mir bereits mit „icacls“ ein Auszug der Filesystemrechte gezogen und werde diese in den nächsten Tagen abgleichen.

Nachdem dieses Problem gelöst war, lief die Installation Problemlos. Bei der Insallation bin ich nach der sehr guten Dokumentation vorgegangen und hatte so auch keine Probleme. Nun haben wir eine, meiner Meinung nach, sehr professionelle Gallerie auf unseren Webspace die auch für viele Anwendungen verwendet werden kann.

Noch ein kleines Bild:

www.perupagos.de/mediathek

Exchange 2010 – IIS Fehlermeldung Verwaltungskonsole

Beim öffnen der Verwaltungskonsole auf dem Exchange 2010 kam es unter dem Punkt Serverkonfiguration -> ClientAccess zur folgenden Fehlermeldung:

Microsoft.Exchange.Management.Metabase.IISGeneralCOMException:

Um den Fehler zu bereinigen muss die Gruppe Exchange 2010 „Exchange Trusted Subsystem“ Lokale Administratorenrechte auf allen Exchange Servern innerhalb der Organisation haben. Ob dieser Fehler mit einer anderen Lösung zu bereinigen ist, habe ich derzeit noch nicht in Erfahrung bringen können.