In two recent updates to Lync Server 2013 we added some new configuration settings that give the Lync administrator more control over the frame rate used in both peer to peer and multi-party conference desktop sharing sessions.

These new capabilities have been added for the purpose of supporting high fps in particular for the sharing of CAD/CAM dynamic models or other similar type of content when network bandwidth is plentiful (such as on LAN or well provisioned WAN). They are not generally needed or desirable for sharing Office documents or static content. They are also not advisable where network bandwidth is already constrained.

The conferencing policy discussed below will be leveraged by the Lync 2013 desktop client and any connections from the Lync Web App 2013. Anonymous participants will inherit the organizer's policy.

Enable High Frame Rate Peer to Peer Desktop Sharing

Lync Server version 5.0.8308.420 (July 2013) introduced a setting to increase the frame rate used in peer to peer desktop sharing sessions by adding the EnableHighPerformanceP2PAppSharing parameter to the clientpolicy object.

You can create a new client policy and set the parameter by using the following syntax:

New-CSClientPolicy -Identity tag:HighFpsTrue -EnableHighPerformanceP2PAppSharing $true

Note: When you use this syntax to create a new clientpolicy object you will see a warning as shown below.

You can update an existing client policy by setting the parameter use the following syntax:

set-CSClientPolicy -Identity tag:MyExistingClientPolicy -EnableHighPerformanceP2PAppSharing $true

Note: When you use this syntax to update a clientpolicy object to enable High Performance app sharing you will see a warning as shown below.

Enable High Frame Rate Multi-party Conference Desktop Sharing

Lync Server version 5.0.8308.556 (October 2013) introduced a setting to increase the frame rate used in multi-party conference desktop sharing sessions by adding the EnableHighPerformanceConferencingAppSharing parameter to the clientpolicy object.

You can create a new client policy and set the parameter by using the following syntax:

New-CSClientPolicy -Identity tag:ConfHighFpsTrue -EnableHighPerformanceConferencingAppSharing $true

You can update an existing client policy by setting the parameter use the following syntax:

set-CSClientPolicy -Identity tag: MyExistingClientPolicy -EnableHighPerformanceConferencingAppSharing $true

An astute blog reader might notice that you are controlling a conferencing feature via a parameter of the clientpolicy object and that reader would be correct however this is how the configuration works so there are no typos in the above syntax.

If you wanted to create a single policy and set both parameters at the same time you would use the following syntax:

new-CSClientPolicy -Identity tag:HighFpsTrue –EnableHighPerformanceP2PAppSharing $true -EnableHighPerformanceConferencingAppSharing $true 

If you wanted to update an existing client policy and set both parameters at the same time you would use the following syntax:

set-CSClientPolicy -Identity tag: MyExistingClientPolicy –EnableHighPerformanceP2PAppSharing $true -EnableHighPerformanceConferencingAppSharing $true 

Note: You will only be able to set both parameters on the clientpolicy object at the same time if your Lync Server environment has been updated to at least version 5.0.8308.556.

If you want to verify that a user is receiving the correct client policy when logging on you can search for the following in the sip trace file.

<property name="EnableHighPerformanceP2PAppSharing" >false</property>

<property name="EnableHighPerformanceConferencingAppSharing" >false</property>

How do I know who to apply the High Performance policies to?

• In a peer to peer desktop sharing session the user sharing the content must have the applicable client policy applied to them in order to share content at increased frame rates
• In a conference the same rule applies, the person sharing the content must have the applicable client policy applied to them (this applies to authenticated users in Lync Web App as well)
• Anonymous sharers will honour the organizer's policy
• Federated sharers will honour the settings given to them by their own company

   

Understanding and Configuring the Desktop Sharing Frame Rate

Simply enabling the high frame rate option in the client policies as shown above is not sufficient for actually increasing the frame rate used by the desktop sharing feature. In addition to implementing the changes above you also need to implement a change that increases the allowed frame rate. When the client policy settings (EnableHighPerformanceConferencingAppSharing or EnableHighPerformanceP2PAppSharing) are turned off, the frame rate will be capped to 2.5 fps max however if either are enabled the fps max will increase based on the values specified in the conferencing policy as shown below.

You can create a new conferencing policy and set the increased frame rate by using the following syntax:

New-CSConferencingPolicy -Identity tag:HighAppSharingBitRate -AppSharingBitRateKb 13000

You can then grant this new conferencing policy to a user by using the following syntax:

