About Me

My photo
These are blogs 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