Configuring Lync Server for Phone Edition Devices

As Microsoft Lync Server 2010 was recently released to the general public many professionals will be starting to get their hands on the new UC endpoints designed specifically for use with Lync Server 2010.  My colleague Mike Stacy first talked about the new line of Polycom CX solutions back in May of this year during early beta cycles of the Lync product.

All previous endpoints are still supported in Lync Server with the identical functionality they contained when used in an Office Communications Server environment.  These device include the Polycom CX100, CX200 (LG-Nortel IP8501), CX300 (Plantronics Calisto P540), and CX700 (LG-Nortel IP8540) voice endpoints.  All of those except for the CX700 (the sole member of Tanjay family) are USB-only devices and simply just plug-and-play into a workstation running the Lync client.  They do not run any version of the Lync Phone Edition client.

Previously the CX700/IP8540 was the only device which ran the Phone Edition client, but now the new Aries family of devices (Polycom CX500, CX600, CX3000 and Aastra 6721ip, 6725ip) all run a new version the Lync Phone Edition client.

As there are many past articles covering the requirements for supporting both Ethernet and USB tethered login methods for the Tanjay phones this article will not cover those items individually.  Instead the configuration detailed here will support both device families for internal connections. No Edge Server configuration is included, that is reserved for a future article.

Behavior

Tanjay

Basically the Tanjay series phones will function in the same way in Lync as in OCS, using the same interface and connection prerequisites.  For example contact photos are not implemented on the Tanjay as that features was not available in Office Communications Server. As there are many article already devoted to managing these devices there is no need to rehash it here.

Aries

The new PIN Authentication process greatly simplifies the user sign-in process on stand-alone device now.  As described in the Tanjay version keying a SIP URI, Domain Name, User Name, and Password on the touchscreen was not the most fun experience each time.  With the new version supported on the Aries devices user simply enter their phone extension and PIN to sign-in directly on the phone.  The Enterprise Voice normalization rules was leveraged (just as in Dial-In Conferencing) so that extensions can be supported.  This allows users to key in a short extension (e.g. 7501) versus their entire phone number (e.g. 13125557501).

The PIN used for authentication is the same PIN that is used for Dial-In Conferencing, so the user only needs to remember one unique PIN for logging in to either Aries phones or into audio conferences from PSTN analog phones.  An additional device-specific PIN will need to be set for Device Unlock, but this is asked for each time a new user signs into an Aries device.  This PIN is only used to unlock the device once the inactivity timeout value is reached and can be the same or different, provided that both authentication and unlock PIN policies are configured with the same length and complexity requirements.  Be default the PIN authentication requires 5 digits and the device unlock policy is set to 6; these can be easily modified to match if desired.

The DHCP option required to support the PIN Authentication method can either be added to an existing DHCP server or they can be handled directly by the Lync Server.  The first method is recommended and is the easiest to deploy when working with Windows DHCP services.  But if third-party or hardware-based DHCP solutions are deployed which may or may not supported the additional options required by the Aries devices then it may be beneficial to use the integrated Lync Server DHCP services.  Understand that this alternate approach does not replace the primary DHCP services as the Lync Server will not hand out DHCP leases, it only provides the additional DHCP options to clients which know to ask for them (the Aries phones).  Obviously where ever the device are located throughout the network these DHCP requests will need to be forwarded to the subnetwork where the DHCP server (and/or Lync Server) resides.

Outline

This in-depth article covers not only what each of the required components are, but what they do and why they are needed (or in some cases, not). These topics are:

• Configuring legacy DHCP options and DNS records
• Understanding the new DHCP options used to support PIN authentication on new Aries phones
• Verifying the Lync Server configuration
• Testing PIN Authentication
• Connecting a Phone

Time Synchronization

