Lync Server 2010 Install failure on Server 2008 R2 SP1

During my free time I thought I’d install Lync Server 2010 and check out the new features. If you want a great guide for installing Lync Server 2010, check out Jeff Schertz’s blog here. I used Windows Server 2008 R2 SP1 slipstream media, since it was just released to the public a few days ago. Why not use the latest and greatest?

Everything was going fine until I got:

Error: Prerequisite installation failed: Wmf2008R2

After a few minutes of digging I spotted the problem, and it’s directly related to Server 2008 R2 SP1. The issue is that the Windows Media format package name was changed in SP1 so the installer bombs since it can’t find the RTM name. The old version was 6.1.7600.16385 and the new version is 6.1.7601.17514. Houston we have a problem!

To fix the problem you can manually install the component using the following command line:

C:Windowssystem32dism.exe /online /norestart /add-package
/packagepath:c:WindowsservicingPackagesMicrosoft-Windows-Media-Format-Pack
age~31bf3856ad364e35~amd64~~6.1.7601.17514.mum /ignorecheck

REBOOT the computer, then you can continue with the Lync Server 2010 installation.

UNC305: OCS 14 Setup and Deployment

This was a fairly dry session covering the setup and deployment of OCS 14. I won’t go through all of the somewhat boring details, but will cover a few juicy tidbits that I learned.

– The Setup of OCS 14 is a completely new experience, 100% different than any previous version of OCS/LCS.

– The presence database is extremely sensitive to performance issues and it should be accessed entirely from memory on the SQL server. If the database is not entirely in memory users can experience delays in presence updates.

– Front-end and back-end servers should have two NICs, at least 1Gb in speed. This is to separate OCS traffic from general traffic such as RDP and backups.

OCS 14 supports Server 2008 R2 read-only DCs, but doesn’t gain any benefit from them.

– Service accounts have been eliminated. OCS services now run as “network service”. This breaks Kerberos authentication, so if you need to use Kerberos instead of NTLM then you need to do some manual configuration steps.

– There is a tool called the topology builder that asks you a lengthy series of questions about what your OCS topology will look like, roles, hostnames, SIP domains, etc. It uses this information to build you a visual diagram of what your OCS topology will look like. It also asks capacity questions, and level of redundancy required. You then export this information into another tool that creates a configuration database. When you go and setup the additional OCS servers it uses this topology information to pretty much automate the remaining OCS server installs. This whole concept of pre-building a topology and then automating server installs is very slick and the first time I’ve ever seen this method. Maybe future versions of Exchange or SharePoint will use this method?

– There a new wizard for configuring OCS certificates. OCS certificates are always very tricky given all of the hosts, pool names, hardware load balancer names, etc. So this wizard asks you about all of these details, pre-populates many values, then can submit the request online to a CA or create a certificate request file for offline usage. Very slick and should ease a lot of problems with certificates.


Although the presenter was showing beta code, the setup seemed fairly straight forward and radically different than any other Microsoft product. I look forward to trying out a beta to see how well it really works.

UNC311: OCS "14" Architecture

This session was really stellar, and covered a lot of good technical details. The session was so information packed that I’ll just highlight a few of the major new features or enhancements in OCS 14.

– The Central Management Store is a completely new feature that schematizes the definition of the deployment topology. What the heck does that mean? It means the entire OCS deployment topology and key configuration details are stored in a XML file. This XML file is replicated to all topology nodes, including Edge servers. This helps by preventing misconfiguration, enables topology validation, and will provide a more reliable discovery method for your OCS services.

– The survival branch appliance (SBA) is a hardware appliance provided by third-party vendors such as HP, Dialogic, and others to provide dial-tone functionality to remote offices should the WAN connection to the datacenter fail. The SBA is designed to be drop-dead easy to configure and easily installed at a remote location.

– Previously Microsoft focused on huge OCS deployments and typically required several servers to support all of the roles since some could not co-exist with each other. In OCS 14 the topology has been simplified and more roles can co-exist with each other. This is good news for smaller deployments as it will require less hardware. On the flip side, OCS can now scale up to almost unlimited size, multi-datacenter deployments, and provide global voice/video/IM support.

– Microsoft will release rich planning and topology build tool to help you size servers, see what roles you need, and help you better plan for your OCS 14 deployment. Previous releases of OCS have had fairly poor planning tools available.

– Like Exchange 2010, the OCS 14 admin tools are built on PowerShell. So anything you can do in the GUI you can now script with PowerShell. This got a round of applause from the audience. As a side note, the OCS control panel (admin tools) is now Silverlight based and no longer uses the MMC. This results in a great boost to usability as the MMC interface was clunky and hard to find all of the settings.

– Full RBAC (role based access control) is now baked into the product. Out of the box there are 14 roles. You can now granularly delegate tasks to the helpdesk, server admins, and other entities within your organization while protecting security.

– Monitoring of OCS has been greatly enhanced. Even with SCOM, previous versions of OCS had very limited monitoring capability. OCS 14 fully supports synthetic transactions, and a much richer SCOM management pack. For example, you could have SCOM run synthetic tests such as IMing between sites, placing voice calls and monitoring call quality, all in an automated fashion and get alerts about any problems. If you scheduled these tests nightly at say 4AM, when you come into work you could be alerted to any potential problems before users complain. You can now proactively monitor OCS.

– All roles, including media processing, are now supported on Hyper-V R2 and VMware ESX. Microsoft made many changes to OCS to support a virtual environment and better process real time data without packet loss. At this time no live migration with Hyper-V R2 is supported, as connections will be dropped. He didn’t mention if VMware vMotion suffers from the same issues or not.

OCS 14 supports very robust DNS load balancing. While this does not eliminate the need for a hardware load balancer (HLB), it greatly reduces the dependency. Apparently HBLs caused many support calls, so all OCS components use DNS load balancing in a smart way, even the client.

– PIN based authentication can be used for devices where a keyboard is not available. This is also good for a new hire onboarding process as they can immediately start using their hard phone by simply providing them a PIN. They don’t even need to know their SIP address.


In summary, OCS “14” has undergone major architectural changes and enhancements. Many pain points of OCS 2007 R2 have been addressed. Microsoft is now positioning OCS 14 as a full fledged voice communications server, including E-911 support. If you so desire, you can kick vendors such as Cisco and Avaya to the curb and rely totally on OCS for an integrated solution.

© 2017 - Sitemap