Merge remote-tracking branch 'refs/remotes/origin/master' into live

This commit is contained in:
LizRoss 2017-01-27 10:01:15 -08:00
commit 4d9992331a
8 changed files with 90 additions and 28 deletions

View File

@ -13,7 +13,9 @@ localizationpriority: medium
# Microsoft Surface Hub
Documents related to the Microsoft Surface Hub.
Documents related to deploying and managing the Microsoft Surface Hub in your organization.
>[Looking for the user's guide for Surface Hub?](https://www.microsoft.com/surface/support/surface-hub)
## In this section

View File

@ -844,17 +844,16 @@ The second Windows Server 2012 R2 VHD needs to be expanded in size from 40GB to
![ISE](images/ISE.png)
19. Click **File**, click **Save As**, and save the commands as **c:\VHD\pc1.ps1** on the Hyper-V host.
20. In the (lower) terminal input window, type the following command to copy the script to PC1 using integration services:
20. In the (lower) terminal input window, type the following commands to enable Guest Service Interface on PC1 and then use this service to copy the script to PC1:
<pre style="overflow-y: visible">
Enable-VMIntegrationService -VMName PC1 -Name "Guest Service Interface"
Copy-VMFile "PC1" SourcePath "C:\VHD\pc1.ps1" DestinationPath "C:\pc1.ps1" CreateFullPath FileSource Host
</pre>
>In order for this command to work properly, PC1 must be running the vmicguestinterface (Hyper-V Guest Service Interface) service. If this service is not installed, you can try updating integration services on the VM by mounting the Hyper-V Integration Services Setup (vmguest.iso), which is located in C:\Windows\System32 on Windows Server 2012 and 2012 R2 operating systems that are running the Hyper-V role service. You can also try running the following command from an elevated Windows PowerShell prompt on the Hyper-V host:
>In order for this command to work properly, PC1 must be running the vmicguestinterface (Hyper-V Guest Service Interface) service. If this service is not enabled in this step, then the copy-VMFile command will fail. In this case, you can try updating integration services on the VM by mounting the Hyper-V Integration Services Setup (vmguest.iso), which is located in C:\Windows\System32 on Windows Server 2012 and 2012 R2 operating systems that are running the Hyper-V role service.
<pre style="overflow-y: visible">Enable-VMIntegrationService -VMName PC1 -Name "Guest Service Interface"</pre>
If the copy-vmfile command does not work and you cannot properly enable or upgrade integration services on PC1, then create the file c:\pc1.ps1 on the VM by typing the commands into this file manually. The copy-vmfile command is only used in this procedure as a demonstration. After typing the script file manually, be sure to save the file as a Windows PowerShell script file with the .ps1 extension and not as a text (.txt) file.
If the copy-vmfile command does not work and you cannot properly enable or upgrade integration services on PC1, then create the file c:\pc1.ps1 on the VM by typing the commands into this file manually. The copy-vmfile command is only used in this procedure as a demonstration of automation methods that can be used in a Hyper-V environment when enhanced session mode is not available. After typing the script file manually, be sure to save the file as a Windows PowerShell script file with the .ps1 extension and not as a text (.txt) file.
21. On PC1, type the following commands at an elevated Windows PowerShell prompt:
@ -865,7 +864,7 @@ The second Windows Server 2012 R2 VHD needs to be expanded in size from 40GB to
>The commands in this script might take a few moments to complete. If an error is displayed, check that you typed the command correctly, paying close attention to spaces. PC1 is removed from its domain in this step while not connected to the corporate network so as to ensure the computer object in the corporate domain is unaffected. PC1 is also not renamed to "PC1" in system properties so that it maintains some of its mirrored identity. However, if desired you can also rename the computer.
22. Upon completion of the script, PC1 will automatically restart. When it has restarted, sign in to the contoso.com domain using the **Switch User** option, with the **user1** account you created in step 11 of this section.
>**Important**: The settings that will be used later to migrate user data specifically select only accounts that belong to the CONTOSO domain. However, this can be changed to migrate all use accounts, or only other specific accounts. If you wish to test migration of user data and settings with accounts other than those in the CONTOSO domain, you must specify these accounts or domains when you configure the value of **ScanStateArgs** in the MDT test lab guide. This value is specifically called out when you get to that step. If you wish to only migrate CONTOSO accounts, then you can log in with the user1 account or the administrator account at this time and modify some of the files and settings for later use in migration testing.
>**Important**: The settings that will be used later to migrate user data specifically select only accounts that belong to the CONTOSO domain. However, this can be changed to migrate all user accounts, or only other specified accounts. If you wish to test migration of user data and settings with accounts other than those in the CONTOSO domain, you must specify these accounts or domains when you configure the value of **ScanStateArgs** in the MDT test lab guide. This value is specifically called out when you get to that step. If you wish to only migrate CONTOSO accounts, then you can log in with the user1 account or the administrator account at this time and modify some of the files and settings for later use in migration testing.
23. Minimize the PC1 window but do not turn it off while the second Windows Server 2012 R2 VM (SRV1) is configured. This verifies that the Hyper-V host has enough resources to run all VMs simultaneously. Next, SRV1 will be started, joined to the contoso.com domain, and configured with RRAS and DNS services.
24. On the Hyper-V host computer, at an elevated Windows PowerShell prompt, type the following commands:

View File

@ -197,7 +197,7 @@
###### [Monitor claim types](monitor-claim-types.md)
##### [Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
###### [Audit Credential Validation](audit-credential-validation.md)
####### [Event 4774 S: An account was mapped for logon.](event-4774.md)
####### [Event 4774 S, F: An account was mapped for logon.](event-4774.md)
####### [Event 4775 F: An account could not be mapped for logon.](event-4775.md)
####### [Event 4776 S, F: The computer attempted to validate the credentials for an account.](event-4776.md)
####### [Event 4777 F: The domain controller failed to validate the credentials for an account.](event-4777.md)

View File

@ -42,7 +42,7 @@ The main reason to enable this auditing subcategory is to handle local accounts
**Events List:**
- [4774](event-4774.md)(S): An account was mapped for logon.
- [4774](event-4774.md)(S, F): An account was mapped for logon.
- [4775](event-4775.md)(F): An account could not be mapped for logon.

View File

@ -1,6 +1,6 @@
---
title: 4774(S) An account was mapped for logon. (Windows 10)
description: Describes security event 4774(S) An account was mapped for logon.
description: Describes security event 4774(S, F) An account was mapped for logon.
ms.pagetype: security
ms.prod: w10
ms.mktglfcycl: deploy
@ -8,14 +8,13 @@ ms.sitesec: library
author: Mir0sh
---
# 4774(S): An account was mapped for logon.
# 4774(S, F): An account was mapped for logon.
**Applies to**
- Windows 10
- Windows Server 2016
It appears that this event never occurs.
Success events do not appear to occur. Failure event [has been reported](http://forum.ultimatewindowssecurity.com/Topic7313-282-1.aspx).
***Subcategory:***&nbsp;[Audit Credential Validation](audit-credential-validation.md)
@ -23,7 +22,7 @@ It appears that this event never occurs.
*An account was mapped for logon.*
*Authentication Package:%1*
*Authentication Package:Schannel*
*Account UPN:%2*

View File

@ -22,8 +22,8 @@ Credential Manager is a place where credentials in the OS are can be stored for
For VPN, the VPN stack saves its credential as the session default.
For WiFi, EAP does it.
The credentials are put in Credential Manager as a "`*Session`" credential.
A "`*Session`" credential implies that it is valid for the current user session.
The credentials are put in Credential Manager as a "\*Session" credential.
A "\*Session" credential implies that it is valid for the current user session.
The credentials are also cleaned up when the WiFi or VPN connection is disconnected.
When the user tries to access a domain resource, using Edge for example, Edge has the right Enterprise Authentication capability so [WinInet](https://msdn.microsoft.com/library/windows/desktop/aa385483.aspx) can release the credentials that it gets from the Credential Manager to the SSP that is requesting it.

View File

@ -29,8 +29,8 @@ You can use these tools to configure access to Windows Store: AppLocker or Group
## <a href="" id="block-store-applocker"></a>Block Windows Store using AppLocker
Applies to: Windows 10 Enterprise, Windows 10 Education, Windows 10 Mobile
Applies to: Windows 10 Enterprise, Windows 10 Mobile
AppLocker provides policy-based access control management for applications. You can block access to Windows Store app with AppLocker by creating a rule for packaged apps. You'll give the name of the Windows Store app as the packaged app that you want to block from client computers.
@ -59,7 +59,10 @@ For more information on AppLocker, see [What is AppLocker?](../keep-secure/what-
## <a href="" id="block-store-group-policy"></a>Block Windows Store using Group Policy
Applies to: Windows 10 Enterprise, version 1511
Applies to: Windows 10 Enterprise, version 1511, Windows 10 Education
> [!Note]
> Not supported on Windows 10 Pro.
You can also use Group Policy to manage access to Windows Store.
@ -89,7 +92,7 @@ When your MDM tool supports Windows Store for Business, the MDM can use these CS
For more information, see [Configure an MDM provider](configure-mdm-provider-windows-store-for-business.md).
## Show private store only using Group Policy
Applies to Windows 10 Enterprise, version 1607.
Applies to Windows 10 Enterprise, version 1607, Windows 10 Education
If you're using Windows Store for Business and you want employees to only see apps you're managing in your private store, you can use Group Policy to show only the private store. Windows Store app will still be available, but employees can't view or purchase apps. Employees can view and install apps that the admin has added to your organization's private store.

View File

@ -18,33 +18,67 @@ localizationpriority: high
> **Looking for consumer information?** See [Windows Update: FAQ](https://support.microsoft.com/help/12373/windows-update-faq)
You can use Group Policy settings or mobile device management (MDM) to configure when devices will restart after a Windows 10 update is installed. You can schedule update installation and set policies for restart, configure active hours for when restarts will not occur, or you can do both.
You can use Group Policy settings, mobile device management (MDM) or Registry (not recommended) to configure when devices will restart after a Windows 10 update is installed. You can schedule update installation and set policies for restart, configure active hours for when restarts will not occur, or you can do both.
## Schedule update installation
When you set the **Configure Automatic Updates** policy to **Auto download and schedule the install**, you also configure the day and time for installation or you specify that installation will occur during the automatic maintenance time (configured using **Computer Configuration\Administrative Templates\Windows Components\Maintenance Scheduler**).
In Group Policy, within **Configure Automatic Updates**, you can configure a forced restart after a specified instllation time.
When **Configure Automatic Updates** is enabled, you can enable one of the following additional policies to manage device restart:
To set the time, you need to go to **Configure Automatic Updates**, select option **4 - Auto download and schedule the instal**, and then enter a time in the **Scheduled install time** dropdown. Alternatively, you can specify that installtion will occur during the automatic maintenance time (configured using **Computer Configuration\Administrative Templates\Windows Components\Maintenance Scheduler**).
**Always automatically restart at the scheduled time** forces a restart after the specified installation time and lets you configure a timer to warn a signed-in user that a restart is going to occur.
While not recommended, the same result can be achieved through Registry. Under **HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate\AU**, set **AuOptions** to **4**, set the install time with **ScheduledInstallTime**, enable **AlwaysAutoRebootAtScheduledTime** and specify the delay in minutes through **AlwaysAutoRebootAtScheduledTimeMinutes**. Similar to Group Policy, **AlwaysAutoRebootAtScheduledTimeMinutes** sets the timer to warn a signed-in user that a restart is going to occur.
For a detailed description of these regsitry keys, see [Registry keys used to manage restart](#registry-keys-used-to-manage-restart).
## Delay automatic reboot
When **Configure Automatic Updates** is enabled in Group Policy, you can enable one of the following additional policies to delay an automatic reboot after update installtion:
- **Turn off auto-restart for updates during active hours** prevents automatic restart during active hours.
- **Always automatically restart at the scheduled time** forces a restart after the specified installation time and lets you configure a timer to warn a signed-in user that a restart is going to occur. To set the time, you need to go **Configure Automatic Updates**, select option **4 - Auto download and schedule the install**, and then enter a time in the **Scheduled install time** dropdown.
- **No auto-restart with logged on users for scheduled automatic updates installations** prevents automatic restart when a user is signed in. If a user schedules the restart in the update notification, the device will restart at the time the user specifies even if a user is signed in at the time. This policy only applies when **Configure Automatic Updates** is set to option **4-Auto download and schedule the install**.
You can also use Registry, to prevent automatic restarts when a user is signed in. Under **HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate\AU**, set **AuOptions** to **4** and enable **NoAutoRebootWithLoggedOnUsers**. As with Group Policy, if a user schedules the restart in the update notification, it will override this setting.
For a detailed description of these regsitry keys, see [Registry keys used to manage restart](#registry-keys-used-to-manage-restart).
## Configure active hours
You can configure active hours for devices without setting the **Configure Automatic Updates** policy. *Active hours* identify the period of time when you expect the device to be in use. Automatic restarts after an update will occur outside of the active hours.
*Active hours* identify the period of time when you expect the device to be in use. Automatic restarts after an update will occur outside of the active hours.
By default, active hours are from 8 AM to 5 PM on PCs and from 5 AM to 11 PM on phones. Users can change the active hours manually. Additionally, administrators can use Group Policy or MDM to set active hours for managed devices.
By default, active hours are from 8 AM to 5 PM on PCs and from 5 AM to 11 PM on phones. Users can change the active hours manually.
Administrators can use multiple ways to set active hours for managed devices:
- You can use Group Policy, as described in the procedure that follows.
- You can use MDM, as described in [Configuring active hours with MDM](#configuring-active-hours-with-mdm).
- While not recommended, you can also configure active hours, as descrbied in [Configuring active hours through Registry](#configuring-active-hours-through-registry).
### Configuring active hours with Group Policy
To configure active hours using Group Policy, go to **Computer Configuration\Administrative Templates\Windows Components\Windows Update** and open the **Turn off auto-restart for updates during active hours** policy setting. When the policy is enabled, you can set the start and end times for active hours.
![Use Group Policy to configure active hours](images/waas-active-hours-policy.png)
### Configuring active hours with MDM
MDM uses the [Update/ActiveHoursStart and Update/ActiveHoursEnd](https://msdn.microsoft.com/library/windows/hardware/dn904962.aspx#Update_ActiveHoursEnd) settings in the [Policy CSP](https://msdn.microsoft.com/library/windows/hardware/dn904962.aspx) to configure active hours.
To configure active hours manually on a single device, go to **Settings** > **Update & security** > **Windows Update** and select **Change active hours**.
### Configuring active hours through Registry
![Change active hours](images/waas-active-hours.png)
This method is not recommended, and should only be used when neither Group Policy or MDM are available.
Any settings configured through Registry may conflict with any existing configuration that uses any of the methods mentioned above.
You should set a combination of the following registry values, in order to configure active hours.
Under **HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate** use **SetActiveHours** to enable or disable active hours and **ActiveHoursStart**,**ActiveHoursEnd** to specify the range of active hours.
For a detailed description of these regsitry keys, see [Registry keys used to manage restart](#registry-keys-used-to-manage-restart).
>[!NOTE]
>To configure active hours manually on a single device, go to **Settings** > **Update & security** > **Windows Update** and select **Change active hours**.
>
>![Change active hours](images/waas-active-hours.png)
## Limit restart delays
@ -65,11 +99,36 @@ In the Group Policy editor, you will see a number of policy settings that pertai
| Reschedule Automatic Updates scheduled installations | ![no](images/crossmark.png) | |
>[!NOTE]
>You can only choose one path for restart behavior.
>
>If you set conflicting restart policies, the actual restart behavior may not be what you expected.
## Registry keys used to manage restart
The following tables list registry values that correspond to the Group Policy settings for controlling restarts after updates in Windows 10.
**HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate**
| Registry key | Key type | Value |
| --- | --- | --- |
| ActiveHoursEnd | REG_DWORD | 0-23: set active hours to end at a specific hour</br>starts with 12 AM (0) and ends with 11 PM (23) |
| ActiveHoursStart | REG_DWORD | 0-23: set active hours to start at a specific hour</br>starts with 12 AM (0) and ends with 11 PM (23) |
| SetActiveHours | REG_DWORD | 0: disable automatic restart after updates outside of active hours</br>1: enable automatic restart after updates outside of active hours |
**HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate\AU**
| Registry key | Key type | Value |
| --- | --- | --- |
| AlwaysAutoRebootAtScheduledTime | REG_DWORD | 0: disable automatic reboot after update installation at scheduled time</br>1: enable automatic reboot after update installation at ascheduled time |
| AlwaysAutoRebootAtScheduledTimeMinutes | REG_DWORD | 15-180: set automatic reboot to occur after given minutes |
| AUOptions | REG_DWORD | 2: notify for download and automatically install updates</br>3: automatically download and notify for instllation of updates</br>4: Automatically download and schedule installation of updates</br>5: allow the local admin to configure these settings</br>**Note:** To configure restart behavior, set this value to **4** |
| NoAutoRebootWithLoggedOnUsers | REG_DWORD | 0: disable do not reboot if users are logged on</br>1: do not reboot after an update installation if a user is logged on</br>**Note:** If disabled : Automatic Updates will notify the user that the computer will automatically restarts in 5 minutes to complete the installation |
| ScheduledInstallTime | REG_DWORD | 0-23: schedule update installation time to a specific hour</br>starts with 12 AM (0) and ends with 11 PM (23) |
There are 3 different registry combination for controlling restart:
- To set active hours, **SetActiveHours** should be **1**, while **ActiveHoursStart** and **ActiveHoursEnd** should define the time range.
- To schedule a specific instllation and reboot time, **AUOptions** should be **4**, **ScheduledInstallTime** should specify the installation time, **AlwaysAutoRebootAtScheduledTime** set to **1** and **AlwaysAutoRebootAtScheduledTimeMinutes** should specify number of minutes to wait before rebooting.
- To delay rebooting if a user is logged on, **AUOptions** should be **4**, while **NoAutoRebootWithLoggedOnUsers** is set to **1**.
## Related topics