Desired State Configuration #2 – Erste Schritte zur SQL Server Installation

EDIT:
Falls ihr nach einer fertigen Lösung sucht, bitte geduldet euch… ich erläutere hier meinen Projekt-Verlauf, wie ich wann wie vorgegangen bin… als letzten Blogbeitrag werde ich die „fertige“ Lösung vorstellen.

Vielen Dank für euer Verständnis

Nach meinem ersten Beitrag – den Vorbereitungen zur Nutzung von Desired State Configuration (DSC) – kann man nun die erste Schritte zur Installation eines SQL Servers einleiten. Was benötigen wir also für Voraussetzungen für die Installation eines SQL Servers auf einem neuen Windows Server?

Zu meiner Test-Umgebung… ich nutze für die Entwicklung meiner Skripte in diesem Fall eine Dev-Umgebung in Azure bestehend aus mindestens zwei Windows Servern. Ich nutze einen Server als Domänencontroller und die zweite Maschine als SQL Server, um hier meine Skripte zu testen und die Funktion zu testen. Einen oder mehrere Server kann und werde ich nach Bedarf ausrollen, um eben meine Demos zu halten bzw meine Skripte zu entwickeln und testen.

Entwicklungs-Umgebung für Ola Hallengren und Powershell-Skripte

Voraussetzungen für die Installation

Um eine einfache SQL Server Installation – im Sinne meines Kunden-Projektes – auf einem neuen Server durchzuführen benötigen wir dreierlei Dinge:

  • .NET Framework 4.5 (Minimum)
  • Installations-Medium SQL Server 2017 Standard Edition
  • und das letzte Update im Sinne des letzten Cumulative Updates

Um das Installations-Medium auf dem neuen Server bereitzustellen, bedarf es mindestens eines Ordner auf irgendeinem Laufwerk. Nun gibt es mehrere Möglichkeiten diesen Ordner bereitzustellen…

  • manuelle Anlage des Ordners
  • Anlage des Ordners mittels DSC
  • Anlage des Ordners mittels Powershell

Da wir ins diesem Projekt, dieser Beitragsserie bestrebt sind alles zu automatisieren, fällt natürlich das manuelle Anlegen des Ordners weg. Je nach dem wie man vorgehen möchte, welche Voraussetzungen man erfüllen muss/möchte bzw in welcher Reihenfolge man vorgehen möchte, kann man nun wählen zwischen Desired State Configuration oder Powershell. In diesem Projekt möchte ich darstellen, wie man nun zur erst auf dem Zielserver ein entsprechendes Verzeichnis anlegt und dann dort mit einfachen Mitteln das Installationsmedium ablegt.

Anlage des Ordners mit Powershell

Um mein Vorhaben zu realisieren, müsste ich theoretisch erst eine Desired State-Configuration für die Folder-Anlage erstellen sowie implementieren und die Kopier-Aktion starten, dann die eigentliche Installation starten, das versuche ich erst in einem zweiten Schritt, jetzt starte ich mit der „einfacheren“ Vorgehensweise. Dazu nutze ich das „Invoke-Command“ und prüfe ob der Ordner auf dem Zielserver vorhanden ist oder nicht, wenn nicht wird der Ordner neu angelegt.

