In my last post (Upgrading to Skype for Business Server 2015) I showed how easy it was to take a Standard Edition Lync 2013 Front-End and upgrade it in-place to Skype for Business Server 2015.

Inspired by how simple it turned out to be I thought I’d flip my Edge as well – only to be hit by a puzzling bug…

The process is essentially the same, and captured here in picture form for you.

Don’t Skimp on the Pre-Req’s

As with the Front-End, the Edge upgrade process was able to download and install missing pre-requisites, so that will cover you if you’re not been all that thorough in your attention to the pre-req’s. Indeed, if you’re running Server 2012 “R1” you can probably get by without actually adding any by hand.

Having said that, a lot of customers don’t give their Edge servers access to the Internet, so for those of you in this category, skimping on the pre-req’s isn’t going to get you far.

• Y0av’s pre-req’s
• Pre-req’s on TechNet

The Build

By now I already had my new “Apps” server with Topology Builder installed on it, as well as the updated Front-End server to which I also added the Admin Tools.

“Flip” the Edge in the Topology

1. Run the Skype for Business Topology Builder
2. Download the latest Topology
3. Navigate to our Edge pool
4. Right-click and select “Upgrade to Skype for Business Server 2015…”:
   
5. OK the pop-up:
   
6. Publish! Remediate if required, otherwise you’re safe to proceed:
   
7. The “to-do” list is looking a bit generic. I’m guessing this will be tweaked in future updates to remove the irrelevant references to normalisation rules – irrelevant in this case as that doesn’t have anything to do with the Edge server:
   
8. Wait for the changes to replicate through the topology before continuing.

Upgrade the Server

1. From another server in the deployment, check that the changes have replicated to the Edge (“Get-csMana<Tab><Tab>”)
2. Stop the services on the Edge:
   
3. Map to or otherwise mount the Skype for Business ISO and run Setup.EXE therein
4. VC++ 2013:
   
5. Check for Updates:
   
6. No Updates found, move on:
   
7. Reboot prompt:
   
8. Installing Core Components:
   
9. Completed successfully:
   
10. Bring ‘er up:
    
11. Start-CsWindowsService:
    
12. Test Connectivity (https://testconnectivity.microsoft.com/):
    
13. Done! Kinda…

What’s With the STOPPED FabricHostSvc?

It concerned me a little to find that in the image for Step 11 the new “FabricHostSvc” wasn’t running. The Connectivity Test wasn’t calling out any problems and there’s nothing in the Event Logs, but here I am with a new service (that’s set to Manual BTW) that’s not running. (In contrast, it exists and is running on my Front-End, and also set to Manual).

Strangely if you “Start-CsWindowsService”, it appears that this one isn’t in the list of services that it starts, as evidenced by the log of the command. You see the seven other services, but not this one:

“Start-CsWindowsService FabricHostSvc” reports no error, but no apparent sign in the log that it tried to do anything anyway:

With nothing to find on the Internet about it I thought i would waste any more time stuffing about – but alas, a reboot didn’t bring it up. ;-)

Neither did re-running the Deployment Wizard after re-enabling the Windows Firewall (one of the known gotchas on the UC & Stuff Blog).

With a few SCHANNEL errors in the logs and some known issues with Edge replication I thought I’d try the Registry key fix, but that didn’t do it either and was reverted.

In the end, manually starting it from services.msc brings it up, but it’s not sticky (being Manual) and won’t come up after your next reboot.

I’m wondering if it’s reliant on some other pre-req that I’ve not yet met – like that my CMS is still on Lync 2013. Or just a bug. Or a deployment step I’ve missed? Time will tell, but if you’ve found yourself here pondering this same question, at least for the moment take some comfort that you’re not alone.

Postscript

1st June: It looks like the fix is just changing the FabricHostSvc to “Automatic”. It starts and survives reboots OK. Is this something that’s broken in the deployment process that’s perhaps specific to Server 2012 “R1”? (A colleague reports he didn’t have this issue on his R2 in-place upgrade).
22nd June: There’s no apparent change to the Fabric service after adding the June 2015 update to the SfB server. “Stop-CsWindowsService FabricHostSvc” will take it down, but “Start-CsWindowsService FabricHostSvc” still won’t try to bring it up.
10th June 2016: There’s no benefit to starting the FabricHostSvc service on your Edge. Its presence on the Edge server appears to be a red herring. If you run the service it’s only going to fill the HDD with logs (C:\ProgramData\Windows Fabric\Log\Traces). Leave it set to Manual and Stopped.

– Greig.