About Me

My photo
This is a blog for John Weber. One of my joys in life is helping others get ahead in life. Content here will be focused on that from this date forward. John was a Skype for Business MVP (2015-2018) - before that, a Lync Server MVP (2010-2014). I used to write a variety of articles (https://tsoorad.blogspot.com) on technical issues with a smattering of other interests. I have a variety of certifications dating back to Novell CNE and working up through the Microsoft MCP stack to MCITP multiple times. FWIW, I am on my third career - ex-USMC, retired US Army. I have a fancy MBA. The opinions expressed on this blog are mine and mine alone.

2019/01/23

Surface, SfBS 2019, PKI

Thanks to Yomi for helping out. Hopefully you have been nice to him. Apparently today I was worthy.

Do you have:

  • SfB 2019/2015 on-premises?
  • Empty root domain with child domain that has the user accounts?
    • Domain.com and ad.domain.com?
  • Internal PKI for internal functions; public PKI for public-facing functions?
  • Multiple SIP domains?
    • Domain.com, aa.domain.com, someotherdomain.com, someotherdomain2.com, (I had 15 of these)
  • Surface hubs that appear to be V1 devices?
    • Mine reported themselves as 10 (built 15063) with all current updates. This will be a bit tricky as all the guidance from google-fu shows different screens that what I had. But you can probably read between the lines a bit and still be successful.
  • Setup the user account as normal – full Exchange mailbox, setup same to handle calendar auto enroll, etc.
    • Non-expiring passwords highly desired but not required (you have to change the PW on the device each time the user account changes PW)
  • Enable that email account as SfB user. EV not required, but they need to be account as described in various guides… full mbx, full calendaring, etc.

The issue at hand:

  • Surface logs in as device admin, finds Exchange account and logs in. Any attempt to login as SfB account results in either a refusal to do anything (you got the SIP domain wrong) or it just spins.
    • For the first one, check your spelling.
    • For the second, it turns out to be two issues:
  • First, the cert being presented by the SfB internal services is PRIVATE, so therefore a non-domain device/user (like a Surface)(Windows Team – the core O/S on a Surface cannot join domain) does not have the Trusted Root Cert from the internal PKI CA, so it refused to connect.
    • In my case, ZERO additional information – no error message, no nothing… just the spin. Bummer.

Fix:

  • You need to tell the Surface to like/trust both the SIP domain name AND the domain the server itself resides within.
    • Ex: sip domain of domain.com, server domain of ad.domain.com
  • And you need the trusted root loaded onto the Surface.
    • Easier said than done.

To fix the first one:

  • Get into the settings (requires device admin)
  • All Settings| Calling and Audio|configure domain name
    • You can enter multiple names comma separated
  • Restart to have it take effect
  • Download via Windows Store the “Windows Imaging and Configuration Designer.
    • With my squeaky new Zbook, the our corp store barfed on delivering what it said we owned. But, there is another source also:

https://docs.microsoft.com/en-us/windows/configuration/provisioning-packages/provisioning-packages

https://docs.microsoft.com/en-us/windows-hardware/get-started/adk-install

  • I did choice #2/3, and then installed JUST the one tool needed as noted in the link.
  • From there, get a copy of the Trusted Root Cert, and then follow these instructions:

https://docs.microsoft.com/en-us/windows/configuration/provisioning-packages/provisioning-create-package

https://docs.microsoft.com/en-us/windows/configuration/provisioning-packages/provisioning-apply-package

  • Next, restart the Surface.

Finally. Enjoy the goodness.

YMMV

No comments:

test 02 Feb

this is a test it’s only a test this should be a picture