Die Master Datenbank kann nicht mittels des Befehls ALTER DATABASE verschoben werden. Das liegt daran das die Master DB alle Systeminformationen des SQL Dienstes vorhält und somit beim Starten des Dienstes direkt geladen wird.

Aus diesem Grund muss der Speicherort der Master DB Dateien im “SQL Server Configuration Manager” angepasst werden.

Als erstes muss der SQL Server Dienst beendet werden.
Als nächstes müssen die Dateien der Master DB in das neue Verzeichnis kopiert werden.
Nun öffnet man die Eigenschaften der gewünschten SQL Server Instanz

Der Speicherort der Master DB ist in den Startup Parameters definiert.

-dC:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA\
master.mdf;-eC:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\
LOG\ERRORLOG;-lC:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\
DATA\mastlog.ldf

-d Gibt die Datendatei an.

-l  Gibt die Logdatei an.

-e Gibt den Pfad fürs Error Log an.

Hier kann der Pfad der Master DB Dateien jetzt auf das neue Verzeichnis, in dem die Kopien der Dateien liegen, angepasst werden.

Abschließend muss der SQL Server Dienst wieder gestartet werden.

Unter Umständen kommt man in die Situation, dass man die Datenbankdateien sowie Log-Files verschoben werden müssen, z.B. weil eine Festplatte voll ist.

In diesem Beispiel heißt die Datenbank DB1 und hat folgende Dateien.

Die Dateien sollen jetzt von c:\data nach x:\data verschoben werden.

1. ALTER DATABASE DB1 SET OFFLINE WITH ROLLBACK_IMMEDIATE

2. Kopiere die Datenbankdateien von C:\data nach X:\Data

3. ALTER DATABASE DB1 MODIFY FILE(NAME = DB1_Data, FILENAME = “X:\data\DB1_Data.mdf”)

4. ALTER DATABASE DB1 MODIFY FILE(NAME = DB1_Log, FILENAME = “x::\data\DB1_Log.ldf”)

5. ALTER DATABASE DB1 SET ONLINE

Wichtig: Diese Methode kann nicht auf die MASTER Datenbank angewendet werden!

Bei der Migration von Microsoft Office SharePoint Server 2007 auf Microsoft SharePoint Server 2010 kann gewählt werden, ob direkt das neue SharePoint Layout eingesetzt werden soll, oder ob das Portal zunächst im alten Layout weiterbestehen soll.

Das Visual Upgrade erst später durchzuführen ist vor allem dann sinnvoll, wenn zunächst noch Anwenderschulungen durchgeführt werden sollen, welche jedoch zum Zeitpunkt der eigentlichen Migration noch nicht stattfinden konnten, oder diese am eigenen System durchgeführt werden sollen.

Einer der Vorteile beim Visual Upgrade ist die Möglichkeit, das neue Layout erst zu testen, bevor es endgültig freigeschaltet wird. So können Administratoren beliebig zwischen beiden Ansichten umschalten, ohne das dies Auswirkungen auf die Ansicht der Endanwender hat.
Das Visual Upgrade ist außerdem Seitenbasiert, so können einige Seiten bereits migriert werden, während andere noch im alten Layout verbleiben.

Um das Visual Upgrade für eine einzelne Site durchzuführen müssen zwei Schritte ausgeführt werden:

1. Ändern der Masterpage auf “V4.master”
2. Auswahl der Aktion “Visual Upgrade” aus dem Site Actions Menü. An dieser Stelle können Administratoren festlegen, ob es sich bereits um das endgütige Upgrade oder nur um eine Vorschau zum Testen handeln soll.

Hat man viele Sites in seinem Portal kann das manuelle Visual Upgrade ziemlich lange dauern, doch zum Glück lässt es sich (wie fast alles in SharePoint 2010) über die PowerShell automatisieren:

$db = Get-SPContentDatabase <Name der Content Datenbank>
$db.Sites | Get-SPWeb -limit all | ForEach-Object {$_.UIversion = 4;
$_.UIVersionConfigurationEnabled = $false; $_.update()}

Seit dem 18.06.2010 steht jetzt auch der SQL Server 2008 R2 Best Practices Analyzer (BPA) zum Download auf der Microsoft Webseite bereit.

http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=0fd439d7-4bff-4df7-a52f-9a1be8725591

Der SQL Server 2008 R2 BPA ist ein Diagnosetool, welches den SQL Server anhand von Best Practices analysiert und einen Bericht ausgibt, in dem auf mögliche Konfigurationsfehlern oder Fehlenden Updates hinweist.

Der BPA gibt auch genaue Hinweise wie die möglichen Probleme gelöst werden können.

SQL Server 2008 R2

My last posts about Reporting Services in SQL Server 2008R2 covered the new support for maps and how to import and work with ESRI shape data.

However, those new features of Reporting Services are not limited to geographical map data (countries, regions etc.) but can be used to visualize almost any kind of polygonal data. For example, there are very interesting posts showing how to actually draw a heat map using SSRS’s map technology. If you’re interested, I suggest taking a look at one of these posts:

• http://prologika.com/CS/blogs/blog/archive/2009/08/30/heat-maps-as-reports.aspx
• http://www.codeproject.com/KB/recipes/treemaps.aspx

