Showing posts with label Skype for Business Troubleshooting. Show all posts
Showing posts with label Skype for Business Troubleshooting. Show all posts

Tuesday, October 4, 2016

RESOLVED: Transfer External Call From Polycom VVX Fails in CCE Environment

My Skype for Business Cloud Connector Edition (CCE) adventures appear to be far from over, and that is a good thing in my book. While the thoughts and opinions on CCE and its purpose have been varied, I personally see a lot of geographically-dispersed companies digging right on in, as they are wanting to become full-Office 365 adopters, but must account for the fact that PSTN Calling is still quite limited in its availability across the globe.

As this adventure continues, however, there is obvious product maturity that is taking place, not just on Microsoft's part, but also on the side of the Vendors whose products will integrate with the environment. In this brief post I want to call out a very specific scenario that some Polycom VVX users might find themselves in when they are kicking the tires on a brand new CCE environment. (Yes, this was a painful troubleshooting experience)

The Scenario


Note: This has only been tested on Polycom VVX 500 and 600s, though it may also pertain to the lower-end models, or other Polycom handset series.

Imagine a situation in which you have a Skype for Business user in your CCE environment, let's call them Jim Bob, and they have not adopted the "No More Phones" mentality yet. They have been using handsets for years, and they simply LOVE their Polycom VVX 600. After all, it is a pretty slick handset! At any rate, your CCE environment is set up properly, everything is working, and this user has been otherwise happy as a clam (I want to know who the psycho is that allegedly determined that clams are even generally happy creatures. Seriously, think about their existence; how on earth can that possibly...I digress).

One day, some one external to the company calls Jim Bob over the PSTN, and this call gets routed through CCE and to Office 365. At this point, Cloud PBX knows which endpoints Jim Bob is active on, and dials him on those. This is when his Polycom VVX 600 rings. Jim Bob cheerfully answers the phone, and after a few minutes of stimulating conversation, he realizes that the call actually needs to be forwarded to a colleague in a different department. No problem; Jim will just transfer the call!

The Problem


As Jim moves to transfer the call via the Call Control mechanisms on his VVX 600, he dials the number of his colleague, and goes to transfer the call. Unfortunately, though, the transfer does not go through, and Jim Bob now needs to figure out what to do with this caller! Please note, Jim Bob already confirmed that he was able to transfer a call from another internal user in his Skype for Business Online tenant within the same CCE deployment, so he was completely stumped about why he could not transfer a call from an external user.

The below diagram shows how the initial call came in, how it was routed to Jim Bob, and then how it would have traversed before being successfully transferred to his colleague. It also shows a big red "X" where the call ends up failing (if you do your homework and trace all the logs through CLS Logger on the CCE VMs):


The Resolution

 
Now, hopefully you found this blog before doing a whole lot of troubleshooting and digging into the logs, because if you did, you will realize that the issue is fixed by something as simple as firmware upgrade. You see Jim Bob's company tries to keep their phones updated with the latest firmware as much as they can, but there was a new firmware version from Polycom for the VVX phones, 5.4.5, that did not get released until October 3, 2016. While Jim Bob was experiencing the issue, this version was still and Beta and not publicly available, making the Call Transfer problem a difficult one to work around.

Version 5.4.5 is certified for Skype for Business, and will most definitely fix this issue if you have come across it. In addition to this issue, there are a good couple of pages of bugs that are addressed in this version. If you have a moment after updating your phone, check out the Release Notes; there is a LOT going on there.

Finally, here is a link to the latest Polycom UC Software Releases: http://support.polycom.com/PolycomService/support/us/support/voice/polycom_uc/polycom_uc_software_release.html  Please note, you do NOT want to go for 5.5.0; stick with 5.4.5, as it is actually certified for Skype for Business.

Well, I hope this has helped at least one or two of you on the CCE pioneering front! Till next time...

Stay Techy, My Friends!




Friday, September 16, 2016

Skype for Business Cloud Connector Edition Fails on BaseVM Windows Update

Well, my adventures in Cloud Connector Edition (CCE) just keep on unfolding, and I must say, learning on a curve can be tricky, as the technology is so new, and things are changing between versions so much. I came across one tricky situation with a very specific fix, and I figured this may help some of you out if your are not as geeky on the Networking side as you are on the Skype for Business side.

The Issue


This problem is not specific to any version of CCE. Let's say you have made it as far as prepping your Hyper-V host with all the appropriate settings. You have downloaded CCE, you have downloaded the S4B bits, you have uploaded the Windows OS ISO that you will be using, and properly filled out your entire CloudConnector.ini file (along with all the other required preparation steps). Finally, you are ready to convert that ISO file into a BaseVM that will be used to create your final 4 VMs in the CCE configuration. You run the following cmdlet:


Convert-CcIsoToVhdx -IsoFilePath <Windows ISO File Path, including file name>

A lot happens now. The original ISO is extracted, stuff is happening in the background, then a new VM gets built and the OS is installed. Of course, the configuration information is pulled from your CloudConnector.ini file, so make sure you have that properly filled out ahead of time. During the original OS install, the PowerShell window does not show you much at all, and doesn't update you with the progress until it is finished. If you are like me, and don't have a lot of patience, or just like to know what is going on, pop open the Hyper-V Manager, click on the BaseVM name (it is named some horrible GUID-looking name), and click Connect from the VM options on the right side. This will let you see the VM as the OS gets installed and the machine restarts over and over again - it is more to look at that PowerShell where nothing seems to be happening.

Finally, in your Powershell window, after the OS is fully installed and the machine has gotten through some initial configuration, you see that it is attempting to download and install Windows Updates. But it fails! NOOOOO!!!! It says it will retry again after 30 seconds...



No Bueno...

The Resolution


So, at this point you are racking your brain. You did everything to prep that you needed to. You cleared all the IPs and Network segments with your Network guy. All the DNS settings are accessible, so you know it is not DNS. The Networking guy even did you a favor and setup the firewall rules correctly on the first try (sorry Networking guys, had to throw that friendly zinger in there). So why is the machine still not able to connect to the internet, resulting in the above cmdlet ultimately failing on Windows Updates?

Well, if your situation was like mine, it was because you did not realize VLAN Tagging was at play! Yep, all your IPs and network information is correct, but the individual vNICs on each VM have to set up with the properly VLAN ID. Luckily, this can be done with the machine still running and doing its thing. With the VM still highlighted in the Hyper-V Manager, click on Settings under the VM options, and then click on the name of the Corpnet NIC as you have set it up on the VMs properties. Once there, you will need to check the box next to Enable virtual LAN identification, and then enter the proper VLAN ID in the box below it. Don't forget to hit Apply before closing the window!




Wasn't that nice? I even added numbers to show you the order to set those VLAN IDs! ;-) 


Once you do this, the VM will almost instantly pick up its connection, and if you are still on the WIndows Update step, you should see updates detected:










And that's that! VLAN tagging is one of those things that is not really covered in the CCE documentation, at least that I have seen, so be aware that you will have to figure it in if it is in use in your environment, or your clients' environments. Please remember, you will need to set it on ALL VMs, not just the BaseVM. On that Edge VM, though, you will have two NICs to set it on, and they should likely each be on different VLANs, thus different tags for each NIC.

Hope this helps at least one or two of you fumbling through a CCE deployment out there!

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



Tuesday, May 12, 2015

Skype for Business Install on Windows Server 2012 R2: Don't forget KB2982006

Hello all! It's been a busy start to the week, but I wanted to take a quick moment to share a tidbit of knowledge I have run acrosse while installing Skype for Business. Here is the scenario:


  • Setting up a small lab with Rackspace Public Cloud VMs.
  • Deploying a Standard Edition install of Skype for Business
  • Server OS is Windows Server 2012 R2
  • Server has been added to AD Domain
  • All Windows & Security updates have been installed
  • All Prerequisite Roles & Features have been installed
  • Administrative Tools were installed
  • AD  was prepared by extending Schema, preparing Forest, and preparing Domain
  • Prepare First Standard Edition Server step was successfully run
  • On the Install or Update Skype for Business Server System step, Step 1 completed successfully

Then, the problem: Step 2 failed with the error stating that not all prerequisites had been met, and it cites the KB article 2982006. This update was not picked up my the local OS when checking for updates, apparently, but is required by Skype for Business Server for install.

Now, to obtain the update, you can start the download process by clicking on the "Hotfix  Download Available" button here: https://support.microsoft.com/en-us/kb/2982006. Once you do this, though, it is not a direct download. You are prompted to first select the proper download, which should be the x64 version of the download, and then you must enter your email address. Within a few minutes, you should receive an email from Microsoft with a link for a direct download of the hotfix. This email also includes a whole lot of warnings about backing up your environment and disclaimer-like information. In my case, this is for a basic lab, so I pretty much ignored all the fine print, and just installed the hotfix. It DID NOT require a reboot.

Once you have installed the hotfix, you should be able to re-run Step 2 successfully, and on you go to Skype for Business Server 2015 testing and fun!  For any of you getting briefly stuck on this, or just planning for your environment in advance, please simply take note that KB2982006 is a prerequisite that does not get downloaded in the normal updates.

Thanks for reading!

Stay techy, my friends!