Wir hatten das Problem, mit einem älteren Server auf welchem wir Citrix Xen Server installiert hatten und dort diverse VMs. Da wir aber nun auf ESXi umstellen wollten, kam die Frage auf, wie wir diese VM’s auf den ESXi kriegen.

Logischerweise testete ich dies mit dem VmWare vCenter Converter und dem VizionCore Free – vConverter SC. Bei beiden Produkten funktionierte dies leider nicht “Out-of-the-Box”, da Windows 2008 R2 wie auch Windows 7 eine 100MB grosse versteckte Partition erstellen und diese nicht migriert wird. Nach einigen Recherchen im Internet habe ich Anleitungen gefunden wie dies gehen soll. Nur sind die meines erachtens ziemlich kompliziert und es werden diverse Tools und Vorarbeiten benötigt.

Nach einigen Tests habe ich nun eine relativ einfache und effiziente Methode gefunden um eine Hot-Migration durchzuführen.

Die Tools welche ich eingesetzt habe sind folgende:

• VizionCore Free – vConverter SC
• VizionCore VA Appliance
• Windows 7 Recovery Disk 64-Bit welche von Neosmart bereitgestellt wird

Das Vorgehen:

Vorbereiten des ESXi

1. Installation und Konfiguration des ESXi
2. Importieren der VA “http://www.vizioncore.com/downloads/vConverter/VA/Esx VA 1.0.17.ovf”  über den vSphere Client
3. Konfigurieren der Appliance gemäss der Anleitung von VizionCore

Vorbereitung des Quellservers:

1. Zuerst habe ich die Xen Tools deinstalliert
2. Danach den Server welchen ich migrieren wollte mal sauber neu gestartet.
3. Der versteckten 100MB Partition vom Server einen Laufwerksbuchstaben zugeordnet (F:)
4. Danach Dienste heruntergefahren welche zu einer Inkonsistenz führen könnten (SQL, Exchange, etc.)

Migration des Servers

1. Starten des vConverters
2. Auswahl des Servers welchen ich migrieren und eine Konvertierungsaufgabe erstellt
3. Alle Volumen ausgewählt, bei den erweiterten Einstellungen den Adaptertyp auf LSI gestellt und natürlich, dass er den Quellserver nach der Konvertierung herunterfahren soll.
4. Migration starten und warten…..

Hochfahren auf dem ESXi und Patchen des migrierten Servers

1. Nachdem die Konvertierung fertiggestellt ist, muss man die VA von Vizioncore auf dem ESXi herunterfahren, da diese sich die Festplattendateien anhängt und sich die neue VM so nicht starten lässt.
2. Einstellungen der VM anpassen:
   - die Standardeinstellungen überprüfen (Servername, Arbeitsspeicher, etc.)
   - den SCSI Controller auf LSI Logic SAS umstellen
   - den Netzwerkadapter auf E1000 stellen (löschen und neu hinzufügen)
   - bei den “Allgemeinen Optionen” das Gastbetriebssystem auf “Microsoft Windows Server 2008 R2 (64-Bit)” umstellen
   - Zum Schluss die Windows 7 Recovery Disk 64-Bit in das CD-Rom einlegen oder mounten (Häckchen “Beim Einschalten verbinden” nicht vergessen)
3. Die VM hochfahren und ab der DVD starten.
4. Die Recovery Disc erkennt nun, dass etwas mit dem Boot-Record nicht stimmt und will dies korrigieren.
5. Reparatur des Boot-Records und neustarten.
6. Nochmals ab CD starten, da nun zwar der Server starten will aber im berüchtigten 7B Bluescreen endet. Daher nochmals ab der CD-starten.
7. Das Windows 7 Recovery System will nun noch mehr reparieren, kann dies aber nicht durchführen und bringt eine Auswahl mit diversen Reparatur möglichkeiten. An diesem Punkt “Command Prompt” auswählen.
8. Regedit eintippen
9. HKEY_Local_Machine auswählen und auf “File –> Load Hive” gehen
10. Dort auf die System Partition (D:) gehen, Windows\System32\Config und dort System auswählen.
11. Bei der Frage nach dem Namen habe ich p2v eingetragen
12. Nun den Eintrag p2v suchen unter HKLM und zu ControlSet001\Services\LSI_SAS navigieren und den REG_DWORD Wert von Start von 3 auf 0 setzen
13. wieder auf p2v klicken und auf “File –> unload Hive”
14. nun die VM nochmals neu starten und hochfahren lassen
15. VmWare Tools installieren neu starten
16. Testen, ob alles funktioniert und Windows erneut aktivieren

