Issue: Web Services cannot publish the certificate requested by the device because it cannot connect to the User Services data store on the pool where the user is homed. An event is logged to the IIS event log, noting that the data store cannot be reached: "data store unavailable." This can occur anytime the User Services store is not located on the same server as Web Services.

Resolution: This may be a sporadic error indicating a connectivity problem between the Registrar the device is connecting to, or may indicate an ongoing problem. In the case of a sporadic error, retry the device’s request by restarting the device. To do this, unplug the device’s power supply, wait a few seconds, and then reconnect power. The device cycles through the connection process, before sending the certificate publish request again. This time Web Services is able to publish the user’s certificate in the user’s home pool and returns the certificate to the device.To determine whether this is a wider problem and is not specific to the device, run the test-CsPhoneBootstrap synthetic transaction:

	Copy Code
test-CsPhoneBootstrap -PhoneorExt <phone or ext of user> -PIN <user's PIN> -UserSipAddress <user's SIP URI> -verbose

This transaction demonstrates that the user’s phone number and PIN match the user’s URI.

You can add the parameters –TargetCertProvWSURL <web services URL> and –TargetFqdn <Registrar FQDN> to bypass DHCP discovery.

Issue: The certificate that is generated by the Web Services cannot be generated or published due to a problem on the Registrar.

Resolution: Check the health of the Registrar by first looking in the Microsoft System Center Operations Manager Management Pack for any alerts regarding the Registrar that the device is connecting to. In System Center Operations Manager, browse to the Registrar and view any critical alerts or state changes indicating a problem that is not critical. Follow the instructions to resolve the problem.If Operations Manager is not available, use the following synthetic transaction to check.

	Copy Code
$cred = get-credential test-CsClientAuth -UserSipAddress <sip address> -UserCredential $cred -TargetFQDN

Note:

If you want to use DHCP discovery, do not specify –TargetFQDN. If you do not want to use DHCP discovery, provide the destination fully qualified domain name (FQDN) into the synthetic transaction and DHCP discovery will be bypassed. The output should show you at what point authentication failed (for example, the DHCP discovery message may not receive a response). Follow the directions in the transaction output to resolve the problem. You can check that the web server is running by looking at the certprov.log in Ocslogger (that is, generated on each of the rtcsrv instances within the pool). You need to get logs from every server in the pool because at this point we do not know which one the device is being directed to. After the problems have been resolved, restart the device to trigger a new connection attempt. This time the certificate should be published to the pool on which the user is homed and returned to the device.

Issue: The device cannot verify the certificate presented by Web Services for TLS communications. The device uses the root certificate chain downloaded when the device first connects to the web server. If this chain does not have a full path of trust from the root certification authority (CA) to the web server, the certificate the web server presents cannot be verified.

Resolution: The device has a number of certificates from well-known CAs when it ships. It is important that the certificate used to identify the web server is issued by a CA that has a chain of trust up to one of these root CAs. If this is not the case, the device will not be able to validate the certificate the server presents for TLS communications.

You can bypass the Receive and Publish Certificate step by using a USB cable to connect the device to a computer running Lync. This process performs the get and publish certificate and will also install the certificate on to the device.

Concepts