mirror of
https://github.com/MicrosoftDocs/windows-itpro-docs.git
synced 2025-06-16 10:53:43 +00:00
Merge branch 'master' of https://github.com/microsoftdocs/windows-itpro-docs
This commit is contained in:
@ -79,12 +79,14 @@ If you have deployed images that have not been generalized, then many of them mi
|
||||
[](images/device-reliability-device-count.png)
|
||||
|
||||
If you have devices that appear in other solutions, but not Device Health, follow these steps to investigate the issue:
|
||||
1. Confirm that the devices are running Windows10.
|
||||
2. Verify that the Commercial ID is present in the device's registry. For details see [https://gpsearch.azurewebsites.net/#13551](https://gpsearch.azurewebsites.net/#13551).
|
||||
3. Confirm that devices have opted in to provide diagnostic data by checking in the registry that **AllowTelemetry** is set to 2 (Enhanced) or 3 (Full) in **HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\DataCollection** (or **HKLM\Software\Policies\Microsoft\Windows\DataCollection**, which takes precedence if set).
|
||||
4. Verify that devices can reach the endpoints specified in [Enrolling devices in Windows Analytics](windows-analytics-get-started.md). Also check settings for SSL inspection and proxy authentication; see [Configuring endpoint access with SSL inspection](https://docs.microsoft.com/windows/deployment/update/windows-analytics-get-started#configuring-endpoint-access-with-ssl-inspection) for more information.
|
||||
5. Wait 48 hours for activity to appear in the reports.
|
||||
6. If you need additional troubleshooting, contact Microsoft Support.
|
||||
1. Using the Azure portal, remove the Device Health (appears as DeviceHealthProd on some pages) solution from your Log Analytics workspace. After completing this, add the Device Health solution to you workspace again.
|
||||
2. Confirm that the devices are running Windows 10.
|
||||
3. Verify that the Commercial ID is present in the device's registry. For details see [https://gpsearch.azurewebsites.net/#13551](https://gpsearch.azurewebsites.net/#13551).
|
||||
4. Confirm that devices have opted in to provide diagnostic data by checking in the registry that **AllowTelemetry** is set to 2 (Enhanced) or 3 (Full) in **HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\DataCollection** (or **HKLM\Software\Policies\Microsoft\Windows\DataCollection**, which takes precedence if set).
|
||||
5. Verify that devices can reach the endpoints specified in [Enrolling devices in Windows Analytics](windows-analytics-get-started.md). Also check settings for SSL inspection and proxy authentication; see [Configuring endpoint access with SSL inspection](https://docs.microsoft.com/windows/deployment/update/windows-analytics-get-started#configuring-endpoint-access-with-ssl-inspection) for more information.
|
||||
6. Remove the Device Health (appears as DeviceHealthProd on some pages) from your Log Analytics workspace
|
||||
7. Wait 48 hours for activity to appear in the reports.
|
||||
8. If you need additional troubleshooting, contact Microsoft Support.
|
||||
|
||||
|
||||
### Device crashes not appearing in Device Health Device Reliability
|
||||
|
@ -25,6 +25,8 @@ Everyone wins when transparency is a top priority. We want you to know when upda
|
||||
|
||||
The latest news:
|
||||
<ul compact style="list-style: none">
|
||||
<li><a href="https://blogs.windows.com/windowsexperience/2019/03/06/data-insights-and-listening-to-improve-the-customer-experience">Data, insights and listening to improve the customer experience</a> - March 6, 2019</li>
|
||||
<li><a href="https://techcommunity.microsoft.com/t5/Windows-IT-Pro-Blog/Getting-to-know-the-Windows-update-history-pages/ba-p/355079">Getting to know the Windows update history pages</a> - February 21, 2019</li>
|
||||
<li><a href="https://techcommunity.microsoft.com/t5/Windows-IT-Pro-Blog/Windows-Update-for-Business-and-the-retirement-of-SAC-T/ba-p/339523">Windows Update for Business and the retirement of SAC-T</a> - February 14, 2019</li>
|
||||
<li><a href="https://blogs.windows.com/windowsexperience/2019/01/15/application-compatibility-in-the-windows-ecosystem/#A8urpp1QEp6DHzmP.97">Application compatibility in the Windows ecosystem</a> - January 15, 2019</li>
|
||||
<li><a href="https://blogs.windows.com/windowsexperience/2018/12/10/windows-monthly-security-and-quality-updates-overview/#UJJpisSpvyLokbHm.97">Windows monthly security and quality updates overview</a> - January 10, 2019</li>
|
||||
|
@ -66,15 +66,21 @@ If you are interested in configuring your environment to use the Windows Hello f
|
||||
|
||||
Certificate authorities write CRL distribution points in certificates as they are issued. If the distribution point changes, then previously issued certificates must be reissued for the certificate authority to include the new CRL distribution point. The domain controller certificate is one the critical components of Azure AD joined devices authenticating to Active Directory
|
||||
|
||||
#### Why does Windows need to validate the domain controller certifcate?
|
||||
#### Why does Windows need to validate the domain controller certificate?
|
||||
|
||||
Windows Hello for Business enforces the strict KDC validation security feature, which enforces a more restrictive criteria that must be met by the Key Distribution Center (KDC). When authenticating using Windows Hello for Business, the Windows 10 client validates the reply from the domain controller by ensuring all of the following are met:
|
||||
Windows Hello for Business enforces the strict KDC validation security feature, which imposes more restrictive criteria that must be met by the Key Distribution Center (KDC). When authenticating using Windows Hello for Business, the Windows 10 client validates the reply from the domain controller by ensuring all of the following are met:
|
||||
|
||||
- The domain controller has the private key for the certificate provided.
|
||||
- The root CA that issued the domain controller's certificate is in the device's **Trusted Root Certificate Authorities**.
|
||||
- Use the **Kerberos Authentication certificate template** instead of any other older template.
|
||||
- The domain controller's certificate has the **KDC Authentication** enhanced key usage.
|
||||
- The domain controller's certificate's subject alternate name has a DNS Name that matches the name of the domain.
|
||||
|
||||
|
||||
> [!Tip]
|
||||
> If you are using Windows Server 2008, **Kerberos Authentication** is not the default template, so make sure to use the correct template when issuing or re-issuing the certificate.
|
||||
|
||||
|
||||
## Configuring a CRL Distribution Point for an issuing certificate authority
|
||||
|
||||
Use this set of procedures to update your certificate authority that issues your domain controller certificates to include an http-based CRL distribution point.
|
||||
@ -164,7 +170,7 @@ These procedures configure NTFS and share permissions on the web server to allow
|
||||
9. Click **Close** in the **cdp Properties** dialog box.
|
||||
|
||||
|
||||
### Configure the new CRL distribution point and Publishing location in the issuing certifcate authority
|
||||
### Configure the new CRL distribution point and Publishing location in the issuing certificate authority
|
||||
|
||||
The web server is ready to host the CRL distribution point. Now, configure the issuing certificate authority to publish the CRL at the new location and to include the new CRL distribution point
|
||||
|
||||
|
Reference in New Issue
Block a user