itp29 - servicing the existing deployment and upgrading to skype for business server_v04

Servicing the existing deployment & upgrading to Skype for Business ServerSpeaker NameSpeaker Title

Upgrading to Skype for Business Server 2015In-place upgradesUpgrade paths

SQL Server improvementsSQL AlwaysOn support

Server managementPatchingCold pool start

Agenda

Upgrading to Skype for Business Server 2015In-place upgrade overview

What is it?Upgrade from Lync Server 2013 to Skype for Business Server using existing hardware

BenefitsPreserving existing hardware/server investmentsSmoother upgrade process without extensive planningReducing the overall cost for deploymentThe goal of heading towards Smart Setup

In-place upgrade

Migrate-users mode (no user downtime)Offline mode

Upgrade path

Original topology

New topology

In-place upgrade supported ? Priority

2013 Skype for Business Server + 2013

Yes. In-place upgrade support from 2013 → Skype for Business Server

P0

2010 Skype for Business Server + 2010

No. Migrate from 2010 → Skype for Business Server, same as 2010 → 2013

P1

2013 + 2010 Skype for Business Server + 2013

Mandatory migration from 2010 → 2013 before deploying Skype for Business ServerThen in-place upgrade from 2013 to Skype for Business Server

P1

Upgrade path(move users): Case 1Upgrade from Lync 2013 to Skype for Business Server

Move Pool1 users

Upgrade to Skype for Business Server

Move back Pool1 users

Move Pool2 users

Upgrade to Skype for Business

Server

Move back Pool2 users

Test functionality

Pool1 (Lync 2013 CU5)



Pool1 (Skype for Business 2015)






Bring up a new Skype for Business Server Pool

Decommission Pool1

Move users from Pool1 to Pool3

Upgrade path(move users): Case 2Upgrade from Lync 2010 to Skype for Business Server

Pool1 (Lync 2010)

Pool2 (Lync 2010)

Pool3 (Skype for Business)

Pool1 (Lync 2010)

Pool2 (Lync 2010)


Pool1 (Lync 2010)

Pool2 (Lync 2010)


Move users from Pool1 to Pool3

Decommission Pool1

Move Pool3 users

Move backPool3 users

Upgrade path(move users): Case 3 Upgrade from Lync 2010 + Lync 2013 to Skype for Business Server


Pool1 (Lync 2010)



Pool1 (Lync 2010)





Send maintenance notice to users on Pool1


Make sure features are working


Send maintenance notice to users on Pool2

Upgrade path(offline mode): Case 4Upgrade from Lync 2013 to Skype for Business Server

Send email to users that services are upand running

Pool1(Lync 2013 CU5)







RecommendationsNo in-place upgrade with Disaster Recovery (pool failover)Please don’t use the Invoke-CsPoolFailover cmdlets to failover the pool!

Don’t start services in mixed mode

Don’t un-pair the pools before upgrade

Ensure minimal time when the pools are paired with different versions

Upgrade path

Upgrade order(Inside→outside)

User pools first

Shared components like: Mediation Server, Director EdgesCMS pool

Role upgrade (2013 to Skype for Business Server 2015)Pools/Roles Requires

upgrade to Skype for Business Server

How to upgrade?

FE pool Yes Topology building + seamless in-place upgrade setup

Director pool Yes Topology building + seamless in-place upgrade setup

Mediation pool Yes Topology building + seamless in-place upgrade setup

Persistent chat pool Yes Topology building + seamless in-place upgrade setup

Edge pool Yes Topology building + seamless in-place upgrade setup

Trusted application pool Yes Topology building + seamless in-place upgrade setup

Survivable Branch Server (SBS)

Yes Topology building + seamless in-place upgrade setup

Survivable Branch Server (SBA)

No Not supporting in-place upgrade of SBAs

SQL Server store Yes Topology building (The store is marked as Skype for Business along with the pool and is upgraded running Install-CsDatabase while the pool gets upgraded)