Wir alle wollen Sharepoint ja einmal auf dem neuen Windows Server 2008 am laufen sehen. Allerdings braucht WSS 3.0 wie auch MOSS 2007 jeweils die aktuelle SP1 Version um auf der neuen Windows Server Plattform zu funktionieren. Seit der RC1 Version des Windows Server 2008 wird WSS 3.0 nicht mehr mitgeliefert, sondern muss als separater Download heruntergeladen werden. Bei WSS 3.0 ist das nicht so ein Problem, da hier die Version mit integriertem SP1 auf den Downloadseiten von Microsoft vorhanden ist. Bei Office Sharepoint Server sieht das im Moment noch ein bisschen anders aus. Hier muss man im Moment den Installer und das SP1 zu einem neuen Installer zusammenfügen. Microsoft nennt das „Slipstream“. Für die Sharepoint SP1 Installation ist das sehr einfach. Hier ist wie man das macht.

1. Den Inhalt der original Installer CD von MOSS auf eine Festplatte kopieren. Im Beispiel habe ich lediglich den x86 Ordner kopiert. Dieser liegt im Ordner Download\MOSS beim Administrator

2. Danach das MOSS SP1 herunterladen.

3. Nun wird der Inhalt des SP1 in den Ordner „Update“ der Sharepoint Installation extrahieren. Dazu extrahiert man in der Command.Com das SP1 exe mit folgendem Befehl:

C:\Users\Administrator\Downloads>
officeserver2007sp1-kb936984-x86-fullfile-en-us.exe /extract:c:\Users\Administrator\Downloads\MOSS\x86\Updates

Wenn zusätzliche Sprachpakete (language template pack) installiert worden sind, muss man mit diesen aktualisierten Sprachpaketen gleich verfahren. Man entpackt sie analog dem Verfahren das man für das Service Pack angewendet hat in den Update Ordner.

Nun hat man einen Installer der direkt SP1 von Office Sharepoint Server 2007 installiert.
PS: MOSS Installation auf Windows Server 2008 RC1

1: WSS 3.0 SP1 installieren. Bei den Optionen die Option “Front End Server” auswählen. Ansonsten kann man bei der späteren MOSS Installation keinen SQL Server mehr auswählen, sondern kann ebenfalls nur noch einen Standalone Server installieren.

2: Das Setup des „geslipstreamten“ MOSS Installer starten.

Es kann durchaus sein, dass mann die Aus-, bzw. die Eingehenden Ports des Exchange ändern muss. Sei dies wegen eines Spamgateways oder weil der Provider den Port 25 gesperrt hat, um Spam-Verkehr zu vermindern.

Um den Empfangenden Port zu ändern, geht man folgendermassen vor.
Exchange Management Konsole öffnen –> Server Konfiguration –> Hub Transport –> Doppelklick auf den Default Receive Connector.
Dort kann unter Netzwerk der Empfangsport angepasst werden.

Der Sende-Port kann nicht mit der Konsole angepasst werden, sondern muss in der PowerShell angepasst werden.

Mit Get-SendConnector wird die aktuelle Konfiguration abgerufen. In meinem Beispiel heisst der Connector “Ex2007 –> Internet”

Mit Get-SendConnector -Identity "SENDCONNECTORNAME" | fl kann man die komplette Konfiguration des Connectors abrufen.

So, nun haben wir alle Angaben und können den Port mit dem Befehl Set-SendConnector -Identity "SENDCONNECTORNAME" -Port 587 anpassen.

Mit dem schon bekannten Befehl Get-SendConnector -Identity "SENDCONNECTORNAME" | fl kann nun überprüft werden, ob der Port auf 587 gesetzt wurde.

