Thursday, October 29, 2015

Configure Hybrid In Your Skype for Business Environment

Hybrid is becoming a huge buzzword. Hybrid Cloud. Hybrid Cars. Hybrid everything! And each is "hybrid" in a different context. Today, I want to discuss implementing Hybrid in a Skype for Business environment.

In addition to seeking guidance on configuring your hybrid deployment with the content from this blog post, be sure to also download a FREE copy of my Hybrid Handbook eBook on the TechNet Gallery: It will provide guidance on various Skype for Business "Hybrid" topics.

What exactly does Skype for Business Hybrid mean? Well, simply put, Hybrid within your Skype for Business deployment is when you have an On-Prem Skype for Business Server 2015 (or Lync Server 2013) deployment, AND Skype for Business Online (Office 365), and you want to connect the two environments. This way you can have some users in your On-Prem environment and others in your Online environment, while they are all part of the same SIP domain, and communicate freely as if they were all in the same physical deployment.

Why Skype for Business Hybrid?

This is a fair question. Why add the complexity to an already deployed Skype for Business Server 2015 deployment? Or the reverse: why complicate your simple Skype for Business Online environment with a whole new On-Prem deployment? Here are a few key reasons:
  1. Flexibility. In today's work environment, users are scattered geographically, and also have varying functionality needs. While some can operate fully within the available feature set of Skype for Business Online, others may need more enterprise-level features that are only found in On-Prem, such as advanced Enterprise Voice functionality.
  2. Cost Savings. By having some Skype for Business users remain cloud-based, you save significantly on licensing costs compared to those users that are on-prem.
  3. Leaner On-Prem Environment. This is kind of tied in with the previous two comments, but the more users you have in Office 365, the less beefy your on-Prem deployment has to be. This goes beyond Skype for Business, as well. If those Office 365 users are also using Exchange Online, or SharePoint Online, those On-Prem deployments can also likely be scaled down over time.
Again, the above points are just a few obvious reasons why a company might want a Hybrid environment. Now that we have taken a quick look at why, let's explore our existing lab environment, and discuss the leg work that was done before we made the actual connection between environments and moved a user to Online.

The Lab Environment