File store No n/a

PSTN gateway No n/a

Trunk No n/a

Office Web Apps Server No n/a

In-place upgradeSeamlessly upgrades SQL Express 2012 to SQL Express 2014

Also upgrades all the local copies of the database

SQL support with Lync / Skype for Business Server

In-place upgradeCustomer experience

STEP

1STEP

2STEP

3STEP

4STEP

5

Upgrade processInstall prerequisites

Upgrade, publish topology, and upgrade databases using Topology Builder

Stop the services on all the servers in the pool to be upgraded

Run Setup.exe which will launch in-place upgrade UI

Start services on all the servers in the upgraded pool at the same time (use the Start-CSPool cmdlet)

Upgrade processSTEP

1STEP

2STEP

3STEP

4STEP

5

Install prerequisites




Start services on all the servers in the upgraded pool at the same-time (use the Start-CSPool cmdlet)

Always install prerequisites!

Install CU5+ latest hotfix to Lync 2013 topology

PowerShell RTM version (6.2.9200.0) or later

Have at least SQL server 2012 SP1 installed

Kb2533623 Windows Server 2008 R2

Kb2858668 Windows Server 2012

KB2982006 Windows Server 2012 R2

Upgrade steps: step 1

http://support.microsoft.com/kb/2533623

http://support.microsoft.com/kb/2858668

Upgrade processSTEP

1STEP

2STEP

3STEP

4STEP

5






Upgrade steps: step 2 (Upgrade and publish topology using Topology Builder)

Upgrade steps: step 2 (Upgrade and publish topology using Topology Builder)

Topology Builder should automatically upgrade your databases for you!

Upgrade processSTEP

1STEP

2STEP

3STEP

4STEP

5



Stop the services on all the servers in the pool to be upgraded(Stop-CsWindowsService)



Upgrade processSTEP

1STEP

2STEP

3STEP

4STEP

5




Run Setup.exe which will launch in-place upgrade UI (use elevated/administrator command prompt)


Upgrade processSTEP

1STEP

2STEP

3STEP

4STEP

5






Allows Skype for Business Server server updates to be installed as part of Skype for Business Server server setup process from Microsoft Updates

Setup will include an option toCheck with Microsoft Updates for Skype for Business Server updatesDownload the updatesInstall them (prior to finishing the installation process)

Move towards—Smart Setup

Note: This doesn’t replace the Skype For Business Server server update installer. That will still be useful for our customers who don’t have connection to access the internet

SQL AlwaysOnOverview

SQL Server AlwaysOn HA solutionsNext generation of database mirroring technologies Provides high availability and disaster recovery in SQLIntroduced in SQL Server 2012 and present in SQL Server 2014 Runs on top of WSFC (Windows Server Failover Clustering)

Overview

Latest and greatest SQL HA solutionAlthough database mirroring is still available in its original feature set, it is now considered a deprecated feature and will be removed in a future release of SQL Server

More reliableAlwaysOn (one primary, can have up to three corresponding secondary replicas)Mirroring (one primary, one mirror)

Multi-database failoversUseful in applications with several databasesDatabases can be added to an Availability Group that can be failed over between replicasAll databases in Availability Group are failed over at the same time

AlwaysOn advantages

Provides high availability by maximizing availability of databases for an enterprise

An Availability Group is a set of databases that are failed over together at the same time

Supports one primary replica and up to two secondary replicas in synchronous-commit mode

Availability Group listener responds/redirects incoming client requests to replicas

Each Availability Group replica has local SQL instance and local copy of databases

AlwaysOn Availability Groups

Provides high availability through redundancy at the server-instance level

One SQL instance is installed across all failover clustering nodes

Single copy of databases are located on shared disk storage which is failed over between nodes

AlwaysOn Failover Cluster Instance (FCI)

SQL AlwaysOnPlanning