Regardless of which family of devices (Tanjay or Aries) both require the ability to properly synchronize their clocks with an external time source.  Now this topic can go down the rabbit hole very quickly as between the different devices and versions of software I have witnessed slightly different behavior.  Yet most often devices are able to synchronize their time without issues as they will fallback to connecting to a hardcoded FQDN (time.windows.com) over the Internet.  So even if your environment is not correctly configured in this area as long as a default gateway is passed to the DHCP client and the phones can connect to the Internet then it’ will work regardless.

After some extensive testing I’ve come up with the basic recommendation to define time server settings in both DHCP and DNS regardless of what device you plan to use and on what levels of code. There really can be no valid argument for omitting time server settings in either system so in an attempt to save yourself some possible heartache take my advice and just configure all of these settings.

Verify NTP Servers

The TechNet instructions for utilizing NTP indicates that the Enable Windows NTP Server group policy setting should be enabled without any mention of what this setting does or why it might be needed.  But most often this step can be omitted as Windows Domain Controllers are already enabled for handling NTP client requests.  Thus the DHCP and DNS time server settings should all be pointed to a domain controller.

• To validate that the NTP server functionality is enabled, simply run this command from the Windows Command Prompt on the domain controller of choice.

w32tm /query /configuration

In the results look under the [Time Providers] section for the following NtpServer settings.

NtpServer (Local)
DllName: C:\Windows\system32\w32time.dll (Local)
Enabled: 1 (Local)
InputProvider: 0 (Local)
AllowNonstandardModeCombinations: 1 (Local)

The setting Enabled:1 means the server is enabled and actively listening on port 123 for UDP requests for time synchronization data from client.

Additionally run the same command on a standard Windows Member Server (the Lync server, for example) and most likely the NtpServer section will not be listed at all, indicating that the server is acting as an NTP client only.

Configure DHCP Options

Add both the 004 Time Server and 042 NTP Servers options to the Windows DHCP server configuration.

• Using the DHCP Manager configure the IPv4 Server Options, add the 004 Time Server option, and enter the IP address of the desired domain controller.

• Highlight the 042 NTP Servers option and enter the same IP address as used above.

 

Configure DNS Records

The importance of the DNS records really comes into play with externally connected devices, but they are equally important for internal connections.  Once the devices are aware of their SIP domain then they perform Service Locator record lookups in the same domain for a time server (e.g. _ntp._udp.domain.com).

It important that each SIP domain in the environment contains an NTP record as the lookup will be based on the suffix of the authenticating user’s SIP URI.  And following the same best practices used in the past of pointing SRV records only to other records in the same domain a new Host (A) record will be required for each domain as well (e.g. time.domain.com).

• Create a new DNS Host (A) record in the SIP domain’s forward lookup zone which resolves to the desired domain controller (e.g. time.mslync.net)

• Create a new DNS Service Location (SRV) record in the same forward lookup zone and then define the Host offering this service as the new host record which was just created.  The Service should be _ntp with the Protocol set to _udp and the Port Number at 123.

Also make sure to verify that the Lync Server environment is correctly configured for Automatic Configuration of Lync clients.  At minimum this includes creating a _sipinternaltls SRV record as discussed in this previous article.

DNS Search Lists

DHCP Option 119

When it is appropriate to use option 119 was covered by Jens Trier Rasmussen a few years ago and his article breaks down the process and requirements clearly.  In short if the Phone Edition devices are located in the same subnet as the Windows servers or broadcast packets are fully routed between the clients and server, then setting this option is not necessary.  If the devices are separated from the server via VLANs or physical routing devices which do not allow for NETBIOS broadcast traffic to traverse them, the either (a) configure WINS Servers and add them to the DHCP Options list or (b) use User Principal Name (UPN) format when signing into the CX700.

This same requirement applies to the Aries devices when attempting to authenticate to Lync Server after tethering to the phone via USB to a workstation.  If PIN authentication is utilized directly from the device’s Ethernet connection then option 119 is not necessary (given the previously stated environmental conditions are true).  But considering you cannot prevent users from tethering in most cases it would be foolish to not support NETBIOS based (DOMAINusername) username formats in the deployment.