Grant-CSConferencingPolicy -Identity sip:user@domain.com tag:HighAppSharingBitRate

Your next logical question should be to ask: "What should I set the AppSharingBitRateKb value to and what type of network bandwidth should I expect to see as a result of this change.

The following table shows an approximation of the fps that you should expect. Please note that these values were derived from internal testing of the feature and the results in your particular environment may vary based on current network conditions and the type of content being shared. They are not absolute values or limits however they represent estimates.

The actual fps that the client will yield will be based on a number of factors such as:

• Network conditions - High bandwidth and low latency network will yield the best fps which low bandwidth and or high latency networks will cause a decrease in fps
• Content - If you have more rapidly changing content on the screen you will see a lower fps value however if the content is static you will see a higher fps value

Additional Points

• If the sharer is using the Lync Desktop client they must be using build 15.0.4551.1005 or higher

Summary

As the above blog post has shown we have made some changes to allow a Lync administrator more control over the frame rate that is produced during a Lync desktop/application sharing session. Please test this out in your labs or customer environments and share your feedback on how it is working for you.

Upon looking at visitor statistics for this blog one of the reoccurring trends is the amount of traffic to articles like Updating Lync Phone Edition Devices after Microsoft releases a new round of Lync updates.  It can sometimes be difficult to successfully navigate through the various updates which follow different release schedules which are sometimes bundled together with other Office releases, so hopefully this article can bring some additional clarity to the subject.

This article will continually be updated to serve as both a source of new update information as well as a history of all past updates for both client and server platforms.  Releases for IP phones will continue to be tracked in their original articles so this article will only cover the server and soft client releases. The ‘Updates’ tag can be used as a quick route to all of these articles.  Keeping this data up-to-date and accurate is an ongoing process feel free to leave comments regarding any errors or dead links.

One thing to understand is that for some products Microsoft will continue to leave multiple previous versions online on their download sites, while others (namely Lync Phone Edition) are removed an only the latest cumulative releases are provided.

Lync 2013 Server Updates

Download

As Microsoft only provides the latest releases for the server components then the following two links are always updated with the most recent information and can be used as a definitive source of the latest server updates.

• Updates for Lync Server 2013
• Lync Server 2013 Cumulative Update KB 2809243

Typically one does not need worry about the individual components as the LyncServerUpdateInstaller.exe is the ideal package to download and run on any servers.  This tool will locate and upgrade only the applicable components on each Lync server it is executed on locally.

Installation

At this point in the product cycle there is no real value in documenting the steps which have been already covered on various other websites for basic installations (like here and here) to more complex articles covering Enterprise Edition pools with mirrored databases.

The important points to understand are the following:

• Use the LyncServerUpdateInstaller referenced above to make life easy.
• Start inside-out and work from Front End servers toward Edge servers.
• Do not forget to update and verify the backend SQL database for each Enterprise Edition pool that is patched

Component History

For occasions when working with the individual packages is desired then the following table covers each cumulative update release with links to the original Knowledge Base articles for each new component.

This matrix provides a visual aid to when and how often some of the various Lync components are updated as cumulative releases will typically not refresh every single server component.

Lync 2013 Client Updates

Windows Desktop Client

The following table lists major client update packages with links directly to the download pages for both the client and any prerequisite components, which are only represented again when they themselves are updated.

• Releases denoted with ‘CU’ refer to the unofficial but commonly used Cumulative Update nomenclature for Lync.
• Releases denoted with ‘SP’  refer to a Service Pack release for Microsoft Office.
• 32-bit downloads are recorded as ‘x86’ while links to 64-bit download are labeled as ‘x64’
• Items in strikethrough text have been pulled and replaced by the following update but have been left in this table for posterity.

Howdy,

In part 1 I wrote about what can be considered a guide on a number of post-migration steps to be done before starting with decommissioning of the Legacy Lync 2010 infrastructure, in this article I will be writing on the steps of removing and uninstalling of the legacy Lync 2010 servers.

Moving Conference Directories

Before you remove the Lync 2010 frontend from the Topology you must move the conference directory to the new Lync 2013 pool, actually if you tried to remove the legacy frontend and to publish the topology you will get an error that the conference directory is not moved and still hosted on the legacy Lync pool you trying to delete.

Moving Conference directory is achieved using the Get-CsConferenceDirectory

• · First list all the conference directories in your infrastructure that is hosted on the Legacy Lync

