You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/active-directory/hybrid/how-to-connect-install-prerequisites.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -57,7 +57,7 @@ Before you install Azure AD Connect, there are a few things that you need.
57
57
* If you plan to use the feature **password synchronization**, then the Azure AD Connect server must be on Windows Server 2008 R2 SP1 or later.
58
58
* If you plan to use a **group managed service account**, then the Azure AD Connect server must be on Windows Server 2012 or later.
59
59
* The Azure AD Connect server must have [.NET Framework 4.5.1](#component-prerequisites) or later and [Microsoft PowerShell 3.0](#component-prerequisites) or later installed.
60
-
* The Azure AD Connect server must not have PowerShell Transcription Group Policy enabled.
60
+
* The Azure AD Connect server must not have PowerShell Transcription Group Policy enabled if you are using Azure AD Connect wizard to manage ADFS configuration. You can enable PowerShell transcription if you are using Azure AD Connect wizard to manage sync configuration.
61
61
* If Active Directory Federation Services is being deployed, the servers where AD FS or Web Application Proxy are installed must be Windows Server 2012 R2 or later. [Windows remote management](#windows-remote-management) must be enabled on these servers for remote installation.
62
62
* If Active Directory Federation Services is being deployed, you need [SSL Certificates](#ssl-certificate-requirements).
63
63
* If Active Directory Federation Services is being deployed, then you need to configure [name resolution](#name-resolution-for-federation-servers).
description: Learn how to scale an Azure SignalR Service instance to add or reduce capacity, through Azure portal or Azure CLI.
4
+
author: sffamily
5
+
ms.service: signalr
6
+
ms.topic: conceptual
7
+
ms.date: 11/21/2019
8
+
ms.author: zhshang
9
+
---
10
+
# How to scale an Azure SignalR Service instance?
11
+
This article shows you how to scale your instance of Azure SignalR Service. There are two scenarios for scaling, scale up and scale out.
12
+
13
+
*[Scale up](https://en.wikipedia.org/wiki/Scalability#Horizontal_and_vertical_scaling): Get more units, connections, messages, and more. You scale up by changing the pricing tier from Free to Standard.
14
+
*[Scale out](https://en.wikipedia.org/wiki/Scalability#Horizontal_and_vertical_scaling): Increase the number of SignalR units. You can scale out to as many as 100 units.
15
+
16
+
The scale settings take a few minutes to apply. They don't require you to change your code or redeploy your server application.
17
+
18
+
For information about the pricing and capacities of individual SignalR Service, see [Azure SignalR Service Pricing Details](https://azure.microsoft.com/pricing/details/signalr-service/).
19
+
20
+
> [!NOTE]
21
+
> Changing SignalR Service from **Free** tier to **Standard** tier or vice versa, the public service IP will be changed and it usually takes 3-60 minutes to propagate the change to DNS servers across the entire internet.
22
+
> Your service might be unreachable before DNS gets updated. Generally it’s not recommended to change your pricing tier too often.
23
+
24
+
25
+
## Scale on Azure portal
26
+
27
+
1. In your browser, open the [Azure portal](https://portal.azure.com).
28
+
29
+
2. In your SignalR Service page, from the left menu, select **Scale**.
30
+
31
+
3. Choose your pricing tier, and then click **Select**. You need to set the unit count for **Standard** Tier.
32
+
33
+

34
+
35
+
4. Click **Save**.
36
+
37
+
## Scale using Azure CLI
38
+
39
+
This script creates a new SignalR Service resource of **Free** Tier and a new resource group, and scale it up to **Standard** Tier.
40
+
41
+
```azurecli-interactive
42
+
#!/bin/bash
43
+
44
+
# Generate a unique suffix for the service name
45
+
let randomNum=$RANDOM*$RANDOM
46
+
47
+
# Generate a unique service and group name with the suffix
48
+
SignalRName=SignalRTestSvc$randomNum
49
+
#resource name must be lowercase
50
+
mySignalRSvcName=${SignalRName,,}
51
+
myResourceGroupName=$SignalRName"Group"
52
+
53
+
# Create resource group
54
+
az group create --name $myResourceGroupName --location eastus
55
+
56
+
# Create the Azure SignalR Service resource
57
+
az signalr create \
58
+
--name $mySignalRSvcName \
59
+
--resource-group $myResourceGroupName \
60
+
--sku Free_F1 \
61
+
--service-mode Default
62
+
63
+
# Scale up to Standard Tier, and scale out to 50 units
64
+
az signalr update \
65
+
--name $mySignalRSvcName \
66
+
--resource-group $myResourceGroupName \
67
+
--sku Standard_S1 \
68
+
--unit-count 50
69
+
```
70
+
71
+
Make a note of the actual name generated for the new resource group. You will use that resource group name when you want to delete all group resources.
For detailed information, such as included messages and connections for each pricing tier, see [SignalR Service Pricing Details](https://azure.microsoft.com/pricing/details/signalr-service/).
78
+
79
+
For a table of service limits, quotas, and constraints in each tier, see [SignalR Service limits](../azure-subscription-service-limits.md#azure-signalr-service-limits).
80
+
81
+
## Next steps
82
+
83
+
In this guide, you learned about how to scale single SignalR Service instance.
84
+
85
+
Multiple endpoints are also supported for scaling, sharding and cross-region scenarios.
86
+
87
+
> [!div class="nextstepaction"]
88
+
> [scale SignalR Service with multiple instances](./signalr-howto-scale-multi-instances.md)
Copy file name to clipboardExpand all lines: articles/backup/backup-azure-sql-database.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -45,15 +45,15 @@ Before you start, verify the below:
45
45
* SQL Server backup can be configured in the Azure portal or **PowerShell**. We do not support CLI.
46
46
* The solution is supported on both kinds of [deployments](https://docs.microsoft.com/azure/azure-resource-manager/resource-manager-deployment-model) - Azure Resource Manager VMs and classic VMs.
47
47
* VM running SQL Server requires internet connectivity to access Azure public IP addresses.
48
-
* SQL Server **Failover Cluster Instance (FCI)**and SQL Server Always on Failover Cluster Instance are not supported.
48
+
* SQL Server **Failover Cluster Instance (FCI)**is not supported.
49
49
* Back up and restore operations for mirror databases and database snapshots aren't supported.
50
50
* Using more than one backup solutions to back up your standalone SQL Server instance or SQL Always on availability group may lead to backup failure; refrain from doing so.
51
51
* Backing up two nodes of an availability group individually with same or different solutions, may also lead to backup failure.
52
52
* Azure Backup supports only Full and Copy-only Full backup types for **Read-only** databases
53
53
* Databases with large number of files can't be protected. The maximum number of files that is supported is **~1000**.
54
54
* You can back up to **~2000** SQL Server databases in a vault. You can create multiple vaults in case you have a greater number of databases.
55
55
* You can configure backup for up to **50** databases in one go; this restriction helps optimize backup loads.
56
-
* We support databases up to **2 TB** in size; for sizes greater than that, performance issues may come up.
56
+
* We support databases up to **2 TB** in size; for sizes greater than that performance issues may come up.
57
57
* To have a sense of as to how many databases can be protected per server, we need to consider factors such as bandwidth, VM size, backup frequency, database size, etc. [Download](https://download.microsoft.com/download/A/B/5/AB5D86F0-DCB7-4DC3-9872-6155C96DE500/SQL%20Server%20in%20Azure%20VM%20Backup%20Scale%20Calculator.xlsx) the resource planner that gives the approximate number of databases you can have per server based on the VM resources and the backup policy.
58
58
* In case of availability groups, backups are taken from the different nodes based on a few factors. The backup behavior for an availability group is summarized below.
When attaching a database, specify the **default principals modification kind"**. The default is keeping the leader database collection of [authorized principals](/azure/kusto/management/access-control/index#authorization)
249
+
When attaching a database, specify the **"default principals modification kind"**. The default is keeping the leader database collection of [authorized principals](/azure/kusto/management/access-control/index#authorization)
241
250
242
251
|**Kind**|**Description**|
243
252
|---------|---------|
244
253
|**Union**| The attached database principals will always include the original database principals plus additional new principals added to the follower database. |
245
-
|**Replace**| No inheritance of principals from the original database. New principals must be created for the attached database. At least one principal needs to be added to block principal inheritance. |
254
+
|**Replace**| No inheritance of principals from the original database. New principals must be created for the attached database. |
246
255
|**None**| The attached database principals include only the principals of the original database with no additional principals. |
247
256
248
257
For more information about using control commands to configure the authorized principals, see [Control commands for managing a follower cluster](/azure/kusto/management/cluster-follower).
0 commit comments