Manjaro schwarzer Bildschirm nach Update

Großes Update mit 98 Paketen – inklusive Linux Kernel, nach Reboot direkt nach GRUB (ESC nicht probiert) schwarzer Schirm (aber Signal, Bildschirm schaltet nicht ab).

Grund: Linux Kernel bzw. INITRAMFS offenbar nicht richtig erzeugt.

Lösung:

Mit Live Stick booten

sudo su -
manjaro-chroot -a
pacman -Q|grep linux
pacman -S linuxXXX

CTRL+D um chroot zu beenden

reboot

System.Data.SqlClient Koexistenz .NET 4.x und .NET Core 3+/.NET 5+

Hat man ein .NET Core/.NET 5+ Projekt welches eine .NET 4.x Library verwendet die wiederum System.Data.SqlClient (SqlConnection, SqlTransaction, etc.) verwendet läuft man in diese beiden Fehler (hier von einem F# Web API Projekt):

FS1108 The type 'SqlConnection' is required here and is unavailable. You must add a reference to assembly 'System.Data.SqlClient, Version=0.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.
FS1109 A reference to the type 'System.Data.SqlClient.SqlConnection' in assembly 'System.Data' was found, but the type could not be found in that assembly

Gerne wird im Internetz dann darauf verwiesen dass .NET Core/.NET 5+ System.Data.SqlClient nicht mehr per Default referenziert und man doch das gleichnamige Nuget installieren solle – nur hilft das halt nur wenn man z.B. eine alte .NET Framework Anwendung auf .NET Core/.NET 5+ bringt; beim Referenzierungsfall (.NET neu referenziert .NET alt) bringt das nichts.

Dort ist dann sowohl das alte als auch das neue Projekt auf das neue Nuget Microsoft.Data.SqlClient umzustellen – liefert die gleichen Klassen und funktionieren dann auch in beiden Welten – das “alte” .NET 4.x Projekt muss dafür aber (aktuell) auf Minimum .NET 4.6.1 sein.

Also Nuget installieren und die usings/opens von System.Data.SqlClient auf Microsoft.DataSqlClient umstellen – fertig.

Referenz: https://devblogs.microsoft.com/dotnet/introducing-the-new-microsoftdatasqlclient/

Powershell Prompt mit Timestamp

Über Function “prompt” – in $PSHome\Profile.ps1 (alle User) oder $Home\Documents\WindowsPowershell\Profile.ps1 (aktueller User) gepackt für automatische Aktivierung:

function prompt { return "[$([System.DateTime]::Now.ToString("yyyy-MM-dd HH:mm:ss"))] $(Get-Location)> "}

Wenn man in einem constrained environment arbeitet und/oder Profile unterbunden werden kann man auch powershell direkt damit starten:

PowerShell -noexit -command "function prompt { return '['+[System.DateTime]::Now.ToString('yyyy-MM-dd HH:mm:ss')+']'+ (Get-Location)+'> '}"

Visual Studio: Signatur des Targets

In den Project Properties unter “Build Events” eine Post-build event command line einfügen:

"c:\Program Files (x86)\Windows Kits\10\bin\10.0.19041.0\x64\signtool.exe" sign /v /sha1 "<sha1 thumbprint vom zertifikat>" /fd "SHA256" /tr http://rfc3161timestamp.globalsign.com/advanced /td "SHA256" $(TargetPath)

Signtool Pfad ist natürlich abhängig von den lokalen Gegebenheiten, ebenso kann man sich anderen Timestampservice aussuchen.

Igel UMS: TCs ohne fixierten DNS Hostnamen finden

Igel TCs melden sich per Default als ITC<macadresse> im Management wenn man ihnen nicht per DHCP oder eben statisch im Management einen Namen gibt – wenn man zwischen DHCP mit Option 12 (Hostname) und DHCP ohne Option 12 wechselt funktioniert der Wechsel nicht immer. Mit dieser Query findet man alle TCs in einem (oder mehreren) TC-Verzeichnissen:

select tc.tcname,tc.network_name,tc.macaddress,tc.movedtobin
from thinclient as tc
where tc.tcid in
   (select td.tcid
    from thinclientisindirectory as td
    where dirid in
       (select d.dirid from directories as d where d.name like '%MyDirectory%')
   )
and (select count(*) from thinclientsettings as tcs where tcs.tcid=tc.tcid and tcs.classname='network.dns.hostname') = 0

Umgekehrt kann man hiermit die konfigurierten DNS Namen rausfinden:

select tc.tcname,tc.network_name,tc.macaddress,tc.movedtobin
from thinclient as tc
where tc.tcid in
   (select td.tcid
    from thinclientisindirectory as td
    where dirid in
       (select d.dirid from directories as d where d.name like '%MyDirectory%')
   )
and (select count(*) from thinclientsettings as tcs where tcs.tcid=tc.tcid and tcs.classname='network.dns.hostname') = 0

SQL Server Express TCP abdrehen

Rausfinden:

$cn="mysqlexpress";(gwmi -ComputerName $cn -Namespace "root\microsoft\sqlserver\$((gwmi -ComputerName $cn -Namespace "root\microsoft\sqlserver" -Query "select * from __NAMESPACE where Name like 'ComputerManagement%'").Name)" -Query "select * from ServerNetworkProtocol where ProtocolName='Tcp'").Enabled

Abdrehen:

$cn="mysqlexpress"; iwmi -InputObject (gwmi -ComputerName $cn -Namespace "root\microsoft\sqlserver\$((gwmi -ComputerName $cn -Namespace "root\microsoft\sqlserver" -Query "select * from __NAMESPACE where Name like 'ComputerManagement%'").Name)" -Query "select * from ServerNetworkProtocol where ProtocolName='Tcp'") -Name "SetDisable"

(geht davon aus dass nur eine Version vom SQL Server installiert ist – sollten es mehr sein muss man halt ein ForEach-Object einbauen)

Digitale Signatur mit Powershell

Weil nicht alle Timestampdienstleister mit Powershell funktionieren und ich es leid bin dauern einzufahren:

Set-AuthenticodeSignature -Certificate (gci cert:currentuser\my -CodeSigningCert) -TimestampServer http://timestamp.sectigo.com ...myfile...

(geht natürlich davon aus dass im Userzertifikatsstore genau ein Code Signing Zertifikat liegt)

Neuer CNAME Registrykey

Als wären notwendige SPNs, DisableStrictNameChecking, DisableLoopbackCheck, BackConnectionHostnames nicht schon genug gibts (eh schon seit 2010…) noch einen weiteren Wert der helfen könnte:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\SrvAllowedServerNames

Ein REG_MULTI_SZ wo man dann die gewünschten CNAMES reinschreibt.

Hier beschrieben (u.a.): Description of the update that implements Extended Protection for Authentication in the Server service (microsoft.com)

Rerun Advertisement Powershell Oneliner

([wmiclass]"\\$computername\root\ccm:SMS_Client").TriggerSchedule(((gwmi -computername $computername -namespace root\ccm\policy\machine\actualconf
ig -query "select * from ccm_scheduler_scheduledmessage where ScheduledMessageID like '%$advertisementid_or_packageid%'").ScheduledMessageID))   

Wenn das nicht hilft hat der Client für sich beschlossen dass er/sie/es das schon zur Zufriedenheit Aller nach bestem Wissen und Gewissen erledigt hat dann hilft das hier (dafür muss das Deployment aber auf “Always rerun”) stehen!) – anschließend MachinePol triggern oder CCMEXEC restarten um Rerun zu beschleunigen:

gwmi -Computername $computername -Namespace root\ccm\Scheduler -Query "select * from ccm_scheduler_history where ScheduleID like '%$advertisementid_or_packageid%'"|Remove-WmiObject

Geklaut von hier bzw. hier.