Being able to show different kind of geometrical data also makes it interesting to use this feature for store layouts. Basically my idea was this:

• Use Microsoft Visio as an editor for the store layout
• Export all sheets of the Visio file to a data base table
• Use Reporting Services to visualize the visio shape information and link some parts of the graphic to an analytical data set for shading

For my example, I created a layout of a park house. Each slot is to be colored depending on the number of parking hours they were occupied during a selected period. Here is the final SSRS report:

And here is the corresponding Visio file I made for this purpose:

The main reasons for me to explore this approach instead of simply using Visio services (included in Sharepoint) are:

1. Purely data driven approach – all layout data is stored as spatial data in a SQL Server table
2. All layouts (for example several stores with different layers) could by managed in a single Visio file (or a few Visio files)
3. The interactivity (for example link action to another drawing) and the mapping to the data can be highly automated.
4. It is very easy to create a report that checks, if shapes are missing (data available, but no corresponding shape in the geometry table).
5. Suitable for users without access to Sharepoint or without the Sharepoint Enterprise CAL

The approach described here is suitable for

• Any kind of store layouts (for example: mapping from product sales to the area in the store)
• Custom geographical maps (it’s quite easy to load a bitmap into Visio and then create some polygons on top of it to get the proper shapes)
• Visualization of technical systems or processes
• Strategy maps
• Etc.

During the development I had some issue to solve, so this post is to describe my general approach. At first, I was quite surprised to find how difficult it is to get the shape data out of Visio. You could export the Visio file to DXF format and use one of the converters from DXF to ESRI you will find in the web. But this seems like a complicated process to me. So for my example, I wrote a Visio macro to actually perform the export. My destination table looks like this:

In order to display the map on an SSRS report, the map tool requires to set up a layer. For each layer you are relatively free to display shapes. However, there are some restrictions:

• Each layer must contain either polygon or line or point shapes. No mixture is allowed
• Each layer may be set up to acquire its shading color either from an analytical data set or from expressions (that can link to existing data of course)

In order to set up the layers for my map, I used the following layout:

In Visio I’m using the Layer functionality to mark all the interactive elements (for layer 1), so this is how my drawing looks like in Visio when hiding this layer:

But how about the round shapes? How are they converted to a polygon. Although I was concerned a little, Visio does this job pretty well. In the following extract of the code, patchcount is a variable to loop through each path contained in the shape (oShape) and adblXYPoints is simply an array of numeric values. The 0.01 gives the precision Visio uses to transform the curves into polygons.

oShape.Paths(pathcount).Points 0.01, adblXYPoints

For layer 0, all shape properties are linked to the underlying data set. For example, this is how the font tab is configured:

You can clearly see that field bindings or expressions are used to configure the properties. For example, the expression for the font size looks like this:

=Fields!fontsize.Value & "pt"

The distribution of the spatial data to the layers is done by using one single data set together with the filters in the layer’s data properties. The the background layer 0, the filter is defined as follows:

However, I had some problems with the filter when using the analytical data, so I created a separate data set for the interactive layer.

Finally, the export from Visio to my geometry table works fine although not all of Visio’s graphical features can be rendered by a Reporting Services map. I’m still surprised how good the rendering actually looks and how easy it is, to link it with some analytical data to get a nice visualization.

Der folgende Beitrag spiegelt unsere Erfahrungen mit der Variante der Database Migration als Migrationsart von SharePoint 2007 nach SharePoint 2010 und beleuchtet einige Eigenheiten dieser Variante. Eine Übersicht über die verschiedenen Upgrade Möglichkeiten können diesem Beitrag entnommen werden.

Für die Migration des ORAYLIS internen MOSS 2007 auf SharePoint 2010 haben wir uns für den Weg der Database Migration entschieden. Dieses Vorgehen wurde vor allem gewählt, da die Migration auch gleichzeitig genutzt werden sollte, um einige infrastrukturelle Änderungen vorzunehmen. Außerdem kann auf diese Art und Weise vermieden werden, dass Altlasten aus dem bestehenden System übernommen werden. Auch ist die Ausfallzeit des Systems bei dieser Variante am geringsten.

Einem erfahrenen SharePoint Administrator sollte das Upgrade mit Hilfe der Database Migration keine allzugroßen Probleme bereiten. Vorteilhaft ist es, wenn bereits Erfahrungen mit dem Austausch oder Umzug der Content Datenbanken gemacht wurden. Und – wie bei so vielen Aufgaben – ist auch hier die Vorbereitung das halbe Leben. Die Dokumentation von Microsoft zum Upgrade sollte gelesen und verstanden sein, genauso sollte bereits im Vorfeld ein wenig Erfahrung mit den neuen Features von SharePoint 2010 gesammelt werden.

Jedem, der die Variante der Database Migration wählt, rate ich dringend dazu, einen “Probelauf” zu machen, bevor der neue SharePoint Server live geschaltet wird. Dies ermöglicht es, die neue Umgebung ausgiebig zu testen, ohne die Endbenutzer zu beeinträchtigen.

Vorbereitung

