OCS2007 R2 Update Server

Informationen zum alten Update Server mit der Sharepoint Seite finden Sie auf  OCS Update Server

Software ist nie fertig und wohl dem, wenn ein Hersteller oder Entwickler die Fehler auch korrigiert. für den Administrator bleibt aber immer noch die Arbeit, die Updates auch zu verteilen. Was für Windows Systeme z.B. der WSUS oder Windows Update erledigt, ist für OCS-Client schon etwas kniffliger. Die PC-gestützte Software OCS Communicator lässt sich noch über eine klassische Softwareverteilung aktualisieren. Aber die verschiedenen OCS-Telefone, (hier besonders Roundtable und Tanjay) nutzen einen eigenen Update-Dienst.

Mit OCS2007 R2 hat Microsoft die vielen Administratoren erhört und den mit dem RTM-Server eingeschlagenen Weg über einen Windows Sharepoint Site zur Verteilung der Updates verlassen. Mit R2 reicht der sowieso schon installierte IIS mit ein paar virtuellen Verzeichnissen aus. Auch wurde die Konfiguration der Updates in die MMC mit integriert:

Device Updater GUI

Über das separat aufgerufene Programm können die Update eingespielt und an Testgeräte oder für alle Geräte frei gegeben werden. Auf der Serverseite finden Sie im IIS eine ganze Flut von Verzeichnissen und Skripten, an denen Sie aber in der Regel nicht eingreifen müssen.

Allerdings gibt es immer noch sehr alte Geräte (z.B. Tanjay mit Beta-Firmware), die mit dem neuen R2-Update-Server einfach nicht zurecht kommen. Die alte Version lässt sich aber nicht in eine R2-Umgebung integrieren. Also bleibt nur eine eigene virtuelle Maschine, um diese alten Geräte mit einer neuen Firmware zu beglücken. Zum Glück beschreibt Microsoft die verschiedenen Vorgehensweisen ganz genau, So dass ich hier nur die von mit erkannten Probleme wiedergeben.

Mit OCS 2007 R2 hat Microsoft den "Device Update Service" mit in den Standard bzw. Enterprise Server integriert. er ist also von Hause aus mit installiert. Sie müssen nur noch per DNS die entsprechenden Einträge (UCUPDATE und UCUPDATE-R2) vornehmen und auf dem Server die aktuellen CAB-Dateien installieren.

Logging

Der OCS R2 Server protokolliert natürlich auch die Update, die er an Client verteilt. neben den IIS-Logs, die natürlich als Quelle herhalten können, sind auch die Update Server Logs selbst die erste Anlaufstelle bei Problemen.

Log Settings

Die Logs liegen dann im Verzeichnis:

C:\Program Files\Microsoft Office Communications Server 2007 R2\Web Components\DeviceUpdateFiles\Logs

Debugging

Natürlich gibt es auch das OCS Debugging Tool (MSXFAQ.DE - OCS Debugging), in welchem Sie den Device Update Service ebenfalls mit auswerten können, selbst wenn auch hier die Daten per SSL verschlüsselt sind:

Hier ein verkürzter Auszug eines Trace des Devices Updates.

(DeviceUpdateHttpHandler,RequestHandlerFactory.GetHandler:requesthandlerfactory.cs(113)) Update request recieved
(DeviceUpdateHttpHandler,UpdateRequestHandler.ProcessRequest:updaterequesthandler.cs(48))
	Server URL : http://ucUpdates-r2/requestHandler/ucdevice.upx
(DeviceUpdate,Utilities.ReadFileFromResource:utilities.cs(181))Requested resource name:	
	RequestSchema
(DeviceUpdate,DeviceUpdater.GetUpdatesList:deviceUpdateservice.cs(57))Input Values: 
	DevicePath: UCPhone/LG-Nortel/IP8540/A/ENU/
	DeviceType: UCPhone
	DeviceMacAddress: 001B9E4B5B10
	SerialNumber: 1108015382
	Requested Module XML: System.Xml.XmlDocument
	IsAllowlistDevice: TRUE