The On-Prem lab environment was built in the Rackspace public cloud, which was very easy to deploy and manage (Disclaimer: for those that don't know, I am a Rackspace employee). It consists of the following servers:

  • 1 Active Directory Domain Controller
  • 1 Azure AD Connect Server for Directory Synchronization
  • 1 Active Directory Federation Services Server
  • 1 AD FS Web Proxy
  • 1 Skype for Business Server 2015 Standard Edition Front End
  • 1 Skype for Business Server 2015 Edge Server
  • 1 Reverse Proxy (IIS w/ ARR)

For the certificates on the Skype for Business components, I installed an internal Root CA on the DC, and have used that on both the public and private-facing certificates, which works fine for the lab. For the AD FS and AD Connect pieces, I set them up according to this previous blog post:

The Skype for Business On-Prem deployment is just a run-of-the-mill Standard Edition deployment, with three users enabled, nothing special:

As you can see, we are going with a Scooby Doo theme, here!

The Office 365 Environment

My tenant for this lab is using the SIP domain '', which is of course the same SIP domain that I used in my On-Prem lab. As you can see, to begin, I had only my 'admin' user, and no SSO or directory synchronization setup. I am not going to walk through those steps, as they are out of scope for this post, but you can find those steps in the blog post I linked to above. 

In the Azure AD portal, you can see that my domain is already verified, but SSO is not yet impletementd:

Next, in our Licenses section, we can see that I have a single valid Skype for Business Online (Plan 2) license, but that it is not yet assigned:

After I activated my domain for Directory Synchronization, we see this for Step 3:

Then, once I got directory synchronization in place with SSO, we can see that Scooby, Shaggy, and Thelma, as well as my AD FS service account, are now synced to the cloud, but their Status shows "Synced with Active Directory". Good times.

When I go back into Azure AD Portal, I can now see that my one verified domain is also configured for SSO:

Alright, for a last look at the Office 365 environment before we move on to actually connecting the Hybrid piece, we can see that there are still no Skype for Business Online users enabled in the Skype for Business Admin Center after our Directory Synchronization:

Prerequisites for Hybrid Skype for Business

Let's first discuss a few key requirements that must be in place before Hybrid can be successfully implemented.
  • Directory Synchronization. A mechanism for directory synchronization between your on-prem Active Directory and Azure AD instance is required. This does not have to be Azure AD Connect, but I would highly recommend it. Also, if SSO is required, you will need to have AD FS with the AD FS Web Proxy configured. As mentioned above, this is already in place in our lab environment.
  • On-Prem Topology. In order to set this up, you cannot have a mix-and-match topology. For a Skype for Business Server 2015 deployment, all servers must be running Skype for Business Server 2015. Likewise, if you have a Lync Server 2013 deployment, all servers must be running Lync Server 2013. 
  • Federation Requirements. The Federation configuration that is in place in your on-prem deployment must be mirrored in your Online environment. For example, if you have Open Federation set up on-Prem, but lock down federation to only certain domains Online, you will have to change one or the other to match the other exactly.
  • DNS. The SRV records for your SIP domain, both _sipfederationtls._tcp and _sip._tls, need to be configured to point to the on-prem Reverse Proxy, NOT the Office 365 addresses.
  • Other Considerations. There are also various requirements for ports and protocols that need to be allowed through your firewall. In addition, there are a few more things that you need to consider, but are not necessarily requirements, regarding user accounts and data, and policies and features. Read up on each of these pieces in detail here:

Configure Hybrid

Edit (12/4/2015): The next two sections describe how to configure hybrid and move users via Powershell cmdlets, so that you have a base to work off for putting scripts together and further automating your environment. For a great How-To on completing these tasks within the Skype for Business Control Panel, check out my other post: Configure Hybrid Skype for Business and Move Users (GUI).

Alright, with our environment fully prepped, and ready for connecting, let's jump into the meat of actually making the Hybrid connection, and then move on to moving users.

  1. So, first, we need to run the following cmdlet in our Skype for Business Management Shell on the on-prem Front End: Set-CSAccessEdgeConfiguration -AllowOutsideUsers 1 -AllowFederatedUsers 1 -UseDnsSrvRouting -EnablePartnerDiscovery $true. 
    As you can see, I first tried running it without -EnablePartnerDiscovery, as that is what was instructed in official documentation, but this parameter is apparently required when using -UseDnsSrvRouting. Note: You can also set the value as $false, but I chose $true to keep things simplified across both environments.
  2. Now, in the Federation and External Access tab within the Skype for Business Server Control Panel, go to the section titled SIP FEDERATED PROVIDERS, and remove the default entry that shows up for Skype for Business Online. You will then only have one default entry. 
  3. Back in the Skype for Business Management Shell, run the following cmdlet: New-CsHostingProvider -Identity SkypeforBusinessOnline -ProxyFqdn -"" -Enabled $true -EnabledSharedAddressSpace $true -HostsOCSUsers $true -VerificationLevel UseSourceVerification -IsLocal $false -AutodiscoverUrl The -EnabledSharedAddressSpace is important because this tells the on-prem deployment that we will be sharing the SIP domain that is in use with an Online tenant. 
  4. Going back to the Control Panel, we can see our new hosting provider if we refresh the screen: 
  5. Next, if we don't already have the Skype for Business Online connector module installed, you must obtain that and install in on your server. If you are using your Skype for Business Front End server to run these commands, however, this module should have been installed by default when installing Skype for Business Server 2015.
  6. Import the module (Import-Module SkypeOnlineConnector), and then set your credentials in the $cred variable ($cred = Get-Credential): 
  7. Next, run this cmdlet to set a new $CSSession variable: $CSSession = New-CsOnlineSession -Credential $cred; follow that cmdlet up with Import-PSSession $CSSession -AllowClobber
  8. Now, just like we configured our Hosting Provider to Share Address Space, we need to set this on our actual tenant in Office 365: Set-CsTenantFederationConfiguration -SharedSipAddressSpace $true

Alright, we are ready to move a user from our on-prem Skype for Business deployment to our Skype for Business Online tenant!

Move Users From On-Prem to Online

Alright, the documentation has us move on to running the cmdlet for move the user. However, if we do this before we set the Skype for Business Online (Plan 2) license on the user within Office 365, we will see the below error: 

The error tells us: "The user could not be moved because he or she has not been assigned a Skype for Business Online license. Users must be licensed before they can be moved to Skype for Business Online." Pretty straightforward, right!

So, we go to the user in Office 365 Admin Center, under the Active Users section, and selecting Scooby (you will notice we tried to move Scooby in the above screenshot) shows us that he has no license assigned:

So, we click on the Edit link next to the text "No license" under Assigned License, and in the Assign License box, we select "United States" in the Set user location dropdown box, and then check the box for Skype for Business Online (Plan 2). Click Save.

We can now see that the user Scooby has a Skype for Business Online (Plan 2) license assigned. 

However, if you attempt to run the Move-CsUser command again immediately, you may still see the same error, which doesn't make sense, right?! Well, you may need to wait 15 - 30 minutes after assigning this license, as the provisioning process is not exactly what you might call...quick.

SO, after waiting all this time, you can now run this again: Move-CsUser -Identity -Target -Credential $cred -HostedMigrationOverrideUrl

**IMPORTANT** In the above command, you first need to make sure you change -Identity to the user that you are attempting to move. Second, in order to get the proper HostedMigrationOverrideUrl, log into your Skype for Business Admin Center, and copy the URL up through "", and then append "/HostedMigration/hostedmigrationservice.svc" to the end of that URL. This may be different for different tenants.

You will then be prompted to Confirm. Type "y" and hit Enter. You should then see the below if it was successful:

Again, provisioning is involved at this point, so after you run Move-CsUser, you may need to wait a while before you see the below stats get updated in your Skype for Business Admin Center:

Then, if you click on the Users tab in the Skype for Business Admin Center, you should now see good ol' Scooby in there!

Let's go take a quick look back at the Active Users in our on-prem Skype for Business Control Panel. Doing so shows us that Scooby is no longer there, as he now lives in the Cloud!

Lastly, let's now log in to a Skype for Business Basic client with Scooby. BOOM! Not only did Scooby log in, but his contacts migrated with him (up to 250 contacts can be migrated). Also, Scooby's last status  of "Yipes!" is still up top. Nice!

Now, if you are wondering why Shaggy and Thelma's Presence shows as Updating, it is because of that private Root CA that I mentioned earlier. Since I am not using trusted public certificates in my lab, Skype for Business Online does not trust the certs, and thus the federation relationship for communication and presence does not work. For a lab, this is no big deal, but in Production, with publicly-issued SSL certificates, you will be able to communicate and see Presence.

Well, I hope this helps to clear up the process for some of you that ran into similar errors as I saw above, and I hope this lays a foundation for you to begin planning your Hybrid environments! As always, I welcome feedback, thoughts, and suggestions!

Stay techy, my friends!

Friday, October 23, 2015

#Skype4BRecap Episode 2 - Azure AD Domain Services, Office 365 E5, The Skype Show, and More!

Happy Friday, everyone! Time for another great roundup of all the latest and greatest info from within the Skype for Business community on #Skype4BRecap! Check out the YouTube video below, and if you are even mildly amused, please Subscribe to the YouTube channel! I'm also providing a couple quick links to things I mentioned in the video, as well as the Twitter profiles of people I called out.

Video Content Links

Honorable Mentions 

Ok, maybe "Honorable Mentions" is silly to say, but you get the point! Enjoy the show, and please leave your thoughts!


Stay techy, my friends!

Monday, October 19, 2015

#Skype4BRecap Commercial

Happy Monday, Campers!

I recorded a brief commercial for the Friday morning Podcast. BE WARNED - I tried using some intro music, and I think it is a bit loud, and needs some smoothing out before using it again. Just a heads up in case you were about to blair the video in an open office environment! Have a great week!

Stay techy, my friends!

Friday, October 16, 2015

Official Launch of My Weekly Podcast: #Skype4BRecap

#Skype4BRecap Is Live! (Sort of "Live")

Hey everyone! So, in addition to keeping up with the blog, I am launching a weekly podcast, simply named: #Skype4BRecap! Since #Skype4B is the popular hashtag on Twitter for all-things-Skype-for-Business, I decided to build on that with a single word that nicely summed up the premise of the podcast. 

So what is the premise?

Simply put, I want to have a fairly quick show, about 15 minutes ideally, but no longer than 30, that re-hashes through all the news and announcements in the Skype for Business and Microsoft UC community from the previous week. There is a LOT of information to consume on Twitter and LinkedIn, so I thought condensing it into some of the biggest highlights would be useful for a lot of us busy techs that just want to keep "in the know" while trying to keep our heads above water at work.

At any rate, this is definitely a work in progress, and I want to move toward a "live" format once I get my bandwidth constraints figured out. If you have helpful suggestions about how I could make the show more interesting, engaging, and relevant, I would LOVE your feedback. Be as brutal as you want, too; getting to the point allows for the fastest progress! At any rate, here it is. Looking forward to your feedback!

Stay techy, my friends!

Tuesday, October 13, 2015

Missing LWA (Skype for Business Web App) Directory After S4B Install

Hello members of the growing Skype for Business community! My team lead is out of the country on an extended sabbatical, so things have been a little busy on this end. Busy is good, of course, as it means business is chugging right along in our case, but it also means less time for putting all my thoughts and deployment adventures into blog posts. Today, however, I have carved out a moment to share a brief troubleshooting tip on an odd problem I ran into on recent Skype for Business Standard Edition deployment.

The Build

I had a very basic Skype for Business build recently. All operating systems were running Windows Server 2012 R2. It was comprised of:
  • A single Standard Edition Skype for Business Front End
  • A single Edge Server
  • A single Reverse Proxy (IIS with ARR)
  • No Dialin
  • No Enterprise Voice
  • No Persistent Chat
  • No Office Web Apps
As you can see, this was a VERY straightforward build.

The Problem

Once the build was completed, however, and testing began, we ran into an issue in which a user tried to join a meeting via an email invite, and they clicked on the option to Join Using Skype for Business Web App instead, but ran into an error upon doing so.

The error stated: "Server Error in '/' Application. The resource cannot be found. Description: HTTP 404. The resource you are looking for..." 

Needless to say, I found this odd, especially on a fresh build. Oh well, time to dig in.

The Troubleshooting

Alright, so as with any error, you should start by actually reading the error, and trying to understand what it might be telling you. In our case, we are specifically being told that there is no resource at: '/lwa/WebPages/LwaClient.aspx', which is the client page for those using the Skype for Business Web App as their meeting client. 

It can be very tempting to skip over the obvious implications of an error and jump straight into the complexities, but with how often I have found the "simple" or "obvious" things to be the culprit, I think it is always best to start with them. So, before we get started with verifying DNS, testing our networking config, and pouring through Reverse Proxy configs, we need to go to our Front End, open up the IIS Manager, and verify that the LWA directory is present.

  1. Start -> Administrative Tools -> Internet Information Services (IIS) Manager
  2. Within the IIS Manager, expand the server name node, then expand Sites, and finally expand the site named Skype for Business Server External Web Site. This is the site we should be hitting when joining a meeting from outside the environment.
  3. Verify the 'lwa' directory is present, and if is, verify that the 'WebPages' directory is present beneath it, and finally that the LwaClient.aspx page is listed in the 'WebPages' directory while using "Content View" in the middle pane.
In my case, the 'lwa' directory was completely absent; simply not there! This was a fresh install, mind you, without errors. So, now I know why we are seeing that error - the directory that is being attempted does not exist. 

What next? Now we need to go to the installed Programs and Features and verify that the Skype for Business Server 2015, Skype for Business Web Application shows as installed.

  1. Start -> Control Panel -> Programs -> Uninstall a program.
  2. Scroll down and verify the Skype for Business Server 2015, Skype for Business Web Application is installed.
Ok, so, in my case, it is installed. That is odd. It shows as installed, BUT, in my case, the actual directory is not present in the IIS web site. This sounds to be a bit like something went wrong during the install, and this particular component did not fully install. SO, what do we do?

The Solution

Ok, in order to reinstall this component all over again, without messing with the rest of our config, we will perform the below steps and hope that it works:

  1. Navigate to your Skype for Business Server 2015 installation media, and then to this directory within it: Setup -> amd64 -> Setup.
  2. Run the EnterpriseWebApp.msi.
  3. On the Welcome screen, click Next
  4. As you can see, our only option now is to Remove the Web App, since it detects that it is already installed. 
  5. Once the removal is finished, we can close this wizard. Next we will navigate to C:\Program Files\Skype for Business Server 2015\Deployment\, and run the Bootstrapper.exe. This will go through and detect that we should have the Web App, but that it is not installed, and it will re-install it from scratch. In my case, it completed without errors. 
Now, let's go back and look in IIS Manager for the 'lwa' directory to see if it is present:

BOOM!!! There it was! As you can see, I drilled down into the WebPages directory and verified the presence of the LwaClient.aspx file. The last thing left to do was to try browsing: Lo and behold, no more error! Of course, your experience at this point could be different, if there are any other configuration problems at the previously mentioned DNS, networking , or Reverse Proxy levels. And, this experience should not be the standard; that directory is not normally missing. Something was just a bit funky this time.

Well, in case any of you run into the same thing in the future, I hope these steps help you get to the bottom of it!

Stay techy, my friends!