Vor Längerer Zeit habe ich diesen Beitrag im PTS Group Blog veröffentlicht. Passend zu meinem Vortrag morgen, möchte ich diesen Artikel nun auch in meinem Blog veröffentlichen.

In einem früheren Beitrag wurde im PTS Blog bereits über die Installation eines SharePoint 2010 Foundation Servers  berichtet. Wer sich für für einen SharePoint 2010 Enterprise Server entscheidet, tut dies meistens um einen oder mehrere der zahlreichen dort enthaltenen Dienste zu nutzen. Wird die Installation etwas größer und eine Trennung der Dienste erforderlich, kann dem Administrator bei der Konfiguration der Sicherheit doch schon mal schnell der Kopf rauchen, denn Kerberos hat es in sich.

Das Szenario

Im Folgenden beschreibe ich wie die Netzwerksicherheit mit Kerberos in einer Umgebung einzurichten ist, in der folgende Server und Dienste existieren:

Server 1: SQL Server
- Datenbankdienste mit SQL Server Agent
- Analysis Services mit SQL Server Browser Dienst

Server 2: SharePoint Server
- Reporting Services im SharePoint integrierten Modus
- SharePoint 2010 Server
- Performance Point Services aktiviert
- Excel Services aktiviert

Wird entweder der SharePoint Server oder der SQL Server - oder gar Beides – nicht richtig für die Verteilung konfiguriert, wird die Verbindung zwischen den Systemen nicht immer einwandfrei funktionieren. Im “normalen” SharePoint Alltag, d.h. dem Umgang mit Listen, Verwalten von Dateien, Listeneinträgen, etc. fällt dies zunächst nicht auf. Wird jedoch eine Datenquelle in Reporting Services angelegt und versucht auf den SQL Server zuzugreifen, erhält man diese Meldung:

rsErrorOpeningConnection: An existing connection was forcibly closed by the remote host.

Hat man im SharePoint sogar schon eine Webpart Seite angelegt und versucht dort den Bericht aufzurufen gibt es die gleiche Meldung, direkt von ASP.Net (links) oder anders von Performance Point (rechts).

Schuld daran sind jedoch nicht fehlende Berechtigungen des Benutzers auf die Datenbank, oder eine Fehlende Netzwerkverbindung, sondern die Authentifizierung im Netzwerk. Damit diese auch mitmacht muss Kerberos konfiguriert werden.

Über Kerberos

Kerberos ist ein Authentifizierungsprotokoll, dass es erlaubt sich im Windows-Netzwerk über mehrere Server hinweg an Diensten zu authentifizieren – und das auch noch vollkommen sicher. Damit dies korrekt funktioniert, muss Ordnung im Netzwerk herrschen, denn standardmäßig vertrauen sich Server nicht gegenseitig und verweigern die Kommunikation wenn es um Kerberos geht. Um dies zu ändern, muss im Active Directory für jeden Server und jedes Dienstkonto ein Secure Principal Name (SPN) hinterlegt werden, und dann wiederrum ist es möglich einzustellen wem dieser Dienst vertraut (bzw. an wen er Kerberos delegieren darf).

Das klingt ja erst mal gar nicht so schwer, oder?
In der Praxis steckt der Teufel bei Kerberos im Detail, denn der kleinste Fehler führt dazu, dass nichts funktioniert.
Ebenso führt die Verwendung von Kerberos eine Beschränkung ein: Je Hostname darf künftig nur noch ein Dienst verwendet werden. D.h. laufen auf Ihrem SharePoint Server z.B. Reporting Services im integrierten Modus und der SharePoint Dienst, erreicht der Nutzer beides über die Webadresse der SiteCollection. Wenn jetzt aber beide Dienste verschiedene Dienstkonten haben, müssten beide Dienstkonsten auf die Adresse der SiteCollection einen SPN haben – und das geht leider nicht.

Schauen wir uns einfach mal, wie Kerberos im oben genannten Szenario für Reporting Services konfiguriert werden muss