PS C:> Get-CsConferenceDirectory | Where-Object {$_.ServiceID -match “LY2010 pool FQDN”}

• · Now take not of their Identity which should be a Numeric value
• · Move them using the Move-CsConferenceDirectory

PS C:> Move-CsConferenceDirectory -Identity “Numeric Value” -TargetPool “LY2013 Pool FQDN”

Some cases you get error when trying to run this command, the workaround is to close the PowerShell session and start a new one and try again.

Remove Association to the Archive& Monitoring Server

We are getting close now to finish the uninstalling process, hang in there :)

NOTE: Archiving & Monitoring data are not moved to Lync 2013 infrastructure, make sure to back up the data before going ahead and decommission the roles

Without removing the association to the Archive or Monitoring server (If you have them deployed) you will not be able to remove the frontend servers / pool from the topology, also don’t forget about the SQL store

Here is how:

• · Start Lync Topology Builder
• · Download the topology (by now you should know what you doing here :)

• · Expand Lync Server >> your site >> Lync server 2010
• · Double click type of deployment you have (Standard or Enterprise)
• · Right click the pool name >> Select Edit Properties
• · Scroll down and clear the box in front of “Associate Archiving server”, “Associate Monitoring Server” and “Associate Edge Pool”

• · Click Ok
• · Expand “Archiving Servers” >> right click the Archiving server name and select “Delete”
• · On the “Delete Dependent Stores” click Ok
• · Publish the Topology

Now log into the Archiving & monitoring servers, run the Lync deployment wizard, click on “Install or update Lync server system” then click on step:2 Setup or Remove Lync Server Components and this will uninstall the Lync role running on the server.

Remove Association to the Trunks & Gateways

If you have Enterprise Voice deployed and associated Trunks to the Frontend server (in case Mediation server is collocated), or to a standalone Mediation server, you must remove the associated trunks to be able to remove the server, this is allowed only or done by removing the Gateway itself which automatically removes the trunk (Hope that you planned that ahead :) )

• · While still on the Topology Builder expand “shared Components”
• · Expand PSTN Gateways

• · Delete the gateways associated with your Lync 2010 Frontend servers/pool or mediation server
• · Publish the topology

Removing Association to SQL Store, and deleting the Lync 2010 servers / Pool

Deleting the Lync 2010 Servers

This parts applies to most of Lync 2010 roles as in Frontends, Standalone Mediations, Directors, Edge, Archiving and Monitoring servers, once you removed the association to other components in the topology of those roles,

You can delete them from the topology, I’ll write about Frontend Standard edition, but this applies to most of them.

• · Start the topology builder
• · Expand the topology >> your site >> Lync 2010 Server >> standard edition
• · Right click the frontend pool and select “Delete”

Don’t publish the topology yet :) go to next part

Delete the associated SQL Store

• · While still on the topology builder and after deleting the Standard edition Frontend server
• · Go to Shared Components >> SQL Server Stores
• · Right click the SQL Store associated with Lync 2010 Pool
• · Select Delete
• · Publish the Topology

Uninstalling the Lync 2010 Server role (Frontends, standalone mediation & Directors)

Wait a minute for the replication to take place, if you don’t want to wait from a PowerShell run the following cmdlet

Then check if all replication status reporting “up to date” using the following cmdlet

Now you can log into the Lync 2010 Frontend server and start the uninstallation process same way you did with Archiving & Monitoring stated above.

With Mediation Server, Director you do the same, remove them from the topology, publish the topology, wait for replication then login to the servers and start the installation wizard to remove the roles.

Uninstalling Edge 2010 Server

in case of Edge server, you need to remove it from the topology, publish it and make sure that the replication reached the Lync 2010 Edge server, if not then export the configuration as a zip file using following cmdlet

• · Copy the file to the Lync 2010 Edge server
• · Import it using the import-CsConfiguration cmdlet

• · Start the Lync 2010 Deployment wizard on the machine, and do as before with Frontend and Archiving server to uninstall the roles.

Congratulation your infrastructure is now running on Lync 2013 server only, welcome to the club :)

Howdy,

To make things easier for all engineers new to the Lync world, I have collected together some of my articles in one place, here you will find all the information to get you started with deploying, configuring and migrating to Lync 2013, as well as decommissioning your Legacy Lync 2010 servers.

I hope it helps and if you find it helpful spread the news and follow me on twitter :)

