PR review fixes

Author: jonburchel

articles/data-factory/concepts-linked-services.md

@@ -118,10 +118,7 @@ Linked services can be created in the Azure Data Factory UX via the [management
 
 You can create linked services by using one of these tools or SDKs: [.NET API](quickstart-create-data-factory-dot-net.md), [PowerShell](quickstart-create-data-factory-powershell.md), [REST API](quickstart-create-data-factory-rest-api.md), [Azure Resource Manager Template](quickstart-create-data-factory-resource-manager-template.md), and [Azure portal](quickstart-create-data-factory-portal.md).
 
-> When creating a linked service, the user needs appropriate authorization to the designated service. If sufficient access is not granted, the user will not be able to see the available resources and will need to use manual entry option, as shown in the screenshot:
-
-:::image type="content" source="media/concepts-linked-services/manual-account-entry.png" alt-text="Screenshot showing the manual account entry option on the account selection dialog.":::
-
+When creating a linked service, the user needs appropriate authorization to the designated service. If sufficient access is not granted, the user will not be able to see the available resources and will need to use manual entry option.
 
 ## Data store linked services
 

articles/data-factory/create-self-hosted-integration-runtime.md

@@ -227,11 +227,11 @@ Here are details of the application's actions and arguments:
 > [!NOTE]
 > Release Notes are available on the same [Microsoft integration runtime download page](https://www.microsoft.com/download/details.aspx?id=39717).
 
-## Service account for Self-hosted integration runtime
+## Service account for self-hosted integration runtime
 
-The default log on service account of Self-hosted integration runtime is **NT SERVICE\DIAHostService**. You can see it in **Services -> Integration Runtime Service -> Properties -> Log on**.
+The default log on service account of the self-hosted integration runtime is **NT SERVICE\DIAHostService**. You can see it in **Services -> Integration Runtime Service -> Properties -> Log on**.
 
-:::image type="content" source="media/create-self-hosted-integration-runtime/shir-service-account.png" alt-text="Service account for Self-hosted integration runtime":::
+:::image type="content" source="media/create-self-hosted-integration-runtime/shir-service-account.png" alt-text="Service account for self-hosted integration runtime":::
 
 Make sure the account has the permission of Log on as a service. Otherwise self-hosted integration runtime can't start successfully. You can check the permission in **Local Security Policy -> Security Settings -> Local Policies -> User Rights Assignment -> Log on as a service**
 
@@ -287,7 +287,7 @@ When the processor and available RAM aren't well utilized, but the execution of
 >
 > Data movement in transit from a self-hosted IR to other data stores always happens within an encrypted channel, regardless of whether or not this certificate is set.
 
-### Credential Sync
+### Credential sync
 If you don't store credentials or secret values in an Azure Key Vault, the credentials or secret values will be stored in the machines where your self-hosted integration runtime locates. Each node will have a copy of credential with certain version. In order to make all nodes work together, the version number should be the same for all nodes. 
 
 ## Proxy server considerations
@@ -377,7 +377,7 @@ If you see error messages like the following ones, the likely reason is improper
 
   ```output
   Unable to connect to the remote server
-  A component of Integration Runtime has become unresponsive and restarts automatically. Component name: Integration Runtime (Self-hosted).
+  A component of Integration Runtime has become unresponsive and restarts automatically. Component name: Integration Runtime (self-hosted).
   ```
 
 ### Enable remote access from an intranet
@@ -457,7 +457,7 @@ There are two ways to store the credentials when using self-hosted integration r
 This is the recommended way to store your credentials in Azure. The self-hosted integration runtime can directly get the credentials from Azure Key Vault which can highly avoid some potential security issues or any credential in-sync problems between self-hosted integration runtime nodes.
 2. Store credentials locally.
 The credentials will be push to the machine of your self-hosted integration runtime and be encrypted. 
-When your self-hosted integration runtime is recovered from crash, you can either recover credential from the one you backup before or edit linked service and let the credential be pushed to self-hosted integration runtime again. Otherwise, the pipeline doesn't work due to the lack of credential when running via self-hosted integration runtime.
+When your self-hosted integration runtime is recovered from crash, you can either recover credential from the one you back up before or edit linked service and let the credential be pushed to self-hosted integration runtime again. Otherwise, the pipeline doesn't work due to the lack of credential when running via self-hosted integration runtime.
 > [!NOTE]
 > If you prefer to store the credential locally, your need to put the domain for interactive authoring in the allowlist of your firewall 
 > and open the port. This channel is also for the self-hosted integration runtime to get the credentials. 
@@ -471,9 +471,9 @@ You can install the self-hosted integration runtime by downloading a Managed Ide
 - Regularly back up the credentials associated with the self-hosted integration runtime.
 - To automate self-hosted IR setup operations, refer to [Set up an existing self hosted IR via PowerShell](#setting-up-a-self-hosted-integration-runtime).
 
-## Important Considerations
+## Important considerations
 
-When installing Self-Hosted Integration Runtime consider following
+When installing a self-hosted integration runtime consider following
 
 - Keep it close to your data source but not necessarily on the same machine
 - Don't install it on the same machine as Power BI gateway