Als erstes sollte mit Hilfe des PreUpgradeChecks (stsadm Befehl ab MOSS SP 2) überprüft werden, ob es mögliche Konflikte innerhalb der Farm gibt. Der PreUpgradeCheck nimmt keine Modifikationen an der bestehenden Umgebung vor. Aufkommende Konflikte sollten gelöst werden, bevor mit der Migration begonnen wird.

Läuft der PreUpgradeCheck ohne Probleme durch, so kann die zweite Farm aufgesetzt werden. In dieser müssen alle Anpassungen (eigene oder Third Party Features, Solutions, Webparts, Themes etc.) installiert werden, welche derzeit noch von der alten Farm verwendet werden. Alle diese Anpassungen müssen 64Bit fähig sein!

Wer längere Zeit SharePoint 2007 administriert und konfiguriert hat, der wird während der Konfiguration von SharePoint 2010 vieles wiedererkennen. Sofort ins Auge springt die Unterstützung durch einen zweiten Wizard in der Central Administration und die Service Applications. In meinen Augen sollte grade den Service Applikationen der Office Web Apps und der sogenannten “User Profile Service Application” besonders viel Aufmerksamkeit geschenkt werden.
Die “User Profile Service Application” ersetzt den Teil des Shared Service Providers, welcher früher für die Benutzerprofile und MySites zuständig war.

Die Installation und Grundkonfiguration von SharePoint 2010 unterscheidet sich nicht sonderlich von der des SharePoint 2007. Interessant wird dies erst bei der Konfiguration der Service Applications. Allerdings nimmt hier der neue Configuration Wizard in der Central Administration auch eine Menge Arbeit ab.

Language Packs

Alle Language Packs, welche im bisherigen SharePoint 2007 im Einsatz waren, müssen auch auf dem neuen SharePoint 2010 Server installiert werden.
Liegt z.B. eine Site in einer Sprache vor, für welche kein Language Pack installiert wurde, so lässt sich diese Site ohne das entsprechende Language Pack nicht öffnen!

Steht die neue Farm, so kann ein erster Probelauf durchgeführt werden. Bei diesem “Probelauf” wird die neue SharePoint 2010 Farm bereits vollständig konfiguriert und eingerichtet. All diese Einstellungen müssen bei der Übernahme der endgültigen Content Datenbank nicht erneut vorgenommen werden, diese bleiben erhalten.

Datenbank Migration

Als erstes müssen die alten Inhaltsdatenbanken auf dem neuen SQL Server wiederhergestellt werden. Dies kann einfach mit Hilfe der Backup und Restore Funktionalität des SQL Servers erfolgen.

Über die Central Administration muss zunächst eine neue Web Applikation erstellt werden, in welcher später das Portal liegen soll. Bei der Erstellung der neuen Web Applikation wird auch eine neue Content Datenbank angelegt. Diese kann später wieder gelöscht werden.

Zur Sicherheit sollte an dieser Stelle noch der PowerShell Befehl “Test-SPContentDatabase” ausgeführt werden, um sicher zu stellen, dass auch tatsächlich alle erforderlichen Komponenten installiert wurden:

Test-SPContentDatabase -Name <alte Content Datenbank> -WebApplication <URL zur neu angelegten Webapplikation>

Ist auch dieser Test erfolgreich, so kann der neuen Applikation die “alte” Content Datenbank zugewiesen werden.
Wer bereits Erfahrungen mit dem Anfügen von Content Datenbanken hat, dem werden die folgenden Schritte bekannt vorkommen.

1. In der SharePoint Central Administration in den Bereich Application Management wechseln
2. Die Seite “Manage content databases” aufrufen

   

3. Nicht vergessen die neu erstellte Applikation auszuwählen

   

4. Die alte Content Datenbank entfernen

   

5. Mit Hilfe des stsadm Befehls “addContentDB” oder über die PowerShell mit “Mount-SPContentDatabase”  die neue Content Datenbank anfügen. Mit diesen Befehlen wird die Datenbank automatisch migriert. In unserer Umgebung hat die Migration einer Content Datenbank mit ca. 3,5 GB knapp 15 Minuten gedauert.
6. Überprüfen des Upgrade Status in der Central Administration:
   Central Administration –> Upgrade and Migration –> Check upgrade Status

Das ist bereits alles. Natürlich muss dieses Vorgehen für alle Content Datenbanken wiederholt werden. Sollen auch die MySites migriert werden, so muss auch der Shared Service Provider migriert werden.

Sowohl bei dem stsadm Befehl “addContentDB”, als auch beim äquivalenten PowerShell Befehl “Mount-SPContentDatabase” besteht die Möglichkeit zu wählen, ob der Content noch im alten SharePoint 2007 Style, oder direkt im neuen SharePoint 2010 Layout inklusive Ribbons angezeigt werden soll. Setzt man das Flag nicht, so wird standardmäßig das alte Layout beibehalten. Dieses kann später über das Visual Upgrade manuell geändert werden.

Reporting Services (Integrierter Modus)

Waren Reporting Services Reports vorhanden, so müssen diese neu bereitgestellt werden.

Funktionstest

Nachdem die alte Content Datenbank der neuen Applikation zugewiesen wurde, sollte das Portal aufgerufen und getestet werden. Die folgenden Punkte sollten überprüft werden:

