Category Archives: Microsoft

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.

Exchange 2010 SP1

Da gerade ein wenig Zeit besteht, werde ich die Installation vom Service Pack 1 für Exchange 2010 vornehmen.
Ein einfacher Klick auf setup.exe reicht hier nicht aus. Zunächst sind einige Vorarbeiten notwendig. Unter anderem müssen einige Patches installiert werden, die nicht über WSUS verteilt angeboten werden. Vorher sollte das Backup nicht vergessen werden. Ich gehe hier von der Installation auf einem Exchange 2010 unter Server 2008 R2 aus.

Exchange 2010 SP1 Begrüßung

Vor der Installation des Service Packs sind einige Vorbereitungen, wie bereits erwähnt, notwendig. Da der Download vom SP1 ca. 550MB nicht gerade klein ausfällt, sollte man den Download bereits anstoßen.
Das Service Pack 1 für Exchange 2010 könnt ihr hier Downloaden:
http://technet.microsoft.com/de-de/evalcenter/dd185495

Außerdem sind folgende Patches Vorraussetzungen bzw. Empfohlen:
KB982867 – WCF: Enable WebHeader settings on the RST/SCT
http://code.msdn.microsoft.com/KB982867
NET Framework 2.0-based Multi-AppDomain application stops responding when you run the application
http://code.msdn.microsoft.com/KB979744

http://support.microsoft.com/hotfix/KBHotfix.aspx?kbnum=977357&kbln=en-us
Microsoft Unified Communications Managed API
http://download.microsoft.com/download/3/6/9/3693C940-1B9A-4386-836F-A21C7F4AE9C6/UcmaRedist.msp
Office 2010 Filterpack
http://download.microsoft.com/download/0/A/2/0A28BBFA-CBFA-4C03-A739-30CCA5E21659/FilterPack64bit.exe
Exchange 2010 Prüfung der Vorraussetzung
Die Installation der Patches lässt sich mit folgendem Befehl vereinfachen:
For /F “” %%i IN (‘Dir /B *.msu’) Do wusa %%i /quiet /norestart
Wichtig: Danach einen Neustart des Server durchführen!

Weiterhin muss zunächst das UM Language Pack deinstalliert werden
setup.com /RemoveUmLanguagePack:DE-de

Nachdem diese Voraussetzungen erfüllt wurden, sollte die nächste Prüfung folgendermaßen aussehen:
Exchange 2010 SP1 Erfolgreiche Voraussetzungsprüfung

Danach konnte das Update gestartet werden. Das Update benötigte in meiner kleinen Umgebung ca. 1 Stunde bis zum Abschluss. Nach Abschluss benötigte das Setup keinen Neustart.
OWA präsentierte sich beim erneuten Einloggen in einem deutlich überarbeiteten Layout.

Mit einigen Vorbereitungen und ein wenig Zeit verlief das Setup ziemlich unspektakulär. Leider kam der ganze Prozess aufgrund der Updates, die nicht über WSUS verteilt werden, nicht wirklich ohne Neustart aus. In einer hochverfügbaren Umgebung oder mit mehreren Servern, sollte der Updateprozess geplant werde.

WSUS 3.0 Event ID 12052, 12042, 12032, 12022, 12012, 12002

Aus dem nichts tauchten bei mir in der Ereignisanzeige die angegebenen Fehler auf, die aussagten, dass alle Webdienste nicht funktionieren. Nach diversen Recherchen, waren unterschiedliche Lösungsvorschläge. Überprüfen der ASP. Net Berechtigung, Neuinstallation des SelfupdateonPort80 (allerdings fragte ich mich, wass das mit dem Fehler zu tun haben sollte) usw.

Letztendlich habe ich den Fehler auf fehlende Berechtigung von .NET auf das Windows Temp- Verzeichnis eingrenzen können. Dort hatte cih letzte Woche was in Zusammenhang mit Sharepoint verstellt. Nachdem ich zunächst die Gruppe “Jeder” berechtigt habe, erzeugte der erneute aufruf von “wsusutil.exe checkhealth” wieder Informationen und keine Fehler. Danach habe ich die Berechtigung weiter eingeschränkt auf die Gruppe “IIS_IUSRS”. Ein erneuter Aufruf blieb weiterhin ohne Fehler.

Computerkonten im AD und SMS 2003 löschen

