Friday, July 19, 2013

Short Takes - A Look at the Previous Week's Lync Blog Posts

Here are some links to posts made this week by other Lync bloggers that you may find interesting:

Enjoy the weekend everyone!

Thursday, July 11, 2013

July 2013 Update for Lync 2013 Icon Weirdness

So, along with probably a bazillion other people, I installed the July 2013 client update for Lync 2013 (CU2) to see all the new awesomeness around Q & A, picture cut'n'paste and other assorted goodies as shown on several other blogs like Richard Brynteson from

While the new features worked great, I couldn't help but notice that the new icons were either completely missing or showed incorrectly, as in the below screenshots:
Note the missing icon for "Q & A"

Note the weird icon on the right where the meeting icon should be
After removing and reinstalling both the Lync 2013 client update and even Lync 2013 itself, the situation never changed. After posting a question in the Lync MVP mailing list, Dave Howe from MS came back asking about the version numbers of MSO.DLL and MSORES.DLL.  Apparently, those DLLs contain the Lync 2013 icons, so if they're the incorrect version, then you'll see issues.  In my Office 2013 x32 installations, those DLLs were found in C:\Program Files (x86)\Common Files\microsoft shared\OFFICE15.

Keeping an eye on those files, I reinstalled the Lync 2013 CU2 update once again.  However, they never changed from their default value.  Going on what I heard from others, I went to Windows Update to install the latest updates for Office 2013.  Several were found on my first pass.  I noticed that MSORES.DLL seemed to be updated by KB2817489 to 15.0.4517.1003 , but MSO.DLL was untouched.  With that update, the wonky icon showed up correctly, but the icons for "Q & A" and "No Meeting IM" were still missing.

Re-running Windows Update again installed a few more updates, notably KB2817491. This updated MSO.DLL to 15.0.4517.1005, at which point all the icons showed up normally.

If you read the description for KB2817489, it says the update should fix the Q & A and ME icons (whatever that is). The description page for KB2817491 is currently not available, so I can't tell what it does. The patch is apparently for Office 2013 x64, but I was running x32, and it updated the x32 version of MSO.DLL.  There may be some documentation fixing to do.

So, if you install Lync 2013 CU2, make sure you run Windows Update not just once, but TWICE to ensure you get all the updates necessary for Lync 2013 to work properly.

What did I learn from all this? MSORES.DLL stores the icons for the main Lync page, while MSO.DLL stores other icons.  Also, not all Lync file updates come in one nice package, as you would hope.

On a final note, I have to say that I am not a fan of this process.  I understand that Lync 2013 is now part of Office 2013, but is it too much to ask that if an update is put out for Lync 2013, that update should include ALL the required DLL updates?  I shouldn't have to install multiple seemingly unrelated updates just to get a fully functional Lync 2013 client.  This took up a good half a day of troubleshooting that would have been better spent doing other things.

By the way, I want to give special thanks to Dave Howe from Microsoft. If it weren't for him asking about MSO/MSORES, it would have taken a lot longer to figure out the solution.

Monday, July 8, 2013

Errors After Installing Office Web App Server on Non-Standard Drive

I haven't come across anything noting this, but beware of installing Office Web App Server 2013 on anything other than the standard C:\Program Files\Microsoft Office Web Apps on Windows Server 2012.  I installed OWA on the D: drive to keep with a corporate policy for all installed applications. The installation itself went without a hitch, and I was even able to create a new Office Web App farm.  However, when I tried to run any other OWA Powershell command (like Get-OfficeWebAppFarm), I would get the following error:
Get-OfficeWebAppsFarm : The content type text/html; charset=utf-8 of the response message does not match the content type of the binding (application/soap+msbin1). If using a custom encoder, be sure that the IsContentTypeSupported method is implemented properly. The first 1024 bytes of the response were: '<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "">
<html xmlns="">
<title>IIS 8.0 Detailed Error - 500.19 - Internal Server Error</title>
<style type="text/css">
.config_source code{font-size:.8em;color:#000000;}
ul,ol{margin:10px 0 10px 5px;}
fieldset{padding:0 15px 10px 15px;word-break:break-all;}
.summary-container fieldset{padding-bottom:5px;margin-top:4px;}{padding:2px 15px 4px 10px;margin:0 0 0 -12px;}
legend{color:#333333;;margin:4px 0 8px -12px;_margin-top:0px;
At line:1 char:1
+ Get-OfficeWebAppsFarm
+ ~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Get-OfficeWebAppsFarm], ProtocolException
    + FullyQualifiedErrorId : System.ServiceModel.ProtocolException,Microsoft.Office.Web.Apps.Administration.GetFarmCommand
Uninstalling Office Web App Server from the D: drive and reinstalling on the default path of C:\Program Files\Microsoft Office Web App fixed the issue.  Again, this was on Windows Server 2012.  No idea if the same thing happens on Windows Server 2008 R2.

Just an FYI for anyone looking for answers for this specific issue.

Tuesday, July 2, 2013

Renaming Lync Servers

No matter how well you discuss it with other stakeholders in advance, how many times you show it in design documents, and how many change requests you submit with it prominently displayed, you may find yourself having to rename Lync servers in a deployment.

I recently found myself in this unenviable position a few months after I built out a brand-spanking new Lync 2013 deployment for a customer. The server naming convention I proposed was accepted by all the important parties and was prominently displayed in design documents, presentations and change request orders.  Well into the deployment, an issue with the naming convention was brought up by someone important enough to force the server name change after the fact, but apparently not important enough to be included in the design process in the first place. Sigh...

At this stage, there were 3 Lync Server 2013 Enterprise Edition front-end servers, 2 edge servers, and a survivable branch server (SBS) all running Windows Server 2008 R2. Thankfully, they didn't have a problem with the pool names for the front-end and edge pools, so we didn't have to do a complete rip-and-replace, but that was minor consolation for the work ahead.

I managed to come up with a fairly streamlined process to do the renames, with minimal interruption to the users already piloting the deployment. The final result was a deployment with no errors relating to the name change.

I'm not saying there's not a faster way of doing this, by removing fewer components, but this process proved to work for me without issue.  If you've done the same thing by doing less, let me know in the comments.

Do each server one at a time, running through the complete process before starting the next one.

  1. Remove Lync server from topology
  2. Publish topology.
  3. Run Lync Server Deployment Wizard local setup on server to remove Lync components
  4. Uninstall SQL Server. Front-ends have LyncLocal and RTCLocal instances. Remove both, rebooting between instance removal.  Edge only has RTCLocal instance. 
  5. Remove SQL Server 2012 Management Objects (x64)
  6. Remove SQL Server 2012 Native Client (x64)
  7. Remove Microsoft System CLR Types for SQL Server 2012 (x64)
  8. Remove Microsoft Lync Server 2013, Front End Server
  9. Remove Microsoft Lync Server 2013, Core Components
  10. Delete C:\Program Files\Microsoft SQL Server
  11. Delete C:\Program Files\Microsoft Lync Server 2013
  12. Delete C:\CSData
  13. Rename server and restart
  14. Wait until AD replication completes with new server name.
  15. Open Topology Builder, add new server to existing pool and publish.
  16. Reinstall Lync components and all cumulative updates
  17. Generate new certificate with updated server name and assign to appropriate services using Lync Server Deployment Wizard.
  18. Restart all servers in pool at same time (only relevant for front-end servers in an Enterprise pool).