1. Lassen sich alle Seiten öffnen?
2. Funktionieren alle Webparts?
3. Wurde das alte Layout fehlerfrei übernommen? / Wird die neue Ribbon Oberfläche angezeigt?
4. (optional) Funktionieren Reports (sowohl Reporting Services, wie auch Excel Services)?
5. (optional) Können die neuen Office Web Apps genutzt werden?
6. (optional) Funktionieren die MySites?
7. (optional) Funktioniert die Suche?

Des Weiteren sollte nun sowohl das Windows Event Log, wie auch die SharePoint Logs nach Fehlern überprüft und eine Weile beobachtet werden.

Abschluss

Waren alle Tests erfolgreich, kann die endgültige Migration durchgeführt werden:

1. die alte SharePoint 2007 Farm offline nehmen
2. ggf. erneut ein Backup der alten Content Datenbank erstellen und diese der neuen Webapplikation hinzufügen. Die Konfigurationen innerhalb der Service Applications müssen nicht neu gesetzt werden. Das Anfügen der alten Content Datenbank hat ausschließlich Auswirkungen auf die Web Applikation, zu welcher die Datenbank gehört.
3. Den neuen SharePoint Server 2010 live schalten

Fazit

Die Database Migration ist für einen erfahrenen SharePoint Administrator kein Problem. Die meiste Arbeit mach das Installieren und Konfigurieren der neuen Umgebung. Die eigentliche Migration ist im Gegensatz hierzu schnell gemacht und mit wenig Aufwand verbunden.
Desweiteren bietet Sie die optimalen Voraussetzungen für eine (zumindest für den Benutzer) sehr schnelle und unkomplizierte Umstellung. Die Database Migration ist mein absoluter Favorit und eigentlich für alle empfehlenswert, die eine schnelle, sichere und saubere Lösung bevorzugen.

SQL Server 2005 | SQL Server 2008 | SQL Server 2008 R2

Within BIDS, our development environment for SSAS applications, the Cube Wizard does a great job. With the wizard you get all the dimensions, the cube and the proper links between the cube and the dimensions. It even takes care of role playing dimensions and names them accordingly. But although it does a great job, the created cube is not ready for the end users. Recently I saw some cubes being just in the state where the wizard left them. So today’s post is about the most essential steps to perform after the cube wizard has finished creating the cube. I don’t go into too much detail here. Some of the topics have been addressed in other posts. Maybe I’m writing about other topics in upcoming posts. So the following list is more like a check list to verify your development.

1. Make the cube user friendly / do not use technical names

While the operational databases belong to a technical area, the OLAP solution has to be clear and easy to understand for the end users. Avoid technical names, use abbreviations only if they are commonly known and well documented and don’t prefix dimensions with ‘Dim’ or ‘D_’ or something like that (same with the fact-tables). The user wants to analyze sales by time not FactSales by DimTime.

2. Check all dimensions for their attributes

The cube wizard cannot know which attributes are important for a dimension. Check each attribute carefully. Delete attributes that are not needed at all. It does not make much sense to develop for future requirements. This only makes the cube harder to understand for the end users. Also, think about the usage of the attributes. For example, having an attribute “OptIn” for a CRM cube with members yes and no may not be ideal for usage in a pivot table as you would only see yes or no on the column/row. It is better to have “With OptIn” and “Without OptIn” as members because here, the meaning is immediately clear. Of course, numeric flags like gender being 0 or 1 also do not make much sense. Members should be clear and readable.

3. Create appropriate attribute relationships and create meaningful hierarchies

Attribute relationship-settings and hierarchies are the key to build a robust OLAP solution that enables query developers to write good MDX queries and also results in a better performance of the cube. However, attribute relationships can be tricky, so make sure you fully understand this topic. You should also use tools like BIDSHelper’s dimension health check to make sure that your attribute relationship really matches the source data.
For further explanation see http://ms-olap.blogspot.com/2008/10/attribute-relationship-example.html or http://ms-olap.blogspot.com/2008/11/turning-non-natural-hierarchy-into.html

4. Provide properties as needed (not every attribute of your dimension is needed as an attribute hierarchy!)

Define only those fields of your dimension table as attributes that you need either for hierarchies or as a filter or for pivot axis. Fields that are just informational (like telephone number of the employee for example) don’t make much sense as attribute hierarchies. Set the property “AttributeHierarchyEnabled” to false for these attributes. They are then shown grayed-out in the dimension designer. However, you can still use them in your OLAP tool, for example in Excel. It is important to understand how your attribute relationships are defined here.

5. Set the format for measures and calculations

The standard format for numbers is just a simple number format. This usually looks ugly in the cube browser or other frontend tools. It’s not a big deal to set the format for every measure. For example, you could use “#,##0.00” for numbers to get a nicely formatted two digit number representation. You should also do this for calculated measures and cube calculations.
For further explanation see http://ms-olap.blogspot.com/2009/11/how-to-define-excel-compliant-format.html

6. Set the proper dimension type. Especially, define a time dimension

Setting the dimension type of your time dimension to “time” makes it much easier for your OLAP client (like Excel) to provide special time dependent filtering options. Also, if you’re planning to use semi-additive measures, the time dimension must be marked accordingly.
Furthermore you also need to qualify the type of the time dimension’s attributes (using Years, HalfYears, Quarters, Months and Date). This is necessary for MDX functions like YTD(…), MTD(…) and ParallelPeriod(…) and for the “Add Time Intelligence” wizard.

