none
WSUS: Keine Updates wg. Fehler 0x80244019 RRS feed

 > 

  • Frage

  • Question
    Anmelden
    0
    Anmelden

    Hallo zusammen,

    ich kämpfe aktuell mit einem Problem, welches mir noch nicht so ganz einleuchten will & hoffe auf eure Unterstützung. Gegeben ist ein neuer WSUS Server auf 2012R2 Basis, der unter dem Namen wsus.domain.tld erreichbar ist. Er wurde auf SSL konfiguriert (im IIS die WSUS-Verwaltungsseite auf SSL gesetzt und wsutil configuressl wsus.domain.tld ausgeführt.), hat MSSQL als Backend-DB und zeigt auch keine Fehler an.

    Per GPO wurde der WSUS an Clients verteilt (mit der URL https://wsus.domain.tld:8531) und die Clients können diese Seite auch aufrufen. Es hängt kein Proxy dazwischen und keine Firewall macht Probleme.

    Wenn ein Client (egal ob Windows 7 oder 10) nun Updates abrufen möchte, kommt nach einigen Sekunden die Fehlermeldung 0x80244019 und der Vorgang wird beendet. Per Get-WindowsUpdateLog kam folgendes heraus:

    2016.05.18 09:06:46.2525845 5392  9584  Agent           WU client version 10.0.10586.212
2016.05.18 09:06:46.2528143 5392  9584  Agent           SleepStudyTracker: Machine is non-AOAC. Sleep study tracker disabled.
2016.05.18 09:06:46.2528701 5392  9584  Agent           Base directory: C:\WINDOWS\SoftwareDistribution
2016.05.18 09:06:46.2539464 5392  9584  Shared          UpdateNetworkState Ipv6, cNetworkInterfaces = 2.
2016.05.18 09:06:46.2540616 5392  9584  Shared          UpdateNetworkState Ipv4, cNetworkInterfaces = 2.
2016.05.18 09:06:46.2543931 5392  9584  Shared          Network state: Connected
2016.05.18 09:06:46.2882847 5392  9584  Shared          UpdateNetworkState Ipv6, cNetworkInterfaces = 2.
2016.05.18 09:06:46.2882919 5392  9584  Shared          UpdateNetworkState Ipv4, cNetworkInterfaces = 2.
2016.05.18 09:06:46.2882972 5392  9584  Shared          Power status changed
2016.05.18 09:06:46.3064666 5392  9584  Agent               Timer: 29A863E7-8609-4D1E-B7CD-5668F857F1DB, Expires 2016-05-19 06:31:27, not idle-only, not network-only
2016.05.18 09:06:46.3065157 5392  10184 Agent           Initializing global settings cache
2016.05.18 09:06:46.3065166 5392  10184 Agent           WSUS server: https://wsus.domain.tld:8531
2016.05.18 09:06:46.3065171 5392  10184 Agent           WSUS status server: https://wsus.domain.tld:8531
2016.05.18 09:06:46.3065171 5392  10184 Agent           Target group: (Unassigned Computers)
2016.05.18 09:06:46.3065175 5392  10184 Agent           Windows Update access disabled: No
2016.05.18 09:06:46.3135035 5392  9584  Agent           Initializing Windows Update Agent
2016.05.18 09:06:46.3135937 5392  9584  DownloadManager Download manager restoring 0 downloads
2016.05.18 09:06:46.3136302 5392  9584  Agent           CPersistentTimeoutScheduler | GetTimer, returned hr = 0x00000000
2016.05.18 09:06:46.4306662 5392  3876  DownloadManager PurgeExpiredFiles::Found 0 expired files to delete.
2016.05.18 09:06:46.4482180 5392  3876  DownloadManager PurgeExpiredUpdates::Found 352 non expired updates.
2016.05.18 09:06:46.5430197 5392  3876  DownloadManager PurgeExpiredUpdates::Found 0 expired updates.
2016.05.18 09:06:46.5439926 5392  3876  Shared          Effective power state: AC
2016.05.18 09:06:46.5439935 5392  3876  DownloadManager Power state change detected. Source now: AC
2016.05.18 09:06:47.6415592 5392  10184 Agent           * START * Queueing Finding updates [CallerId = UpdateOrchestrator  Id = 1]
2016.05.18 09:06:47.6415641 5392  10184 Agent           Added service 00000000-0000-0000-0000-000000000000 to sequential scan list
2016.05.18 09:06:47.6415989 5392  10184 ComApi          Search ClientId = UpdateOrchestrator
2016.05.18 09:06:47.6422161 5392  5792  Agent           * END * Queueing Finding updates [CallerId = UpdateOrchestrator  Id = 1]
2016.05.18 09:06:47.6424548 5392  5792  Agent           * START * Finding updates CallerId = UpdateOrchestrator  Id = 1
2016.05.18 09:06:47.6424553 5392  5792  Agent           Online = Yes; Ignore download priority = No
2016.05.18 09:06:47.6424557 5392  5792  Agent           Criteria = IsInstalled=0 and DeploymentAction='Installation' or IsPresent=1 and DeploymentAction='Uninstallation' or IsInstalled=1 and DeploymentAction='Installation' and RebootRequired=1 or IsInstalled=0 and DeploymentAction='Uninstallation' and RebootRequired=1""
2016.05.18 09:06:47.6424580 5392  5792  Agent           ServiceID = {00000000-0000-0000-0000-000000000000} Third party service
2016.05.18 09:06:47.6424584 5392  5792  Agent           Search Scope = {Machine}
2016.05.18 09:06:47.6424611 5392  5792  Agent           Caller SID for Applicability: S-1-5-21-439752975-2252521825-1950776753-1221
2016.05.18 09:06:47.6424615 5392  5792  Agent           RegisterService is set
2016.05.18 09:06:47.6430640 5392  5792  Misc            Got WSUS Client/Server URL: https://wsus.domain.tld:8531/ClientWebService/client.asmx""
2016.05.18 09:06:48.2320285 5392  5792  ProtocolTalker  ServiceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}, Server URL = https://wsus.domain.tld:8531/ClientWebService/client.asmx
2016.05.18 09:06:48.2320370 5392  5792  ProtocolTalker  OK to reuse existing configuration
2016.05.18 09:06:48.2320388 5392  5792  ProtocolTalker  OK to reuse existing configuration
2016.05.18 09:06:48.2320415 5392  5792  ProtocolTalker  Cached cookie has expired or new PID is available
2016.05.18 09:06:48.2320531 5392  5792  Misc            Got WSUS SimpleTargeting URL: https://wsus.domain.tld:8531""
2016.05.18 09:06:48.2325306 5392  5792  ProtocolTalker  Initializing simple targeting cookie, clientId = bd081a5e-70af-4f17-9a1d-a8e72bde3bd7, target group = <NULL>, DNS name = laptop.domain.tld
2016.05.18 09:06:48.2325315 5392  5792  ProtocolTalker    Server URL = https://wsus.domain.tld:8531/SimpleAuthWebService/SimpleAuth.asmx
2016.05.18 09:06:48.2325547 5392  5792  WebServices     Auto proxy settings for this web service call.
2016.05.18 09:06:48.3641169 5392  5792  WebServices     Auto proxy settings for this web service call.
2016.05.18 09:06:48.3809440 5392  5792  WebServices     WS error: Fehler bei der Kommunikation mit dem Endpunkt bei https://wsus.domain.tld:8531/ClientWebService/client.asmx"."
2016.05.18 09:06:48.3809453 5392  5792  WebServices     WS error: Vom Server wurde der HTTP-Statuscode 404 (0x194)" mit dem Text "Not Found" zurückgegeben."
2016.05.18 09:06:48.3809462 5392  5792  WebServices     WS error: Die angeforderte Ressource wurde nicht gefunden.
2016.05.18 09:06:48.3809480 5392  5792  WebServices     Web service call failed with hr = 80244019.
2016.05.18 09:06:48.3809485 5392  5792  WebServices     Current service auth scheme=0.
2016.05.18 09:06:48.3809489 5392  5792  WebServices     Current Proxy auth scheme=0.
2016.05.18 09:06:48.3809601 5392  5792  ProtocolTalker  PTError: 0x80244019
2016.05.18 09:06:48.3809627 5392  5792  ProtocolTalker  GetCookie_WithRecovery failed  0x80244019
2016.05.18 09:06:48.3809654 5392  5792  ProtocolTalker  RefreshCookie failed 0x80244019
2016.05.18 09:06:48.3809685 5392  5792  ProtocolTalker  RefreshPTState failed 0x80244019
2016.05.18 09:06:48.3809721 5392  5792  ProtocolTalker  SyncUpdates round trips: 0
2016.05.18 09:06:48.3809730 5392  5792  ProtocolTalker  Sync of Updates 0x80244019
2016.05.18 09:06:48.3809743 5392  5792  ProtocolTalker  SyncServerUpdatesInternal failed 0x80244019
2016.05.18 09:06:48.3816160 5392  5792  Agent           Failed to synchronize, error = 0x80244019
2016.05.18 09:06:48.3855564 5392  5792  Agent           Exit code = 0x80244019
2016.05.18 09:06:48.3855680 5392  5792  Agent           * END * Finding updates CallerId = UpdateOrchestrator  Id = 1
2016.05.18 09:06:48.3866292 5392  1804  ComApi          *RESUMED* Search ClientId = UpdateOrchestrator
2016.05.18 09:06:48.3870464 5392  1804  ComApi          Updates found = 0
2016.05.18 09:06:48.3870473 5392  1804  ComApi          Exit code = 0x00000000, Result code = 0x80244019
2016.05.18 09:06:48.3870478 5392  1804  ComApi          * END *   Search ClientId = UpdateOrchestrator
2016.05.18 09:06:48.3873302 5392  10184 ComApi          ISusInternal:: DisconnectCall failed, hr=8024000C
2016.05.18 09:06:59.9254382 5392  9584  Agent           Earliest future timer found:
2016.05.18 09:06:59.9254601 5392  9584  Agent               Timer: 29A863E7-8609-4D1E-B7CD-5668F857F1DB, Expires 2016-05-19 06:31:27, not idle-only, not network-only
2016.05.18 09:06:59.9260781 5392  9584  Misc            WUTaskManager couldn't register scheduled start task, hr=80070003
2016.05.18 09:06:59.9465158 5392  9584  Shared          * END * Service exit Exit code = 0x240001

    Angeblich wird die URL nicht gefunden (404) obwohl ich sie im Browser ganz normal ansurfen kann. Mich irritiert darüber hinaus, dass die URL mit komischen Anführungszeichen am Ende angegeben wird (https://wsus.domain.tld:8531/ClientWebService/client.asmx"") obwohl diese weder in der GPO noch in der Registry zu finden sind. Ist das ein Darstellungsfehler oder liegt es daran, dass die Updates eine 404 Not Found zurückmelden? Wenn ich die URL mitsamt der "" eingebe, bekomme ich natürlich eine 404.

    Habe WSUS bereits neuinstalliert (mit komplettem IIS Reset zuvor) und hänge wieder am gleichen Problem. Komischerweise reporten sich die Clients aber an den WSUS, da sie in der MMC des WSUS auftauchen. Allerdings ohne detaillierte Daten (z.B. Windowsversion = 0.0) - irgendwas scheint da echt schief zu laufen.

    Hat jemand eine Idee, was ich da noch weiter troubleshooten kann?

    Danke im Voraus!

    Mittwoch, 18. Mai 2016 07:23
    |

Alle Antworten

  • Question
    Anmelden
    1
    Anmelden
    > Wenn ein Client (egal ob Windows 7 oder 10) nun Updates abrufen möchte,
    > kommt nach einigen Sekunden die Fehlermeldung 0x80244019 und der Vorgang
    > wird beendet.
     
    Winfried hat mal ein Howto dazu geschrieben:
    Passt Das zu Deiner Konfiguration?
     
    Mittwoch, 18. Mai 2016 08:57
    |
  • Question
    Anmelden
    0
    Anmelden

    Moin,

    die Anleitung hatte ich zwar nicht auf dem Schirm, bin sie jetzt aber zur Sicherheit noch einmal durchgegangen. Passt soweit alles - Fehler bleibt bestehen.

    Mittwoch, 18. Mai 2016 09:40
    |
  • Question
    Anmelden
    1
    Anmelden

    Am 18.05.2016 schrieb Admonstrator:

    ich kämpfe aktuell mit einem Problem, welches mir noch nicht so ganz einleuchten will & hoffe auf eure Unterstützung. Gegeben ist ein neuer WSUS Server auf 2012R2 Basis, der unter dem Namen/wsus.domain.tld/ erreichbar ist. Er wurde auf SSL konfiguriert (im IIS die WSUS-Verwaltungsseite auf SSL gesetzt und/wsutil configuressl wsus.domain.tld/ ausgeführt.), hat MSSQL als Backend-DB und zeigt auch keine Fehler an.

    Zertifikat erstellt und auf die Clients verteilt? Im IIS auch
    zugewiesen? Nicht alle Verzeichnisse im IIS dürfen auf SSL gestellt
    werden, das hast Du berücksichtigt?

    Per GPO wurde der WSUS an Clients verteilt (mit der URL https://wsus.domain.tld:8531) und die Clients können diese Seite auch aufrufen. Es hängt kein Proxy dazwischen und keine Firewall macht Probleme.

    Wenn ein Client (egal ob Windows 7 oder 10) nun Updates abrufen möchte, kommt nach einigen Sekunden die Fehlermeldung 0x80244019 und der Vorgang wird beendet. Per/Get-WindowsUpdateLog/ kam folgendes heraus:

    Läuft auf dem WSUS noch etwas im IIS? AV-Scanner oder ähnliches?
    Können die Clients sich melden, wenn der WSUS auf Port 8530 läuft?

    Habe WSUS bereits neuinstalliert (mit komplettem IIS Reset zuvor) und hänge wieder am gleichen Problem. Komischerweise reporten sich die Clients aber an den WSUS, da sie in der MMC des WSUS auftauchen. Allerdings ohne detaillierte Daten (z.B. Windowsversion = 0.0) - irgendwas scheint da echt schief zu laufen.

    Hat jemand eine Idee, was ich da noch weiter troubleshooten kann?

    Evtl. mal einen neuen Server aufsetzen, WSUS aktivieren, Port 8530
    lassen und testen. Funktioniert alles? Dann SSL aktivieren. HowTo hat
    Martin ja schon genannt.

    Gibt es evtl. auf dem WSUS in %programfiles%\Update Services\Logs in
    der SoftwareDistribution.log Fehlermeldungen?

    Servus
    Winfried

    WSUS Package Publisher: http://wsuspackagepublisher.codeplex.com/
    HowTos für WSUS/WPP: http://www.wsus.de/wpp
    GPO's: http://www.gruppenrichtlinien.de
    NNTP-Bridge für MS-Foren: http://communitybridge.codeplex.com/

    Mittwoch, 18. Mai 2016 14:43
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Winfried,

    da hab ich ja direkt einen Experten erwischt - yey!

    Habe das ganze Spielchen jetzt noch mal komplett durchgearbeitet. Streng nach Anleitung und mit vorherigem Test ohne SSL auf Port 8530. Ohne SSL funktioniert alles fehlerfrei. Sobald ich SSL aktiviere, kriege ich wieder meine 404 Meldungen.

    Cert wird per CA signiert und ist demnach bei den Clients gültig. Auch ansonsten bin ich allen Anweisungen gefolgt.

    In der SoftwareDistribution.log taucht ebenfalls folgendes auf:

    2016-05-19 06:59:51.075 UTC	Error	WsusService.9	HmtWebServices.CheckClientWebService	Client WebService WebException:System.Net.WebException: Fehler bei der Anforderung mit HTTP-Status 404: Not Found.

    Andere Anwendungen mit IIS laufen nicht, es läuft noch arcServe UDP, aber per Tomcat/Apache und auf einem gänzlich anderen Port. Ich werde es einfach aufgeben und das Ding jetzt erstmal ohne SSL laufen lassen. 

    Schlau werde ich aus den Fehlern dennoch nicht. Leider.

    Dennoch Danke für etwaige Ideen & Tipps!



    Donnerstag, 19. Mai 2016 07:05
    |
  • Question
    Anmelden
    1
    Anmelden

    Hi,

    da ich das heute auch durchgespielt hatte, hier der Hinweis aus dem WSUS Blog: https://blogs.technet.microsoft.com/wsus/

    Bei mir haben diese "Ideen", wie das Problem trotz KB3159706 gelöst werden kann, nicht geholfen. Also habe ich das KB3159706 vom WSUS deinstalliert und da der WSUS der einzige war, der das installieren wollte, hab ich das Update auch direkt abgelehnt.

    Vielleicht hilft dir das :)

    Donnerstag, 19. Mai 2016 12:12
    |
  • Question
    Anmelden
    1
    Anmelden

    Am 19.05.2016 schrieb Admonstrator:

    Habe das ganze Spielchen jetzt noch mal komplett durchgearbeitet. Streng nach Anleitung und mit vorherigem Test ohne SSL auf Port 8530. Ohne SSL funktioniert alles fehlerfrei. Sobald ich SSL aktiviere, kriege ich wieder meine 404 Meldungen.

    Du hast auch das hier beachtet?

    **********
    Jetzt muss auf diesen Virtuellen Seiten noch die SSL-Verschlüsselung
    aktiviert werden.

    ApiRemoting30
    ClientWebService
    DSSAuthWebService
    ServerSyncWebService
    SimpleAuthWebService

    Abbildung 27

    Mit einem Doppelklick auf die jeweilige Seite wechseln. Die
    SSL-Einstellungen auf der Startseite öffnen und SSL erforderlich
    aktivieren. Der Rest kann so bleiben. Rechts im Aktionsbereich auf
    Übernehmen klicken. Für jede der o.g. Seiten muss dies Konfiguration
    wiederholt werden.
    **********

    Exakt so beachtet? Nicht zu viel oder zu wenig gemacht?

    Cert wird per CA signiert und ist demnach bei den Clients gültig. Auch ansonsten bin ich allen Anweisungen gefolgt.
    In der SoftwareDistribution.log taucht ebenfalls folgendes auf:

    2016-05-19 06:59:51.075 UTC        Error        WsusService.9
HmtWebServices.CheckClientWebService        Client WebService
WebException:System.Net.WebException: Fehler bei der Anforderung mit
HTTP-Status 404: Not Found.

    Kompletten Server anschließend schon neu gestartet?

    Dennoch Danke für etwaige Ideen & Tipps!

    Kannst Du einen Testserver aufsetzen und das wiederholen?

    Servus
    Winfried

    WSUS Package Publisher: http://wsuspackagepublisher.codeplex.com/
    HowTos zum WSUS Package Publisher http://www.wsus.de/wpp
    GPO's: http://www.gruppenrichtlinien.de
    NNTP-Bridge für MS-Foren: http://communitybridge.codeplex.com/

    Donnerstag, 19. Mai 2016 16:31
    |
  • Question
    Anmelden
    0
    Anmelden

    Hey,

    ja, ich hatte die SSL-Konfiguration entsprechend beachtet und auch den ein oder anderen Neustart durchgeführt. Einen Testserver werde ich mir diese Woche einmal zu Gemüte führen.

    Danke!

    Montag, 23. Mai 2016 07:22
    |
  • Question
    Anmelden
    1
    Anmelden

    Am 23.05.2016 schrieb Admonstrator:

    ja, ich hatte die SSL-Konfiguration entsprechend beachtet und auch den ein oder anderen Neustart durchgeführt. Einen Testserver werde ich mir diese Woche einmal zu Gemüte führen.

    Hast Du denn das fehlerhafte Update KB3159706 auch installiert? Hast
    Du die Anpassungen gem. dem Artikel alle vorgenommen?

    In diesem Thread hat jemand die gleiche Fehlermeldung:
    http://social.Technet.microsoft.com/Forums/en-US/winserverwsus/thread/487db77b-c203-4ed6-afe5-246953579727#487db77b-c203-4ed6-afe5-246953579727

    Servus
    Winfried

    WSUS Package Publisher: http://wsuspackagepublisher.codeplex.com/
    HowTos zum WSUS Package Publisher http://www.wsus.de/wpp
    GPO's: http://www.gruppenrichtlinien.de
    NNTP-Bridge für MS-Foren: http://communitybridge.codeplex.com/

    Montag, 23. Mai 2016 17:04
    |
  • Question
    Anmelden
    0
    Anmelden

    Am 19.05.2016 schrieb Winfried Sonntag [MVP]:
    Nabend,

    Du hast auch das hier beachtet?

    Ich kann mich dunkel an den ersten SSL WSUS bei mir erinnern, da hab ich den letzten Step "überlesen". ;)
    Der exakte Befehl für das hier beschriebene HowTo: WSUSUtil.exe ConfigureSSL W2012 [ENTER]
     Bye
    Norbert

    Dilbert's words of wisdom #32:
    If it wasn't for the last minute, nothing would get done.
    nntp-bridge Zugriff auf die MS Foren wieder möglich: https://communitybridge.codeplex.com/

    Dienstag, 24. Mai 2016 21:03
    |
  • Question
    Anmelden
    0
    Anmelden

    Am 24.05.2016 schrieb Norbert Fehlauer [MVP]:

    Am 19.05.2016 schrieb Winfried Sonntag [MVP]:
    Nabend,

    Du hast auch das hier beachtet?

    Ich kann mich dunkel an den ersten SSL WSUS bei mir erinnern, da hab ich den letzten Step "überlesen". ;)

    Hmm, daran kann ich mich auch noch erinnern. :)

    Servus
    Winfried

    WSUS Package Publisher: http://wsuspackagepublisher.codeplex.com/
    HowTos zum WSUS Package Publisher http://www.wsus.de/wpp
    GPO's: http://www.gruppenrichtlinien.de
    NNTP-Bridge für MS-Foren: http://communitybridge.codeplex.com/

    Mittwoch, 25. Mai 2016 04:51
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo zusammen.

    Ich kämpfe mit dem gleichen Problem: Server 2012 R2, WSUS hinzugefügt, konfiguriert, SSL eingerichtet, läuft.

    Damit man auch die Informationen lesen kann den Report Viewer 2008 und das erforderliche .Net 3.5 installiert, läuft immer noch.

    Nun die letzten, online abgerufenen, Updates installiert (wegen .Net 3.5) und das war es. :-(

    Aufruf der URL im IE zeigt mir dass das Zertifikat gültig ist. Auch registrieren sich die Clients wie oben genannt. Die Meldungen sind die gleichen wie oben.

    Den Server habe ich jetz schon 2x aufgesetzt, daher vermute ich, das es an einen von den .Net-Updates liegt.

    Auch ein erneutes starten der Nachinstallation änderte nichts ("%ProgramFiles%\Update Services\Tools\wsusutil.exe" postinstall). Danach musste ich allerdings für die virtuellen Seiten wieder die SSL-Verschlüsselung aktivieren.

    Ich werde jetzt erst mal SSL abschalten und schauen was sich dann ergibt.

    Donnerstag, 2. Juni 2016 08:12
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo,

    hier mal der aktuelle Stand:

    Der internen Updatedienst zum Ermitteln von Updates läuft nur unverschlüsselt,

    die Verbindung Intranetserver für die Statistik läuft auch verschlüsselt.

    Ich habe es auch mit einem neuen Zertifikat versucht, aber sobald der Updatedienst über eine verschlüsselte Verbindung laufen soll wird der Server nicht erreicht (Fehler 404). Die Firewall habe ich auch schon deaktiviert.

    Also so wie es jetzt ist scheint es zu funktionieren; die Clients bekommen Updates und der Server zeigt den Status der Clients an.

    Vielleicht findet sich ja noch eine Lösung, ich werde es erst einmal so lassen.

    Viel Erfolg noch. :-)

    Stefan

    Donnerstag, 2. Juni 2016 15:26
    |
  • Question
    Anmelden
    0
    Anmelden
    > Der /internen Updatedienst zum Ermitteln von Updates/ läuft nur
    > unverschlüsselt,
    > die /Verbindung Intranetserver für die Statistik/ läuft auch verschlüsselt.
     
    @Winfried: Dunkle Erinnerung, dass das schon immer so war?!? Dass man
    nur die Reporting-URL auf https umstellen durfte und die andere nicht -
    aber ich kann mich täuschen...
     
    Donnerstag, 2. Juni 2016 15:40
    |
  • Question
    Anmelden
    0
    Anmelden

    Am 02.06.2016 schrieb Martin Binder [MVP]:

    nur die Reporting-URL auf https umstellen durfte und die andere nicht -

    Nein bei mir stehen immer beide auf https. Aber man braucht trotzdem den http Port für den Download.

    Bye
    Norbert

    Donnerstag, 2. Juni 2016 21:14
    |