This information is also cross-posted at http://www.ucblogs.net/blogs/ocs

On the About screen you'll see:

           Last Update Status: (0x####/0x#####)

The two hexadecimal numeric codes are for the benefit of debugging an issue when the Phone Edition can't contact
the Update Server. The normal state is (0x00/0). If the Phone Edition can't update, the user will read these
codes to the Administrator.

The first field is a WinInet error code. An error here would indicate a problem contacting the server.

The list of possible values can be found at:
http://support.microsoft.com/kb/193625

The commonly occurring values are

   Code        Error Message and Description
   -----       -----------------------------
   12002       ERROR_INTERNET_TIMEOUT
   (0x2ee2)    The request has timed out.

   12005       ERROR_INTERNET_INVALID_URL
   (0x2ee5)    The URL is invalid.

   12007       ERROR_INTERNET_NAME_NOT_RESOLVED
   (0x2ee7)    The server name could not be resolved.

   12028       ERROR_INTERNET_ITEM_NOT_FOUND
   (0x2efc)    The requested item could not be located.

   12029       ERROR_INTERNET_CANNOT_CONNECT
   (0x2efd)    The attempt to connect to the server failed.

   12030       ERROR_INTERNET_CONNECTION_ABORTED
   (0x2efe)    The connection with the server has been terminated.

   12031       ERROR_INTERNET_CONNECTION_RESET
   (0x2eff)    The connection with the server has been reset.

The second field is an HTTP status code: An error here would indicate that the server was contacted,
but failed to handle our request. The list of possible values can be found at:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

The commonly occurring values are

10.4.2 401 Unauthorized
The request requires user authentication. The response MUST include a WWW-Authenticate header field (section 14.47) containing a challenge applicable to the requested resource. The client MAY repeat the request with a suitable Authorization header field (section 14.8). If the request already included Authorization credentials, then the 401 response indicates that authorization has been refused for those credentials. If the 401 response contains the same challenge as the prior response, and the user agent has already attempted authentication at least once, then the user SHOULD be presented the entity that was given in the response, since that entity might include relevant diagnostic information. HTTP access authentication is explained in "HTTP Authentication: Basic and Digest Access Authentication" [43].

10.4.4 403 Forbidden
The server understood the request, but is refusing to fulfill it. Authorization will not help and the request SHOULD NOT be repeated. If the request method was not HEAD and the server wishes to make public why the request has not been fulfilled, it SHOULD describe the reason for the refusal in the entity. If the server does not wish to make this information available to the client, the status code 404 (Not Found) can be used instead.

10.4.5 404 Not Found
The server has not found anything matching the Request-URI. No indication is given of whether the condition is temporary or permanent. The 410 (Gone) status code SHOULD be used if the server knows, through some internally configurable mechanism, that an old resource is permanently unavailable and has no forwarding address. This status code is commonly used when the server does not wish to reveal exactly why the request has been refused, or when no other response is applicable.

10.5.1 500 Internal Server Error
The server encountered an unexpected condition which prevented it from fulfilling the request.

10.5.2 501 Not Implemented
The server does not support the functionality required to fulfill the request. This is the appropriate response when the server does not recognize the request method and is not capable of supporting it for any resource.

10.5.3 502 Bad Gateway
The server, while acting as a gateway or proxy, received an invalid response from the upstream server it accessed in attempting to fulfill the request.

10.5.4 503 Service Unavailable
The server is currently unable to handle the request due to a temporary overloading or maintenance of the server. The implication is that this is a temporary condition which will be alleviated after some delay. If known, the length of the delay MAY be indicated in a Retry-After header. If no Retry-After is given, the client SHOULD handle the response as it would for a 500 response.

      Note: The existence of the 503 status code does not imply that a
      server must use it when becoming overloaded. Some servers may wish
      to simply refuse the connection.