Merge branch 'master' into Issue#3421

This commit is contained in:
Jose Gabriel Ortega Castro 2019-05-31 01:35:55 -05:00 committed by GitHub
commit faf7b62fd7
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
3 changed files with 232 additions and 300 deletions

View File

@ -24,19 +24,31 @@ ms.topic: article
Before deploying a device using Windows Autopilot, the device must be registered with the Windows Autopilot deployment service. Ideally, this would be performed by the OEM, reseller, or distributor from which the devices were purchased, but this can also be done by the organization by collecting the hardware identity and uploading it manually. Before deploying a device using Windows Autopilot, the device must be registered with the Windows Autopilot deployment service. Ideally, this would be performed by the OEM, reseller, or distributor from which the devices were purchased, but this can also be done by the organization by collecting the hardware identity and uploading it manually.
## OEM registration
When you purchase devices directly from an OEM, that OEM can automatically register the devices with the Windows Autopilot deployment service. For the list of OEMs that currently support this, see the "Participant device manufacturers" section of the [Windows Autopilot information page](https://www.microsoft.com/en-us/windowsforbusiness/windows-autopilot).
Before an OEM can register devices on behalf of an organization, the organization must grant the OEM permission to do so. This process is initiated by the OEM, with approval granted by an Azure AD global administrator from the organization. See the "Customer Consent" section of the [Customer consent page](https://docs.microsoft.com/en-us/windows/deployment/windows-autopilot/registration-auth#oem-authorization).
## Reseller, distributor, or partner registration
Customers may purchase devices from resellers, distributors, or other partners. As long as these resellers, distributors, and partners are part of the [Cloud Solution Partners (CSP) program](https://partner.microsoft.com/en-us/cloud-solution-provider), they too can register devices on behalf of the customer.
As with OEMs, CSP parnters must be granted permission to register devices on behalf of an organization. This follows the process described on the [Customer consent page](https://docs.microsoft.com/en-us/windows/deployment/windows-autopilot/registration-auth#csp-authorization). The CSP partner initiates a request to establish a relationship with the organization, with approval granted by a global administrator from the organization. Once approved, CSP partners add devices using [Partner Center](https://partner.microsoft.com/en-us/pcv/dashboard/overview), either directly through the web site or via available APIs that can automate the same tasks.
Windows Autopilot does not require delegated administrator permissions when establishing the relationship between the CSP partner and the organization. As part of the approval process performed by the global administrator, the global administrator can choose to uncheck the "Include delegated administration permissions" checkbox.
## Automatic registration of existing devices
If an existing device is already running Windows 10 version 1703 or later and enrolled in an MDM service such an Intune, that MDM service can ask the device for the hardwareh ID (also known as a hardware hash). Once it has that, it can automatically register the device with Windows Autopilot.
For instructions on how to do this with Microsoft Intune, see [Create an Autopilot deployment profile](https://docs.microsoft.com/en-us/intune/enrollment-autopilot#create-an-autopilot-deployment-profile) documentation describing the "Convert all targeted devices to Autopilot" setting.
Also note that when using the [Windows Autopilot for existing devices](https://docs.microsoft.com/en-us/windows/deployment/windows-autopilot/existing-devices) scenario, it is not necessary to pre-register the devices with Windows Autopilot. Instead, a configuration file (AutopilotConfigurationFile.json) containing all the Windows Autopilot profile settings is used; the device can be registered with Windows Autopilot after the fact using the same "Convert all targeted devices to Autopilot" setting.
## Manual registration ## Manual registration
To perform manual registration of a device, you must caputure its hardware ID (also known as a hardware hash) and upload this to the Windows Autopilot deployment service. See the topics below for detailed information on how to collect and upload hardware IDs. To perform manual registration of a device, you must first caputure its hardware ID (also known as a hardware hash). Once this process has completed, the resulting hardware ID can be uploaded to the Windows Autopilot service. Because this process requires booting the device into Windows 10 in order to obtain the hardware ID, this is intended primarily for testing and evaluation scenarios.
>[!IMPORTANT]
>Do not connect devices to the Internet prior to capturing the hardware ID and creating an Autopilot device profile. This includes collecting the hardware ID, uploading the .CSV into MSfB or Intune, assigning the profile, and confirming the profile assignment. Connecting the device to the Internet before this process is complete will result in the device downloading a blank profile that is stored on the device until it is explicity removed. In Windows 10 version 1809, you can clear the cached profile by restarting OOBE. In previous versions, the only way to clear the stored profile is to re-install the OS, reimage the PC, or run **sysprep /generalize /oobe**. <br>
>After Intune reports the profile ready to go, only then should the device be connected to the Internet.
Also note that if OOBE is restarted too many times it can enter a recovery mode and fail to run the Autopilot configuration. You can identify this scenario if OOBE displays multiple configuration options on the same page, including language, region, and keyboard layout. The normal OOBE displays each of these on a separate page. The following value key tracks the count of OOBE retries:
**HKCU\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\UserOOBE**
To ensure OOBE has not been restarted too many times, you can change this value to 1.
## Device identification ## Device identification
@ -44,9 +56,13 @@ To define a device to the Windows Autopilot deployment service, a unique hardwar
The hardware ID, also commonly referred to as a hardware hash, contains several details about the device, including its manufacturer, model, device serial number, hard drive serial number, and many other attributes that can be used to uniquely identify that device. The hardware ID, also commonly referred to as a hardware hash, contains several details about the device, including its manufacturer, model, device serial number, hard drive serial number, and many other attributes that can be used to uniquely identify that device.
Note that the hardware hash also contains details about when it was generated, so it will change each time it is generated. When the Windows Autopilot Deployment Service attempts to match a device, it considers changes like that, as well as more substantial changes such as a new hard drive, and is still able to match successfully. But substantial changes to the hardware, such as motherboard replacement, would not match, so the device would need to be re-uploaded. Note that the hardware hash also contains details about when it was generated, so it will change each time it is generated. When the Windows Autopilot deployment service attempts to match a device, it considers changes like that, as well as more substantial changes such as a new hard drive, and is still able to match successfully. But substantial changes to the hardware, such as a motherboard replacement, would not match, so a new hash would need to be generated and uploaded.
## Collecting the hardware ID from existing devices using PowerShell ### Collecting the hardware ID from existing devices using System Center Configuration Manager
Starting with System Center Configuration Manager current branch version 1802, the hardware hashes for existing Windows 10 version 1703 and higher devices are automatically collected by Configuration Manager. See the [Whats new in version 1802](https://docs.microsoft.com/sccm/core/plan-design/changes/whats-new-in-version-1802#report-on-windows-autopilot-device-information) documentation for more details. The hash information can be extracted from Configuration Manager into a CSV file.
### Collecting the hardware ID from existing devices using PowerShell
The hardware ID, or hardware hash, for an existing device is available through Windows Management Instrumentation (WMI), as long as that device is running Windows 10 version 1703 or later. To help gather this information, as well as the serial number of the device (useful to see at a glance the machine to which it belongs), a PowerShell script called [Get-WindowsAutoPilotInfo.ps1 has been published to the PowerShell Gallery website](https://www.powershellgallery.com/packages/Get-WindowsAutoPilotInfo). The hardware ID, or hardware hash, for an existing device is available through Windows Management Instrumentation (WMI), as long as that device is running Windows 10 version 1703 or later. To help gather this information, as well as the serial number of the device (useful to see at a glance the machine to which it belongs), a PowerShell script called [Get-WindowsAutoPilotInfo.ps1 has been published to the PowerShell Gallery website](https://www.powershellgallery.com/packages/Get-WindowsAutoPilotInfo).
@ -62,25 +78,23 @@ Get-WindowsAutoPilotInfo.ps1 -OutputFile AutoPilotHWID.csv
The commands can also be run remotely, as long as WMI permissions are in place and WMI is accessible through the Windows Firewall on that remote computer. See the Get-WindowsAutoPilotInfo scripts help (using “Get-Help Get-WindowsAutoPilotInfo.ps1”) for more information about running the script. The commands can also be run remotely, as long as WMI permissions are in place and WMI is accessible through the Windows Firewall on that remote computer. See the Get-WindowsAutoPilotInfo scripts help (using “Get-Help Get-WindowsAutoPilotInfo.ps1”) for more information about running the script.
>[!IMPORTANT]
>Do not connect devices to the Internet prior to capturing the hardware ID and creating an Autopilot device profile. This includes collecting the hardware ID, uploading the .CSV into MSfB or Intune, assigning the profile, and confirming the profile assignment. Connecting the device to the Internet before this process is complete will result in the device downloading a blank profile that is stored on the device until it is explicity removed. In Windows 10 version 1809, you can clear the cached profile by restarting OOBE. In previous versions, the only way to clear the stored profile is to re-install the OS, reimage the PC, or run **sysprep /generalize /oobe**. <br>
>After Intune reports the profile ready to go, only then should the device be connected to the Internet.
>[!NOTE] >[!NOTE]
>If you will connect to the device remotely to collect the hardware ID, see the information at the top of this page about device connectivity to the Internet. >If OOBE is restarted too many times it can enter a recovery mode and fail to run the Autopilot configuration. You can identify this scenario if OOBE displays multiple configuration options on the same page, including language, region, and keyboard layout. The normal OOBE displays each of these on a separate page. The following value key tracks the count of OOBE retries: <br>
>**HKCU\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\UserOOBE** <br>
## Collecting the hardware ID from existing devices using System Center Configuration Manager >To ensure OOBE has not been restarted too many times, you can change this value to 1.
Starting with System Center Configuration Manager current branch version 1802, the hardware hashes for existing Windows 10 version 1703 and higher devices are automatically collected by Configuration Manager. See the [Whats new in version 1802](https://docs.microsoft.com/sccm/core/plan-design/changes/whats-new-in-version-1802#report-on-windows-autopilot-device-information) documentation for more details.
## Registering devices ## Registering devices
Once the hardware IDs have been captured from existing devices, they can be uploaded through a variety of means. See the detailed documentation for each available mechanism: Once the hardware IDs have been captured from existing devices, they can be uploaded through a variety of means. See the detailed documentation for each available mechanism:
For guidance on how to register devices, configure and apply deployment profiles, follow one of the available administration options: - [Microsoft Intune](https://docs.microsoft.com/intune/enrollment-autopilot). This is the preferred mechanism for all customers.
- [Microsoft Intune](https://docs.microsoft.com/intune/enrollment-autopilot) - [Partner Center](https://msdn.microsoft.com/partner-center/autopilot). This is used by CSP partners to register devices on behalf of customers.
- [Microsoft Store for Business](https://docs.microsoft.com/microsoft-store/add-profile-to-devices#manage-autopilot-deployment-profiles) - [Microsoft 365 Business & Office 365 Admin](https://support.office.com/article/Create-and-edit-AutoPilot-profiles-5cf7139e-cfa1-4765-8aad-001af1c74faa). This is typically used by small and medium businesses (SMBs) who manage their devices using Microsoft 365 Business.
- [Microsoft 365 Business & Office 365 Admin](https://support.office.com/article/Create-and-edit-AutoPilot-profiles-5cf7139e-cfa1-4765-8aad-001af1c74faa) - [Microsoft Store for Business](https://docs.microsoft.com/microsoft-store/add-profile-to-devices#manage-autopilot-deployment-profiles).
- [Partner Center](https://msdn.microsoft.com/partner-center/autopilot)
For those using Microsoft Intune, devices should normally be uploaded via Intune; for those using Microsoft 365 Business, its administrative portal would be used. For [Cloud Solution Provider (CSP)](https://partnercenter.microsoft.com/en-us/partner/cloud-solution-provider) partners uploading devices on the behalf of a customer that they are authorized to manage, Partner Center can be used. For any other scenario, the Microsoft Store for Business is available.

View File

@ -127,6 +127,7 @@ If your AD FS farm is not already configured for Device Authentication (you can
`Import-module activedirectory` `Import-module activedirectory`
`PS C:\> Initialize-ADDeviceRegistration -ServiceAccountName "<your service account>" ` `PS C:\> Initialize-ADDeviceRegistration -ServiceAccountName "<your service account>" `
3. On the pop-up window click **Yes**. 3. On the pop-up window click **Yes**.
> [!NOTE] > [!NOTE]
@ -136,7 +137,6 @@ If your AD FS farm is not already configured for Device Authentication (you can
The above PSH creates the following objects: The above PSH creates the following objects:
- RegisteredDevices container under the AD domain partition - RegisteredDevices container under the AD domain partition
- Device Registration Service container and object under Configuration --> Services --> Device Registration Configuration - Device Registration Service container and object under Configuration --> Services --> Device Registration Configuration
- Device Registration Service DKM container and object under Configuration --> Services --> Device Registration Configuration - Device Registration Service DKM container and object under Configuration --> Services --> Device Registration Configuration
@ -374,6 +374,7 @@ The following script helps you with the creation of the issuance transform rules
Type = "http://schemas.microsoft.com/ws/2012/01/accounttype", Type = "http://schemas.microsoft.com/ws/2012/01/accounttype",
Value = "DJ" Value = "DJ"
);' );'
$rule2 = '@RuleName = "Issue object GUID for domain-joined computers" $rule2 = '@RuleName = "Issue object GUID for domain-joined computers"
c1:[ c1:[
Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid",
@ -391,6 +392,7 @@ The following script helps you with the creation of the issuance transform rules
query = ";objectguid;{0}", query = ";objectguid;{0}",
param = c2.Value param = c2.Value
);' );'
$rule3 = '@RuleName = "Issue objectSID for domain-joined computers" $rule3 = '@RuleName = "Issue objectSID for domain-joined computers"
c1:[ c1:[
Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid",
@ -403,6 +405,7 @@ The following script helps you with the creation of the issuance transform rules
Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$" Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
] ]
=> issue(claim = c2);' => issue(claim = c2);'
$rule4 = '' $rule4 = ''
if ($multipleVerifiedDomainNames -eq $true) { if ($multipleVerifiedDomainNames -eq $true) {
$rule4 = '@RuleName = "Issue account type with the value User when it is not a computer" $rule4 = '@RuleName = "Issue account type with the value User when it is not a computer"
@ -446,6 +449,7 @@ The following script helps you with the creation of the issuance transform rules
Value = "http://' + $oneOfVerifiedDomainNames + '/adfs/services/trust/" Value = "http://' + $oneOfVerifiedDomainNames + '/adfs/services/trust/"
);' );'
} }
$rule5 = '' $rule5 = ''
if ($immutableIDAlreadyIssuedforUsers -eq $true) { if ($immutableIDAlreadyIssuedforUsers -eq $true) {
$rule5 = '@RuleName = "Issue ImmutableID for computers" $rule5 = '@RuleName = "Issue ImmutableID for computers"
@ -466,11 +470,16 @@ The following script helps you with the creation of the issuance transform rules
param = c2.Value param = c2.Value
);' );'
} }
$existingRules = (Get-ADFSRelyingPartyTrust -Identifier urn:federation:MicrosoftOnline).IssuanceTransformRules $existingRules = (Get-ADFSRelyingPartyTrust -Identifier urn:federation:MicrosoftOnline).IssuanceTransformRules
$updatedRules = $existingRules + $rule1 + $rule2 + $rule3 + $rule4 + $rule5 $updatedRules = $existingRules + $rule1 + $rule2 + $rule3 + $rule4 + $rule5
$crSet = New-ADFSClaimRuleSet -ClaimRule $updatedRules $crSet = New-ADFSClaimRuleSet -ClaimRule $updatedRules
Set-AdfsRelyingPartyTrust -TargetIdentifier urn:federation:MicrosoftOnline -IssuanceTransformRules $crSet.ClaimRulesString Set-AdfsRelyingPartyTrust -TargetIdentifier urn:federation:MicrosoftOnline -IssuanceTransformRules $crSet.ClaimRulesString
#### Remarks #### Remarks
- This script appends the rules to the existing rules. Do not run the script twice because the set of rules would be added twice. Make sure that no corresponding rules exist for these claims (under the corresponding conditions) before running the script again. - This script appends the rules to the existing rules. Do not run the script twice because the set of rules would be added twice. Make sure that no corresponding rules exist for these claims (under the corresponding conditions) before running the script again.
@ -507,8 +516,7 @@ For your reference, below is a comprehensive list of the AD DS devices, containe
>[!div class="nextstepaction"] >[!div class="nextstepaction"]
[Configure Windows Hello for Business settings](hello-hybrid-cert-whfb-settings.md) [Configure Windows Hello for Business settings](hello-hybrid-cert-whfb-settings.md)
<br><br> <br>
<hr> <hr>
## Follow the Windows Hello for Business hybrid certificate trust deployment guide ## Follow the Windows Hello for Business hybrid certificate trust deployment guide

View File

@ -46,108 +46,18 @@ See [Enable cloud-delivered protection](enable-cloud-protection-windows-defender
After you've enabled the service, you may need to configure your network or firewall to allow connections between it and your endpoints. After you've enabled the service, you may need to configure your network or firewall to allow connections between it and your endpoints.
The following table lists the services and their associated URLs that your network must be able to connect to. You should ensure there are no firewall or network filtering rules that would deny access to these URLs, or you may need to create an **allow** rule specifically for them: As a cloud service, it is required that computers have access to the internet and that the ATP machine learning services are reachable. The following table lists the services and their associated URLs. You should ensure there are no firewall or network filtering rules that would deny access to these URLs, or you may need to create an allow rule specifically for them:
<table style="vertical-align:top">
<tr style="vertical-align:top">
<th >Service</th>
<th>Description</th>
<th>URL</th>
</tr>
<tr style="vertical-align:top">
<td>
Windows Defender Antivirus cloud-delivered protection service, also referred to as Microsoft Active Protection Service (MAPS)
</td>
<td>
Used by Windows Defender Antivirus to provide cloud-delivered protection
</td>
<td>
*.wdcp.microsoft.com<br />
*.wdcpalt.microsoft.com<br />
*.wd.microsoft.com
</td>
</tr>
<tr style="vertical-align:top">
<td>
Microsoft Update Service (MU)
</td>
<td>
Security intelligence and product updates
</td>
<td>
*.update.microsoft.com
</td>
</tr>
<tr style="vertical-align:top">
<td>
Security intelligence updates alternate download location (ADL)
</td>
<td>
Alternate location for Windows Defender Antivirus Security intelligence updates if the installed Security intelligence falls out of date (7 or more days behind)
</td>
<td>
*.download.microsoft.com
</td>
</tr>
<tr style="vertical-align:top">
<td>
Malware submission storage
</td>
<td>
Upload location for files submitted to Microsoft via the <a href="https://www.microsoft.com/en-us/security/portal/submission/submit.aspx">Submission form</a> or automatic sample submission
</td>
<td>
ussus1eastprod.blob.core.windows.net<br />
ussus1westprod.blob.core.windows.net<br />
usseu1northprod.blob.core.windows.net<br />
usseu1westprod.blob.core.windows.net<br />
ussuk1southprod.blob.core.windows.net<br />
ussuk1westprod.blob.core.windows.net<br />
ussas1eastprod.blob.core.windows.net<br />
ussas1southeastprod.blob.core.windows.net<br />
ussau1eastprod.blob.core.windows.net<br />
ussau1southeastprod.blob.core.windows.net<br />
</td>
</tr>
<tr style="vertical-align:top">
<td>
Certificate Revocation List (CRL)
</td>
<td>
Used by Windows when creating the SSL connection to MAPS for updating the CRL
</td>
<td>
http://www.microsoft.com/pkiops/crl/<br />
http://www.microsoft.com/pkiops/certs<br />
http://crl.microsoft.com/pki/crl/products<br />
http://www.microsoft.com/pki/certs
</ul>
</td>
</tr>
<tr style="vertical-align:top">
<td>
Symbol Store
</td>
<td>
Used by Windows Defender Antivirus to restore certain critical files during remediation flows
</td>
<td>
https://msdl.microsoft.com/download/symbols
</td>
</tr>
<tr style="vertical-align:top">
<td>
Universal Telemetry Client
</td>
<td>
Used by Windows to send client diagnostic data; Windows Defender Antivirus uses this for product quality monitoring purposes
</td>
<td>
This update uses SSL (TCP Port 443) to download manifests and upload diagnostic data to Microsoft that uses the following DNS endpoints: <ul><li>vortex-win.data.microsoft.com</li><li>settings-win.data.microsoft.com</li></ul></td>
</tr>
</table>
<a id="validate"></a> | **Service**| **Description** |**URL** |
| :--: | :-- | :-- |
| *Windows Defender Antivirus cloud-delivered protection service, also referred to as Microsoft Active Protection Service (MAPS)*|Used by Windows Defender Antivirus to provide cloud-delivered protection|*.wdcp.microsoft.com *.wdcpalt.microsoft.com *.wd.microsoft.com|
| *Microsoft Update Service (MU)*| Security intelligence and product updates |*.update.microsoft.com|
| *Security intelligence updates Alternate Download Location (ADL)*| Alternate location for Windows Defender Antivirus Security intelligence updates if the installed Security intelligence is out of date (7 or more days behind)| *.download.microsoft.com|
| *Malware submission storage *|Upload location for files submitted to Microsoft via the Submission form or automatic sample submission |*.blob.core.windows.net|
| *Certificate Revocation List (CRL)* |Used by Windows when creating the SSL connection to MAPS for updating the CRL | http://www.microsoft.com/pkiops/crl/ http://www.microsoft.com/pkiops/certs http://crl.microsoft.com/pki/crl/products http://www.microsoft.com/pki/certs |
| *Symbol Store *|Used by Windows Defender Antivirus to restore certain critical files during remediation flows | https://msdl.microsoft.com/download/symbols |
| *Universal Telemetry Client* | Used by Windows to send client diagnostic data; Windows Defender Antivirus uses this for product quality monitoring purposes | This update uses SSL (TCP Port 443) to download manifests and upload diagnostic data to Microsoft that uses the following DNS endpoints: * vortex-win.data.microsoft.com * settings-win.data.microsoft.com|
## Validate connections between your network and the cloud ## Validate connections between your network and the cloud