Servicing the

existing
deployment
& upgrading to
Skype for Business
Speaker Name
Server
Speaker Title

Agenda
Upgrading to Skype for Business Server
2015
In-place upgrades
Upgrade paths

SQL Server improvements

SQL AlwaysOn support

Server management
Patching
Cold pool start

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

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

Benefits
Preserving existing hardware/server investments
Smoother upgrade process without extensive planning
Reducing the overall cost for deployment
The goal of heading towards Smart Setup

Upgrade path
Migrate-users mode (no user downtime)
Offline mode
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 Server
Then in-place upgrade from 2013 to Skype for
Business Server

P1

Upgrade
path
(move
users):

Move Pool1 users

Pool1
(Lync 2013
CU5) Upgrade to Skype for
Business Server

Case 1
Upgrade from
Lync 2013 to
Skype for Business
Server

Pool2
(Lync 2013
CU5)

Pool3
(Lync 2013
CU5)

Pool2
(Lync 2013
CU5)
Upgrade to Skype
for Business
Server

Pool3
(Lync 2013
CU5)

Pool2
(Skype for
Business
2015)

Pool3
(Lync 2013
CU5)

Move back Pool1

users

Test
functionality

Pool1
(Skype for
Business
2015)

Move Pool2 users

Move back Pool2

users

Pool1
(Skype for
Business
2015)

Upgrade
path
(move
users):

Pool1
(Lync 2010)

Pool2
(Lync 2010)

Pool3
(Skype for
Business)

Pool2
(Lync 2010)

Pool3
(Skype for
Business)

Pool2
(Lync 2010)

Pool3
(Skype for
Business)

Case 2
Upgrade from
Lync 2010 to
Skype for Business
Server

Pool1
(Lync 2010)

Move users
from Pool1
to Pool3

Decommission Pool1

Pool1
(Lync 2010)

Bring up
a new
Skype for
Business
Server Pool

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

Move users
from Pool1
to Pool3

Pool1
(Lync 2010)

Pool3
(Lync 2013
CU5)

Pool2
(Lync 2013
CU5)

Decommission
Pool1

Move Pool3
users

Pool1
(Lync 2010)

Pool3
(Lync 2013
CU5)

Pool2
(Lync 2013
CU5)

Upgrade
to Skype for
Business
Server
Move back
Pool3 users

Pool2
(Lync 2013
CU5)

Pool3
(Skype for
Business)

Upgrade
path
(offline
mode):

Send
maintenanc
e
notice to
users
on Pool1

Case 4
Upgrade from
Lync 2013 to
Skype for Business
Server

Pool1
(Lync 2013
CU5) Upgrade to
Skype for
Business Server

Pool2
(Lync 2013
CU5)

Pool1
(Skype for
Business)

Pool2
(Lync 2013
CU5)

Make sure
features
are
working

Send email
to users that
services are
up
and running

Send
maintenance
notice to users
on Pool2
Pool1
(Skype for
Business)

Pool2
(Skype2013
(Lync
for
Business)
CU5)

Upgrade to
Skype for
Business
Server

Upgrade path
Recommendations

Upgrade order

No in-place upgrade with

Disaster Recovery (pool failover)

(Insideoutside)

Please dont use the Invoke-CsPoolFailover

cmdlets to failover the pool!

Dont start services in mixed

mode
Dont un-pair the pools before
upgrade
Ensure minimal time when the
pools are paired with different
versions

User pools first

Shared components like:
Mediation Server, Director
Edges
CMS pool

Role upgrade (2013 to Skype for Business

Pools/Roles
Requires
How to upgrade?
Server 2015)
upgrade to
Skype for
Business Server

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

SQL support with Lync / Skype for Business

Server
In-place upgrade
Seamlessly upgrades SQL
Express 2012 to SQL Express
2014
Also upgrades all the local
copies
of the database

In-place upgrade
Customer experience

Upgrade process
STEP

STEP

STEP

STEP

STEP

Install 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 process
STEP

STEP

STEP

STEP

