Lync 2013 mit TMG 2010 über DirectAccess

Wer Lync 2013 auf DirectAccess Clients über den/die „normalen“ Internet-facing Lync Edge Server fahren will (was bei Audio/Video/Sprache angesagt ist weil sonst alles doppelt verschlüsselt wird und Jitter, Lags & Co. ausufern) muss die ganzen URLs (sip, dialin, meet, webcon, av, discover, _sip._tls, _sip._internaltls) in der DirectAccess Konfiguration aus dem Tunnel ausschließen – das ist bekannt und wohl dokumentiert (auch wenn die Fülle an Namen schon Potential für spaßige Effekte hat).

Eher unbekannt sind aber 2 zusätzliche Tatsachen:

1) Lync-Discovery fährt über HTTPS auf lyncdiscover.mydomain.com und je nach Proxyconfig geht das im DA-Umfeld über den Proxy. Ich habe auch gesehen dass Lync Client irgendwo ins Internet hin will (irgend eine 23er Adresse) und da natürlich über Proxy gehen will/muss.

2) TMG liefert per default (in einer single Node Config) bei http://myproxy.mydomain.com/array.dll?Get.Routing.Script) in der MakeProxies() Funktion die IPv4 Adresse des TMG Hosts aus.

Diese zwei Umstände führen dazu dass der Lync-Client über die IPv4 Adresse des Proxies auf Lync-Discovery machen will und daran scheitert – die Effekte sind je nach weiterer Lync- und DA-Konfiguration ebenso manigfaltig wie spannend (und unter Garantie zeigt keiner davon in die richtige Richtung).

Also: Script aus TMG holen, ändern, wo anders speichern (Webserver) und Browser manuell oder via Policy dorthin schielen lassen und schon macht der Lync Client auch das was er soll.

Windows Management Framework 4.0 und .NET 4.5.x

Möge es jemanden die 3 schmerzhaften Stunden die ich deswegen ver*zensur*en habe ersparen: Das Setup von Windows Management Framework 4.0 (=PowerShell 4) hat ein sehr unschönes Problem – aufgetreten auf einer Image-VM für Terminalserver. Wenn auf der Kiste kein .NET 4.5 (ohne .1 oder .2 oder was noch immer da kommt) drauf war und via WSUS dann gleich 4.5.1 kommt läuft das Setup von WMF 4.0 durch, will keinen Reboot aber PowerShell 4 ist auch nicht installiert.

Will man den KB über WUSA entfernen meint es es ist nicht installiert, will man es nochmal installieren meint er es ist schon installiert (!!). D.h. die Kiste ist mehr oder weniger im Eimer was PowerShell 4 angeht.

Installiert man hingegen .NET 4.5 (ohne hinten was dran, aber Vorsicht falls das mit hinten dran noch drauf ist muss das VORHER runter) pfeift alles einwandfrei….

KB2984972 tötet App-V

Wie ich erst heute festgestellt habe hat KB2984972 (Update for RDC 7.1 to support restricted administration logons on Windows 7 and Windows Server 2008 R2 (!!!!)) vom Oktober Patchday nicht nur neue Features gebracht sondern so nebenbei auf manchen App-V Clients jeglichen Start einer App-V Application unmöglich gemacht. Die Lösung für das Problem steht auch in o.a. KB-Artikel (bzw. im offiziellen App-V Blog):

reg add HKLM\Software\Microsoft\AppV\Subsystem\ObjExclusions /v 93 /t REG_SZ /d TermSrvReadyEvent

Commvault Pruning und Free Disk Space Anzeige beschleunigen

Da beim Troubleshooting die Defaultzeiten für das echte Löschen der vom Data Aging für prunable befundenen Diskbereiche sowie das Update des Free Disk Space bei den MagLibs entwas zu lang sind (30 und 60 Minuten) kann man die per Parameter (live!) etwas beschleunigen – natürlich nur fürs Troubleshooting weil das die Systemlast am CommServe doch arg anhebt.

Die Zeit zwischen den echten Löschaktionen kann man über den Reiter Additional Settings vom CommServe mit Parameter „MMpruneProcessIntervalMin“ steuern:

Simpana2

 

Die Zeit zwischen den Checks wie es mit dem Disk Space auf den MagLibs aussieht über das Control Panel / Media Management, Reiter Service Configuration, Parameter „Interval (Minutes) between disk space updates„:

Simpana1

 

 

 

StorageSpaces und Cluster Shared Volumes: bad idea

Also ging er hin und kaufte eine für Storage Spaces zertifiziertes Enclosure mit zertifizierten Disken, zertifizierte Controller und stopfte sie in zwei zertifizierte Server die ein Hyper-V Cluster werden sollten.

Er erzeugte einen Pool und eine virtual disk (=Storage Space) vom Typ Parity mit Journaldisken auf SSDs und Write Caches auf allen Ecken und Enden enabled damit das ganze auch schnell ist – und hängte das darauf basierende Volume als CSV in den Cluster ein.

Soweit so gut, alles funktioniert, Failover pfeift, alles fein. Dann schaute er mal mit Get-ClusterSharedVolumeState nach ob auch wirklich alle Knoten direct auf die Platten zugreifen – was sie natürlich nicht taten:

StateInfo                    : BlockRedirected
VolumeFriendlyName           : Volume1
FileSystemRedirectedIOReason : NotFileSystemRedirected
BlockRedirectedIOReason      : StorageSpaceNotAttached

Herrn Google befragt und dieses gefunden (hier):

StorageSpaceNotAttached – Space is not attached on this node. Many Storage Spaces on disk formats are not trivial, and cannot be accessed for read/write by multiple nodes at the same time. Cluster enforces that a Space is accessible by only one cluster node at a time. Space is detached on all other nodes and it is attached only on the node where corresponding Physical Disk Resource is online. The only type of Space that can be attached on multiple nodes and is a Simple Space, which does not have write-back cache.

D.h. in Wahrheit kann man keine Storage Space Konfiguration als CSV verwenden weil das weder sicher noch schnell wäre, insgesamt also ein total sinnloses Feature.

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 🙂