New install scenarioInstall new backend using SQL Enterprise 2012 or SQL Enterprise 2014Add new Skype for Business Server pool with AlwaysOn back-end to topologyInstall Skype for Business Server and add databases to Availability Group

Upgrade scenarioUpgrade an existing Lync Server 2013 pool to Skype for Business ServerUpgrade back-end server to SQL Enterprise 2012 or SQL Enterprise 2014Enable SQL AlwaysOn for Skype for Business Server databases

Planning for AlwaysOn

Standalone ServerStandard or Enterprise Edition

AlwaysOn Failover Clustering Instance (FCI)Standard or Enterprise Edition (two nodes)Enterprise Edition (three or more nodes)

MirroringStandard or Enterprise Edition

AlwaysOn Availability GroupsEnterprise Edition required

SQL version requirements

Supported with Skype for Business ServerAvailability groups are not supported with Lync Server 2010 or 2013

AlwaysOn support information

Standalone

Failover Clustering

Mirroring Availability Groups

Lync Server 2010 SQL 2008 R2 SP2

SQL 2008 R2 SP2

Not supported Not supported

Lync Server 2013 SQL 2008 R2 SP2

SQL 2012 SP1

SQL 2008 R2 SP2

SQL 2012 SP1

SQL 2008 R2 SP2

SQL 2012 SP1

Not supported

Skype for Business Server

SQL 2008 R2 SP2

SQL 2012 SP1SQL 2014

SQL 2008 R2 SP2


SQL 2008 R2 SP2



Supported configurations* for Skype for Business ServerSupport having replicas only in the same subnetSupport only the Synchronous-Commit ModeSupport the Automatic Failover ModeNo support for read access on secondary replicasNo support for having an off-site replica in Azure

Supported Availability Group settings

* Other configurations are possible and not actively blocked, but not supported

Supported only for Skype for Business Server poolsIn-place upgrade from SQL 2012 SP1 standalone to SQL 2014 Availability Groups

In-place upgrade from SQL 2012 SP1 mirroring to SQL 2014 Availability Groups

All other in-place upgrade scenarios for SQL Servers are currently unsupported

Full database backup prior to in-place upgrade is recommended

SQL in-place upgrade support

Change compatibility level for each database after upgradeSelect SQL Server 2014 (120)

Set using Transact-SQL (optional)

ALTER DATABASE cpsdynSET COMPATIBILITY_LEVEL = 120;GO

SQL AlwaysOnPrerequisites and dependencies

Windows Server 2008 R2 SP1 or higher

WSFC feature installed, with sufficient nodes for desired configuration Select the File Share Witness option for the quorum witness

Cluster nodes cannot be Active Directory domain controllers

Cluster nodes must be from the same Active Directory domain

Cluster nodes must be connected to the same network subnet

Windows Server Failover Clustering (WSFC)

SQL Server 2012 SP1/2014 Enterprise Edition or higher

SQL installation steps are different depending on HA option selected

SQL AlwaysOn must be manually enabled on SQL service and restarted

Full recovery model required for each Availability Group database

Full backup required for each database added to Availability Group

Database folder structure must be duplicated across all AG replicas

SQL Server and database requirements

High availability option

Installation selection

Availability Groups (AG) New SQL Server stand-alone installation (all replicas)

Failover Cluster Instance (FCI) New SQL Server failover cluster installation (first node)

Add node to a SQL Server failover cluster (additional nodes)

ManagementPatching process

ObservationsMany steps

Based on upgrade domains

Check for readiness of upgrade domain, stop services, patch and

move unto next upgrade domain

Multiple decision points

“Wait and try” suggestions

Lync 2013 patching

Complex patching process with many steps; deviations from the process might result in downtime for users

Ready state-to-start patching not always reliable

Could run into unable to start front-end servers after patching

Some users are signed in with limited functionality and sign-in performance issues

Problems are hard to troubleshoot and solve—particularly for larger pools

Understand upgrade domain/other fabric concepts

2013 patching and reliability challenges