So, although this is not needed for my lab environment I’ve included instructions on how to add option 119 to the existing DHCP scope; defining a few domains will not hurt anything as long as they are valid.

Configure DHCP Option

• Using DHCP Manager highlight IPv4 and select Set Predefined Options then click Add.  Enter a  Name of DNS Search List, select a Data Type of String, and enter a Code of 119.  The Description field is optional

• Under IPv4 highlight Server Options select Configure Options.  Locate 119 DNS Search List and enter the desired domain names in the String field, using a semi-colon to separate additional names (e.g. schertz.local;mslync.net).

At this point the Scope Options (which display both inherited Server Options and Scope-level options) should display at least the following items: 003 Router, 004 Time Server, 006 DNS Servers, 015 DNS Domain Name, 119 DNS Search List.  Additional items may be included which are specific to your existing deployment and are not utilized by Lync.

Aries PIN Authentication

Here is where things start to get interesting as the new Aries devices now leverage a host of new DHCP options.  A number of sub-options are categorized under option 43 and are used for provisioning new devices over Ethernet.  The second option is used to allow the Aries phone to locate a Lync SIP registrar to sign-in to.

What is important to understand is that these options are solely for supporting the PIN authentication process of the phones without first utilizing USB tethering and are not mandatory.  It is possible to tether an Aries phone to a workstation with a Lync client signed-in and the phone will download the root/issuing certificate from the Lync server as well as cache the Lync user’s SIP URI and domain credentials.  Once the phone has successfully connected it can be untethered (and even restarted) and will sign-in to the Lync server over the Ethernet connection automatically.  The cached SIP URI will be used to preform a standard SRV/A client lookup to locate the correct Lync registrar, and the cached credentials will be used to authenticate against the Lync Server.

Just to reiterate this point, as it is commonly misunderstood in the field, there is no requirement that an Aries device (which contains a USB port) must be provisioned first on an internal network in order to download a certificate.  This is incorrect as a brand new device can function in either ‘Better Together’ mode (USB) or in Ethernet stand-alone mode (via PIN auth) once it is first successfully tethered to a workstation with the Lync client. 

That said, the Polycom CX500 and Aastra 6721ip endpoints do not include USB ports for tethering so if either of those devices are to be used then the new DHCP options must be deployed on the internal DHCP server.  And as a general best practice these options should really be deployed as it’s not a great user-experience to always require USB tethering each time a new user needs to sign-in to a device.

DHCP Option 43

As previously mentioned Option 43 is not really a single option but a number of sub-options which tell the phone where to locate the Certificate Provisioning service on the Lync server.

Option Number	Option Name	ASCII Value (example)
001	UCIdentifier	MS-UC-Client
002	URLScheme	https
003	WebServerFQDN	lync.schertz.local
004	WebServerPort	443
005	CertProvRelPath	/CertProv/CertProvisioningService.svc

When reassembled into a single value these sub-components build a complete URL as Option 43 to the DHCP client.

https://lync.schertz.local:443/CertProv/CertProvisioningService.svc

DHCP Option 120

Once the certificate is downloaded to the phone then a valid Lync registrar server needs to be located.  The value of Option 120 will be the FQDN of the Lync server which will handle authentication requests from the phones.  This must be a Lync server as the Aries devices cannot sign into a down-level OCS 2007 or 2007 R2 server.

 

The TechNet documentation on this option currently states that “the pool FQDN suffix must match the user’s SIP address”.  This statement is under review and should be updated to more correctly explain that it is not a requirement that the suffixes match.  In the example here I have used the local AD namespace of schertz.local to reference the Lync server’s actual hostname.  This value is in the Lync server’s certificate and thus any users in the SIP domain of mslync.net will still connect successfully.

Configure Windows DHCP Server

Luckily setting up these options is much simpler than actually understanding what they do.  Microsoft has included a utility and script with Lync Server which will automatically add the appropriate values to a Windows DHCP server.  Currently this utility is only supported on 64-bit operating systems so if your Windows DHCP server is running on an older 32-bit server then you will have to run the commands separately.  A completely manual process will be required if any non-Windows DHCP servers are used in your environment.

