If you plan to deploy Office Web Apps in support of Lync Server 2013 and decide to run in it on Windows Server 2012, you will run into problems if you do not install .NET 3.5

Technet does not call this specific requirement out http://technet.microsoft.com/en-us/library/jj219455.aspx however if you do not install .NET 3.5 you will see the following issue when attempting to upload PowerPoint presentations.  “Some Presenting Features are unavailable due to server connectivity issues.”

You will also likely not get Event ID 41034 which say the Web Conferencing Server has successfully discovered the Office Web Apps Server, PowerPoint content is enabled.  

The Fix:

On the Office Web App server in question, open a Powershell window and run

"Add-WindowsFeature NET-Framework-Features, NET-Framework-Core"

Patch the server using Windows Update and reboot. 

Re-test Sharing Powerpoints and they rendering and you should be able to upload PowerPoint content!

Hopefully Microsoft updates Technet to include this in the pre-requisites soon so you don’t get burned by this.

The first round of cumulative updates for Lync 2013 are now available as well as the much anticipated Planning Tool and other goodies.

I was recently deploying Lync Phone Edition for a client and ran into a strange situation where Phones we setup at a certain site were all failing to sign into Lync with their previously established PIN Authentication.  We would configure the brand new phones out of the box using PIN Authentication and they would successfully sign onto Lync Server and all was well.  So we thought… 

Later once the phones were idle they downloaded their firmware updates and rebooted and were failing authentication displaying the message “Cannot contact certificate Web Service”  Thinking it was an anomaly we re-entered the PIN Authentication info and the phone promptly signed onto Lync.  To be sure, I rebooted the phone once more and found it that it would display that it could not contact the Lync Server and to check the network port… Seconds later it pauses on the same message “Cannot contact certificate web service”… 

