CDPInfo

Weil mir die ganzen CDP Clients für Windows (cdp4win, WinCDP, CDPClient, etc.) auf die Nerven gegangen sind und vor allem alle nur ein GUI haben bin ich in die Tiefen von WinPCap abgestiegen und hab einen eigenen kleinen Commandline CDP Client names CDPInfo zusammen geschustert (basierend auf SharpPcap).

Aufgerufen wird es entweder mit „LIST“ um die vorhandenen Adapter aufzulisten oder einem Adapternamen wobei entweder der Name den man in NCPA.CPL vergibt oder der Devicename (\Device\NPF_{GUID}) oder Teile davon (Regex!) zu verwenden ist.

Die Adapter die unter einem Team (2012) dienen können leider nicht mit dem NCPA-Namen angesprochen warden, da muss man in die Untiefen von WMI abtauchen: Angenommen der Adapter heißt „Teamadapter1“ dann bekommt man mit

(gwmi win32_networkadapterconfiguration | ? index -eq (gwmi win32_networkadapter|? NetConnectionID -eq 'Teamadapter1").index).SettingID

die GUID die man dann vorne noch mit \Device\NPF_ ergänzt und schon hat man gewonnen 🙂

 

 

.NET Framework 3.5, patched Windows Server 2012 R2 U1 und 0x800f081f

Scheinbar hat MS mit irgend einem Post Update 1 Hotfix irgendwo einen Fisch eingebaut sodass DISM/CBS irgendwelche Parentfeatures von .NET 3.5 nicht mehr auf der Original 2012R2-Update 1 DVD findet. Wenn man dann noch einen WSUS Server konfiguriert hat hilfts auch nicht /LimitAccess beim Standardworkaround mit DISM anzugeben weil das Feature natürlich am Companyinternen WSUS nicht vorhanden ist.

Wenn der Server dennoch irgendwie ins Internet kommt kann man CBS aber über ein lokales Policy Setting sagen dass er/sie/es WSUS nicht verwenden soll:

Computer Configuration/Administrative Templates/System/Specify settings for optional component installation and component repair: Enablen und „Contact Windows Update directly to download repair content instead of Windows Server Update Services (WSUS)“ checken, dann funktionert der Standardtrick (DISM /all /online /enable-feature /featurename:netfx3 (halt ohne /source und /LimitAccess wie sonst)) auch wieder.

Storage Spaces: Performancetipps

Hier ein paar Punkte wie man Storage Spaces ein wenig schneller macht (wenn man die entsprechende Hardware hat, hier gehts um Server und Storage mit redundanten Netzteilen die an USV(s) hängen – NICHT um Storage Spaces mit 0815-Disken am Heim-PC!):

1) Disk write cache enablen:
Cache

 

2) Beim Erzeugen des Storage Pools 2 (Mirror/Parity) bzw. 3 (doppel-Mirror/Parity) SSDs als Journaldisken einfügen:

Add-PhysicalDisk -StoragePoolFriendlyName MeinPool-PhysicalDisks (Get-PHysicalDisk|? ...whatever...) -Usage Journal

3) Beim Erzeugen des Storage Spaces (=VirtualDisk) WriteCacheSize angeben:

New-VirtualDisk -FriendlyName MeineDisk -StoragePoolFriendlyName MeinPool -ResiliencySettingName Parity -WriteCacheSize 100GB

4) Dem Storage Pool sagen dass alles gaaaanz sicher ist mit dem Strom:

Set-StoragePool -FriendlyName MeinPool -IsPowerProtected $True

 

Bei meinen Tests hat sich damit eine Verdopplung der Geschwindigkeit eingestellt (synthetisch mit IOMeter und diesem CrystalDiskDingens als auch praktisch).

 

Storage Spaces: Diskmonitoring und -tausch mit LSI in FTS Server

Wie ich heute feststellen musste schreit der Fujitsu RAID Manager nicht los wenn eine Disk als JBOD in einem Storage Space eingebunden ist – fühlt sich einfach nicht mehr zuständig sobald eine Disk im JBOD Modus ist (scheinbar).

D.h. es ist aktives Monitoring angesagt – entweder über PowerShell

Get-PhysicalDisk|? OperationalStatus -ne "OK" (bzw. Get-PhysicalDisk|? HealthStatus -ne "Healthy")

oder gleich direkt über WMI (Get-PhysicalDisk macht nichts anderes):

