One of the things that makes me feel good about being a fake IT guy is the little victories: when you successfully figure out a problem that's in some ways over your head. Sadly, I don't have a lot of people to share this with -- so onto the blog it goes.
Skype for Business
Our organization has Skype for Business accounts that we don't really use. However, recent issues with our way too expensive videoconferencing equipment has allowed for more investigation into the capacity of Skype for Business. In particular, one of our employees is wanting to do a videoconference with a colleague from our Regina to our Saskatoon office. With the main videoconference equipment down, we thought we'd look into the option of using Skype for Business.
The first hurdle to overcome was making sure we had a guest sign-in for the person to use. We already had one set up in Active Directory, but it would also need an Office 365 account to access Skype for Business. Easy enough: I went into the O365 admin panel and provisioned the license. (This prompted a deeper look at a number of other things that have been left undone for a while around here, and that pile is stacked pretty high. It reminded me a lot of this video, which happens to me a lot.)
The next step was to remote into the Saskatoon computer and set up the Skype for Business connectivity for the guest account. This was tricky, but not super tricky, and I got it pretty much worked out. The final step was to make sure we could connect to Saskatoon from my coworker's computer.
AD to the Rescue
I set things up remotely in Saskatoon and went over to open Skype for Business and login on my coworker's computer. Nothing doing. Skype was throwing an error message that the login, password, or domain was incorrect.
Very well. This sometimes happens, y'know? So I go through the steps again and double-check that things are accurate. Still no go.
I pop back into the O365 admin panel and make sure he's got a license provisioned: check. Then I reset his password to something I can verify and try to login again. Nothing.
I try to login as the guest account on his machine, and it works perfectly. Now I'm frustrated.
Off I go to research the problem. Google tells me I might have the login information entered incorrectly. Nope. Then I read that I might need to upgrade some kind of verification service or that I'm running the wrong version of Skype for Business. Completely unlikely, because I can login with the guest account. I continue to dig through dozens of message boards, reading about problems and potential solutions. I'm marking a few of these as maybes, but writing off most of them as not relevant. Finally, I come across something that says the SIP setting might be out of sync.
This rang a bell for me. We changed our domain a couple of years back and things are still all kinds of messed up for some people in a lot of subtle ways; like, someone's login for the network and their login for Office 365 might be different. (It's one of those things on that giant heap I mentioned earlier that I'll get to. Eventually.) I also recalled that my coworker's login for Skype for Business was our old domain, which I thought was a little weird. Time to open up AD.
I remoted into our domain controller and went to ADSI Edit. Then I looked up my coworker's record, went to properties, found the Proxy Addresses attribute, and sure enough: there was a laundry list of values in there, including an SIP that was out of sync with his account. I made the change, propagated it through AD, checked the propagation, and proceeded to login without further incident. Victory!
Nuts and Bolts
I went into Active Directory Sites and Services, navigated on the left panel down to the DC I wanted, found the NTDS setting in the detail panel on the right side that I wanted to replicate, then right-clicked on that setting and chose Replicate Now.
To verify the replication I opened up PowerShell in administrator mode and used the following command:
As they say in Ireland, done and dusted.