#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!

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!

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: https://skypeweb.domain.com/lwa/WebPages/LwaClient.aspx. 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!

Persistent Chat: Challenges vs. Benefits

No, we are not discussing that office worker that tends to yack your ear off like Kelly Kapoor on The Office. That would be Incessant Chat. We are talking about Persistent Chat!

This post is a very brief one. We are simply going over some pros and cons, or rather challenges and benefits, to implementing Persistent Chat in your Lync Server 2013 or Skype for Business Server 2015 environment. For those of that need a brief jogging of the memory, Persistent Chat is what was previously known as Group Chat in Lync 2010. It enables chat "rooms" where the conversation persists independent of the participants. For instance, User A can come and go from the chat room, but the conversation will  go on without that user, and the previous conversation involving User A will remain in the room regardless of their involvement. Yes, it is very cool indeed.

Challenges

So, what are the challenges associated with implementing Persistent Chat? Well, there are some things that are simply good things to keep in mind, and others that are indeed challenges. For this sake of this list, though, I am going to list them all together into one bullet-ed list.

• In an Enterprise environment, Persistent Chat cannot be collocated on the Front End Server. This means that if you are planning for Persistent Chat, you will need to plan in additional servers. Persistent Chat (PC) also requires a backend database. This database can live on the same SQL instance as your other roles, so you don't necessarily need another server for this role, but you should make sure your SQL server has enough computing power. The only case where you can collocate the PC role with the Front End is in a single-server Standard Edition build, in which case the PC SQL backend is simply another database in the existing SQL Express instance on the Standard Edition server. Of course Microsoft recommends that such an environment only be used for Demo and POC purposes, but anyone in the industry is well aware that these environments are used in production for MANY smaller businesses. If you are one of those smaller businesses, make sure you have enough RAM and CPU power on that server!
• The ability to partake in PC as an end user depends upon group and room membership. This membership is managed on the Room  level by the Managers of the room. In order to create a room, as user has to be added to the Creators group for a "Category", which is setup in the Skype for Business Control Panel. To manage these Control Panel settings, and  to create Categories and assign Creators, a user needs to be a member of the RBAC role Persistent Chat Administrator. Once a room is created, managers must be assigned per room, and those managers can then add Members. As you can see, there is quite a hierarchy that must be accounted for when deciding how use of Persistent Chat will be managed and administered within your organization.Will your chat rooms just be "open"? Will users need to submit tickets to a central Help Desk team to gain access to any rooms? Will more granular controls be required?
• A separate web interface is required to manage individual rooms, Managers, and Members. While this interface is fairly simple and  straightforward web portal that is managed through the Skype for Business client, it is yet another interface to be aware of, and to learn. This is not overly burdensome, but may require a bit of end-user training for those who will be "Managers".

Benefits

Alright, so, the challenges weren't too bad, were they? Nah. Now for the benefits. I am sure many of you have already started compiling into your own mental list.

• Many teams may have slightly different use cases for PC, but despite these differences, most of these teams share the commonality that having a central chat room for their  team  to work out of in real-time is a key component to enhancing internal communication and increasing efficiency. Having the leadership of a time buy into the added benefit of this tool will not just deliver this enhanced productivity - it will also increase end-user adoption of the Skype for Business product as a whole.
• Many teams run a 24-7 shop, meaning they have at least 3 shifts working around the clock, and such a structure usually include some sort of shift hand-off. Imagine how seamless and more complete this hand-off would be if all teammates were using a Persistent Chat room throughout their shift, recording all the happenings (good and bad) of that particular shift. Suddenly, Johnny ThirdShift won't be caught off-gaurd when an unhappy customer calls in to get the status of a down server when Suzy SecondShift forgot to mention that at turnover time.
• Enhanced productivity means less time spent trying to track down various bits of communication. If less time is spent tracking things down, or looking for an available tech to escalate to ("Hey, anybody in this room that can help me out"), workers can be more productive. This eventually translates to cost savings, which in turn means greater revenue.
• There are also "Auditorium" rooms. These rooms have a Presenter, who can essentially broadcast messages to a room with many members. While the members are not able to participate in conversation, they can closely follow the messages broadcast by the Presenter. This is especially useful in situations where there is a major outage, and several teams are trying to coordinate and work together to track the status and keep up with the latest developments of the issue. 