root\Microsoft\Windows\Storage\MSFT_PhysicalDisk (Doku)

 

Hat man nun eine ungesunde Disk hat folgendes funktioniert (MegaCLI Download):

  • Disk tauschen
  • MegaCLI64.exe -PDList -aALL => Disk suchen mit Firmware State ungleich JBOD, Enclosure und Slot notieren, Adapternummer auch
  • MegaCli64.exe -PDClear -Start -PhysDrv[:] -a => Disk löschen
  • MegaCli64.exe -PDClear -ShowProg -PhysDrv[:] -a => bis fertig
  • MegaCli64.exe -PDMakeJBOD -PhysDrv[:] -a => damit tauchts im Windows auf
  • Set-PhysicalDisk -FriendlyName "PhysicalDiskXX" -Usage Retired => alte Disk (die ungesunde) aus dem Storage Space entfernen (falls sie nicht sowieso schon automatisch auf retired gesprungen ist)
  • Remove-PhysicalDisk -StoragePoolFriendlyName meinPool -PhysicalDisks (get-physicaldisk -FriendlyName "PhysicalDiskXX") => alte Disk (die ungesunde) entfernen
  • Add-PhysicalDisk -StoragePoolFriendlyName meinPool -PhysicalDisks (Get-PhysicalDisk -CanPool $True) => neue Disk einfügen (falls es die einzige nicht zugeordnete ist, sonst ist wohl Get-PhysicalDisk -FriendlyName "PhysicalDiskYY" besser)
  • Repair-VirtualDisk -FriendlyName meineDisk
  • => zur Sicherheit Repair anwerfen 🙂

IE11 nimmt Trusted Sites aus GPO bei Aufruf via RemoteApp nicht an

Situation:

  • Trusted Sites werden über GPO gesteuert
  • Internet Explorer 11
  • Aufruf (direkt oder indirekt) in RemoteApp
  • Internet Explorer Enhanced Security Configuration (IE ESC) ist für User+Admininstratoren abgedreht

Ergebnis: Trusted Sites im IE11 sind leer, darauf aufbauende Settings werden natürlich nicht angewendet. Bei Logon auf Full Desktop funktioniert hingegen alles.

Lösung: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\IEHarden=0 (REG_DWORD)

Mir wurde im Rahmen des Calls mit MS nicht ganz klar ob das ein Bug ist oder Absicht, funktionieren tuts auf alle Fälle 🙂

Passwort für Deployment mit MDT

Damit nicht jeder seinen Rechner mit MDT neu aufsetzen kann nutzt man das Prestaging-Verfahren mit Hinterlegung der PXE GUID im AD – nur hindert das diejenigen die auf so einem prestaged Rechner sitzen MDT anzuwerfen, deswegen sollte man die MDT Task Sequenzen mit einem Kennwort schützen. Da wir sowieso den Rechnernamen über die MDT Datenbank „mitgeben“ habe ich ein „freies“ Feld in der Datenbank (ScanStateArgs da wir USMT nicht nutzen) zweckentfremdet und schreibe dort ein zufälliges Kennwort rein (welches ich dem berechtigten Installateur natürlich bekannt gebe) – in der MDT TS wird dann ganz weit oben der Aufruf für diese HTA eingefügt (welche halt natürlich irgendwo am MDT Deployment Share herumkugeln muss):

