Improved consistency in the articles

windows/client-management/mdm/policy-csp-kerberos.md

@@ -14,7 +14,6 @@ manager: dansimp
 
 # Policy CSP - Kerberos
 
-
 <hr/>
 
 <!--Policies-->
@@ -54,7 +53,6 @@ manager: dansimp
 > 
 > The payload of the SyncML must be XML-encoded; for this XML encoding, there are a variety of online encoders that you can use. To avoid encoding the payload, you can use CDATA if your MDM supports it.  For more information, see [CDATA Sections](http://www.w3.org/TR/REC-xml/#sec-cdata-sect).
 
-
 <hr/>
 
 <!--Policy-->
@@ -140,8 +138,8 @@ This policy allows retrieving the cloud Kerberos ticket during the sign in.
 
 <!--SupportedValues-->
 Valid values:  
-0 (default) - Disabled. 
+0 (default) - Disabled
-1 - Enabled. 
+1 - Enabled
 
 <!--/SupportedValues-->
 
@@ -184,7 +182,7 @@ ADMX Info:
 
 <!--/Scope-->
 <!--Description-->
-This policy setting controls whether a device will request claims and compound authentication for Dynamic Access Control and Kerberos armoring using Kerberos authentication with domains that support these features. 
+This policy setting controls whether a device will request claims and compound authentication for Dynamic Access Control and Kerberos armoring, using Kerberos authentication with domains that support these features. 
 If you enable this policy setting, the client computers will request claims, provide information required to create compounded authentication and armor Kerberos messages in domains that support claims and compound authentication for Dynamic Access Control and Kerberos armoring.
 
 If you disable or don't configure this policy setting, the client devices won't request claims, provide information required to create compounded authentication and armor Kerberos messages. Services hosted on the device won't be able to retrieve claims for clients using Kerberos protocol transition.
@@ -285,9 +283,10 @@ ADMX Info:
 
 <!--/Scope-->
 <!--Description-->
-This policy setting controls whether a computer requires that Kerberos message exchanges be armored when communicating with a domain controller.
+This policy setting controls whether a computer requires that Kerberos message exchanges being armored when communicating with a domain controller.
 
-Warning: When a domain doesn't support Kerberos armoring by enabling "Support Dynamic Access Control and Kerberos armoring", then all authentication for all its users will fail from computers with this policy setting enabled.
+> [!WARNING]
+> When a domain doesn't support Kerberos armoring by enabling "Support Dynamic Access Control and Kerberos armoring", then all authentication for all its users will fail from computers with this policy setting enabled.
 
 If you enable this policy setting, the client computers in the domain enforce the use of Kerberos armoring in only authentication service (AS) and ticket-granting service (TGS) message exchanges with the domain controllers. 
 
@@ -341,7 +340,7 @@ This policy setting controls the Kerberos client's behavior in validating the KD
 
 If you enable this policy setting, the Kerberos client requires that the KDC's X.509 certificate contains the KDC key purpose object identifier in the Extended Key Usage (EKU) extensions, and that the KDC's X.509 certificate contains a dNSName subjectAltName (SAN) extension that matches the DNS name of the domain. If the computer is joined to a domain, the Kerberos client requires that the KDC's X.509 certificate must be signed by a Certificate Authority (CA) in the NTAuth store. If the computer isn't joined to a domain, the Kerberos client allows the root CA certificate on the smart card to be used in the path validation of the KDC's X.509 certificate.
 
-If you disable or don't configure this policy setting, the Kerberos client requires only that the KDC certificate contain the Server Authentication purpose object identifier in the EKU extensions that can be issued to any server.
+If you disable or don't configure this policy setting, the Kerberos client requires only the KDC certificate that contains the Server Authentication purpose object identifier in the EKU extensions that can be issued to any server.
 
 <!--/Description-->
 
@@ -393,7 +392,7 @@ If you enable this policy setting, the Kerberos client or server uses the config
 If you disable or don't configure this policy setting, the Kerberos client or server uses the locally configured value or the default value. 
 
 > [!NOTE]
-> This policy setting configures the existing MaxTokenSize registry value in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters, which was added in Windows XP and Windows Server 2003, with a default value of 12,000 bytes. Beginning with Windows 8 the default is 48,000 bytes. Due to HTTP's base64 encoding of authentication context tokens, it's not advised to set this value more than 48,000 bytes.
+> This policy setting configures the existing MaxTokenSize registry value in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters, which was added in Windows XP and Windows Server 2003, with a default value of 12,000 bytes. Beginning with Windows 8, the default is 48,000 bytes. Due to HTTP's base64 encoding of authentication context tokens, it's not advised to set this value more than 48,000 bytes.
 
 <!--/Description-->
 
@@ -436,9 +435,9 @@ ADMX Info:
 
 <!--/Scope-->
 <!--Description-->
-Adds a list of domains that an Azure Active Directory joined device can attempt to contact when it can't resolve a UPN to a principal.
+Adds a list of domains that an Azure Active Directory joined device can attempt to contact, when it can't resolve a UPN to a principal.
 
-Devices joined to Azure Active Directory in a hybrid environment need to interact with Active Directory Domain Controllers, but they lack the built-in ability to find a Domain Controller that a domain-joined device has. This limitation can cause failures when such a device needs to resolve an Azure Active Directory UPN into an Active Directory Principal. You can use this policy to avoid those failures.
+Devices joined to Azure Active Directory in a hybrid environment need to interact with Active Directory Domain Controllers, but they lack the built-in ability to find a Domain Controller that a domain-joined device has. This limitation can cause failures, when such a device needs to resolve an Azure Active Directory UPN into an Active Directory Principal. You can use this policy to avoid those failures.
 
 <!--/Description-->
 <!--SupportedValues-->
@@ -455,3 +454,6 @@ Devices joined to Azure Active Directory in a hybrid environment need to interac
 
 <!--/Policies-->
 
+## Related topics
+
+[Policy configuration service provider](policy-configuration-service-provider.md)

windows/client-management/mdm/policy-csp-kioskbrowser.md

@@ -14,8 +14,6 @@ manager: dansimp
 
 # Policy CSP - KioskBrowser
 
-
-
 These policies currently only apply to Kiosk Browser app. Kiosk Browser is a Microsoft Store app, added in Windows 10 version 1803, that provides IT a way to customize the end user's browsing experience to fulfill kiosk, signage, and shared device scenarios. Application developers can also create their own kiosk browser and read these policies using [NamedPolicy.GetPolicyFromPath(String, String) Method](/uwp/api/windows.management.policies.namedpolicy.getpolicyfrompath#Windows_Management_Policies_NamedPolicy_GetPolicyFromPath_System_String_System_String_). 
 
 
@@ -297,7 +295,7 @@ Enable/disable kiosk browser's navigation buttons (forward/back).
 
 <!--/Scope-->
 <!--Description-->
-Amount of time in minutes the session is idle until the kiosk browser restarts in a fresh state.  
+Amount of time in minutes, the session is idle until the kiosk browser restarts in a fresh state.  
 
 The value is an int 1-1440 that specifies the number of minutes the session is idle until the kiosk browser restarts in a fresh state. The default value is empty, which means there's no idle timeout within the kiosk browser.
 
@@ -309,3 +307,7 @@ The value is an int 1-1440 that specifies the number of minutes the session is i
 <hr/>
 
 <!--/Policies-->
+
+## Related topics
+
+[Policy configuration service provider](policy-configuration-service-provider.md)

windows/client-management/mdm/policy-csp-lanmanworkstation.md

@@ -14,8 +14,6 @@ manager: dansimp
 
 # Policy CSP - LanmanWorkstation
 
-
-
 <hr/>
 
 <!--Policies-->
@@ -27,7 +25,6 @@ manager: dansimp
   </dd>
 </dl>
 
-
 <hr/>
 
 <!--Policy-->
@@ -57,13 +54,13 @@ manager: dansimp
 
 <!--/Scope-->
 <!--Description-->
-This policy setting determines if the SMB client will allow insecure guest sign ins to an SMB server.
+This policy setting determines, if the SMB client will allow insecure guest sign in to an SMB server.
 
-If you enable this policy setting or if you don't configure this policy setting, the SMB client will allow insecure guest sign ins.
+If you enable this policy setting or if you don't configure this policy setting, the SMB client will allow insecure guest sign in.
 
-If you disable this policy setting, the SMB client will reject insecure guest sign ins.
+If you disable this policy setting, the SMB client will reject insecure guest sign in.
 
-Insecure guest sign ins are used by file servers to allow unauthenticated access to shared folders. While uncommon in an enterprise environment, insecure guest sign ins are frequently used by consumer Network Attached Storage (NAS) appliances acting as file servers. Windows file servers require authentication and don't use insecure guest sign ins by default. Since insecure guest sign ins are unauthenticated, important security features such as SMB Signing and SMB Encryption are disabled. As a result, clients that allow insecure guest sign ins are vulnerable to various man-in-the-middle attacks that can result in data loss, data corruption, and exposure to malware. Additionally, any data written to a file server using an insecure guest sign in is potentially accessible to anyone on the network. Microsoft recommends disabling insecure guest sign ins and configuring file servers to require authenticated access.
+Insecure guest sign in are used by file servers to allow unauthenticated access to shared folders. While uncommon in an enterprise environment, insecure guest sign in are frequently used by consumer Network Attached Storage (NAS) appliances acting as file servers. Windows file servers require authentication, and don't use insecure guest sign in by default. Since insecure guest sign in are unauthenticated, important security features such as SMB Signing and SMB Encryption are disabled. As a result, clients that allow insecure guest sign in are vulnerable to various man-in-the-middle attacks that can result in data loss, data corruption, and exposure to malware. Additionally, any data written to a file server using an insecure guest sign in is potentially accessible to anyone on the network. Microsoft recommends disabling insecure guest sign in and configuring file servers to require authenticated access.
 
 <!--/Description-->
 <!--ADMXMapped-->
@@ -83,3 +80,6 @@ This setting supports a range of values between 0 and 1.
 
 <!--/Policies-->
 
+## Related topics
+
+[Policy configuration service provider](policy-configuration-service-provider.md)

windows/client-management/mdm/policy-csp-licensing.md

@@ -14,8 +14,6 @@ manager: dansimp
 
 # Policy CSP - Licensing
 
-
-
 <hr/>
 
 <!--Policies-->
@@ -30,7 +28,6 @@ manager: dansimp
   </dd>
 </dl>
 
-
 <hr/>
 
 <!--Policy-->
@@ -123,8 +120,8 @@ ADMX Info:
 <!--SupportedValues-->
 The following list shows the supported values:
 
--   0 (default) – Disabled.
+-   0 (default) – Disabled
--   1 – Enabled.
+-   1 – Enabled
 
 <!--/SupportedValues-->
 <!--/Policy-->
@@ -133,3 +130,6 @@ The following list shows the supported values:
 
 <!--/Policies-->
 
+## Related topics
+
+[Policy configuration service provider](policy-configuration-service-provider.md)