Icon: Bjorn Andersson, Noun Project

Not enough safe guards to prevent servers from being taken down without harm

Load balancing continues between decision point and execution (no heads up to fabric)

Idle secondary bug in winfab v1 CU1

Incorrect use of some cmdlets might make problems worse

What made 2013 solution problematic?

Server managementPatching

Lync 2013 Skype for Business

Simplified workflow leverages Windows Fabric v2 APIs

4 steps:Invoke-CsComputerFailOver to failover (stop) a front end; take the FE out of rotation, move the replicas out

Perform patching/upgrade

Invoke-CsComputerFailBack to failback (start) a front end; bring FE into active state, move replicas in

Do this for all front ends in the pool

Skype for Business Server patching

Checks for availability of sufficient number of servers

Waits for replica stability across the poolConfirm all replicas exists before taking server down

Initiate deactivation of the node; wait for success/failure from windows fabric

Stops services after successfully deactivating the node

Invoke-CsComputerFailOver

Start services if not already started

Activate node—windows fabric will now consider this server for replica placement

Invoke-CsComputerFailBack

Simpler workflow, fewer commands, less errorsFaster: 2–3 hrs. for 12 FE pool (down from 8–12 hrs.)More reliableChecks for readiness across the pool within the cmdlet before failoverLeverages windows fabric v2 deactivate/activate node APIs ensuring more dependable operation (moving replicas in/out, not move replicas into node going down)Since scope is always one frontend, avoids situations where multiple front ends could be down within a pool (reason servers don’t start)Will not allow fail over of a server if there are existing replica issues in the poolEnforces min server requirements implicitly (if other servers are down)

Progress indicators

How is this better?

Invoke-CsComputerFailOver progress indicator

Invoke-CsComputerFailBack progress indicator

How is this better?

Prerequisite: Skype for Business Server, Fabric version 2.0 CU3+

Don’t execute on more than one server at a time in a pool (it might block)

Invoke-CsComputerFailOver requires RTCSRV service to be running

Invoke-CsComputerFailBack will start RTCSRV service

Stopping services outside of this cmdlet out-of-scope

Notes

Server managementPool cold start

2013 to Skype for Business in-place upgrade

Adding a new pool

Pool fail back starts a pool if it was offline

Miscellaneous cases where administrator decides to take down the entire pool for a maintenance activity (not recommended in 2013)

Pool cold start scenarios

Typically, all the servers need to be started for one server to be up

Confusing “minimum number of servers” requirements

Starting a subset of a pool is not straightforward since it involves running RG quorum loss recovery

Incomplete information on why a server cannot be started

No automatic recovery actions initiated for failures

Lync 2013/pool cold start problems

Start the servers within a pool with a single command with easy to follow instructions

Allow pool to start even if some of the routing group replicas are stuck

For problems encountered that might cause issues during pool/server cold start, alert with resolution steps

Skype for Business Server pool start

Prerequisite checks (all servers Skype for Business Server, WinFab 2.0+)

Attempts to start all the servers in the poolIf problems starting any server; perform extended diagnosis; alertIf problem on front end cannot be fixed, run Start-CsPool with exclusion listFail if min server requirements cannot be met due to exclusion listDoes this operation require quorum loss recoveryIf no data loss, perform implicit quorum loss recoveryIf there will be data lossSeek admin approval with data loss information (or)Configure option to skip specific routing group replicas and proceed with start

Start all servers if no issues

Start-CsPool

Upgrading to Skype for Business Server 2015In-place upgradesUpgrade paths

SQL Server improvementsSQL AlwaysOn support

Server managementPatchingCold pool start

Summary

Appendix Slides

Installing the WSFC feature

Validating the cluster configuration

Creating the cluster

Configuring Quorum settings

Enabling SQL AlwaysOn

Changing the recovery model for each database

Performing a full SQL backup for each database

Duplicating the database folder structure on replicas