Seit gestern ist das Service Pack 1 für den SharePoint Server 2007 offiziell verfügbar. Das Service Pack 1 ist ebenfalls für den Windows SharePoint Service 3.0 erschienen. Was ist enthalten? Das Service Pack 1 enthält rund 60 Hotfixes in allen Bereichen der SharePoint Technologie und Produkten. Weiter wurde die Kompatibilität zu dem, bald verfügbaren, Windows Server 2008 hergestellt. Die neuen Funktionen im Bereich Administration, mit der Windows Server 2008 aufwartet, können nun auch mit dem SharePoint Server verwendet werden. Mit dem Service Pack 1 können nun Entwickler Web Parts auch mit AJAX programmieren. Entweder über die .NET 1.0 Extension oder dem AJAX 1.0 Control Toolkit für MS .NET. Weiter sind ein paar neue STSADM.EXE Befehle hinzugekommen. Unter anderem einen Befehl um Site Collections zwischen unterschiedlichen Inhaltsdatenbanken zu verschieben und einen Befehlssatz um den Scope des People Picker einzugrenzen oder zu erweitern.

Hier auf Scolab existiert bereits ein HowTo über das Aktualisieren einer SharePoint Farm. Dieser Artikel beschreibt das Einspielen eines Sicherheits-Hotfixes. Das Update des SP1 ist im Prinzip fast gleich. Aber eben nur fast! Microsoft hat die Links zu Dokumenten die das Upgrade einer SharePoint Farm beschreiben auf einer speziellen TechNet Seite zusammengefasst. Zusammenfassend die wichtigsten Punkte.

Für das Upgrade einer Farm müssen die Front-End Webserver und die Applikationsserver gestoppt werden. Das heisst, während dem Update wird der SharePoint dem Betrieb nicht zur Verfügung stehen. Das wiederum bedeutet Nachtschicht für den Farm Administrator, den DB-Admin und irgendjemand aus dem Backup und Restore Team (Just in case).

Für sehr grosse SharePoint Farmen empfiehlt es sich die Datenbanken von der Farm abzuhängen und an andere temporäre Front-End Server zu binden. Dies ist der einzige Weg um die „downtime“ der Farm zu minimieren. Nach dem alle Server mit der Aktualisierungen des Service Pack 1 ausgestattet sind, nimmt man dann eine Datenbank nach der anderen wieder zurück. Bei diesem Vorgang wird jede Datenbank beim Anhängen an die Farm automatisch aktualisiert.

Vor dem Update sollten alle SQL DBs der Farm gesichert werden. Nach diesem Backup sollte man mit dem SQL DBCC shrinkfile Befehl die Log Dateien der DB verkleinern.

Der Index Server braucht unter MOSS 2007 SP1 mehr Platz. Die Methode um die Indexes zu bearbeiten hat sich unter dem SP1 geändert. Dies steigert zwar die Performance, braucht dafür aber mehr freien Platz auf der Disk. Die Faustregel war bisher, immer das Doppelte der Grösse des Indexes frei zu haben. Diese Regel ändert sich nun auf das Dreifache der physischen Grösse des Indexes.

Vor dem eigentlichen SharePoint Server Update muss auf allen Servern der Farm das Service Pack 1 von Windows SharePoint Serrvices 3.0 installiert werden. Nachdem dieses Update durch ist, startet die Installationsroutine den „SharePoint Products and Technologies Configuration Wizard“. Dieser darf aber nicht ausgeführt werden. Sondern jetzt wird das eigentlich Service Pack Update des SharePoint Servers installiert. Wenn diese Installationsroutine durch ist, wird ebenfalls der „SharePoint Products and Technologies Configuration Wizard“ gestartet. Dieser sollte aber auch jetzt nicht durchgeführt werden. Sondern zuerst alle anderen gestoppten Server der Farm mit dem Update ausgestattet werden. Wie in unserem HowTo über das Updaten einer SharePoint Farm detailiert beschrieben, muss zuerst der Server auf dem die Administrative Webseite ausgeführt wird, über den „SharePoint Products and Technologies Configuration Wizard“, aktualisiert werden. Nach dem erfolgreichen Update der Farm sollte in der Zentral Administration -> Operations -> Servers in Farm die „Farm Version“ 12.0.0.6219 angezeigt werden.

Für jedes installierte „language template pack“ muss ebenfalls eine aktualisierte Version installiert werden. Auch hier müssen sowohl für WSS 3.0 wie auch für MOSS 2007 die beiden aktuellen „language template pack“ nacheinander installiert werden. Allerdings können die Dateien der beiden Updates ganz einfach durch Zusammenkopieren der beiden extrahierten Installationsordner in einem Durchgange installiert werden.

