All posts by Gregor Reimling

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

vSphere Virtual Machine Hardware Upgrade

Da Direct Access in meiner Umgebung derzeit immer noch nicht lauffähig ist und ich vom Gefühl her immer den Eindruck hatte, es liegt mit der virtuellen Netzwerkstruktur zusammen, habe ich die Hardware Versionen der Virtuellen Maschinen einem Upgrade unterzogen.

Zunächst einmal gibt es in der Hardware Version 7 vom vSphere 4 mehrere neue Hardwarekomponenten, die für eine bessere Performance sorgen sollen.

Darunter fällt zu einem der neue Netzwerkadapter vmxnet3 (Unterstützung von JumboFrames, Hardware Offloads, fully IPv6 Support, IPv6 offloads, usw.) und der neue VMware Paravirtualized SCSI Adapter (PVSCSI), der eine bessere Performance und weniger I/O-Last erzeugen soll.

Das Upgrade habe ich in mehreren Schritten durchgeführt:

  1. Zunächst einmal sollte man schauen, ob die IP-Liste der Server noch aktuell ist
  2. Wichtig ist vorher noch ein mal zu checken, dass die VMware-Tools auf dem aktuellen Stand sind, ggf. neu installieren bzw. updaten
  3. Solltet Ihr diese upgraden, danach ein Neustart durchführen und anschliessend die Virtuelle Maschine runterfahren
  4. Bevor ihr die Hardware Version aktualisiert, solltet Ihr eine Sicherung der VM anlegen, da ein Downgrade nur umständlich möglich ist
  5. Nun könnt ihr die Hardware Version der VM upgraden, in dem ihr ein Rechtsklick auf die VM im vSphere Client tätigt und dort “Upgrade Virtual Hardware”
  6. Hinzufügen einer neuen Netzwerkkarte in den VM-Eigenschaften vom Typ VMXNET3 und Zuordnung zur selben Port-Gruppe
  7. Hinzufügen einer neuen virtuellen Festplatte (Grösse unerheblich). Wichtig, diese muss dem SCSI-Punkt 1:0 oder höher zugewiesen werden
  8. Ändern des neuen, zweiten SCSI-Controller Typ in VMware Paravirtual
  9. Starten der VM, dabei am besten die Desktopansicht des VSphere-Clients verwenden, um keinen Verbindungsabbruch beim Ändern der IP-Adresse zu haben
  10. Nachdem anmelden, vorherige Netzwerkkarte auf DHCP stellen und bei der neuen Netzwerkkarte die IP-Adresse konfigurieren
  11. Neue Systemvariable anlegen “DEVMGR_SHOW_NONPRESENT_DEVICES” Wert= “1”
  12. Nun Geräte-Manager aufrufen und unter Ansicht “Ausgeblendete Geräte anzeigen” wählen
  13. Die vorherigen Netzwerkadapter “Intel Pro E1000” entfernen
  14. Nun sollte die Migration auf die neue Hardware abgeschlossen sein.

Wichtig: Laut VMWare ist es nicht supported, den Paravirtuellen SCSI-Adapter für Boot-Devices (Systemlaufwerk) zu verwenden, dieser soll ausschliesslich für Datenträger mit Daten und Anwendungen verwendet werden, siehe: VMware Paravirtual SCSI-Adapter Support

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.

Datei-Dienste auf WDC2 installiert

Auf dem WDC2 wurde nach folgender Anleitung http://blog.fumus.de/sharepoint/2010/04/dokumente-verwalten-mit-windows-2008-r2-und-sharepoint-2010-teil-1-dokumentenklassifizierung-unter-windows-2008-r2 die Funktion Ressourcenmangeer installiert.

Der Ressourcenmanager kann bereits Dokumente klassifizieren und mit Metadaten versorgen. Somit ist eine spätere Portierung in eine Sharepoint Farm einfacher, da die Metadaten bereits vorhanden sind.