Nachdem wir vor einigen Wochen eine Regeneration hatten, sind nahezu 80% der Clients ausgetauscht worden. Diese Clients besitzen ja nun noch Computerkonten in der AD und im SMS 2003.
Wie sollte es auch anders sein, kam natürlich vor kurzem eine Lizenzabfrage, der aktuellen Clients, so müssen wir nun adhoc die Computerkonten im AD und SMS bereinigen.

Active Directory
Im AD lässt sich dies relativ einfach realisieren (Vorraussetzungen: min. Windows Server 2003). Mit dem Tool dsquery lassen sich die inaktiven Computerkonten der vorgegebenen Wochen anzeigen. Die Ausgabe lässt sich auch zugleich als Eingabe für eine Löschung nutzen.
Beispiel: dsquery computer ou=Clients,DC=Test,DC=Domain -inactive 3 -limit 0 -s domaincontroller01 | dsrm -s domaincontroller01 -c
Im Beispiel werden alle Computerobjekte, die in den letzten 3 Wochen (-inactive 3) inaktiv waren, auf dem Domaincontroller01, aus der OU=Clients entfernt. Das Entfernen geschieht nach der Pipe (|) mit dsrm, der Parameter -c gibt an, dass auch bei Fehlern, der Vorgang fortgesetzt wird.
Zu beachten ist, dass die AD Computerobjekte als Tree ansieht, wenn an den entsprechenden Computerobjekten ein Drucker frei gegeben wurde. Hier muss der Parameter -subtree angehängt werden.

SMS 2003
Für den SMS 2003 bin ich über einen Interesannten Blogeintrag gestolpert:

Deleting computers from SMS 2003 (and perhaps SCCM 2007), with a script.


Das Script steht zum Download zur Verfügung und funktioniert einwandfrei.

Mit diesen beiden Tools konnte ich unsere Umgebung relativ schnell auf einen sauberen Stand bringen und wir waren in der Lage die Lizenzabfrage relativ schnell zu beantworten.

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

Sharepoint 2010 Installation

Vor einigen Tagen wurde die Installation des Sharepoint Servers 2010 in einer dreistüfigen Farm vorgenommen. Dabei verlief die Installation nach der Dokumentation auf technet ab und war relativ unspektakulär. Viel wichtiger ist die Vorbereitung der benötigten Dienstkonten und die Anpassung der Rechte z.B. für den Sharepoint Farmadministrator auf dem SQL-Server.
Für den großteil der Dienste wurden einige Dienstkonten im AD angelegt. Diese wurden im Sharepoint eingetragen und dort wurde auch gleich Gebrauch von der neuen Funktion “Managed Accounts” gemacht. Hierrüber lassen sich die Dienstkonten für den Sharepoint-Server zentral verwalten und zudem wird automatisch ein Passwortwechsel, basierend auf den Kennwortrichtlinien, vorgenommen.
Auf eine bebilderte Anleitung verzichte ich an dieser Stelle, da es hier zu schon genügend gibt und ich, wie bereits oben erwähnt, rein nach der TechNet Doku vorgegangen bin.

Ein nettes Feature ist auf jeden Fall die Statusanzeige der Sharepoint-Farm auf der Seite der Zentraladministration. Nach Abschluss der Installation wurden hier noch einige Warnungen (z.B. doppelt verwendete Dienstkonten, Dienstkonten in der Gruppe der lokalen Admins, usw.) angezeigt, die nach den vorhandenen Informationen, bereinigt wurden.

Zunächst wurde ein weiteres Zertifikat für die Zentraladministration beantragt. Danach wurde eine Teamwebseite angelegt, auf der ein DMS eingerichtet wird, welches die neuen Funktionen von Sharepoint 2010 nutzen soll, wie z.B. Metadaten Service und die Navigation zu Dokumenten über die vorhandenen Metadaten. Ausserdem sollen die bisher vorhandenen Daten, nach und nach, auf den Sharepoint wandern und die neu angelegten Dokumente direkt im Sharepoint erstellt werden.

Das Backup der SQL-Datenbanken ist bereits im DPM 2010 eingerichtet. Die Sicherung der Sharepoint-Farm an sich, ist ein weiterers Thema, was die nächsten Tage angegangen wird.

DPM 2010 Installation