• If using 64-bit Windows DHCP servers copy the DHCPUtil.exe and DHCPConfigScript.bat files from the following default location on the Lync Server to the Windows Server(s) running DHCP services for subnets where any phones will be connected.

%ProgramFiles%\Common Files\Microsoft Lync Server 2010\DHCPUtil.exe

%ProgramFiles%\Common Files\Microsoft Lync Server 2010\DHCPConfigScript.bat

• If using 32-bit Windows DHCP servers then only copy the DHCPConfigScript.bat file from the Lync server to the DHCP server.  The DHCPUtil.exe tool will be run on the Lync server locally and the output will be used to call the batch file manually on the DHCP server.

Executing DHCPutil.exe /? will return most of the available switches and a quick read-through appears to indicate a number of switch will be necessary.  The keys to using this commands are that (1) if a single Lync Server is deployed in the environment then only the -SipServer is required as the same FQDN will be used for the other settings and (2) the –RunConfigScript option needs to be included otherwise the command will only printout what changes it ‘would’ make but will not actually do anything.

• So this next step is optional (and purely for education) when dealing with a 64-bit DHCP server configuration, but must be run on the Lync Server for 32-bit DHCP server configuration.

DHCPUtil.exe -SipServer lync.schertz.local

(If the error “application has failed to start because its side-by-side configuration is incorrect” then take a look at Mike Stacy’s blog article for the resolution.)

The following output explains that you must either (1) re-run the command with the aforementioned –RunConfigScript or (2) manually execute the example command which contains the hexadecimal strings.

SIP Server FQDN : lync.schertz.local
Certificate Provisioning Service URL : https://lync.schertz.local:443/CertProv/CertProvisioningService.svc

Option 120: 00046C796E63077363686572747A056C6F63616C00

Vendor Class Identifier: MS-UC-Client
Option 43 (for vendor=MS-UC-Client):
        sub-option 1 <UC Identifier>: 4D532D55432D436C69656E74
        sub-option 2 <URL Scheme>: 6874747073
        sub-option 3 <Web Server FQDN>: 6C796E632E7363686572747A2E6C6F63616C
        sub-option 4 <Port>: 343433
        sub-option 5 <Relative Path for Cert Prov>: 2F4365727450726F762F43657274
50726F766973696F6E696E67536572766963652E737663

To configure DHCP Server with appropriate values, you can do one of the following things:
        1. Run DHCPUtil on the DHCP Server: use ‘-RunConfigScript’ switch
        2. Run the following command on the DHCP Server (modify the path of DHCP
ConfigScript.bat appropriately):
"C:\DHCPConfigScript.bat" Configure MS-UC-Client 00046C796E6307736368657274
7A056C6F63616C00 4D532D55432D436C69656E74 6874747073 6C796E632E7363686572747A2E6
C6F63616C 343433 2F4365727450726F762F4365727450726F766973696F6E696E6753657276696
3652E737663

• For 32-bit DHCP server configuration capture the command line string listed under item #2 at the end of the output and then execute it locally on the DHCP server

C:>DHCPConfigScript.bat Configure MS-UC-Client 00046C796E6307736368657274
7A056C6F63616C00 4D532D55432D436C69656E74 6874747073 6C796E632E7363686572747A2E6
C6F63616C 343433 2F4365727450726F762F4365727450726F766973696F6E696E6753657276696
3652E737663

• For 64-bit DHCP server configuration re-run the DHCPUtil command locally on the DHCP server with the RunConfigScript switch to apply the changes to the DHCP server options.

C:>DHCPUtil.exe -SipServer lync.schertz.local –RunConfigScript

The script will open in a new window and the various netsh commands will be executed with the secondary closing upon completion.

• To validate the new changes highlight the server name in DHCP Manager and refresh the console.  Expand IPv4 and then highlight Server Options to the new options should be listed.