We checked the previously installed site and the Lync Phones were not exhibiting this behavior there..  Still though, because that site had a different DHCP server, we double-checked all the DHCP settings in the problematic site.  (See http://technet.microsoft.com/en-us/library/gg398369(OCS.14).aspx and Jeff Schertz’s great blog on how to do this: http://blog.schertz.name/2010/12/configuring-lync-server-for-phone-edition-devices/)  After double-checking all the DHCP settings that were done for Lync were correct I was convinced it was something else.  If the DHCP settings had been incorrect the phones likely would not be able to sign on at all.

Doing some searching I found the following post in the Technet forums: http://social.technet.microsoft.com/Forums/en-US/ocsclients/thread/c870fbb3-96d5-4e12-8cf8-53e147d8c020/  This was that exact same issue we were experiencing and in this case they were tracing it back to a switch issue.  We asked the network team to compare the settings on the switch in this site from the working site and they found that LLDP was not enabled.  They enabled it and we retested.  Same problem.  Further probing showed that the while Spanning Tree was enabled on the switches, the PortFast option was not enabled on the ports connecting workstations, servers and Phones.  The use of PortFast  allows the speedup of convergence on ports which are connected to a workstations, servers or phones.  Essentially any device that will not cause spanning tree loops (like other connected switches).

After enabling PortFast on these ports, we retested several times and success!  The phones signed on straight away every time. 

There are likely many ways to do this including some fancy Powershell Scripts I’ve seen to do this but here is the easiest way I’ve found to restart all lync services running on a server.  The nice thing is this will work on all Lync Server roles and you can do it in just two lines:

Get-CsWindowsService | Where-Object {$_.Status -eq "Running"} | Stop-CsWindowsService
Get-CsWindowsService | Where-Object {$_.Status -ne "Running"} | Start-CsWindowsService

Enjoy.

By Dino Caputo & Kevin Kieller of enableUC

Cloud services continue to attract much interest from potential customers and Microsoft's Office 365 is often considered by those looking to move to the cloud.

Part 1 of this series looked at how enableUC moved from Microsoft BPOS to Office 365, primarily focusing on email. (For more of an overview of Office 365, see Office 365: First Impressions.)

In this installment we look at how Office 365 allows organizations to move their voicemail into the cloud. The example we look at involves voicemail for a Lync environment however keep in mind that there is an opportunity to move voicemail to the Office 365 cloud for other more traditional telephony systems as well. We will likely explore using cloud-based Office 365-powered voice mail with other telephony systems in future installments.

enableUC's Lync Environment

The Office 365 version of Lync includes a number of limitations.

A full comparison between Lync Online and on-premise Lync Server features can be viewed here. In summary, the main limitation of Lync Online is the lack of voice and telephony functionality. Features such as PSTN calling (inbound and outbound) are not possible with the native Office 365 offering today.

To work around these (current) limitations with Office 365, enableUC has installed its own on-premise version of Lync.

The enableUC Lync environment consists of two Physical Servers which run Windows Server 2008R2 and leverages Hyper-V virtualization to host the Lync server roles required. The following 5 virtual server roles support enableUC's Lync infrastructure today:

• Active Directory Domain Services (ADDS) with DNS and Certificate Services
• Lync Standard Edition Server (providing all Lync workloads)
• Lync Mediation Server (providing SIP/TCP to SIP/TLS & SRTP to RTP translations as well as codec translations, RTAudio to G.711, termination point for ThinkTEL SIP Trunk)
• Microsoft Threat Management Gateway (TMG) providing secure Web reverse proxy services
• Lync Edge Server allowing for remote user access and federation to other OCS/Lync networks as well as Public IM Networks (AIM, MSN, and Yahoo)

Focus on Voicemail

With BPOS, the previous version of Microsoft's hosted offering, the Exchange component did not support the unified messaging role that provides voice mail.

This meant that in order for enableUC to have voicemail, we effectively needed to leverage either a 3^rd party solution or run Exchange Server on premise alongside Lync, which diminished the value proposition of BPOS.

A major improvement with Office 365 was the inclusion of Exchange Unified Messaging as part of the offering. This allows organizations to enable Microsoft Exchange Unified Messaging for their on-premise Lync deployment or connect a UM capable IP-PBX. If you have previously worked with and enabled Exchange UM for and on-premise solution, enabling cloud-based Exchange UM will be very similar.

In summary, below is the ten step process that enables an on-premise Lync deployment to use voicemail services from the Office 365 cloud:

1. Ensure you have a working Lync environment.
2. Verify existing or create a new Hosted Voice Mail Policy.
3. Create UM Dial Plan.
4. Configure an E.164 Routing Number within the Dial Plan and Configure a Subscriber Access Number.
5. Create a Lync Exchange UM Contact to represent the previously created Dial Plan in Exchange.
6. Associate the Hosted VoiceMail Policy with the Contact Object.
7. Ensure that the Lync Users you want to UM enable are first enabled for Lync Enterprise Voice.
8. Enable users for Hosted Voicemail in Lync.
9. Enable users for Exchange UM within Office365.
10. Ensure users have email addresses in Active Directory.

     

All the "Techie" Details Fit to Print

For those technically adept and those who want to "play along at home" below is the detail on how this process unfolded for our configuration. (Those who are scared off by technical jargon may want to skip ahead to the "Success and Limitations" section.)

1. First off you need to have a working on premise Lync environment that includes a Lync Front-End Standard Edition server or a Lync Enterprise Edition Pool along with a Lync Mediation server (could be collocated on Standard Edition Server) and a Lync Edge Server. I will assume for the purposed of this post that your environment is fully functional in terms of the Lync workloads.

    

2. By default Lync creates a Global Hosted Voice Mail Policy you can use or you can create a new Policy based on a Lync Site, or Per-User basis. Here is what the command would look like to create a Per-User basis policy:

    

   New-CsHostedVoicemailPolicy -Identity Oakville -Destination exap.um.outlook.com -Description "Hosted voice mail policy for Oakville users." -Organization "enableUC.com"

    

   The destination should always be exap.um.outlook.com

    

3. In Exchange Control Panel (ECP), create a new UM Dial Plan for the Lync users who will be enabled for Enterprise Voice, and use Exchange Online UM for voice mail. This will need to be a SIP URI based Dial Plan and for simplicity I used a 10 Digit plan that matched our E.164 numbers.

   To do this logon to the Office 365 Admin site and select Manage under the Exchange Online heading as shown below:

    

   

This brings you to the Exchange Online Control Panel. Next select the Phone and Voice option choose UM Dial Plans.

Click New UM Dial Plan and set the type to "SIP URI". I used a 10 digit dial plan that will simply match our DID numbers.

Save your changes.

1. Next we create The E.164 Routing number which coincides with the Dial Plan that we just created. This tells Exchange UM how to route calls destined for any user configured for this dial plan. You will also specify this same number but in a readable format which represents the Subscriber Access number. This will also be the number that users would dial into for Exchange Voice Access. Click on "Configure UM Dial Plan" for the UM Dial Plan you just created:

    

   

Enter the E.164 Routing Number you have selected and then enter the same number as you want it displayed to users

1. We now need to create a contact object within Active Directory to represent the Dial Plan. To do this we run the following Lync Powershell cmdlet:

New-CsExUmContact -DisplayNumber +1645551212 -SipAddress sip:EX-UM-SA@enableUC.com -RegistrarPool EUCLyncSE1.corp.enableUC.com –OU "OU=EXUMContacts,DC=corp,DC=enableUC,DC=com"

The DisplayNumber, SIP address and Registrar Pool should be changed to your values specific to your organization. You can even specify where you want these contacts created using the OU parameter.

1. We will now associate the Hosted Voicemail Policy we dealt with in Step 2 with this contact object we just created in Step 5. Again we run a Lync Powershell cmdlet to do this.

Grant-CSHostedVoiceMailPolicy –Identity "ex-um-sa" – PolicyName Oakville

If you used the Global HostedVoiceMail Policy then you don't need to specify a PolicyName otherwise use the PolicyName parameter. In our case since we created created a user based Hosted VoiceMail Policy called Oakville that is what I specified. The Identity parameter should exactly match what you called your Exchange UM object that was created in step 5. Note that the cmdlet in step 5 will create the Display name using the first part of the sip uri.

1. Ensure users you want to Exchange UM enable are Enterprise Voice enabled in Lync.
   
2. If you used a Global or Site based CSHostedVoiceMailPolicy then you may not need to do this. If you used a per-user based CSHostedVoiceMailPolicy then you will need to apply that policy to each user that requires Exchange UM. Use the same cmdlet as in step 6.
   1. So for me it would be Grant-CSHostedVoiceMailPolicy –Identity "Dino Caputo" – PolicyName Oakville
   2. Then Set the CSHostedVoiceMail attribute for the user with the following cmdlet: Set-CsUser -Identity "Dino Caputo" -HostedVoiceMail $True
      
3. In the Exchange Control Panel within Office365, enable a user for Unified Messaging.
   
4. Ensure users have their email address field populated within your local Active Directory. This is crucial for the Lync client to be able to access Exchange Web Services in the cloud and for the voicemail functionality to work in the Lync client.

    

If everything has been setup correctly the next time you sign onto Lync you should be prompted to install the Microsoft Online Services Sign-in Assistant. This client facilitates the remote Exchange Autodiscover process, allowing Lync to communicate with Exchange Web Services and tap into the rich integration features that Lync and Exchange provide. Install this client and restart the Lync client. You will then be prompted for your Office 365 Credentials after signing onto Lync.

Success and Limitations

Overall our transition to voicemail in the cloud went very well.

For an organization that is focused on Unified Communications we really needed an on-premise Lync environment to take advantage of its full list of capabilities and also to facilitate the custom development that we are presently doing. Generally speaking there is no difference between the on-premise version Exchange 2010 UM and the cloud version with respect to the feature set offered. For more Q&A on this topic please see http://community.office365.com/en-us/w/exchange/569.aspx

In our case, all of the Lync client integration features between Outlook and Exchange 2010 Online worked well. This includes features such as Missed Call Notification, Conversation history, voicemails, received and dialed calls right from within the Lync and Outlook client.

What doesn't work so well is Lync Phone Edition. (For clarity, Lync Phone edition is the software that runs on the Lync-compatible IP phone sets.) Although you do get Message Waiting Indicator (MWI) on received voicemails and can listen to them via the Lync Phone Edition, you cannot access Exchange Contacts or Calendar because the Phone is not capable of talking to Exchange Web Services which is required for these features to work.

These issues arise due to the fact that the Lync Phone Edition does not support wildcard certificates, which is what Microsoft Exchange Online is utilizing in order to enable organizations to connect to it. We are hoping that this is something that Microsoft will correct in the near future as many Office 365 customers will want to take advantage of using Lync Phone Edition.

Using Office 365 Voice Mail with Traditional PBXs

An exciting area for customers looking at moving their voicemail into the cloud and taking advantage of all the great features of Exchange UM is that your existing IP-PBX may be capable of leveraging Office 365 Exchange UM.

We run into many customers that have IP-PBXs that are working fine however their voicemail solution is on its last legs. In this case, Exchange UM online might be able to solve your problems.

Conclusion

While not a trivial process, setting up voicemail in the cloud using Microsoft's Exchange UM Online is certainly possible and very worthwhile. If you have Lync Server on premise today or have an existing IP-PBX this is a solution you may want to consider.

Dino Caputo is a partner with enableUC a company that helps organizations get the most out of their UC investments. You can follow Dino on twitter at @dinocaputo.

Kevin Kieller is a partner with enableUC and regular contributor to No Jitter. You can follow Kevin on twitter @kkieller.

One of my clients recently went through a very painful troubleshooting process with OCS 2007R2 Group Chat whereby the Channel Service would stop after minimal load was presented to it.  We would get the following error in the Group Chat logs:

System.NullReferenceException: Object reference not set to an instance of an object.

   at Microsoft.Rtc.Internal.Chat.Server.ServerCommon.User.ChannelParticipantsMap.YieldForEachNativeEndpoint(IServerChannel channel, PermissionType permType, Predicate`1 predicate)

   at Microsoft.Rtc.Internal.Chat.Server.Channel.MessageProcessors.GroupChatProcessor.Process(GroupChatMessage command, ProcessStatus status)

   at Microsoft.Rtc.Internal.Chat.Server.Channel.MessageProcessors.MessageProcessor`2.Microsoft.Rtc.Internal.Chat.Server.Channel.MessageProcessors.IMessageProcessor.ProcessInSafeMode(ITransportMessage transportMessage, ProcessStatus status)

After weeks of troubleshooting with Microsoft it turns out that root cause of the issue was due to the Group Chat Logging Level set to up to DEBUG.  The default is INFO but we had turned up the logging level during the initial burn in period to troubleshoot another issue and had left it that way.  In fact Microsoft had asked us to turn it up to DEBUG as well to troubleshoot this issue as Group Chat doesn’t really log much relevant into to the Application Event Log.

The issue was escalated up to Product Development and they were able to reproduce the issue citing the logging level actually creating a situation while under heavy loads would terminate the Channel Service.  Apparently it was related to Group Chat functions that attempt to determine if client is native or remote.  If NULL then it impacts the Channel Service if Logging is above DEBUG level causing a QUIT PROCESS to being the graceful shutdown. 

The immediate workaround is to lower logging level to INFO for the Channel Service which can be done on the Group Chat Server Configuration Tool as shown below.

Microsoft said that this issue will be fixed in CU11 which is slated for sometime in early 2012.

I haven’t confirmed if this also affects Lync 2010 Group Chat but suspect it does given the little differences between the versions.

Latest Lync Cumulative updates are located here:

The latest batch of Lync cumulative updates are detailed below:

Server-side updates

• Lync 2010 Server – KB2571546 – download
• Lync 2010 Core Components – KB2571545 – download

Client-side updates

• Lync 2010 (Communicator) – KB25715423 – download (x86 / x64)