7. Define the default measure for the cube

The default measure is used, when no measure is on the axis or the slicer (where – expression) of the query. If not set, SSAS takes the first measure in the first measure group. This can easily change if new measures or measure groups are created in the cube. Queries that rely on the default measure (which is in turn not a good practice) will then result in a different result. That’s why it is important to set a default measure.

8. Define the default member for dimensions/attributes which are not aggregatable

Similar to the default measure for the cube, each dimension has a default member that is used, if the dimension is not explicitly present in the query. For example, think of a dimension ‘Scenario’ with members like Actual, Forecast, Midterm plan etc. It does not make sense to aggregate the different members so you will usually set the IsAggregatable property to false. In this case you don’t have an All-element and you should provide a default member (in our example it would usually be ‘Actual’). If not specified, the first member is used which could again lead to errors if new members are created or the member names change. Keep in mind, that there are three ways to specify the default member: in the dimension itself, in the cube script (also useful for role-playing dimensions with different names) and in the security role definition.

9. Create a drill-through action for every measure group and make this the default action

Using a drill-through action shows the detail data behind a given cell. However, the default drill-through method only shows the name information of the dimensions’ key attributes. Often enough we would see meaning less surrogate keys here which do not make sense for our end users. By defining a drill through action the developer can set the displayed attributes for each dimension making the result of the drill through query much more readable. In addition, making this action the default action also works well with clients like Microsoft Excel. Here, a double-click on a cell triggers the default action.

10. Properly deal with unrelated dimensions

By default, values on unrelated dimensions are shown as the All-member of the unrelated dimension. For example, in Adventure Works, measures from the Internet Sales measure group are not linked to a reseller (obviously). However, if you try to analyze internet sales by reseller (for example by reseller type) you will see the same value (the total of sales) for each reseller. This is confusing. The property to control this behavior is the IgnoreUnrelatedDimensions setting in the measure group properties. When setting this to ‘false’ values for unrelated dimensions are not shown anymore. This is much easier to understand for the end users.
For further explanation see http://ms-olap.blogspot.com/2010/04/properly-showing-values-for-unrelated.html

Whats’ next?

So that’s all? Of course not. First, all the tips from above do not prevent a bad architecture or cube structure. A good architecture is important for each Business Intelligence solution and there are many good books (for example Kimball’s “The Data Warehouse Toolkit”) out there about setting up such an infrastructure. In general, building an SSAS solution on top of a well made dimensional model instead of some OLTP systems is a good idea.

And of course, the tips from above are not complete in any sense. If you asked someone else, you may get different tips. For example, it’s also important to set up the cube security or to define some time intelligence for easier analysis (like YTD-computations or year-over-year growth etc.). It is also a good practice to simplify complex cubes with many measure groups and dimensions using perspectives to make them easier to understand by the end user. And as many measures/calculations are not self-explaining just from their name, it is a good idea to link an html-document with a specification or helpful text with the member. You can use a cube action for this.

However, I guess you all have many more good ideas with best practices and most important tips. If you like, I would be very happy if you could share these tips with me and – who knows – maybe there will be a post like “25 tips for every SSAS developer” in the near future.

By the way, this is the second anniversary of my OLAP blog. It was quite an interesting time so far and I’m looking forward to more topics to write about. The main location of this blog is http://ms-olap.blogspot.com. The posts are mirrored to http://oraylis-olap.spaces.live.com/ and also reposted to the new blog system of ORAYLIS at http://blog.oraylis.de (here you can find more interesting posts about Sharepoint, Business Intelligence in general and much more). My posts are also readable by using some blog aggregators like http://www.ssas-info.com/ which I really recommend to learn more about SSAS, MDX and OLAP.

Viele Unternehmen haben bereits den Microsoft Office SharePoint Server 2007 im Einsatz und stehen nun vor der Aufgabe, diesen nach Microsoft SharePoint Server 2010 zu migrieren. In diesem Beitrag werden die verschiedenen Upgrade Mechanismen vorgestellt und einige allgemeine Hinweise zum Upgrade gegeben.

Wer mit der Migration von SharePoint 2003 auf 2007 schon Erfahrung hat, dem wird es vermutlich vor dem Upgrade auf 2010 grausen. Allerdings kann ich hier bereits sagen, dass Microsoft sich sehr große Mühe gegeben hat und wirklich gute Upgrade Mechanismen entwickelt hat.

Hinweis: Eine Migration von SharePoint 2003 auf 2010 ist nicht möglich. Hier muss zuvor ein Upgrade auf 2007 erfolgen.

Vor dem eigentlichen Upgrade

Wichtig für alle Upgrade Varianten ist, dass die Systemvoraussetzungen für SharePoint 2010 erfüllt sind und dass die bisherige MOSS Installation über das Service Pack 2 verfügt.
Desweiteren sollte man mit Hilfe des “Pre-Upgrade-Checks” überprüfen, welche “Problembereiche” in der aktuellen Farm existieren.

Der PreUpgradeCheck ist ab MOSS SP2 ein Befehl des Administrationstools stsadm:

