SQL Server 2017 Cumulative Update 3

Soeben wurde das dritte Cumulative Update für SQL Server 2017 veröffentlicht.

16 Bugfixes sind enthalten und es wird empfohlen das CU proaktive zu installieren.

Darunter interessante wie

CUs sind nicht mehr optional und erfordern keine Registrierung für den Download.

Verbose Logging in Azure Automation

Beim Debugging von Azure Automation Scripten gibt es einiges zu beachten. Das Wichtigste, es gibt kein Write-Debug!

Ein bestimmtes Verhalten ist aber besonders störend. Bei aktiviertem Verbose Logging kann dies nicht für einzelne cmdlets deaktiviert werden.

In der lokalen PowerShell lässt sich mittels „-Verbose:$false“ die Ausgabe von Verbose Messages verhindern. Das lässt sich einfach nachvollziehen.

Dieses Verhalten ist bei Azure Automation nicht gegeben. Sobald das Verbose Logging für ein Runbook aktiviert ist, betrifft dies die komplette Ausgabe.

Das führt zu sehr langen Wartezeiten bei der Ausgabe. Beim AzureRM Module sind das aktuell 11464 Zeilen Verbose Log. Die Anzeige dieser Ausgabe im Browser dauert nicht nur sehr lang, es macht das Ergebnis schwer lesbar.

Hilfe bei doppelten PowerShell cmdlet Namen

Danke VMware für die doppelte Verwendung des cmdlet Namen „New-Cluster“ und „Get-Cluster“ im PowerCLI Module „VMware.VimAutomation.Core“

Diese Namen werden, wie die meisten wissen, auch schon von einer anderen Technologie genutzt. Dem Microsoft Windows Failover Cluster.

Sobald man das „failoverclusters“ Modul manuell nachlädt wird das VMware cmdlet überschrieben.

Sollte man beide Module auf einem Server installiert haben und möchte nicht immer manuell ein Import-Module durchführen, gibt es noch eine einfache Lösung das korrekte cmdlet direkt zu adressieren.

Dieses betrifft folgende cmdlets wenn die VMware Module installiert sind.

SQL Server und Meltdown und Spectre

Was ein Einstieg in das Jahr 2018. Meine Blogpause wurde begleitet von einer der größten Sicherheitslücken in den letzten Jahren. Betroffen ist fast jeder Nutzer von IT und das platformübergreifend.

Mittlerweile hat nicht nur das Project Zero von Google weitreichende Informationen veröffentlicht, sondern auch die Hersteller haben reagiert.

Microsoft Azure wurde schon, soweit Patches vorhanden sind, abgesichert.

Für SQL Server hat Microsoft Richtlinien veröffentlicht, die von jedem Admin befolgt werden sollten um sensible Daten zu schützen.

  • Windows Updates aktivieren und installieren
    Achtung: Für Windows Server 2012, 2008 und <= 20003 sind keine Patches vorhanden, die Lücke betrifft diese Systeme aber natürlich trotzdem.
  • SQL Server Updates installieren
    Achtung: Für alle anderen SQL Versionen ist aktuell kein Patch veröffentlicht worden. Bitte bei Microsoft prüfen ob dies in der Zwischenzeit der Fall ist!

  • Alle Funktionen deaktivieren, welche Code ausführen den Microsoft nicht kennt und somit als gefährlich gelten. Dazu gehören:
    • SQL CLR assemblies
    • R und Python Pakete die als externe Skripte angesprochen werden oder das „R/Machine Learning Studio“
    • SQL Agent auf dem selben Server wie der SQL Server mit z.B. ActiveX Skripten
    • Nicht-Microsoft OLE DB Treiber für Linked Server
    • Nicht-Microsoft Extended Stored Procedures

Wie immer sollten die Patches vorher getestet werden. In diesem speziellen Fall liegt das daran, dass die Patches zu Leistungseinbußen führen können.
Jedoch sollte bei der Frage Datensicherheit vs. Performance nicht die Performance gewinnen, sondern es sollte einem nur bewusst sein was passieren wird.

Microsoft continues to do performance evaluation on the patched binaries. However, at the time of publication, Microsoft has not yet validated SQL Server performance with all microcode patches, nor has it validated performance in all Linux environments. Customers are advised to evaluate the performance of their specific application when applying patches. Please validate the performance impact of enabling microcode changes before deploying into a production environment. Microsoft will update this section with more information when it is available.

DSC Ressource Namenskoventionen

Bisher galten für experimentelle und Community DSC Ressourcen folgende Namenskoventionen.

Prefixe:

  • x = Experimentell oder nicht offiziell supported
  • c = Support durch die Community

Der Suffix Dsc war Modulen vorbehalten, welche die Anforderungen an ein „High Quality DSC Resource Module“ erfüllen.

Damit ist ab sofort Schluss: Die Prefixe „x“ und „c“ werden nicht mehr verwendet!

In der aktuellen Dokumentation der Namenskonvention wird diese Änderung explizit benannt.
DSC Ressourcen sollen, wenn vorhanden, nach dem bestehenden Modul benannt werden oder das „Dsc“ Suffix erhalten.

Damit diese Änderung bestehende Umgebungen nicht stört, wird die PowerShell Gallery eine Historie der Namen pflegen und somit die Ressourcen auch unter dem alten Namen verfügbar machen.

Azure AD Sync – Höchstwert für Objektlöschungen bei der Identitätssynchronisierung erreicht

Hallo fabian.bader@company.com,

am Donnerstag, 20 Dezember 2017 10:07:51 GMT hat der Dienst für die Identitätssynchronisierung festgestellt, dass die Anzahl von Löschvorgängen den für [company.onMicrosoft.com] konfigurierten Schwellenwert überschritten hat. Es wurden insgesamt 551 Objekte bei dieser Ausführung der Identitätssynchronisierung zum Löschen gesendet. Dies entspricht dem konfigurierten Schwellenwert für Löschungen von 500 Objekten bzw. überschreitet ihn.

Sie müssen vor dem Fortfahren bestätigen, dass diese Löschvorgänge durchgeführt werden sollen.
Weitere Informationen zu dem in dieser E-Mail-Nachricht genannten Fehler finden Sie unter Verhindern von zufälligem Löschen.
Vielen Dank!

Ihr Azure Active Directory-Team

Wer eine solche E-Mail das erste Mail erhält fragt sich was jetzt zu tun ist.

Weiterlesen

PowerShell Core 6 RC 2

Mit PowerShell Core Release Candidate 2 ist der letzte Meilenstein vor dem FInalen Release geschafft.

Also schnell die Version herunterladen und auf Herz und Nieren testen.

Zwei wichtige Änderungen, die das bisherige Standardverhalten ändern:

  • Wenn die Execution Policy auf „AllSigned“ steht, müssen auch Skripte unter $PSHome signiert sein (#5511)
  • Bei Parametern wird die Prüfung ValidateNotNull und ValidateNotNullOrEmpty  ausgesetzt wenn der übergebene Wert ein Value Type ist (#5432)

Die kompletten Release Notes findet Ihr hier