Merged PR 6732: Merge DHAppLogin to master

PM says go ahead and publish. Hopefully in today's PM push to Live.

windows/deployment/update/device-health-using.md

@@ -4,7 +4,7 @@ description: Explains how to begin usihg Device Health.
 ms.prod: w10
 ms.mktglfcycl: deploy
 ms.sitesec: library
-ms.date: 10/10/2017
+ms.date: 03/21/20178
 ms.pagetype: deploy
 author: jaimeo
 ---
@@ -90,6 +90,142 @@ Clicking a listed driver on the Driver-Induced OS Crashes blade opens a driver p
 The driver version table can help you determine whether deploying a newer version of the driver might help you reduce the crash rate. In the example shown above, the most commonly installed driver version (19.15.1.5) has a crash rate of about one-half of one percent--this is low, so this driver is probably fine. However, driver version 19.40.0.3 has a crash rate of almost 20%. If that driver had been widely deployed, updating it would substantially reduce the overal number of crashes in your organization.
 
 
+## App Reliability
+
+The App Reliability report shows you useful data on app usage and behavior so that you can identify apps that are misbehaving and then take steps to resolve the problem.
+
+### App reliability events
+
+The default view includes the **Devices with events** count, which shows the number of devices in your organization that have logged a reliability event for a given app over the last 14 days. A "reliability event" occurs when an app either exits unexpectedly or stops responding. The table also includes a **Devices with Usage** count. This enables you to see how widely used the app was over the same period to put the Devices with Events count into perspective.
+
+![Main App Reliability view](images/app-reliability-main.png)
+
+When you click a particular app, the detailed **App reliability** view opens. The first element in the view is the App Information summary:
+
+![App reliability view with columns for app name, publisher, devices with usage, devices with events, percentage of devices with events logged for that app, and percentage of devices with events as a "commercial average"](images/app-reliability-app-detail.png)
+
+This table contains:
+
+- App name
+- Publisher
+- Devices with usage: the number of unique devices that logged any usage of the app
+- Devices with events: the number of unique devices that logged any reliability event for the app
+- % with events: the ratio of "devices with events" to "devices with usage"
+- % with events (commercial average): the ratio of "devices with events" to "devices with usage" in data collected from deployments with a mix of operating system versions and device models that is similar to yours. This can help you decide if a given app is having problems specifically in your environment or more generally in many environments.
+
+#### Trend section
+Following the App Information summary is the trend section:
+
+![Trend view](images/app-reliability-trend-view.png)
+
+With these trend graphs you can more easily detect if an issue is growing, shrinking, or steady. The trend graph on the left shows the number of devices that logged any reliability event for the app. The trend graph on the right shows the ratio of "devices with events" to "devices with usage."
+
+Each graph displays two lines:
+
+- Trailing window: in this line, each day’s value reflects reliability events that occurred in the 14 days leading up to that day. This is useful for gauging the long-term trend with reduced volatility due to weekends and small populations.
+- Single day: Each day’s value reflects reliability events that occurred in a single day. This is useful if an issue is quickly emerging (or being resolved).
+
+#### App and OS versions table
+The next element in the view is the App and OS versions table:
+
+
+![App/OS version view](images/app-reliability-app-OS-version.png)
+
+This table breaks out the metrics by combinations of App and OS version. This enables you to identify patterns in that might indicate devices needing an update or configuration change.
+
+For example, if the table shows that a later version of an app is more reliable than an earlier version in your environment, then prioritizing deployment of the later version is likely the best path forward. If you are already running the latest version of the app, but reliability events are increasing, then you might need to do some troubleshooting, or seek support from Microsoft or the app vendor.
+
+By default the table is limited to the most-used version combinations in your environment. To see all version combinations click anywhere in the table.
+
+
+#### Reliability event history table
+
+The next element in the view is the reliability event history table:
+
+![event history view](images/app-reliability-event-history.png)
+
+This table shows the most detailed information. Although Device Health is not a debugging tool, the details available in this table can help with troubleshooting by providing the specific devices, versions, and dates of the reliability events.
+
+This view also includes the **Diagnostic Signature** column. This value can be helpful when you are working with product support or troubleshooting on your own. The value (also known as Failure ID or Failure Name) is the same identifier used to summarize crash statistics for Microsoft and partner developers.
+
+The Diagnostic Signature value contains the type of reliability event, error code, DLL name, and function name involved. You can use this information to narrow the scope of troubleshooting. For example, a value like *APPLICATION_HANG_ThreadHang_Contoso-Add-In.dll!GetRegistryValue()* implies that the app stopped responding when Contoso-Add-In was trying to read a registry value. In this case you might prioritize updating or disabling the add-in, or using Process Monitor to identify the registry value it was trying to read, which could lead to a resolution through antivirus exclusions, fixing missing keys, or similar remedies.
+
+
+By default the table is limited to a few recent rows. To see all rows click anywhere in the table.
+
+
+### FAQs and limitations
+
+#### Why does a particular app not appear in the views?
+When we allow reliability events from all processes, the list of apps fills with noisy processes which don't feel like meaningful end-user apps (for example, taskhost.exe or odd-test-thing.exe). In order to draw focus to the apps which matter most to users, App Reliability uses a series of filters to limit what appears in the list. The filter criteria include the following:
+
+- Filter out background processes which have no detected user interaction.
+- Filter out operating system processes which, despite having user interaction, do not feel like apps (for example, Logonui.exe, Winlogon.exe). **Known limitation:** Some processes which may feel like apps are not currently detected as such (and are therefore filtered out as OS processes). These include Explorer.exe, Iexplore.exe, Microsoftedge.exe, and several others.
+- Remove apps which are not widely used in your environment. **Known limitation:** This might result in an app that you consider important being filtered out when that app is not among the 30 most widely used in your environment.
+
+
+We welcome your suggestions and feedback on this filtering process at the [Device Health Tech Community](https://aka.ms/community/DeviceHealth).
+
+#### Why are there multiple names and entries for the same app?
+For example, you might see *Skype for Business*, *‘skype for business’*, and *Lync* listed separately, but you only use *Skype for Business*. Or you might see *MyApp Pro* and *MyApp Professional* listed separately, even though they feel like the same thing.
+
+
+
+#### Clicking an app in the App Reliability Events blade sometimes results a List view of records instead of the App Reliability view
+To work around this, click the **App Reliability** tab above the results to see the expected view.
+ 
+![Click app reliability tab](images/app-reliability-tab.png)
+
+
+#### Clicking "See all…" from the App Reliability Events blade followed by clicking an app from the expanded list results in raw records instead of the App Reliability view
+To work around this, replace all of the text in the Log Search query box with the following:
+
+*DHAppReliability | where AppFileDisplayName == "<Name of app as it appeared in the list>"*
+
+For example:
+
+*DHAppReliability | where AppFileDisplayName == "Microsoft Outlook"*
+
+
+
+## Login Health
+
+Login Health provides reports on Windows login attempts in your environment, including metrics on the login methods being used (such as Windows Hello, face recognition, fingerprint recognition, PIN, or password), the rates and patterns of login success and failure, and the specific reasons logins have failed.
+
+The Login Health blades appear in the Device Health dashboard:
+
+
+![Main Login health view](images/login-health.png)
+
+### Login Errors
+The **Login errors** blade displays data on the frequency and type of errors, with statistics on specific errors. They are generally categorized into user-generated (caused by bad input) or non-user-generated (might need IT intervention) errors. Click any individual error to see all instances of the error's occurence for the specified time period.
+
+### Login Metrics by Type
+The **Login metrics by type** blade shows the success rate for your devices, as well as the success rate for other environments with a mix of operating system versions and device models similar to yours (the **Commercial average success rate**).
+
+In the table (by type) you can gauge how broadly each login type is attempted, the number of devices that prefer the type (most used), and the success rate. If migration from passwords to an alternative such as Hello: PIN is going well, you would see high usage and high success rates for the new type.
+
+Click any of the login types to see detailed login health data for that type:
+
+![Login type detail](images/login-health-detail.png)
+
+This view shows trends over time of usage, preferred credentials, and success rate along with the most frequent errors and frequently failing devices for that login type.
+
+Click a specific login error in this view to see a list of all instances for that error and login type within the specified time range:
+
+![Login error detail](images/login-health-detail-failure.png)
+
+Included in this view are device attributes and error attributes such as the following:
+
+- LogonStatus/LogonSubStatus: Status code for the login attempt
+- SignInFailureReason: Known failure reasons evaluated from status or sub-status
+- SuggestedSignInRemediation: Suggested remediation that was presented to the user at the time of error
+
+The filters in the left pane allow you to filter errors to a particular operating system, device model, or other parameters. Alternatively, clicking the most frequently failing models from the Login Health perspective will take you to a list of error instances filtered to the login type and specified device model within the specified time range.
+
+>[!NOTE]
+> Windows Hello: Face authentication errors are not currently included in the login health reports.
+