Invoke-Command -ComputerName $NodeName -ScriptBlock { 
param ($LocalInstallFolder)
if (!(Test-Path -Path $LocalInstallFolder )) {
    New-Item -ItemType directory -Path $LocalInstallFolder | Out-Null
} else {
    Remove-Item -Recurse -Force $LocalInstallFolder
    New-Item -ItemType directory -Path $LocalInstallFolder | Out-Null
} -ArgumentList "D:\$LocalInstallFolder\"

Warum lösche ich erst das Zielverzeichnis? Na klar, wenn ich das Skript mehrfach ausführe, dann muss immer das aktuelle Installationsmedium und das aktuelle Update dort bereit liegen, daher wird erst einmal das Verzeichnis gelöscht, um dann neu erstellt zu werden.
Wenn die Ziel-Verzeichnisse vorhanden sind, dann kann man die benötigeten Dateien/Verzeichnisse kopieren.

Kopieren des Installationsmediums

Anfänglich hatte ich meine Dateien alle mit „Copy-Item“ vom Netzlaufwerk auf den Zielserver kopiert, da ich aber doch recht viel mit der Powershell ISE entwickel, fehlte mir eine „Fortschrittsanzeige“… daher bin ich später auf „Start-BitsTransfer“ umgestiegen.

Write-host "Copy SQL-Image to"$NodeName.ToUpper()
$DestinationPath = "\\$NodeName\d$\$LocalInstallFolder\"
Start-BitsTransfer -Source ..\SQL\* -Destination $DestinationPath -Description "..\SQL\* will be moved to $DestinationPath" -DisplayName "Copy SQL-Image" 
Start-BitsTransfer -Source ..\SQL\Updates\* -Destination "$DestinationPath\Updates\" -Description "..\SQL\Updates\* will be moved to $DestinationPath" -DisplayName "Copy SQL-Updates" 

Aber das war mir dann irgendwie auch zu aufwendig und kompliziert, so irgendwie „Work-around“… aber zu mindestens funktionierte es 😉 Genauso bin ich vorgegangen, als die notwendigen Powershell-Module auf den Zielserver kopiert habe. Aber mit jedem Tag und jedem weiteren Versuch sich mit Desired State Configuration auseinanderzusetzen, lernt man dazu.
So bin ich jetzt dazu übergegangen auch dieses vorbereitende Kopieren mittels DSC zu realisieren.

Configuration CopyInstallationMedia
{
    Node $AllNodes.where{ $_.Role.Contains("SqlServer") }.NodeName
    {
        File InstallationFolder 
        {
            Ensure = 'Present'
            Type = 'Directory'
            SourcePath = "\\dc1\NetworkShare\SQL\"
            DestinationPath = "D:\SQL2017\"
            Recurse = $true
        }
    
        File PowershellModules 
        {
            Ensure = 'Present'
            Type = 'Directory'
            SourcePath = "\\dc1\NetworkShare\Modules\"
            DestinationPath = "C:\Windows\system32\WindowsPowerShell\v1.0\Modules\"
            Recurse = $true
        }
    }
}

Clear-Host
$OutputPath = "\\dc1\DSC-ConfigShare"
CopyInstallationMedia -OutputPath "$OutputPath\CopyInstallationMedia\"    

Start-DscConfiguration -ComputerName sqlvm02 -Path \\DC1\DSC-ConfigShare\CopyInstallationMedia -Wait -Verbose -Force

Aufbau meiner DSC-Konfigurationen

Ich habe mir zwecks besserer Übersicht und vereinfachtem, schrittweisem Ausprobieren sowie Nachvollziehbarkeit mehrere Abschnitte in meiner Desired-State-Configuration angelegt. Die jeweilige Konfiguration kann ich nun gezielt und einzeln aufrufen und „verfeinern“.

Configuration CopyInstallationMedia
{
    Node $AllNodes.where{ $_.Role.Contains("SqlServer") }.NodeName
    {
        File InstallationFolder 
        {
            ...
        }

        File PowershellModules 
        {
            ...
        }

        Configuration ConfigureSQL
        {
            ...
        }
}

Natürlich bedarf es auch einiger Parameter, die man nicht ungeachtet lassen darf, diese werden eingangs des Skriptes definiert. In meinen Fall benötige ich zur Installation und späteren Konfiguration zumindest den Pfad wo die Installationsmedien zentral abgelegt werden und den Zielserver, wo die DSC-Konfiguration ausgerollt werden soll.

param
(
    # Path where all Install media will be located
    [Parameter(Mandatory=$true)]
    [String]
    $InstallPath,

    # Computer name to install SQL Server On
    [Parameter(Mandatory=$true)]
    [String]
    $ComputerName
)

Nachdem ich nun die Konfiguration unterteilt und definiert habe, kann ich notwendige Skripte bzw Module hinzufügen und das Erstellen der MOF-Files einleiten. Anhand dieser MOF-Files wird dann die IST-Konfiguration mit der SOLL-Konfiguration abgeglichen und entsprechend korrigiert. Da sich zwischen letztmaligen Erstellen der MOF-Files und „Jetzt“ etwas an der SOLL-Konfiguration geändert haben könnte, lasse ich sicherheitshalber immer die Files neu erstellen, um diese direkt im Anschluss auf den Zielserver auszurollen. Zur näheren Erläuterung meines Skript-Abschnittes… Ich rufe die jeweilige Konfiguration auf, weise ihr eine Konfigurationsdatei hinzu und definiere einen Pfad für die Ablage der MOF-Files. Als Abschluss wird die jeweilige SOLL-Konfiguration vom zentralen Ablageort auf den Zielserver ausgerollt.
Wie man nun auch nachvollziehen kann, bin ich in der Lage die einzelnen Schritte auch separat für Debug-Zwecke auszuführen, entweder manuell nacheinander oder nur einzelne Konfigurationen wie zum Beispiel die bloße Konfiguration eines SQL Servers.

Write-host "Starting DSC process on"$NodeName.ToUpper()
Import-Module $PSScriptRoot\ConfigureSQLServer.psm1 -Force

## Create MOF-Files
$OutputPath = "\\dc1\DSC-ConfigShare"
CopyInstallationMedia -ConfigurationData \\dc1\NetworkShare\scripts\configData.psd1 -OutputPath "$OutputPath\CopyInstallationMedia\"
SQLInstall -ConfigurationData \\dc1\NetworkShare\scripts\configData.psd1 -OutputPath "$OutputPath\SQLInstall\"
ConfigureSQL -ConfigurationData \\dc1\NetworkShare\scripts\configData.psd1 -OutputPath "$OutputPath\SQLConfig\"

## Use MOF-Files to establish desired state configuration
Start-DscConfiguration -ComputerName $Computername -Path \\DC1\DSC-ConfigShare\CopyInstallationMedia -Wait -Verbose -Force     
Start-DscConfiguration -ComputerName $Computername -Path \\DC1\DSC-ConfigShare\SQLInstall -Wait -Verbose -Force     
Start-DscConfiguration -ComputerName $Computername -Path \\DC1\DSC-ConfigShare\SQLConfig -Wait -Verbose -Force

So sieht dann meine Ordner-Struktur bzw Datei-Struktur auf dem zentralen Server aus, für jede SOLL-Konfiguration gibt es einen Ordner und für jeden Zielserver eine einzelne Datei.

Desired State Configuration – Einfache SQL Server Administration mit DSC

Ich hatte mich vor etwa zwei Jahren erstmalig mit DSC auseinandergestzt, um für den SQLSaturday #605 eine Demo zu zaubern, die die Konfiguragtion des SQL Servers ständig überwacht und gffs korrigiert. Jetzt habe ich wieder ein sehr schönes Kundenprojekt, bei dem ich die Wahl habe zwischen kompletter Umsetzung in Powershell (via dbatools) oder eben ein wenig DSC in Verbindung mit dbatools.

Aufgabenstellung

Auf „Knopfdruck“ sollen zwei neue SQL Server installiert und konfiguriert werden, auf denen dann mehrere Datenbanken in Basic Availibility Groups laufen. Hierzu habe ich mir also meine Azure-Test-Umgebung erweitert und möchte euch nun meinen Weg zur einer funktionierenden SQL Server Umgebung darstellen.

Folgenden Themen werde ich in den nächsten Wochen entsprechend beleuchten:

  • Vorbereitung der Server
  • Installation des SQL Servers
  • Konfiguration des SQL Servers
  • Backup/Restore Automatisierung
  • Erstellung der BAGs aus den Backups
  • Aktivierung und Abschluss der neuen Server

Voraussetzungen für DSC schaffen

Ich gehe von folgender Ausgangslage aus:

Die neuen Server sind bis Oberkante Betriebssystem installiert und konfiguriert, hängen in einer Domäne und habe das aktuelle Windows Management Framework installiert, idealerweise ist auch bereits Windows Remote Management (WinRM) installiert und aktiviert… wenn nicht überprüfen wir das und holen dies ggfs nach.

Anfänglich wollte ich auch den Server noch mit Powershell in die Domäne hängen, hätte mich aber dabei ein wenig im Kreis gedreht ohne zu einer zufriedenstellenden Lösung zu kommen… daher hier nur ein Versuch mittles Screenshot… 😉

Versuch einen Server in die Domäne zu bringen

Ok, also weiter… wie bekomme ich also auf allen Zielservern WinRM automatisch ausgerollt und konfiguriert, sowie alle dazugehörigen Firewall-Ports geöffnet… Google half mir etwas bei der Ideenfindung, aber meine Gedanken liefen auch so schon in die richtige Richtung => Domänen-Gruppen-Richtlinien (aka Group-Policies).

Dazu also in der GruppenRichtlinienVerwaltung der Domäne eine Gruppenrichtlinie erstellen, damit man auch eine ordentliche und nachvollziehbare Struktur aufbauen kann.

1.) Service einrichten

Neuen Service hinzufügen und entsprechend konfigurieren

Computer Configuration > Preferences > Control Panel Settings > Services

DSC - GPO - gpedit - WinRM Service

2.) Zugriff auf Window Remote Shell erlauben

