Volle Kontrolle über DRIVESTOREDIRECT

Mit RDP 7.0 hat Microsoft ja beschlossen gaaaanz schlau zu sein und im RDP-File Parameter DRIVESTOREDIRECT nicht mehr nur einfach die Laufwerksbuchstaben die man gerne in die Session mappen würde zuzulassen sondern da muss man echt das eintragen was der Explodierer zum Zeitpunkt des Verbindungsaufbaus (wie das Teil nachher heißt ist vollkommen schnurz….) anzeigt, also z.B. „CD-Laufwerk (D:)“ – da das naturgemäß ein brutal bewegliches Ziel ist (Sprache, Typen, Volumenamen, Laufwerksbuchstabe vorne/hinten, etc.) kann man das nicht wirklich hardcoden und ist damit aufgeschmissen…..gäbe es in der SHELL32.DLL nicht die Funktion SHGetFileInfo() die uns genau das liefert was wir wollen (DisplayName in der SHFILEINFO Struktur die da befüllt wird), hier ein Beispielprogramm dass alle Laufwerke auflistet:

using System;
using System.Runtime.InteropServices;

namespace GetVolumeLabel
{
   [StructLayout(LayoutKind.Sequential)]
   public struct SHFILEINFO
   {
      public IntPtr Icon;
      public int IconIndex;
      public uint Attributes;
      [MarshalAs(UnmanagedType.ByValTStr, SizeConst = 260)]
      public string DisplayName;
      [MarshalAs(UnmanagedType.ByValTStr, SizeConst = 80)]
      public string TypeName;
   };

   class Program
   {
      public const uint SHGFI_DISPLAYNAME = 0x200;

      [DllImport("shell32.dll")]
      public static extern IntPtr SHGetFileInfo(string Path, uint FileAttributes, ref SHFILEINFO Info, uint Size, uint Flags);

      static void Main(string[] args)
      {
         SHFILEINFO oInfo;
         IntPtr oRes;

         for (char cDrive = 'A'; cDrive <= 'Z'; cDrive++ )
         {
            oInfo =  new SHFILEINFO();
            oRes = SHGetFileInfo(cDrive + ":\\", 0, ref oInfo, (uint)Marshal.SizeOf(oInfo), SHGFI_DISPLAYNAME);
            Console.WriteLine(cDrive + ":\\ = '" + oInfo.DisplayName + "'");
         }

      }
   }
}

REMOTEPROGRAMS für Windows Server 2012/2012 R2 revisited: MSI Erzeugung

Ich wurde darauf aufmerksam gemacht dass meine REMOTEPROGRAMS Lösung nicht ganz funktioniert – die Erzeugung von MSI Pakete scheitert (was mir nicht aufgefallen ist weil ich das Feature nicht verwende); die Lösung ist aber recht einfach (wiederum von 2008 R2 auf 2012/2012 R2 importieren/kopieren):

  • Registrykey HKEY_CLASSES_ROOT\CLSID\{31A2EA80-A9A3-40E5-9B16-20D7D855E55F}
  • rapmsign.dll (System32)

REMOTEPROGRAMS für Windows Server 2012/2012 R2

Nach TSADMIN und TSCONFIG fehlt nur mehr REMOTEPROGRAMS um den RDSH Admin der den MS Weg nicht mitgehen will glücklich zu machen:

  • PublishingWIzard.dll (System32) kopieren
  • de-DE/PublishingWizard.dll.mui (System32) kopieren
  • PublishSnapIn.dll (System32) kopieren
  • de/PublishSnapIn.resources.dll (System32) kopieren
  • remoteprograms.msc (System32) kopieren
  • Registrykeys von 2008 R2 exportieren und auf 2012 (R2) importieren:
    • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MMC\SnapIns\FX:{fc2a784c-94da-4493-abe4-f7f9dc25d16f}
  • Spaß haben 😀

TSCONFIG für Windows Server 2012/2012 R2