SQL AlwaysOnDeployment and configuration

Deploying AlwaysOn for new poolsCreating a new SQL AlwaysOn Availability Group for a new pool

Deploying AlwaysOn for existing poolsMoving from SQL standalone backend to AlwaysOn Availability GroupsMoving from SQL mirrored backend to AlwaysOn Availability Groups

AlwaysOn deployment options

Deployment optionsNew pools

Creating a new AlwaysOn Availability Group

Creating a new Availability Group for a new pool can be somewhat confusingCreating a new SQL back-end Availability Group requires at least one databaseDatabases for a new pool cannot be created until a SQL backend is available


Step 1: Add new SQL Store using the FQDN of the Availability Group ListenerIn Topology Builder, select the option New Front End PoolWhen prompted to define the SQL Server store, click NewAdd the FQDN of the Availability Group Listener as the SQL Server FQDNSelect High Availability Settings, and choose SQL AlwaysOn Availability GroupsAdd the FQDN of the SQL primary replica as the FQDN for the SQL Server AlwaysOn InstanceComplete the configuration of the new pool and publish the topology

Step 2: Enable AlwaysOn Availability Groups

Step 3: Create a new AlwaysOn Availability Group for the back-end databases

Step 4: Update the settings for the SQL Store and publish the topology


Creating a new AlwaysOn SQL Store

Availability Group Listener FQDN

Primary Replica FQDN

Note: Databases will be created on the Primary Replica when the topology is published

Step 1: Add new SQL Store using the FQDN of the Availability Group Listener

Step 2: Enable AlwaysOn Availability GroupsAdd the Windows Server Failover Clustering (WSFC) feature on each replica serverValidate the cluster configurationCreate a new Windows Failover ClusterConfigure cluster quorum settingsEnable AlwaysOn Availability Groups






Step 3: Create a new AlwaysOn Availability Group for the back-end databasesSet the recovery model for each database to FullPerform a SQL backup of each databaseDuplicate the database folder structure on each replica server Create the new Availability Group and add the back-end databases



Creating a new Availability Group




Step 4: Update the settings for the SQL Store and publish the topologyIn Topology Builder, open the properties of the Availability Group SQL StoreUnder High Availability Settings, change the FQDN for the SQL Server AlwaysOn instance value to the FQDN of the Availability Group ListenerPublish the topology


Modifying the AlwaysOn SQL Store



Deployment optionsExisting pools

Moving from SQL standalone

to AlwaysOn Availability Groups

Step 1: Install additional SQL Servers to be used as secondary replicasMust be on the same subnet as primary replicaUse same SQL version as primary replica (must be Enterprise Edition)Use same SQL instance as primary replica


Step 3: Create AlwaysOn Availability Group for the existing back-end databases


Step 5: Associate the pool with the new SQL Store and publish the topology


Moving from SQL standalone to Availability Groups

Step 1: Install additional SQL Servers to be used as secondary replicas

Step 2: Enable AlwaysOn Availability GroupsAdd the Windows Server Failover Clustering (WSFC) feature on each replica serverValidate the cluster configurationCreate a new Windows failover clusterConfigure cluster quorum settingsEnable AlwaysOn Availability Groups








Step 3: Create AlwaysOn Availability Group for the existing back-end databasesSet the recovery model for each database to FullPerform a SQL backup of each databaseDuplicate the database folder structure on each replica server Create the new Availability Group and add the back-end databases








Step 4: Add new SQL Store using the FQDN of the Availability Group ListenerIn Topology Builder, select the option New SQL Server StoreAdd the FQDN of the Availability Group Listener as the SQL Server FQDNSelect High Availability Settings, and choose SQL AlwaysOn Availability GroupsAdd the FQDN of the SQL standalone server as the FQDN for the SQL Server AlwaysOn Instance








Step 5: Associate the pool with the new SQL Store and publish the topologyChange the SQL Server store association for the pool to the new AlwaysOn SQL StorePublish the topology, selecting the option to create databases