Zumindest dem Service den Zugriff erlauben, falls das nicht ausreichend sein sollte, auch noch der RemoteShell den Zugriff erlauben.

Computer Configuration > Policies > Administrative Templates > Windows Components > Windows Remote Management (WinRM) > WinRM Services

DSC - GPO - gpedit - WinRM Service
DSC - GPO - gpedit - Windows Remote Shell

Nun zu den Löchern in der Firewall

3.) Firewall öffnen für winRM

Letzte Konfiguration, damit alle Server in der Domäne mittles dieser Gruppenrichtlinie konfiguriert werden, um später in der Lage zu sein über DSC (Desired State Configuration) einen SQL Server zu installieren.

Computer Configurations > Policies > Windows Settings > Security Settings > Windows Firewall and Advanced Security > Windows Firewall and Advanced Security 

Nun eine neue Inbound-Rule erstellen, damit auch Zugriffe von aussen (hier vom DomainController auf die SQL Server) ermöglicht werden.

Diese Regel wird explizit für das Windows Remote Management erstellt, um damit alle Verbindungen innerhalb der Private und Domain-Netzwerkes zu erlauben, das Public-Netzwerk wird sicherheitshalber nicht berücksichtigt.

DSC - GPO - gpedit - WinRM Service Firewall Regeln erstellen

