mirror of
https://github.com/MicrosoftDocs/windows-itpro-docs.git
synced 2025-06-18 11:53:37 +00:00
Merge branch 'master' of https://github.com/Microsoft/win-cpub-itpro-docs
This commit is contained in:
@ -306,7 +306,7 @@ This procedure will demonstrate how to deploy the reference image to the PoC env
|
||||
```
|
||||
[Settings]
|
||||
Priority=Default
|
||||
|
||||
|
||||
[Default]
|
||||
_SMSTSORGNAME=Contoso
|
||||
OSInstall=YES
|
||||
@ -362,7 +362,7 @@ This procedure will demonstrate how to deploy the reference image to the PoC env
|
||||
```
|
||||
[Settings]
|
||||
Priority=Default
|
||||
|
||||
|
||||
[Default]
|
||||
DeployRoot=\\SRV1\MDTProd$
|
||||
UserDomain=CONTOSO
|
||||
@ -417,12 +417,16 @@ This procedure will demonstrate how to deploy the reference image to the PoC env
|
||||
Disable-NetAdapter "Ethernet 2" -Confirm:$false
|
||||
```
|
||||
|
||||
>Wait until the disable-netadapter command completes before proceeding.
|
||||
|
||||
|
||||
2. Next, switch to the Hyper-V host and open an elevated Windows PowerShell prompt. Create a generation 2 VM on the Hyper-V host that will load its OS using PXE. To create this VM, type the following commands at an elevated Windows PowerShell prompt:
|
||||
|
||||
```
|
||||
New-VM –Name "PC2" –NewVHDPath "c:\vhd\pc2.vhdx" -NewVHDSizeBytes 60GB -SwitchName poc-internal -BootDevice NetworkAdapter -Generation 2
|
||||
Set-VMMemory -VMName "PC2" -DynamicMemoryEnabled $true -MinimumBytes 720MB -MaximumBytes 2048MB -Buffer 20
|
||||
```
|
||||
|
||||
>Dynamic memory is configured on the VM to conserve resources. However, this can cause memory allocation to be reduced past what is required to install an operating system. If this happens, reset the VM and begin the OS installation task sequence immediately. This ensures the VM memory allocation is not decreased too much while it is idle.
|
||||
|
||||
3. Start the new VM and connect to it:
|
||||
@ -452,24 +456,24 @@ This completes the demonstration of how to deploy a reference image to the netwo
|
||||
|
||||
This section will demonstrate how to export user data from an existing client computer, wipe the computer, install a new operating system, and then restore user data and settings. The scenario will use PC1, a computer that was cloned from a physical device to a VM, as described in [Step by step guide: Deploy Windows 10 in a test lab](windows-10-poc.md).
|
||||
|
||||
If the PC1 VM is not already running, then start and connect to it:
|
||||
|
||||
1. If the PC1 VM is not already running, then start and connect to it:
|
||||
|
||||
```
|
||||
Start-VM PC1
|
||||
vmconnect localhost PC1
|
||||
```
|
||||
|
||||
1. Switch back to the Hyper-V host and create a checkpoint for the PC1 VM so that it can easily be reverted to its current state for troubleshooting purposes and to perform additional scenarios. Checkpoints are also known as snapshots. To create a checkpoint for the PC1 VM, type the following command at an elevated Windows PowerShell prompt on the Hyper-V host:
|
||||
2. Switch back to the Hyper-V host and create a checkpoint for the PC1 VM so that it can easily be reverted to its current state for troubleshooting purposes and to perform additional scenarios. Checkpoints are also known as snapshots. To create a checkpoint for the PC1 VM, type the following command at an elevated Windows PowerShell prompt on the Hyper-V host:
|
||||
|
||||
```
|
||||
Checkpoint-VM -Name PC1 -SnapshotName BeginState
|
||||
```
|
||||
|
||||
2. Sign on to PC1 using the CONTOSO\Administrator account.
|
||||
3. Sign on to PC1 using the CONTOSO\Administrator account.
|
||||
|
||||
>Specify **contoso\administrator** as the user name to ensure you do not sign on using the local administrator account. You must sign in with this account so that you have access to the deployment share.
|
||||
|
||||
3. Open an elevated command prompt on PC1 and type the following:
|
||||
4. Open an elevated command prompt on PC1 and type the following:
|
||||
|
||||
```
|
||||
cscript \\SRV1\MDTProd$\Scripts\Litetouch.vbs
|
||||
@ -477,13 +481,13 @@ If the PC1 VM is not already running, then start and connect to it:
|
||||
|
||||
**Note**: Litetouch.vbs must be able to create the C:\MININT directory on the local computer.
|
||||
|
||||
4. Choose the **Windows 10 Enterprise x64 Custom Image** and then click **Next**.
|
||||
5. Choose the **Windows 10 Enterprise x64 Custom Image** and then click **Next**.
|
||||
|
||||
5. Choose **Do not back up the existing computer** and click **Next**.
|
||||
6. Choose **Do not back up the existing computer** and click **Next**.
|
||||
|
||||
**Note**: The USMT will still back up the computer.
|
||||
|
||||
6. Lite Touch Installation will perform the following actions:
|
||||
7. Lite Touch Installation will perform the following actions:
|
||||
- Back up user settings and data using USMT.
|
||||
- Install the Windows 10 Enterprise X64 operating system.
|
||||
- Update the operating system via Windows Update.
|
||||
@ -491,15 +495,15 @@ If the PC1 VM is not already running, then start and connect to it:
|
||||
|
||||
You can review the progress of installation on SRV1 by clicking on the **Monitoring** node in the deployment workbench. When OS installation is complete, the computer will restart, set up devices, and configure settings.
|
||||
|
||||
7. Sign in with the CONTOSO\Administrator account and verify that all CONTOSO domain user accounts and data have been migrated to the new operating system, or other user accounts as specified [previously](#configure-the-mdt-production-deployment-share).
|
||||
8. Sign in with the CONTOSO\Administrator account and verify that all CONTOSO domain user accounts and data have been migrated to the new operating system, or other user accounts as specified [previously](#configure-the-mdt-production-deployment-share).
|
||||
|
||||
8. Create another checkpoint for the PC1 VM so that you can review results of the computer refresh later. To create a checkpoint, type the following command at an elevated Windows PowerShell prompt on the Hyper-V host:
|
||||
9. Create another checkpoint for the PC1 VM so that you can review results of the computer refresh later. To create a checkpoint, type the following command at an elevated Windows PowerShell prompt on the Hyper-V host:
|
||||
|
||||
```
|
||||
Checkpoint-VM -Name PC1 -SnapshotName RefreshState
|
||||
```
|
||||
|
||||
9. Restore the PC1 VM to it's previous state in preparation for the replace procedure. To restore a checkpoint, type the following command at an elevated Windows PowerShell prompt on the Hyper-V host:
|
||||
10. Restore the PC1 VM to it's previous state in preparation for the replace procedure. To restore a checkpoint, type the following command at an elevated Windows PowerShell prompt on the Hyper-V host:
|
||||
|
||||
```
|
||||
Restore-VMSnapshot -VMName PC1 -Name BeginState -Confirm:$false
|
||||
@ -507,7 +511,7 @@ If the PC1 VM is not already running, then start and connect to it:
|
||||
vmconnect localhost PC1
|
||||
```
|
||||
|
||||
10. Sign in to PC1 using the contoso\administrator account.
|
||||
11. Sign in to PC1 using the contoso\administrator account.
|
||||
|
||||
## Replace a computer with Windows 10
|
||||
|
||||
@ -557,10 +561,10 @@ At a high level, the computer replace process consists of:<BR>
|
||||
```
|
||||
3. Complete the deployment wizard using the following:
|
||||
- **Task Sequence**: Backup Only Task Sequence
|
||||
- **User Data**: Specify a location: **\\SRV1\MigData$\PC1**
|
||||
- **User Data**: Specify a location: **\\\\SRV1\MigData$\PC1**
|
||||
- **Computer Backup**: Do not back up the existing computer.
|
||||
4. While the task sequence is running on PC1, open the deployment workbench console on SRV1 and click the **Monitoring* node. Press F5 to refresh the console, and view the status of current tasks.
|
||||
5. Verify that **The user state capture was completed successfully** is displayed, and click **Finish** when the capture is complete.
|
||||
5. On PC1, verify that **The user state capture was completed successfully** is displayed, and click **Finish** when the capture is complete.
|
||||
6. On SRV1, verify that the file **USMT.MIG** was created in the **C:\MigData\PC1\USMT** directory. See the following example:
|
||||
|
||||
```
|
||||
@ -585,18 +589,24 @@ At a high level, the computer replace process consists of:<BR>
|
||||
```
|
||||
Disable-NetAdapter "Ethernet 2" -Confirm:$false
|
||||
```
|
||||
|
||||
>As mentioned previously, ensure that you disable the **external** network adapter, and wait for the command to complete before proceeding.
|
||||
|
||||
|
||||
3. Start and connect to PC3 by typing the following commands at an elevated Windows PowerShell prompt on the Hyper-V host:
|
||||
|
||||
```
|
||||
Start-VM PC3
|
||||
vmconnect localhost PC3
|
||||
```
|
||||
|
||||
4. When prompted, press ENTER for network boot.
|
||||
|
||||
6. On PC3, ue the following settings for the Windows Deployment Wizard:
|
||||
6. On PC3, use the following settings for the Windows Deployment Wizard:
|
||||
- **Task Sequence**: Windows 10 Enterprise x64 Custom Image
|
||||
- **Move Data and Settings**: Do not move user data and settings
|
||||
- **User Data (Restore)**: Specify a location: **\\SRV1\MigData$\PC1**
|
||||
- **User Data (Restore)**: Specify a location: **\\\\SRV1\MigData$\PC1**
|
||||
|
||||
5. When OS installation has started on PC1, re-enable the external network adapter on SRV1 by typing the following command on SRV1:
|
||||
|
||||
```
|
||||
@ -606,7 +616,9 @@ At a high level, the computer replace process consists of:<BR>
|
||||
|
||||
8. When PC3 has completed installing the OS, sign in to PC3 using the contoso\administrator account. When the PC completes updating, click **Finish**.
|
||||
|
||||
9. Verify that settings have been migrated from PC1, and then shut down PC3 in preparation for the next procedure.
|
||||
9. Verify that settings have been migrated from PC1. This completes demonstration of the replace procedure.
|
||||
|
||||
10. Shut down PC3 in preparation for the [next](windows-10-poc-sc-config-mgr.md) procedure.
|
||||
|
||||
## Troubleshooting logs, events, and utilities
|
||||
|
||||
|
@ -131,7 +131,6 @@ This following is a full list of BCD settings with friendly names which are igno
|
||||
| 0x15000052 | all| graphicsresolution|
|
||||
| 0x15000065 | all| displaymessage|
|
||||
| 0x15000066| all| displaymessageoverride|
|
||||
| 0x15000081 | all| logcontrol|
|
||||
| 0x16000009 | all| recoveryenabled|
|
||||
| 0x1600000b | all| badmemoryaccess|
|
||||
| 0x1600000f | all| traditionalkseg|
|
||||
|
@ -32,6 +32,7 @@ The following sections provide a comprehensive list of BitLocker Group Policy se
|
||||
|
||||
The following policy settings can be used to determine how a BitLocker-protected drive can be unlocked.
|
||||
|
||||
- [Allow devices with Secure Boot and protect DMS ports to opt out of preboot PIN](#bkmk-hstioptout)
|
||||
- [Allow network unlock at startup](#bkmk-netunlock)
|
||||
- [Require additional authentication at startup](#bkmk-unlockpol1)
|
||||
- [Allow enhanced PINs for startup](#bkmk-unlockpol2)
|
||||
@ -85,6 +86,55 @@ The following policies are used to support customized deployment scenarios in yo
|
||||
- [Allow access to BitLocker-protected fixed data drives from earlier versions of Windows](#bkmk-depopt4)
|
||||
- [Allow access to BitLocker-protected removable data drives from earlier versions of Windows](#bkmk-depopt5)
|
||||
|
||||
### <a href="" id="bkmk-hstioptout"></a>Allow devices with Secure Boot and protect DMS ports to opt out of preboot PIN
|
||||
|
||||
This policy setting allows users on devices that are compliant with InstantGo or the Microsoft Hardware Security Test Interface (HSTI) to not have a PIN for preboot authentication.
|
||||
|
||||
<table>
|
||||
<colgroup>
|
||||
<col width="50%" />
|
||||
<col width="50%" />
|
||||
</colgroup>
|
||||
<tbody>
|
||||
<tr class="odd">
|
||||
<td align="left"><p><strong>Policy description</strong></p></td>
|
||||
<td align="left"><p>With this policy setting, you can allow TPM-only protection for newer, more secure devices, such as devices that support InstantGo or HSTI, while requiring PIN on older devices.</p></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td align="left"><p><strong>Introduced</strong></p></td>
|
||||
<td align="left"><p>Windows 10, version 1703</p></td>
|
||||
</tr>
|
||||
<tr class="odd">
|
||||
<td align="left"><p><strong>Drive type</strong></p></td>
|
||||
<td align="left"><p>Operating system drives</p></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td align="left"><p><strong>Policy path</strong></p></td>
|
||||
<td align="left"><p>Computer Configuration\Administrative Templates\Windows Components\BitLocker Drive Encryption\Operating System Drives</p></td>
|
||||
</tr>
|
||||
<tr class="odd">
|
||||
<td align="left"><p><strong>Conflicts</strong></p></td>
|
||||
<td align="left"><p>This setting overrides the <b>Require startup PIN with TPM</b> option of the [Require additional authentication at startup](#bkmk-unlockpol1) policy on compliant hardware.
|
||||
|
||||
</p></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td align="left"><p><strong>When enabled</strong></p></td>
|
||||
<td align="left"><p>Users on InstantGo and HSTI compliant devices will have the choice to turn on BitLocker without preboot authentication.</p></td>
|
||||
</tr>
|
||||
<tr class="odd">
|
||||
<td align="left"><p><strong>When disabled or not configured</strong></p></td>
|
||||
<td align="left"><p>The options of the [Require additional authentication at startup](#bkmk-unlockpol1) policy apply.</p></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
**Reference**
|
||||
|
||||
The preboot authentication option <b>Require startup PIN with TPM</b> of the [Require additional authentication at startup](#bkmk-unlockpol1) policy is often enabled to help ensure security for older devices that do not support InstantGo.
|
||||
But visually impaired users have no audible way to know when to enter a PIN.
|
||||
This setting enables an exception to the PIN-required policy on secure hardware.
|
||||
|
||||
### <a href="" id="bkmk-netunlock"></a>Allow network unlock at startup
|
||||
|
||||
This policy controls a portion of the behavior of the Network Unlock feature in BitLocker. This policy is required to enable BitLocker Network Unlock on a network because it allows clients running BitLocker to create the necessary network key protector during encryption. This policy is used in addition to the BitLocker Drive Encryption Network Unlock Certificate security policy (located in the **Public Key Policies** folder of Local Computer Policy) to allow systems that are connected to a trusted network to properly utilize the Network Unlock feature.
|
||||
|
@ -22,9 +22,9 @@ This policy setting determines whether the Lightweight Directory Access Protocol
|
||||
|
||||
Unsigned network traffic is susceptible to man-in-the-middle attacks, where an intruder captures packets between the server and the client device and modifies them before forwarding them to the client device. In the case of an LDAP server, this means that a malicious user can cause a client device to make decisions based on false records from the LDAP directory. You can lower the risk of a malicious user accomplishing this in a corporate network by implementing strong physical security measures to protect the network infrastructure. Furthermore, implementing Internet Protocol security (IPsec) Authentication Header mode, which provides mutual authentication and packet integrity for IP traffic, can make all types of man-in-the-middle attacks extremely difficult.
|
||||
|
||||
This setting does not have any impact on LDAP simple bind or LDAP simple bind through SSL.
|
||||
This setting does not have any impact on LDAP simple bind through SSL (LDAP TCP/636).
|
||||
|
||||
If signing is required, then LDAP simple bind and LDAP simple bind through SSL requests are rejected.
|
||||
If signing is required, then LDAP simple binds not using SSL are rejected (LDAP TCP/389).
|
||||
|
||||
>**Caution:** If you set the server to Require signature, you must also set the client device. Not setting the client device results in loss of connection with the server.
|
||||
|
||||
|
@ -26,8 +26,8 @@ This section addresses issues that might arise as you use the Windows Defender A
|
||||
If you encounter a server error when trying to access the service, you’ll need to change your browser cookie settings.
|
||||
Configure your browser to allow cookies.
|
||||
|
||||
### Data is missing on the portal
|
||||
If data is missing on the Windows Defender ATP portal it’s possible that proxy settings are blocking it.
|
||||
### Elements or data missing on the portal
|
||||
If some UI elements or data is missing on the Windows Defender ATP portal it’s possible that proxy settings are blocking it.
|
||||
|
||||
Make sure that `*.securitycenter.windows.com` is included the proxy whitelist.
|
||||
|
||||
|
@ -109,7 +109,20 @@ In order for your devices to show up in Windows Analytics: Update Compliance, th
|
||||
3. In the **Options** box, under **Commercial Id**, type the Commercial ID GUID, and then click **OK**.<P>
|
||||
|
||||
- Using Microsoft Mobile Device Management (MDM)<BR><BR>
|
||||
Microsoft’s Mobile Device Management can be used to deploy your Commercial ID to your organization’s devices. The Commercial ID is listed under **Provider/ProviderID/CommercialID**. More information on deployment using MDM can be found [here](https://msdn.microsoft.com/windows/hardware/commercialize/customize/mdm/dmclient-csp).
|
||||
Microsoft’s Mobile Device Management can be used to deploy your Commercial ID to your organization’s devices. The Commercial ID is listed under **Provider/ProviderID/CommercialID**. More information on deployment using MDM can be found [here](https://msdn.microsoft.com/windows/hardware/commercialize/customize/mdm/dmclient-csp).
|
||||
|
||||
For information on how to use MDM configuration CSPs, see [Introduction to configuration service providers (CSPs) for IT pros](https://technet.microsoft.com/en-us/itpro/windows/manage/how-it-pros-can-use-configuration-service-providers).
|
||||
|
||||
When using the Intune console, you can use the OMA-URI settings of a [custom policy](https://go.microsoft.com/fwlink/p/?LinkID=616316) to configure the commercial ID. The OMA-URI (case sensitive) path for configuring the commerical ID is: <PRE>./Vendor/MSFT/DMClient/Provider/ProviderID/CommercialID</PRE>
|
||||
|
||||
For example, you can use the following values in **Add or edit OMA-URI Setting**:
|
||||
|
||||
**Setting Name**: Windows Analytics Commercial ID<BR>
|
||||
**Setting Description**: Configuring commercial id for Windows Analytics solutions<BR>
|
||||
**Data Type**: String<BR>
|
||||
**OMA-URI (case sensitive)**: ./Vendor/MSFT/DMClient/Provider/ProviderID/CommercialID<BR>
|
||||
**Value**: \<Use the GUID shown on the Windows Telemetry tab in your OMS workspace\><BR>
|
||||
|
||||
|
||||
|
||||
## Related topics
|
||||
|
Reference in New Issue
Block a user