« September 2016 | Main | November 2016 »
Posted at 11:39 AM | Permalink | Comments (0) | TrackBack (0)
Using Skype Online eliminates the need for you to deploy servers on-premises and also relieves your IT department from needing to deal with the on-going security patching and cumulative update installation associated with operating an on-premises Skype for Business Server solution. However, even with Skype Online you still need to ensure your managed network is properly provisioned and configured. Additionally, you still need to work to set user expectations and through training, communications and change management help your users get the most from Skype Online.
In the first part of this story, I documented the network requirements for Skype for Business. In the second part of this story, I explained how to download, install and run the free Skype for Business Network Assessment Tool. In this article I details how to interpret the assessment tool results.
Continue reading at http://www.ucstrategies.com/unified-communications-strategies-views/prepping-your-network-for-skype-online.aspx
Posted at 03:26 PM | Permalink | Comments (0) | TrackBack (0)
To have a successful Skype Online implementation you must test your network.
In the first part of this story, I documented the network requirements for Skype for Business. In this article I explore how to setup and run Microsoft’s free network assessment tool.
The Skype for Business Network Assessment Tool provides the ability to determine how well your network would perform for a Skype for Business Online call by means of a simple audio call test. The tool tests the connection to Microsoft Network Edge by streaming a set of packets to the nearest edge site and back for approximately 17 seconds for a configured number of iterations.
The tool measures, monitors and reports a number of key call quality metrics.
Read the rest here:
Posted at 11:45 AM | Permalink | Comments (0) | TrackBack (0)
With more and more customers adopting the Enterprise Mobility Suite I am encountering customers that run into issues with turning on Microsoft Multi-Factor Authentication (MFA) within Office365 and not being fully prepared for how that impacts the Skype for Business client. Specifically, I am referring to customers that have moved to Exchange Online and have Skype for Business Server installed on their premises. Why might we enable MFA? As the name implies you want to have multiple layers of security to ensure a user is really that user. MFA is a feature provided by Modern authentication which brings Active Directory Authentication Library (ADAL)-based sign-in to Office client apps across platforms. This enables sign-in features such as Multi-Factor Authentication (MFA).
Any pre-office 2016 Skype client is not ADAL/MFA aware and as such when you sign onto Skype for Business or Lync Server, the client fails to connect to the Exchange mailbox for clients that have MFA enabled. So you have two options here. You can have the users request and enter an MFA password for their Skype client or you can enable support for the Office 2013 user.
Here is an example of an app password:
bifvmvcpqwdbpsyz
Clearly this would be a hard password to guess which makes it secure. However, it’s also a tedious one to have to enter into your client or phone.
That’s certainly a mouthful! The Allow AllowAdalForNonLyncIndependentOfLync setting in Skype for Business allows you to provide the Modern Auth experience for users of Office 2013 so they don’t need to use the MFA password in their client.
KB3082803 goes into detail on how to do this.
Note The option to enable this setting through Group Policy is available only after you apply the July, 2015 Public Update (PU).
For Skype for Business or Lync 2013 clients 15.0* (available from the September 2015 PU only):
HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\15.0\Lync
For Skype for Business or Lync 2013 clients 16.0*:
HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\16.0\Lync
Note This option is available through the September PU only.
To enable the in-band setting on the Lync server, run the following cmdlet:
$a = New-CsClientPolicyEntry -name AllowAdalForNonLyncIndependentOfLync -value "True"
Set-CsClientPolicy -Identity Global -PolicyEntry @{Add=$a}
To enable Modern Authentication for Office 2013 applications on a Windows-based device, you must set an additional registry key:
Registry key |
Type |
Value |
HKCU\SOFTWARE\Microsoft\Office\15.0\Common\Identity\EnableADAL |
REG_DWORD |
1 |
HKCU\SOFTWARE\Microsoft\Office\15.0\Common\Identity\Version |
REG_DWORD |
1 |
If you are running Office 2016 then you will already have support for Modern Auth so you will not have to make any changes to your environment. If you support both Office 2013 and 2016 then you will need to follow the steps above.
Posted at 12:33 AM | Permalink | Comments (0) | TrackBack (0)
In part one of this series I introduced the Microsoft Call Quality Methodology and have a high level overview of what CQM was and how you could start your journey to improving user experience for your Lync or Skype for Business Server deployment. In Part 2 we dive into running Key Health Indicators or (KHI) for short on your servers. Microsoft has published KHI guidance for your Lync and Skype for Business Servers. The notion is that if your servers are not running optimally then you might expect a less than desirable user experience.
KHI or Key Health Indicators are a refined list of critical Performance Counters (with accompanying thresholds) considered vital to the health of a Lync Server 2013 or Skype for Business Server deployment.
The KHI’s are grouped into 3 categories or “rings” which outline the priority of the KHIs. While all the KHIs are important, the logical groupings correspond to which KHIs are expected to have the biggest impact.
Ring 0 is comprised of all System KHIs (e.g. CPU, Disk, Memory and Network). When KHIs in this ring are beyond threshold, there is high likelihood that KHIs in Ring 1 and Ring 2 are beyond threshold. Therefore, when developing a remediation plan, focus should first be on Ring 0 issues before taking other actions to resolve KHI issues in other rings.
Ring 1 mostly contains request queue latencies, SIP problem indicators and network response queues. Often KHI problems in Ring 0 contribute to Ring 1 issues.
Ring 2 is all remaining KHIs.
Start with downloading the Key Health Indicators for Lync Server 2013 and Skype for Business Server 2015. This contains the bits you need to run the KHI as well as a good explanation of how to do this. Basically the steps are as follows to run the KHI for your servers:
1. Create the Performance Monitor Data Collectors on each server. This is done by running the following on each server:
#Create KHI Data Collector on a single server
Create_KHI_Data_Collector.ps1 –version Skype4B
Create_KHI_Data_Collector.ps1 –version LyncServer2013
#Create KHI Data Collector on a remote server
Create_KHI_Data_Collector.ps1 –version Skype4B –computer fe1pool1.contoso.com
Create_KHI_Data_Collector.ps1 –version LyncServe2013 –computer fe1pool1.contoso.com
The above step should be done on all Lync/Skype servers in your environment and only needs to be done once.
2. Next you are ready to start a collection run. Typically, we want to run KHI sample collections for a period of 24 hours so you can get a good idea of how the servers are performing over the course of an entire day. The following shows the commands required to do this either on the server in question or remotely from a machine that has the appropriate access to all your servers:
#Start KHI Data Collector on a single server
Logman start KHI
#Start KHI Data Collector on a remote server
Logman start KHI –computer fe1pool1.contoso.com
3. Stop the collection after 24 hours.
#Stop KHI Data Collector on a single server
Logman stop KHI
#Stop KHI Data Collector on a remote server
Logman stop KHI –computer fe1pool1.contoso.com
4. After stopping the LyncKHI Data Collectors, you will want to move the output files to a central location so you can start the analyzing process. By default they are located at c:\PerfLogs\Admin\LyncKHI\ on all the servers you deployed the KHI data collectors to. Move all the results to your workstation and keep the results organized per server to keep things easy on you as there could be a lot of data you need to go through.
Included in the KHI download there is an excel spreadsheet called Key_Health_Indicators_-_Analysis_and_Definitions_Workbook_-_v1.1.xlsm. You will open this workbook and on the first tab you will find the following macro that allows you to import the KHI data you have collected. I like to have a separate workbook for all my collection of server roles. So I would have a workbook for all servers in a Front-End Pool for example. Same goes for Edge Pools and Mediation Pools. This allows the files to remain somewhat small and allows you to view your server environment based on the server roles. Once you hit the start button it can take a while to parse all the data you are pointing it to.
After the data has been imported, you can move through the tabs of the workbook. The second tab KHI Definitions explains all the counters the workbook is using. This is useful for reference.
The third tab or “Charts” shows the following data
The first chart shows the total number of servers analyzed listing the optimal vs sub-optimal servers per Ring with Ring 0 in the center moving to Ring 2 on the outer edge. In this case of the 18 servers looked at, all had sub optimal counters. The chart on the right shows the optimal vs sub-optimal counters per ring. It is important to note that the counters in the charts are showing the number of times a counter sample exceeded a prescribed threshold in a given sample period.
The third tab or “Timeline” shows the breakdown of counter thresholds being exceeded by the timeline sample period. This is helpful in identifying the peek times of when servers may be performing poorly.
The fifth tab or “Pivots” tab shows all the sample periods where counters where sub-optimal. You can fine tune and select what you are looking for in terms of the Ring you wish to sort by or server name.
Lastly the final tab or “Tables” tab shows all the sample data collected allowing you to dive in and view the raw data if required.
So what’s next? Remediation will involve starting with Ring 0 and determining if you can remediate the issues flagged. For example, if the majority of the Ring 0 issues involved CPU or Disk related issues and you are in a virtualized environment, you may consider giving more CPU to the servers and increasing I/O to the disks. Once done you would re-run the KHI and see if this improves the results. Repeat the steps until all Ring 0 issues are remediated or you no longer experience the issues caused by the reported sub-optimal counter.
Move onto Ring 1 and repeat the remediation steps here and then finally do the same for Ring 2. In most cases solving Ring 0 issues will remediate Ring 1 and 2 issues. Remember that if you make changes you will need to validate the changes by running another collection sample to validate those changes.
Once you have stabilized your environment and you are happy with your KHI results, remember to run them from time to time, perhaps once every six months to ensure your servers remain healthy. If you have significant change in your environment like adding a large number of users, you will want to run the KHI collection sample again.
In the next part I will dive into running CQM reports to look at call quality health.
Posted at 09:52 PM | Permalink | Comments (1) | TrackBack (0)
Skype for Business Online (or Skype Online for short) delivers a strong IM & presence, voice, video, and conferencing solution that operates on all leading desktops and mobile devices. Organizations looking to simplify, or avoid, on-premises server and equipment deployment may look to Skype Online, which is powered by the Office 365 Cloud. However, in order to have a successful Skype Online implementation your network needs to be up to the task.
In this three-part series, I explore:
Check out Part 1: http://www.ucstrategies.com/unified-communications-strategies-views/is-your-network-ready-for-skype-online.aspx
Posted at 08:00 AM | Permalink | Comments (0)
Here is my quick reference guide to patching Skype for Business Server environment with Cumulative updates for the Skype for Business application itself. Microsoft provides regular cumulative updates which can be found here on the TechNet Skype for Business downloads and updates page. The Cumulative Updates contain important bug fixes as well as feature enhancements to the product so you will want to stay up to date and patch with a regular cadence. I don’t like being more than one CU behind at any given point in time.
You will want to download the Cumulative Update Installer which takes the guess work out of what patches are required on which Skype server role. At the time of writing this post the current Cumulative Update or CU is the June 2016 CU. The following shows the typical landing page where you can download the current CU.
Figure 1: Cumulative Update installation page
The following outlines patching a typical Skype for Business 2015 Enterprise Edition Server environment. In this case I have the following inventory of servers running a SfB 2015 Role:
· 6 Front End Servers
· 3 Mediation Servers
· 2 Edge Servers
The patching process is broken up into three parts which are:
· Patching the Front End Server Pools
· Patching Mediation, Director and Edge servers
· Patching the backend SQL Databases
It is recommended you plan and schedule a maintenance window to patch your environment. It should be done afterhours as the process can cause temporary outages for users. While these outages are quick (anywhere from 30 seconds to 2 minutes) you should still schedule the changes after business hours.
Expert Tip:
Patching your Skype Front-End servers requires you do them one at a time. I cannot emphasize the importance of this so that you do not experience any Windows Fabric issues. Work with one pool and one server at a time when patching and never patch more than one front end server at one time.
1. Type the following cmdlet:
Get-CsPoolFabricState -PoolFqdn SkypePool.contoso.com.com
You should see something similar to the following output. Basically we are looking for any missing replicas. The following shows a working state. I’ve highlighted in green a sample of the text you are looking for that shows a healthy fabric.
Windows PowerShell
Copyright (C) 2014 Microsoft Corporation. All rights reserved.
PS C:\Windows\system32> Get-CsPoolFabricState -PoolFqdn SkypePool.contoso.com.com
Replica Instances for MCUFactory Service
Address: SKYPESFBFE01.CONTOSO.COM - Primary: 1 Secondary: 3
Address: SKYPESFBFE02.CONTOSO.COM - Primary: 1 Secondary: 2
Address: SKYPESFBFE03.CONTOSO.COM - Primary: 1 Secondary: 3
Address: SKYPESFBFE04.CONTOSO.COM - Primary: 2 Secondary: 1
Address: SKYPESFBFE05.CONTOSO.COM - Primary: 0 Secondary: 2
Address: SKYPESFBFE06.CONTOSO.COM - Primary: 1 Secondary: 1
Local MCUFactory Service:
Missing Primary : 0
Missing Both Secondary : 0
Missing One Secondary : 0
No Missing Replicas : 6
Total Count : 6
Pool MCUFactory Server and Services Summary:
Fqdn: SKYPESFBFE01.CONTOSO.COM Primary: 1 Secondary: 3
Fqdn: SKYPESFBFE02.CONTOSO.COM Primary: 1 Secondary: 2
Fqdn: SKYPESFBFE03.CONTOSO.COM Primary: 1 Secondary: 3
Fqdn: SKYPESFBFE04.CONTOSO.COM Primary: 2 Secondary: 1
Fqdn: SKYPESFBFE05.CONTOSO.COM Primary: 0 Secondary: 2
Fqdn: SKYPESFBFE06.CONTOSO.COM Primary: 1 Secondary: 1
Replica Instances for ConferenceDirectory Service
Address: SKYPESFBFE02.CONTOSO.COM - Primary: 0 Secondary: 1
Address: SKYPESFBFE04.CONTOSO.COM - Primary: 0 Secondary: 1
Address: SKYPESFBFE05.CONTOSO.COM - Primary: 1 Secondary: 0
Local ConferenceDirectory Service:
Missing Primary : 0
Missing Both Secondary : 0
Missing One Secondary : 0
No Missing Replicas : 1
Total Count : 1
Pool ConferenceDirectory Server and Services Summary:
Fqdn: SKYPESFBFE02.CONTOSO.COM Primary: 0 Secondary: 1
Fqdn: SKYPESFBFE04.CONTOSO.COM Primary: 0 Secondary: 1
Fqdn: SKYPESFBFE05.CONTOSO.COM Primary: 1 Secondary: 0
Replica Instances for Routing Service
Address: SKYPESFBFE01.CONTOSO.COM - Primary: 3 Secondary: 8
Address: SKYPESFBFE02.CONTOSO.COM - Primary: 3 Secondary: 7
Address: SKYPESFBFE03.CONTOSO.COM - Primary: 3 Secondary: 8
Address: SKYPESFBFE04.CONTOSO.COM - Primary: 3 Secondary: 8
Address: SKYPESFBFE05.CONTOSO.COM - Primary: 4 Secondary: 7
Address: SKYPESFBFE06.CONTOSO.COM - Primary: 3 Secondary: 0 Other: 9
Local Routing Service:
Missing Primary : 0
Missing Both Secondary : 0
Missing One Secondary : 0
No Missing Replicas : 19
Total Count : 19
Pool Routing Server and Services Summary:
Fqdn: SKYPESFBFE01.CONTOSO.COM Primary: 3 Secondary: 8
Fqdn: SKYPESFBFE02.CONTOSO.COM Primary: 3 Secondary: 7
Fqdn: SKYPESFBFE03.CONTOSO.COM Primary: 3 Secondary: 8
Fqdn: SKYPESFBFE04.CONTOSO.COM Primary: 3 Secondary: 8
Fqdn: SKYPESFBFE05.CONTOSO.COM Primary: 4 Secondary: 7
Fqdn: SKYPESFBFE06.CONTOSO.COM Primary: 3 Secondary: 0
Replica Instances for LYSS Service
Address: SKYPESFBFE01.CONTOSO.COM - Primary: 3 Secondary: 8
Address: SKYPESFBFE02.CONTOSO.COM - Primary: 3 Secondary: 7
Address: SKYPESFBFE03.CONTOSO.COM - Primary: 3 Secondary: 8
Address: SKYPESFBFE04.CONTOSO.COM - Primary: 3 Secondary: 8
Address: SKYPESFBFE05.CONTOSO.COM - Primary: 4 Secondary: 7
Address: SKYPESFBFE06.CONTOSO.COM - Primary: 3 Secondary: 0
Local LYSS Service:
Missing Primary : 0
Missing Both Secondary : 0
Missing One Secondary : 0
No Missing Replicas : 19
Total Count : 19
Pool LYSS Server and Services Summary:
Fqdn: SKYPESFBFE01.CONTOSO.COM Primary: 3 Secondary: 8
Fqdn: SKYPESFBFE02.CONTOSO.COM Primary: 3 Secondary: 7
Fqdn: SKYPESFBFE03.CONTOSO.COM Primary: 3 Secondary: 8
Fqdn: SKYPESFBFE04.CONTOSO.COM Primary: 3 Secondary: 8
Fqdn: SKYPESFBFE05.CONTOSO.COM Primary: 4 Secondary: 7
Fqdn: SKYPESFBFE06.CONTOSO.COM Primary: 3 Secondary: 0
Replica Instances for Fabric Service
Address: SKYPESFBFE01.CONTOSO.COM - Primary: 0 Secondary: 3
Address: SKYPESFBFE02.CONTOSO.COM - Primary: 0 Secondary: 3
Address: SKYPESFBFE03.CONTOSO.COM - Primary: 0 Secondary: 3
Address: SKYPESFBFE04.CONTOSO.COM - Primary: 0 Secondary: 3
Address: SKYPESFBFE05.CONTOSO.COM - Primary: 3 Secondary: 0
Address: SKYPESFBFE06.CONTOSO.COM - Primary: 0 Secondary: 3
Local Fabric Service:
Missing Primary : 0
Missing Both Secondary : 0
Missing One Secondary : 0
No Missing Replicas : 3
Total Count : 3
Pool Fabric Server and Services Summary:
Fqdn: SKYPESFBFE01.CONTOSO.COM - Health: Ok Status: Up [Seed Node] Primary: 0 Secondary: 3
Fqdn: SKYPESFBFE02.CONTOSO.COM - Health: Ok Status: Up [Seed Node] Primary: 0 Secondary: 3
Fqdn: SKYPESFBFE03.CONTOSO.COM - Health: Ok Status: Up [Seed Node] Primary: 0 Secondary: 3
Fqdn: SKYPESFBFE04.CONTOSO.COM - Health: Ok Status: Up [Seed Node] Primary: 0 Secondary: 3
Fqdn: SKYPESFBFE05.CONTOSO.COM - Health: Ok Status: Up [Seed Node] Primary: 3 Secondary: 0
Fqdn: SKYPESFBFE06.CONTOSO.COM - Health: Ok Status: Up [Seed Node] Primary: 0 Secondary: 3
Pool All Server and Services Summary:
Fqdn: SKYPESFBFE01.CONTOSO.COM Primary: 7 Secondary: 19
Fqdn: SKYPESFBFE02.CONTOSO.COM Primary: 7 Secondary: 17
Fqdn: SKYPESFBFE03.CONTOSO.COM Primary: 7 Secondary: 19
Fqdn: SKYPESFBFE04.CONTOSO.COM Primary: 8 Secondary: 18
Fqdn: SKYPESFBFE05.CONTOSO.COM Primary: 9 Secondary: 16
Fqdn: SKYPESFBFE06.CONTOSO.COM Primary: 7 Secondary: 1
PS C:\Windows\system32>
If this cmdlet shows any missing replicas, then run the following cmdlet to recover the pool before you apply any patches.
Reset-CsPoolRegistrarState -ResetType QuorumLossRecovery
2. On the first server you want to patch, run the following cmdlet:
Stop-CsWindowsService
3. Apply the upgrade or patch to this server. (run the Skype Cumulative Updater or apply windows patches if you are only applying Windows patches)
4. Once the patch has been completed reboot the server
5. Validate that all Skype Services have been started and that there are no issues in the Event Logs.
Repeat Steps 2-4 for each front end server that needs to be upgraded.
Expert Tip:
It should be stated that the guidance that Microsoft supplies recommends the use of the Invoke-CsComputerFailOver and Invoke-CsComputerFailBack cmdlets when patching front-end servers. These cmdlets take the specified front end server out of the pool for maintenance mode while you patch them and then add them back to the topology when you are done patching them.
I have found that using these cmdlets results in having to use the Reset-CsPoolRegistrarState -ResetType QuorumLossRecovery to recover from fabric issues. In general I find stopping the services and patching does not put the fabric in a state requiring the use of the Reset-CsPoolRegistrarState -ResetType QuorumLossRecovery cmdlet.
Please consider your options and proceed at your own discretion.
For Mediation, Directors and Edge Servers the process is more simplified since there isn’t a windows fabric you need to concern yourself with. Generally speaking, I would still recommend doing one server at a time for each of these server roles. If your environment is large and you have more than one person to assist you could divide these servers up to speed up the process. IE. Patch one mediation server and one director server at the same time.
1. On the first server you want to patch, run the following cmdlet:
Stop-CsWindowsService
2. Apply the upgrade or patch to this server. (run the Skype Cumulative Updater or apply windows patches if you are only applying Windows patches)
3. Once the patch has been completed reboot the server
4. Validate that all Skype Services have been started and that there are no issues in the Event Logs.
Repeat Steps 1-4 for each Mediation, Director or Edge Server that needs to be upgraded.
Once all servers have been patched we can patch the back end databases. This process assumes you have SQL Always On Availability Groups providing highly available backend database services to your Skype servers. The process varies slightly if you are not running Enterprise Edition or have SQL Mirroring installed. Please refer here for information on the process you should follow.
1. From any FE Server open an elevated PowerShell module and run the following cmdlets:
Stop-CsWindowsService
net stop w3svc
2. Ensure the Primary SQL Server is hosting all the backend SQL databases. Then run the following cmdlet. This cmdlet assumes that you also have Monitoring, Cdr and Archiving databases installed on the same SQL server. If not please refer here for further info. Below SQLAOAG.contoso.com represents the FQDN of your SQL Always ON Availability group.
Install-CsDatabase -Update -ConfiguredDatabases -SqlServerFqdn SQLAOAG.contoso.com.com -ExcludeCollocatedStores
3. To patch Monitoring, LCSCdr and Archiving databases use the following cmdlet
Install-CsDatabase -ConfiguredDatabases -SqlServerFqdn SQLAOAG.contoso.com.com -Verbose
4. To check that everything completed OK run the following cmdlet
Test-CsDatabase -ConfiguredDatabases -SqlServerFqdn SQLAOAG.contoso.com| Select-Object DatabaseName,Installed*,Expected*
a. Ensure the output shows Installed and Expected as the same
DatabaseName InstalledVersion ExpectedVersion
------------ ---------------- ---------------
rtcxds 15.13.10 15.13.10
rtcshared 5.0.1 5.0.1
rtcab 62.42.12 62.42.12
rgsconfig 5.5.1 5.5.1
rgsdyn 2.2.1 2.2.1
cpsdyn 1.1.2 1.1.2
LcsCDR 39.85.10 39.85.10
QoEMetrics 62.93.9 62.93.9
LcsLog 24.40.2 24.40.2
Posted at 09:12 AM | Permalink | Comments (0) | TrackBack (0)
Skype for Business allows you to add customer footers for your meetings which appears when users schedule their meetings in Outlook. The Skype or Lync client add-in DLLs control this behavior. The custom footer is useful for providing additional information specific to your organization.
In working with a customer that wanted to add both French and English text in the custom footer field we noticed that the non-English characters were not appearing properly in the meeting invites. I opened a ticket with Microsoft PSS and it was flagged as a client side bug.
Microsoft Released a new update KB3118281 for Lync 2013 / Skype for Business 2015 clients on September 6th. This KB has a fix for this issue specifically.
Posted at 10:57 AM | Permalink | Comments (2) | TrackBack (0)
After much searching you will find there isn’t much in the way of guidance provided on TechNet when migrating from Lync 2013 to Skype for Business Server as there is when migrating from Lync 2010 to Lync 2013. I was working on a Lync 2013 to Skype for Business Migration and wanted to make sure we didn’t forget anything when moving from a Lync 2013 Pool to a Skype for Business Pool. The following should help. Essentially the process is the same so refer to https://technet.microsoft.com/en-us/library/jj205369%28v=ocs.15%29.aspx?f=255&MSPPError=-2147217396 for more details.
This process assumes that your new pool is built and tested with pilot users. You have validated that all aspects and functionality are working as they should be including Edge server functionality. You have also cutover the required DNS records to support primary user sign on to this new pool as well as Public DNS records that support Skype for Business. It is best to dump all your DNS and SRV records and ensure you have not missed anything here. Again, the article above will provide guidance if you need it.
Don’t forget any topology changes with respect to your Edge servers communicating with your next hop front end servers. You likely need to make changes here. Lastly if you have deployed phones, you may have to make DHCP changes with respect to your certificate publishing. Guidance provided here.
Once you have addressed these prerequisites you can move on.
Step 1: Make a Copy
Export-CsRgsConfiguration -Source "service:ApplicationServer:LyncPool01.contoso.com" -FileName "D:\software\RGSExportCopy1.zip"
Step 2: Make a copy and then delete the source
Export-CsRgsConfiguration -Source "service:ApplicationServer:LyncPool01.contoso.com" -FileName "D:\software\RGSExportCopy2.zip" -RemoveExportedConfiguration
Step 3: Recreate the whole thing on new pool
Import-CsRgsConfiguration -Destination "service:ApplicationServer:SkypePool01.contoso.com" -FileName "D:\software\RGSExportCopy2.zip" -OverwriteOwner -ReplaceExistingRgsSettings
Get-CsCommonAreaPhone -Filter {RegistrarPool -eq "LyncPool01.contoso.com"} | Move-CsCommonAreaPhone -Target SkypePool01.contoso.com
Get-CsExUmContact -Filter {RegistrarPool -eq "LyncPool01.contoso.com"} | Move-CsExUmContact -Target SkypePool01.contoso.com
Get-CsDialInConferencingAccessNumber | where {$_.Pool -eq "LyncPool01.contoso.com"} | Move-CsApplicationEndpoint -TargetApplicationPool SkypePool01.contoso.com
Get-CsUser -Filter {RegistrarPool -eq "LyncPool01.contoso.com"} | Move-CsUser -Target SkypePool01.contoso.com
After you move users make sure they are not assigned to any Site Level Voice Policies in the old pool. If both your pools are in the same site you don’t have to worry about this. If you are moving between sites then you should create all the required voice policies on the new pool and then change this for any users using them. As an example, the following changes
get-CsUser -Filter {VoicePolicy -eq "Site1:InternationalCalling"} | Grant-CsVoicePolicy -PolicyName "Site2:InternationalCalling"
Get-CsConferenceDirectory | Where-Object {$_.ServiceID -match "LyncPool01.contoso.com"} | Move-CsConferenceDirectory -TargetPool "SkypePool01.contoso.com"
Assuming all your Lync Room Systems are on the old pool you can run the following to move them to the new pool
Get-CsMeetingRoom | Move-CsMeetingRoom -Target SkypePool01.contoso.com
Posted at 02:39 PM | Permalink | Comments (0) | TrackBack (0)
I have been working with a customer that uses Polycom RealConnect for Skype for Business (http://www.polycom.com/content-collaboration/content-sharing/realconnect.html) This is a fantastic technology which allows for a seamless integration of various video endpoints to one-click join Lync/Skype Meetings. We had originally setup the interoperability against a Lync 2013 Server Pool. After building out a new Skype for Business 2015 pool we wanted to move this interoperability (interop) to the new pool so we could upgrade the Lync 2013 pool and avoid any outages.
Technically speaking there is no way to simply move the interop between two Lync or Skype for Business Pools. The interop is based on the Skype UCMA Trusted Application model and moving trusted pools between pools is not something you can do in the product today. So you must effectively delete the interop and then recreate it on the new target pool. This will involve some very careful planning and a maintenance window or you will have unhappy users sitting in meeting rooms that won’t be able to join meetings
The focus of this article is what happens under the cover on the Microsoft Skype for Business side of the equation. To help illustrate what is going on I am providing the initial setup that was done.
The Polycom RealConnect interop will require the following configuration items in Lync/Skype:
So the following configuration had been done on the Lync 2013 Server side to initially get the integration working:
New-CsTrustedApplicationPool -Identity polycom.contoso.com -Registrar Registrar:Lyncpool01.contoso.com -site 2 –ComputerFqdn PolycomDMA01.contoso.com -ThrottleAsServer $true -TreatAsAuthenticated $true -RequiresReplication $false
New-CsTrustedApplicationComputer –Identity PolycomRMX01.com -Pool polycom.contoso.com
New-CsTrustedApplicationComputer –Identity PolycomRMX02.contoso.com -Pool polycom.contoso.com
Enable-CsTopology
New-CsTrustedApplication -ApplicationId dmaProxy -TrustedApplicationPoolFqdn polycom.contoso.com -port 5061
New-CsTrustedApplicationEndpoint -sipaddress sip:[email protected] -ApplicationId dmaProxy -TrustedApplicationPoolFqdn polycom.contoso.com
New-CsTrustedApplicationEndpoint -sipaddress sip:[email protected] -ApplicationId dmaProxy -TrustedApplicationPoolFqdn polycom.contoso.com
Get-CsTrustedApplication | fl ServiceGruu
The ServiceGRUU is then used on the Polycom side as well as the Lync pool name to complete the interop. (I don’t cover this in this here but perhaps that is another post!)
Now is the fun part. We are going to delete the interop and re-create on the new Skype for Business Pool! Once again, this will break the integration so please plan accordingly and do this during a maintenance window.
#Remove Endpoints
Remove-CsTrustedApplicationEndpoint -Identity sip:[email protected]
Remove-CsTrustedApplicationEndpoint -Identity sip:[email protected]
#Remove the Trusted Application
Remove-CsTrustedApplication polycom.contoso.com/urn:application:dmaproxy
#Remove Computers
Remove-CsTrustedApplicationComputer -Identity Polycomdma01.contoso.com
Remove-CsTrustedApplicationComputer -Identity Polycomrmx01.contoso.com
Remove-CsTrustedApplicationComputer -Identity Polycomrmx02.contoso.com
#Remove Pool
Remove-CsTrustedApplicationPool TrustedApplicationPool:polycom.contoso.com
# New Trusted Pool at LDC
New-CsTrustedApplicationPool -Identity polycom.contoso.com -Registrar Registrar:SFBpool01.contoso.com -site 3 -ComputerFqdn PolycomDMA01.contoso.com -ThrottleAsServer $true -TreatAsAuthenticated $true -RequiresReplication $false
# New Trusted App Computers
New-CsTrustedApplicationComputer -Identity PolycomDMA01.contoso.com -Pool polycom.contoso.com
New-CsTrustedApplicationComputer –Identity PolycomRMX01.contoso.com -Pool polycom.contoso.com
New-CsTrustedApplicationComputer -Identity PolycomRMX02.contoso.com -Pool polycom.contoso.com
Enable-CsTopology
#Create New Trusted Application
New-CsTrustedApplication -ApplicationId dmaProxy -TrustedApplicationPoolFqdn polycom.contoso.com -port 5061
#Create New Trusted Endpoints
New-CsTrustedApplicationEndpoint -sipaddress sip:[email protected] -ApplicationId dmaProxy -TrustedApplicationPoolFqdn polycom.contoso.com
New-CsTrustedApplicationEndpoint -sipaddress sip:[email protected] -ApplicationId dmaProxy -TrustedApplicationPoolFqdn polycom.contoso.com
New-CsTrustedApplicationEndpoint -sipaddress sip:[email protected] -ApplicationId dmaProxy -TrustedApplicationPoolFqdn polycom.contoso.com
#GRUU for Polycom
Get-CsTrustedApplication | fl ServiceGruu
The new GRUU is given the to Polycom team and is used along with the new Skype pool name to setup the integration from the Polycom RealConnect side.
Posted at 10:59 AM | Permalink | Comments (0) | TrackBack (0)