Wie TSADMIN kann man auch TSCONFIG von Windows Server 2008 R2 auf 2012/2012 R2 (es gibt ja keine Abhängigkeit zur Remote Control Funktionalität wie bei 2012) „portieren“:

  • tsconfig.dll (System32) kopieren
  • de/tsconfig.resources.dll (System32) kopieren
  • tsconfig.msc (System32) kopieren und alle Elemente die FX:{48128E8C-DFEA-4722-BD00-9D39C3B371F9} enthalten entfernen (TS Licensing Diagnostics, machen Probleme)
  • Registrykeys von 2008 R2 exportieren und auf 2012 (R2) importieren:
    • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MMC\SnapIns\FX:{80aaa290-abd9-9239-7a2d-cf4f67e42128}
    • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MMC\SnapIns\{9910DD01-DF8C-11D1-AE27-00C04FA35813}
    • HKEY_CLASSES_ROOT\CLSID\{9910dd01-df8c-11d1-ae27-00c04fa35813}
    • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MMC\NodeTypes\{F86E6446-AAFF-11D0-B944-00C04FD8D5B9}
    • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MMC\SnapIns\{9910DD01-DF8C-11D1-AE27-00C04FA35813}
  • Spaß haben 😀

TSADMIN für RDSH mit Windows Server 2012 R2

Wie ich schon mal geschrieben habe ist das TSADMIN MMC Snapin eines der FX (.NET) Gattung und kann damit angepasst werden (natürlich höchst unsupported und vermutlich sogar böse). Wie ich auch schon mal geschrieben habe sind altbekannte Weggefährten wie eben TSADMIN.MSC aber auch TSCONFIG.MSC und REMOTEPROGRAMS.MSC ab Windows Server 2012 nicht mehr enthalten weil Microsoft glaubt mit ihrer neuen ServerManager-zentrierten RDSH Methodik (die wo man auch für einen Single-Terminalserver einen Broker mit DB und allen drum und dran braucht…..) tun sie dem Kunden etwas unglaublich Gutes – mit der TSADMIN-Methodik habe ich durch winzige Anpassungen in TSManagerForm.RemoteControlSession (Entfernung des RemoteControlDialog wo die Tastenkombination für RemoteControl-Ende konfiguriert werden konnten) und TerminalServer.RemoteControl(Änderung von TSManager.WTSStartRemoteControlSession() auf System.Diagnostics.Process.Start(new System.Diagnostics.ProcessStartInfo(„mstsc“, „/shadow:“ + sessionID + “ /v:“ + targetServerName + “ /control“));) in die 2012 R2 Welt bringen können.

Die nächsten auf der Liste sind dann TSCONFIG.MSC und REMOTEPROGRAMS.MSC 😀

CTL Update endet in CAPI2 Event 4101

Fehler bei der automatischen Aktualisierung des Drittanbieterstammzertifikats von http://ctldl.windowsupdate.com/msdownload/update/v3/static/trustedr/en/irgendeinenummer.crt. Fehler: Die Vorgangskennung ist ungültig. (alternativ auch mit Diese Netzwerkverbindung ist nicht vorhanden. am Ende) – und das regelmäßig. Über KB2813430 (wo übrigens auch steht wie man das local verteilen könnte) bin ich auf den Key HKLM/SOFTWARE/Microsoft/SystemCertificates/AuthRoot gestoßen – und musste feststellen dass die ACL scheinbar beschädigt wurde (NT SERVICECryptSvc hat gefehlt). Da man entgegen diverser Artikel im Registry ACL GUI NT SERVICECryptSvc nicht verwenden kann (auch die SID geht nicht) habe ich das Problem mit der Kraftmuschel gelöst:

CD HKLM:
CD SOFTWAREMicrosoftSystemCertificatesAuthRoot
$acl=get-acl
$ace=new-object System.Security.AccessControl.RegistryAccessRule("NT SERVICECryptSvc", "FullControl", "ContainerInherit", "None", "Allow")
$acl.SetAccessRule($ace)
$acl|set-acl

Disk Configuration für Unattended Windows 8 Setup mit (U)EFI

Nach vielen (fruchtlosen) Versuchen kam das raus und es funktioniert sogar 😀

<DiskConfiguration>
<WillShowUI>OnError</WillShowUI>
<Disk wcm:action="add">
<CreatePartitions>
<CreatePartition wcm:action="add">
<Order>4</Order>
<Type>Primary</Type>
<Extend>true</Extend>
</CreatePartition>
<CreatePartition wcm:action="add">
<Order>2</Order>
<Size>500</Size>
<Type>EFI</Type>
</CreatePartition>
<CreatePartition wcm:action="add">
<Order>3</Order>
<Size>128</Size>
<Type>MSR</Type>
</CreatePartition>
<CreatePartition wcm:action="add">
<Order>1</Order>
<Size>300</Size>
<Type>Primary</Type>
</CreatePartition>
</CreatePartitions>
<ModifyPartitions>
<ModifyPartition wcm:action="add">
<PartitionID>2</PartitionID>
<Order>1</Order>
<Label>System</Label>
<Letter>S</Letter>
<Format>FAT32</Format>
</ModifyPartition>
<ModifyPartition wcm:action="add">
<Order>2</Order>
<PartitionID>4</PartitionID>
<Letter>C</Letter>
<Label>Windows</Label>
<Format>NTFS</Format>
</ModifyPartition>
</ModifyPartitions>
<DiskID>0</DiskID>
<WillWipeDisk>true</WillWipeDisk>
</Disk>
</DiskConfiguration>