stsadm –o preupgradecheck

Nachdem dieser Befehl durchgelaufen ist wird eine übersichtliche Website angezeigt, welcher man die Ergebnisse des Checks und eventuelle Probleme (inkl. Lösungsvorschlag!) entnehmen kann.

Werden eigene (oder eingekaufte) Solutions/Features oder Webparts verwendet, so müssen auch diese 64-Bit fähig sein, oder entsprechend angepasst werden, bevor die Migration erfolgt.

Variante 1: In-Place Upgrade (Direktes Upgrade)

Das In-Place Upgrade ist wohl die “rabiateste” Methode. Hierbei wird der neue SharePoint 2010 über den bereits existierenden SharePoint 2007 installiert.
Wichtig bei diesem Vorgehen ist, dass auf allen beteiligten Servern die Systemvoraussetzungen bereits erfüllt sind. Sollte die bestehende Umgebung noch nicht auf 64-Bit implementiert sein, so muss vor dem Upgrade auf SharePoint 2010 eine Migration auf 64-Bit erfolgen (gleiches gilt natürlich auch für Windows Server 2008 und die SQL Server Komponenten).
Sind alle Voraussetzungen erfüllt, so sollte die Farm noch einmal mit dem “Pre-Upgrade-Check” überprüft werden.

Ist der “Pre-Upgrade-Check” erfolgreich durchgelaufen, so kann mit dem Upgrade begonnen werden.

Das Upgrade muss in einer bestimmten Reihenfolge erfolgen. (Zuerst auf dem Server, auf dem die Central Administration installiert ist. Konfigurationsassistenten nicht ausführen, bevor das Upgrade nicht auch auf allen Front-End-Webservern ausgeführt wurde!)

Da in SharePoint 2010 kein Shared Service Provider mehr existiert, wird dieser während des Upgrade Prozesses in einzelne Service Applikationen “zerlegt”. Somit werden auch diese Einstellungen übernommen. Die so angelegten Service Applications sollten jedoch genau auf die richtigen Einstellungen und ihre Funktion überprüft werden.

Nach dem Upgrade erscheint das neue Portal zunächst im alten SharePoint 2007 Layout. Dieses kann mit Hilfe des Visual Upgrades auf die neue Ribbon Oberfläche umgestellt werden. Sehr schön bei diesem Vorgehen ist auch die “Vorschau” Funktion. So kann die neue Oberfläche erst für Administratoren zur Verfügung gestellt werden und diese können dann entscheiden, wann das Upgrade auch an den Endanwender weitergegeben wird.

Für wen ist das In-Place Upgrade geeignet?
Meiner Meinung nach ist das In-Place Upgrade nur geeignet, wenn es sich um eine kleine Serverfarm handelt und wenn die bisherige Architektur übernommen werden soll. Es ist auf jeden Fall ratsam, sich für das In-Place Upgrade professionelle Hilfe zu holen, da dieses das Risiko birgt, die komplette Farm zu “verlieren”.

Variante 2: Database Migration (Upgrade mit Anfügen der Datenbanken)

Die Variante der Database Migration ist in meinen Augen die sanfteste und sicherste Variante, ist jedoch gleichzeitig auch ressourcenintensiv.

Bei der Database Migration wird neben der existierenden Farm eine neue Farm aufgebaut (daher ressourcenintensiv). Diese ist vollkommen unabhängig von der bisherigen SharePoint 2007 Farm. Auch hier gilt: erst alle Voraussetzungen erfüllen, bevor SharePoint 2010 installiert wird. Auch sollten vor dem Umzug der alten Inhaltsdatenbanken unbedingt alle eigenen Features/Solutions installiert werden. Wichtig ist hierbei z.B. auch das eigene Theme.
Steht der neue SharePoint, dann können die alten Inhaltsdatenbanken der neuen Farm hinzugefügt werden (entweder über die Power Shell, oder über den altbekannten stsadm Befehl “addcontentdb”)

Auch nach der Database Migration erscheint das neue Portal zunächst im alten Layout. Dies kann mit Hilfe des Visual Upgrades angepasst werden.

Für wen ist die Database Migration geeignet?
Die Database Migration ist vor allem für Umgebungen mit sehr vielen und sehr großen Datenbanken geeignet, da hierbei das Upgrade der Datenbanken parallel geschehen kann. Außerdem ist diese Variante auch für alle zu empfehlen, deren Endanwender so wenig wie möglich von der Migration beeinflusst werden sollen. Während man beim In-Place Upgrade die Farm bis zur Vollendung des Upgrades offline nehmen muss, können bei der Database Migration beide Farmen parallel laufen, bis es zur eigentlichen Datenübernahme kommt.

Variante 3: Hybrid Variante

Die Hybrid Variante ist eine Kombination aus dem In-Place Upgrade und der Database Migration.

Die Hybrid Variante selbst teilt sich noch einmal in zwei unterschiedliche Methoden:

Methode 1:
Während des Upgrade Vorgangs wird weiterhin schreibgeschützter Zugriff auf die Inhaltsdatenbanken gewährt, während das Upgrade in einer anderen Farm ausgeführt wird.