Kerberos Konfiguration: Datenbankserver

Als erstes müssen die Dienste für ihren SQL Server SPNs bekommen. Dazu müssen Sie wissen, unter welchem Dienstkonto die Dienste laufen. Unter welchem Benutzer die Dienste laufen verrät einem der SQL Server Configuration Manager, wie hier:

Wichtig: Für den Zugriff über Kerberos darf der SQL Server nicht unter dem lokalen Systemkonto oder dem Netzwerkdienst laufen. Es muss schon ein Active Directory Benutzerkonto sein.

Angenommen, sowohl der Datenbankdienst, als auch Analysis Services, laufen unter einem Dienstkonto mit dem Namen sqlsrv, können Sie wie folgt feststellen, ob das Dienstkonto bereits über SPNs verfügt:

• Über die Eingabe des folgenden Befehls in die Konsole:
  setspn –l DOMAIN\sqlsrv
• Aufrufen des in der Verwaltungskonsole für Benutzer und Computer und prüfen, ob das Tab Delegierung vorhanden ist
  

Ist alles bereits richtig konfiguriert, müssten folgende SPNs für dem Benutzer sqlsrv hinterlegt sein, unter der Annahme, dass der Server MeinSQLServer heißt und in der Domäne dev.local Mitglied ist:

MSSQLSvc/MeinSQLServer:1433
MSSQLSvc/MeinSQLServer.dev.local:1433
MSOLAPDisco.3/MeinSQLServer
MSOLAPSvc.3/MeinSQLServer.dev.local
MSOLAPSvc.3/MeinSQLServer
MSOLAPDisco.3/MeinSQLServer.dev.local
MSOLAPSvc.3/MeinSQLServer.dev.local:1433
MSOLAPSvc.3/MeinSQLServer:1433

Fehlen diese Werte, lassens ich diese über den Kommandozeilenbefehl SetSPN –U –A setzen, also:

setspn –U –a MSSQLSvc/MeinSQLServer:1433 DEV\sqlsrv
setspn –U –a MSSQLSvc/MeinSQLServer.domain.local:1433 DEV\sqlsrv
setspn –U –a MSOLAPDisco.3/MeinSQLServer DEV\sqlsrv
setspn –U –a MSOLAPSvc.3/MeinSQLServer.domain.local DEV\sqlsrv
setspn –U –a MSOLAPSvc.3/MeinSQLServer DEV\sqlsrv
setspn –U –a MSOLAPDisco.3/MeinSQLServer.domain.local DEV\sqlsrv
setspn –U –a MSOLAPSvc.3/MeinSQLServer.domain.local:1433 DEV\sqlsrv
setspn –U –a MSOLAPSvc.3/MeinSQLServer:1433 DEV\sqlsrv

Das wär es für den Datenbankserver. Gehen wir nun zum SharePoint Server über

Kerberos Konfiguration: SharePoint Server

Bevor wir, wie beim SQL Server, die SPNs registrieren, müssen eine ganze Reihe von Voraussetzungen im SharePoint und in Reporting Services geschaffen werden. Als erstes muss sichergestellt werden, dass die Anwendungspools und der Reportserver mit dem selben Dienstkonto betrieben werden. Da in unserem Szenario Reporting Services und SharePoint auf dem selben Server liegen, würde eine andere Konfiguration sonst zu doppelten, und somit widersprüchlichen, SPNs führen.

Den Benutzer des Reporting Services Dienstes erfahren Sie, wie oben, über den SQL Server Configuration Manager. Die Dienstkonten der SharePoint Dienste müssen Sie in der Zentraladministration unter folgendem Pfad überprüfen:
Central Administration > Security > Configure Service Accounts.
Stellen Sie hier sicher, dass die Dienste und die Web Applikation über das selbe Konto, wie Reporting Services verwenden.

Fehlt das Benutzerkonto, klicken Sie unten auf "Register new managed account”

