Lokasi ngalangkungan proxy:   [ UP ]  
[Ngawartoskeun bug]   [Panyetelan cookie]                
Skip to content

Commit 57fac7c

Browse files
authored
Merge pull request #17906 from WilliamDAssafMSFT/patch-1
SQL BDC minor typos
2 parents 95bca34 + 7da7fd4 commit 57fac7c

1 file changed

Lines changed: 6 additions & 6 deletions

File tree

docs/big-data-cluster/active-directory-deployment-background.md

Lines changed: 6 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -15,9 +15,9 @@ ms.technology: big-data-cluster
1515

1616
[!INCLUDE[SQL Server 2019](../includes/applies-to-version/sqlserver2019.md)]
1717

18-
This article explains the updates to SQL server 2019 CU 5 that enable de capability for multiple SQL Server 2019 Big Data Clusters to be deployed and integrated with the same Active Directory Domain.
18+
This article explains the updates to SQL Server 2019 CU5 that enables the capability for multiple SQL Server 2019 Big Data Clusters to be deployed and integrated with the same Active Directory Domain.
1919

20-
Prior to CU5 there were two issues preventing deployment of multiple BDCs in an AD domain.
20+
Prior to SQL 2019 CU5 there were two issues preventing deployment of multiple BDCs in an AD domain.
2121

2222
- Naming conflict for service principal names and DNS domain
2323
- Domain account principal names
@@ -30,11 +30,11 @@ The domain name provided at deployment time is used as AD DNS domain. This means
3030

3131
### Domain account principal names
3232

33-
During a deployment of BDC with an Active Directory domain, multiple account principals are generated for services running inside the BDC. These are essentially AD user accounts. Prior to CU5 the names for these account would not be unique between clusters. This manifests in an attempt to create the same user account name for a particular service in BDC in two different clusters. The cluster that is being deployed second will run into a conflict in AD and cannot create their account.
33+
During a deployment of BDC with an Active Directory domain, multiple account principals are generated for services running inside the BDC. These are essentially AD user accounts. Prior to SQL 2019 CU5 the names for these account would not be unique between clusters. This manifests in an attempt to create the same user account name for a particular service in BDC in two different clusters. The cluster that is being deployed second will run into a conflict in AD and cannot create their account.
3434

3535
## Resolution for collisions
3636

37-
### Solution to solve the problem with SPNs and DNS domain - CU5
37+
### Solution to solve the problem with SPNs and DNS domain - SQL 2019 CU5
3838

3939
Since SPNs must differ in any two clusters, the DNS domain name passed in at deployment time must be different. You can specify different DNS names using the newly introduced setting in the deployment configuration file: `subdomain`. If the subdomain differs between two clusters and internal communication can happen over this subdomain, the SPNs will include the subdomain achieving the required uniqueness.
4040

@@ -58,7 +58,7 @@ The subdomain only applies to DNS. Hence the new LDAP user account name is `bdc-
5858

5959
## Semantics
6060

61-
In summary, these are the semantics of the parameters added in CU5 for multiple clusters in a domain:
61+
In summary, these are the semantics of the parameters added in SQL 2019 CU5 for multiple clusters in a domain:
6262

6363
### `subdomain`
6464

@@ -133,7 +133,7 @@ Below is an example of endpoint spec for control plane endpoints. You can use an
133133

134134
It is not required, but is recommended. Providing separate OUs for separate clusters helps you manage the generated user accounts.
135135

136-
### How to revert back to the pre-CU5 behavior?
136+
### How to revert back to the pre-CU5 behavior in SQL 2019?
137137

138138
There might be scenarios where you can't accommodate the newly introduced `subdomain` parameter. For example you must deploy a pre-CU5 release and you already upgraded [!INCLUDE [azure-data-cli-azdata](../includes/azure-data-cli-azdata.md)]. This is highly unlikely, but if you need to revert to the pre-CU5 behavior you can set `useSubdomain` parameter to `false` in the active directory section of `control.json`.
139139

0 commit comments

Comments
 (0)