Nach dem Update von DSM von Version 2016 auf 2017 hatte ein Kollege an einem Standort Probleme mit dem Aufsetzen von Rechnern. Während der PE Phase des Aufsetzprozesses zeigte sich folgendes Fehlerbild (sorry für den schlechten Screenshot):
Ein Blick in die ClientProxyWebService.txt (zu finden in C:\Program Files (x86)\Common Files\enteo\NiLogs\ClientProxy\) zeigte folgenden Fehler:
2018-02-13 08:39:21,933 [65] FATAL DSM.ClientProxy.WebService – Exception occurred while downloading file.
2018-02-13 08:39:21,933 [65] FATAL DSM.ClientProxy.WebService – Could not load file or assembly ‚Enteo.Nwcm, Version=7.4.0.4329, Culture=neutral, PublicKeyToken=2aa8ae3ddce4beba‘ or one of its dependencies. The system cannot find the file specified.
2018-02-13 08:39:21,933 [65] FATAL DSM.Common.WebService.HttpApplication – Web service error occurred: Could not load file or assembly ‚Enteo.Nwcm, Version=7.4.0.4329, Culture=neutral, PublicKeyToken=2aa8ae3ddce4beba‘ or one of its dependencies. The system cannot find the file specified.
Requested URL: /ClientProxy/DownloadFile.ashx?File=OSDProxy.BinClntPEx64%5cosdget.exe&ClientID=1&Type=2
System.IO.FileNotFoundException: Could not load file or assembly ‚Enteo.Nwcm, Version=7.4.0.4329, Culture=neutral, PublicKeyToken=2aa8ae3ddce4beba‘ or one of its dependencies. The system cannot find the file specified.
File name: ‚Enteo.Nwcm, Version=7.4.0.4329, Culture=neutral, PublicKeyToken=2aa8ae3ddce4beba‘
at Enteo.ClientProxy.Logic.WebServiceSupport.FileDownloadHandlerBase.SendFile()
at Enteo.ClientProxy.WebService.DownloadFile.ProcessRequest(HttpContext context)
at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
at System.Web.HttpApplication.ExecuteStepImpl(IExecutionStep step)
at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)
Ihm fehlt also das Assembly oder die Datei „Enteo.Nwcm“. Da wir mehrere Management Points haben, suchte ich auf einem, von dem ich wusste, dass es funktioniert, nach der Datei und konnte diese auch ausfindig machen:
Auf dem fehlerhaften Server suchte ich an derselben Stelle:
Die Lösung des Problems schien naheliegend: Die Dateien kopieren und fertig. Leider brachte alleine das Kopieren keinen Erfolg, der Fehler war weiterhin da. Im zweiten Schritt musste ich noch die dll’s im Assembly Cache registrieren. Dazu benötigt man aus dem Windows SDK das Tool „gacutil.exe“ (da DSM 2017 jetzt auf .Net 4.x läuft, ist dieses hier das Richtige: C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.1 Tools). Ich hatte mir der Einfachheit halber den ganzen SDK Ordner nach „C:\temp\“ kopiert; man kann ja nie wissen, was man noch so benötigt. Danach war noch ein Kommandozeilen-Aufruf nötig, um beide dll’s zu registrieren:
C:\temp\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.1 Tools>gacutil.exe /i „C:\Windows\Microsoft.NET\assembly\GAC_MSIL\policy.7.4.Enteo.Nwcm\v4.0_7.4.0.4329__2aa8ae3ddce4beba\policy.7.4.Enteo.Nwcm.dll“
C:\temp\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.1 Tools>gacutil.exe /i „C:\Windows\Microsoft.NET\assembly\GAC_MSIL\Enteo.Nwcm\v4.0_7.4.0.4329__2aa8ae3ddce4beba\Enteo.Nwcm.dll“
Zur Sicherheit wurde die Maschine noch neu gestartet und die ClientProxyWebService.txt zeigte dann:
—– Started logging at 2018-02-13 10:22:41,363 ———————-
Computer-Information
====================
Machine-Name : ehemals_kaputter_Server
OS Version : Microsoft Windows NT 6.3.9600.0
# of processors : 2
====================
2018-02-13 10:22:41,435 [1] INFO DSM.Common – Registering for unhandled exceptions in AppDomain ‚/LM/W3SVC/2/ROOT/ClientProxy-1-131629873592181317‘
2018-02-13 10:22:41,483 [1] INFO DSM.Common – Registering callback for server certificate validation (Mode=RejectCertificatesWithErrors)
2018-02-13 10:22:41,570 [7] INFO DSM.Common.WebService.HttpApplication – Web service successfully initialized
2018-02-13 10:22:42,170 [7] INFO DSM.Common.WebService.TraceExtension – Tracing of SOAP calls disabled