Offline Domain Join für DirectAccess

Auf einem Rechner im Unternehmensnetzwerk:
djoin /provision /Domain mydomain.com /machine mymachine /machineou "ou=myou,dc=mydomain,dc=com" /reuse /savefile c:\temp\mymachine.txt /policynames "DirectAccess Client Settings" /policypaths "\\mydomain.com\sysvol\mydomain.com\Policies\{policy-guid}\machine\Registry.pol" /certtemplate Machine /rootcacerts

mymachine.txt auf den Zielclient transportieren

Am Zielclient:
djoin /requestODJ /loadfile mymachine.txt /windowspath %SystemRoot% /localos

Hinweise:

  • User am Rechner im Unternehmensnetzwerk braucht natürlich das Recht für Domäne um Rechnerkonto zu erstellen und Zertifikat zu requesten.
  • Das /policypaths ist vermutlich nicht notwendig aber sicher ist sicher 🙂
  • Bei /certtemplate das Template angeben welches intern für Clients verwendet wird (der interne Name, nicht der Displayname des Templates, der ohne Blanks).
  • Beim Transport auf den Zielrechner aufpassen dass durch Mailsysteme oder ähnlichem nicht da Encoding des Files verändert wird – am einfachsten via ZIP transportieren.
  • User am Zielrechner muss natürlich lokaler Administrator sein.
  • Die Zeit sollte habwegs richtig bzw. ident mit der Zeit am DA Server sein (Kerberos).
  • Falls das Rechnerkonto schon existiert und reused wird muss es vorher resetiert (=Passwort gelöscht) warden.
  • DirectAccess funktioniert nicht instant, Reboot oder Netz disable/enable hilft.

VMM Fuckup #89027: Fileserver Shares

Wieder ein paar Stunden sinnlos verbraten und wieder im VMM Debuglog gelandet weil das Produkt sonst keine vernünftigen Logs hat.

Szenario: VM (DPM in dem Fall), liegt auf Cluster, soll externe Disken auf einem Fileserver bekommen.

Also Fileserver in VMM registrieren, Share im VMM erzeugen (managed), am Cluster registrieren und das erste Mal ärgern weil man offenbar im VMM keine VHDX auf einem UNC Pfad eintragen kann.

Also im Cluster Admin eintragen. Wieder ärgern weil die Share Permission die VMM anlegt für ihn reicht aber nicht für Cluster Admin weil da der eintragende User auch Rechte haben muss.

Schaut man nach einiger Zeit auf die VM steht da plötzlich “unsupported cluster configuration” und die VM ist nicht mehr konfigurierbar über VMM. Horray. Fehlermeldung: Die VM verwendet Disken auf Shares die im Cluster nicht registriert sind.

Nachgeschaut. Stimmt. Share ist weg. Komplett (Config, nicht am Fileserver).

Stundenlange Suche, im Debuglog findet sich bei einem Refresh des Fileservers folgende Information:


WindowsFileStorageService.cs,439,Found 9 MSFT_SmbShare!,{00000000-0000-0000-0000-000000000000}
WindowsFileStorageService.cs,461,Skipping share name: ADMIN$ (C:\Windows). We filter out IPC$, ADMIN$ and drive letter share like C$, D$.

WindowsFileStorageService.cs,461,Skipping share name: C$ (C:\). We filter out IPC$, ADMIN$ and drive letter share like C$, D$.

WindowsFileStorageService.cs,461,Skipping share name: DPM$ (X:\Hyper-V\DPM). We filter out IPC$, ADMIN$ and drive letter share like C$, D$.

WindowsFileStorageService.cs,461,Skipping share name: HVData$ (X:\Hyper-V\HVData). We filter out IPC$, ADMIN$ and drive letter share like C$, D$.
WindowsFileStorageService.cs,461,Skipping share name: IPC$ (). We filter out IPC$, ADMIN$ and drive letter share like C$, D$

WindowsFileStorageService.cs,461,Skipping share name: print$ (C:\Windows\system32\spool\drivers). We filter out IPC$, ADMIN$ and drive letter share like C$, D$.

WindowsFileStorageService.cs,461,Skipping share name: Test$ (X:\Hyper-V\Test). We filter out IPC$, ADMIN$ and drive letter share like C$, D$.

WindowsFileStorageService.cs,461,Skipping share name: X$ (X:\). We filter out IPC$, ADMIN$ and drive letter share like C$, D$.

WindowsFileStorageService.cs,461,Skipping share name: Y$ (Y:\). We filter out IPC$, ADMIN$ and drive letter share like C$, D$. 

Wir erkennen: VMM skipped (und löscht in weiterer Folge aus der VMM Config und damit von den Cluster wo das Share registriert war) nicht nur ADMIN$, IPC$ und Laufwerk$ sondern alles mit $ – dabei kann man in der VMM Console ganz locker und ohne jegliche Hinweise Shares mit $ erfolgreich anlagen!

Bravo! 🙂

VMM Fehler bei Erstellung File Share (New-SCStorageFileShare)

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

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

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

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

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

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

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.