Der Foxit PDF IFilter funktioniert nach dem Update auf SP1 nicht mehr. Um dieses Problem zu beheben muss man den iFilter erneut installieren.

Standardmässig wenn man eine SharePoint Webapplikation mit Form-based Authentication erstellt oder erweitert, ist die „Client Integration“ auf „No“ gesetzt. Dadurch können Produkte aus der Office Suite nicht nahtlos mit dem SharePoint Server zusammen arbeiten.

Um die Office Integration auch bei Form-based Authentication sicher zu stellen ist der erste Schritt als hier sicher zu stellen das die „Client Integration“ auf „Yes“ gesetzt ist.

Wenn sich nun ein Benutzer anmeldet muss er gegen die erste Logik „Sign me in automatically“ aktivieren. Dadurch wir ein persistentes Cookie erstellt welches sich der Webbrowser und die Office Applikationen teilen können.

Wenn der Benutzer dies nicht macht, wird einfach ein einfaches Session Cookie erstellt, welches nur innerhalb des Browser verwendet werden kann.

Interessante Links zu diesem Thema:
- Wie werden Dokumente von einer Website in Office 2003 geöffnet
- Enabling Forms-based Authentication for SharePoint 2007

Seit dem Mitte August steht das SP1 von Microsoft Forefront Security für SharePoint zur Verfügung. Das Service Pack wird in 11 Sprachen ausgeliefert. Allerdings kann man es nicht als dezidiertes Service Pack beziehen, sondern nur als Installer in dem Forefront Security für Sharepoint inklusive Service Pack 1 angeboten wird. Allerdings werden nach meinen Erfahrungen die Einstellungen von der ursprünglichen Version übernommen. Das SP1 behebt eine ganze Reihe von Fehlern. Der wichtigste Fix ist sicher der „Impersonation Fix“.

1. Impersonation Fix
Dieser Fehler erlaubte es in unserer Umgebung nicht, das wir Dokumente beim Upload scannen konnten. Wenn wir in der Central Administration „Scan document on upload“ aktiviert hatten, erschien beim Upload eines Dokuments eine Fehlermeldung das ein Virus namens „“ gefunden wurde.

Der Fehler ist eigentlich ein Sharepoint Fehler. Sharepoint verwechselt für gewisse interne Prozesse den regulären Benutzer welcher einen Prozess angestossen hat, mit dem Benutzer des „application pools“ welcher wiederum für gewisse Prozesse aber benötigt wird. In diesem Fall hat der Benutzer welcher einen Upload tätigt keinen Zugriff auf die Forefront Registry Einträge. SP1 von Forefront Security für SharePoint stellt nun sicher, das die „Sharepoint application pools“ Credentials für diesen Prozess benutzt werden. Gleichzeitig stellt er sicher, dass wenn SharePoint durch einen Hotfix oder über ein Service Pack dieses Verhalten nicht mehr aufweist, dieser Wechsel der Credentials nicht mehr vornimmt.

2. File Size Fix
Die maximale Grösse einer Datei sollte eigentlich 2GB sein. In der aktuellen Version ist sie aber nur 128MB. Dieser Fehler wurde behoben.

3. STSADM Fix
Eine Inkompatibilität zwischen Forefront und STSADM.EXE führte bei Import- oder Export Vorgängen zu Abstürzen. Dies weil der Forefront Prozess als „Network Service“ läuft. So hatte Forefront die Berechtigung nicht, Dateien die über den STSADM.EXE „Weg“ in das Sharepoint System kommen, richtig zu scannen. Allerdings konnte Forefront gegenüber STSADM.EXE auch keine Fehlermeldung präsentieren. Stattdessen stürzte einfach STSADM.EXE ab.

4. Manual Scan Fix
Nun, ist es möglich, dass ein manueller Scan das Microsoft Virus Scan API (VSAPI) für die Zeit des Scans deaktivieren kann, so dass der Scan effektiver arbeiten kann. In der ursprünglichen Version war das nicht möglich. So wurde einfach ein weiterer „real-time scan“ angestossen.

5. Crashes
Manchmal führten Änderungen an den Anti Virus Einstellung in der Zentraladministration zu Abstürzen von Sharepoint 2007. Um das Sharepoint System wieder in einen brauchbaren Zustand zu kriegen musste man sich dann mit den Diensten herumschlagen oder den Server neustarten.

