diff --git a/windows/deployment/update/waas-wufb-group-policy.md b/windows/deployment/update/waas-wufb-group-policy.md index 8707f69961..fc80d55002 100644 --- a/windows/deployment/update/waas-wufb-group-policy.md +++ b/windows/deployment/update/waas-wufb-group-policy.md @@ -68,7 +68,7 @@ Drivers are automatically enabled because they are beneficial to device systems. #### I want to receive pre-release versions of the next feature update 1. Ensure that you are enrolled in the Windows Insider Program for Business. This is a completely free program available to commercial customers to aid them in their validation of feature updates before they are released. Joining the program enables you to receive updates prior to their release as well as receive emails and content related to what is coming in the next updates. -2. Use Group Policy Management Console to go to: C**omputer Configuration > Administrative Templates > Windows Components > Windows Update > Windows Update for Business > Manage preview builds** and set the policy to **Enable preview builds** for any of test devices you want to install pre-release builds. +2. Use Group Policy Management Console to go to: **Computer Configuration > Administrative Templates > Windows Components > Windows Update > Windows Update for Business > Manage preview builds** and set the policy to **Enable preview builds** for any of test devices you want to install pre-release builds. 3. Use Group Policy Management Console to go to **Computer Configuration > Administrative Templates > Windows Components > Windows Update > Windows Update for Business > Select when Preview Builds and Feature Updates are received**. In the **Options** pane, use the pulldown menu to select one of the preview builds. We recomment **Windows Insider Program Slow** for commercial customers using pre-release builds for validation. 4. Select **OK**. diff --git a/windows/security/identity-protection/hello-for-business/hello-cert-trust-adfs.md b/windows/security/identity-protection/hello-for-business/hello-cert-trust-adfs.md index d4c919784d..4486823bc5 100644 --- a/windows/security/identity-protection/hello-for-business/hello-cert-trust-adfs.md +++ b/windows/security/identity-protection/hello-for-business/hello-cert-trust-adfs.md @@ -145,6 +145,9 @@ Windows Server 2012 or later domain controllers support Group Managed Service Ac GMSA uses the Microsoft Key Distribution Service that is located on Windows Server 2012 or later domain controllers. Windows uses the Microsoft Key Distribution Service to protect secrets stored and used by the GMSA. Before you can create a GMSA, you must first create a root key for the service. You can skip this if your environment already uses GMSA. +>[!NOTE] +> If the [default object creation quota for security principles](https://docs.microsoft.com/openspecs/windows_protocols/ms-adts/d55ca655-109b-4175-902a-3e9d60833012) is set, you will need to change it for the Group Managed Service Account in order to be able to register new devices. + #### Create KDS Root Key Sign-in a domain controller with _Enterprise Admin_ equivalent credentials. diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-dir-sync.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-dir-sync.md index 7576402a17..efeaaacd05 100644 --- a/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-dir-sync.md +++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-dir-sync.md @@ -65,6 +65,9 @@ Sign-in a domain controller or management workstation with _Domain Admin_ equiva > [!NOTE] > If your AD forest has multiple domains, make sure you add the ADConnect sync service account (ie. MSOL_12121212) into "Enterprise Key Admins" group to gain permission across the domains in the forest. +> [!NOTE] +> Transfer the PDC emulator FSMO role to a domain controller running Windows Server 2016 (or later) to be able to search the Key Admins and Enterprise Key Admins groups (domain controllers running previous versions of Windows Server cannot translate the security identifier to a name for these groups). + ### Section Review > [!div class="checklist"] diff --git a/windows/security/identity-protection/hello-for-business/hello-planning-guide.md b/windows/security/identity-protection/hello-for-business/hello-planning-guide.md index 1f28723cc9..ea3430b5dd 100644 --- a/windows/security/identity-protection/hello-for-business/hello-planning-guide.md +++ b/windows/security/identity-protection/hello-for-business/hello-planning-guide.md @@ -168,16 +168,13 @@ Choose the deployment model based on the resources your users access. Use the f If your organization does not have on-premises resources, write **Cloud Only** in box **1a** on your planning worksheet. -If your organization is federated with Azure or uses any online service, such as Office365 or OneDrive, or your users' access cloud and on-premises resources, write **Hybrid** in box **1a** on your planning worksheet. +If your organization is federated with Azure or uses any service, such as AD Connect, Office365 or OneDrive, or your users access cloud and on-premises resources, write **Hybrid** in box **1a** on your planning worksheet. If your organization does not have cloud resources, write **On-Premises** in box **1a** on your planning worksheet. > [!NOTE] -> If you're unsure if your organization is federated, run the following Active Directory Windows PowerShell command from an elevated Windows PowerShell prompt and evaluate the results. -> ```Get-AdObject "CN=62a0ff2e-97b9-4513-943f-0d221bd30080,CN=Device Registration Configuration,CN=Services,CN=Configuration,DC=corp,DC=[forest_root_CN_name],DC=com" -Properties keywords``` -> * If the command returns an error stating it could not find the object, then you have yet to configured AAD Connect or on-premises Device Registration Services using AD FS. Ensure the name is accurate and validate the object does not exist with another Active Directory Management tool such as **ADSIEdit.msc**. If the object truly does not exist, then your environment does not bind you to a specific deployment or require changes to accommodate the desired deployment type. -> * If the command returns a value, compare that value with the values below. The value indicates the deployment model you should implement -> * If the value begins with **azureADName:** – write **Hybrid** in box **1a**on your planning worksheet. -> * If the value begins with **enterpriseDrsName:** – write **On-Premises** in box **1a** on your planning worksheet. +> * Main use case of On-Premises deployment is for "Enhanced Security Administrative Environments" also known as "Red Forests". +> * Migration from on-premise to hybrid deployment will require redeployment. + ### Trust type diff --git a/windows/security/information-protection/bitlocker/bitlocker-how-to-enable-network-unlock.md b/windows/security/information-protection/bitlocker/bitlocker-how-to-enable-network-unlock.md index f537134414..5c7b1190b1 100644 --- a/windows/security/information-protection/bitlocker/bitlocker-how-to-enable-network-unlock.md +++ b/windows/security/information-protection/bitlocker/bitlocker-how-to-enable-network-unlock.md @@ -313,7 +313,7 @@ To turn off the unlock server, the PXE provider can be unregistered from the WDS To update the certificates used by Network Unlock, administrators need to import or generate the new certificate for the server and then update the Network Unlock certificate Group Policy setting on the domain controller. > [!NOTE] -> Machines that do not get the GPO will ask for the PIN when booting. In this case one needs to investigate and understand why the machine could not get the GPO and update the certificate. +> Servers that do not receive the Group Policy Object (GPO) will require a PIN when booting. In such cases, the reason why the server did not receive the GPO to update the certificate needs to be investigated. ## Troubleshoot Network Unlock