Issue: The DHCP server must be set up to return the Web Services URL in option 43 (for requests where the class ID is specified as ms-uc-client). If it is not, the device will fail over to use DNS instead. However, there may not be a redundant DNS server entry for the Registrar cluster in the site where the device is connecting from, and so DNS is a less reliable option.

Resolution: First, open the Lync Server Management Shell and run the test-CsPhoneBootstrap synthetic transaction:

	Copy Code
test-CsPhoneBootstrap -TargetFQDN <fqdn of DHCP server>-PhoneOrExt <phone or extension of the user on the device seeing this failure> -PIN <pin of the user on the device seeing this failure> -verbose

This indicates whether DHCP is returning the URL or not.

If DHCP is not returning the URL, configure DHCP to do this. This can be done by using DHCPUtil.exe, to determine which DHCP options have been set up on a DHCP server. DHCPUtil can also help set up any missing option correctly. It can be used to set up Option 43. For details about using DHCPUtil, see Configuring DHCP Options to Enable Sign-in for IP Phones.

You should also check that the URL being returned resolves correctly to Web Services. To do this, type the URL into a web browser and verify that an HTTP 404 – file not found error does not appear.

Issue: The DHCP server must be set up to return the Registrar FQDN in option 120 (for requests where the class ID is specified as ms-uc-client). If it is not, the device fails over to use DNS instead. However, there may not be a redundant DNS server entry for the Registrar cluster in the site where the device is connecting from, and so DNS is a less reliable option. In this case, the device may successfully authenticate, but fail to begin SIP communications with Lync Server.

Resolution: First, open the Lync Server Management Shell and run the test-CsPhoneBootstrap synthetic transaction:

	Copy Code
test-CsPhoneBootstrap -PhoneOrExt <phone number or extension> -PIN <pin for that user> -verbose

If this fails, it is likely that DHCP does not have option 120 set up. To set it up, use DHCPUtil.exe to check that the DHCP server has option 120 set up and is returning the correct FQDN for the Registrar(s).

It is possible to include up to two Registrar FQDNs in this record. The client tries each one until a successful query response is received. Additionally, verify that there is an authoritative DNS SRV record set up for the Registrar.

Issue: The DHCP server that the Aries device is connecting to might not return the 120 and 43 options the device uses for connection. You can determine this by obtaining a DHCP log from the device at \DSK1\logs\cpsw3g.log. For details, see How to Get Log Files Off a Device.

Resolution: Check your DHCP server to see if it is configured to return Options 120 and 43. You can use DHCPUtil.exe to act as a client and see what the DHCP Server returns. For details, see Using DHCPUtil. If it is not configured to return these options and you are using the DHCP server on the Registrar or Windows DHCP server to learn how to configure the options, see Using DHCP to Assign IP Addresses to Devices and Configuring DHCP Options to Enable Sign-in for IP Phones. If you are using another DHCP server, refer to the configuration documentation for that server.

The device performs a DHCP option 120 query in parallel with a DNS SRV lookup.

DHCP responses containing FQDNs are always cached, regardless of the outcome of the DNS SRV lookup.

After the device has successfully authenticated and connected to Registrar, the previous DHCP/DNS results are cleared from the cache and the values are stored.