.NET 4.0 Bug: RegDeleteKeyEx remote auf XP

Im .NET Framework 4.0 führt Microsoft.Win32.RegistryKey.DeleteSubKeyTree() remote gegen einen XP Rechner geschossen zu einer netten Exception “The procedure number is out of range.”.
Grund: Die Win32 Funktion RegDeleteKeyEx() wird erst ab Vista in advapi32.dll unterstützt (MSDN-Thread).
Workaround: Selber rekursiv löschen, Beispiel:
      [DllImport("advapi32.dll", EntryPoint = "RegDeleteKey", SetLastError = true)]
      public static extern int RegDeleteKey(IntPtr hKey, string sSubKey);

      public static int RecurseDeleteKey(RegistryKey oKey, string sKey)
      {
         int nStatus;
         RegistryKey oSubKey;

         oSubKey = oKey.OpenSubKey(sKey);
         foreach (string sSubKey in oSubKey.GetSubKeyNames())
         {
            if ((nStatus = RecurseDeleteKey(oSubKey, sSubKey)) != 0)
            {
               try { oSubKey.Close(); } catch (Exception) { }
               return nStatus;
            }
         }
         nStatus = RegDeleteKey(oKey.Handle.DangerousGetHandle(), sKey);
         try { oSubKey.Close(); } catch (Exception) { }
         return nStatus;
      }


WDS Discover Image ohne DHCP

Das Problem: Rechner ohne DHCP soll mit WDS beatmet werden. Das Discover-Image besteht aber auf DHCP, findet der Rechner keine Adresse kommt Fehler – macht man in der Zwischenzeit SHIFT+F10 und netsh Interface ip set address "<Verbindungsname, z.B. LAN-Verbindung>" static <Adresse> <Subnet> <Gateway> hat man zwar eine superdolle statische Adresse aber sobald man den Fehler vom Setup wegklickt fährt die Gurke runter, ein Parallelstart von Setup.exe funktioniert auch nicht da das Zeug offensichtlich prüft ob es schon läuft 🙁

Im TechNet ist recht gut beschrieben wie man ein Custom Image macht:

  • Discover-WIM mounten
  • WindowsSystem32Winpeshl.ini editieren, z.B. das Setup rausnehmen und %systemroot%Windowssystem32cmd.exe oder irgendeine Custom-GUI, Script, whatever reingeben
  • WIM committen und in ISO, auf Stick, wherever geben
  • Damit booten, mit WPEUTIL InitializeNetwork Netzwerk starten
  • mit dem o.a. NETSH Kommando statische Adresse vergeben
  • mit %systemroot%SourcesSetup.exe /wds /wdsdiscover /wdsserver:whatever das discovery starten (/wdsserver ist optional)

PortUsers

Wer schon immer (filterbar) wissen wollte welches Programm in welcher Sitzung (Terminalserver) von welchem Rechner (Terminalserver) mit welchem User auf welche Ports auf welchen Zielen zugreift: PortUsers kann das 😀

RemoteApps und das Logoff-Problem

Selbst wenn man alle Möglichkeiten wie

  • tsconfig.msc/RDP-Tcp/Sitzungen/Wenn das Sitzungslimit erreicht oder die Verbindung getrennt wurde: Sitzung beenden
  • lokale Policy: Computereinstellungen/Adm.Vorlagen/Remotedesktopdienste/Remotedesktopsitzungs-Host/Sitzungslimits/Zeitlimit für die Abmeldung bei RemoteApp-Sitzungen festlegen (aktiviert/sofort)

ausnutzt passiert es immer wieder dass Sessions im disconnected Status (wenn auch nur für kurze Zeit) herum lungern. Wenn man nun viele Sessions mit einem Benutzer betreibt und ein Reconnect verhindern will ist man an dieser Stelle ziemlich *zensur*.

Zum Glück gibt es WTSRegisterSessionNotification, damit kann man sein Interesse an Änderungen des Sessionstatus bekannt geben – und wenn die Session disconnected wird kann man dann einfach ein Logoff anwerfen. Das Tool dazu: WTSLogoffOnDisconnect. Einmal in die Session gestartet (z.B. über lokale Police/Benutzereinstellungen/Windows-Einstellungen/Scripts/Anmelden, Run-Key wird ja für RemoteApp mangels Explorer nicht ausgewertet) führt es ein Logoff durch sobald die Sitzung getrennt wird. %ProgramData%ROMGAL muss dafür existieren und für alle in Frage kommenden Benutzer beschreibbar sein – da kommt das Logfile rein.

