Windows: “Autoconfiguration IPv4 Address”

Wenn ich (hier in Windows Server 2016) manuell eine statische IP konfiguriere, würde ich davon ausgehen, dass die dann auch verwendet wird. Spoiler: Wird sie nicht. Sie erscheint zwar in ipconfig /all, aber eine weitere “Autoconfiguration IPv4 Address” wird als “(Preferred)” markiert. Das “W” in WTF steht für Windows 🙄

Nun habe ich keine Ahnung, was der Grund (oder der Sinn) davon ist, und es ist mir auch egal. So deaktiviert man es:

netsh interface ipv4 show inter
netsh interface ipv4 set interface <id> dadtransmits=0 store=persistent

1 2	netsh interface ipv4 show inter netsh interface ipv4 set interface <id> dadtransmits=0 store=persistent

mit <id> gleich der Nummer des gewünschten Adapters, wie sie der erste Befehl ausgibt. Eventuell deaktiviere man danach den DHCP Client Service, es sollte aber auch so gehen – und letzteres brachte bei mir andere Probleme mit sich; auf diesen Service verlassen sich doch einige weitere.

Quelle

WiX: Install features options

Das Feature-Element hat einige UI-relevante Attribute, die nicht selbsterklärend sind:

Absent='disallow' schaltet “The feature will not be installed” aus – wie man für mandatorische Features das Dropdown insgesamt deaktiviert, weiß ich nicht. Ja, man kann das ganze Feature verstecken (Display='hidden'), aber nicht nur das Dropdown 🤷🏻‍♂️
AllowAdvertise='no' schaltet “The feature will be installed when needed” aus
“The feature and all of its subfeatures will be installed locally” (in früheren Versionen auch “Entire feature will be installed on local hard drive”) kann laut Internet nicht entfernt werden… andere Quellen legen nahe, dass man das über die Subfeatures und Komponenten steuert, aber ich hatte damit keinen Erfolg.

PowerShell: Zertifikatsprüfung deaktivieren

Add-Type @"
    using System.Net;
    using System.Security.Cryptography.X509Certificates;
    public class TrustAllCertsPolicy : ICertificatePolicy {
        public bool CheckValidationResult(
            ServicePoint srvPoint, X509Certificate certificate,
            WebRequest request, int certificateProblem) {
            return true;
        }
    }
"@
[System.Net.ServicePointManager]::CertificatePolicy = New-Object TrustAllCertsPolicy
Invoke-WebRequest 'https://127.0.0.1:8444/my/endpoint' -OutFile 'c:\response.json'

Add-Type @"

using System.Net;

using System.Security.Cryptography.X509Certificates;

public class TrustAllCertsPolicy : ICertificatePolicy {

public bool CheckValidationResult(

ServicePoint srvPoint, X509Certificate certificate,

WebRequest request, int certificateProblem) {

return true;

}

[System.Net.ServicePointManager]::CertificatePolicy = New-Object TrustAllCertsPolicy

Invoke-WebRequest 'https://127.0.0.1:8444/my/endpoint' -OutFile 'c:\response.json'

via. PS, in einem Vagrantfile so zu escapen – man beachte auch die Einrückungen:

  config.vm.provision "disable cert validation callback", type: "shell", inline: <<-SHELL
Add-Type @"
  ...
"@
[System.Net.ServicePointManager]::CertificatePolicy = New-Object TrustAllCertsPolicy
Invoke-WebRequest 'https://127.0.0.1:8444/my/endpoint' -OutFile 'c:\\response.json'
  SHELL

config.vm.provision "disable cert validation callback", type: "shell", inline: <<-SHELL

Add-Type @"

...

[System.Net.ServicePointManager]::CertificatePolicy = New-Object TrustAllCertsPolicy

Invoke-WebRequest 'https://127.0.0.1:8444/my/endpoint' -OutFile 'c:\\response.json'

SHELL

HTH

Windows Server Updates hinter einem Proxy

Wenn Windows Server 2016^* immer 0% Fortschritt anzeigt, dann kann man davon ausgehen, dass er nix runterlädt. Auch wenn die Liste der noch verfügbaren Updates sich dabei ständig ändert 🙄

Lösung: Offenbar laufen Windows Updates über “WinHTTP“, und selbstverständlich hat WinHTTP seine eigenen Proxy-Einstellungen. Man kann in einer Admin-Shell aber die IE-Einstellungen importieren:

netsh winhttp import proxy source=ie

1	netsh winhttp import proxy source=ie

, danach neu starten, klar. Den Rechner oder nur den Service (per PowerShell):

Restart-service wuauserv

1	Restart-service wuauserv

Ein

netsh winhttp show proxy

1	netsh winhttp show proxy

sollte dann die importierten Proxyeinstellungen zeigen.

^*Update: Bei Windows Server 2012 stellt sich das Problem so dar, dass er gar nicht erst Updates findet. Die Lösung ist aber dieselbe.

Windows: %PATH% überschreiben

Angenommen, ich möchte JAVA_HOME setzen und %PATH% um %JAVA_HOME%/bin ergänzen, habe aber keine Adminrechte. JAVA_HOME kann ich setzen, das überschreibt ggf. gesetzte globale Variablen mit demselben Namen. Aber ein User-PATH wird hinter den globalen PATH gehängt, und überschreibt dadurch nix.

Lösung (nur für die CMD!):

Definiere eine .bat, die mit jeder neuen DOS-Box ausgeführt wird:

reg add "HKCU\Software\Microsoft\Command Processor" /v AutoRun ^ /t REG_EXPAND_SZ /d "%"USERPROFILE"%\init.cmd" /f

1
2

reg add "HKCU\Software\Microsoft\Command Processor" /v AutoRun ^
/t REG_EXPAND_SZ /d "%"USERPROFILE"%\init.cmd" /f
Füge die entsprechenden Settings ein (hier: setze den globalen %PATH% hinter meinen):

SET JAVA_HOME=C:\jdk-11.0.2+7-jre SET PATH=%JAVA_HOME%\bin;%PATH%

1
2

SET JAVA_HOME=C:\jdk-11.0.2+7-jre
SET PATH=%JAVA_HOME%\bin;%PATH%

WiX: Upgrade Pitfalls

Art des Upgrades

tl;dr: MajorUpgrade ab der initialen Version!

Folgendes Szenario: Ich baue mit WiX einen MSI-Installer für meine Software. Die Software hat die Version 1.0. Nun möchte ich meine Software auf v1.1 upgraden. Was tun?

WiX bietet mehrere Möglichkeiten, namentlich “Major Upgrades”, “Minor Upgrades”, sowie “Small Updates”, die sich ungefähr so definieren:

Small Updates: Quasi ein Patch vorhandener Files, erfordert nicht (zwingend?) eine Änderung der Versionsnummer
Minor Upgrade: Aktualisiert bestehende Files ohne die vorhandene Software zu deinstallieren. Kann aber Features oder Komponenten hinzufügen. Erfordert neue (=höhere) Versionsnummer
Major Upgrade: “Deinstalliert das Produkt und installiert es neu”, erfordert neue (=höhere) Versionsummer und eine neue Product.Id (Achtung: Product.UpgradeCode “bleibt immer unverändert”)

Liest sich, als würde man meistens ein Minor Upgrade wollen. Internet sagt allerdings das Gegenteil, die Literatur^* sieht Major Upgrades als “easier to implement than any other option” an, und last but not least empfiehlt WiX selbst:

When creating an .msi-based installer, you are strongly encouraged to include logic that supports Windows Installer major upgrades.

Was dabei nie so richtig, richtig klar wird (teilweise wird implizit das Gegenteil angedeutet): Beinhaltet nicht bereits Version 1.0 MajorUpgrade (sondern bspw. erst das erste Upgrade), dann funktioniert quasi nichts:

v1.1 wird nicht als Update erkannt, sondern parallel installiert!
Conditions funktionieren deshalb ebenfalls nicht wie erwartet, es gilt der Pfad wie bei Erstinstallation
Downgrades werden nicht verhindert, weil ja beides parallel installiert wird
…
In anderen Worten: Eine Installation, deren Installer nicht MajorUpgrade enthielt, wird von Upgrade/Downgrade-Logik komplett ignoriert!

Warum das dann nicht mandatorisch ist, wird wohl Microsofts Geheimnis bleiben.

^*Nick Ramirez, “WiX 3.6: A Developer’s Guide to Windows Installer XML”, Seite 342

“Scheduling”

Per default deinstalliert ein MajorUpgrade die alte Version und installiert dann die neue. Das kann problematisch sein, denn ein Upgrade (engl. für “Verbesserung”, “Aufrüstung”!) sollte ja bspw. Konfigurationsdaten usw. behalten. Da hilft das Scheduling-Attribut:

<MajorUpgrade Schedule="afterInstallExecute" DowngradeErrorMessage="A newer version of [ProductName] is already installed."/>

1	<MajorUpgrade Schedule="afterInstallExecute" DowngradeErrorMessage="A newer version of [ProductName] is already installed."/>

sorgt dafür, dass bestehende Dateien (und in diesem Fall auch Services) erhalten bleiben. Es wird quasi definiert, wann das bestehende Produkt entfernt werden soll, und afterInstallExecute sagt “nach der Installation des Upgrades” – natürlich wird dann nur noch entfernt, was in v1.1 nicht mehr benötigt wird.

Achtung: Das setzt offenbar die Erkennung außer Kraft, die eine Neuinstallation derselben Version verhindert 🙄

Conditions

Bestimmte Schritte des Installers sollen nur bei Erstinstallation ausgeführt werden (etwa die Konfiguration durch den User, die Installation eines Services, …). Dafür gibt es Conditions, bzw. verschiedene States, auf die man prüfen kann – und das ist ziemlich unübersichtlich. Ich beschränke mich an dieser Stelle auf einen Stackoverflow-Post, der gute, sprechende Aliase definiert:

<SetProperty After="FindRelatedProducts" Id="FirstInstall" Value="true">
  NOT Installed AND NOT WIX_UPGRADE_DETECTED AND NOT WIX_DOWNGRADE_DETECTED
</SetProperty>
<SetProperty After="SetFirstInstall" Id="Upgrading" Value="true">
  WIX_UPGRADE_DETECTED AND NOT (REMOVE="ALL")
</SetProperty>
<SetProperty After="RemoveExistingProducts" Id="RemovingForUpgrade" Sequence="execute" Value="true">
  (REMOVE="ALL") AND UPGRADINGPRODUCTCODE
</SetProperty>
<SetProperty After="SetUpgrading" Id="Uninstalling" Value="true">
  Installed AND (REMOVE="ALL") AND NOT (WIX_UPGRADE_DETECTED OR UPGRADINGPRODUCTCODE)
</SetProperty>
<SetProperty After="SetUninstalling" Id="Maintenance" Value="true">
  Installed AND NOT Upgrading AND NOT Uninstalling AND NOT UPGRADINGPRODUCTCODE
</SetProperty>

NOT Installed AND NOT WIX_UPGRADE_DETECTED AND NOT WIX_DOWNGRADE_DETECTED

</SetProperty>

WIX_UPGRADE_DETECTED AND NOT (REMOVE="ALL")

</SetProperty>

(REMOVE="ALL") AND UPGRADINGPRODUCTCODE

</SetProperty>

Installed AND (REMOVE="ALL") AND NOT (WIX_UPGRADE_DETECTED OR UPGRADINGPRODUCTCODE)

</SetProperty>

Installed AND NOT Upgrading AND NOT Uninstalling AND NOT UPGRADINGPRODUCTCODE

</SetProperty>

Update

Ein Kind von Component sollte immer KeyPath="yes" gesetzt bekommen. Selbst, wenn es nur ein Kind gibt, aber insbesondere bei mehreren. Daran wird entscheiden, welches die maßgebliche Datei ist, die vorhanden (und aktuell) sein muss, um “muss (re-)installiert werden” zu entscheiden.

Windows: Iteriere alle Dateien mit derselben Endung

@ECHO OFF

ECHO Looking for *.xml files...
SET /a count=0
FOR /F "delims=" %%i IN ('dir/s/b/a-d ".\*.xml"') DO (
  ECHO Processing %%i
  SET /a count=count+1
)
ECHO Processed %count% files

PAUSE

@ECHO OFF

ECHO Looking for *.xml files...

SET /a count=0

FOR /F "delims=" %%i IN ('dir/s/b/a-d ".\*.xml"') DO (

ECHO Processing %%i

SET /a count=count+1

)

ECHO Processed %count% files

PAUSE

Windows: Synchrones Starten von Services

Nachdem ich mich neulich über sc gefreut habe: net ist cooler. Während

sc start HelloWorld.exe

1	sc start HelloWorld.exe

meinetwegen auch über’s Netzwerk möglich ist, wartet

net start HelloWorld.exe

1	net start HelloWorld.exe

dafür, bis der Service auch läuft. Und, mal ehrlich, in einem Skript ist das das deutlich häufiger benötigte. Und so spart man sich nerviges Drumherumgebastel.

Windows: Einen Service deinstallieren

Postgres deinstalliert, aber der Service ist noch da?

> sc delete postgres

1	> sc delete postgres

(In einer DOS-Box mit Admin-Rechten)

Danke, Nils

Missing vcruntime140.dll / vcruntime140d.dll

Deine Visual Studio Anwendung beschwert sich über eine fehlende vcruntime140d.dll? Das “d” steht für debug, bitte als “Release”-Version kompilieren.

Deine Visual Studio Anwendung beschwert sich (nun) über eine fehlende vcruntime140.dll? Dann bitte das aktuelle Microsoft Visual C++ Redistributable Package installieren. Achtung: Ob x64 oder x86 entscheidet sich nicht an der Systemarchitektur, sondern an der Programm-Version! Also: Win32-Anwendung läuft nicht -> x86-Package installieren.

hth

crusy.net

♪ Commit ins Abenteuerland ♫

Tag Archives for Windows

Windows: “Autoconfiguration IPv4 Address”

WiX: Install features options

PowerShell: Zertifikatsprüfung deaktivieren

Windows Server Updates hinter einem Proxy

Windows: %PATH% überschreiben

WiX: Upgrade Pitfalls

Art des Upgrades

“Scheduling”

Conditions

Update

Windows: Iteriere alle Dateien mit derselben Endung

Windows: Synchrones Starten von Services

Windows: Einen Service deinstallieren

Missing vcruntime140.dll / vcruntime140d.dll