Understanding and Planning your Lync 2013 DNS & Simple URLs

• Understanding and Planning for Lync DNS records
• Understanding and planning for Lync Simple URLs

Installing Lync 2013 Server

• Installing Lync 2013 Frontend Server Part-I
• Installing Lync 2013 Frontend Server Part-II

Migrating from Lync 2010 to Lync 2013

• Lync 2010 to Lync 2013 Migration

Lync High Availability with SQL Mirroring

• Migrate Standalone SQL Store to Mirrored SQL Store  Part-I
• Migrate Standalone SQL Store to Mirrored SQL Store  Part-II

Publishing Lync 2013 Services

• Publishing Lync using KEMP
• Publishing Lync using JetNexus
• Publishing Lync using UAG 2010

Installing Lync 2013 Edge Server

• Install & Configure Lync 2013 Edge Server Par-I
• Install & Configure Lync 2013 Edge Server Par-II

Migrating to Lync Edge 2013

• Migrate Lync Edge 2010 to Lync Edge 2013

Migrate Lync 2010 Central Management Store to Lync 2013

• Migrating the Management Store from Lync 2010 to Lync 2013

Integrating Lync 2013 With Exchange

• Integrate Lync 2013 with Exchange UM
• Integrate Lync 2013 with Exchange OWA

Decommissioning Legacy Lync 2010

• Post Migration Steps to get ready for decommissioning of Legacy Lync 2010
• Decommissioning Legacy Lync 2010 servers

Then I came across the SNOM m9.

What is it?

How to setup SNOM m9 to register with Lync 2013?

The base station is set to DHCP by default, connect it to your network and boot. Also power up the DECT handset. Initially the handset will display "searching for base", once it finds the base you can use the handset to determine the IP address assigned to the base station. Press the right key on the circular menu button on the handset

- scroll to System Info and select OK, the IP Address should be shown on the display

Final comments

The Updates have been coming thick and fast, first Server then client and now Lync Phone Edition

Unlike the last LPE update, this one adds some interesting new functionality. There is not a great level of detail at the moment, I will post more when I test the new features.

•  2988196 The lock feature does not prevent users from making calls on a Lync Phone Edition telephone
  • You lock a Microsoft Lync Phone Edition telephone by selecting the “lock” button on the telephone or by locking the computer that is connected to the telephone. The Lync Phone Edition telephone is deployed for Enterprise Voice users. In this situation, you can still make calls by using the telephone.

To control the lock feature, an administrator must set an existing policy entry in the CsClientPolicy object. By default, the lock behavior will not be changed by this update until the DisableHandsetOnLocketMachine value is set to “TRUE.” 

To enable the lock feature, an administrator must run the following command in Lync Server Management Shell:

Set-CsClientPolicy -Identity PhoneLockPolicy -DisableHandsetOnLockedMachine $True

To disable the lock feature, an administrator must run the following command in Lync Server Management Shell:

Set-CsClientPolicy –Identity PhoneLockPolicy –DisableHandsetOnLocketMachine $False

Note If an administrator enables calls to both the EmergencyDialString number and the EmergencyDialMask number that are defined in the CSLocationPolicy policy, the in-band policy for the lock feature will be overwritten.

• 2988193 Update enables users who are not enabled for UC or EV to sign in to Lync Phone Edition telephone
  • This update for Microsoft Lync Phone Edition applies to users who are not enabled for unified communications (UC) or Enterprise Voice (EV).

There are also a couple of fixes noted:

• 2988192 Receive incorrect message when you call a user whose line is busy on a Japanese version of Lync Phone Edition telephone
• 2988195 Incoming call from a PSTN number is disconnected when you put the call on hold on a Lync Phone Edition telephone

     

Twice in two months! How lucky are we? This LPE firmware update (from 4.0.7577.44450 to 4.0.7577.4451) is an interesting one…

What’s Fixed?

• 2988196 The lock feature does not prevent users from making calls on a Lync Phone Edition telephone
• 2988195 Incoming call from a PSTN number is disconnected when you put the call on hold on a Lync Phone Edition telephone
• 2988192 Receive incorrect message when you call a user whose line is busy on a Japanese version of Lync Phone Edition telephone

What’s New?

• 2988193 Update enables users who are not enabled for UC or EV to sign in to Lync Phone Edition telephone

Download

Download the relevant CAB files from here:

• Polycom CX500, 600 and CX3000
• Aastra 6721 and 6725
• HP 4110 and 4120
• Tanjay