• To view the details of these new options simply view the properties of any one entry in this list and the Advanced option list should appear, showing the MSUCClient Vendor Class options.

 

Configure Lync Integrated DHCP (Alternative Configuration)

This step is optional and will not actually be used in this article, but it is important to understand there are two choices here.  As previously explained the DHCP options 43 and 120 can be offered by either the same DHCP server scope which provides IP addresses to requesting clients, or they can be provided directly by the Lync Server, after clients have received an IP address fro the primary DHCP server.

So basically the scenarios are either:

1. All DHCP options on configured on a standard DHCP server
2. Most DHCP options are configured on a standard DHCP server and options 43 & 120 are configured on a DHCP ‘lite’ service which runs on the Lync Server.

Again, only configure this next setting if the devices will be installed in the same subnetwork that the Lync Server is installed in or if the current DHCP server does not support the ability to add the 43 sub-options.  Only enable this option if the previous configuration steps were not performed and the primary DHCP server does not or cannot handle the 43 and 120 options.

• From the Lync Server Management Shell enter the following cmdlet.

set-CsRegistrarConfiguration –EnableDHCPServer $true

Validate Options 43 & 120

The DHCPUtil tool can also be used with the –EmulateClient switch to test that the new options are correctly installed and will be presented to the DHCP client as expected.

Select a workstation or server other than the DHCP server itself to run the client emulation test.  The client emulate test does not function from the DHCP server locally .  Also select a test host with a single active network adapter as there is a bug which makes the test fail with multiple adapters enabled.  This test should also work from the Lync server but make sure to also test from a client on the same subnet where the phones will be deployed.

• Copy the DHCPUtil.exe program to a test computer and execute the following command.

DHCPUtil.exe -EmulateClient

If a Windows Security Alert appears for the DHCP Configuration Utility click Allow Access.  The results will list the contents of both the DHCP client’s INFORM packet and the DHCP server’s ACK response packet.

Firstly the Option Field portion of the INFORM packet shows how the client uses Option 55 to ask for specific options 120 and 43 from the server, as well as offers the known Vendor ID of MS-UC-Client.

DHCP: Option Field
    DHCP: DHCP MESSAGE TYPE(  53) = (Length: 1) DHCP INFORM
    DHCP: Server Identifier(  54) = (Length: 0) 0.0.0.0
    DHCP: Client Identifier(  61) = (Length: 7) ☺ (0100155D670224)
    DHCP: SIP Server( 120)        = (Length: 0) enc:0  ()
    DHCP: Host Name(  12)         = (Length: 4) LYNC
    DHCP: Vendor Identifier(  60) = (Length: 12) MS-UC-Client
    DHCP: Param Req List(  55)    = (Length: 2) 120 43
    DHCP: Vendor Info(  43)       = (Length: 0)  ()
    DHCP: End of this option field

In the returned ACK packet the same Option Field section now lists the options 120 and 43 in the DHCP server which have been supplied to the DHCP client.

DHCP: Option Field
    DHCP: DHCP MESSAGE TYPE(  53) = (Length: 1) DHCP ACK
    DHCP: Server Identifier(  54) = (Length: 4) 192.168.103.20
    DHCP: Client Identifier(  61) = (Length: 0)  ()
    DHCP: SIP Server( 120)        = (Length: 21) enc:0 lync.schertz.local (00046
C796E63077363686572747A056C6F63616C00)
    DHCP: Host Name(  12)         = (Length: 0)
    DHCP: Vendor Identifier(  60) = (Length: 0)
    DHCP: Param Req List(  55)    = (Length: 0) 0 0
   DHCP: Vendor Info(  43)       = (Length: 90) ☺♀MS-UC-Client☻♣https♥↕lync.sch
ertz.local♦♥443♣%/CertProv/CertProvisioningService.svcÜ♥NAP (010C4D532D55432D436
C69656E740205687474707303126C796E632E7363686572747A2E6C6F63616C040334343305252F4
365727450726F762F4365727450726F766973696F6E696E67536572766963652E737663DC034E415
0)
    DHCP: End of this option field