Damit wäre eine der Voraussetzungen erfüllt, es geht jedoch noch weiter.

Claims to Windows Token Service

Für Reporting Services reicht die aktuelle Einstellung bereits aus. Excel Services und Performance Point Services brauchen zur Weitergabe von Kerberos Tokens allerdings auch den Claims to Windows Token Service (C2WTS). Dieser Dienst kann basierend vertrauenswürdigen Anfragen, Sicherheitstokens generieren – somit kann der Dienst für Operationen die Identität des Benutzers annehmen und mit seinen Berechtigungen arbeiten.
Damit es gelingt, muss dieser Dienst seinen Zielen, wo das Token hingeschickt wird, aber auch vertrauen können. Das wird mittels SPNs und Delegierungen festgelegt.

Stellen Sie als erstes sicher, dass dieser Dienst unter einem Domänenbenutzerkonto arbeitet. Dies kann auch über die SharePoint-Maske Configure Service Accounts (siehe oben) erledigt werden. Nun sind da jedoch ein paar Berechtigungen mehr, die dieser Benutzer erfordert. Diese lassen sich in der Verwaltung der Systemsteuerung über die Lokale Sicherheitsrichtlinie einstellen:

• Er muss Mitglied der lokalen Administratorengruppe sein
• Er muss in der Lokalen Sicherheitsrichtlinie folgende Rechte haben:
  • Einsetzen als Teil des Betriebssystems (Act as part of the operating system)
  • Als Dienst anmelden (Logon as a service)
  • Annehmen der Clientidentität nach Authentifizierung (Impersonate a client after authorization)
    

Soweit, so gut, jetzt sind die meisten Hürden geschafft und es kann an das Erstellen der SPNs und Delegierungen

SharePoint SPNs und Delegierungen

Angenommen, der Claims to Windows Token Service läuft unter einem Benutzer DEV\SPC2WTS, können wir folgenden SPN anlegen. Der Text SP/C2WTS kann beliebig sein, da auf den Dienst von außen nicht zugegriffen wird. Der SPN wird nur für die Delegierung benötigt.

SetSPN –U –A SP/C2WTS DEV\SPC2WTS

Nun die SPNs für das Konto des Anwendungspools:

SetSPN –U –A http/MeinSharePointServer DEV\SPXAPD
SetSPN –U –A http/intranet DEV\SPXAPD
SetSPN –U –A http/intranet.domain.local DEV\SPXAPD

Und jetzt kommt der wichtigste Teil, damit die Kerberos Tickets auch weitereicht werden dürfen: Die Delegierung.
Öffnen Sie dazu auf Ihrem Domänencontroller die Eigenschaften des Benutzers SPC2WTS, dort wird das Tab Delegierung angezeigt. Dort müssen “Benutzer bei Delegierungen angegebener Dienste vertrauen”, “Beliebiges Authentifizierungsprotokoll verwenden” aktiviert sein, dann können Sie auf “Hinzufügen…” klicken.
Es öffnet sich ein neues Fenster, dort gibt es den Button “Benutzer oder Computer”, dort suchen Sie jetzt nach ihrem SharePoint Anwendungspool Benutzer, wenn alles richtig gelaufen ist, erhalten sie dann folgende Anzeigen:

Nun vertrat der User DEV\SPC2WTS dem Benutzer DEV\SPAPD im Kontext des Protokolls http auf dem Server MeinSharePointServer. D.h. SPC2WTS delegiert Kerberos Tokens an http/MeinSharePointServer für den Benutzer SPAPD.
Das wiederholen Sie nun für den Datenbankserver.

Der Benutzer SPAPD muss nämlich das Token weiter delegieren können an den Dienst MSSQLSvc, MSSQLOlapDisco.3 und MSSQLOlapSvc.3 auf dem Datenbankserver.

Weitere Links und Literatur