Methode 2:
Die Möglichkeiten des In-Place Upgrades werden genutzt, um die Farm zu migrieren, jedoch werden die Datenbanken hierbei nicht migriert. Erst nach dem Upgrade werden die Datenbanken nach dem Verfahren der Database Migration getrennt, aktualisiert und wieder neu angefügt. Somit ist ein paralleles Upgrade der Datenbanken möglich.

Die Hybrid Variante vereinigt somit alle Vor- und Nachteile der In-Place und der Database Migration Variante.

Fazit

Egal für welche Methode man sich entscheidet, alle erfordern einiges an Planung, Vorbereitung und auch Nachbereitung (Beobachtung der Logfiles, evtl. Fehlerbehebung). Microsoft hat sehr viel Arbeit in die neuen Upgrade Mechanismen investiert, viel dokumentiert und vor allem viel Unterstützung geliefert. Dennoch sollte das Upgrade nur von erfahrenen SharePoint Administratoren durchgeführt werden, da es doch immer wieder kleine Stolperfallen gibt.

In meinem nächsten Post werde ich von den Erfahrungen berichten, die wir während des Upgrades auf SharePoint 2010 gemacht haben und etwas detaillierter auf die Variante der Database Migration eingehen.

SQL Server 2008 | SQL Server 2008 R2

In order to utilize map data in SQL Server the spatial data types and the spatial functions of the SQL Server are important. In my last post I “aggregated” detailed shapes up to a surrounding shape by using the built-in STUnion() function.

For the current post I’m using the detailed data for the German PLZ regions from my last post together with Craig Dunn’s function for aggregating shapes. The installation of these aggregate functions is pretty straight forward. After compiling the library from the source code you have to register the new aggregate in your SQL Server database. You will find all the needed information in his post.

Using this library, the aggregation of the shape becomes pretty easy. For example. The full aggregation for postal code region 42 now looks like this:

Not aggregated	Aggregated
select geom from dbo.post_pl where PLZ99 like ’42%’	select dbo.UnionAggregate(geom.MakeValid()) from dbo.post_pl where PLZ99 like ’42%’

This is much easier than the T-SQL function from my last post. I still recommend to persist the results for later use because the geo spatial operation may be more time consuming than “normal” queries.

However, there are two special topics to take care of:

1. Not all polygons may be correct (Open Geospatial Consortium type)
2. The shapes may not fit together perfectly

The first topic could result in errors when using the aggregation function above as well as the built-in T-SQL STUnion() function. This can be easily avoided using the MakeValid() function as shown in the example above. If you omit this function and remove the where-condition to get the aggregate of the full German map you will get a .Net error because of incorrect shapes.

For the second topic, take a closer look to the right picture from above. You will notice some lines within the shape. This effect becomes even more visible if we use the STBoundary() function to reduce the shape to its boundaries:

Without STBuffer()	With STBuffer()
select dbo.UnionAggregate(geom)    .STBoundary() from dbo.post_pl where PLZ99 like ’42%’	select dbo.UnionAggregate(geom)    .STBuffer(0.00001).STBoundary() from dbo.post_pl where PLZ99 like ’42%’

STBuffer() simply adds some buffer around the existing shape. This can be easily examined using the following T-SQL statement with its corresponding result:

DECLARE @s1 AS GEOMETRY = ‘POLYGON((0 0, 1 0, 1 1, 0 1, 0 0))’
DECLARE @s2 as GEOMETRY = ‘POLYGON((1.1 0, 2.1 0, 2.1 1, 1.1 1, 1.1 0))’
select @s1.STUnion(@s2).STBoundary()

As you can see, there is a small gap between the two squares. If you don’t want to look at the coordinates, you can query the distance by using the STDistance function, for example: select @s1.STDistance(@s2). The distance is actually 0.1 units.

If we now add the STBuffer function the result looks like this:

DECLARE @s1 AS GEOMETRY = ‘POLYGON((0 0, 1 0, 1 1, 0 1, 0 0))’
DECLARE @s2 as GEOMETRY = ‘POLYGON((1.1 0, 2.1 0, 2.1 1, 1.1 1, 1.1 0))’
select @s1.STUnion(@s2).STBuffer(0.1).STBoundary()

By actually extending the shape a little bit, the tiny gap in the middle of the shape disappears. This is why the map on the right side looks smoother than then one on the left side. You still need to be careful with the parameter for STBuffer. Higher parameters will result in a totally different shape. For example, if we use 4 as the parameter value in the example above, the shape looks like this:

Also higher values of STBuffer result in more time needed to compute the new shape. So in practice, you would try small values first or you could use the STDistance-function to compute the distance between the shapes.

As some people are surprised, the samples above are also fully functional with SQL Server 2008 because the spatial data type and functions have been introduced with SQL Server 2008. New in SQL Server 2008 R2 is the map support for Reporting Services, not the support for spatial data.

Nach der Entwicklung von Sql Server Integration Services (SSIS) Projekten, dem ETL Produkt von Microsoft, steht der Betrieb dieser Lösungen an. Wir haben bereits eine Vielzahl von Microsoft basierten BI Projekten realisiert. SSIS spielt dabei stets eine übergeordnete Rolle. In immer mehr Projekten übernehmen wir auch den Betrieb. So individuell die Projekte auch sein mögen, so ähnlich sind die Anforderungen des Betriebs.

