Merge pull request #108274 from MicrosoftDocs/repo_sync_working_branch

huypub · web-flow · commit e76276bda03e · 2020-03-19T09:51:13.000-07:00
Confirm merge from repo_sync_working_branch to master to sync with https://github.com/Microsoft/azure-docs (branch master)
diff --git a/articles/active-directory/devices/hybrid-azuread-join-control.md b/articles/active-directory/devices/hybrid-azuread-join-control.md
@@ -40,7 +40,7 @@ Use the Active Directory Services Interfaces Editor (ADSI Edit) to modify the SC
 1. Launch the **ADSI Edit** desktop application from and administrative workstation or a domain controller as an Enterprise Administrator.
 1. Connect to the **Configuration Naming Context** of your domain.
 1. Browse to **CN=Configuration,DC=contoso,DC=com** > **CN=Services** > **CN=Device Registration Configuration**
-1. Right click on the leaf object under **CN=Device Registration Configuration** and select **Properties**
+1. Right click on the leaf object **CN=62a0ff2e-97b9-4513-943f-0d221bd30080** and select **Properties**
    1. Select **keywords** from the **Attribute Editor** window and click **Edit**
    1. Select the values of **azureADId** and **azureADName** (one at a time) and click **Remove**
 1. Close **ADSI Edit**
diff --git a/articles/active-directory/saas-apps/planview-enterprise-one-tutorial.md b/articles/active-directory/saas-apps/planview-enterprise-one-tutorial.md
@@ -88,7 +88,7 @@ Follow these steps to enable Azure AD SSO in the Azure portal.
     `https://<SUBDOMAIN>.pvcloud.com/planview`
 
 	> [!NOTE]
-	> These values are not real. Update these values with the actual Sign on URL and Identifier. Contact [Planview Enterprise One Client support team](mailto:hostingsupport@planview.com) to get these values. You can also refer to the patterns shown in the **Basic SAML Configuration** section in the Azure portal.
+	> These values are not real. Update these values with the actual Sign on URL and Identifier. Contact [Planview Enterprise One Client support team](mailto:customercare@planview.com) to get these values. You can also refer to the patterns shown in the **Basic SAML Configuration** section in the Azure portal.
 
 1. On the **Set up single sign-on with SAML** page, in the **SAML Signing Certificate** section,  find **Federation Metadata XML** and select **Download** to download the certificate and save it on your computer.
 
@@ -130,11 +130,11 @@ In this section, you'll enable B.Simon to use Azure single sign-on by granting a
 
 ## Configure Planview Enterprise One SSO
 
-To configure single sign-on on **Planview Enterprise One** side, you need to send the downloaded **Federation Metadata XML** and appropriate copied URLs from Azure portal to [Planview Enterprise One support team](mailto:hostingsupport@planview.com). They set this setting to have the SAML SSO connection set properly on both sides.
+To configure single sign-on on **Planview Enterprise One** side, you need to send the downloaded **Federation Metadata XML** and appropriate copied URLs from Azure portal to [Planview Enterprise One support team](mailto:customercare@planview.com). They set this setting to have the SAML SSO connection set properly on both sides.
 
 ### Create Planview Enterprise One test user
 
-In this section, you create a user called B.Simon in Planview Enterprise One. Work with [Planview Enterprise One support team](mailto:hostingsupport@planview.com) to add the users in the Planview Enterprise One platform.Users must be created and activated before you use single sign-on.
+In this section, you create a user called B.Simon in Planview Enterprise One. Work with [Planview Enterprise One support team](mailto:customercare@planview.com) to add the users in the Planview Enterprise One platform.Users must be created and activated before you use single sign-on.
 
 ## Test SSO 
 
diff --git a/articles/azure-monitor/insights/container-insights-health-monitors-config.md b/articles/azure-monitor/insights/container-insights-health-monitors-config.md
@@ -57,7 +57,7 @@ Azure Monitor for containers includes a number of key monitoring scenarios that
 |Container memory utilization |Unit monitor |This monitor reports combined health status of the Memory utilization(RSS) of the instances of the container.<br> It performs a simple comparison that compares each sample to a single threshold, and specified by the configuration parameter **ConsecutiveSamplesForStateTransition**.<br> Its state is calculated as the worst state of 90% of the container (StateThresholdPercentage) instances, sorted in descending order of severity of container health state (that is, Critical, Warning, Healthy).<br> If no record is received from a container instance, then the health state of the container instance is reported as **Unknown**, and has higher precedence in the sorting order over the **Critical** state.<br> Each individual container instance's state is calculated using the thresholds specified in the configuration. If the usage is over critical threshold (90%), then the instance is in a **Critical** state, if it is less than critical threshold (90%) but greater than warning threshold (80%), then the instance is in a **Warning** state. Otherwise, it is in **Healthy** state. |ConsecutiveSamplesForStateTransition<br> FailIfLessThanPercentage<br> StateThresholdPercentage<br> WarnIfGreaterThanPercentage| 3<br> 90<br> 90<br> 80 ||
 |Container CPU utilization |Unit monitor |This monitor reports combined health status of the CPU utilization of the instances of the container.<br> It performs a simple comparison that compares each sample to a single threshold, and specified by the configuration parameter **ConsecutiveSamplesForStateTransition**.<br> Its state is calculated as the worst state of 90% of the container (StateThresholdPercentage) instances, sorted in descending order of severity of container health state (that is, Critical, Warning, Healthy).<br> If no record is received from a container instance, then the health state of the container instance is reported as **Unknown**, and has higher precedence in the sorting order over the **Critical** state.<br> Each individual container instance's state is calculated using the thresholds specified in the configuration. If the usage is over critical threshold (90%), then the instance is in a **Critical** state, if it is less than critical threshold (90%) but greater than warning threshold (80%), then the instance is in a **Warning** state. Otherwise, it is in **Healthy** state. |ConsecutiveSamplesForStateTransition<br> FailIfLessThanPercentage<br> StateThresholdPercentage<br> WarnIfGreaterThanPercentage| 3<br> 90<br> 90<br> 80 ||
 |System workload pods ready |Unit monitor |This monitor reports status based on percentage of pods in ready state in a given workload. Its state is set to **Critical** if less than 100% of the pods are in a **Healthy** state |ConsecutiveSamplesForStateTransition<br> FailIfLessThanPercentage |2<br> 100 ||