6. Non-ASCII Keyword Filtering
Nun werden auch Non-ASCII Keywords aus Office 2007 Dokumenten korrekt ausgelesen.

8. Softblock Forefront Sharepoint und Exchange auf dem gleichen Server
Forefront moniert nun während der Installation, das diese Kombination nicht vorgesehen ist. Trotzdem erlaubt es der Installer weiter zu installieren.

9. CA InoculateIT Engine Fix
Commputer Associates (CA) kombinierte ihre beiden Virenscan Engines InoculateIT und CA Vet in eine Virus Engine. Diese Änderung reflektiert sich nun in Forefront für Sharepoint SP1 dadurch, dass man die InoculateIT Engine nicht mehr auswählen kann.

Installation
Als Pre-Requisite für Forefront Security für Sharepoint SP1 nennen Microsoft interne Quellen den SharPoint Hotfix KB936867. Welcher aber nicht heruntergeladen werden kann. Dieser muss telefonisch bei Microsoft nachgefragt werden.
Danach stoppt man folgende Dienste auf dem Server:

- MOM
- Perfmon
- Eventvwr
- SPTimer

Dieser Schritt spart uns den Neustart am Ende der Installation. Nun wird Forefront Security für Sharepoint SP1 installiert über das Setup Package gestartet. Nach Abschluss der Installation kann man die oben genannten Dienste wieder starten.

Forefront Security for Sharepoint Webseite

Um Exchange richtig und Sicher zu betreiben benötigt man mit dem Exchange 2007 einen neuen Zertifikats-Typ mit mehreren Servernamen im Zertifikat. Es reicht nicht mehr nur noch ein Zertifikat für owa.firma.ch zu registrieren, damit man mit SSL auf das OWA zugreifen kann. Importiert man dieses so, kommt spätestens beim öffnen des Outlook 2007 eine Fehlermeldung, dass der Name auf dem Zertifikat nicht mit dem Namen des Servers übereinstimmt. Daher müssen im Zertifikat mehrere Namen hinterlegt werden können. Dies geht mit sogenannten x509 oder TLS Zertifikaten.

howto_eigene_zertifikate_fuer_exchange_2007

Nicht alle IT-Abteilungen haben die Möglichkeit ein eigenes IT-Labor zu betreiben. Um den Benutzern trotzdem die neuen Möglichkeiten von Exchange 2007 zu zeigen, konnte man von Microsoft die vorgefertigten „Virtual Server Images“, mit dem kostenlosen “Microsoft Virtual Server 2005” nutzen.

Wenn auch dies nicht möglich ist, gibt es jetzt eine weitere Variante, um den Benutzern die neuen Möglichkeiten zu demonstrieren. Microsoft stellt neu ein “Microsoft Exchange Server 2007 Hosted Trial” zur Verfügung. Man kann damit die neuen Einstellmöglichkeiten erkunden, Mails mit Outlook und Outlook Web Access senden und empfangen und sogar Outlook Voice Access nutzen.

Während dem Test wird eine temporäre E-Mailadresse erstellt und mit Musterdaten vorbereitet. Dieses Konto kann man dann während fünf Tagen online kostenlos testen.

Ein neues Schlagwort von Exchange 2007 heisst, Outlook Anywhere. Bei Exchange 2003 hiess dieses Feature noch RPC over HTTP. Das Prinzip ist aber immer noch dasselbe.
Das Setup von Outlook Anywhere wird in diesem scolab.ch How-To Schritt für Schritt erklärt.

how-to_outlook_anywhere

Die neue Grundhaltung von Microsoft, dass jede Platform eine “Secure Platform” zu sein hat, macht sich auch bei der Microsoft Exchange Installation bemerkbar. Neu akzeptiert Exchange grundsätzlich nur noch Authentifizierte- und Exchange 2007-Kommunikation. Bei einer Standard Exchange Installation werden E-Mails über einen nicht authentifizierten Mailserver nicht mehr akzeptiert.

Damit aber die “herkömmliche” Kommunikation wieder funktioniert, muss auf dem “Default Receive Connector” die Permission Group ”Anonymous” manuell aktiviert werden. Dies findet man unter, Server Configuration –> Hub Transport. Einen Neustart des Connectors erfolgt automatisch.