VMM Fehler bei Erstellung File Share (New-SCStorageFileShare)

Posted on by roman

Weil mir das jetzt gefühlte 10 Stunden gekostet hat muss ich das für mich und die Nachwelt festhalten.

Wollte über VMM Console auf einem File Server (Windows) ein Share erzeugen – Wizard durchgeklickt, dieses Command kommt am Ende raus


New-SCStorageFileShare -StorageFileServer (Get-SCStorageFileServer -Name Server.mein.at) -Name "Share`$" -Description "Some share" -LocalPath "X:\Pfad" -StorageClassification (Get-SCStorageClassification -Name "whatever")

Abgesetzt hat das immer folgende dezente Meldung geworfen:


New-SCStorageFileShare : VMM does not have appropriate permissions to access the resource C:\Windows\system32\qmgr.dll on the Server.mein.at server. (Error ID: 2910, Detailed Error: Access is denied (0x80070005))

Irgendwann wars mir dann zu blöd und ich hab Tracing gemäß 2913445 angeworfen und folgende Perle gefunden:


[Microsoft-VirtualMachineManager-Debug]19,2,NewStorageFileShareSubtask.cs,207,Found WindowsNonClustered FileServer Server.mein.at,{00000000-0000-0000-0000-000000000000}
[Microsoft-VirtualMachineManager-Debug]9,2,SmbOperationsHelper.cs,818,InvokePowerShellCommand: Connecting to Server.mein.at with Mein\User,{00000000-0000-0000-0000-000000000000}
[Microsoft-VirtualMachineManager-Debug]9,2,SmbOperationsHelper.cs,832,Errors while invoking PS command New-Item -Path "X:\Pfad" -ItemType directory,{00000000-0000-0000-0000-000000000000}
[Microsoft-VirtualMachineManager-Debug]9,1,SmbOperationsHelper.cs,837,Following exception while invoking PS command.,{00000000-0000-0000-0000-000000000000}
[Microsoft-VirtualMachineManager-Debug]9,1,SmbOperationsHelper.cs,837,System.Management.Automation.RemoteException: An item with the specified name X:\Pfad already exists.,{00000000-0000-0000-0000-000000000000}

D.h. das Teil versucht das Directory anzulegen (von mir aus), scheitert aber weils (in meinem Fall) schon vorhanden war und läuft in weiterer Folge komplett Amok und liefert den vollkommenen Schwachfug zurück an den aufrufenden, dann ratlosen, User….

Lync 2013 – Cumulative Update – CERT_E_UNTRUSTEDROOT

Posted on by roman

Lync 2013, Cumulative Update 7 – nach Reboot noch alles klar, nach einem späteren Frontend Servicerestart plötzlich Event ID 12303/LS Server (The protocol stack reported a critical error: code 800B0109 (CERT_E_UNTRUSTEDROOT). The service has to stop.) und 14649/LS Protocol Stack

A serious problem related to certificates is preventing Lync Server from functioning.

Unable to use the default outgoing certificate.
Error 0x800B0109(CERT_E_UNTRUSTEDROOT).
The certificate may have been deleted or may be invalid, or permissions are not set correctly.
Ensure that a valid certificate is present in the local computer certificate store. Also ensure that the server has sufficient privileges to access the store.

Cause: The Lync Server failed to initialize with the configured certificate.
Resolution:
Review and correct the certificate configuration, then start the service again.

  • Certificates Snap In meint es ist alle da – Root Zert, Intermediate Zert, Zert an sich – alles in den korrekten Stores
  • certutil -verify -urlfetch liefert keinerlei Fehler, CRL Prüfung also auch ok
  • Rechte auf private Keys passen (NETWORK SERVICE)
  • Assign mit Lync Deployment hilft auch nicht

Erst nachdem ich alle Zertifikate außer dem Root CA Zert (das “eigentliche” und alle Intermediates) neu importiert hatte ist das Gewerk plötzlich fehlerfrei los gelaufen….

App-V Totalreset/cleanup ohne Neuinstallation

Posted on by roman

App-V ist relative empfindlich was Dateisystem, ACLs und Registry angeht – es passiert leider viel zu oft dass gar nix mehr geht und die spannendsten Fehlermeldung und vor allem Codes (App-V hat ja seine eigenen Regeln (und ist sehr eigen dabei…)).

Folgende Vorgangsweise hat sich für einen Totalreset ohne Neuinstallation recht gut bewährt:

MACHINE

Get-appvclientpackage -all|remove-appvclientpackage
Stop-Service appvclient

handle | find "C:\ProgramData\App-V" => kill process
Gardelete /dir:c:\programdata\app-v /subdirectories

Registry:
HKLM\SOFTWARE\Microsoft\AppV\Client\Packages\*
HKLM\SOFTWARE\Microsoft\AppV\Client\Streaming\Packages\*
HKLM\SOFTWARE\Microsoft\AppV\Client\Virtualization\LocalVFSSecuredUsers\* (ohne S-1-5-18)
HKLM\SOFTWARE\Microsoft\AppV\MAV\Packages\*

Usercleanup (s.u.)

Start-Service appvclient