(DeviceUpdate,DeviceUpdater.GetUpdatesList:deviceUpdateservice.cs(65))Deserializing module xml
(DeviceUpdate,DeviceUpdaterRules.MatchesDevice:deviceupdaterrules.cs(590))Input Values: 
	Folder Names: System.String[]
	Device Type: CPE
(DeviceUpdate,DeviceUpdaterRules.MatchesDevice:deviceupdaterrules.cs(590))Input Values:
	Folder Names: System.String[]
	Device Type: CPE
(DeviceUpdateHttpHandler,UpdateRequestHandler.ProcessRequest:updaterequesthandler.cs(78))IsTestDevice : True
(DeviceUpdateHttpHandler,UpdateRequestHandler.ProcessRequest:updaterequesthandler.cs(85))Response Xml :
	<?xml version="1.0" ?>
		<Response>
			<NumOfFiles>0</NumOfFiles>
			<CurrentTime>2009-05-04T17:23:39</CurrentTime>
			<LangList>DEU|ENU</LangList>
		</Response>
(DeviceUpdateHttpHandler,UpdateRequestHandler.ProcessRequest:updaterequesthandler.cs(94))
	Received on : 05.04.2009 17:23:39.2803 [Request processing time is : 0.015624 Sec.]

IISLogs

Das die Updates selbst per IIS verteilt werden, ist auch ein Blick in ein IISLog ratsam. Hier ein Auszug eines fehlerhaften Updates:

#Software: Microsoft Internet Information Services 7.0
#Version: 1.0
#Date: 2009-05-04 14:08:11
#Fields: date time cs-method cs-uri-stem cs-uri-query s-port cs-Username c-ip cs(User-Agent) sc-status sc-substatus sc-win32-status
2009-05-04 14:08:11 POST /RequestHandler/ucdevice.upx - 80 - 192.168.102.34 Microsoft+UCPhone+Device 500 19 183
2009-05-04 14:08:12 POST /RequestHandler/ucdevice.upx - 80 - 192.168.102.34 Microsoft+UCPhone+Device 500 19 183

Man erkennt gut die zwei "Versuche" des UCPhone, ein Update zu erreichen (anonym) und es bekommt vom Server einer 500er Meldung mit der Submeldung 19 und dem Windows Code 183. Da ein 500er Fehler immer erst mal ein Server Fehler ist, kann ein einfacher Browseraufruf schon Hinweise liefern. beim IIS7 sind die Aussagen sogar sehr genau:

Ich wollte mir dann die Handler im IIS anschauen und laufe auch hier auf den Fehler:

Warum in meinem IIS nun ein "Duplicate Key" enthalten ist, kann ich nicht sagen. Ich habe diesen "ADD"-Eintrag einfach in der "C:\Program Files\Microsoft Office Communications Server 2007 R2\Web Components\DeviceUpdate\WEB.CONFIG" entfernt.

<add name="AboMapperCustom-41766" path="*.upx" verb="*" modules="IsapiModule" scriptProcessor="C:\Windows\Microsoft.NET\Framework64\v2.0.50727\aspnet_isapi.dll" resourceType="Unspecified" preCondition="classicMode,runtimeVersionv2.0,bitness64" />

Interessanterweise war der Eintrag danach in der Konfiguration immer noch aktiv.

Mittlerweile habe ich auch einen BLOG-Eintrag zu genau dem Thema gefunden:

Nun hat auch ein Zugriff mit dem Explorer zumindest eine Antwort geliefert:

Aber im IISLog war nun immer noch der Fehler 500.19 mit 183 protokolliert. Ein "net helpmsg 183" liefert dann den nächsten Anhaltspunkt.

Also versucht der Post an einer Stelle etwas zu schreiben, an der er nicht schreiben darf. Solchen Berechtigungsproblemen kommt man mit den Sysinternals Tools (Filemon etc.) auf die Schliche. Das war bei mir aber nicht mehr erforderlich, denn im Update Device Log habe ich schon gesehen, dass der Client mit dem Server spricht:

Device Updater Log

Das Device Updatede Log liegt im Verzeichnis: "C:\Program Files\Microsoft Office Communications Server 2007 R2\Web Components\DeviceUpdateFiles\Logs\Server\Audit\imageUpdates\RequestHandlerAuditLog_nawocsstd_TTMMJJJJ" und enthält als CSV-Datei die Ergebnisse:

