This article serves as a follow-up to a few previous articles which will further explain some of the requirements, capabilities, and limitations of the Lync Phone Edition firmware which appear to still be unclear to some and seem to warrant further discussion. It does not cover complete feature functionality but instead focuses on provisioning and operation of the client as well as some of the most common issues.
Additionally the focus of this article is primarily on the Lync Phone Edition firmware which runs on the Aries family of devices (Polycom CX500/600/3000, Aastra 6721ip/6725ip, and HP/SNOM 4110ip/420ip) but also references the original Tanjay version (Polycom CX7000, LG-Nortel 8540) on a few occasions. The following list of topics are discussed in this article.
- Authentication Methods
- Exchange Integration
- External Usage
- Common Issues
- Firmware Updates
It is suggested to review the following blog articles as some of the concepts in this article are explained in much more depth and thus a solid understanding of how the devices function can often be key to interpreting the observed behavior of the device.
Lync supports a variety of different authentication methods and understanding which method is used, when, and why is important when troubleshooting any issues.
There are currently three different types of authentication supported by Lync Server 2010: NTLM, Kerberos, and Certificate.
By default Kerberos is not completely functional throughout Lync Server as some additional configuration steps must be completed first. But both NTLM and Certificate authentication methods are enabled and used by default for both the Windows Lync client and the Lync Phone Edition client.
Although NTLM authentication needs no introduction, this new-for-Lync certificate based method is still a mystery to many. It is more specifically known as TLS-DSK and for some background on what it is an how it works the following materials are recommended reading.
- MSDN SIP Protocol Overview: http://msdn.microsoft.com/en-us/library/dd905435.aspx
- Microsoft Lync 2010 Technology Explained: http://channel9.msdn.com/Events/TechEd/Europe/2010/UNC310
As the Windows Lync client supports both types of authentication what typically happens is that a user signs into the application using their Active Directory credentials for the first time and during this process the Lync Server will submit a client certificate to that user which the client application then stores in its local cache. This client certificate can be used for future authentication attempts against any Lync Server registrar (Front End, Director, Edge, SBA) and explains why the Lync client can still successfully sign-in even after a user’s AD account password has expired (or the account has even been disabled). This cached client certificate on endpoints can be valid in Lync Server for between 6 to 12 months, which is typically much longer than most environment’s AD password expiration policies. By default the Lync client requests a validity period using the minimum value (180 days) when a user signs into the client on a specific endpoint for the first time.
For more details on the certificate validity parameters see the Set-CsWebServiceConfiguration cmdlet documentation.
MaxValidityPeriodHours When using certificate authentication, clients can request the period of time (in hours) that the certificate remains valid. MaxValidityPeriodHours represents the maximum amount of time a client can request.
MaxValidityPeriodHours can be any integer value between 8 hours and 8760 hours (365 days). The default value is 8760.
MinValidityPeriodHours When using certificate authentication, clients can request the period of time (in hours) that the certificate remains valid. MinValidityPeriodHours represents the minimum amount of time a client can request.
MinValidityPeriodHours can be any integer value between 8 hours and 4320 hours (180 days). The default value is 8
The new client certificate is then replicated to all other Lync registrars so that if that same user later attempts registration to a different servers from a different client endpoint then the same issued certificate is available to be downloaded to the new endpoint. Although the client certificates cannot be viewed under Lync Phone Edition, there are a few different ways to view them on a Windows workstation.
- Run mmc.exe and then add the Certificates snap-in. Select My User Account (instead of the Computer account which is normally chosen when dealing with server certificates).
- Expand the Personal container and then the Certificate container to see all of the client certificate stored in the current Windows user’s profile.
In the example above it is evident that multiple different Lync users have signed into Lync within the same Windows user profile. Normally only one client certificate issued by ‘Communications Server’ would appear in a standard user’s store.
- Alternatively open the User Accounts control panel in Windows 7 and select Manage your credentials to see the same list of client certificates under the Generic Credentials header.
In this example one important distinction can be made in that the same set of credentials is sometimes listed twice (with either an OCS:1 or EWS:1 extension) and each showing a different username (SIP URI versus Domain\Username).
As covered extensively in previous articles, PIN authentication is only available on the Aries family of Lync Phone Edition devices and this method of signing into a phone using only the user’s phone number (or extension) leverages only the TLS-DSK certificate method. Standard NTLM simply cannot be used here as there is no way for a user to key-in their full AD credentials in a DOMAIN\username or User Principal Name format.
Alternatively the touch-screen equipped Tanjay devices (e.g. CX700) does support NTLM because a user is presented with a full keyboard in which a SIP address, AD credentials, and password can be entered directly from the device. Certificate-based PIN Authentication is not supported in the Tanjay firmware release.
Also know as ‘Better Together’ this approach is only applicable for devices which have a USB Type B connector. When a device is USB-tethered to a supported Windows PC running the Lync client (Mac OS is currently unsupported and this does not work with the Lync:mac client) then the user is prompted for additional login information, as shown in the following screenshot:
The sole purpose of this dialog box is to provide a way to get the user’s Active Directory credentials into a device which does not contain the ability for the user to enter it in directly on the device. When a Tanjay device is USB-tethered and this prompt appears it is simply just an easier way to do what can be done directly from the phone’s touch-panel interface: enter in the AD credentials. But for an Aries device this is the only way to get the AD credentials into the phone.
This USB-based approach to authentication offers two distinct advantages over the PIN Authentication method:
- Simpler sign-in process for users
- Exchange Integration capabilities
The key concept to understand here is that only Lync Server supports TLS-DSK certification authentication and Exchange Server does not. Only NTLM authentication can be used by any Lync clients to directly connect to the Exchange Client Access Server to access the account’s mailbox.
Any device which does not currently have valid AD credentials cached (e.g. PIN Authentication was used) will not be able to successfully authenticate to an Exchange Server. Thus only devices with USB-tethering capabilities (e.g. CX600) or the ability to enter AD credentials directly on the device (e.g. CX700) will ever be able to leverage Exchange integration features. Primarily the CX500 will never be able to connect to Exchange as it does not include a USB connection since it is designed as a Common Area Phone. Common Area devices do not support Exchange integration as they are primarily designed to be used with the specific Common Area Phone accounts in Lync which are Active Directory contacts that are SIP-enabled for Lync in a special way. Since AD contacts cannot be Mailbox-enabled in Exchange then these accounts will never have any Exchange data to integrate with in the first place (e.g. Calendar or Voice Mail).
When Exchange Integration is not currently available for the signed-in user then the Menu button icon will change to an alert icon and the notification “Microsoft Exchange integration unavailable” will be displayed:
When the integration is functioning on the device then standard Exchange-enabled mailboxes will provide basic integration features like Calendar data, but only UM-enabled mailbox will provide Visual Voice Mail information. The following screenshots show the various related menu options as a side-by-side comparison between an Aries device using PIN Authentication and one using USB-tethering.
- There is a known issue that if Exchange UM is not enabled on the account’s mailbox then the Call Log information also will not be displayed, even though the Conversation History folder in the user’s mailbox is not a Unified Messaging feature.
- Although Exchange authentication has failed on the device on the left, because the Lync account is UM-enabled in Exchange the option to ‘Call Voice Mail’ is still displayed, offering one-touch access to the Exchange Subscriber Access number. As seen on the right Visual Voice Mail providing one-touch retrieval of individual voice messages is provided.
- One important exception is when using Exchange Server 2010 the Voice Mail Message Waiting Indicator (MWI) status can actually be updated directly from the Lync Server (this functionality is not available in Exchange Server 2007). When an Exchange Unified Messaging user receives a new voice mail message the UM service will send a SIP notification message directly to the Lync Server, which in turn will send this on to the registered Lync users via a presence update. So even without any access to Exchange Web Services directly from the device the unread Voice Mail is updated on the main menu, as well as the physical MWI lamp on equipped devices (e.g. CX600). The screenshots below shows the Exchange integration warning icon on the main menu, yet the ‘1 New Voice Mail’ indicator is still shown, as well as the MWI lamp is illuminated.
- Another common misunderstanding is around the topic of Outlook Contact integration. It is often believed that Outlook Contacts are not available in Lync Phone Edition, but this is not correct. Any contacts which only exists in the user’s Outlook mailbox and are not also added to the Contact List in Lync are still available on the phone, but only via searching, not via browsing. The Contacts menu only displays objects on the Lync contact list, but the Search menu will return results from either the downloaded Lync address book device files or the user’s Outlook mailbox, of course assuming that Exchange integration is currently available and functioning.
The ability to provision a Lync Phone Edition device out-of-the-box is covered in detail in this previous blog article but this process only works on some devices, not all. Any of the Common Area Phone models which do not contain a USB port (e.g. CX500) should not be used externally.
These common area devices are incapable of being provisioned externally as even if the required PIN Authentication settings were manually configured in the external network’s DHCP services to point to an Edge Server, the device can neither connect to the Web Ticket service nor authenticate in this fashion.
It is possible although to first provision the device internally on a network where the DHCP options are configured correctly and the device can successfully download and cache a client certificate for authentication to Lync. Then that same device can be taken off-site (e.g. home office) and successfully sign-in to the Edge server using the cached user credentials. This will only work until the client certificate expires though, at which point the device would need to be brought back into the internal network to be re-provisioned. Clearly this is not a viable solution for remote workers, but it is possible to use for demonstration or temporary testing purposes. Officially Microsoft does not support use of Common Area Phone models externally.
Branch Appliance WAN Outage
In a typical Survivable Branch Appliance (SBA) scenario where Lync Phone Edition phones are deployed in the branch office it is important to understand that it is not possible to sign-in to a new or reset device during a WAN outage.
Devices configured to support PIN Authentication in the branch office would be directed towards the SBA registrar via DHCP Option 120, yet Option 43 would still be pointing back to a Front End Pool typically in main office or datacenter because the SBA does not contain any Lync Web Services, thus it does not host a Certificate Provisioning service.
What this means is that during a WAN outage scenario all Lync clients and devices which already are signed-in to the SBA using cached credentials can still authenticate directly to the SBA, so clients can be successfully signed-out and signed-in during this outage. Lync Phone Edition devices can also sign-in after a reboot using cached credentials as well, but if a device is manually signed-out, factory-reset, or is brand new out-of-the-box then it cannot be provisioned through either PIN Authentication or USB-tethering methods until the WAN is back online as the device will have no way of reaching the Front End Pool to authenticate and receiving a client certificate. (In this scenario if Internet access is still available in the branch office and there is an Edge deployment in Lync then the branch users could potentially use USB-tethering while signed-in to an Edge server to provision a phone.)
Backup Registrar Pool
When an associated backup registrar pool is assigned to a Front End pool in the Lync topology then the Lync Phone Edition clients can automatically failover to that secondary server or pool just like a standard Windows Lync client.
But in earlier versions of the Lync Phone Edition firmware (this has recently been resolved with Cumulative Update 5 4.0.7577.4066) there was a known issue which prevented devices signed-in using Common Area Phone accounts from automatically reconnecting to either a secondary registrar (during a failover) or to the primary register (during a brief outage). This issue was related to the configured HotdeskingTimeout parameter on the client policy assigned to the device. If the timeout interval elapsed before the device was able to successfully connect to a registrar then although the screen would show that it was still ‘retrying’ a connection it was in fact no longer attempting to connect to the server and it would need to be rebooted in order to connect again.
Get-CsClientPolicy | Select-Object Identity,HotdeskingTimeout
The issue would typically occur when the hotdesking timeout (5 minutes by default) was reached before either the failure detection interval elapsed (in the event of a failover) or if the primary registrar was offline for more than 5 minutes (in the event of a server reboot or extended maintenance window). Meanwhile all other device with standard Lync user accounts sign-in, as well as Windows Lync clients would all successfully failover or reconnect to the working registrar after any time interval (hours or even days). So in this scenario if the failover interval was measurably longer than the hotdesking timeout, or if the a Front End server was offline for longer then the devices with Common Area Phone accounts would never sign back in without manual intervention.
Below is a list of the issues which can often prevent a device from working as designed with a Lync Server deployment. This is by no means a comprehensive list, yet most of the common issues are addressed.
Lync Registration Issues
- Ethernet Required – This seems basic but quite often customers have attempted to use these devices as USB-only handsets and they simply will not function in this manner. The device must be connected to an Ethernet switch at minimum and receive a valid DHCP lease on the network in order to contact the Lync Server, even if USB-tethering is being used to provision the device.
- Enterprise Voice Required – The only CX device that completely functions without the user’s Telephony setting configured for Enterprise Voice is the CX100 USB. When the user account is still in the default PC-to-PC Calling mode then the CX200/CX300 USB devices will function as audio devices but the presence lights do not function. The IP-based devices (CX500/600/700/3000) will not work at all. PIN Authentication will fail, as will USB-tethering since the Lync client will never prompt for the user’s credentials. Note that actual PSTN integration is not required as it is still possible to simply set the Telephony mode to Enterprise Voice but still leave the Line URI field blank. (Update: as of the August 2014 Cumulative Release (.4451) Enterprise Voice Telephony Mode is no longer a requirement).
- Using Old Firmware – This one should be obvious but many of the most common issues seen in the field can be resolved by simply upgrading to newer firmware which has already addressed the root cause. One of the more common issues is when the preinstalled public root certificate on older versions is missing, has expired or has been revoked. More recent firmware versions contain new or updated root certificates but the phone would need to be registered to a different environment in order to apply the firmware update needed to register successfully to the original environment. This is just one example, but whenever troubleshooting any issues the first step should always be to identify the firmware version on the phone and get it upgraded to the latest release.
- Missing Automatic Configuration Records – Lync Phone Edition cannot utilize Manual Configuration and requires that Automatic Configuration records for Lync clients are properly defined in DNS. So if Windows Lync clients are manually pointed to a Lync server (either directly in the client or passed via GPO) this information is not passed to a tethered phone, the phone must perform it’s own automatic lookup. Thus is the proper SRV or Host (A) records are not available in the DNS server provided to the phones then they will fail to sign-in, even when tethered. If the proper SRV records are not deployed for Lync then the only other option is to use the sip.<sipdomain>, sipinternal.<sipdomain>, or sipexternal.<sipdomain> hostnames for the Lync server, pool, or Access Edge names.
- Unsupported Version – If a device ever displays a screen which simply states “The hardware version of your phone is no longer supported and is now unusable. Please contact your support team to get a replacement” then that device is essentially ‘bricked’. This only happens on pre-production hardware and in Cumulative Update 2 Microsoft no longer supported any beta devices, so if this happens contact the vendor directly to swap out the hardware in the event that a demo unit was left out in the wild somewhere after the Lync 2010 Server software was officially launched.
Exchange Integration Issues
- Expired Credentials – One of the most common reasons for Exchange integration issues is related to the AD credentials in the phone expiring. As previously mentioned authentication to the Lync server happens using a client certificate (TLS-DSK) but Exchange authentication happens using NTLM which requires the AD user’s credentials. If the AD user account’s password has expired then it will still be able to connect to Lync using the client certificate, but NTLM authentication to the Exchange server will fail triggering the “Microsoft Exchange integration is unavailable” error message. In this scenario the device will not prompt the user for new credentials, even when actively USB-tethered to a Lync Windows client. The current user account must manually be signed out of the device and back in to successfully update the password.
- Message Waiting Indicator – A number of devices include a Message Waiting Indicator (MWI) lamp which can be illuminated via Exchange integration (messages directly from the Exchange server) or from the Lync Server through SIP registration (via a SIP NOTIFY message). Some of the common area phone models which do not include a USB port still contain a MWI lamp (e.g. the HP 4110ip). Although these devices cannot authenticate to Exchange directly when the user has a new voice mail message the Exchange UM server will always notify the Lync server, thus the Lync client can receive the new status information from the Lync Server. The Exchange Team Blog has a detailed article which covers troubleshooting MWI status in great detail.One of the more common causes for this can be identified by looking for an MSExchange Unified Messaging error event of 1344 on the Exchange UM server which usually is related to a certificate configuration issue between Lync and Exchange. During TLS communications between Lync and Exchange UM the Lync server only accepts the Common Name (aka Subject Name) value of the certificate assigned to the Exchange UM service and completely ignores the Subject Alternative Field (SAN) entries. Thus if the Exchange UM service is assigned to a SAN cert which includes the server FQDN in the SAN (e.g. cas01.contoso.local) but a different FQDN in the Subject Name field (e.g. mail.contoso.com) then the MWI update message from the UM server to Lync will fail, and the client will never receive the notification. It is not until the client polls Exchange again that the new voice mail will be known about. This scenario normally translates into a longer delay for unread and read voice mail counts to refresh on any Lync client. The recommended resolution is to issue a separate certificate with only the Exchange server FQDN as the Common Name (and no SAN field) to the Exchange server and assign it to only the UM role. Alternatively a SAN certificate for all Exchange roles can still be used but the Common Name must be the server FQDN which does not always match best practices (and is not how the Exchange certificate wizard will format the certificate request by default).
- Missing Exchange Autodiscover SRV Record – This issue is a bit odd as it does not seem to be a definitive requirement. In some deployments Exchange integration has failed on all phones until the _autodiscover._tcp.contoso.com DNS Service Locator (SRV) Record was created; it appeared that the devices would simply refused to use the fall-back Host (A) record to locate the Exchange Client Access Server. Yet in other environments Exchange integration would perform normally yet the autodiscover SRV record never existed. But as it is best practice to deploy that SRV record for a properly designed Exchange autodiscover configuration then it is one of the first things to check when troubleshooting Exchange integration issues.
- Untrusted Certificates – Sometimes the Exchange Client Access servers (or load balancer) will have a certificate issued by a different Certificate Authority than what is used on the Lync servers. Often this can be a scenario where the Exchange server is using a public certificate while the Lync Front End Server has a private certificate. But since Lync Phone Edition has a shorter list of pre-installed public trusted certificates than the Windows client does then it’s possible that the device does not trust the certificate in use on Exchange. This also applies to using private internal certificates issued by a completely different certificate authority chain then was used to issue certificates to the Lync Server. Lync Phone Edition can only download the root certificate chain used on the Lync Server and is unable to download or store any additional certificates from a different CA.
- Wildcard Certificates – As previously discussed in this blog article Lync Phone Edition devices do not currently like wildcard entries in the Lync Server certificates. This carries over into Exchange integration as well, so if the Exchange certificate contains wildcard entries then the phones will also fail to establish a TLS connection with the Exchange Client Access Server thus preventing a successful authentication attempt. This issue can be identified by the error code 0x80072f06 reported in the device client log files and Mike Stacy has highlighted this issue in a past blog article as well.
Begin by reading through the Updating Lync Phone Edition Devices article to get understand how the update process works. Whether a Test Device is being used or a new update has been approved for a specific device model and revision then the phones should just automatically update themselves and reboot into the new version when left idle. There is no way to force the update and the more that the process is messed with (or seemingly the longer one stares at the phone) the less of a chance it will successfully complete the update.
So when updating a device it is recommended to reboot the phone and just let it sign in with the currently cached user account and then immediately lock; do not touch the device. In a normal situation the device will check for a new update upon initial sign-in and then begin downloading the package about 1 minute later, rebooting into the new firmware roughly 7 minutes after that. These time estimates depend on network bandwidth as the packages may take longer to download in some environments. But a good rule of thumb is that if the device has not updated after sitting untouched for ~30 minutes then something is preventing a successful update and some troubleshooting steps are required.
Normal Update Process
To briefly revisit the firmware update processing originally discussed in this article when a package is approved for a specific phone model and revision (or a test device is defined via the MAC address) the easiest way to start troubleshooting is to verify if the device has even checked in yet to ask the server if a new software version is available. This process happens on each boot sequence and systematically throughout the day as the devices experience inactivity periods in between use, as it would not be desirable to have the phones rebooting themselves to update firmware while a user is on a call.
- To follow the device check-in process first look at the IIS log for the associated web services directory on the appropriate Front End server: W3SVC34577 for the Internal Web Site or W3SVC34578 for the External Web Site.
- Search for the “RequestHandler” to locate the latest POST log entries, comparing the device IP address or MAC address to identify the correct line items. The initial POST message shows the device connecting to the /RequestHandler/ucdevice.upx service.
2012-03-17 15:35:01 192.168.1.23 POST /RequestHandler/ucdevice.upx – 443 – 192.168.1.108
Microsoft+UCPhone+Device+(lcs_se_w14_main:985232:2011/11/09:16:08:29) 200 0 0 128
- Then move to the latest RequestHandlerAuditLog_lync_xxxxxxxx.log stored under the imageUpdate log folder on the Lync Server to see what the service logged about that client request. The following text coincides with the request timestamp, which happens 4 seconds after the request logged in IIS from the same host. (Pay close attention to the hour as the IIS logs and Update Service logs do not use the same format; IIS uses the local time zone while the update logs use UTC.)The logged response shows that the update service has passed the internal and external URLs for the device to retrieve the update package from.
03/17/2012 10:35:05,email@example.com, 192.168.103.108,UCPhone,3/17/2012 8:34:59 AM,”0004F2953DFC”,”0004f2953dfc”, “POLYCOM”,”CX500″,”Rev-4″,”ENU”,cpe.nbt;4.0.7577.4047;11/9/2011 5:32:04 PM, http://lync.schertz.local/RequestHandler/Files/UCPhone/POLYCOM/CX500/Rev-4/ ENU/4.0.7577.4066/CPE/CPE.nbt; https://external.mslync.net/RequestHandlerExt/Files/UCPhone/POLYCOM/CX500/Rev-4/ENU/4.0.7577.4066/CPE/CPE.nbt; 4.0.7577.4066;2/18/2012 8:49:56 PM
For comparison, when a device has the latest approved firmware already installed then the response from the update service will not include any URLs, as demonstrated here:
03/17/2012 10:42:35,firstname.lastname@example.org,192.168.103.108,UCPhone,3/17/2012 8:42:34 AM,”0004F2953DFC”,”0004f2953dfc”,”POLYCOM”,”CX500″,”Rev-4″,”ENU”,cpe.nbt;4.0.7577.4066;2/18/2012 8:49:56 PM,
- Once it has been confirmed that the device was given a path to download the update the IIS log can be checked again and sometime shortly after the original POST message there should be a GET message showing the actual device requesting the file from the web server. The values at the very end of the lines in the IIS logs is the time elapsed for that request, so the log shows that the download of the CPE.nbt firmware file (52MB) took 47685 milliseconds, or 47 seconds.
2012-03-17 15:35:53 192.168.103.23 GET /RequestHandler/Files/UCPhone/POLYCOM/CX500/Rev-4/ENU/4.0.7577.4066/CPE/CPE.nbt – 80 – 192.168.103.108 Microsoft+UCPhone+Device+(lcs_se_w14_main:985232:2011/11/09:16:08:29) 200 0 0 47685
The example below (click the screenshot for a full-resolution image) shows the entire process of a Polycom CX500 located at 192.168.1.23 requesting the CU5 update package (4.0.7577.4066).
Troubleshooting Failed Updates
In the event that the device neither requests an update or does but seems to never actually update itself then additional steps can be performed to narrow down the issue.
The first item to check is the Last Update Status code shown on the device’s System Information menu, which can be used to identify if the device encountered an error in the update process. There is also a Send Logs button on this screen but in reality these logs are not very helpful. Firstly the device must be able to successfully sign in to the server before it can actually send the logs by uploading them to a directory on the Front End server. But then the resulting file is a unusable .clg1 Windows CE error log which requires the nearly-impossible-to-find readlog.exe utility. from Microsoft. And even when the logs are converted into text with this tool they are still very difficult to read and are primarily meant only for Microsoft PSS to troubleshoot from.
Most often recoding the status update information will point to the root cause and the client logs are not needed. the status code is actually two individual codes, the first value displayed in hexadecimal format is the WinInetError code and the second value in decimal format is the HTTPError code. The WinInetError codes can be reported generically (e.g. 0x2, file not found) or more specifically (e.g. 2F0D, invalid certificate trust).
When an issue prevents the device from downloading the update then the code value will often contain a non-null value, but searching online for that error code will often return nothing helpful. This is because the error code needs to first be converted to decimal, then the resulting error code will be much more helpful.
- For example assume that the Last Update Status is reported for a device as 0x2ee7/0. The hexadecimal value of 0x2ee7, simplified as just 2EE7 converted into decimal is 12007.
With that decimal value the following Microsoft articles can be used to lookup the actual error code description. Each page is not a complete list so make sure to search both references as some error codes are only listed in one them.
Microsoft Support: INFO: WinInet Error Codes (12001 through 12156)
MSDN Library: System Error Codes (0-499)
MSDN Library: WinHTTP Constants – Error Messages
- Using the table in one of the articles above error 12007 is described as “ERROR_INTERNET_NAME_NOT_RESOLVED the server name could not be resolved.” This would point to the device failing to resolve the FQDN used in the download URL passed by the update services.
Following is a list of common status message and resolutions:
- 0x0/200 – This status is a normal state of no WinInetError (0x0) and an HTTP 200 OK status message, meaning that no error occurred and that device is on the latest approved version and there is nothing to do. If this is not the case and the device should be updating to a newer version verify that the version is approved for the proper revision. For example the Polycom CX600 device has multiple hardware revisions that use unique firmware packages which are reflected by the Rev-3, Rev-4, or Rev-5 label in the Part Number field displayed in the System Information menu.
- 0x5/404 – This code is a basic HTTP 404 NOT FOUND error and indicates that the device was unable to connect to the device update web service in order to download the firmware package. This is a common error in deployments where a traffic is not properly forwarded to the Front End servers. Often times only HTTPS traffic over TCP:443 will be configured on a Hardware Load Balancer and HTTP traffic over TCP:80 is accidentally omitted. As most other Lync client functionality is unaffected it is not until attempting to get Lync Phone Edition devices to work that this missing configuration can become a problem. As indicted in the device log examples in the earlier section any internally-registered devices will be passed the internal device update URL with an HTTP header, so if the phone is unable to connect over port 80 then the update process will fail here. Insure that the Lync Front End server’s internal web services are available over both port 80 and 443 to resolve this.
- 0x7/0 – This generic code entitled ERROR_ARENA_THRASHED means that the storage control blocks were destroyed and that, more simply, the new firmware was unable to be written to the device due to some corruption in the file system, or that there is no free space remaining. The resolution is to perform a hard reset (aka factory reset) on the device and then the let the upgrade process perform again and the newly rewritten file system should no longer contain the corruption.
- 0x5/401 – This error indicates ERROR_ACCESS_DENIED in the first code followed by a common HTTP 401 Access Denied error as well, indicating a general authentication failure of the device accessing the IIS web service when attempting to download the new firmware package. In scenario there may be an account permissions issue or a general configuration issue in IIS preventing proper access to the web server directory.
- 0x2EE7/0 – As described in the example above this error code of 12007 is described as ERROR_INTERNET_NAME_NOT_RESOLVED and means that the device is failing to resolve the FQDN of the download URL passed by the update service. This is normally the Internal or External Web Services FQDN in Lync.
- 0x2F0D/0 – This error code converts to 12045 in decimal and is certificate related based on the descriptive name of ERROR_WINHTTP_SECURE_INVALID_CA. This typically happens when an untrusted public certificate is installed on the web service (or reverse proxy for external device updates) and it was not issued by one of the trusted Root certificate authorities that Lync Phone Edition supports be default. See the TechNet article Certificate in Lync 2010 Phone Edition for a complete list of the preinstalled CA certificates. Also be on the lookout for Hardware Load Balancer configuration using SSL Offloading as even though the internal Front End services may be using an internal private certificate that the phone trusts the load balanced web services sometime can be installed with a different certificate which the device does not support, effectively breaking only device updates.
Each device family has a different process for rolling back the firmware to a prior version but the behavior and results are nearly identical. Both versions contain two separate reset procedures. First there is a soft reset which only wipes the phone’s current configuration data (user credentials, certificates, etc.) but does not impact the firmware. The second is a hard reset (or factory reset) which not only wipes the configuration data but also rolls the firmware back to the previously installed version.
Calling this second process a ‘factory-reset’ is technically incorrect as only the previously installed firmware can be restored, there is no factory firmware image stored anywhere on the phone. There is also no specifically designed ‘factory’ version as depending on the model revision and manufacturing date it could have come with a beta, RTM, or any CU version pre-installed. Additionally, if a device ever crashes during bootup and begins to be stuck in a crash-loop due to some file corruption for example, then after the 5th successive reboot the device will automatically perform a firmware rollback. Take note that once the device is rolled back it will immediately attempt a firmware upgrade if the update services still have that newer version approved for that device model and revision (or if it is defined as a Test Device).
Both device families use the same upgrade process in that each device contains two separate ‘partitions’ where firmware is stored: an active partition and an inactive partition. Under normal operation the device is working on its active partition and the inactive partition will have the previously installed firmware, whatever version that might have been for that device. So as multiple versions are loaded on a device over its life it becomes apparent why it can never truly be reset back to factory as each new installation simply overwrites the older, inactive partition data and the device simply ‘flip’s’ the partitions after a successful upgrade. For example a device originally shipped with RTM firmware which was systematically upgraded over the past year to CU1, then CU2, then CU3, then CU4, and finally with the most recent CU5 is only able to move back one version. It is also not possible to force installation of an older version using the device update services. (That being said, there is an unsupported workaround which can be used to roll a Tanjay device from 4.0.x Lync firmware back to the 3.5.x OCS R2 version.)
The process to reset a Tanjay device is triggered by depressing a recessed reset button (most easily with a straightened paperclip) which is located on the bottom of the handset in between the USB and headset ports.
- To perform a soft reset on a Tanjay device simply depress the switch while the device is currently powered on and it will immediately reboot back to the initial sign-in screen with the current user data wiped.
- To perform a hard reset on a Tanjay device just repeat this process 4 more times (for a total of 5 resets) in rapid succession to trigger the built-in failsafe firmware rollback.
The process to reset an Aries device is triggered by holding down certain keys while powering on the device and is documented in more detail in this previous article.
- To perform a hard reset on a Aries device simply hold down both the * and # buttons while connecting the power. Continue to hold the keys for approximately 10 seconds until the following screen appears, indicating that all user data and configuration settings will be erased.
- To perform a factory reset on a Aries device simply hold down both the 4 and 6 buttons while connecting the power. Continue to hold the keys for approximately 10 seconds until the following screen appears, indicating that the phone will be rolled back to the previously installed firmware version as well as erasing all settings.
150 thoughts on “Troubleshooting Lync Phone Edition Issues”
[…] Lync Phone Edition Issues : Jeff Schertz’s Blog Posted on March 19, 2012 by johnacook http://blog.schertz.name/2012/03/troubleshooting-lync-phone-edition-issues/ Share this:StumbleUponDiggRedditLike this:LikeBe the first to like this […]
This is a great post! I have hit alot of these issue before essentially the Exchange UM ones with SRV and Certs.
With regards to the Missing Automatic Configuration Records for Lync Phone and specific the sip.<sipdomain>, sipinternal.<sipdomain>, or sipexternal.<sipdomain> hostnames for the Lync server, pool, or Access Edge names.
Does this work for an Edge server when using the standard TCP/443 port for remote access or will this only work if TCP/5061 is used for remote access?
When using Automatic Configuration SRV records the service listening port is determined in the SRV record, so it works for both. Traditionally the phones will connect to the internal Front End server over 5061 but will register to an Edge server over 443.
obviously the service port in the SRV record. but if you're not using SRV's and just using manual configuration and have specified sip.<sipdomain>, sipinternal.<sipdomain>, or sipexternal.<sipdomain> hostnames for the Lync server, pool, or Access Edge names. Will the phone connect to the access edge on TCP/443 (default) or does the remote access port need to be on TCP/5061.
Typically in the Lync client you need to specific sip.<sipdomain>:443 for the external server address (assuming that is you access edge fqdn)
This depends on which Host (A) record is successfully resolved. If the sipinternal record is resolved then the client will only attempt a connection to 5061 on the resolved host IP. If either sip or sipexternal are resolved then the Lync client will first attempt a connection to 443 and if that fails then it will try 5061 (and then back to 443 again for some reason). This underscore the recommendation to use sipinternal on internal DNS zones and either sip or sipexternal on external DNS zones for the Access Edge FQDN.
I’m having in issue with CX600 phones in a SFB 2015 environment. The remote users at home can dial in/out just fine, but when dialing internal numbers it will ring, but say “call unsuccessful” when the other user picks up. Any thoughts on this?
Same issue, exactly.
Adding, the CX600 office desk phones are on their own VLAN, and if the external user is VPN’d it works.
Likewise it works, always, if the desk phone is on the regular office VLAN and is dialed from anywhere.
Great post Jeff.
[…] Veja aqui: http://blog.schertz.name/2012/03/troubleshooting-lync-phone-edition-issues/ […]
Extremely thorough post Jeff! Since we usually recommend Polycoms to clients, this is going in the reference folder. Thanks for putting in all the work to formulate this.
[…] Jeff Schertz (Lync Server MVP and an excellent blogger) has posted a “massive” troubleshooting article. It gives exhaustive detail on fixing problems with Lync Phone Edition, AND firmware for compatible phones. […]
Hi Jeff, thank you for the detailed post. I was wondering if you could answer a query I have regarding the CX500/CX600/CX3000. Across many deployments we are getting message that states "Network Cable was not detected. Please check that your cable is connected to the network port that you have a network connection" on CX500/CX600 & CX3000 devices. The phones are powered over PoE and this issue seems to affect around 15 in every 100 devices. The devices may work for six months or so, and then one day display the aforementioned message and despite a hard reset or firmware roll back the issue persists and we have to RMA. Is this something you have come across? Any feedback would be much appreciated.
I have not seen this issue myself but I suggest that you call your support contact to open a ticket as it appears to be a physical issue.
The cause of this is a problem with the ethernet cable. Polycom phones need a good ethernet cable for the phone to work well and effectively.
I might argue that any wired network device need a 'good' cable to work effectively. 🙂
We have the same issue with the Polycom CX600s.
I had the same issue some days ago with a new CX600 Rev 5.
-setup are 4 Hyper-Vs (DC, Lync-FE13, Exchange13, Sharepoint13; all on W2K12R2)
-HP4120 was first connected for testing, then the power supply (no original one..too weak…10W only) gave up
-new phone bought in the meanwhile…CX600 Polycom
-same port…everything same…no changes on Setup
-CX600 did only Login when rebooted via power off/on…if Lync-FE was restarted, then it was not able to connect again, like the HP4120 was
-tried again some days
-started registering for the Polycom Support Website…started my first SR there…had to Register the phone before with its Serial number
-SR was cancelled as the reseller is responsible, so no answer from Polycom…but…strangely enough…short after the Registration of the SN of the phone, it showed in the System info now an entry for “Last Updated Request” with the day of the Registration, and the time was some time after the Registration (Lync CU for the phone was the newest , 4.0.7577.4463 already before)….before the Registration, the phone showed some value from 2010 there in the “Last Update Request” field, so I assume, that perhaps only registered phones can download Firmware updates from the Polycom Servers in the Background?…not sure, but…
…well…it was worth an assumption 🙂
->just right now…again the sign-in issue…again the “Last Update Request” Shows some date in 2010 (phone was powered off, as the Workstation with the Hyper-Vs)
Unless you are leveraging the ‘ucupdates-r2’ method which I’ve covered in another article the phone cannot update until after it successfully registers to Lync.
[…] the article here: Troubleshooting Lync Phone Edition Issues : Jeff Schertz's Blog document.write(unescape("%3Cscript src=%27http://s10.histats.com/js15.js%27 […]
What can I say? Another excellent post. I feel more and more that the Lync Reskit ebook should be printed, and thrown immediately into the trash, as its nowhere near to this level of detail that I can read on a regular basis here.
Yeah, and I have a question: I was reading this since 1st day from OCS R1: the Tanjay supportability guide always stated, that the Exchange certificate must come from literally the same CA which issue the certificate for the FrontEnd as well. Is this really true? Or just a mistake of a techwriter, which was never noticed and corrected?
That sounds like a documentation error to me as I've never run into that I've worked in many environments with different certificates between OCS/Lync and Exchange, some public and some private.
Hi Jeff, it seems you also confirmed this behavior since the last time in this paragraph:
Lync Phone Edition can only download the root certificate chain used on the Lync Server and is unable to download or store any additional certificates from a different CA.
By default, yes. But you can import additional CA certificates using the process in this article: http://ocsguy.com/2012/05/19/lync-phone-edition-c…
Thanks for the tip. I started to see this trick pop-up on several Lync blogs in the last 10-12 months, so at least the community spreads those tricks that MS failed to explain on the Lync Technet document properly.
thank you for the great posts!
What about integration between Lync on premise, Polycom cx600 and Exchange Online?
Polycom is always with error on the display. invalid credentials error.
Lync is with CU3, Polycom with version 4.0.7577.4047, Outlook 2010 SP1.
Unfortunately the Lync Phone Edition firmware do not yet support a hybrid scenario where Lync and Exchange are split across untrusted forests (on-premises versus hosted) as the device is only currently able to store credentials for one user. So when the Lync server uses a different AD user account than the Exchange Server then Exchange integration will fail. you should still be able to sign-in to the device, it's just Exchange integration which is not available.
Great post as usual Jeff – one question
Is the hybrid model with Office 365 sign in issue you mention above planning to be addressed anytime soon ?
January 2014 update (7577.4420) fixed the issue with Lync on-premise and Exchange online. Polycom CX600 is now able to see missed calls etc.
Mitch, unfortunately I cannot comment on any time-line for O365 support scenarios.
I found no information of how exactly Lync Phone Edition downloads Root CA certificate. Microsoft's documentation don't tell the full true 🙂 ! Even your post don't give a full answer.
I'm made investigation of it process and described it here. Maybe it will be interesting for you and we can write an Eglish version of it?
P. S. Sorry for my English 🙂 .
In a effort to add continued value to this troubleshooting article I'll add links to unique issues and resolutions discussed over in the TechNet forums. Here is one related to odd directory search behavior in LPE where results come from different sources depending on how the device was authenticated: http://social.technet.microsoft.com/Forums/en-US/…
In regards to Lync and exchange in a different forests, I have a scenario where Lync is deployed in a "resource forest" and user with exchange server (without UM) are deployed in "user forest" there is a one way trust at which users in "users forest" are able to log on their domain and access Lync mapped accounts in "resource forest" to use Lync.
Everything works well from Lync client including exchange integration, the problem is from the Lync phones cx600. When I log on with pin authentication on phone, of course no exchange integration work, but when I connect the USB cable and lo on phone using the user credentials in the "user forest" the integration fails on the phone….
I suspect that this is due to a certificate problem, but not sure… I mean when the phone tries to connect to the exchange it will receive a certificate issued from the local CA of the "user forest" where the phone only trust public certificates and certificates issued from the "resource forest" CA… have you seen such case? am I missing something?
Amr, that is most likely the issue. Lync Phone Edition will only download the root CA certificate for what is issued to the Lync Server. If the Exchange server uses a certificate which was issued by a different, untrusted CA, then the phone cannot connect to Exchange, even with the credentials sent via USB. IT can only import certificates from a single private CA at one time.
I am currently having a problem with my CX500 – CX600's Common Area Phones. When our FE's are rebooted for patching, the phones do not automaticly sign back in. CU5 was supposed to resolve this. (•2688319 A common area phone does not try to sign in after it disconnects from the server in a Lync Server 2010 environment) We have deployed this to our phones and the issue is still happening. Any thoughts?
I've tested this in CU5 and see that is resolved int he same environments where it failed before. I'd suggest contacting Microsoft for additional support.
I am currently having problems with firmware .4100 not updating to Polycomm phones. I have applied and even repeated the importing of the firmware update for all the polycomm devices but the phones will only update to 4.0.7577.4066 even when doing a factory reset (Holding 4 and 6 while powering up device) so I know my certs and configuration is good. It is just acting like the request handler is only returning 4.0.7577.4066 when a update is requested by the device. I have also double and tripple check to make sure the correct rev number is approved under control panel and that the files are located under the share as well..
07/09/2012 09:50:19,***********@domain.net,192.168.16.136,UCPhone,7/9/2012 9:50:19 AM,"0004F******","0004f******","POLYCOM","CX600","Rev-4","ENU",cpe.nbt;4.0.7577.4047;11/9/2011 5:32:04 PM ,http://lyncfe.domain.local/RequestHandler/Files/UCPhone/POLYCOM/CX600/Rev-4/ENU/4.0.7577.4066/CPE/CPE.nbt;https://lync.domain.net/RequestHandlerExt/Files/UCPhone/POLYCOM/CX600/Rev-4/ENU/4.0.7577.4066/CPE/CPE.nbt;4.0.7577.4066;2/18/2012 8:49:56 P
Great article, this certainly helps a lot. But I'm still left with a puzzle… Today I got my new 6725ip and CX600 phones to test with. I was able to login, but only for accounts which had their autoconfig DNS records configured. I would expect these records not to be necessary as I've configured the DHCP server to give the phones the registrar address in option 120. Are these autoconfig addresses still required, if so why doesn't the phone extract the address from the DHCP options?
Erwin, The autodiscover requires are mandatory for Lync Phone Edition, you cannot use Manual Configuration for sin-in like the Windows Lync client can. The DHCP option 120 is used by the phone during PIN Authentication to locate a Lync Server to perform the Phone Number to User lookup and then complete the TLS-DSK authentication (along with Options 43). Once this process is complete the phone will go back to the normal process of looking up the SRV and A records. I do not know why Option 120 is not sufficient in the case that the SRV/A records are missing, but this is the behavior I have always observed in Lync Phone Edition.
Thanks Jeff. I've configured _sipinternaltls._tcp.lyncdomain.com to point to ocspool.domain.local port 5061. Is this a valid configuration where the SRV record maps to the internal pool address, or am I still required to map to a lyncdomain.com address and add that address as a SAN on the certificate for ocspool.domain.local in this example?
To support LPE devices you'll need to point the SRV to an A record in the exact same domain. Although Lync now supports the ability to use mismatched names (an SRV record in Domain1 pointing to an A record in Domain2) and the Windows client will work with that (it did not previously in OCS) the user will receive a Trust prompt first. The phones do not utilize this Trust prompt and thus the domains must match.
Is domain matching also required for the autodiscover SRV record? I'm still having a problem where the phone won't download autodiscover.xml and thus never connects to EWS. I have made a post on the MS forums about it for some detail. I would be grateful if you could take a quick look and voice your knowledge about this 🙂
The thread is located at http://social.technet.microsoft.com/Forums/en-US/…
A fair amount of code has been changed since CU7 to begin support for Lync Online and that seems to have changed some of the previous behavior. I suggest opening a support ticket with Microsoft PSS (since your article states you are using LG-Nortel and Aastra devices) to troubleshoot the issue.
This is a minor issue. Should Aries phones provide a name to a Microsoft DHCP server? My phones are mostly Aastra 6725ip phones. It would be nice to have an idea what device is using what IP address instead of having many blank leases.
Jim, unfortunately the Lync Phone Edition client does not advertise any sort of hostname when it requests a DHCP lease, so you'll have to look at the MAC address in the lease information to identify the specific devices.
Thanks for the information Jeff. Since the Microsoft Response Point phones generated names to register with the DHCP server, it seems they would have done it with Lync, which is a mich higher end system.
The most common problem that arises on non-clarity and signal disruption are mis-configured data cabling that is often about cross-talk and interference.
We have Polycom CX600 phones and they work well internally; however, when using one externally a call to another CX600 internal does not complete (shows connecting then fails). Externally we can recieve calls, call a cell phone, another extension on a different internal PBX, and the Lync client just not to another CX600 internally. Any ideas what could be wrong. Any help would be greatly appreciated.
Mike, are you saying that calling with external Windows Lync clients are fine but only CX600 calls are impacted? The only major difference in media handling between these different client types is that QoS is enabled on the phones by default. Now for Internet-based calling that should not be an issue but it's possible that somewhere along the line either at the source or the destination these DSCP markings are creating a problem. See this article for more details: http://blog.schertz.name/2011/08/lync-qos-behavio…
thank you for the quick response, I will try disabling QoS and see if that corrects the issue.
removing the QoS settings corrected the issue, thanks for the assistance.
[…] Jeff on Lync Phone Troubleshooting: http://blog.schertz.name/2012/03/troubleshooting-lync-phone-edition-issues/ Share this:TwitterFacebookLike this:LikeBe the first to like this. LG 8540, Lync, Phone Edition, […]
I have a client with Lync and Polycom CX600's deployed with permanent USB tethering. One of the users has an issue where certain incoming calls from the PSTN only show the email address on his display, not the name and phone number. The Outlook contact has all the details in it, and the Exchange integration is working, and it's OBVIOUSLY pulling the email address from the contact info on either Lync or Exchange, since it would not be able to find that from the caller id header. So why do a few calls only show the email while all others show name and phone number?
Kyle, most likely the difference is due to whether or not the inbound caller has a defined Outlook contact in the callee's Exchange mailbox, but it's very hard to say without knowing your environment. I have not seen this before.
I'm assuming it's an Outlook contact issue. The same person can call someone else who has them as a contact, and it displays properly. I can also have that person call a stand alone freshly deployed copy room (ad contact) cx500 and it displays the correct info straight from regular caller id.
Problem is, I can't figure out what it is that's wrong with the contact formatting in Outlook. It looks the same as everyone else. It's a lawyer, and he has several thousands of contacts, and nearly all of them are doing this. They were originally created in Outlook 2003, so it could be the old formatting being brought over. Or they could have been created on an iPhone and synced. Or they could have been imported in from some LoB law app for all I know….but they LOOK fine, ie, all the fields are the same config as anyone else in the office who don't have the same problem with the same caller.
I guess I'll have to delete one of the problem contacts and recreate fresh to see if that fixes it. But that still doesn't tell me what the problem was, or how to mass resolve it for thousands of contacts.
I am having issues getting Polycom CX-x00 Phones to retrieve updates from our Lync Pool. I can see from the RequestHandlerAuditLog file that the phone is receiving the correct internal and external URLs. I am not sure what the reason, but even thought the phone in on an internal VLAN is attempts to access one of my Front End servers' external sites for the update. The error message I am receiving from that server is :
2013-02-08 22:09:00 10.xxx.xx.xx GET / – 4443 – xx.xxx.xx.xxx- 403 14 0 3
Pulling my hair out over here even though I must say at least I have found a great resource in Jeff's website. (Always a silver lining) 😉 Any help would be appreciated.
Scott, what is the "Last Update Status" error code as displayed on the phone itself? It appears that the phone is attempting to download the package based on the GET message you see in the IIS logs. My guess is there is a certificate-related issue preventing the phone from receiving the update. On possibility is if you are using a Hardware Load Balancer in front of the Lync Web Services with SSL Offloading and are using a different certificate CA chain than the Lync FEs themselves.
I'm also having issues getting updates on my Polycom CX phones. I can get to the internal URL and the phone is receiving the correct URL address as well, as shown in the RequestHandlerAuditLog files. The error code on the phones is 0x5/404.
Message in IIS is as follows:
GET /RequestHandlerExt/Files/UCPhone/POLYCOM/CX500/Rev-4/ENU/4.0.7577.4372/CPE/CPE.nbt – 443 – 10.x.x.x Microsoft+UCPhone+Device+(lcs_se_w14_main:824457:2010/10/21:23:13:00) 404 0 2 5
POST /CertProv/CertProvisioningService.svc/mex – 443 – 10.x.x.x OC/4.0.7577.4356+(Microsoft+Lync+2010) 200 0 0 45
I also briefly see a "cannot download root certificate" error on the phone before it logs in. What root certificate is it looking for and where should I put it? In the Lync Share?
Is the issue because these are using 443 instead of 80?
The device is trying to download the root CA certificate which would automatically be stored in the domain-connected server. Usually that error is not indicated that the actual cert download is failing but the phone is unable to locate and connect to the proper service in the first place.
How do you fix this? I updated our sip.domain.com certificate last week, and now our external CX600s don't work. They work internally, but as soon as they are external, they don't sign in. External lync clients sign in fine. Digicert checker all comes back fine, although when viewing the cert in the tool it doesn't show a key, but viewing from cert authority in windows, the key comes up.
Paul, without knowing what was updated on the certificate (different issuing CA, names, etc) I don't know what the issue could be. The phones should work in either location; have you tried performing a complete factory reset to flush out any older cached certificates?
i face a registration problem, i have lync server 2013
the CX600 working good with lync 2010 Phone edition, but when i upgrade the phone to UC 7 update which should support lync server 2013 the registration fail
did anyone face same problem.
I suggest opening a support ticket with Microsoft as your scenario should work with CU7.
You need to be sure you upgrade your phone to UC5 first before you can go to UC7. The Polycom's come shipped with the old version, which isn't compatible. Only way it will work.
Yes, I've already covered this in another article I posted last summer when this issue first appeared in CU6: http://blog.schertz.name/2012/08/lync-phone-editi…
One other thing we had come across, which didn't make any sense. I re-issued the local certificate for the mediation server. All services worked perfectly fine from inside and outside. Even some of our old phones with the latest version could login. It wasn't till I contacted Microsoft and found out about the UC5 to UC7 issue and the local certificate re-issue that cleared the issue. Microsoft couldn't explain it for me either, but that's what worked in the end for us.
I am currently having issue with CX 500 and CX 600 to sign in using pin number.Target Fqdn : pool01.x.x
Target Uri : https://webint01.x.x:443/CertProv/CertProvisionin…
Result : Failure
Latency : 00:00:01.1175856
Error Message : No response received for getting root certificate chain. Inner Exception:The request channel timed out while waiting for a reply after 00:00:59.9329933. Increase the timeout value passed to the call to Request or increase the SendTimeout value on the Binding. The time allotted to this operation may have been a portion of a longer timeout.Inner Exception:The HTTP request to 'http://webint01.x.x/CertProv/CertProvisioningService.svc/anon' has exceeded the allotted timeout of 00:00:59.9840000. The time allotted to this operation may have been a portion of a longer timeout. Inner Exception:The operation has timed out. On the phone the error is : An account maching this phone number cannot be found
It appears the phone cannot locate or connect to the Front End server to access the Certificate Provisioning web service. There could be any number of issues causing this so I can't really say what the problem might be.
Just wondering if you could assist with some issues I seem to be having with IP8540 and CX700s. I have installed the CU5 update and successfully registered (can see the pending update in the Lync control panel) and configured 2 test devices 1 for the IP8540 and the other for the CX7000, but the updates never seem to come through to the phones. I have checked the Device update logs and can see the phones that I have specified as 'test devices' hitting the servers but they do not seem to upgrade. After checking the system information of the phone I have it says the last update was today with a status of (0xb/0). Due to working on a secure environment I can't post a lot of logs. But any assistance would be appreciated.
Are the devices receiving the internal and external web services FQDNs in the Device Update Logs, as shown in my examples? And then do you see the device attempt to download the update or not in the IIS logs?
Thanks for the great post Jeff. This is what I consider required reading for anyone who works with the Lync Phone Edition.
Hi Jeff, how are you?
I'm working in a project with Lync 2010 and CX600 Polycom. How did you say, it's impossible to find the Readlog. Do you have any software what I can read the CX600 *.clg1 device log? Some devices are the error message "Sign-in canceled due to internal error" but sometimes they works.
I do not believe that Microsoft provides this tool for download anymore, it is only used by their support team.
For clarity I’ll throw what our issue was..
When the DNS admin cleaned up from our MTHP install.. they left the _sipinternaltls SRV record pointing to lync.external.com however the frontends had lync.internal.local in their SAN
The Phone trusted the server01.internal.local host, but it didnt match the signin URI so it cycled through to the next server in the list (from the sipinternaltls entry) but as that name wasn’t on the SAN. trust was broken and the phone threw an “Internal Error” message on one firmware.. and “Verify your username and password” on another.
I spent considerable time troubleshooting the root certificate service when really the issue was the SAN’s
Remember kiddies.. just because Lync signs in, doesnt mean all your certs are right.
Did you ever solve this issue? we appear to be having the same with LPE 4.0.7577.4455
I have the utility but I dread reading those logs.
Two days ago I had an issue where all our IP Phones (CX600 for users and CX3000 in the conf rooms) suddenly signed out and would not sign back in, even if I manually reset them. The Lync clients worked fine. Our Lync implementer looked at the certificates and said they were fine. The event logs looked fine. Nothing had changed with the network and the phones were getting IP addresses and I could ping them. This was the last entry from an IP phone in the IIS log:
2013-06-10 17:34:10 192.168.1.70 POST /groupexpansion/service.svc/WebTicket_Bearer – 443 – 192.168.7.67 OCPhone/4.0.7577.4387+(Microsoft+Lync+Phone+Edition) – 200 0 121 18939
My understanding is that the "121" near the end of the line means that the server timed out. No more entries for IP phones appear until a few hours later when I rebooted the Lync Front End server. Then all the phones signed in automatically. Any idea what would cause this?
Sorry, no idea on what may have caused that to happen.
Hello Jeff, Great article and I always recommend people to read your blogs before starting to troubleshoot.
I have a quick question, Are the Aries family phones still unsupported with USB Tethering in Lync for Mac Clients? I tried Polycom CX600 and Astra 6725 with no luck.
If they are still unsupported, how likely that Windows Lync will work if I run Bootcamp in Mac ? Any ideas or tests in the past?
Sai, the Lync Mac client does not yet support USB tethering of any Lync Phone Edition devices.
At first thanks for this great site !
But now i have some problems with a polycom cx3000. In our network we have a Lync 2013 and a few Exchange 2007. My problem is, that i cant connect the polycom to our exchange. The IIS Log of my Exchange says that the polycom cant access the autodiscover.xml: GET /autodiscover/autodiscover.xml – 443 – 10.77.84.129 OCPhone/4.0.7577.4372+(Microsoft+Lync+Phone+Edition) 401 2 5 125
I have this problem only with the polycom cx3000. Our Astra 6725ip Phones work fine and also the lync clients dont have any problems.
Could you give me an advice?
P.S. Sorry for my awful english 🙂
I'm assuming the Aastra phones are running a different firmware version as the operation of each device is 100% identical as they share the same clients written by Microsoft. For dealing with Exchange Web Service issues I recommend either upgrading to the latest firmware (if on exists) or rolling back to a previous release (typically 1 or 2 versions old) to see if that resolves your issue. Various Exchange connectivity issues have been found and addressed in different firmware releases, but sometimes new problems are introduced as a result of those earlier fixes. It's best to isolate which version(s) are causing problems and then contact support with this information.
Hi Jeff, I really need you to explain further what you mean when you say the following:
"Thus is the proper SRV or Host (A) records are not available in the DNS server provided to the phones then they will fail to sign-in, even when tethered. If the proper SRV records are not deployed for Lync then the only other option is to use the sip.<sipdomain>, sipinternal.<sipdomain>, or sipexternal.<sipdomain> hostnames for the Lync server, pool, or Access Edge names."
Our Lync 2010/2013 clients are all set for manual config, CXphones connect outside our corp network but not internally. Within our internal network, the sign in error occurs. In light of your comments above, please explain in detail what we need to do to make this work properly. Public DNS records appear to be working since the phones work externally.
Allen, you need to create the required SRV and A records for your SIP domain in your internal DNS zone as LPE cannot use 'Manual Configuration'. The phones must be able to successfully perform either an SRV or Host (A) record lookup in order to sign-in.
I stuck to register the VVX500 Polycom phone with Lync 2013. I really need your advise. I cannot either using user credential or PIN code to sign in to Lync 2013
1/ With the same user account, let say A, I can sign in by PC and use Lync client 2013 normally for chat and call peer to peer by software. however I cannot use the account to sign in by VVX 500
2/ In addition, if I test user authentication in Dos, it is successful if I point to pool domain
Test-Csclientauth -targetFQDN pool1.testing.dic…………
But if I stripped of the targetPool ==> it is fail, and error message is10060, …….connected party did not response, and connected host has failed to respond 18.104.22.168:5061
This is not an IP in my system.
What is the problem
Not sure, I suggest contacting your official support channels.
Hi Jeff, Great article. I have one question regarding the phone certificate. If the certificate expired, will the phone sign out from the lync server and we need manually key in user name/password to sign in and download certificate again? Or before certificate expire, the phone will automatically request to renew the certificate?
The LPE devices do not currently pick up the certificate automatically. You must manually reset the phone (# + *) to trigger a root certificate download, in the event of the root certificate expiring. If the TLS-DSK client certificate were to expire before being automatically renewed then you'd need to sign out and sign back in with the user account.
Is USB tethering to a Mac computer supported with Lync 2013
I had an issue with installing a Aastra phone with Lync for Mac client in a Lync 2013 environment
Not currently; the latest Mac Lync client supports some USB phones but not USB tethering for IP phones running Lync Phone Edition.
Just thought I'd throw this in there as I have had some issues with the CX500 and CX600 after updating from CU6 to CU7 and above. Basically no http traffic was able to be used on the phones. It turns out that after CU6 LPE is able to use a proxy pac file if you have one in your environment. So if you find things like Contact Search, Exchange integraton and phone updates not working then I would start looking at your proxy server and exclude your Lync servers/pools.
Our CX600's can no longer get calendar info from Exchange. We suspect that it is because of the new cert that was installed on the Exchange server and we know it isn't in the approved list for the phone. Is there a way to get the phones to accept it?
Yes, see this article: http://ocsguy.com/2012/05/19/lync-phone-edition-c…
We have a pool (one of 5) that's misbehaving since no phones are getting their updates. When trying to navigate to the http and https url of the cx600 files, I'm greeted with a 404 of that front end pool. Ive verified that the update files exist locally on the server. Upon further investigation of the IIS (comparing it to a known pool) I've noticed that I have missing folders in the Lync Server Internal and External sites. The folder that's missing is the UCPhone folder that's located in the RequestHandler(Ext)>Files directory(s). It looks like this is where the phone update folder structure resides.
I've attempted to re-create a virtual folder but I still get permission errors even though these are the same as the other pools. Long story short, there are several inconsistencies in IIS (including url rewrites and maybe others) in this pool for an unknown reason. Server hardware, OS, system updates and Lync updates are all consistent across the board. Where do i even start other than burning it down and rebuilding this pool (after migrating users to a backup of-course)?
I've never seen that before so I would recommend contacting Microsoft support to see if they can help you recreate the missing folder structure or if that is actually evidence of a bad pool which may need to be replaced altogether.
Greetings, Jeff! I am running into problems with a SoundPoint IP 450 and Lync 2013. I am attempting to use the base Lync option on the phone and have DHCP options 4 (time), 6 (DNS), 15 (DN), 42 (NTP), 43 (MSUCClient), 119 (DNS Search) and 120 (UCSipServer) configured on the DHCP server.
I have successfully tested the DHCP options using the test-CsPhoneBootstrap option from a machine on the same subnet as the phone and I am able to get a Polycom VVX 500 working using all the same parameters. However, the recalcitrant 450 continually fails to download the internal Root CA certificate. With the sip logging turned up to debug, it appears that the phone is not getting the 43 options from the DHCP server. The log entry
"CreateFailOverProxyList : 'Auto Discovery' 0 DHCP servers recieved"
is immediately followed by DNS SRV record lookups (the appropriate SRV records are in place). Then the phone methodically trys to register with each of the seven IP addresses that are returned. After the first attempt fails due to the untrusted certificate, the phone attempts to download the server root certificate, but fails:
"MakeTlsConnection: Fetching server root certificate"
"CTrans::TCPFail workingServer 1 -> 2 0x94e85010"
SoundPoint IP 450
Assembly: 2345-12450-001 Rev:E
3 Enterprise Front-End servers
2 Back-End servers
2 Edge servers
2 Office Web Apps servers
1 Reverse Proxy server
1 Edge hardware load-balancer (KEMP)
1 Internal hardware load-balancer (KEMP)
DNS/DHCP on 2 Active Directory servers
I am sort of baffled as to what to try next. Can you point me in the right direction?
What's the correct number formatting, dial plan rules, trunk rules, etc. for user's phone number to display as 10-digit only on a CX phone?
Or where does the CX phone get it's normalization rules from?
i.e. when I search for a Lync user to view their DiD, it displays it with a + in the front no matter the format in AD –
AD entry – 8885555555
CX Display – +8885555555
The Dial Plan that is assigned to the user which signs on to the phone.
Lync Phone Edition has the same behavior as the desktop client so you do not need to create different dial plan rules for them. You should always normalize for proper +E.164 format as the best practice has always been in Lync.
I have a backup registrar in Lync 2013 and using Polycom CX600 phones and when I failover they dont all reconnect properly to the backup registrar. Do you think i need to increase the hotdesking timeout? I am on lync 2013 CU3.
Make sure you are not running some very old version of firmware as Primary/Backup registrar failover and failback has been supported for a long time.
I just purchased a bunch of new Polycom CX600s for actual deployment, and the firmware shipped was .4327. For some reason, I cannot get any of these devices to connect, yet I have a few others that were initially deployed and do not have any issues with them. There were definitely some issues as a result of the GlobalSign root expiration earlier this year, but I had fixed the issue by making a registry change on the FE servers themselves. When I try to connect through USB, I get the error "Cannot connect to domain controller". When attempting through DHCP, it does not seem to be presenting the Device Client type, so the DHCP options required are never sent and when trying to login, the phone says that the account does not exist.
Is there any way to get the firmware updated accordingly to the latest in the current environment, or will I need to setup something special to do this?
Paul, you may need to use a staging environment with a simple Windows Enterprise CA to get the phones upgraded to a more recent version,
Thanks Jeff! We ended up setting that up, but installing our GlobalSign SHA1 certs into the domain to mimic our production environment as best as possible. Thanks to your most recent blog, we were able to get all 50 remaining phones up and running for deployment. It did require putting the FQDN domain name in the domain user field with USB provisioning as I forgot the updates-rc2 SAN for PIN authentication on the older firmware. I had tried with just the Enterprise CA, but wasn't doing the FQDN domain name with that so built the lab over 🙁 oops!
Anyways, lab was much better as I could do 3 times as many phones, and completed the 50 in a 10th of the time it took me to do the other 50.
Thanks for the reply and your great work!
Hi Jeff, Long time lurker first time poster..
Your Blog and Channel 9 have really helped me along the Lync journey
I'm in the middle of a deployment of Lync 2013 MTHP for one of my clients.
They have a requirement for users with LPE devices to connect using Thin Clients.
I know that USB redirection works with Lync 2010 to get "Better Together" and CTI working with CX600 handsets. However I can find little to know information on Lync 2013
If we setup and use the Lync VDI plugin on the Thin Client the LPE device seems to want to Pair with the VDI plugin and moves on to "Enter your username and password on Lync" but no dialog box is displayed (my guess is because the VDI plugin doesn't have a GUI to actually display the dialog box)
Microsoft points out the above configuration is unsupported. so this behavior is expected. http://technet.microsoft.com/en-us/library/jj2049…
However Disabling the VDI client (both in Set-CSClientPolicy) and renaming the VDI files stops the VDI client from pairing and stealing the phone and thus Lync should attempt to pair with the CX600 once USB redirection is configured
With USB redirection configured in Citrix, the handset appears with all its associated HID devices on the remote machine. However the CX600 never moves from the "plug me in" screen and the remote Lync Full client still displays "Lync cannot connect to your desk phone because the USB cable is not plugged in. Make sure that you connect the cable" in configuration information.
Do you have any experience getting this working? Or am I in seriously uncharted waters?
As you’ve mentioned that is a completely unsupported scenario. Technically Microsoft does not even support LHP on LPE devices, much less compatibility with the VDI client.
Thanks Jeff.. as per my notes we had been disabling the VDI plugin to try and see similar functionality to 2010. But I guess Microsoft removed the functionality from the Fat client when it detects its in a VDI session for better stability/supportability.
The customer has binned the MTHP install and has gone for a normal Lync 2013 Enterprise deployment w/Citrix performing Multi Tenant duties instead and we are presently evaluating options for CTI with other handsets.
Just for testing purposes I popped the Lync 2010 Client into the VDI lab. Straight away it found the LPE device and initiated Better Together pairing showing theirs nothing wrong with our USB redirection policy or the old client handing better together.
Just for anyone looking this up. I had guys at Microsoft confirm this *should* work and was advised to raise a TSS case
The client in this case however opted to roll the LPE clients back to Lync 2010.
Greg, I’ve never seen that before. As usual, make sure you are running the latest firmware.
Jeff, great article. I was wondering if you would be willing to update this article for 2014? Has anything changed?
Nothing has really changed and the same issues covered in here are the most common, other than the various certificate trust issues I’ve created newer article for (check ‘LPE’ tag cloud for the latest related articles).
many thanks for this great article especially the Exchange Integration with Lync Phone Edition.
We have have HP 4110 phones which do not have USB tethering capability and updated to latest firmware 7577.4455.
I can see Call Logs on the HP4110 device, but the Call logs are not synched with Exchange Conversation History folder. Even the missed call notification is not being sent via Email to the userafter updating to this LPE version. (previously i was using the version 7577.4100 and Missed call emails were working fine.
Why after having the latest LPE 7577.4455 on these CommanAreaPhones, I gained the Call Logs capability BUT lost the Missed Call Email Notification.
Even the HP4110 itself DOES NOT alert the user that there is a MISSED CALL on its TFT display.
I am using normal AD accounts with PIN-authentication.
I have not seen that before, I suggest opening a support ticket on this.
Were you able to resolve the issue? I have same symptoms. Users with HP 4110 are not receiving missed call notification.
Jeff — We’re seeing issues with getting the Polycom CX600 (latest firmware 4.0.7577.4455) to connect to Exchange once a mailbox is migrated to Office 365 (E4 license) from on-premise Exch 2010. We were missing the DHCP opt 43 sub-options 1-5, but had 120. Those have been added with no luck. Oddly enough, MWI works, but call logs, calendar, and visual voicemail fail to render. Autodiscover SRV record is configured for on-premise (hybrid mode config). I have opened a case with Microsoft but they can’t really seem to pinpoint anything so far. Hoping to see if you, or anybody else has any suggestions to help.
The DHCP 43/12- options have no impact on Exchange integration as those are only used for PIN Authentication directly to Lync on-premises servers only. If your PSS case has been resolved since posting this question feel free to add the resolution here.
Big thank you for your blog. Even with MS working on it, a single line around the root CA for phone edition only coming from lync server fixed my problem (sort off).
When renewing the certificates for the phones (or new phone installs), we have recently found that you must login to the phone using extension/pin. Once you do this, the certificate will download as normal – after which you will be able to login using the client as well.
Is this expected behavior or is there something wrong.?
That should not be the case, but the certificate can be downloaded differently between those 2 authentication methods so it seems there is some difference in the configuration related to the CA chain of trust.
I’m having a similar problem I think. new phones are ones I have reset to factory with the 4-6 combo won’t download the cert when doing a usb tethered login. the username field in the lync 2010 client defaults to domain/username. When I use domain.local\username the cert will download.
So now I’m looking to either fix the auth for certificate downloading or find some way to make lync default to the fqdn.
Perhaps you have some insight.
wups ” new phones OR ones I have reset to factory”
wups OR not ARE
That usually indicated an issue with WINS or broadcast NetBIOS name resolution. Supplying the DNS domain name in the NetBIOS format is a long-known workaround and you cannot program the phones to prepopulate the user name in that format. It must be entered manually in that way.
It’s not the phones I’m asking about but the usb integration signin box in the lync client. Also I just noticed my boss has his local pc name come up as default in the user name field rather than the domain. I have yet to find where I can change this permanently and/or programmatically.
I don’t think too many places have a flat network it seems silly for it to default to a netbios name,
p.s. sorry about the two correction posts, I thought the first one wouldn’t post because it said it was a duplicate comment.
I have a customer who wants to prefill the logon UM page with a UPN credential.
The issue is :
On the first pairing-process the user provides the credentials in the correct form:
When the user must repeat that process the login-window provided by Lync is prefilled an unsupported Username
What I understood here it is not possible to prepopulate. Can you tell me, if NetBIOS prefill is by design? And that we cannot prepopulate with an UPN logon?
We have VVX500 phones on a hosted Lync 2013. provisioning server is setting up these phones for the most part. and the phones login and register and work fine. we are getting random unregister and re-register on the phones. We will watch as the phone randomly log out, then back in resetting the status. I can’t find any settings in Lync server or Polycom cfg that shows what to do, any advice?
Make sure you are running the latest 5.3.1 firmware. Do not use the recent 5.4.0 release for Lync environments.
i’m struggling to register a Polycom CX3000 to my lync environment with PIN authentication. But when i enter the extension and PIN the device gives the fallowing error: “The update could not be completed. Please check your network connection or contact your support team.”
But if i Use SNOM Phones 7XX series they work normaly. any thoughts are appreciated.
I manage to solve it. I think the problem was generated by the fact that in client version policy I’ve restricted CPE user agent to 8.*.*.* (for SNOM Phones) and Polycom’s version is 4.*.*.* and i think that was blocking the polycom to register.
I’ve got a strange issue with some CX600 phone’s (Around 20 from 600) not signing in, with an error of “Cannot sign in. Please verify your sign-in address, domainWuser name, and password, and try again. Please verify that the domain entered is correct” Please note that the W in between domain and user name has a strike-through on the phone itself. Have you come across this issue before, and know what causes it? I’m currently getting around it by clearing user data from the phone and logging users in again.
I’ve never seen that before, but wiping the phone cache is probably your only option to resolve it.
I have seen this exactly and we have worked around it by authenticating with domain\user or domain.local\user.
That may tell Jeff or others what the exact problem curious if the workaround works for you.
BTW – greatly appreciate all the info Jeff!
Hi Jeff. If we add a phone (cx3000 in this case) and do not want to integrate with exchange (as we don’t want voicemails or calendar on the phone), is there any way of disabling this so we don’t get the error symbol above the menu button and lose the ‘Microsoft Exchange integration unavailable’ error?
No, the Exchange connectivity failure notification can not be suppressed.
Jeff…. a popular thread 3.5 years and still going. We have ~300 CX600s deployed here and have a recent phenomenon where many of them will randomly sign out and straight back in again, no power loss. Most are deployed at various WAN connected branches. We don’t see the issue in our head office which has a local DC, so to date have concentrated our efforts on AD and Mtu/fragmentation issues. No closer to a resolution after quite a few weeks of digging. The only real clue we have to date is that it typically revolves around a 60 min cycle for the sign-out/in event, so now looking for something server-side. Don’t suppose you have come across this one? Firmware date for the CX600 is about April this year. Unfortunately it didn’t coincide with that update. Thanks for any advice.
Damien, the few times I’ve heard of this in the past was always traced back to a server issue. One example was a nightly backup routine on the Lync FE that was stalling the Front End service for a very short period. It seems that Lync Phone Edition devices are more susceptible to this brief outage than the soft clients.
Damien, experiencing the same behavior in our environment. Have you been able to trace this down to an exact cause? This seems to have started in October 2015. Phones have the latest firmware. Only thing we’ve found in PIN auth instead of USB seems to eliminate the sign-out/in issue.
Regarding common area phones and external access;
[…] Clearly this is not a viable solution for remote workers, but it is possible to use for demonstration or temporary testing purposes. Officially Microsoft does not support use of Common Area Phone models externally. […]
I have a temporary office that only has Internet access and need to give them a common area phone. I activated a CX600 as a common area phone on the internal network, but when I connect it to the Internet it fails to log in with “Certificate web service cannot be found”. Also tried it with a CX3000 with the same result. They have the latest firmware, 4.0.7577.4463. User activated phones work fine.
We are currently using Lync 2013 with Polycom CX600 phones. I have to constantly hard reset phones to get it logged in. This appears to be happening with users that work at different locations. They log into their phone in their remote office and then when they come to corporate they log in again to another phone. Could this be causing this issue? Is there a way to have it log off the other phone when logging in the new one? Seems like it is only happening to people going back and forth between offices.
Thanks for any help you can provide.
Michael, if users are physically moving these phones between external networks (Edge-registered) and internal networks (Front End-registered) then this is not really a supported use-case. The phones, once registered will never attempt to re-download a new root certificate chain so if the registration server changes to one that uses a server certificate issued from a different CA chain then the registration will fail. Resetting the devices clears the cached certificates and resolves this issue.
I must say, this is an amazing article. I continue to pluck great details from it. Awesome job!
We have USB tethered Polycom CX600 phone running on Skype for Business 2016. I am dealing with the “expired credentials” issues after users reset their passwords. The phone displays the “Microsoft Exchange integration unavailable” error.
I just wanted to know has Microsoft put out a patch or fix for this integration issue? It would be nice to sync the phone to Skype\Windows automatically after changing the password.
This is in response to the section of your article that says “Expired Credentials – One of the most common reasons for Exchange integration issues is related to the AD credentials in the phone expiring. As previously mentioned authentication to the Lync server happens using a client certificate (TLS-DSK) but Exchange authentication happens using NTLM which requires the AD user’s credentials. If the AD user account’s password has expired then it will still be able to connect to Lync using the client certificate, but NTLM authentication to the Exchange server will fail triggering the “Microsoft Exchange integration is unavailable” error message. In this scenario the device will not prompt the user for new credentials, even when actively USB-tethered to a Lync Windows client. The current user account must manually be signed out of the device and back in to successfully update the password.”
Craig, Microsoft is not addressing this in Lync Phone Edition at this point. The newer Modern Authentication protocol which is coming to Skype for Business will help with issues like this, but not on the older LPE devices as their firmware will not be updated for this new authentication methods. Only newer clients and devices will receive support for this new approach.
Can you identify the authentication protocols that would specifically address this? I am reading up on them, but none specifically point-out this bug as being specifically handled or how to configure authentication to handle it.
Thanks for a such an informative article, I wanted to see if you could help me with vvx 400 series phone sign-in issue, I have the resource forest deployment and the users are in account forest try to signi-n to device gets ssl error 5, but they sigin using pin. The CA certificate is already loaded on the device and SAN entries on the skype FE server has account forest entries. Any help would be appreciated.
Thanks for such an informative article! I have several cx600 Rev-5 phones that I am trying to get setup for SFB online. When I go to get firmware updates for them the only one offered is the latest firmware version which only shows CX600 Rev-6 firmware when added to the SFB front end server. Any tips on where I might find an older firmware version that may also include updates for Rev-5 phones?
The CAB files are all inclusive and should apply to all Revs. I have not heard of this before, but maybe that CU has changes that only apply to the newer hardware revisions.
Excellent article, thank you. Currently I am getting an issue where I try to run the test-csphone bootstrap command and get the following error:
Getting web ticket for the given user is failed. Error Code: 28037 , Error Reason: The AppliesTo
element of web ticket request points to a different web server or site.
I have tried everything. Any ideas?
I recall that command failing often in scenarios where the actual functionality was fine. Might just be a problem that was never fixed with the Test cmdlet.
Thank you you article really helped me , big ups !!
We have an error on our phones and I can’t find any information on it. Any chance you know what 0x2f06/0 means??
Where is the error appearing and what environment are you trying to sign the phone into? That might be an SSL error (tracks back to a Certificate Common Name error from what I could find).