Skype for Business - online

Migration to Skype for Business Online

After the AD Sync and license application, I was wondering why no users where showing up in the Lync Admin panel, despite having a valid license applied.

After a bit of searching, I discovered that if you have previously had an On Premises Lync installation, you need to clear the AD attributes associated with that configuration, then wait/force a sync before the users will show up in the portal.

msRTCSIP-DeploymentLocator
msRTCSIP-FederationEnabled
msRTCSIP-InternetAccessEnabled
msRTCSIP-Line
msRTCSIP-OptionFlags
msRTCSIP-PrimaryHomeServer
msRTCSIP-PrimaryUserAddress
msRTCSIP-UserEnabled
msRTCSIP-UserPolicies

No doubt there will be more on that when we get closer to an actual cutover to the online service!

A handy powershell snip I found for clearing these attributes:

Get-ADUser -Filter {proxyaddresses -like "sip:*"} |

  Set-ADUser -Clear  msRTCSIP-ApplicationOptions,msRTCSIP-DeploymentLocator,msRTCSIP-Line,msRTCSIP-OwnerUrn,msRTCSIP-PrimaryUserAddress,msRTCSIP-UserEnabled,msRTCSIP-OptionFlags



ADFS and Azure AD Connect Part II

So after my earlier issues missing the Customised settings for configuring AD Connect, I stumbled across another awesome "feature".

Everything was working as planned until the 3rd to last step, then I got the below error:

"We cannot federate an Azure AD domain while signed in to Azure AD as a user in the same domain. Please choose a different domain to federate or restart this wizard and provide different Azure AD global administrator credentials"

Well, thank you very much, that's confusing.

So, I re-ran the wizard after creating a different global admin account.
Nope, same error.
After much angst and retries, it turns out that MS wants you to use their domain for the Azure connect account.

This involved logging into the Azure Portal and manually updating the global admin user account to have the sign in <username>@<yourdomaincomhere>.onmicrosoft.com

After configuring this in the Azure Portal, I went back to the Connect to Azure AD setting and changed the user account to use @<yourdomaincomhere>.onmicrosoft.com and the wizard completed successfully.

Success!

Onward to the next unexpected issue that needs to be resolved! 

ADFS and Azure AD Connect

The steady march on to "Cloud" based services continues. Don't even start me on the use of the catch phrase "Cloud" nothing there has changed, we're just calling it something new now. But I digress.

Mid configuration and implementation of our migration to aforementioned service and I discover I've made an error in AADC configuration.

Apparently there's no option to change from the "Express settings" option to "Custom settings" after using Express during the installation. Seems like an omission to me.
I missed the ADFS step and thought I could go back and just re-run the wizard to configure it. Unfortunately the option was missing, no matter how many times I re-ran the wizard. (Yes, I ran it a few times).

So, after the tried and true Uninstall/Reinstall method, I correctly selected "Custom Settings" and now get all the bells and whistles for ADFS configuration!

Woohoo!

On a side note, I'm looking forward to the Passthrough authentication option coming out of Preview mode. This will make the connection a little bit more seamless than the current ADFS option.

Software, I love it!

Why can't software be simple? You know, you install it, click ignore on the usual caveats (at your peril) then Next Next Next and it just works.

My recent experiences tell me this is not always so.

One particular product requires install from original executable, then every update since then to get you to the latest working package.

Then there's tab order in applications, or consistent location and icons of common application features like Save, or Next, or Back.
It's the simple things that make life work and when the simple things are ignored in software fundamentals, it just makes the life of an IT guy that much more difficult!