Wenn Sie diese Einstellungen vorgenommen, sollten Sie Performance Point und Excel Services mit einer erfolgreichen Verbindung belohnen. Ist dies nicht der Fall, prüfen Sie noch die allgemeine Konfiguration dieser Dienste, dazu empfehle ich die folgende Literatur und Links:

Buch: SharePoint 2010 Performance Point Services unleashed
MSDN: Configure Performance Point Services
MSDN: Übersicht über den Claims to Windows Token Service

Bis SQL Server 2008 R2 war es üblich das Debuggen von .NET Code im SQL-Server sowie T-SQL-Abfragen mit der Premium Edition von Visual Studio durchzuführen. Wer versucht ein Datenbankprojekt in Visual Studio 2010 zu erstellen und es mit einer SQL Server 2012 Datenbank zu verbinden, erhält nur eine Fehlermeldung. Auch sucht man Datenbankprojekte in Visual Studio 2012 vergeblich, denn nun gibt es die SQL Server Data Tools, die übrigens auch für Visual Studio 2010 erhältlich sind.

Microsoft ist damit einen großen Schritt auf die SQL Server Entwicklergemeinde zugegangen, denn bisher war es immer erforderlich eine recht teure MSDN Premium Lizenz zu erwerben, wenn man die Datenbankprojekte nutzen wollte. Die SQL Server Datatools sind kostenfrei verfügbar und lassen sich auch mit der Visual Studio 2010 oder 2012 Shell benutzen, somit reicht es also aus eine Developer Edition des SQL Servers zu erwerben.
Es gibt nur einige Funktionen, die erst ab einer Professional Edition von Visual Studio verfügbar sind, wie das Unit Testen.

Nach der Installation steht einem auch in Visual Studio 2012 im Bereich SQL-Server wieder ein Datenbankprojekt zur Verfügung! Es wird bei den Projekten nun auch nicht mehr unterschieden, ob es sich um ein SQL Server Projekt für .NET Assemblies oder um ein Datenbankprojekt für Datenbankobjekte handelt. Nun findet sich beides im Datenbankprojekt!

Erstellen einer Assembly

Ein Datenbankprojekt wird um eine Assembly ergänzt sobald ein .NET Element dem Projekt hinzugefügt wird. Diese Objekte befinden sich beim Hinzufügen eines neuen Objektes im Abschnitt SQL CLR C#.

Um nun eine Assembly in einem Datenbankprojekt zu erzeugen muss nach dem Hinzufügen eines Elementes das Projekt kompiliert werden. Nehmen wir zum Beispiel die gute alte Hello World-Funktion:

Debuggen des Codes

Um .NET Code im SQL Server debuggen zu können ist es nicht länger erforderlich sich an den Prozess einer laufendenden Instanz anzuhängen. Alles was man braucht ist ein Skript, das nicht in den Build-Prozess integriert ist (siehe unten).

Mit diesem Skript lassen sich beliebige Abfragen ausführen und dann auch Debuggen. Doch wogegen wird denn ausgeführt, wenn es nicht ein laufender Prozess einer SQL Server Instanz ist? Die Data Tools bringen eine SQL Server 2012 LocalDB Instanz mit, diese wird zur Laufzeit instanziiert, wenn im Menü Debuggen der Menüpunkt Starten ausgewählt wird. Das erste Kompilieren kann je nach Geschwindigkeit des verwendeten Gerätes und Komplexität des Datenmodells durchaus einige Zeit dauern. Ist das Erstellen fertig gestellt, haben die Data Tools eine DACPAC Datei ausgegeben, deren Pfad in der Ausgabe zu sehen ist. In dem gleichen Pfad befindet sich dann auch die Assembly, hier im Beispiel Database1.dll.

Um nun ein Skript zu Debuggen bietet es sich an ein Skript zu öffnen, das außerhalb des Builds liegt, um es dann mit dem Debugger auszuführen, mit der Maus íst dabei neben dem Start-Knopf ein kleiner Pfeil zu betätigen um das Kontextmenü zu öffnen, alternativ tut es aber auch die Tastenkombination ALT+F5:

Mit dem Debugger lässt sich nun ein Einzelschritt (F11) durchführen, sodass der Cursor zu unserer Hello-World-Funktion springt. Hier ist es nun möglich, wie es findige C#-Entwickler von Visual Studio gewohnt sind, Variablenwerte einzusehen und das Ablaufen des Codes genauestens nachzuvollziehen. Und nun wünsche ich viel Spaß beim Debuggen :-)

Weiterführende Literatur und Links

Kapitel 4 des Buches Microsoft SQL Server 2012 - Überblick über Konfiguration, Administration, Programmierung.
Video2Brain Training zu Neues in SQL Server 2012
SQL Server Data Tools (SSDT) für Visual Studio 2010
SQL Server Data Tools (SSDT) für Visual Studio 2012

Original Blogpost im PTSGroup BI Blog und der Ceteris AG

Seit dem SQL Server 2008 R2 liefert Microsoft in der Enterprise Edition des SQL Servers ein oft unbekanntes, aber mächtiges Tool mit: Die Master Data Services, kurz MDS!

In der aktuellen Version, dem SQL Server 2012, hat Microsoft die Oberfläche gepimpt und auf Silverlight-Basis mit einer deutlich erhöhten Bedienbarkeit ausgestattet. Silverlight ist in diesem Fall ein Segen, aber wie so oft auch ein Fluch. Da Silverlight keine direkte Konnektivität zu einer Datenbank mitbringt müssen sämtliche Zugriffe über Webdienste gekapselt werden, und wenn dort etwas schief geht steckt der Teufel oft im Detail.

Wer versucht Master Data Services unter Windows 8 bzw. Windows Server 2012 zu verwenden kann genau in diese Falle laufen und bekommt nur eine Meldung mit dem wenig hilfreichen Hinweis HttpWebRequest_WebException_RemoteServer Argumente: NotFound angezeigt (siehe folgende Abbildung).

Wenn man Fiddler2 versucht etwas über diesen Fehler in Erfahrung zu bringen zeigt sich tatsächlich ein HTTP 404 Fehler – ein Blick das MDS Verzeichnis verrät aber, dass der Webservice vorhanden ist.

Die Lösung zu dem Problem ist ein kleines Häkchen, in den Windows-Features (ehemals Windows-Funktionen unter Windows 7, zu erreichen in der Systemsteuerung über Programme und Funktionen) befindet sich im .Net Framework 4.5 Advanced Services im Bereich WCF-Dienste ein kleines Häkchen mit dem Namen “HTTP-Aktivierung”.

Bei der Installation von Master Data Services wird dies leider nicht geprüft, so wird man zwar darauf hingewiesen wenn das .Net Framework gänzlich fehlt, aber der Hinweis, dass hier noch eine zusätzliche Funktion von Nöten ist fehlt zumindest im Installer.

Nun ja, wenn man es weiß ist es schnell gemacht und schwupps läuft auch die Weboberfläche.

Und nun wünsche ich viel Freude beim Aufbauen des Stammdatenmodells.

Dieser Artikel ist auch verfügbar im PTSGroup BI Blog: http://biblog.ptsgroup.de/allgemein/stolpersteine-bei-der-installation-von-master-data-services/ 

Kommende Woche findet ein Treffen des PASS Deutschland e.V. in Bremen statt.
Dort werde ich einen Abriss über die neuen Funktionen in SQL Server Denali geben und die CTP3 auch vorführen.

Alle Interessierten sind herzlich eingeladen.

Stattfinden wird das Treffen am 14.09. von 18 bis ca. 21 Uhr in der Linzer Straße 4 in Bremen bei der PTS Group AG.
Die Räumlichkeiten befinden in der Nähe der Universität.

Ich freue mich auf euer Erscheinen.