Changing the SQL Server Store association

Select the Availability Group Listener FQDN






Step 6: Update the settings for the SQL Store and publish the topologyIn Topology Builder, open the properties of the Availability Group SQL StoreUnder High Availability Settings, change the FQDN for the SQL Server AlwaysOn Instance value to the FQDN of the Availability Group ListenerPublish the topology


Deployment optionsExisting pools

Moving from SQL mirroring to AlwaysOn Availability Groups

Step 1: Failover all databases to the Primary SQL serverUse Get-CsDatabaseMirrorState to find the Principal server for each databaseNote if the StateOnMirror value is Principal for any back-end databaseUse Invoke-CsDatabaseFailover –NewPrincipal Primary to failover databases

Step 2: Uninstall each database type and drop databases on Mirror server

Step 3: Disable database mirroring and publish the topology






Moving from SQL mirroring to Availability Groups

Step 1: Failover all databases to the Primary SQL server

Step 2: Uninstall each database type and drop databases on Mirror serverRun Uninstall-CsMirrorDatabase –DropExistingDatabasesOnMirror for each database typeRun Get-CsDatabaseMirrorState and verify that the StateOnMirror value is DatabaseUnavailable for all previously mirrored databasesUsing SQL Management Studio, connect to the Mirror server and manually delete any database that could not be dropped by the Uninstall-CsMirrorDatabase cmdlet










Step 3: Disable database mirroring and publish the topologyIn Topology Builder, open the properties of the poolDeselect the Enable SQL Server store mirroring option Publish the topology










Step 4: Enable AlwaysOn Availability GroupsAdd the Windows Server Failover Clustering (WSFC) feature on each replica serverValidate the cluster configurationCreate a new Windows failover clusterConfigure cluster quorum settingsEnable AlwaysOn Availability Groups










Step 5: Create AlwaysOn Availability Group for the existing back-end databasesSet the recovery model for each database to FullPerform a SQL backup of each databaseDuplicate the database folder structure on each replica server Create the new Availability Group and add the back-end databases










Step 6: Add new SQL Store using the FQDN of the Availability Group ListenerIn Topology Builder, select the option New SQL Server StoreAdd the FQDN of the Availability Group Listener as the SQL Server FQDNSelect High Availability Settings, and choose SQL AlwaysOn Availability GroupsAdd the FQDN of the SQL primary server as the FQDN for the SQL Server AlwaysOn Instance










Step 7: Associate the pool with the new SQL Store and publish the topologyChange the SQL Server store association for the pool to the new AlwaysOn SQL StorePublish the topology, selecting the option to create databases










Step 8: Update the settings for the SQL Store and publish the topologyIn Topology Builder, open the properties of the Availability Group SQL StoreUnder High Availability Settings, change the FQDN for the SQL Server AlwaysOn Instance value to the FQDN of the Availability Group ListenerPublish the topology


SQL always onKnown issues

Clients go into resiliency mode after failing over Availability Group to secondary replica

Issue 1

Reason: The Availability Group wizard does not replicate the SQL logins from the primary node to each of the defined secondary replicasWorkaround steps:1. Launch Topology Builder and download topology2. Change the SQL machine FQDN value to the AG

Listener FQDN3. Publish the topology and wait for CMS replication to occur4. Use Cluster Manager to failover the AG Listener cluster

resource to one of the replica servers5. Run Install-CsDatabase –Update (which creates the missing

SQL logins on the replica server)6. Repeat steps 4–5 for each additional replica server

Note: If you want to create a new database you will need to repoint the SQL Machine FQDN to the Primary Node in the Availability Group

RTC Universal Groups are missing

Unable to move from SQL mirroring to AlwaysOn Availability Groups due to location of CMS database

Issue 2

Reason: If the CMS database is homed on or paired with the pool where you are attempting to move to AlwaysOn Availability Groups, you will be unable to change the HA model for the backend database