STEP

Install 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 steps: step 1

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 process
STEP

STEP

STEP

STEP

STEP

Install 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 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 process
STEP

STEP

STEP

STEP

STEP

Install prerequisites
Upgrade, publish topology, and upgrade databases using Topology
Builder
Stop the services on all the servers in the pool to be upgraded
(Stop-CsWindowsService)
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 process
STEP

STEP

STEP

STEP

STEP

Install 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
(use elevated/administrator command prompt)
Start services on all the servers in the upgraded pool
at the same-time (use the Start-CSPool cmdlet)

Upgrade process
STEP

STEP

STEP

STEP

STEP

Install 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)

Move towardsSmart Setup

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 to
Check with Microsoft Updates for Skype for Business Server
updates
Download the updates
Note:
doesnt
replace
Skype Forthe
Business
Server server
update installer. That will
InstallThis
them
(prior
tothe
finishing
installation
process)
still be useful for our customers who dont have connection to access the internet

SQL AlwaysOn
Overview

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

AlwaysOn advantages
Latest and greatest SQL HA solution
Although 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 reliable
AlwaysOn (one primary, can have up to three corresponding secondary replicas)
Mirroring (one primary, one mirror)

Multi-database failovers
Useful in applications with several databases
Databases can be added to an Availability Group that can be failed over
between replicas
All databases in Availability Group are failed over at the same time

AlwaysOn Availability Groups

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 synchronouscommit mode
Availability Group listener
responds/redirects incoming client

AlwaysOn Failover Cluster

Instance
(FCI)through
Provides high availability
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

SQL AlwaysOn
Planning

Planning for AlwaysOn

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

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

SQL version requirements

Standalone Server
Standard or Enterprise Edition

AlwaysOn Failover Clustering Instance (FCI)

Standard or Enterprise Edition (two nodes)
Enterprise Edition (three or more nodes)

Mirroring
Standard or Enterprise Edition

AlwaysOn Availability Groups

Enterprise Edition required

AlwaysOn support
information
Supported with Skype for Business
Server

Standalon
Mirroring
Availability
Availability groups are
not supported Failover
with Lync Server
2010 or 2013
e

Clustering

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 SP1
SQL 2014

SQL 2008 R2
SP2
SQL 2012 SP1
SQL 2014

SQL 2008 R2
SP2
SQL 2012 SP1
SQL 2014

SQL 2012 SP1

SQL 2014

Supported Availability Group

settings
Supported configurations for Skype for Business
*

Server
Support having replicas only in the same subnet
Support only the Synchronous-Commit Mode
Support the Automatic Failover Mode
No support for read access on secondary replicas
No support for having an off-site replica in Azure

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

SQL in-place upgrade support

Supported only for Skype
for Business Server pools
In-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

Change compatibility level

for each database after
upgrade
Select SQL Server 2014 (120)
Set using Transact-SQL (optional)

ALTER DATABASE cpsdyn

SET COMPATIBILITY_LEVEL = 120;
GO

SQL AlwaysOn
Prerequisites and dependencies

Windows Server Failover Clustering

(WSFC)
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

SQL Server and database requirements

SQL Server 2012 SP1/2014 Enterprise Edition or higher
SQL installation steps are different depending on HA option
selected
High
availability
Installation selection

option
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)

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

Management
Patching process

Lync 2013 patching

Observations
Many 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

2013 patching and reliability challenges

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
solveparticularly for larger pools

Icon: Bjorn Andersson, Noun Project

What made 2013 solution

problematic?

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

Server management
Patching

Lync 2013

Skype for
Business

Skype for Business Server

patching
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

Invoke-CsComputerFailOver
Checks for availability of sufficient number
of servers
Waits for replica stability across the pool
Confirm 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-CsComputerFailBack
Start services if not already started
Activate nodewindows fabric will now
consider this server for replica
placement

How is this better?