The final portion should display these option values (SIP Server and Certificate Provisioning URL) in a more readable format along with a Success status.

Result: Success
DHCP Server : 192.168.103.20
SIP Server FQDN : lync.schertz.local
Certificate Provisioning Service URL : https://lync.schertz.local:443/CertProv/CertProvisioningService.svc

 

Lync Server Configuration

At this point the environment is ready to connect both Tanjay and Aries devices.  But before a user can sign-in directly from a phone the Lync user account must first be enabled for Enterprise Voice (for both device types) and a PIN defined (Aries only).

Enable Enterprise Voice

• To enable a Lync user account for Enterprise Voice create new account, or edit an existing account , and select Enterprise Voice from the Telephony drop-down and then define a unique Line URI in the proper format (e.g. tel:+<number>).  This process is discussed in more detail in this previous blog article.

Set PIN

• Using the Lync Server Management Console locate and highlight the user account and then select Set PIN… from the Action menu.  Enter the desired PIN, adhering to any policy requirements.  The default policy will only accepts PINs of 5 digits and series or repeating numbers (e.g. 12345 or 44444) cannot be used.

• Alternatively the Lync Server Management Shell can be used to set the authentication PIN on Lync user accounts by using the following Set-CsClientPin cmdlet.

Set-CsClientPin -Identity Laura -Pin 14753

Enable PIN Authentication

The PIN Authentication method is already enabled by default on the Lync Server, but it is a good idea to first validate that is enabled.  If for some reason it is not, or a different policy (other than the Global) is in use which it is disabled on, then PIN authentication using the following commands.

• Enter the cmdlet Get-CsWebServiceConfiguration in the Lync Server Management Shell and verify the value of the UsePinAuth setting is ‘True’.

 

• If the value is False (it should be enabled by default) then use the following cmdlet to enable it on the global policy.

Set-CsWebServiceConfiguration -Identity Global -UsePinAuth $true

Alternatively the Lync Server Control Panel (LSCP) can be used to check the current

• In the LSCP go to Security > Web Service and look at the Global object’s properties for verify the Enable PIN authentication setting is checked. (The PIN check in the previous window also shows the same setting.)

Verification

Bootstrap Emulator

The easiest way to test that the configuration is correct an working is to use the Lync Phone Edition emulator which is spawned by using the Test-CsPhoneBootstrap cmdlet.  This process can be run from the Lync Server itself, assuming that DHCP server responses can reach the subnet where the Lync Server is installed.  In a flat network this is no problem, but in a larger, segmented network it may not work locally.  In that case the Lync Server Management Console can be installed on a workstation in the correct subnet and the test run from there.  (Or if you are feeling adventurous just fire up that shiny new CX600 and see if everything works.)

• Run the following cmdlet from the Lync Server Management Console and supply the extension number and PIN for an Enterprise Voice enabled Lync user account.  (Note that in this example only four digits are supplied as the PhoneOrExt value as the Lync Server contains Normalization Rules which will translate that 7501 string out into a full RFC3966 format of +13125557501.  For more details see Part 3 of the Lync deployment articles.)

Test-CsPhoneBootstrap -PhoneOrExt 7501 -PIN 14789

As this process dumps a ton of output I will just highlight the important items.

• The client constructs a DHCP request packet, specifically asking for the required options that Lync Phone Edition needs. 

Constructing a dhcp packet
Adding dhcp option PARAMETER_REQUEST_LIST
Successfully added dhcp option
Adding dhcp option VENDOR_CLASS_IDENTIFIER
Successfully added dhcp option
Successfully constructed dhcp packet

• The response from the DHCP server is deconstructed with the various DHCP options. (Some of the text will be goofy ASCII characters when read in plain text.)

Constructing a dhcp packet from received raw data
Extracting DHCP Options
DHCP Packet successfully constructed