Diese Beitragsreihe stellt die allgemeinen Anforderungen für den Betrieb von SSIS dar. In Folgebeiträgen gehe ich auf die Stärken und Schwächen des Produktes ein. Ferner gehe ich darauf ein, wie wir diese Anforderungen standardisiert in unseren Projekten lösen.

Was sind die allgemeinen Anforderungen?

Betrieb bedeutet einen Service bereitzustellen, nicht selten 24×7, der zuverlässig funktioniert. Im Falle von SSIS werden periodisch Jobs gestartet, die projektindividuell Daten von A nach B bewegen. Das geschieht in der Regel im verborgenen, d.h. die Prozesse und deren Ergebnisse sind von Hause aus “unsichtbar”. Die nachfolgenden Anforderungen treffen wir in allen Projekten wieder:

1. statusbasierte Ergebnisüberwachung
   • Welche Jobs müssen laufen?
   • Sind diese erfolgreich gelaufen? Gewünscht ist ein einfacher Soll Ist Vergleich, analog zu Performance Management, zum Beispiel anhand von roten oder grünen Ampeln
2. Laufzeit basierte Überwachung
   • aktuell aktive Jobs (Wie lange laufen sie schon? Wie lange werden sie vermutlich noch laufen?)
   • abgeschlossene Jobs (Wie lange läuft der Job gewöhnlich? Wie hat sich die Laufzeit in der letzten Zeit entwickelt? Wie ist der Trend? Wann wird ein kritisches Limit erreicht?)
3. KPI Überwachung
   • Welche Datenmengen befördert der Job? (aktuell und gewöhnlich)
   • Anzahl von Fehlern, Korrekturen oder sonstigen wichtigen Ereignissen?
4. Fehlererkennung und Lösung
   • Sind Fehler aufgetreten?
   • Wenn ja, wo? Die Praxis zeigt, dass Logging immer falsch ist. Für den Betrieb ist das Logging in der Regel unübersichtlich und überfrachtet. Die wichtigen Informationen müssen wie Rosinen herausgepickt werden. Expertentätigkeit. Für die Fehleranalyse ist es immer zu wenig. Das Optimum ist sehr schwer zu erreichen.
   • Wer ist der geeignete Ansprechpartner?
   • Trennung nach technischen Fehlern: In aller Regel auf Systemressourcenengpässe oder Security zurückzuführen, kann durch das BI Team oder die IT gelöst werden.
   • Und fachliche Fehler: Fehler liegt in aller Regel im Vorsystem (Datenquelle), kann nicht dauerhaft durch das BI Team gelöst werden, sondern fällt in die Zuständigkeit der Quellsysteme. Das ist einer der wesentlichen Beiträge der BI zur Verbesserung der primären Datenqualität! In der Regel wechselt hier die organisatorische Zuständigkeit. Nicht selten wird eine “andere Sprache gesprochen”.
5. Optimierung
   • Die Daten sind wichtig für die Erkennung des Optimierungsbedarfs. Wie so soft machen 20% des Codes 80% der Laufzeit aus. Deshalb ist eine längerfristige Bevorratung wichtig.
6. Performance
   • Trotz langer Bevorratung von Logging Informationen müssen alle Berichte innerhalb von 2 Sekunden zur Verfügung stehen
   • Alle Berichte müssen die Gegenwart zeigen, d.h. Bewirtschaftungszeiten werden nicht akzeptiert 
7. Nachrüstbarkeit
   • Ganz gleich in welcher Phase ein SSIS Projekt ist: Die hier genannten Anforderungen müssen leicht nachrüstbar sein. Besser noch. Bestehende Loggingdaten sollten in die neue Welt migriert werden können.

BI mit BI betreiben!

Nach Durchsicht der Anforderungen ist die Lösung recht naheliegend: Alle Betriebsanforderungen erfordern die Sammlung und Aufbereitung von Daten. Das ist die wesentliche BI Kernkompetenz!

Das ist das zentrale Ziel unserer Projekte: Ein standardisiertes Datenmodell mit standardisierten Berichten und einer standardisierten Vorgabe für die Entwicklung, um die hier darstellten Anforderungen zu erfüllen.

Damit erfüllen sich auch weitere, unausgesprochene Anforderungen:

1. Mit der Standardisierung kann eine BI Plattform kostengünstiger erstellt werden. Die Entwickler können sich zu 100% auf die Business Lösung konzentrieren und müssen sich nicht mit Fehlerhandling auseinandersetzen. Wir werden oft in Projekte gerufen, bei denen dieser Teil der Umsetzung eine signifikante Größe eingenommen hat und den Blick auf das wesentliche eintrübt.
2. Mit der Standardisierung kann eine BI Plattform kostengünstiger betrieben werden. Das Personal benötigt für den 1rst und 2nd Level Support keine tiefen Projektkenntnisse. Es bekommt effizient die Informationen, die es benötigt.
3. Consultants können zwischen den Projekten leichter wechseln

In den nächsten Beiträgen erläutere ich, was die Stärken und Schwächen des Produktes SSIS sind und was zur Erfüllung der Anforderungen erforderlich ist.