-|Kube API status |Unit monitor |This monitor reports status of Kube Api service. Monitor is in critical state in case Kube Api endpoint is unavailable. For this particular monitor, the state is determined by making a query to the 'nodes' endpoint for the kube-api server. Anything other than an OK response code changes the monitor to a **Critical** state. | No configuration properties |||
+|Kube API status |Unit monitor |This monitor reports status of Kube API service. Monitor is in critical state in case Kube API endpoint is unavailable. For this particular monitor, the state is determined by making a query to the 'nodes' endpoint for the kube-api server. Anything other than an OK response code changes the monitor to a **Critical** state. | No configuration properties |||
 
 ### Aggregate monitors
 
diff --git a/articles/azure-monitor/platform/media/metrics-charts/018.png b/articles/azure-monitor/platform/media/metrics-charts/018.png
diff --git a/articles/azure-monitor/platform/metrics-charts.md b/articles/azure-monitor/platform/metrics-charts.md
@@ -107,6 +107,16 @@ To control the y-axis range, use the “…” chart menu, and select **Edit cha
 > [!WARNING]
 > Locking the boundaries of y-axis for the charts that track various counts or sums over a period of time (and thus use count, sum, minimum, or maximum aggregations) usually requires specifying a fixed time granularity rather than relying on the automatic defaults. This is necessary is because the values on charts change when the time granularity is automatically modified by the user resizing browser window or going from one screen resolution to another. The resulting change in time granularity effects the look of the chart, invalidating current selection of y-axis range.
 
+## Change colors of chart lines
+
+After you configure the charts, the chart lines are automatically assigned a color from a default palette. You can change those colors.
+
+To change the color of a chart line, click on the colored bar in the legend that corresponds to the chart. The color picker dialog will open. Use the color picker to configure the color for the line.
+
+After the chart colors are configured, they will remain that way when you pin the chart to a dashboard. The following section shows you how to pin a chart.
+
+![metric image](./media/metrics-charts/018.png)
+
 ## Pin charts to dashboards
 
 After configuring the charts, you may want to add it to the dashboards so that you can view it again, possibly in context of other monitoring telemetry, or share with your team.
diff --git a/articles/data-explorer/k2bridge.md b/articles/data-explorer/k2bridge.md
@@ -106,33 +106,35 @@ By default, K2Bridges's Helm chart references a publicly available image located
         ```bash
         helm install kibana elastic/kibana -n k2bridge --set image=docker.elastic.co/kibana/kibana-oss --set imageTag=6.8.5 --set elasticsearchHosts=http://k2bridge:8080
         ```
+        
     1. Use port forwarding to access Kibana on localhost: 
 
         ```bash
         kubectl port-forward service/kibana-kibana 5601 --namespace k2bridge
         ```
+        
     1. Connect to Kibana by browsing to http://127.0.0.1:5601.
 
     1. Expose Kibana to the end users. There are multiple methods to do so. The method you use largely depends on your use case.
 
         For example:
 
-        Expose the service as a LoadBalancer service. To do so, add the following parameter to the K2Bridge Helm install command ([above](#install-k2bridge-chart)):
-
-        `--set service.type=LoadBalancer`
+        Expose the service as a LoadBalancer service. To do so, add the `--set service.type=LoadBalancer` parameter to the K2Bridge Helm install command ([above](#install-k2bridge-chart)).        
     
         Then run:
-
-           ```bash
-           kubectl get service -w -n k2bridge
-           ```   
+        
+        ```bash
+        kubectl get service -w -n k2bridge
+        ```
+        
         The output should look like: 
 
         ```bash
         NAME            TYPE           CLUSTER-IP     EXTERNAL-IP   PORT(S)          AGE
         kibana-kibana   LoadBalancer   xx.xx.xx.xx   <pending>      5601:30128/TCP   4m24s
         ```
-        You can then use the generated EXTERNAL-IP that appears, and use it to access Kibana by opening a browser to: `\<EXTERNAL-IP>:5601`.
+ 
+        You can then use the generated EXTERNAL-IP that appears, and use it to access Kibana by opening a browser to `<EXTERNAL-IP>:5601`.
 
 1. Configure index patterns to access your data:  
 In a new Kibana instance:
