lync server 2010

Quick Tip: Media Bypass Not Available for Edge Connected Users

This is just a quick tip from the field. If you are deploying media bypass it is important to know it will only be available for endpoints that have registered internally, NOT through the Edge. This is by design and may be changed in the future as can be seen in the cmdlet parameters for New-CSNetworkMediaBypassConfiguration. The parameter ExsternalBypassMode is reserved for future use. Read more


Posted on by Randy Wintle in Uncategorized 2 Comments

Understanding Lync Server Support Options

Microsoft recently made changes to the support options available to organizations deploying Microsoft Lync. Microsoft covered these changes in a Next Hop Blog Post- Expanded Lync Server Support Options. I wanted to provide an overview of these changes as I see them from a Microsoft Customer and Microsoft Partner perspective. This post will outline the pros and cons to the newly available support options.

Read more


Posted on by Randy Wintle in Uncategorized Leave a comment

Lync Server 2013 Unleashed has been… Unleashed!

I am super proud to announce that the new book I Co-Authored, Lync Server 2013 Unleashed is now available! This book is available on Amazon in ebook and good ol paperback!

The Microsoft NextHop blog provided an incredibly generous review of the book, which is available here:

What I want to do in this post is provide an overview of the sections in the book, and how they will apply to readers of all types. When we started writing this book we wanted it to be the number one resource for Lync. This includes covering all aspects of a Lync journey, from early conception to detailed troubleshooting and advanced technical scenarios. I have broken the readers down into two broad categories, although I am sure there are many other scenarios out there.

Read more


Posted on by Randy Wintle in Uncategorized 2 Comments

An afternoon in NYC with Lync 2013- NYC Lync User Group

Quick announcement here:

See for more details!

Meeting Details

August 16th 2012 2PM-5PM, an Afternoon in NYC with Lync 2013

The NYC Lync User Group will be conducting its next meeting on August 16th, 2012 at the Microsoft Manhattan Office!   This meeting will introduce everyone to Lync Server 2013. With all of the new features coming in Lync 2013, we will have plenty to talk about at this meeting. Food and Drink will be provided as well!

In addition to discussing Lync 2013, we will also have a special presentation from the Unify2 UC Adoption Team. “The switch from legacy telephony to unified communications is a high hurdle for many enterprises, and changing the way workers conduct meetings from in physical locations to online is an even steeper learning curve. Unify2 Adoption Services are designed to lay groundwork for increased user satisfaction and improved productivity, and to help our customers realize their ROI in a shorter timeframe.”




Intros and Welcome 2:00PM-2:30PM
Lync 2013 – What is New (Overview) Speaker TBD 2:30PM-3:30PM
Lync 2013 Functionality Demo – Randy Wintle 3:45PM-4:00PM
Break 3:45PM-4:00PM
Driving UC Adoption in Your Enterprise- Unify2 UC Adoption Specialist 4:00PM-4:45PM
Sponsor Presentation- Jabra 4:45PM-5:00PM
Evaluation Surveys and Giveaways 5:00PM
Networking/Social Hour 5:00PM-6:00PM



Posted on by Randy Wintle in Uncategorized Leave a comment

Lync Mobility Calculator (Alpha)

This calculator is alpha at best. I plan on hopefully fine tuning and adding more to this very soon.


What this does to date is calculate the memory you will require for your Lync FE servers to properly scale for Lync Mobility.


It requires you to enter your planned user bases (IOS/Windows Phone or Android/Nokia) and will output data based on the Microsoft Planning Formulas.


I do not take any credit for these formulas, I am simply putting them in a spreadsheet for easy access.


Let me know your thoughts in the comments, I will continue to update and hopefully make this a valuable tool!


Posted on by Randy Wintle in Uncategorized 3 Comments

Why Lync Mobile Call-Via-Work Makes Sense



Earlier this week, Microsoft released the Lync 2010 Mobile clients for all major platforms. (See more about that here

With that release, a lot of people are talking about the lack of Voice over IP calling over 3G of Wifi in the product. Instead, Microsoft implemented a solution used for many years, referred to as “Call-Via Work”.

What is Call-Via-Work?

Call via work enables enterprises to deploy a consistently reliable enterprise voice solution to all mobile endpoints connecting to the Lync infrastructure. This functionality essentially bridges calls through the cell phone carrier network, and gives the appearance of a SIP call through your Lync identity.

This solution offers some great benefits:

  • A true “single number” solution, your identity is your work number. You can make or receive calls on this number from anydevice.
  • Battery friendly. This solution allows for users to actually utilize the tested and proven technology available on cell phones for years, reducing the impact on battery life when compared to a Voice over 3G, 4G or WiFi call.
  • Lync mobile users can call federated contacts.The call via work option allows users to make Lync calls to federated partners the same way it does to internal enterprise users, this is great because there is no gap in user capabilities from desktop to mobile.
  • I’ll say it again, Reliability! End users want a consistent experience, and do not want to be worried about the type of connection they are on when making a business call. Lets keep in mind, Lync is a business platform.

In some instances, VOIP makes sense, and lets face it, its kind of a popular technology right now. Everyone wants VOIP, not all end users know why they want it, but its just the new technology to use for most of them. However, it is important to understand that while it is a cool technology, with some potential for cost savings, a true enterprise grade solution cannot provide a reliable experience with VoIP on mobile devices, yet.

The potential savings that would be introduced through a VoIP solution deployed with Lync Mobile would definitely be eaten up by:

  • An overhaul of your Wireless Infrastructure. (If you want to deploy those fancy Cisco WAPs to support mobile VOIP, say good bye to any cost savings introduced by VOIP calling on your mobile)
  • Help Desk costs are a real problem in enterprise environments, these would definitely increase as users start having a poor experience when in an airport, or in a faux 4G area on an overloaded cell tower that provides limited bandwidth.
  • Costs for data vs cell minutes. Not many people know, but it isn’t always true that cell phone data is cheaper than cell phone minutes. Specifically when in roaming, and roaming international scenarios.In some instances, a roaming international 3G or 4G call could cost as much as 50 times more per minute than a roaming cell call…

So, to summarize:

Microsoft has done their research, they are not ignoring the fact that enabling mobile endpoints to communicate anywhere through their enterprise environment is important. What they are doing is deploying it properly! I would rather have a working, reliable solution, than have all the features in the world, that work half the time and provide me with a poor experience.


Posted on by Randy Wintle in Uncategorized 21 Comments

Cannot login to Lync Control Panel “Unauthorized: Authorization Failed”

When accessing the Lync Control Panel you may receive this error:



One possible resolution to this issue is to make sure that your CSCP URL is in your Trusted Sites List. If you have already done this and are still receiving this error, head to the Lync Event Logs on your Lync Front End.

In my case there were a string of LS Remote PowerShell errors each time I attempted connecting to the Lync Control Panel.

The first error from the event logs that I saw was this:


Log Name: Lync Server

Source: LS Remote PowerShell

Date: 7/29/2011 7:22:46 AM

Event ID: 35007

Task Category: (3500)

Level: Warning

Keywords: Classic

User: N/A

Computer: LYNCSE1.contoso.local


Remote PowerShell cannot create InitialSessionState.

Remote PowerShell cannot create InitialSessionState for user: S-1-5-21-1369671878-2169378501-2720954840-500. Cause of failure: A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: SQL Network Interfaces, error: 26 – Error Locating Server/Instance Specified)

Cause: Remote PowerShell can fail to create InitialSessionState for varied number of reasons. Please look for other events that can give some specific information.


Follow the resolution on the corresponding failure events.

This error shows that it could not connect to the SQL Server due to a network error.


Log Name: Lync Server

Source: LS Remote PowerShell

Date: 7/29/2011 7:18:51 AM

Event ID: 35005

Task Category: (3500)

Level: Error

Keywords: Classic

User: N/A

Computer: LYNCSE1.contoso.local


Remote PowerShell cannot read the RBAC Roles information from the store.

Remote PowerShell encountered problem when trying to read the RBAC Roles information for the user. Cause of failure: A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: SQL Network Interfaces, error: 26 – Error Locating Server/Instance Specified)

Cause: The failure may have happened due to some permissions issue in reading the management store.


Make sure that the server is domain joined machine and able to query the active directory.

This error shows that there were issues retrieving my RBAC information from the CMS.

The resolution for this issue ended up being to start the SQL Browser Service on the Lync Front End.

This service provides connecting users with the ability to discover proper connection information when attempting to make a SQL Connection.

After starting this service, logins to the Lync Control Panel worked again.



Posted on by Randy Wintle in Lync, Lync Server 2010, Networking, Unified Communications 6 Comments

Lync RBAC with Child Domains Bug- Fixed in CU2

Prior to Lync Server CU2, if you attempted to create a custom Administrator Role to a child domain, with a user scope set to that child domain it would not work. Example Provided Below: Empty root domain


1x Std Edition Front End w/ CMS


1x Std Edition Front End

Lets say we wanted to create a custom admin role that gave an administrator in the CHILD2 domain to manage his users specifically in the CHILD2 domain. Assume In this scenario you would be logged into the CHILD1 domain with full admin permission on all domains, and CSAdministrator.

The cmdlet would look like this:

New-CSAdminRole –Idenetity Child2CSUserAdministrator –UserScopes “OU:ou=Users,dc=child2,dc=contoso,dc=com” –Template CSUserAdministrator

Before Applying CU2 you would receive the following error:

Set-CSAdminRole : Organization unity (OU) or container “ou=Users,dc=child2,dc=contoso,dc=com” does not exist. Specify a valid OU or container, and then try again.

Once you apply CU2 this error would go away and you would successfully be able to create the custom Admin Role.

Another similar issue with creating or modifying admin roles to have a use OU scope, is that they are Case Sensitive! The OU must be in the exact case as is seen in Active Directory. See the screenshot below for an example, in my lab, when trying to set an admin role with “users” instead of “Users” it fails, switching to “Users” succeeds.


Hope this helps!


Posted on by Randy Wintle in Lync, Lync Server 2010, Microsoft, RBAC, Unified Communications 1 Comment

Deploying DSCP QoS On Server 2003 R2 and Server 2008 R2

This is a brief post to summarize my experiences with deploying quality of service in a recent deployment.

In this engagement, the customer had existing OCS 2007 R2 infrastructure, these were running Server 2003 R2 with the latest service pack, and were running on HP hardware with Teamed NICS for redundancy, not load balancing.

When attempting to deploy packet tagging on the servers using the QoS Packet Scheduler and related policies, packets would not tag at all. When breaking the NIC Team packets would tag, and on any servers without a teamed NIC the same policies worked fine. This was identified as a known issue with 2003 R2 and Teamed NICS.

The good news, is that while we are upgrading to Lync Server 2010 their new servers are running Server 2008 R2 and on similar hardware with Teamed NICS. As of today we have tested QoS deployed using the packet scheduler and related policies and it does work with the Team.


Posted on by Randy Wintle in Lync, Lync Server 2010, Microsoft, Networking, OCS 2007 R2, Unified Communications Leave a comment

Deploying a Lync SBA? Watch out for port 444 (Updated with more ports)

As Lync deployments start ramping up, we are starting to notice a few gotchas in documentation and deployments. One thing that has come up a couple of times is deploying a Lync SBA in a branch site with a firewall between the Datacenter and branch office.

The firewall ports required for the SBA are not well documented, particularly one that is very important to making the SBA Work.

Port 444 TCP is required for front end to SBA communications, below is the only documentation I have found on it so far in the CHM.

Front End Servers

Front-End service




Used for HTTPS communication between the Focus (the Lync Server component that manages conference state) and the individual servers.

This port is also used for TCP communication between Front End Servers and Survivable Branch Appliances.


I reviewed the Lync 2010 Workloads Poster and it is not showing this port as well. However, I have requested an update which we will hopefully see soon.

So, very important, open port 444 TCP between your Data Center and your Branch Office or users will not be able to register against the SBA. Reference of the ports can be seen below.



As a follow up, one of my colleagues pulled together the full list of firewall requirements for branch users. As many enterprises have firewalls between branch and central sites, this list becomes very important. Look for a workloads poster focused on firewalls from Microsoft soon, but hopefully this comes by then. Credit for this list goes to Peter Pawlak at UnifySquare:

SBA (ASM side) <-> Central Site Pool(s):

· TCP/5061 (both ways)

· TCP/444 (both ways)

· TCP/445

· TCP/448

· TCP/5062-5065

· TCP/5072-5073

· TCP/5076

· TCP/5080

(NOTE: I’m not 100% positive that ports in RED are really needed)

SBA -> Monitoring Server(s) (to support MSMQ)

· TCP/135

· TCP/389

· TCP/1801

· TCP/2101

· TCP/2103

· TCP/2105

SBA (ASM side) <-> Exchange UM servers

· TCP/5061

· UDP/<ExUM media port range>

SBA (ASM side) <-> Edge Server(s):

· TCP/5061

· TCP/5062

CMS servers -> SBA (ASM side) (for local config store replication)

· TCP/4443

· TCP/444

· TCP/445

Branch Clients -> SBA (ASM side):

· TCP/5061 (client->SBA)


· UDP/<media port range> (assumes no media bypass)

Branch Clients <-> SBA (GW side):

· UDP/<media port range> (assumes media bypass will be used)

Branch Clients -> Central site Pool (must be pool in site associated with Branch site)

· TCP/8057 (and TCP/8058 if using Lync’s legacy data conf service)

· TCP/5061 (to allow failover to backup central site)

· TCP/<app share conf MCU port range>

· UDP/<A/V conf MCU port range>

Branch Clients -> Central site Pool Web service HLB VIP (pool in site associated with Branch site)

· TCP/443

· TCP/80 (needed by Lync PE devices)

Branch clients <-> Clients & Mediation servers/services in other sites

· UDP/ <media port range>

· TCP/<media port range>

Branch clients <-> Edge servers (running media relay)

· UDP/3478

· UDP/ <media port range>

· TCP/443

· TCP/<media port range>

Branch clients -> Exchange UM servers

· UDP/<ExUM media port range>

Branch clients -> Exchange CAS servers (for EWS)

· TCP/443


Posted on by Randy Wintle in Lync, Microsoft, Networking, Unified Communications 9 Comments