Workaround steps:If the pool is not paired, use the Move-CsManagementServer cmdlet to move the CMS database to another pool.If the pool is paired and the CMS is not homed locally on the pool where you are attempting to change the backend HA model:• Disable pool pairing and uninstall the CMS database• Change the HA model from SQL mirroring to Availability Groups• Reinstall the CMS database and re-enable pool pairing• Add the CMS databases to the Availability GroupIf the pool is paired and the CMS is homed on locally on the pool where you are attempting to change the backend HA model:• Use Invoke-CsManagementServerFailover cmdlet to failover the CMS

database• Disable pool pairing and uninstall the CMS database• Change the HA model from SQL mirroring to Availability Groups• Reinstall the CMS database and re-enable pool pairing• Add the CMS databases to the Availability Group

Creating an Availability Group with only a single replica

Issue 3Reason: For test environments, you may want to create an Availability Group with only a single replica. If you attempt to use SQL Management Studio to do this, you will be blocked as it requires a minimum of two replicas. However, you can use PowerShell to work around this limitation

Workaround steps:1. Use the powershell cmdlets to set this up# Create an in-memory representation of the primary replica$primaryReplica = New-SqlAvailabilityReplica -Name "lab2-sql5\Instance1" -EndpointURL "TCP://lab2-sql5.contoso.com:5022" -AvailabilityMode "SynchronousCommit" -FailoverMode "Automatic" -Version 12 -AsTemplate

# Create the Availability GroupNew-SqlAvailabilityGroup -Name "MyAG" -Path "SQLSERVER:\SQL\lab2-sql5\Instance1" -AvailabilityReplica @($primaryReplica) -Database "cpsdyn"

# Add additional database to the Availability GroupAdd-SqlAvailabilityDatabase -Path "SQLSERVER:\SQL\lab2-sql5\Instance1\AvailabilityGroups\MyAG" -Database "rgsconfig"Add-SqlAvailabilityDatabase -Path "SQLSERVER:\SQL\lab2-sql5\Instance1\AvailabilityGroups\MyAG" -Database "rgsdyn"Add-SqlAvailabilityDatabase -Path "SQLSERVER:\SQL\lab2-sql5\Instance1\AvailabilityGroups\MyAG" -Database "rtcab"Add-SqlAvailabilityDatabase -Path "SQLSERVER:\SQL\lab2-sql5\Instance1\AvailabilityGroups\MyAG" -Database "rtcshared"Add-SqlAvailabilityDatabase -Path "SQLSERVER:\SQL\lab2-sql5\Instance1\AvailabilityGroups\MyAG" -Database "rtcxds"

# Add Availability Group Listener (note port number - you will get an error if default SQL port 1433 is already in use)New-SqlAvailabilityGroupListener -Name lab2-sqlclu1 -StaticIp '192.168.0.209/255.255.252.0' -Path "SQLSERVER:\SQL\lab2-sql5\Instance1\AvailabilityGroups\MyAG“ -Port 1431

Unable to create AlwaysOn Availability Group Listener due to connection failure

Issue 4

Reason: For named instances, SQL Server listens for connections on a dynamic TCP port. Some admins may wish to configure SQL to listen on either the default port (TCP/1433) or use a SQL alias to configure SQL to listen on a non-default static port (e.g., 1499). If you configure your SQL Servers to listen on the default port, you will encounter an error when attempting to create the Availability Group listener for SQL AlwaysOn due to a port conflictWorkaround steps:1. Use a SQL alias to configure SQL to listen on a non-

default static port (e.g.,1499) if default SQL port 1433 is already in use (http://technet.microsoft.com/en-us/library/dn776290.aspx)

2. Verify that exceptions have been added in Windows Firewall for the port used by the Availability Group Listener

http://technet.microsoft.com/en-us/library/dn776290.aspx

itp29 - servicing the existing deployment and upgrading to skype for business server_v04

Documents