And don’t forget Pat’s great “New-CsFirmware.ps1″ script will do all the hard work uploading the new CABs for you.

I love the story of the old engineer called in from retirement to fix something at the factory only to have his $20,000 invoice for 5 minutes’ work questioned by the bean-counters. When asked for a breakdown of the charges he submitted “Chalk mark: $1, knowing where to put it: $19,999”. (Snopes says it’s a myth. Party poopers).

To the untrained eye, the Lync Client isn’t all that special, but if you know what to look for it reveals quite a wealth of information. And who doesn’t delight in being able to walk up to the Client PC (or maybe establishing the briefest of desktop sharing sessions), going “oh, OK” and walking off with the fix already known to you without having to click a thing?

Here I spill the beans. Let me know if I’ve missed anything.

The Search Bar

The Search Bar tells you if several features are enabled just by the prompt it offers:

If this says “Find someone” on its own, this user’s set for Presence and IM only (aka “Audio/Video Disabled”), or has only PC-to-PC voice (aka “-EnterpriseVoice $false”).

The addition of “or a room” means they’re enabled for Persistent Chat, and “or dial a number” means they have Enterprise Voice.

A Tale of Two Clients

Both of the images below are valid working Lync configs, albeit massaged with some help from Photoshop and Snagit. The only liberty I’ve taken here is that the pizza and calendar icons (designated 6 and 7 below) will never appear together. (I’ll explain shortly).

The left image is of a user set as Audio/Video disabled, with the one on the right enabled for Enterprise Voice, Exchange UM & Persistent Chat. (Click for a higher-resolution view).

No? Suspect Registry and/or GPO

If the user’s account settings don’t align to the way Lync’s presenting on-screen, I’d go digging for rogue registry keys or checking if Group Policy is overriding the settings. The table below says it’s not meant to, but in the real world I’ve seen otherwise, especially if the old Communicator.ADM is still kicking around from your OCS days.

(The above screen-grab came from the TechNet article “Configuring client bootstrapping policies in Lync Server 2013“).

Several people have documented the Lync registry and GPO values. Here are some useful blogs:

• Tom Arbuthnot: What Lync 2013 client setting are held in the Registry?
• Richard Brynteson: Client Registry Keys (Part 1) [this then links to a really comprehensive list of follow-on posts]

Hungry for More?

Configuration Information

If you control-right-click the Lync icon in the tray, Lync will offer you the Configuration Information screen.

This provides a wealth of information specific to this user. Rather than reinvent the wheel, I’ll refer you to where Yoav Barzilay’s documented the meaning of each element.

Lync Conference – Advanced Troubleshooting

If you’re REALLY wanting to dig deeper while staying on the Client, you’ll need to enable Lync logging and fire up Snooper (one of the Debugging Tools). Scott Stubberfield and Nick Smith’s “Advanced Troubleshooting SERV400″ session from the 2014 Lync Conference is a great intro to client-side debugging and I commend it to you.

Credits

Thanks to Rocky for the PhotoShop work, to TechSmith for the copy of Snagit, and those linked above who’ve provided their own indirect contribution to this post.

- G.

So far, we’ve just patched our backup pool… but we normally (even in the backup pool) drain all the Lync services on a front end (Stop-CSWindowsService -graceful -nowait) before applying a CU.  This also helps prevent the need for a reboot of the server.  We do the -nowait because we still (at least as of CU4) have issues with the response group call performance counter going haywire (like say, showing 1 billion active calls — I think it is actually due to a subtraction from zero).  This inaccurate performance counter prevents the RTCRGS service from ever draining, so we usually give it a few minutes in this scenario and then stop it without -graceful.

Anyway, we noticed when running the updater for CU5, it applies an update to the Windows Fabric at the end.  This update appears to unexpectedly start up all of the Lync server services on the front end, even if they were previously all stopped, and it seems to wait for them to be running before finishing the fabric patch.  This restarting of services doesn’t allow us to plan for the timing of the restart or work in a desired reboot as in previous CUs.  Also, we encountered one of the 4 FEs in this pool which actually required a reboot on the fabric update step, I believe because one of the services either started too early or didn’t start quick enough.  In this case, I had to say “no” to the reboot, then drain the services again, so that then I could actually reboot without forcing the Lync services to shut down with the OS.

