Microsoft Copilot is all around...

  As the debut of Microsoft 365 Copilot approaches, there are a lot of Copilot features set to be introduced across the Microsoft 365 ecosystem. Here are a few noteworthy additions: Microsoft has unveiled a series of innovative features in the upcoming releases of Windows 11, some of them are already released, and some are currently available in preview builds. The Windows 11 Copilot, conveniently located in the taskbar, eliminates the need to open your Edge browser. It is seamlessly integrated with Bing Enterprise Chat (BEC) and ChatGPT, making it really easy to get started on your creative journey. Included in Windows 11 is the new co-creator feature in Paint. This feature, also in preview, is integrated with DALL-E and provides a swift and straightforward method for creating illustrations and images. If you possess a knack for crafting descriptions, you can generate quite impressive imagery. Another AI-powered feature is image creation directly from BEC. This feature, also integrate

A thing about DHCPUtil -EmulateClient

I was trying to troubleshoot a Lync phone registry issue for a client of mine, and I ran into an issue I haven't seen before.

As I do not have access to every LAN to every customer at all times, I often get the customer to run certain commands and have them read me the output. When troubleshooting the registration of a CS-Commonareadevice, one of these commands are "DHCPUtil -Emulateclient". I send them instructions on how to map to the Lync server, set their path correct, and run the command from dos.

Usually, I've only been concerned whether the result is a failure, or success. Preferably have the client read out loud the bottom lines of the output. It would look something like this, and I'll say: Read me the result, and what ever information below "result".:

If the result is "success", and everything else seems valid, I will then move on to run the test-csphonebootstrap command, and try to understand the underlying issue.

This is what the test-csphonebootstrap had to tell me:

If you look closely at the TargetURI, it is missing something. It should contain the FQDN of the webservice providing the RootCertChain. So I told the customer his DHCP was all wrong, and asked him to fix it. He's reply was: "No, it's not". And he provided a screenshot of the settings/options showing everything was in order (Or at least it looked like it was in order)

Time to inspect that DHCP ACK packet in-depth. Or at least scroll up a line or two. And try to figure out what was happening.

This is what I saw with my own eyes:
Success, and the correct provisioning url as shown in the first screen shot. But as I scrolled up, I saw something interesting:

Taking a closer look at the option 43 as the client read it, it revealed the values were read in the wrong order.
I do not know why the result came out "Success" or why the output seemingly gave the correct provisioning URL. But I do know the phones didn't register and the test cmdlet gave me an error, and cleaning up the DHCP (removing settings, and reapplying them as described in this post) fixed the error.

Lessons learned:
- Don't always accept "Success" as a definite answer when troubleshooting. Sometimes you still need to take a closer look at things. The -Emulateclient obviously only look for the values in DHCP, and it doesn't do a syntax check. Nice knowing? It took me a couple of rounds before I really realized what was wrong.
- And from now on, I will have to ask the customer for the entire output not just the result.


Anonymous said…
Recreating the Options solved the problem for me.
Some hours wasted...