Die Disk muss dafür (vermutlich) vorher schon im GPT Modus laufen.

Wenn der Wurm im Apfel ist

Das Apple MacBook nudelt ewig rum, Fortschrittsbalken beim Boot geht bis ca. 40% dann schaltet sich der Rechner ab? Die Platte ist korrupt dass fsck (oder DiskUtility) sie nicht mehr reparieren kann – obwohl zumindestens die Userdaten normalerweise durchaus noch verfügbar sind – aber halt nicht zugreifbar wenn man nicht grad einen zweiten Rechner mit Firewire hat (Cmd-T für Target Mode).

Wenn die Kiste aber noch im Single User Mode (Cmd-S) bootet habe ich diese Anleitung gefunden, meine Daten wandern gerade auf den Stick 😀

Zusammengefasst:

  • mit Cmd-S in Single User Mode booten
  • USB Stick anstecken (meiner war mit FAT32 formatiert)
  • ls /dev/disk* – bei mir wars /dev/disk1s1
  • mkdir /Volumes/usb
  • /sbin/mount_msdos /dev/disk1s1 /Volumes/usb
  • cp -r /Volumes/Macinthsh HD/Users /Volumes/usb
  • /sbin/unmount /Volumes/usb

AD CA Restore und der Fehler 0x8007010b

Es gibt ja jede Menge KB-Artikel und Diskussionen zum Thema 0x8007010b beim Restore einer CA – in meinem Fall kam der generische Fehler mit der Zusatzinfo „The expected data does not exist in this directory. Please choose a different directory.“ – obwohl genau die Files in dem gewählten Directory lagen die u.a. in KB298138 beschrieben sind.

Was dort (und auch sonstwo) aber niiicht steht ist dass in dem Directory SONST NICHTS LIEGEN DARF – wie etwa (wie in meinem Fall) EDB####.log Files von anderen Backups als dem aktuellen (meine Sicherung hat jeden Tag ins gleiche Verzeichnis geschrieben und immer neue .log Files erzeugt)…..

Mehr Spaß mit AD RMS

Szenario: Firma mit AD RMS (auch über Internet erreichbar) will geschütztes XPS an Mitarbeiter einer anderen Firma ohne Federation schicken (der Mitarbeiter der anderen Firma hat aber z.B. einen Account in der sendenden Firma).

Ergebnis: Geht nicht. XPS Viewer kann per Default den Benutzer nicht im AD RMS der sendenden Firma aktivieren, er versuchts nicht mal.

Workaround 1: Mit Office 2010 (nicht 2013, das verwendet MSIPC den neuen RMS Client!) ein geschütztes Dokument (Mail, Word, Excel) öffnen – die können mit dem Szenario umgehen, fragen nach einem Account in der sendenden Firma und aktivieren den Account. XPS Viewer kann dann auf die Informationen aufbauen und geschützte XPS anzeigen.

Workaround 2: Folgende Registrykeys erzeugen (alle REG_SZ):
* HKEY_LOCAL_MACHINE\Software\Microsoft\MSDRM\ServiceLocation\Activation, Default Value = https://rms.meinefirma.com/_wmcs/licensing
* HKEY_LOCAL_MACHINE\Software\Microsoft\MSDRM\ServiceLocation\ServiceLocation, Default Value = https://rms.meinefirma.com/_wmcs/certification
* HKCUS\oftware\Microsoft\XPSViewer\Common\DRM\CorpCertificationServer = https://rms.meinefirma.com/_wmcs/certification
* HKCU\Software\Microsoft\XPSViewer\Common\DRM\CorpLicenseServer = https://rms.meinefirma.com/_wmcs/licensing
* HKCU\Software\Microsoft\XPSViewer\Common\DRM\Username = user@meinefirma.com
* HKCU\Software\Microsoft\XPSViewer\Common\DRM\UserType = WindowsAuthProvider

Vorsicht: Das alles ist (vermutlich) in keinster Weise supported oder dokumentiert und natürlich ohne Gewähr 🙂