Nun kann man diese neue Gruppen-Richtlinie auf alle Server ausrollen und sollte danach in der Lage sein, alle Server mittels DSC zu konfigurieren und administrieren.

4.) Gruppen-Richtlinien aktualisieren

Den neuen Server nun in die Domäne bringen und somit sollte der Server eigentlich die neu erstellten Richtlinien automatisch erhalten. Um aber absolut sicherzustellen, dass dem so ist kann man auch die Gruppen-Richtlinien auf dem Server selber manuell einmal aktualisieren.

Nun sollte der Konfigurator des Server mit DSC nichts mehr im Wege stehen und man kann auf dem zentralen Administrations-Server die entsprechenden Regel erstellen und ausrollen. Dazu aber mehr im nächsten Blogbeitrag 😉

Quelle: How to Enable WinRM via Group Policy

Update der Gruppen-Richtlinien aufgrund von Fehlern in der Skript-Ausführung

Nachdem ich den ersten Beitrag fertig hatte und für weitere Beiträge sowie das Kunden-Projekt recherchiert und getestet habe, musste ich leider feststellen, dass ich im späteren Verlauf des Skriptes darauf angewiesen bin mittels WMI bestimmte Werte wie RAM und CPU zu ermitteln. Dies geht nur, wenn ich eine Verbindung vom zentralen Management-Server aus zum Zielserver aufbauen kann. Hierzu fehlte leider eine Regel in der Firewall der Server, die eine eingehende und ausgehende Kommunikation mit dem RPC-Server/-Service zulässt. Also musste ich noch eine weitere Anpassung an der Gruppen-Richtlinie vornehmen.