Logging DateTime,User Name,User Host Address,Device Type,Request DateTime,Mac Address,Serial Number,Vendor,Model,Revision,Locale,Requested<FileName;Version;TimeStamp>[# Seperated für Multiple],Response<FileName;Version;TimeStamp>[# Seperated für Multiple]
05.04.2009 16:30:13,,192.168.102.34,UCPhone,04.05.2009 07:30:04,"001B9E4B5B10","1108015382","LG-Nortel","IP8540","A","ENU",cpe.nbt;0.0.0.0;01.01.1601 00:00:00,http://NAWOCSSTD.netatwork.de/DeviceUpdateFiles_Int/OCInterim/ENU/CPE.nbt;1.0.522.103;05.04.2009 20:09:14
05.04.2009 16:49:00,,192.168.102.34,UCPhone,04.05.2009 07:48:59,"001B9E4B5B10","1108015382","LG-Nortel","IP8540","A","ENU",cpe.nbt;0.0.0.0;01.01.1601 00:00:00,http://NAWOCSSTD.netatwork.de/DeviceUpdateFiles_Int/OCInterim/ENU/CPE.nbt;1.0.522.103;05.04.2009 20:09:14

Hier sehen Sie die erste Anfrage des Clients, dass er das Update erkannt und die URL bekommen hat. Wenn Sie z.B. die URL "http://NAWOCSSTD.netatwork.de/DeviceUpdateFiles_Int/OCInterim/ENU/CPE.nbt" dann in einem Browser eingeben, dann sollten Sie die Firmware auch herunter laden können. Der Client macht aber nicht sofort ein Update, sondern erst nach einigen Minuten.

Im IISLog sehen Sie dann ebenfalls die "guten" Einträge

#Software: Microsoft Internet Information Services 7.0
#Version: 1.0
#Date: 2009-05-04 14:39:52
#Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-Username c-ip cs(User-Agent) sc-status sc-substatus sc-win32-status time-taken
2009-05-04 14:49:00 192.168.100.60 POST /RequestHandler/ucdevice.upx - 80 - 192.168.102.34 Microsoft+UCPhone+Device 200 0 0 1062
2009-05-04 15:14:08 192.168.100.60 POST /RequestHandler/ucdevice.upx - 443 - 192.168.102.34 Microsoft+UCPhone+Device 200 0 0 218

Zuerst erfolgt der Zugriff noch per HTTP auf Port 80 um nach dem Update über HTTPS (443) verschlüsselt zu erfolgen.

Eventlog

Auch im Eventlog hinterlässt der Update Service Spuren. per Default meldet er zumindest, wenn der Request-handler initialisiert wird. 

Log Name: Office Communications Server
Source: OCS Software Update Service
Date: 04.05.2009 18:15:48
Event ID: 65002
Task Category: (4004)
Level: Information
Keywords: Classic
User: N/A
Computer: NAWOCSSTD.netatwork.de
Description:
The Software Update Service has started.
C:\Windows\assembly\GAC_MSIL\DeviceUpdate\3.5.0.0__31bf3856ad364e35\DeviceUpdate.dll v3.5.6907.0
C:\Windows\Microsoft.NET\Framework64\v2.0.50727\mscorlib.dll v2.0.50727.3074
C:\Windows\assembly\GAC_MSIL\System\2.0.0.0__b77a5c561934e089\System.dll v2.0.50727.3053
C:\Windows\assembly\GAC_MSIL\System.Xml\2.0.0.0__b77a5c561934e089\System.Xml.dll v2.0.50727.3074
C:\Windows\assembly\GAC_64\System.Data\2.0.0.0__b77a5c561934e089\System.Data.dll v2.0.50727.3053
C:\Windows\assembly\GAC_MSIL\System.Windows.Forms\2.0.0.0__b77a5c561934e089\System.Windows.Forms.dll v2.0.50727.3053
C:\Windows\assembly\GAC_MSIL\LcWmiConsumer.Managed\3.5.0.0__31bf3856ad364e35\LcWmiConsumer.Managed.dll v3.5.6907.0
C:\Windows\assembly\GAC_MSIL\System.Management\2.0.0.0__b03f5f7f11d50a3a\System.Management.dll v2.0.50727.3053
C:\Windows\assembly\GAC_MSIL\System.Security\2.0.0.0__b03f5f7f11d50a3a\System.Security.dll v2.0.50727.3053

Update alter Tanjay-Telefone

Viele viele andere OCS-Consultants habe auch ich ein Tanjay der ersten Generation mit einer sehr alten Beta-Firmware (1.0.199(1.23)). Angeblich wäre es sehr einfach, diese Firmware mit dem alten OCS Update Server (basierend auf Sharepoint Services etc.) zu aktualisieren. Ein Update mit dem Update Service von R2 funktioniert aber erst, wenn Sie manuell ein paar Einträge in der Konfiguration addieren. Der R2-Update Server hat nicht alle URLs gefüllt, die aber von dieser alten Firmware noch benötigt werden. Mit WBEMTEST können Sie diese Einträge aber nachpflegen.

  • Starte das Programm WBEMTEST.EXE, welches auf dem Server vorhanden ist
  • Verbindungen Sie sich mittels "Connect..." mit dem Namespace auf "root\cimv2"
  • Suchen Sie dann über "Query" nach folgendem String:
    Der erste String ist für einen einfachen Standardserver auf dem gleichen System. Die zweite Abfrage ist für einen Pool mehrerer Enterprise-Server zu verwenden. Beide Male sollten sie am Ende eine Liste der Instanzen angezeigt bekommen:

SELECT * from MSFT_SIPUpdatesServerSetting where backend='(local)\\rtc'

SELECT * from MSFT_SIPUpdatesServerSetting where backend='%backendpool%'

  • öffnen Sie die angezeigte Instanz durch einen Doppelklick. Sie sollten die vier URLs sehen:

    Sie sehen auch, dass die Felder von "ExternalUpdatesDownloadURL" und "ExternalUpdatesStoreURL" nicht gefüllt sind. Genau diese Inhalte benötigt aber das alte Tanjay, um ein Update durchzuführen. Es nutzt zwar nur die beiden URLs "InternalUpdatesDownloadURL" und "InternalUpdatesStoreURL" aber die leeren beiden anderen URLs verhindern das Update.
  • Editieren Sie die Felder "ExternalUpdatesDownloadURL" und "ExternalUpdatesStoreURL"
    Über den Button "Edit Property" können Sie die beiden Felder anpassen. Sie müssen zuerst die Auswahl "Not NULL" nutzen, um im Feld darunter die entsprechende URL einzutragen.

    Beenden Sie den Dialog mit "Save Property" je jedes der beiden Felder
  • Kontrolle und Speichern
    Überprüfen Sie nach der Änderung zur Sicherheit noch einmal die URLs in allen vier Feldern:

    Damit die Änderungen aktiv werden, müssen Sie hier auch noch einmal ein "Save Object" durchführen

Erst dann liefert der OCS 207 R2-Update Server alle URLs, damit auch alte Tanjay-Clients sich aktualisieren können. Das Update selbst erfolgt in zwei Schritten: Zuerst mach das Tanjay ein Update auf die Zwischenversion 1.0.522.103 um dann auf die aktuell bereit gestellte  Version (z.B. 3.5.6907.0) zu kommen.

Weiterhin müssen Sie vermutlich den Client Filter anpassen, damit sich die alten Tanjays noch an den OCS anmelden dürfen und nicht komplett ausgesperrt werden.

Was letztlich zwischen OCS-Server, Update Server und Tanjay passiert, kann man in Grenzen mit dem NetMon3 mitschneiden. Sofern man in die verschlüsselten SIP-Pakete schauen will, hilf nur ein SIP-Trace auf dem OCS-Server und natürlich ein Blick in die Logfiles des Update Servers unter

C:\Program Files\Microsoft Office Communications Server 2007 R2\Web Components\DeviceUpdateFiles\Logs

OCPE Device (Tanjay) upgrade Guide
http://blogs.technet.com/rickva/archive/2009/10/03/ocpe-device-tanjay-upgrade-guide.aspx
Dieser BLOG-Eintrag ist sehr hilfreich für das Update des Tanjay

Weitere Links