After doing all the FE’s I applied the database update.  It appears that on a quick glance that rtcab and mgc are the only databases to change version numbers.  I’ll be checking tomorrow to see if rtcab’s update reversed our ABSCONFIG custom settings, which has happened in past CUs.

Table of Contents:

1. Discussion about 802.1P
2. Server QOS
3. Client QOS

1. Setup of DSCP using Lync and Windows Server/Client  

Before trying to layout the issue, I feel it is important to understand the context of the problem at hand on a Lync Deployment. The process for setting up QOS is documented, but there is little documentation on how the settings affect the packets. It is the Operating system which affects the packets. Lync is not responsible for Packet generation. The Windows Server or client is in charge of that. The overall Lync process, is to set the proper ports with Lync and Group policy. Second, it is necessary to set every switch to specifically allow communication, on the specified port range ;to pass, only if tagged, the DSCP value in the lync packet.

To be clear, the DSCP value is a layer three item, which goes into the IPV4 header.  This value indicates an 802.1p tag should be added to the layer two header when the packet gets to the switch. For an abstract of QOS, look to TechNet for more related material. DSCP is only part of the QOS equation. this value may be set, but 802.1p is the actual layer two QOS. DSCP only affects layer 3.

IMPORTANT POINT—there is a setting in Lync called 8021p. Its default value is 0. It is not used in Lync 2013 and has no effect on anything. The command you will see this under is Get-CsUCPhoneConfiguration.

Finally, the Operating system must be verified, to be set to allow for QOS DSCP generation. This article hopefully will help get this last item accomplished.

This article looks at DSCP from a windows perspective, providing the locations to check for DSCP privatization to work. IT is important to note that just because DSCP is in place, 802.1p may not be enabled. Here is the top level way to look at the overview from a windows perspective:

¨  Enable QOS on all physical NICS that will be using DSCP

¨ Disable NLA on windows 7 clients  at policy Computer Configuration->Windows Settings->Security Settings->Network List Manager Policies

Use the registry key to disable NLA

¨ Client must be domain joined for NLA to function. Said another way, the client will not get enforcement of DSCP or QOS if not in a domain member.

Set up Lync ports using an article you trust. Ethan Shudnow and Jeff Schertz come to mind. (official MS documentation should be used). blogs are only examples. I have the commands necessary below. Here is another good resource; example setup

Once you have a solid setup in place, its time to look at the OS settings

2. Server Registry locations for DSCP enablement 
This Section is not exhaustive, but  It is important to understand internal QOS should include internal server and ports only. QOS is set up on:

¨ Conferencing, Application and Mediation servers

¨ Edge Servers

¨ Application Sharing

You need to configure Port ranges and Policies. The port range commands are stated below, but consult TechNet for any corner cases. Verify your existing port ranges to determine what changes need to be made:. Keep in mind the ports are contiguous, so you only need to specify the start port and how many ports you want to use. Furthermore, the ports do not need to be the same on a server basis. They can overlap. However, both of these things are not recommended for the sake of ease of management.

¨ Get-CsService -ConferencingServer | Select-Object Identity, AudioPortStart, AudioPortCount, VideoPortStart, VideoPortCount, AppSharingPortStart, AppSharingPortCount¨ Get-CsService -ApplicationServer | Select-Object Identity, AudioPortStart, AudioPortCount¨ Get-CsService -MediationServer | Select-Object Identity, AudioPortStart, AudioPortCountThe changes you will make will involve the following commands. This is called In band provisioning:

Set-CsConferenceServer -Identity EEFE1.mydomain.com -AppSharingPortStart 40800 -AppSharingPortCount 200

Set-CsConferenceServer -Identity EEFE1.mydomain.com -AudioPortStart 49000 -AppSharingPortCount 6000

Set-CsConferenceServer -Identity EEFE1.mydomain.com -VideoPortStart 57000 -AppSharingPortCount 3000For Application Servers:

Set-CsApplicationServer -Identity mypool.mydomain.com -AppSharingPortStart 40800 -AppSharingPortCount 200

Set-CsApplicationServer -Identity mypool.mydomain.com -AudioPortStart 49000 -AppSharingPortCount 6000

Set-CsApplicationServer -Identity mypool..mydomain.com -VideoPortStart 57000 -AppSharingPortCount 3000

3. Windows 7 Client Issues

By this point you may be asking if its worth all the trouble. If you read QOS from Microsoft, they seem to tell us its more work then what its worth.

But were going through with this!