GruppenRichtlinien WMI Inbound
GruppenRichtlinien WMI Outbound

Housekeeping einer Azure SQL DB Managed Instance

Ich habe mich heute etwas intensiver mit der „neuen“ Azure SQL Database – Managed Instance beschäftigt und dabei ging es auch um das Housekeeping, welches man in regelmäßigen Abständen auf allen SQL Servern durchführen sollte. Überlicherweise nehme ich hierfür die Skripte von Ola Hallengren, welche in regelmäßigen Abständen aktualisiert und erweitert werden. Aufgrund der weit verbreiteten, weltweiten Nutzung kann man hier auch davon ausgehen, dass die Funktionalität und Stabilität absolut produktionswürdig ist und können daher ohne Bedenken auch in Produktionsumgebungen eingesetzt werden.

Für einen Workshop und natürlich aus eigenem Interesse habe ich einen einfachen Weg gesucht, wie ich das Housekeeping in einer Managed Instance realisieren kann, daher habe ich einfach nur das normale Skript von der Webseite runtergeladen und in das SQL Management Studio eingefügt. Kurz überprüft, ob die Einstellungen in dem Skript valide sind und ausgeführt.

Zu meinem Erstaunen lief das Skript ohne Probleme einfach durch und meldete eine erfolgreiche Ausführung, ein kurzer Blick in die SQL Server Agent Jobs brachte die nächste Überraschung da die zu erstellenden Jobs auch tatsächlich vorhanden waren. Ok, die Backup-Jobs fehlten, aber darum brauche ich mich in einer Managed Instance nicht zu kümmern, da dies automatisch erfolgt.

Managed Instance - Housekeeping - Ola Hallengren - SQL Server Agent Jobs

Als ich jetzt auch noch die Jobs nacheinander gestartet hatte und diese alle einwandfrei durchliefen, war ich nahezu platt. Also ich kann die Ola Hallengren Housekeeping Jobs nur empfehlen, sowohl onprem, als auch in irgendeiner virtuellen Maschine oder eben in der Azure SQL Database Managed Instance! Beim Schreiben dieses Beitrages habe nocheinmal direkt in das Skript geschaut, ob es irgendeine „Magic“ gibt, die dafür sorgt, dass die Backup-Jobs nicht angelegt werden und tatsächlich hat Ola hier großartige Arbeit geleistet. Wenn man sich dann auch die Dokumentation auf der Webseite anschaut, wird man feststellen, dass er tatsächlich auch auflistet, dass die Managed Instance offiziell unterstützt wird.

Also worauf wartet ihr, nutzt die Ola Hallengren Housekeeping Jobs (aka Maintenance Jobs) auch für eure SQL Server!

SQLDays 2018 in München

Dieses Jahr war ich erstmalig auf den SQLDays in München genauergesagt in Erding (Erdinger Stadthalle), bei den SQLDays handelt es sich um eine Schulungs-Veranstaltung der ppedv. In den zwei bzw vier Tagen geht es vor allem um die namensgebende Microsoft-DataPlatform Umgebung rund um den SQL Server, an zwei Workshop-Tagen und zwei Konferenz-Tagen können die Teilnehmer aus einer Vielzahl von interessanten Sessions von hochrangigen Sprechern auswählen. Zum Beispiel hielt Georg Urban die Keynote und Markus Raatz hielte folgenden Vortrag:

Markus Raatz : Echtzeitdatensets in Power BI: Einführung und HowTo

Von Echtzeit-Daten, wie sie meist im Streaming-Verfahren von IoT-Datenquellen geliefert werden, geht ein großer Reiz aus. Nichts ist schöner, als auf ein Browserfenster zu starren und zu sehen, wie sich der winzige Lieferwagen von allein Meter um Meter auf mein Haus zubewegt! Auch Dashboards, in denen Liniengrafiken auf- und abwärts zucken, können uns stundenlang beschäftigen. Der technische Hintergrund dazu sind Power BI Streaming Datasets, deren Möglichkeiten wir uns in diesem demo-reichen Vortrag einmal ansehen werden. Was sind mögliche Visualisierungen, welche Datenquellen bieten sich an und welche Beschränkungen der Technologie gibt es?

Aber auch die Sponsoren liessen es sich nicht nehmen ihr Wissen zu verbreiten, hier ist Andreas Heberger von Amazon mit seinem Vortrag zu nennen:

Orange Is The New Blue – Warum Amazon Web Services eine gute Wahl für Ihre Microsoft SQL Workloads ist

Wir zeigen Ihnen welche Möglichkeiten die AWS Plattform bietet, Ihre Microsoft SQL Workloads performant, flexibel und kosteneffizient in der Cloud zu betreiben. Desweiteren bietet AWS Möglichkeiten den administrativen Aufwand zu verringern, damit Sie sich wieder auf Kernaufgaben konzentrieren können. Dabei beleuchten wir die Vor – und Nachteile der einzelnen Varianten, von der klassischen Installation auf IaaS VMs, dem AWS managed Service (RDS) sowie Migrationsstrategien. Darüber hinaus wollen wir Wege aufzeigen wie vorhandene Lizenzinvestments weiterverwendet werden können, und wie Sie mithilfe von AWS sogar Ihre Lizenzkosten verringern können.

Neben den genannten waren viele nationale und europäische Sprecher auf den SQLDays und trugen so zu einem ordentlichen Wissenstransfer bei!

Mein Vortrag zu Azure SQL Database konnte ein wenig auf dem zeitlich früheren Vortrag von Greogor Reimling aufbauen, der den Teilnehmern etwas über die Azure Managed Instance erzählte.

Gregor Reimling - SQLDays 2018 - Azure SQL Managed Instance

Kurz vor der Mittagspause stand ich dann im großen Saal und durfte den interessierten Teilnehmern etwas zu Azure SQL Database und deren Administration mit Powershell näher bringen, für alle die an meinem Vortrag teilgenommen haben, hier auch noch einmal ein Hinweis wegen der gescheiterten Demo => hier ist der Nachtrag bzw die Korrektur

Die Organisation der Veranstaltung war sehr gut, Teilnehmer und Sprecher der SQLDays wurden sehr gut versorgt, man musste sich um nichts Gedanken machen, egal ob Getränke und Snacks zwischen den Sessions oder Mittagessen oder während der gemeinsamen Abendveranstaltung! Ausreichend Getränke und super-leckeres Essen sorgten für eine angenehme Atmosphäre und motivierte Mitwirkende!

Bjoern Peters - Azure SQL Database - SQLDays 2018

Natürlich habe ich auch im Rahmen meiner Anwesenheit (ich war nur den Dienstag auf den SQLDays) auch mehreren Sessions gelauscht, wie zum Beispiel Andre Essing:

The joy of analytics – Lassen Sie uns zusammen ein Data Warehouse in die Cloud malen