Message Type : DHCPACK
Option43 : ☺♀MS-UC-Client☻♣https♥↕lync.schertz.local♦♥443♣%/CertProv/CertProvisioningService.svc?♥NAP
Option55 :
Option60 :
Option120 :  ♦lyncschertz♣local
Other options : 6♦??g¶☺♦???

• A standard HTTP connection is attempted to the Certificate Provisioning service on the Lync Server.  If the connection is successful then the client will request to download the root certificate for the Lync Server’s configured certificate.

Connecting to web service : http://lync.schertz.local/CertProv/CertProvisioningService.svc 
Using anonymous authentication 
Successfully created connection proxy and website bindings 
Attempting to download certificate root chain 
request created 
GetRootCertChain() webservice call successful

• With the root certificate downloaded the client then connects to the Lync server over SSL (443) and requests a Web Ticket.

Connecting to web service : https://lync.schertz.local:443/WebTicket/WebTicketService.svc
Using PIN authentication
Successfully created connection proxy and website bindings
Requesting new web ticket
Sending Web-Ticket Request:

• The  20 or so lines of XML after the text below is comprised of the request data.

• A Web-Ticket response is then received from the server, followed by a hundred or so lines of the XML data.  Don’t read this if you value your free time.

• Another new connection is made from the client to server via SSL.

Connecting to web service : https://lync.schertz.local:443/CertProv/CertProvisioningService.svc
Using Webticket Proof authentication
Trying to download MEX data from https://lync.schertz.local:443/CertProv/CertProvisioningService.svc/mex
Searching for end point with name CertProvisioningServiceWebTicketProof
Searching for end point with name CertProvisioningServiceWebTicketProof
Found endpoint with name CertProvisioningServiceWebTicketProof
Using CertProvisioningServiceWebTicketProof endpoint
Successfully created connection proxy and website bindings
Attempting ResolveUser()Creating WebTicket security token request
ResolveUser() webservice call successful
Connecting to web service : https://lync.schertz.local:443/WebTicket/WebTicketService.svc
Using PIN authentication
Successfully created connection proxy and website bindings
Requesting new web ticket
Sending Web-Ticket Request:

• A second Web-Ticket response is received. More excitement. I’ll spare you the screenshot.

 

• The response is handled by the client and should complete with a successful GetAndPublishCert webservice call.

Connecting to web service : https://lync.schertz.local:443/CertProv/CertProvisioningService.svc
Using Webticket Proof authentication
Trying to download MEX data from https://lync.schertz.local:443/CertProv/CertProvisioningService.svc/mex
Searching for end point with name CertProvisioningServiceWebTicketProof
Searching for end point with name CertProvisioningServiceWebTicketProof
Found endpoint with name CertProvisioningServiceWebTicketProof
Using CertProvisioningServiceWebTicketProof endpoint
Successfully created connection proxy and website bindings
Requesting certificate for User:jeff@mslync.net
EndpoinID:4815e36e-4028-5c2f-99c6-7e95082e4fc8Creating WebTicket security token request
GetAndPublishCert() webservice call successful

• The bootstrap test should then finish with a brief summary report.

TargetUri  : https://lync.schertz.local:443/CertProv/CertProvisioningService.svc
TargetFqdn : lync.schertz.local
Result     : Success
Latency    : 00:00:02.3250824
Error      :
Diagnosis  :

Polycom CX500

The final test is to connect an Aries device without a USB interface (no cheating!) to validate that everything is setup correctly.

• Power-on the phone and wait for the animated logon-screen to appear.  Press the select button as demonstrated.

• Enter the same Phone Extension and PIN of the user account previously used with the test bootstrap method.

    

• The Signing In process while briefly display “Contacting Time Server” followed by “Connecting to Lync Server” for a few seconds.
• Indicating a successful connection, the next prompt will ask to define the temporary phone-unlock PIN which will be used for the duration of the time this account is signed into this phone.  This PIN is retained between phone reboots and it only lost when either the user is signed-out or a factory-reset is performed.