PHP unter Windows war schon immer eine Odysse. Inzwischen ist es zwar sehr einfach möglich PHP direkt zu installieren, ja sogar die FastCGI Konfiguration im IIS klappt automatisch, doch sobald man auf die Idee kommt sich mit dem SQL Server verbinden zu wollen, wird es spannend.

Seit PHP 5.2.0 ist der Treiber für den SQL-Server standardmäßig nicht mehr bei PHP mitgeliefert, da es seitdem einen Treiber von Microsoft gibt, für den sogar offiziel Support geleistet wird und ja sogar in Open Source. Mittlerweile ist der Treiber in der Version 2.0 erhältlich und liefert eine Vielzahl von DLL-Dateien mit, welche für die verschiedenen PHP-Versionen gedacht sind (Version, Compiler, Threadsicherheit).
Hat man den richtigen Treiber in das ext-Verzeichnis kopiert und in der php.ini eingetragen zeigt sich der Treiber in phpinfo() unter dem unscheinbaren Namen sqlsrv.
Die Suche nach dem richtigen Treiber kann man sich ersparen, indem PHP sowie den Treiber über den Web Platform installer installiert werden.

Doch beim Testen meldet PHP erst mal nichts, dafür muss das Error Reporting in der php.ini aktiviert werden. Dies geschieht indem display_errors = On gesetzt wird.
Dann erscheint die Meldung "Call to undefined function mssql_connect()".
Hier steckt der Teufel im Detail, denn die in der PHP-Dokumentation erwähnten Befehle sind für den alten PHP-eigenen Treiber gedacht. Microsoft lässt einen zum Glück nicht im Stich und stellt in der MSDN eine API-Referenz bereit: http://msdn.microsoft.com/library/cc296152(v=SQL.90).aspx
Der Wehrmutstropfen dabei ist, dass nicht nur die Befehle anders heißen, als bisher, sondern obendrein auch noch die Parameter geändert wurden. Das bedeutet also viel Spaß beim Anpassen bereits existierender Software.

Dies weckt alte Erinnerungen an die Umstellung von PHP 3 auf PHP 4, als die Servervariablen alle nun unter einem Array erreichbar waren und alle Anwendungen angepasst werden mussten, was wirklich ärgerlich war.
Aber immerhin: Es funktioniert!

Dieser Artikel ist auch im PTS BI Blog veröffentlicht: http://biblog.ptsgroup.de/sql-server/sql-server-treiber-fur-php-unter-windows-richtig-verwenden/

Vor zwei Wochen hat Microsoft die erste CTP-Version des neuen SQL Servers, der unter dem Coenamen Denali entwickelt wird, veröffentlicht. Die Version wird derzeit auch als SQL Server 2011 gehandelt, zum offiziellen Releasedatum gibt es bisher aber keine genauen Angaben.

Management Studio

Die ersten Unterschiede zum SQL Server 2008 R2 fallen bereits bei  der Installation auf, so wird neben Visual Studio 2008 auch Visual Studio 2010 mitinstalliert. VS 2010 wird allerdings bisher nur für das Management Studio benötigt, welches sich in einem neuen WPF-Kleid präsentiert.

Bereits beim Start wird auf den neuen Motor hingewiesen:

Während der Arbeit mit dem neuen Management Studio zeigt sich das gewohnte Verhalten von Visual Studio 2010. Eine neue Optik, angenehmere Schriften, verbessertes Intellisense.

Auffällig ist, dass das Management Studio bei der Verbindung mit der Datenbankinstanz nun auch einen Ordner für die Integration Services zeigt. Ein Klick mit der Rechten Maustaste verrät, dass es möglich ist einen Katalog für SSIS Pakete zu erstellen.
Um einen solchen Katalog erstellen zu können, ist es allerdings notwendig den .Net CLR im SQL Server zu aktivieren. Dies lässt sich mit folgenden T-SQL-Statements schnell bewerkstelligen:

sp_configure 'show advanced options', 1;
GO
RECONFIGURE;
GO
sp_configure 'clr enabled', 1;
GO
RECONFIGURE;
GO