Of course, you need to make the Server side commands for the clients and also set the GPOs up. Thank you to Lain Smith for his help on this command and his articles as well at Northernlync.wordpress.com:

Set-CsConferencingConfiguration -ClientAudioPort 20000 -ClientAudioPortRange 199 -ClientVideoPort 20200 -ClientVideoPortRange 199 -ClientAppSharingPort 20400 -ClientAppSharingPortRange 199 -ClientFileTransferPort 20600 -ClientFileTransferPortRange 199 -ClientMediaPort 20800 -ClientMediaPortRange 199

These are really the registry keys on the client machine. Set your GPOs up (example) and your set.

Wait, don’t forget the phone setting- Set-CsUCPhoneConfiguration -identity global -VoiceDiffServTag 46

The interesting thing about QOS on the Lync clients are that it begins to make you wonder, If Lync is actually in control of packet generation. After you look at some traces, and start to stumble on the whole concept of QOS. It is the network stack that generates the packet, with information, provided from the Lync client. Hopefully you will find guidance to help you see the simple truths at work. The bottom line is the QOS concept is really a Group policy setup to force the clients and servers to use specific ports, and to pass specific request to the network, to identify the packets in a certain way.

The bottom line is the job of QOS is really up to the network. My  recommendation is you simply set the Group policy up and verify the proper values are in place. The only things that will go wrong is the client is not talking on the correct port, as specified, the DHCP value is not changed, or the client is being ignored, no matter what you do to it. Do not fear, there are a few things you cant read in the setup guide.

1. The setup appears to be correct, but the DSCP value wont change, no matter what.

Are you using Windows 7? Well guess what? Windows 7 is the only OS that supports QOS at the time of this writing. DO you know what else? There is a bug in Win 7 so it wont work!  It so happens, I cant find it. Of course. However, it was an update to SP1 windows 7. The main things here, are the drivers and firmware for all Windows, Clients, Switch’s and Routers. This should be a first step to begin with consistent updates across your deployment.

A second common problem is the Windows Client is not sending the DSCP value. Its not sending the DSCP value, because the switch is not set to specifically take the value. It may even take the packet. But… If there is not priority rule on the switch, then QOS will not work.

2. The policy is setup, and I have even put the values in the client registry. They keep going back to defaults, or no value at all.

You have to make sure your looking at the right place. A device should only place DSCP markings on RTP or RTCP traffic. The RTP packet will have odd number as the sequence number. RTCP, even.

This could be, for example, Lync- or Exchange Online / Office365.

Recently, federation broke when implementing “voicemail in the cloud” with Microsoft’s Exchange Online. Microsoft Exchange was configured in Hybrid mode, all successful and operational – users could be moved back and forth and use either Exchange on-premise or Exchange online.

Unified Messaging was already enabled and configured in Lync 2013 on-premise. Recently, we extended the configuration to leverage Exchange Online, e.g. by following this blog article http://blog.msgeneral.nl/2011/11/configuring-voicemail-in-cloud-with.html.

issue

But directly after, forwarding calls to voicemail in Online didn’t work. On Lync front-end server, amongst other errors we found event logs that there were no servers in the  “Dial Plan” which accepted the call.

At about the same time, we found that we lost connection to all federated contacts. But we couldn’t find any errors related in the Event Viewer on the Lync servers. Strange thing!

But, ofcourse, when federation stops working, Microsoft Lync cannot connect to Microsoft Office365 correctly, thus failing calls to the UM services. This might make sense, but WHY did we loose contact with all federated patners and providers?

The issues arose after configuring the SIP Hosting Provider for Microsoft Office365 / Exchange (UM) Online, the only “global”configuration we did on Lync side. And in there, not so much configuration was possible. One thing in particular was the “EnableSharedAddressSpace” switch.

Enabled Shared Address Space

“EnabledSharedAddressSpace” is a switch which controls whether the SIP domain namespaces will be “shared” over the on-premises Lync environment and Microsoft Office365. Thus, users in Online can use the same namespace as used on-premises, or of individual namespaces should be used ( “user1@onpremise.contoso.com” and “user2@online.contoso.com”, for example). This switch, at least in our customers environment, causes a major change in how federation and related communications works.

In short, now it becomes more important that the Microsoft Lync on-premises environment is able to look up some external DNS records. It is crucial that the SRV Record, _sipfederationtls._tcp.<sip-domain> is able to resolve successfully to the external access edge address.