<html>
   <head>
      <meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
      <title>Deployment password</title>
      <HTA:APPLICATION ID="App Mapping" APPLICATIONNAME="App Mapping" VERSION=".01" BORDER="thin" SCROLL="no" SHOWMENU="no" SYSMENU="no" SINGLEINSTANCE="yes" WINDOWSTATE="Normal"/>
   </head>
   <script language="vbscript" type="text/vbscript" src="..\ZTIUtility.vbs"></script>
   <script language="vbscript" type="text/vbscript">
      on error resume next
      sub Window_onload
         on error resume next
         
         Set oTSProgressUI = CreateObject("Microsoft.SMS.TSProgressUI") 
         oTSProgressUI.CloseProgressDialog 
         Set oTSProgressUI = Nothing         
         
         x=350
         y=150
         window.resizeTo x,y
         window.moveTo ((screen.availWidth \ 2) - (x \ 2)), ((screen.availHeight \ 2) - (y \ 2))
         MDTPassword.Focus
      end sub

      sub Document_onKeyDown
         alt=window.event.altKey
         if window.event.keyCode=13 then
            CheckPassword
         end if
         if window.event.keyCode=116 or window.event.keyCode=27 or (alt=true and window.event.keyCode=115) then
            window.event.keyCode=0
            window.event.cancelBubble=true
            window.event.returnValue=false
         end if       
      end sub

      Function CheckPassword
         if Trim(MDTPassword.Value) = "" Then
            MsgBox "Password empty/only blanks"
            MDTPassword.Focus
            Exit Function
         end if
         if IsNull(oEnvironment.Item("ScanStateArgs")) or Trim(oEnvironment.Item("ScanStateArgs")) = "" Then 
            MsgBox "No password in MDT database, cannot continue"
            MDTPassword.Focus
            Exit Function
         end if
         if oEnvironment.Item("ScanStateArgs") = MDTPassword.value then
            self close ()
         else
            msgbox "Wrong password"
            MDTPassword.Value=""
            MDTPassword.Focus
         end if
      End Function
   </script>
   <body>
      <br/>
      <Font Face=Arial size=3>
         <b>Deployment password: </b>
         <input name="MDTPassword" type="password" value="" size="10">
      </font>
      <input id=runbutton class="button" type="button" value=" OK " name="ok_button" onClick="CheckPassword">
   </body>
</html>

Windows Embedded Standard 7 auf Hyper-V via RDP

Wenn man Windows Embedded Standard 7 (WES7) auf Hyper-V (in meinem Fall auf Windows 8.1) betreibt hat man bei Zugriff auf Hyper-V Remote Connection via RDP (also die Remote Connection läuft innerhalb einer RDP Session) keinen Maussupport („Mouse not captured in remote Desktop session“) – die Integration Services lösen das Problem normalerweise nur sind die offenbar in der aktuellen Version nicht für WES7 supported bzw. funktionieren schlicht nicht (installieren lassen sie sich nämlich).

Wenn man aber die „alten“ Versionen im Kompatibilitätsmodus installiert pfeift das einwandfrei (Link):

WES7_IntegrationServices

 

 

PXE GUID einer Hyper-V Generation 2 VM ermitteln

Wer seine Rechner für WDS prestagen muss sollte auch die PXE GUID wissen – was bei Generation 2 Hyper-V VMs gar nicht einfach ist weil sich MS entschlossen hat die nicht anzuzeigen, auch nicht im Hyper-V Manager und auch nicht mit den PowerShell Cmdlets (zumindestens hab ich nichts gefunden); in den Tiefen des WMI Repositories ists aber dann doch versteckt:

(gwmi -namespace root\virtualization\v2 -query "select BIOSGUID from Msvm_VirtualSystemSettingData where InstanceID='Microsoft:$((get-vm MEINE_VM).VMId)'").BIOSGUID

Client Certificate Authentication mit IIS 8.x

MS hat mit Windows 8/2012 bzw. 8.1/2012R2 in SCHANNEL ein paar Änderungen durchgeführt die u.a. die SCCM 2012 R2 Clientkommunikation (wenn im HTTPS-Modus betrieben) vernichtet (403 Error Codes beim Versuch irgendwas vom DP oder MP zu laden, im IIS Log kann man dann auf 403.16 (=CERT_E_UNTRUSTEDROOT) weiter tracen).

Die Ursache ist ein nicht self signed Zertifikat (s. KB2802568) in den Trusted Root Certification Authorities des Webservers, man kann dieses entweder finden (Get-Childitem cert:\LocalMachine\root -Recurse | Where-Object {$_.Issuer -ne $_.Subject} | Format-List * (aus KB295828)) und löschen oder man ändert das SCHANNEL Verhalten mit

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL]

„ClientAuthTrustMode“=dword:00000002

 

 

Der Vorgang wurde aufgrund von aktuellen Beschränkungen….

Ein weiteres klassisches Beispiel einer sprechenden Fehlermeldung bei der man gleich weiß wo man suchen muss:

RemoteAppRestrictions

Passiert auf einem 2008R2 Terminalserver (wobei die Version vermutlich egal ist), beim Aufruf einer RemoteApp.

Grund war: Der Pfad der RemoteApp war nicht korrekt geschrieben:

RemoteAppRestrictions2

Kein Eintrag im EventLog (nicht mal in den Terminalserverspezifischen), nix – wenn nicht zufällig eine zweite RemoteApp die sehr ähnlich ist funktioniert hätte wäre das Troubleshooting anstrengend geworden….