Lync DHCP Discovery

Question

Hi
As I understand, the Lync 2010 software installed on a Windows 7 PC, will send a DHCP request (class ID MS-UC-Client) in an attempt to locate SIP server information.
I have an issue where our network authorization system (which uses DHCP class id as one of the identifying attributes of a device) is interpreting the MS-UC-Client
DHCP request as meaning that a different device is now on the network port, and thus it fails the authorization and kicks the client off the network.
The problem is that this issue occurs intermittently. I can see via a Wireshark trace that the Lync 2010 client does not always perform the DHCP request when we connect the Windows 7 computer into the network.
Does anyone know if Lync 2010 only performs the DHCP request in certain circumstances.   Is there a way I can force Lync 2010 software to make a DHCP request, so I can troubleshoot my issue further. 

Answer 1

Do we have the latest updated installed for Lync 2010?
Post Cu4 update
                              The client sign-in process has changed
quite a bit since the introduction of the mobility discovery process.
SRV records are used to assist the mobile clients with the sign-in
process, no matter whether the mobile clients are inside or outside the
organization. For example, if the domain is contoso.com, the path for
signing in follows this order:
                              lyncdiscoverinternal.contoso.com (A
record for the Autodiscover service for internal connections directed to
internal Web services)                             
                              lyncdiscover.contoso.com (A record for the Autodiscover service for external Web
services)                             
                              _sipinternaltls._tcp.contoso.com (SRV record for internal TLS connections)                             
                              _sipinternal._tcp.contoso.com (SRV record for internal TCP connections)                             
                              _sip._tls.contoso.com (SRV record for external TCP connections)                             
                              sipinternal.contoso.com (A record for the Front End pool)                             
                              sip.contoso.com (A record for the Front
End pool when the client is on the internal network; A record for the
Access Edge Server when the client is external with no VPN access)                             
                              sipexternal.contoso.com (A record for
the Access Edge Server when the client is external with no VPN access)
                              In this new sign-in process, the client's
first DNS resolution request is sent to the lyncdiscoverinternal and
lyncdiscover Fully Qualified Domain Names (FQDNs). This means that
internal Lync clients could potentially be redirected out to the reverse
proxy and treated like external clients. This is why the Autodiscover
DNS records are a huge part of the deployment picture and need to be
realigned to their proper locations. The lyncdiscoverinternal FQDNs
should exist only in the internal DNS and point to the internal Front
End Servers (or Directors Servers if you have them in place). The
lyncdiscover DNS A record should be published only in an external DNS
and point to a reverse proxy server. In the event you have an internal
DNS A record for lyncdiscover, it should still point to the external IP
address that resolves to the reverse proxy server and act in the same
manner.
PLEASE REMEMBER, if you see a post that helped you please click "Vote As Helpful" and if it answered your question please click "Mark As Answered"