In our customers environment, the Edge server uses an internal DNS server for its name resolving, instead of a public DNS server directly. This works well in the usual design – both internal server records, as well as external addresses could be looked up and resolve.

However, as the internal DNS server is also authorities for the used SIP namespaces, it is not looking up EXTERNAL DNS records for these domains. If a record is not defined in its scope, it just will not resolve and the edge server (as any internal server) will treat it as nonexistent. And exactly this is happening to our lookups to _sipfederationtls._tcp.<sip-domain>, as well as its containing A-record to the external Edge IP Address!

After some testing, we found out that when the external SRV-record and A-record for the external edge is resolvable from the Lync environment, at the very least from the Lync Edge server, the federation issue will be resolved! Both external organisations and hosting providers will be “availble” again, federation will start working again and so will the connection to Office 365 be restored. Our newly created voicemail configuration started working as well.

Solution

Now we know the cause, we can work to a solution. We could do this in two ways. Either way, add a large doses of patience to it;

1. Configure Microsoft Lync Edge server to use External DNS servers (and for internal resolving, use a HOSTS file f.i.).

This way, both external organizations as also the own (sip)domains will be looked up at the public internet side, and return the public SRV- and A-records succussfully.

2. When this configuration is not desired, adding the external SRV-record and A-record to the internal DNS server(s) is an alternative solution.

This way, the required DNS records will be resolvable for the Lync servers. This was the solution of choice.

Be aware that this could mean that the last fall-back lookup option to sip.<sip-domain> at clients will also return the public IP address of the edge. Of course only when sip.<sip-domain> is used as the external Access Edge address, and when all other automatic lookup methods ( Lyncdiscover, SRV-record lookup and “sipinternal”) fail.

When applying a solution, allow your environment to apply the changes. Of course you can force a refresh of its DNS cache by running a “IPconfig /flushdns”, but this is not enough. Even restarting the Lync (edge) services might not be sufficient. Allow yourself at least 15-30 minutes after applying the DNS changes and “flushing” DNS cache on the servers to see any changes in the behaviour.

In yet another example of how picky IIS/ARR can be here is a perfect example that took a bit of figuring out.  As a baseline, there was absolutely nothing special about the configuration of IIS/ARR (other than I didn’t hit the install button myself) but everything else is laid out as I’ve done before in my IIS/ARR Guide.

• Windows 2012 R2
• IIS ARR 3.0
• Fully patched server

Externally, meet, dialin and discovery services all seemed to work fine.  The problem came with authenticated traffic and more specifically when the Lync Client would request a web ticket, the process would fail.  So a quick trip into fiddler showed this error:

And when I clicked on the request to get more details it was as generic as you could get:

401 – Unauthorized: Access is denied due to invalid credentials.

So I decided to verify internal services were working and there were no issues present there.  And I even went to my IIS/ARR server and was able to reach the website directly through IE.  So I knew a problem had to be happening within the IIS/ARR instance itself.  So I decided to build a new server side-by-side and see if I could reproduce the issue.  The only thing different from my guide to here was the fact I didn’t do the install.  After my install, I swung over the DNS records via host file and everything worked great.  So it was time to find the difference between the two.

After digging from screen to screen I found this:

And there was my problem!  Somehow Windows Authentication (and basic auth but less of an issue) had found it’s way onto my IIS/ARR Server.  This was not on the server I manually built.  I can only assume that the Web Platform Installer is putting all of these authentication methods on the server by default.

So lesson learned.  Make sure that Windows Authentication is disabled (and feel free to disable basic auth as well) on your IIS/ARR box otherwise instead of passing your credentials through it’s going to try to authenticate on it’s own.

Gallery View is now available for iPad, Lync Windows Store App already had this capability a long time ago and now it finally arrives for iPad.  Will this capability be avaiable on Android soon?

Secondly for all iOS Devices control for Lobby and Promorion/Demotion of Presenters.  While this is awesome it is not yet available on other Mobile platforms including Windows Phone & Lync Windows Store App.

More info @ Office Blogs : Lync Mobile update–Gallery View on iPad and participant management on both iPad and iPhone
http://blogs.office.com/2014/08/26/lync-mobile-update-gallery-view-ipad-participant-management-ipad-iphone/

More info comparing Lync Mobile Devices (all platforms – not updated yet with new feature set for iOS)
http://technet.microsoft.com/en-us/library/hh691004.aspx