Die Installation der RTM Version von DPM 2010 erfolgt auf dem Backupserver. Die Routine prüft, vor der Installation, ob alle erforderlichen Komponnten vorhanden sind. Bei der Installation auf einem Windows Server 2008 werden noch einige Patches benötigt, die unter den angegebenen Links herunter zu laden sind. Ein Patch befindet sich im Quellordner unter RedistKB975759.

Danach ist ein Neustart erforderlich und die Routine muss erneut aufgerufen werden.

Die Installation gestaltet sich recht simpel. Für die ersten Tests, habe ich einen SQLServer mit auf dem BackupServer installieren lassen, ob ich dies später auf den SQL-Server ändere, werde ich mir noch überlegen. Zumindest werden nun auch SQL Server 2008 untersützt.

Die Installation der Agents auf den Domänenserver war leider wieder nicht über die GUI möglich,erneut erschien der Fehler 337 Zugriff verweigert, eine Deaktivierung der Firewall ist eine Lösung. Ich habe aber ein Skript erstellt, welches die Installation vornimmt.

  1. Zunächst das Verzeichnis %Program Files%DPM2010DPMProtectionAgents Lesend freigegeben
  2. Skript für x86 und x64 erstellt
  3. Skript für x86: net use P: \backupserverdpmprotectionagents
    P:RA3.0.7696.0i386DPMAgentInstaller_x86.exe f1nalbackup1.f1nalbyte.de
  4. Danach muss der Server noch in die Verwaltungskonsole vom Backupserver eingetragen werden, dazu starten der Verwaltungsshell DPM 2010 und eingabe von: .ProductionServer.ps1 <DPM server name> <production server name> <user name> <password> <domain>.l

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

Windows 7 Remotedesktop Zertifikat anpassen

Um das zu verwendende Zertifikat für z.B. Server 2008 anzupassen, kann man hier das Tool tsconfig.msc.

Dies ist allerdings in den Client-Versionen nicht verfügbar. Standardmässig verwendet Windows 7 ein selbst signiertes Zertfikat für die Remotedesktop Verbindung, welches natürlich nicht von einer authorisierten Zertifikatsverwaltung ausgestellt ist.

Um diesen Fehler zu vemeiden und das von der (falls vorhanden) eigenen Zertifizierungsstelle, ausgestellte Zertifkat zu verwenden, sind mehrere Schritte notwendig:

  1. Öffnen der Zertifikatsverwaltug auf dem Client und auswählen des Zertifikats, welches für die Remotedesktopverbindung genutzt werden soll.
  2. Um Remotedesktop das korrekte Zertifikat zur Verwendung mitzuteilen, muss sich der SHA1Hash (Fingerabdruck) notiert werden.
  3. Nun starten wir “Regedit”  und navigieren zu folgendem Schlüssel “HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlTerminal ServerWinStationsRDP-Tcp” und hier legen wir einen neuen “SSLCertificateSHA1Hash” , binärischen Wert (REG_BINARY) an.
  4. Als Wert geben wir den oben notierten Fingerabdruck des zu verwendenden Zertifikats ein
  5. Leider war das noch nicht alles, da die Remotedesktopdienste unter Windows 7 im Sicherheitsaccount “Netzwerkdienst” laufen, muss dieser noch entsprechend berechtigt werden, dass Zertifikat einzulesen, dazu starten wir zunächs ein Managementkonsole “mmc.exe” und fügen unter Snap-In “Zertifikate” hinzu, im erscheinenden Auswahlfenster wählen wir “Computer” aus, klicken auf weiter, lassen “Lokalen Computer” aktiviert und bestätigen die Auswahl mit einem Klick auf “Fertigstellen
  6. Nun navigieren wir zum Fenster “Zertifikate -> Eigene Zertifikate -> Zertifikate” und starten einen Rechtsklick auf das Zertifikat im Kontext wählen wir “Alle Aufgaben -> Private Schlüssel verwalten
  7. Im erscheinenden Fenster wählen wir “Hinzufügen” und geben den “Netzwerkdienst” an und geben diesem die Berechtigung “Lesen

Die nächste Remotedesktopverbindung sollte nun mit dem angegebenen Zertifikat starten, dies Funktioniert direkt nach dem nächsten Versuch einer Remoteverbindung mit dem Windows 7 Client

Die Informationen stammen aus einem Technet Forum und haben bei mir einwandfrei funlktioniert.