Freitag, 20. August 2010

SSRS: My Reports Ordner fehlt

Laut Dokumentation gibt es die Möglichkeit, berechtigten Anwendern den Ordner "My Reports" zur Verfügung zu stellen. Dort haben sie dann die erforderliche Berechtigung, um nach Herzenslust eigene Berichte zu erstellen. Jeder Benutzer sieht seinen eigenen Ordner "My Reports", so dass der Datenschutz gewährleistet ist.
Das Problem ist nur: Es reicht nicht, einer Gruppe von Benutzern die Berechtigung hierfür zu erteilen, so wie nachfolgend dargestellt.

Bevor Ihre Anwender tatsächlich das erste Mal auf "My Reports" zugreifen können, müssen Sie als Administrator einmalig eine Einstellung vornehmen, die sehr gut versteckt ist:
Öffnen Sie mit SQL Server Management Studio eine Verbindung zu der richtigen SSRS Instanz. Achten Sie beim Herstellen der Verbindung darauf, dass Sie als Servertyp "Reporting Services" wählen, wie im Bild dargestellt.
Jetzt können Sie im Object Explorer mit der rechten Maustaste auf die SSRS-Instanz klicken und im Kontextmenü den Punkt "Properties" (Eigenschaften) auswählen. Das folgende Fenster öffnet sich:
Sehen Sie die unscheinbare Option "Enable a My Reports folder for each user"? Wenn Sie diesen Haken setzen und mit OK bestätigen, dann ist das Wunder vollbracht und die berechtigten Anwender sehen im Report Manger ihren My Reports Ordner!

Eigentlich ganz einfach, wenn man es weiß. Ob es in der nächsten Version von Report Manager vielleicht auch die Möglichkeit geben wird, das über die Web Anwendung einzustellen?

Donnerstag, 19. August 2010

Maps in SSRS - mehr als nur Landkarten

Die spektakulärste neue Data Region in Reporting Services 2008 R2 ist sicher die Landkarte ("Map"). Damit lassen sich zum Beispiel die Vertriebsstandorte in einer Landkarte darstellen und zu den Standorten zum Beispiel die Umsätze mit Symbolen wie Kreisen unterschiedlicher Größe und Farbe. Das ist schon ziemlich gut.
Hinter einer Landkarte steckt immer eine Beschreibung der Koordinaten mit Hilfe sphärischer Daten, also der Position auf der gerundeten Erdoberfläche.
Was mir bisher nicht so klar war, womit sich aber noch einmal ganz neue Einsatzgebiete für SSRS erschließen lassen: Genauso gut können Sie mit geometrischen Daten, also mit Koordinaten in einer Ebene, arbeiten.
Zum Beispiel beschreibt Hilmar Buchta hier die Erstellung von Shape-Dateien mit Visio. Auf diese Weise hat er einen Bericht erstellt, der die Verweildauer von Autos auf einzelnen Parkplätzen in einem Parkhaus mit Farben darstellt.
Sehr gut gefällt mir auch der Heatmap von Teo Lachev. Hier werden den Umsatzzahlen der einzelnen Geschäfte entsprechende Rechtecke zugewiesen.
Da bieten sich viele neue Möglichkeiten der Darstellung!

Deutsche Landkarten in SSRS anzeigen

Mit SQL Server 2008 R2 und Report Builder 3.0 ist es ja möglich, ortsbezogene Daten in Berichten darzustellen. Allerdings stellt Microsoft lediglich Karten der US-amerikanischen Bundesstaaten zur Verfügung.
Um in Deutschland lokalisierte Daten in einer Karte darzustellen, benötigt man ESRI-Shapefiles der deutschen Bundesländer. Wo man diese (kostenpflichtig und teilweise auch kostenfrei) bekommen kann, hat Tillmann Eitelberg in seinem sehr informativen Artikel dargestellt.

Freitag, 13. August 2010

SQL Server auf Windows Server 2008: Wie öffne ich die Firewall?

Bei der Installation von SQL Server 2008 (R2) auf einem der aktuellen Betriebssyteme gibt es diese Warnung:

Clients, die von anderen Rechnern aus versuchen, sich am SQL Server anzumelden, erhalten später folgende Meldung:
Netzwerkbezogener oder instanzspezifischer Fehler beim Herstellen einer Verbindung mit SQL Server. Der Server wurde nicht gefunden, oder auf ihn kann nicht zugegriffen werden. Überprüfen Sie, ob der Instanzname richtig ist und ob SQL Server Remoteverbindungen zulässt. (provider: Named Pipes-Provider, error: 40 - Verbindung mit SQL Server konnte nicht geöffnet werden)

Der Grund ist, dass die Firewall-Funktion von Windows die Maschine gegen die Außenwelt abschottet und nur solche Verbindungen durchlässt, die Sie in der Firewall freigeben. Es handelt sich also um eine ganz wichtige Sicherheitsfunktionalität. Daher erliegen Sie bitte nicht der Versuchung, einfach die ganze Windows Firewall zu deaktivieren – danach funktioniert zwar der Zugriff auf den SQL Server, aber Ihr Windows Server stünde dann "nackt" im Netz...

Die Funktionsweise der Windows Firewall ist so, dass jedes über das Netzwerk ankommende Nachrichtenpaket gegen einen Satz von Regeln geprüft wird. Gibt es eine Regel, die das Paket passieren lässt, funktioniert die Kommunikation. In unserem Fall brauchen wir also eine Regel, die den Zugriff von Clients auf den SQL Server zulässt.
Es gibt zwei unterschiedliche Werkzeuge zur Konfiguration von Regeln:
  • Das Kommandozeilentool netsh.exe
  • Die grafische Oberfläche des Betriebssystems, in diesem Fall ist das der Server Manager.
Der erste Weg ist zum Beispiel hier ausführlich beschrieben: http://support.microsoft.com/kb/839980/en-us

Ich erläutere nachfolgend den zweiten Weg mit Hilfe des Server Managers. Öffnen Sie hierfür den Server Manager ("Start" – "Administrative Tools" – "Server Manager") und öffnen Sie links unter "Configuration" den Knoten "Windows Firewall with Advanced Services".


Wir möchten eine Regel erstellen, die von außen Zugriffe auf den SQL Server erlaubt. Aus Sicht des Servers sind das eingehende Anfragen, also klicken Sie auf "Inbound Rules" – Regeln für eingehende Anfragen.
Sie sehen die bereits bestehenden Regeln. Ausgegraute Regeln sind zurzeit nicht aktiv.


Wir erstellen nun eine neue Regel. Klicken Sie hierzu mit der rechten Maustaste auf "Inbound Rules" und wählen Sie den Menüpunkt "New Rule…" aus.
Die erste Entscheidung, die zu treffen ist, betrifft die Art der Regel ("Rule Type"). Für unsere Aufgabenstellung kommen nur die ersten beiden Typen (Programm oder Port) in Frage. Was ist der Unterschied?



  • Port: Wir können zum Beispiel angeben, dass TCP Port 1433 für Anfragen von außen freigegeben wird. Das ist der Standard-Port für eine SQL Server Standard-Instanz. Wenn wir also bei der SQL Server Installation nichts Abweichendes angegeben haben, wird durch eine solche Regel die Standardinstanz von außen erreichbar.
    Das ist geradlinig und übersichtlich. Komplizierter wird die Sache, wenn Sie mehrere Instanzen von SQL Server installieren. Solange Sie daran denken, jeder Instanz einen festen Port zuzuteilen, können Sie für jede Instanz eine entsprechende Regel konfigurieren. Aber standardmäßig erhalten benannte Instanzen dynamisch beim Start einen Port zugeteilt – dann wissen Sie nicht, welchen Port Sie in der Firewall öffnen müssen.
    Hier kommt der Typ "Program" ins Spiel.

  • Program: Bei dieser Art von Regel können wir konfigurieren, dass einem Programm alle Netzwerkzugriffe erlaubt werden, die es benötigt. Wir geben nur den vollständigen Pfad der EXE-Datei an und das war's. Damit wird zum Beispiel das Problem der dynamisch zugewiesenen Ports gelöst.
    Nachteil: Da über eine Regel mehrere Ports geöffnet werden, kann die Fehlersuche aufwändig werden.