As you can see, Persistent Chat is not just as simple as flipping a switch on in your Control Panel, but depending on your company's needs, it may be well worth it to invest the extra planning into making Persistent Chat a part of your company's collaboration strategy. I hope this proved helpful for those of you currently weighing this decision. For others that have implemented it, and found additional Challenges or Benefits than what I have listed above, we would love to hear about your experiences! Drop a comment below!

Stay techy, my friends!

Setting Up Cloud PBX (Skype Voice Preview) Voicemail in Skype for Business Online

And another video...

Hey guys! So, I had a lot of fun doing the last video, short and simple as it was, so I wanted to do my next post in the Podcast format as well. This time, however, I used Google Hangouts On Air. I know, I know, I will look into Skype Meeting Broadcast one of these days, but for now, streaming the video on Google+ and then having it automatically uploaded to YouTube and ready to go was just a convenient way to go for a novice like myself. Plus, I really liked their "Showcase" feature for sharing the sites that I was working from!

Following up on Cloud PBX with PSTN Calling

So, following up my post on Configuring Cloud PBX with PSTN Calling, this video is a how-to on how to enable a Skype Voice user for Voicemail using Exchange Online Unified Messaging (UM). While I call these out in the video, there are a couple caveats that I want you to be aware of:

Caveats

• Exchange UM in Office 365 requires at least Exchange Online Plan 2
• All of this functionality is still in PREVIEW, and unless you are in the Preview program (apply at https://www.skypepreview.com), you will not have access to this functionality until it is GA.
• Step 6 of the given Technet article actually includes 2 cmdlets all run together, so watch out for that.
• Step 6 also has a policy named incorrectly, and per their example, should actually read "USTenDigits Default Policy" (you will see what I mean in the video).

At any rate, while this video is 5 minutes longer than my intended 15 minute target, it is still a good watch for seeing how to work through these steps. Please don't hesitate to throw some feedback my way!

Stay techy, my friends!

Deciding Where to Place Users in a Hybrid Skype for Business Environment

Trying something new...

Hello everyone! Things have been a bit crazy, schedule-wise, but I found some time to put something together today. Actually, I am changing things up a bit, and trying something new. Today, I tested out web-casting, a bit, and I have to say, I kind of like it!

It is a bit rough around the edges since it is a first blog video post, but I am hoping to incorporate these more and more, with deeper content and more substance. Since today was the maiden voyage for a video post, though, I went with something simple. Therefore, this is a brief walk-through on the feature comparison of Skype for Business Online Plan 1, Plan 2, and Skype for Business Server 2015 (On-Prem). If you are planning out a Hybrid Skype for Business environment, or just need to brush up on the differences in features/pricing of the different plans, this will be helpful!

Again, this was a very simple and basic recording, with very basic content, but I promise, these will get more in-depth and interesting as I incorporate them into the blog more regularly!

Stay techy, my friends!

Exploring Azure AD Connect - Part 3: Configuring User and Password Writeback with Azure AD Premium

Other posts in this series:

• Exploring Azure AD Connect - Part 1: Express Installation
• Exploring Azure AD Connect - Part 2: Configuring SSO with AD FS

Exploring Azure AD Connect - Part 3: Azure AD Premium Features

Well, this series has taken a while to wrap up! What can I say? When it rains, it pours. So far, we have taken a look at setting up Azure AD Connect for synchronization in a Hybrid environment using Express Installation, and we followed that up with a look at setting up synchronization and SSO with AD FS, which of course was a bit more complicated. Now we move on to a couple of the advanced synchronization features that require Azure AD Premium licensing.

First, let's list out a few of the awesome features that can be achieved through Azure AD Premium licensing and Azure AD Connect:

• Multi-factor Authentication
• Self-Service Password Reset for users with Write-back to On-Prem AD
• Password Write-back
• User Write-back (Note: This feature was in Preview, but is not available as an option currently. I have been instructed by an Azure AD Product Manager to stay tuned for GA.)
• Group Write-back is also possible, but does not require Azure AD Premium licensing. Groups are written back as Exchange Distribution Lists, and have other Exchange requirements
• Device Write-back

As you can see, there are some very cool perks with using Azure AD Premium licensing. Check out this link for a more in-depth comparison of the feature sets between Azure AD licenses, and price comparison: http://azure.microsoft.com/en-us/pricing/details/active-directory/.

Getting Started - Azure AD Premium Trial

Obviously, you can go out and just purchase Premium licensing if you want to, but for the purposes of this tutorial, I was just testing and demonstrating, so I took advantage of the 30 day trial that was available.

To do this, you can log into your Admin Portal for Office 365, and then towards the bottom of the left-hand navigation menu, under the Admin menu item, click on Azure AD. This will open up the Azure AD portal. From here, you will click on the ACTIVE DIRECTORY tab on the left side of the screen, and then click on your AD instance name. In my case, this was "The MS UC Guy". You will now see the below screen, and as you can see, our Trial awaits with the TRY AZURE ACTIVE DIRECTORY PREMIUM NOW link button at the top of the screen. Click on it.

You will then be prompted to agree to the terms of the Azure AD Premium trial in the Activate Azure AD Premium trial box. Click the check mark button at the bottom-right of the box.

After accepting the terms, you are brought back to the main Active Directory screen, and you can see that your Premium trial is being activated.

Once your Premium licensing has been activated, it is time to go to your server that has been setup to run Azure AD Connect. Let's take a quick moment to look at what our On-Prem environment looks like.

On-Prem Lab Environment

My "On-Prem" environment is the same virtual environment in Rackspace's Public Cloud that I used in the previous posts in this series, minus a couple servers. All servers in this environment are running Windows Server 2012 R2, and are fully patched. All are joined to the S4BLAB.org Active Directory domain. The environment consists of:

• 1 Active Directory Domain Controller
• 1 small server for installing Azure AD Connect
• 1 small client VM, joined to the on-prem Active Directory domain

Office 365 Environment

I am using the same Office 365 tenant that I used in my previous posts, using only Skype for Business Online Plan 2 licensing, and now the Azure AD Premium licensing. I cleaned up the environment by uninstalling Azure AD Connect completely from the on-prem server, deactivating synchronization in the Office 365 portal (this can take up to 72 hours to take effect), and then deleting all users that had synced from the on-prem Active Directory from the last post.

NOTE: You must also delete the users in the Deleted Users section of your Office 365 portal as well, because if you have any same-named users from a previous lab/demo, you can run into issues where password writeback won't work due to duplicate entries. You cannot purge the Deleted Users from the Office 365 Admin portal; instead, reference this article for how to connect remotely via Azure AD Powershell module, and purging those users: http://jaapwesselius.com/2014/12/10/purge-deleted-users-in-office-365/.

Per the last post, the custom domain "s4blab.org" is already setup in the portal, with all necessary DNS records having been created. Lastly, before getting stared, I navigated to the Active Directory synchronization line at the top of the Active Users page in the Office 365 admin portal, and clicked the Manage link button. From there, I activated AD synchronization by click the Activate button, as seen below:

Configuring Azure AD Connect for User & Password Write-back

Alright, now it is time to get into how to configure Azure AD Connect on our on-prem server. The advanced features that we will be demonstrating are User Write-Back, and Password-Write-Back, because how cool is it that we can manage our users in the Cloud, and have the changes synced back to our on-prem AD?! Let's dig in:

• Once you have downloaded the Azure AD Connect tool from Microsoft's Download Center, run the AzureADConnect.msi file. You will see the below Welcome screen. Check the box next to "I agree to the license terms and privacy notice.", and then click the big green Continue button. 
  
• On the Express Settings screen, click the Customize button at the bottom.
• On the Install required components screen, leave all the boxes un-checked (unless any of those specific Optional configurations apply to you for some reason), and click Install. You will then see the progress bar as the required components are installed. 
  
• The User sign-in screen comes up and gives you three options. This time, we will leave the default option selected, Password Synchronization, and then click Next. 
  
• The next screen is the Connect to Azure AD screen. Input credentials from your Office 365 subscription that have the Global Administrator role assigned (preference here is to use an @domain.onmicrosoft.com account, and NOT a user with the same domain name that you are about to sync with), and click Next. You will see your Microsoft Online credentials be validated, and information from your Office 365 environment verified. 
  
• Next, you will add your on-prem AD domain on the Connect your directories screen. You should already see the Forest field populated. Add your credentials, and then click the Add Directory button. The credentials get verified, and then you can see the directory added. Click Next. 
  
• Leave the defaults selected on the Uniquely identifying your users screen, and click Next. 
  
• On the Filter users and devices screen, you can either enter a Distinguished Name or name of a group in AD, and then click Resolve, or you can Synchronize all users and devices. We are leaving the defaults since this is just a demo environment, and clicking Next. 
  
• The Optional Features screen is where we make our important selections for this post. As you can see, the Password sync box is selected and grayed out because of our earlier selections in the wizard. We will now check both the Password writeback and User writeback boxes (Note, as of the time of this post, User Writeback still shows as being in Preview). Click Next. 
  
• Next we come to the Writeback screen, where we need to traverse the on-prem AD tree structure to select the target Organizational Unit (OU) for User Writeback. Here we have created a special OU for this: The Users OU underneath the Awesome OU, of course! Once you select the desired OU, click Next. 

  

  
  

• Finally, we have the Ready to configure screen. This gives us a chance to review our previous selections. We are going to leave the Start the synchronization process as soon as the configuration completes box checked, and click Install. 
  
• After clicking Install, we see the wizard make several configuration changes before finally showing us the below Configuration complete screen. Click Exit. 
  

Now, if I had been thinking, I would have had users created in the first place, so that we could see that the initial synchronization replicated those users to Office 365. However, I didn't do that, so I went ahead and created Josh, Jack, and Jill in our Awesome -> Users OU: 

Now, back on our Azure AD Connect server, I click on the Start menu, and find the Azure AD Connect Synchronization Service, and click on it:

Now we see the below tool:

We are going to click on the Actions menu, and then select Run from the drop-down menu:

A pop-up box opens up, and we need to select Full Synchronization. Then click OK.

After this synchronization runs, we should be able to see it's successful status in the Service tool that is open. Go ahead and close this tool now, and let's go back to the Active Users screen in our Office 365 Admin portal. Voila! Look at those users!

User Writeback

(Note: This feature was in Preview, but is not available as an option currently. I have been instructed by an Azure AD Product Manager to stay tuned for GA.)

Ok, so, now that our users have synced from our on-prem AD to Azure AD, let's flip that switch. We create a new user called "Cloud Man", and as you can see below, his Status shows as "In Cloud".

NOTE: when going through the user creation wizard in Office 365, I selected the Azure AD Premium license. Without this, the user would not be able to sync back to the on-prem AD. Alright, time to go check out our on-prem AD and see if this user replicated. If you do not see them in AD yet, you may have to wait for a while before the next synchronization pass. However, after waiting a while, I was able to see Cloud Man in the proper OU (as defined in the wizard earlier. User Writeback is a success! 

Password Writeback

Alright, back in our Office 365 Admin portal, we now need to go to one of the users that we synced from our local Active Directory, check the box to the left of their name, and then click the Edit button under the Assigned license section on the right.

In the Assign license overlay, select the user's country from the drop-down list, check the box beside the desired license (in this case we want Azure Active Directory Premium for Password Writeback functionality), and then click Save. 

Now, with Jack's user object still selected, click on the Reset Password link button in the user actions on the right side of the screen. 

The resulting overlay allows us to specify an email address that the password will be sent to, and we can also choose to require the user to reset their password at next logon. We have left  this unchecked for this demo. Click Reset.

Once the reset finishes, you should see this reported back as a success, and you will be given the password. Make note of this password, so that we can try logging in with Jack on our test client VM. Click Close. 

Now, to prepare our client VM, we needed to allow Jack to logon to the server by adding him to the Remote Desktop Users group on the server, but this is not  necessary if you are logging onto a client OS in your AD environment, rather than a VM with a server OS.

Lo and behold, once I logged in with a new password, I was actually prompted to change my password (the one issued from Azure AD was a temporary password since it was done by the administrator, and not by the user themselves via Self-Service Password Reset). Amazing!

In Summary....

In summary, Azure AD Premium licensing is freakin' awesome! The new feature set that opens up to Office 365 hybrid users is incredible, and I have just scratched the surface (barely!). Don't take my word for it, though. Dig in, and open up a new world of hybrid goodness to your organization!

Stay techy, my friends!