USER

gardelete /dir:c:\users\akhedvgar\appdata\roaming\microsoft\appv /subdirectories
gardelete /dir:c:\users\akhedvgar\appdata\local\microsoft\appv /subdirectories

HKCU\SOFTWARE\Microsoft\AppV (komplett)
HKCU\SOFTWARE\Classes\AppV (komplett)

Shortcuts löschen
	• %USERPROFILE%\Desktop
	• %USERPROFILE%\AppData\Roaming\Microsoft\Windows\Start Menu

.NET TcpClient() und DirectAccess

Posted on by roman

Die .NET Klasse TcpClient() kann scheinbar nur IPv4 oder IPv6 – nicht beides. Und wenn man nichts dazu sagt wird defaultmäßig IPv4 genommen. Sitzt man aber auf einem DirectAccess Client werden die Unternehmensresourcen auf IPv6 Adressen aufgelöst und das was im Unternehmen einwandfrei pfeift (weil IPv4) funktioniert von außen (DirectAccess) überhaupt nicht, TcpClient.Connect() wirft eine nette Exception:

System.Net.Sockets.SocketException (0x80004005): A request to send or receive data was disallowed because the socket is not connected and (when sending on a datagram socket using a sendto call) no address was supplied

Der richtige Weg (zumindestens funktioniert er) ist sich je nach Sachlage anzupassen:

IPHostEntry oHost = null;
TcpClient oClient = null;
string sHost = "host.company.com";
int nPort = 4711;

oHost = Dns.GetHostEntry(sHost);
if (oHost == null || oHost.AddressList == null || oHost.AddressList.Length == 0)
      throw new Exception("DNS resolution for '" + sHost + "' failed");

oClient = new TcpClient(oHost.AddressList[0].AddressFamily);
oClient.Connect(oHost.AddressList[0], nPort);

Super Micro IPMI Zertifikat

Posted on by roman

Da Super Micro (oder wer für das IPMI auch immer verantwortlich ist) die übergebenen Files nicht wirklich prüft und dann einfach weder HTTP noch HTTPS hoch bekommt hier die 2 Befehle die man von einem PFX weg braucht um das Cert und das Private Key File zu bekommen:

openssl pkcs12 -in my.pfx -nokeys -out my_cert.pem
openssl pkcs12 -in my.pfx -nocerts -nodes -out my_key.pem

Wenn mans doch verkackt hat kann man mit IPMITOOL von jedem Linux weg die Config (seltsamerweise aber nicht die LAN-Config) auf Factory Settings zurück setzen:

ipmitool -H meinhost -U meinuser -P meinpasswort raw 0x3c 0x40

WMI isolieren und töten

Posted on by roman

Microsoft hält ja große Stücke auf WMI – Cluster, Hyper-V, Server Manager, Storage Spaces und viele neue prominente Produkte funktionieren ohne WMI exakt überhaupt nicht  mehr. Wenn dann WMI (vielleicht nur bei mir aber irgendwie glaube ich nicht dran) wieder mal verreckt sich aber nicht stoppen lässt ist guter Rat unbezahlbar weil WMI per Default ein shared Service ist und noch dazu in einer Gruppe mit gefühlt 800 anderen Diensten, d.h. den SVCHOST Prozess töten kann man nicht ohne den Rechner in den Abgrund zu schicken (was z.B. bei einem hochproduktiven Hyper-V Clustermember irgendwie nicht so prickelnd ist – da WMI aber im Eck ist kann man weder auf die Cluster- noch auf die Hyper-V Funktionalität zurückgreifen und z.B. die VMs wegmigrieren….).

Man kann Dienste aber auch isolieren (own statt shared process) – das war ja schon bekannt, bei WMI läuft das aber anders weil da muss man mit WINMGMT /STANDALONEHOST die notwendigen Änderungen vornehmen und dann den Dienst neu starten (oder halt auf Reboot warten weil Restart ist so eine Sache :-D).

Damit ist WMI mal isoliert aber wie findet man es unter den 300 SVCHOSTS – vor allem weil z.B. TASKLIST /SVC auch WMI braucht um zu funktionieren und u.U. ist ein interaktives Login auf dem Rechner nicht mehr möglich weil eine Group Policy einen WMI Filter hat (oder 1000 andere Gründe, wie gesagt WMI is everywhere)?

Sysinternals hat wieder mal das rettende Tool vor vielen Jahren für eigentlich andere Sachen gebaut (man kann sich die Sachen sicher auch anders über die Win32 API besorgen aber das ist halt fix/fertig und funktioniert soweit ichs beurteilen kann überall): ListDLLs.

Mit z.B. LISTDLLS | FINDSTR "pid Command" bekommt man eine Liste aller Prozesse und deren Commandline, u.a. eine Commandline die mit "-k winmgmt” endet – und das ist unser WMI Prozess (die Gruppe winmgmt entsteht durch das /STANDALONEHOST, im Original ist das eine Gruppe die 1000 andere Dienste auch haben!).

Lync 2013 mit TMG 2010 über DirectAccess

Posted on by roman

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

Posted on by roman

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

Posted on by roman

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