Gestern um 15 Uhr (MEZ) fand die Keynote der #MSIgnite in Orlando statt. Anschließend folgten einige Sessions und Ankündigungen zu Neuerungen in Azure, einige wurden im Vorfeld bereits erwartet andere waren überraschend. In diesem Beitrag werde ich euch einen kurzen Überblick über einige Neuigkeiten des 1. Tages vermitteln.
Die Überschriften sind mit Links zum jeweiligen Artikel versehen, damit ihr schnell und einfach zum Originalartikel gelangt.
Soeben ist meine Session SQL Backup on Azure auf dem SQL Saturday Rheinland zu Ende gegangen. Es war mir eine besondere Freude an der Hochschule sprechen zu dürfen.
Continue reading SQL Backup on SQL Saturday – Sessioninhalte
Eines der häufigsten Azure VMs die ich bei Kunden antreffe ist die Installation eines oder mehrere SQL Instanzen innerhalb der VMs. Um die Datenbanken zu sichern waren bisher immer Umwege über MABS, DPM oder 3rd Party Backup Programme notwendig. Dabei ist bereits seit der Ignite 2017 das Azure Backup Feature “Backup SQL Server in Azure VM” in Private Preview und soeben in Public Preview gegangen und in allen Tenants verfügbar. Mit diesem Feature besteht die Möglichkeit SQL Datenbanken die innerhalb von Azure VMs auf installierten SQL Instanzen vorhanden sind, automatisiert direkt in den Keyvault zu sichern. Und das ganze ohne extra Tools oder Backupagents.
In diesem Beitrag werde ich die notwendigen Voraussetzungen, die Einrichtung und die Kosten vorstellen.
Bitte beachten der Service befindet sich derzeit noch in der Preview Phase.
Continue reading Backup SQL Server Datenbanken in Azure IaaS VMs #AzureBackup
Aufgrund des bevorstehenden SQL-Server Wechsels. Wird auch der MySQL Server in der aktuellen Version auf dem neuem Datenbankserver installiert. Da ich in der Vergangenheit doch einige Probleme mit phpMyAdmin hatte, habe ich mich nach einer Alternative umgeschaut und bin auf das vielversprechende Tool Adminer gestossen. Das erste, was bei nahezu gleichem Funktionsumfang, auffällt, ist die Downloadgröße Adminer: 334kb vs. phpMyAdmin 5,4MB als Zip Archiv.
Einen Übersichtlichen Vergleich, welche Vorteile Adminer gegenüber phpMyAdmin hat, gibt es unter www.adminer.org. Einige Vorteile die gleich auffallen, sind:
Ich werde mir die Alternative die nächsten Tage mal anschauen und denke, dass es langsam auch Zeit wird, sich von phpMyAdmin abzuwenden. Nach mehr als 13 Jahren ist der Quellcode nicht mehr zeitgemäß und eine Überarbeitung wäre sicherlich notwendig. Auch die Anzahl an Sicherheitslücken, die im letzten Jahr geschlossen werden mussten, sind deutlich höher als bei Adminer. Allerdings muss man dies in Relation sehen, da phpMyAdmin derzeit wesentlich häufiger eingesetzt wird, als Adminer. Dennoch halte ich es für eine gute Alternative.
Wer noch etwas mehr Informationen sucht, wird auch bei Typo3News fündig.
Für einige Webseitenprojekte habe ich einige Zeit nach einem Portalsystem gesucht. Zunächst hatte ich mich eigentlich für joomla entschieden, doch so recht kam ich nicht zurecht, dass mag aber auch an mangelnder Zeit liegen.
Nun kommen doch einige Webprojekte auf mich zu und ich musste mich nun für ein Portalsystem entscheiden. Aufgrund der Tatsache, dass ich zu großen Teilen Windows-Maschinen betreue und fit werden muss in Powershell habe ich mich für DotNetNuke entschieden. Zum einen ist die Community ausreichend groß und zum anderen basiert das System auf den Sprachen die ich erlernen muss. So bleibe ich zunächst bei einer einheitlichen Sprache und kann mich darauf konzentrieren und spätere Anpassungen werden mir so sicherlich leichter fallen.
Die Installation verlief durch den Webbrowserbasierte Installationsroutine sehr einfach und dazu gibt es eigentlich keine weiteren Worte zu verlieren. Die Verbindung zum SQL-Server war auch unspektakulär.
Einzig sind im Vorfelg einige Vorkonfigurationen vorzunehmen.
So wurde zunächst ein Service-Account im AD angelegt. Diesem Server-Account wurde Ändernde-Rechte auf dem DotNetNuke-Verzeichnis gewährt. Außerdem wurde eine Datenbank im SQL-Server angelegt und als Besitzer ebenfalls der Service-Account zugewiesen.
Im IIS wird die Seite als Application ausgeführt. Auch hier wurden Typischerweise die Rechte vom Service-Account übernommen.
Nach durchführen dieser Konfigurationsschritte war das Starten der Installationsroutine ein Kinderspiel. Diese macht zunächst ein Check, ob alles entsprechend korrekt konfiguriert wurde und die entsprechenden Rechte gesetzt sind, also keine Panik, sollte etwas nicht passen, so wird einem dies von der Installationsroutine mitgeteilt.
Nachtrag:
Aufgrund der doch eher unübersichtlichen Webkonfiguration bei DotNetNuke habe ich im letzten Moment doch noch einen Schwenk nach Joomla gemacht. Nach einem Tag Einarbeitung und ein weiteren Tag Websiteerstellung muß ich meine Aussage zurück ziehen. Zunächst war die Einarbeitung doch sehr einfach und die Ergebnisse die bereits nach kurzer Zeit Erzielbar sind, sind mehr als nur Zufriedenstellend.
Für einen Kunden benötigten wir einen SQL Server 2008 R2 Express. Dieser sollte über die LAN-Verbindung ansprechbar sein und es sollte eine ODBC-Verbindung für bestehenden Datenbanken und weitere Clients eingerichtet werden. Dabei stellten sich die ein oder anderen Schwierigkeiten heraus, da der SQL Server Express sich bei den Management Werkzeugen zum Vorgänger unterscheidet.
Bei der Vollinstallation des SQL 2008 R2E werden zwar alle Komponenten installiert, aber einige benötigte Dienste bleiben mittlerweile Standardmäßig deaktiviert. Dazu gehören unter anderem auch die Dienste um den SQL 2008 R2E über LAN zu erreichen.
Nach Abschluß der Installation fällt auf, dass es im Programmordner nur noch den Eintrag für das SQL Server Management-Studio gibt. Sucht man hingegen den SQL Server Konfigurations-Manager so ist dieser nun mit in die Computerverwaltung integriert:
Um nun eine Verbindung von außerhalb zu zu lassen, sind folgende Schritte notwendig:
1. Konfiguration der Windows Firewall und öffnen der Ports 1433, 1434 und einen dynamischen Port den hier bereits festlegen würde (z.B. 48124)
2. Unter Computerverwaltung->Dienste den Dienst “SQL Browser” von deaktiviert auf Automatisch einstellen
3. Computerverwaltung -> Dienste und Anwendungen -> SQL-Server-Management-Konfiguration -> SQL-Server-Netzwerkkonfiguration->Protokolle für SQL Express -> TCP/IP auswählen und hier kann ganz am Ende unter dem Punkt “IPall” der dynamische Port fest vergeben werden. 
Nachdem durchführen dieser Schritte sollter einer ODBC-Verbindung von einem externen Host nichts mehr im Wege stehen.
Um den dynamischen Port auch fest im ODBC-Connector zu verwenden, gibt es bei der Einrichtung der ODBC-Datenquelle den Punkt Clientkonfiguration (siehe Screenshot), hier lässt sich ein Port fest bestimmen.
Solltet Ihr Probleme haben, so hinterlasst einfach ein Kommentar, ich schau dann mal wo der Fehler liegt.
Ansonsten viel Erfolg.
Vor einigen Tagen wurde die Installation des Sharepoint Servers 2010 in einer dreistüfigen Farm vorgenommen. Dabei verlief die Installation nach der Dokumentation auf technet ab und war relativ unspektakulär. Viel wichtiger ist die Vorbereitung der benötigten Dienstkonten und die Anpassung der Rechte z.B. für den Sharepoint Farmadministrator auf dem SQL-Server.
Für den großteil der Dienste wurden einige Dienstkonten im AD angelegt. Diese wurden im Sharepoint eingetragen und dort wurde auch gleich Gebrauch von der neuen Funktion “Managed Accounts” gemacht. Hierrüber lassen sich die Dienstkonten für den Sharepoint-Server zentral verwalten und zudem wird automatisch ein Passwortwechsel, basierend auf den Kennwortrichtlinien, vorgenommen.
Auf eine bebilderte Anleitung verzichte ich an dieser Stelle, da es hier zu schon genügend gibt und ich, wie bereits oben erwähnt, rein nach der TechNet Doku vorgegangen bin.
Ein nettes Feature ist auf jeden Fall die Statusanzeige der Sharepoint-Farm auf der Seite der Zentraladministration. Nach Abschluss der Installation wurden hier noch einige Warnungen (z.B. doppelt verwendete Dienstkonten, Dienstkonten in der Gruppe der lokalen Admins, usw.) angezeigt, die nach den vorhandenen Informationen, bereinigt wurden.
Zunächst wurde ein weiteres Zertifikat für die Zentraladministration beantragt. Danach wurde eine Teamwebseite angelegt, auf der ein DMS eingerichtet wird, welches die neuen Funktionen von Sharepoint 2010 nutzen soll, wie z.B. Metadaten Service und die Navigation zu Dokumenten über die vorhandenen Metadaten. Ausserdem sollen die bisher vorhandenen Daten, nach und nach, auf den Sharepoint wandern und die neu angelegten Dokumente direkt im Sharepoint erstellt werden.
Das Backup der SQL-Datenbanken ist bereits im DPM 2010 eingerichtet. Die Sicherung der Sharepoint-Farm an sich, ist ein weiterers Thema, was die nächsten Tage angegangen wird.
Aufgrund der Anforderungen von Exchange und Sharepoint 2010 nach einer homogenen Architektur wird die Serverlandschaft sukzessive auf 64Bit angehoben. Zunächst wurde der SQL-Server neu aufgesetzt, siehe vorherigen Post. Dabei wurde Server 2008 64Bit und SQL Server 2008 64Bit installiert. Bei der Konfiguration muss den SQL-Tools allerdings mitgeteilt werden, dass diese jetzt auf einer 64Bit Plattform laufen.