Sie können also frei entscheiden, welchen Typ Regel Sie erstellen möchten. Ich zeige Ihnen beide Wege. Fangen wir mit der Regel für den Port an:
  1. SQL Server benötigt normalerweise TCP Port 1433
  2. Die Regel soll den Zugriff erlauben ("Allow the connection")

  3. Die Frage nach dem Geltungsbereich der Regel benötigt noch eine Erklärung:
    Sie kennen diese Frage vielleicht von Windows 7, wenn Sie sich mit einem neuen Netzwerk verbinden, zum Beispiel mit dem WLAN zu Hause oder mit dem WLAN in einem Hotel. Dann stellt das System die Frage: "Was für eine Art von Netzwerk ist das?" Bei dem Netzwerk zu Hause (Private) haben Sie eine höhere Vertrauenswürdigkeit als in dem öffentlichen Netzwerk (Public). Innerhalb des Firmennetzwerks (Domain) können Sie die höchste Vertrauenswürdigkeit unterstellen. Dem entsprechend können Firewall Regeln abhängig gemacht werden von dem Netzwerk, in dem ein Rechner sich gerade befindet.

  4. Schließlich erhält die Regel noch einen Namen und eine Beschreibung:



    Das war die Konfiguration einer Regel für den Port.

Nun erstellen wir eine Regel für das Programm.

  1. Die Programmdatei sqlservr.exe befindet sich im Instanzverzeichnis im Unterverzeichnis BINN. Bei einer Installation mit den Default-Einstellungen ist das:
    %ProgramFiles%\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\Binn\sqlservr.exe

  2. Die Verbindungen sollen zugelassen werden

  3. Erläuterung siehe oben

Vergeben Sie schließlich noch einen guten Namen und eine Beschreibung für die Regel
Das war die Konfiguration einer Regel für das Programm.

Weiter führende Informationen finden Sie zum Beispiel in diesem ausgezeichneten TechNet-Artikel: http://technet.microsoft.com/en-us/library/cc646023.aspx Hier wird unter anderem detailliert beschrieben, welche Ports für alle möglichen Konfigurationen freigeschaltet werden müssen, insbesondere auch für die Analysis Services, Integration Services und Reporting Services.

Nachtrag (23.06.2011)
Ein weiterer Port muss noch freigegeben werden: der UDP Port 1434! Dieser ist dann erforderlich, wenn Sie mit benannten Instanzen arbeiten. Über UDP Port 1434 fragen Clients an, welcher Port einer benannten Instanz zugeordnet ist. (Hintergrund: Da die Standardinstanz per Default TCP Port 1433 erhält und da jede Instanz einen anderen Port benötigt, haben benannte Instanzen einen anderen TCP Port als 1433.) Die Auflösung des Instanznamens zum Port übernimmt der SQL Server Browser Dienst. Daher muss dieser Dienst auch gestartet sein, wenn Sie mit benannten Instanzen arbeiten.
Nachdem Sie UDP Port 1434 freigegeben haben, werden Ihnen übrigens auch alle Instanzen im Auswahlmenü von SQL Server Management Studio angeboten :-)

Montag, 9. August 2010

Versionsverwirrung - Report Builder 3.0

Entgegen allen anders lautenden Hinweisen hatte ich das Problem, dass einige Funktionen, die im Report Designer (Visual Studio) enthalten waren, nicht im Report Builder 3.0 angeboten wurden. Dabei handelte es sich um die neuen Berichtselemente Data Bar, Sparkline, Gauge und Indicator.
Nach Deinstallation des Report Builder 3.0, Download der aktuellen Version und anschließender Neu-Installation waren die fehlenden Funktionen im Report Builder vorhanden.
Fazit: Es gibt anscheinend eine ältere Version von Report Builder 3.0, die sich in der Versionsnummer nicht unterscheidet, die aber dennoch nicht alle Funktionen der aktuellen Version enthält. Frage an Microsoft: Wäre es da nicht besser gewesen, einen Report Builder 3.1 zu veröffentlichen?