Simpler workflow, fewer commands, less errors
Faster: 23 hrs. for 12 FE pool (down from 812
hrs.)
More reliable
Checks for readiness across the pool within the cmdlet before failover
Leverages 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 dont start)
Will not allow fail over of a server if there are existing replica issues in the pool
Enforces min server requirements implicitly (if other servers are down)

How is this better?

Invoke-CsComputerFailOver progress
indicator

Invoke-CsComputerFailBack progress
indicator

Notes
Prerequisite: Skype for Business Server, Fabric version 2.0
CU3+
Dont 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

Server management
Pool cold start

Pool cold start scenarios

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)

Lync 2013/pool cold start

problems
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

Skype for Business Server

pool
start
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

Start-CsPool
Prerequisite checks (all servers Skype for Business
Server, WinFab 2.0+)
Attempts to start all the servers in the pool
If problems starting any server; perform extended diagnosis; alert
If problem on front end cannot be fixed, run Start-CsPool with exclusion list
Fail if min server requirements cannot be met due to exclusion list
Does this operation require quorum loss recovery
If no data loss, perform implicit quorum loss recovery
If there will be data loss
Seek 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

Summary
Upgrading to Skype for Business Server 2015
In-place upgrades
Upgrade paths

SQL Server improvements

SQL AlwaysOn support

Server management
Patching
Cold pool start

Q&A

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 AlwaysOn
Deployment and configuration

AlwaysOn deployment
options

Deploying AlwaysOn for new pools

Creating a new SQL AlwaysOn Availability Group for a new pool

Deploying AlwaysOn for existing pools

Moving from SQL standalone backend to AlwaysOn Availability Groups
Moving from SQL mirrored backend to AlwaysOn Availability Groups

Deployment
New pools
options

Creating a new AlwaysOn

Availability Group

Creating a new AlwaysOn

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

Creating a new AlwaysOn

Availability Group
Step 1: Add new SQL Store using the FQDN of the Availability
Group Listener
In Topology Builder, select the option New Front End Pool
When prompted to define the SQL Server store, click New
Add the FQDN of the Availability Group Listener as the SQL Server FQDN
Select High Availability Settings, and choose SQL AlwaysOn Availability Groups
Add the FQDN of the SQL primary replica as the FQDN for the SQL Server AlwaysOn
Instance
Complete 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

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

Creating a new AlwaysOn

Availability Group
Step 1: Add new SQL Store using the FQDN of the Availability
Group Listener
Step 2: Enable AlwaysOn Availability Groups
Add the Windows Server Failover Clustering (WSFC) feature on each replica server
Validate the cluster configuration
Create a new Windows Failover Cluster
Configure cluster quorum settings
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

Availability Group
Step 1: Add new SQL Store using the FQDN of the Availability Group
Listener
Step 2: Enable AlwaysOn Availability Groups
Step 3: Create a new AlwaysOn Availability Group for the back-end
databases
Set the recovery model for each database to Full
Perform a SQL backup of each database
Duplicate the database folder structure on each replica server
Create the new Availability Group and add the back-end databases

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

Creating a new Availability

Group

Creating a new Availability

Group

Creating a new AlwaysOn

Availability Group
Step 1: Add new SQL Store using the FQDN of the Availability
Group Listener
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
In Topology Builder, open the properties of the Availability Group SQL Store
Under High Availability Settings, change the FQDN for the SQL Server AlwaysOn instance
value
to the FQDN of the Availability Group Listener
Publish the topology

Modifying the AlwaysOn SQL

Store
Availability Group Listener
FQDN

Availability Group Listener

FQDN

Deployment
Existing pools
options

Moving from SQL standalone

to AlwaysOn Availability
Groups

Moving from SQL standalone to Availability

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

Step 2: Enable AlwaysOn Availability Groups

Step 3: Create AlwaysOn Availability Group for the existing backend databases
Step 4: Add new SQL Store using the FQDN of the Availability
Group Listener
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 Groups
Add the Windows Server Failover Clustering (WSFC) feature on each replica server
Validate the cluster configuration
Create a new Windows failover cluster
Configure cluster quorum settings
Enable AlwaysOn Availability Groups

Step 3: Create AlwaysOn Availability Group for the existing backend databases
Step 4: Add new SQL Store using the FQDN of the Availability
Group Listener

Moving from SQL standalone to Availability

Groups
Step 1: Install additional SQL Servers to be used as secondary
replicas
Step 2: Enable AlwaysOn Availability Groups
Step 3: Create AlwaysOn Availability Group for the existing back-end
databases
Set the recovery model for each database to Full
Perform a SQL backup of each database
Duplicate 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
Listener
Step 5: Associate the pool with the new SQL Store and publish the

Moving from SQL standalone to Availability

Groups
Step 1: Install additional SQL Servers to be used as secondary
replicas
Step 2: Enable AlwaysOn Availability Groups
Step 3: Create AlwaysOn Availability Group for the existing backend databases
Step 4: Add new SQL Store using the FQDN of the Availability Group
Listener
In Topology Builder, select the option New SQL Server Store
Add the FQDN of the Availability Group Listener as the SQL Server FQDN
Select High Availability Settings, and choose SQL AlwaysOn Availability Groups
Add the FQDN of the SQL standalone server as the FQDN for the SQL Server AlwaysOn
Instance

Moving from SQL standalone to Availability

Groups
Step 1: Install additional SQL Servers to be used as secondary
replicas
Step 2: Enable AlwaysOn Availability Groups
Step 3: Create AlwaysOn Availability Group for the existing backend databases
Step 4: Add new SQL Store using the FQDN of the Availability
Group Listener
Step 5: Associate the pool with the new SQL Store and publish the
topology
Change the SQL Server store association for the pool to the new AlwaysOn SQL Store
Publish the topology, selecting the option to create databases

Changing the SQL Server Store

association
Select the Availability Group Listener
FQDN

Moving from SQL standalone to Availability

Groups
Step 1: Install additional SQL Servers to be used as secondary
replicas
Step 2: Enable AlwaysOn Availability Groups
Step 3: Create AlwaysOn Availability Group for the existing backend databases
Step 4: Add new SQL Store using the FQDN of the Availability
Group Listener
Step 5: Associate the pool with the new SQL Store and publish the
topology
Step 6: Update the settings for the SQL Store and publish the

Deployment
Existing pools
options

Moving from SQL mirroring

to AlwaysOn Availability
Groups

Moving from SQL mirroring to Availability

Groups
Step 1: Failover all databases to the Primary SQL server
Use Get-CsDatabaseMirrorState to find the Principal server for each database
Note if the StateOnMirror value is Principal for any back-end database
Use 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
Step 4: Enable AlwaysOn Availability Groups
Step 5: Create AlwaysOn Availability Group for the existing backend databases
Step 6: Add new SQL Store using the FQDN of the Availability
Group Listener

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
server
Run Uninstall-CsMirrorDatabase DropExistingDatabasesOnMirror for each database type
Run Get-CsDatabaseMirrorState and verify that the StateOnMirror value is
DatabaseUnavailable for
all previously mirrored databases
Using 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 topology

Step 4: Enable AlwaysOn Availability Groups
Step 5: Create AlwaysOn Availability Group for the existing backend databases
Step 6: Add new SQL Store using the FQDN of the Availability

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
server
Step 3: Disable database mirroring and publish the topology
In Topology Builder, open the properties of the pool
Deselect the Enable SQL Server store mirroring option
Publish the topology

Step 4: Enable AlwaysOn Availability Groups

Step 5: Create AlwaysOn Availability Group for the existing backend databases
Step 6: Add new SQL Store using the FQDN of the Availability
Group Listener

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
server
Step 3: Disable database mirroring and publish the topology
Step 4: Enable AlwaysOn Availability Groups
Add the Windows Server Failover Clustering (WSFC) feature on each replica server
Validate the cluster configuration
Create a new Windows failover cluster
Configure cluster quorum settings
Enable AlwaysOn Availability Groups

Step 5: Create AlwaysOn Availability Group for the existing backend databases
Step 6: Add new SQL Store using the FQDN of the Availability
Group Listener

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
server
Step 3: Disable database mirroring and publish the topology
Step 4: Enable AlwaysOn Availability Groups
Step 5: Create AlwaysOn Availability Group for the existing back-end
databases
Set the recovery model for each database to Full
Perform a SQL backup of each database
Duplicate 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
Listener

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
server
Step 3: Disable database mirroring and publish the topology
Step 4: Enable AlwaysOn Availability Groups
Step 5: Create AlwaysOn Availability Group for the existing backend databases
Step 6: Add new SQL Store using the FQDN of the Availability Group
Listener
In Topology Builder, select the option New SQL Server Store
Add the FQDN of the Availability Group Listener as the SQL Server FQDN
Select High Availability Settings, and choose SQL AlwaysOn Availability Groups
Add the FQDN of the SQL primary server as the FQDN for the SQL Server AlwaysOn
Instance

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
server
Step 3: Disable database mirroring and publish the topology
Step 4: Enable AlwaysOn Availability Groups
Step 5: Create AlwaysOn Availability Group for the existing backend databases
Step 6: Add new SQL Store using the FQDN of the Availability
Group Listener
Step 7: Associate the pool with the new SQL Store 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
server
Step 3: Disable database mirroring and publish the topology
Step 4: Enable AlwaysOn Availability Groups
Step 5: Create AlwaysOn Availability Group for the existing backend databases
Step 6: Add new SQL Store using the FQDN of the Availability
Group Listener
Step 7: Associate the pool with the new SQL Store and publish the
topology
Step 8: Update the settings for the SQL Store and publish the

SQL always on
Known issues

Issue 1
Clients go into resiliency mode after
failing
over Availability
Group
to not
secondary
Reason:
The Availability Group
wizard does
replicate the
SQL logins from the primary node to each of the defined
replicareplicas
secondary
Workaround steps:
1. Launch Topology Builder and download topology
2. Change the SQL machine FQDN value to the AG
ListenerFQDN
3. Publish the topologyand wait for CMS replication to occur
4. Use Cluster Manager to failover the AG Listener cluster
resource to one of the replica servers
5. Run Install-CsDatabase Update(which creates the missing
SQL logins on the replica server)
6. Repeat steps 45 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

Issue 2
Unable to move from SQL mirroring to AlwaysOn
Availability Groups due to location of CMS database
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 Group
If 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

Issue 3
Creating an Availability Group with only a single replica
Reason: 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 Group

New-SqlAvailabilityGroup -Name "MyAG" -Path "SQLSERVER:\SQL\lab2-sql5\Instance1" -AvailabilityReplica @($primaryReplica)
-Database "cpsdyn"

# Add additional database to the Availability Group

Add-SqlAvailabilityDatabase -Path "SQLSERVER:\SQL\lab2-sql5\Instance1\AvailabilityGroups\MyAG"
Add-SqlAvailabilityDatabase -Path "SQLSERVER:\SQL\lab2-sql5\Instance1\AvailabilityGroups\MyAG"
Add-SqlAvailabilityDatabase -Path "SQLSERVER:\SQL\lab2-sql5\Instance1\AvailabilityGroups\MyAG"
Add-SqlAvailabilityDatabase -Path "SQLSERVER:\SQL\lab2-sql5\Instance1\AvailabilityGroups\MyAG"
Add-SqlAvailabilityDatabase -Path "SQLSERVER:\SQL\lab2-sql5\Instance1\AvailabilityGroups\MyAG"

-Database
-Database
-Database
-Database
-Database

"rgsconfig"
"rgsdyn"
"rtcab"
"rtcshared"
"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\lab2sql5\Instance1
\AvailabilityGroups\MyAG -Port 1431

Issue 4
Unable to create AlwaysOn Availability Group Listener
due to connection failure
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 conflict steps:
Workaround
1. Use a SQL alias to configure SQL to listen on a nondefault 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

 2015 Microsoft Corporation. All rights reserved.