Nun ist es möglich mit einem Assistenten im Ordner Integration Services einen Katalog zu erstellen, welcher offensichtlich das bisherigen Deployment in die msdb ablösen wird. Im SSIS Katalog können Unterordner erstellt werden, welche wiederrum Projekte und Umgebungsparameter beinhalten. Damit räumt Microsoft auf und ermöglicht es mehrere SSIS Projekte auf einem Server abzulegen und sauber zu trennen. Damit hält auch die Möglichkeit Einzug direkt in Visual Studio ein Deployment vorzunehmen, sodass der bisherige Umweg über das Management-Studio bzw. die Deployment-Datei entfällt.

Integration Services

Beim Entwickeln eines SSIS Paketes fällt sofort der neue Designer in Visual Studio auf. Neben der neuen Optik und der Möglichkeit die Ansicht zu vergrößern bzw. zu verkleinern wurden die Tasks neu geordnet. Die Kategorien sind jetzt nicht mehr nach Tasktypen sondern nach der Häufigkeit der Benutzung angelegt worden.

Auf der Ebene des Datenflusstasks enthält die Favoritenkategorie nun zwei Assistenten für Datenquellen und Ziele, die es komfortabler, als  bisher, erlauben diese Objekte anzulegen.

Neu im SQL Server Denali sind auch die Dependency Services, welche Data Lineage für SSIS ermöglichen. Um dort einen Einblick zu erhalten müssen diese erst per Kommandozeile aktiviert werden, eine Anleitung gibt es in der MSDN. Nach der Einrichtung ist es möglich einen Extraktion Point zu erstellen, um dann die Metadaten aus den SSIS Paketen auszulesen.

Einen Ausblick auf kommende Features zeigt die “Data Correction” Komponente, welche einen Auffordert eine Datenbank auszuwählen, welche für Data Quality Services eingerichtet wurde. Microsoft hat 2008 die Data Quality Services von Zoomix akquiriert und wird diese in Denali nun weiter entwickeln. Diese Funktionalität ist im aktuellen CTP noch nicht implementiert und gibt einen Ausblick auf kommende Funktionen zur Datenqualitätssicherung im SQL Server.  Danach lässt sich mit einem grafischen Designer leicht nach Verfolgen, welche Tabellen und Spalten in welchem Paket wohin verarbeitet werden.

Reporting Services und Analysis Services

In SSRS und SSAS sind noch keine Änderungen im CTP1 enthalten, jedoch sind interessante Neuerungen angekündigt.

Analysis Services soll mit der aus PowerPivot bekannten VertiPaq-Engine ein verbessertes MOLAP erhalten. Sehr spannend wird auch das für Reporting Services laufende Project Crescent, in dem eine neue Silverlight-Oberfläche entwickelt wird, die neue Möglichkeiten eröffnet, wie dynamische Zeitverlaufsdiagramme. Dazu empfiehlt sich ein Präsentationsvideo auf YouTube.

Denali bringt bereits jetzt einige sinnvolle Neuerungen, gespannt Blicken wir nun auf die CTP2 in der die angekündigten Funktionen wahrscheinlich das erste Mal der Öffentlichkeit zur Verfügung stehen werden.

Dieser Post wurde auch im PTS Business Intelligence Blog veröffentlicht

Demnächst geht bei der PTSGroup ein Blog über Business Intelligence an den Start, auf dem ich als Autor mit Tätig sein werde.

Die Artikel werden von hier aus auch verlinkt.

Als kleinen Vorgeschmack: Es wird neben Inhalten aus unseren Projekten auch um die spezielle BI Themen im SQL Server gehen, die unter anderem auch in diesen Büchern behandelt werden:

Gansor, Totok & Stock: Von der Strategie zum Business Intelligence Competency Center (BICC): Konzeption - Betrieb - Praxis

MacLennan, Tang & Crivat: Data Mining with Microsoft SQL Server 2008