Alle Wege führen zur RemoteApp

RemotePrograms.msc kennt ja jeder, weiß jetzt grad nicht ob sie das wegen des großen Erfolges so wie z.B. tsadmin.msc im Windows Server 2012 entsorgt haben.

Die die sich mit dem Thema schon mal befasst haben sind vermutlich auch schon über die WMI Klasse Win32_TSPublishedApplication gestolpert.

Im Rahmen eines Calls hat mir ein MS Supportler auch noch den wertvollen Tipp gegeben dass man doch auch mit den 2008R2 Tools remote arbeiten kann 😎

Neu war mir die zufällig gefundene Methode über den RDS-Provider in der Kraftmuschel.

Da das aber remote eher anstrengend, fehleranfällig und maximal unperformant ist habe ich mal auf Verdacht die Registry eines Terminalservers durchsucht und bin auf den Key HKLMSoftwareMicrosoftWindows NTCurrentVersionTerminal ServerTSAppAllowListApplications gestoßen. Im Endeffekt sind die ganzen anderen Methoden nichts anderes als Editoren für diesen Key und seine Subkeys (=RemoteApps). Die Werte Name und Path sind minimal notwendig, den Rest kann man ja via “Editor” erzeugen und rausfinden was welche Bedeutung hat 😀

Java CRL Checks einschalten

Wie wir heute gelernt haben prüft Java Zertifikate per Default nicht auf Revocation (CRL oder OCSP).

Abhilfe über Loginscript: AppData/Local AppData ermitteln (SpecialFolders oder HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionExplorerUser Shell FoldersLocalAppData, siehe auch unten) und dort eine Datei deployment.properties mit folgendem Inhalt erstellen/hin kopieren:

# Allow user to grant permissions to signed content (true by default)
deployment.security.askgrantdialog.show=true
# Allow user to grant permissions to content from an untrusted authority (true by default)
deployment.security.askgrantdialog.notinca=false
# Check publisher certificate for revocation (false by default)
deployment.security.validation.crl=true
# Enable online certificate validation (false by default)
deployment.security.validation.ocsp=true
Quelle

Vorsicht XP/2003 und Vista/7/8/2008/2008R2/2012 verhalten sich hier scheinbar unterschiedlich – bzw. tun dies auch verschiedene Java Versionen – sodass die Datei manchmal im Roaming Teil von AppData gesucht wird und manchmal im LocalLow Bereich (für den es weder einen SpecialFolder noch einen Registrykey gibt – ich hänge einfach “Low” and den bei LocalAppData ermittelten Pfad an). Einfach überall hinkopieren und man ist vor Überraschungen gefeit 😀

Tools

GARCopy – das Ding mit dem man (wenn man Administrator ist und es auch elevated startet) unabhängig von ACLs im Backupkontext Dinge kopieren kann.

GARDirSize – das Ding mit dem man (wenn man Administrator ist und es auch elevated startet) unabhängig von ACLs die Größe (Anzahl der Dateien+Bytes) eines Verzeichnisses ermitteln kann.

GARDelete – das Ding mit dem man (wenn man Administrator ist und es auch elevated startet) unabhängig von ACLs Verzeichnisse löschen kann.

IIS >= 6.0, ASP.NET und VMware.VimClient

Wie ich eben lernen musste kommt VMware.VimClient (Teil von Power CLI) ab 2003/IIS6 nicht mit den dort limitierten Stack von 256 KB (KB932909) zurecht.

Man kann das aber umgehen in dem man einen Thread mit entsprechendem Stack startet:


public void SomeHandler(object sender,EventArgs e)
{
Thread oWorker=new Thread(new ParameterizedThreadStart(SomeHandlerWorker),1024*1024*4); // 4 MB Stack
oWorker.Start(e);
oWorker.Join();
}
public void SomeHandlerWorker(object oPar)
{
EventArgs e=(EventArgs)oPar;

// do something great
}