Es gibt eine Menge Wege und Möglichkeiten Mehrwerte aus seinen Daten zu ziehen. Seit Jahren machen wir das mit den gleichen Techniken in unseren „klassischen“ Data Warehouse Umgebungen. Aber die Welt ist im steten Wandel und so auch die Daten. Wo die Daten vor ein paar Jahren noch ausschließlich strukturiert waren, wächst die Zahl von schemalosen Datentypen ins unermessliche, und eine Ende ist nicht in Sicht. Wir kämpfen mit Daten, bei denen sich ständig das Schemata ändert und versuchen Mehrwerte aus neuen Datentypen wie Soziale Medien, Videos und Bildern zu ziehen. In dieser Whiteboard Session möchte ich mit Ihnen über moderne Wege sprechen, Ihre Daten zu speichern, zu analysieren und zu visualisieren. Zusammen zeichnen wir ein Modern Data Warehouse, schauen uns an welche Möglichkeiten sich bieten verschiedenste Daten zu analysieren und warum uns die Cloud hier hilft. Besuchen Sie meinen Vortrag und zeichnen Sie mit mir zusammen ein modernes Data Warehouse.

Andre Essing - SQLDays 2018

Es hat auf jeden Fall sehr viel Spaß gemacht und es war meine erste Teilnahme an den SQLDays, die meine Münchener Kollegen immer wieder als großartige Veranstaltung erwähnt haben, daher erfüllt es mich auch ein wenig mit Stolz dort als Sprecher dabei sein zu dürfen. Vielleicht klappt es ja auch im nächsten Jahr wieder mit einem spannenden exklusiven Vortrag für die SQLDays 2019 in Erding. Termin steht schon 😉

SQLDays 2019 – Save the date: 14.-17. Okt. 2019 München

Weitere Informationen findet ihr auf der Homepage der SQLDays…

SQLSaturday #772 – München – wieder 3 PreCons, 27 Sessions, 29 Sprecher

Am kommenden Freitag, den 26. Oktober 2018 ist es endlich wieder einmal so weit… es gibt einen weiteren SQLSaturday in München!!!

In 2017 gab es leider keinen SQLSaturday in München, da sich aufgrund privater Umorientierungen kein Organisations-Team gefunden hat… auch dieses Jahr wurde es schwierig, aber man hat es in einer starken Gemeinschaftsleistung geschafft => Community eben 😉

Somit trifft sich die deutsche (und umliegende) PASS-Community am nächsten Wochenende (26.+27.10.2018) bei Microsoft in München, um sich mal wieder einen ganzen Tag über die aktuellsten Themen rund um die Microsoft Data-Plattform zu unterhalten. Eine Vielzahl an spannenden Themen von erfahrenen Sprechern mit viel Know-How informieren euch über Vereinfachung der DBA-Tätigkeiten mit Powershell, Power BI Deployment Strategien, ganz viel Azure SQL Database (im Allgemeinen, als Managed Instance und über die Migration) und nicht zu vergessen, dass unvergessliche NerdyCorn-Quiz von Ben Weissman!

Informiert euch auf der Event-Seite über den ganzen Zeitplan, wann es welche Session von welchem Sprecher in welchem Raum gibt => SQLSaturday #772 München 2018 Schedule

Ich hoffe wir werden uns dort sehen !!!

SQLSaturday #772 - Part of Schedule - Munich 2018

Allgemeines zum SQLSaturday

Ich war einfach frech und habe die englische Beschreibung von der Event-Seite kopiert 😉

SQLSaturday is a free 1-day training event for Microsoft Data Platform, SQL Server professionals and those wanting to learn about SQL Server and the Microsoft Data Platform. Admittance to this event is free, all costs are covered by donations and sponsorship. Please register soon as seating is limited, and let friends and colleagues know about the event!

Also, we offer 4 pre-conference workshops on the day before the main conference. So, if one day of training isn’t enough, join SQL Server Experts and MVPs for full-day workshop on October 26th, 2018.

Hotel Recommendations

Our hotel recommendation for the SQL Saturday is the INNSIDE München Parkstadt Schwabing, Mies-van-der-Rohe Straße 10, 80807 Munich, Germany. The hotel is just around the corner and just a few steps away from the Microsoft Office.

Alternative hotels in the same neighborhood are: