deepblue/windows-itpro-docs
1
0
Fork 0
mirror of https://github.com/MicrosoftDocs/windows-itpro-docs.git synced 2025-05-13 05:47:23 +00:00
Code Issues Actions 2 Packages Projects Releases Wiki Activity

Merge branch 'master' into v-tea-CI-103321

Browse Source
This commit is contained in:
Teresa-Motiv 2019-07-01 08:47:34 -07:00
commit cd0ecc874b
6 changed files with 74 additions and 28 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

29
devices/surface/surface-system-sku-reference.md
View File

@ -16,9 +16,9 @@ manager: dansimp
# System SKU reference
This document provides a reference of System Model and System SKU names that you can use to quickly determine the machine state of a specific device using PowerShell or WMI.
This document provides a reference of System Model and System SKU names that you can use to quickly determine the machine state of a specific device by using PowerShell or WMI.
System Model and System SKU are variables stored in System Management BIOS (SMBIOS) tables in the UEFI layer of Surface devices. The System SKU name is required to differentiate between devices with the same System Model name, such as Surface Pro and Surface Pro with LTE Advanced.
System Model and System SKU are variables that are stored in the System Management BIOS (SMBIOS) tables in the UEFI layer of Surface devices. The System SKU name is required to differentiate between devices that have the same System Model name, such as Surface Pro and Surface Pro with LTE Advanced.
| Device | System Model | System SKU |
| ---------- | ----------- | -------------- |
@ -26,11 +26,13 @@ System Model and System SKU are variables stored in System Management BIOS (SMBI
| Surface 3 LTE AT&T | Surface 3 | Surface_3_US1 |
| Surface 3 LTE Verizon | Surface 3 | Surface_3_US2 |
| Surface 3 LTE North America | Surface 3 | Surface_3_NAG |
| Surface 3 LTE Outside of North America and T-Mobile In Japan | Surface 3 | Surface_3_ROW |
| Surface 3 LTE Outside of North America and Y!mobile In Japan | Surface 3 | Surface_3_ROW |
| Surface Pro | Surface Pro | Surface_Pro_1796 |
| Surface Pro with LTE Advanced | Surface Pro | Surface_Pro_1807 |
| Surface Book 2 13inch | Surface Book 2 | Surface_Book_1832 |
| Surface Book 2 15inch | Surface Book 2 | Surface_Book_1793 |
| Surface Go LTE Consumer | Surface Go | Surface_Go_1825_Consumer |
| Surface Go LTE Commercial | System Go | Surface_Go_1825_Commercial |
| Surface Go Consumer | Surface Go | Surface_Go_1824_Consumer |
| Surface Go Commercial | Surface Go | Surface_Go_1824_Commercial |
| Surface Pro 6 Consumer | Surface Pro 6 | Surface_Pro_6_1796_Consumer |
@ -40,22 +42,23 @@ System Model and System SKU are variables stored in System Management BIOS (SMBI
## Examples
**PowerShell**
Use the following PowerShell command to pull System SKU:
**Retrieving the SKU by using PowerShell**
Use the following PowerShell command to pull the System SKU information:
```
``` powershell
gwmi -namespace root\wmi -class MS_SystemInformation | select SystemSKU
```
**System Information**
You can also find the System SKU and System Model for a device in System Information.
**Retrieving the SKU by using System Information**
You can also find the System SKU and System Model for a device in **System Information**. To do this, follow these steps:
- Go to **Start** > **MSInfo32**.
One example of how you could use this in Microsoft Deployment Toolkit (MDT) or System Center Configuration Manager is as part of a Task Sequence WMI Condition. For example:
**Task Sequence WMI Condition**
1. Select **Start**, and then type **MSInfo32** in the search box.
1. Select **System Information**.
**Using the SKU in a task sequence WMI condition**
You can use the System SKU information in the Microsoft Deployment Toolkit (MDT) or System Center Configuration Manager as part of a task sequence WMI condition.
``` powershell
- WMI Namespace – Root\WMI
- WQL Query – SELECT * FROM MS_SystemInformation WHERE SystemSKU = "Surface_Pro_1796"
```

2
windows/client-management/mdm/new-in-windows-mdm-enrollment-management.md
View File

@ -1903,7 +1903,7 @@ How do I turn if off? | The service can be stopped from the "Services" console o
|[Policy CSP - System](policy-csp-system.md)|Added the following new policies:<br>AllowCommercialDataPipeline, TurnOffFileHistory.|
|[Policy CSP - Troubleshooting](policy-csp-troubleshooting.md)|Added the following new policy:<br>AllowRecommendations.|
|[Policy CSP - Update](policy-csp-update.md)|Added the following new policies:<br>AutomaticMaintenanceWakeUp, ConfigureDeadlineForFeatureUpdates, ConfigureDeadlineForQualityUpdates, ConfigureDeadlineGracePeriod, ConfigureDeadlineNoAutoReboot.|
|[Policy CSP - WindowsLogon](policy-csp-windowslogon.md)|Added the following new policies:<br>AllowAutomaticRestartSignOn, ConfigAutomaticRestartSignOn, EnableFirstLogonAnimation.|
|[Policy CSP - WindowsLogon](policy-csp-windowslogon.md)|Added the following new policies:<br>AllowAutomaticRestartSignOn, ConfigAutomaticRestartSignOn, EnableFirstLogonAnimation.<br><br>Removed the following policy:<br>SignInLastInteractiveUserAutomaticallyAfterASystemInitiatedRestart. This policy is replaced by AllowAutomaticRestartSignOn.|
### April 2019

32
windows/security/information-protection/windows-information-protection/wip-learning.md
View File

@ -62,7 +62,13 @@ Once you have WIP policies in place, by using the WIP section of Device Health,
The information needed for the following steps can be found using Device Health, which you will first have to set up. Learn more about how you can [Monitor the health of devices with Device Health](https://docs.microsoft.com/windows/deployment/update/device-health-monitor).
1. In **Device Health** click the app you want to add to your policy and copy the publisher information.
1. In **Device Health** click the app you want to add to your policy and copy the **WipAppId**.
For example, if the app is Google Chrome, the WipAppId is:
`O=GOOGLE LLC, L=MOUNTAIN VIEW, S=CA, C=US\GOOGLE CHROME\CHROME.EXE\74.0.3729.108`
In the steps below, you separate the WipAppId by back slashes into the **PUBLISHER**, **PRODUCT NAME**, and **FILE** fields.
2. In Intune, click **App protection policies** and then choose the app policy you want to add an application to.
@ -74,12 +80,36 @@ The information needed for the following steps can be found using Device Health,
5. In **NAME** (optional), type the name of the app, and then in **PUBLISHER** (required), paste the publisher information that you copied in step 1 above.
For example, if the WipAppId is
`O=GOOGLE LLC, L=MOUNTAIN VIEW, S=CA, C=US\GOOGLE CHROME\CHROME.EXE\74.0.3729.108`
the text before the first back slash is the publisher:
`O=GOOGLE LLC, L=MOUNTAIN VIEW, S=CA, C=US`
![View of Add Apps app info entry boxes](images/wip-learning-app-info.png)
6. Type the name of the product in **PRODUCT NAME** (required) (this will probably be the same as what you typed for **NAME**).
For example, if the WipAppId is
`O=GOOGLE LLC, L=MOUNTAIN VIEW, S=CA, C=US\GOOGLE CHROME\CHROME.EXE\74.0.3729.108`
the text between the first and second back slashes is the product name:
`GOOGLE CHROME`
7. Copy the name of the executable (for example, snippingtool.exe) and paste it in **FILE** (required).
For example, if the WipAppId is
`O=GOOGLE LLC, L=MOUNTAIN VIEW, S=CA, C=US\GOOGLE CHROME\CHROME.EXE\74.0.3729.108`
the text between the second and third back slashes is the file:
`CHROME.EXE`
8. Type the version number of the app into **MIN VERSION** in Intune (alternately, you can specify the max version, but one or the other is required), and then select the **ACTION**: **Allow** or **Deny**
When working with WIP-enabled apps and WIP-unknown apps, it is recommended that you start with **Silent** or **Allow overrides** while verifying with a small group that you have the right apps on your allowed apps list. After you're done, you can change to your final enforcement policy, **Block**. For more information about WIP modes, see: [Protect enterprise data using WIP: WIP-modes](protect-enterprise-data-using-wip.md#bkmk-modes)

13
windows/security/threat-protection/microsoft-defender-atp/minimum-requirements.md
View File

@ -45,6 +45,16 @@ For a detailed comparison table of Windows 10 commercial edition comparison, see
For more information about licensing requirements for Microsoft Defender ATP platform on Windows Server, see [Protecting Windows Servers with Microsoft Defender ATP](https://techcommunity.microsoft.com/t5/Windows-Defender-ATP/Protecting-Windows-Server-with-Windows-Defender-ATP/ba-p/267114).
## Browser requirements
Access to Microsoft Defender ATP is done through a browser, supporting the following browsers:
- Microsoft Edge
- Internet Explorer version 11
- Google Chrome
>[!NOTE]
>While other browsers might work, the mentioned browsers are the ones supported.
## Hardware and software requirements
### Supported Windows versions
- Windows 7 SP1 Enterprise
@ -146,6 +156,9 @@ For more information on additional proxy configuration settings see, [Configure
Before you onboard machines, the diagnostic data service must be enabled. The service is enabled by default in Windows 10.
## Windows Defender Antivirus configuration requirement
The Microsoft Defender ATP agent depends on the ability of Windows Defender Antivirus to scan files and provide information about them.

10
windows/security/threat-protection/security-policy-settings/domain-member-disable-machine-account-password-changes.md
View File

@ -14,7 +14,7 @@ manager: dansimp
audience: ITPro
ms.collection: M365-security-compliance
ms.topic: conceptual
ms.date: 04/19/2017
ms.date: 06/27/2019
---
# Domain member: Disable machine account password changes
@ -39,19 +39,19 @@ Verify that the **Domain member: Disable machine account password changes** opti
### Best practices
1. Do not enable this policy setting. Machine account passwords are used to establish secure channel communications between members and domain controllers and between the domain controllers within the domain. After it is established, the secure channel transmits sensitive information that is necessary for making authentication and authorization decisions.
2. Do not use this policy setting in an attempt to support dual-boot scenarios that use the same machine account. If you want to dual-boot installations that are joined to the same domain, give the two installations different computer names. This policy setting was added to the Windows operating system to make it easier for organizations that stockpile pre-built computers that are put into production months later; those devices do not have to be rejoined to the domain.
3. You may consider using this policy setting in particular environments, such as the following:
2. Do not use this policy setting to try to support dual-boot scenarios that use the same machine account. If you want to configure dual-boot installations that are joined to the same domain, give the two installations different computer names. This policy setting was added to the Windows operating system to help organizations that stockpile pre-built computers that are put into production months later. Those devices do not have to be rejoined to the domain.
3. You may want to consider using this policy setting in specific environments, such as the following:
- Non-persistent Virtual Desktop Infrastructure implementations. In such implementations, each session starts from a read-only base image.
- Embedded devices that do not have write access to the OS volume.
In either of these cases, a password change that was made during normal operations would be lost as soon as the session ends. We strongly recommend that you plan password changes for maintenance windows. Add the password changes to the updates and modifications that Windows performs during maintenance windows. To trigger a password update on a particular OS volume, use the following command:
In either case, a password change that was made during normal operations would be lost as soon as the session ends. We strongly recommend that you plan password changes for maintenance windows. Add the password changes to the updates and modifications that Windows performs during maintenance windows. To trigger a password update on a specific OS volume, run the following command:
```
Nltest /sc_change_pwd:<AD DS domain name>
```
In this command, **\<AD DS domain name\>** represents the domain of the local computer. For more information about maintenance windows and non-persistent VDI implementations, see [Optimizing Windows 10, version 1803, for a Virtual Desktop Infrastructure (VDI) role: VDI optimization principles: Non-Persistent VDI](/windows-server/remote/remote-desktop-services/rds-vdi-recommendations-1803#vdi-optimization-principles).
In this command, \<AD DS domain name\> represents the domain of the local computer. For more information about maintenance windows and non-persistent VDI implementations, see [Optimizing Windows 10, version 1803, for a Virtual Desktop Infrastructure (VDI) role: VDI optimization principles: Non-Persistent VDI](/windows-server/remote/remote-desktop-services/rds-vdi-recommendations-1803#vdi-optimization-principles).
### Location

16
windows/security/threat-protection/security-policy-settings/domain-member-maximum-machine-account-password-age.md
View File

@ -14,7 +14,7 @@ manager: dansimp
audience: ITPro
ms.collection: M365-security-compliance
ms.topic: conceptual
ms.date: 05/31/2018
ms.date: 06/27/2019
---
# Domain member: Maximum machine account password age
@ -28,22 +28,22 @@ Describes the best practices, location, values, and security considerations for
The **Domain member: Maximum machine account password age** policy setting determines when a domain member submits a password change.
In Active Directory–based domains, each device has an account and password. By default, the domain members submit a password change every 30 days. You can extend or reduce this interval. Additionally, you can use the policy **Domain member: Disable machine account password changes** to disable the password change requirement altogether. However, before you consider this option, review the implications as described in [Domain member: Disable machine account password changes](domain-member-disable-machine-account-password-changes.md).
In Active Directory–based domains, each device has an account and password. By default, the domain members submit a password change every 30 days. You can extend or reduce this interval. Additionally, you can use the **Domain member: Disable machine account password changes** policy to disable the password change requirement completely. However, before you consider this option, review the implications as described in [Domain member: Disable machine account password changes](domain-member-disable-machine-account-password-changes.md).
> [!IMPORTANT]
> Significantly increasing the password change interval (or disabling password changes) gives a malicious user more time to undertake a brute-force password-guessing attack against one of the machine accounts.
> Significantly increasing the password change interval (or disabling password changes) gives an attacker more time to undertake a brute-force password-guessing attack against one of the machine accounts.
For more information, see [Machine Account Password Process](https://blogs.technet.microsoft.com/askds/2009/02/15/machine-account-password-process-2/).
For more information, see [Machine Account Password Process](https://techcommunity.microsoft.com/t5/Ask-the-Directory-Services-Team/Machine-Account-Password-Process/ba-p/396026).
### Possible values
- User-defined number of days between 1 and 999
- Not defined.
- User-defined number of days between 1 and 999, inclusive
- Not defined
### Best practices
1. It is often advisable to set **Domain member: Maximum machine account password age** to about 30 days. Setting the value to fewer days can increase replication and impact domain controllers. For example, in Windows NT domains, machine passwords were changed every 7 days. The additional replication churn would impact domain controllers in large organizations with many computers or slow links between sites.
2. Some organizations pre-build computers and then store them for later use or ship them to remote locations. When a computer starts after being offline more than 30 days, the Netlogon service will notice the password age and initiate a secure channel to a domain controller to change it. If the secure channel cannot be established, the computer will not authenticate with the domain. For this reason, some organizations might want to create a special organizational unit (OU) for computers that are prebuilt, and configure the value for this policy setting to a larger number of days.
1. We recommend that you set **Domain member: Maximum machine account password age** to about 30 days. Setting the value to fewer days can increase replication and affect domain controllers. For example, in Windows NT domains, machine passwords were changed every 7 days. The additional replication churn would affect domain controllers in large organizations that have many computers or slow links between sites.
2. Some organizations pre-build computers and then store them for later use or ship them to remote locations. When a computer is turned on after being offline more than 30 days, the Netlogon service notices the password age and initiates a secure channel to a domain controller to change it. If the secure channel cannot be established, the computer does not authenticate with the domain. For this reason, some organizations might want to create a special organizational unit (OU) for computers that are prebuilt, and then configure the value for this policy setting to a greater number of days.
### Location