fixing

Author: billmath

articles/active-directory/hybrid/concept-adsync-service-account.md

@@ -48,7 +48,7 @@ Legend:
 - Local account - Local user account on the server 
 - Domain account - Domain user account 
 - sMSA - [standalone Managed Service account](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd548356(v=ws.10))
-- gMSA - [group Managed Service account](/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/hh831782(v=ws.11)) 
+- gMSA - [group managed service account](/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/hh831782(v=ws.11)) 
 
 |Machine type |**LocalDB</br> Express**|**LocalDB/LocalSQL</br> Custom**|**Remote SQL</br> Custom**|
 |-----|-----|-----|-----|
@@ -67,7 +67,7 @@ The Virtual Service Account can't be used on a Domain Controller due to [Windows
 
 ## Managed Service Account 
 
-If you use a remote SQL Server, then we recommend to using a group managed service account. For more information on how to prepare your Active Directory for group Managed Service account, see [Group Managed Service Accounts Overview](/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/hh831782(v=ws.11)). 
+If you use a remote SQL Server, then we recommend to using a group managed service account. For more information on how to prepare your Active Directory for group managed service account, see [Group Managed Service Accounts Overview](/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/hh831782(v=ws.11)). 
 
 To use this option, on the [Install required components](how-to-connect-install-custom.md#install-required-components) page, select **Use an existing service account**, and select **Managed Service Account**. 
 

articles/active-directory/hybrid/how-to-connect-health-alert-catalog.md

@@ -47,7 +47,7 @@ Azure AD Connect Health alerts get resolved on a success condition. Azure AD Con
 ## Alerts for Active Directory Federation Services
 | Alert Name | Description | Remediation |
 | --- | --- | ----- |
-|Test Authentication Request (Synthetic Transaction) failed to obtain a token | The test authentication requests (Synthetic Transactions) initiated from this server has failed to obtain a token after 5 retries. This may be caused due to transient network issues, AD DS Domain Controller availability or a mis-configured AD FS server.  As a result, authentication requests processed by the federation service may fail. The agent uses the Local Computer Account context to obtain a token from the Federation Service. | Ensure that the following steps are taken to validate the health of the server.<ol><li>Validate that there are no additional unresolved alerts for this or other AD FS servers in your farm.</li><li>Validate that this condition isn't a transient failure by logging on with a test user from the AD FS login page available at https://{your_adfs_server_name}/adfs/ls/idpinitiatedsignon.aspx</li><li>Go to <a href="https://testconnectivity.microsoft.com">https://testconnectivity.microsoft.com</a> and choose the ‘Office 365’ tab. Perform the ‘Office 365 Single Sign-On Test’.</li><li>Verify if your AD FS service name can be resolved from this server by executing the following command from a command prompt on this server. nslookup your_adfs_server_name</li></ol><p>If the service name can't be resolved, refer to the FAQ section for instructions of adding a HOST file entry of your AD FS service with the IP address of this server. This will allow the synthetic transaction module running on this server to request a token</p> | 
+|Test Authentication Request (Synthetic Transaction) failed to obtain a token | The test authentication requests (Synthetic Transactions) initiated from this server has failed to obtain a token after 5 retries. This may be caused due to transient network issues, AD DS Domain Controller availability or a mis-configured AD FS server.  As a result, authentication requests processed by the federation service may fail. The agent uses the Local Computer Account context to obtain a token from the Federation Service. | Ensure that the following steps are taken to validate the health of the server.<ol><li>Validate that there are no additional unresolved alerts for this or other AD FS servers in your farm.</li><li>Validate that this condition isn't a transient failure by logging on with a test user from the AD FS login page available at https://{your_adfs_server_name}/adfs/ls/idpinitiatedsignon.aspx</li><li>Go to <a href="https://testconnectivity.microsoft.com">https://testconnectivity.microsoft.com</a> and choose the ‘Office 365’ tab. Perform the ‘Office 365 single sign-on Test’.</li><li>Verify if your AD FS service name can be resolved from this server by executing the following command from a command prompt on this server. nslookup your_adfs_server_name</li></ol><p>If the service name can't be resolved, refer to the FAQ section for instructions of adding a HOST file entry of your AD FS service with the IP address of this server. This will allow the synthetic transaction module running on this server to request a token</p> | 
 | The proxy server can't reach the federation server | This AD FS proxy server is unable to contact the AD FS service. As a result, authentication requests processed by this server will fail. | Perform the following steps to validate the connectivity between this server and the AD FS service. <ol><li> Ensure that the firewall between this server and the AD FS service is configured accurately. </li><li> Ensure that DNS resolution for the AD FS service name appropriately points to the AD FS service that resides within the corporate network. This can be achieved through a DNS server that serves this server in the perimeter network or through entries in the HOSTS files for the AD FS service name. </li><li> Validate the network connectivity by opening up the browser on this server and accessing the federation metadata endpoint, which is at `https://<your-adfs-service-name>/federationmetadata/2007-06/federationmetadata.xml` </li> | 
 | The SSL Certificate is about to expire | The TLS/SSL certificate used by the Federation servers is about to expire within 90 days. Once expired, any requests that require a valid TLS connection will fail. For example, for Microsoft 365 customers, mail clients won't be able to authenticate. | Update the TLS/SSL certificate on each AD FS server.<ol><li>Obtain the TLS/SSL certificate with the following requirements.<ol type="a"><li>Enhanced Key Usage is at least Server Authentication. </li><li>Certificate Subject or Subject Alternative Name (SAN) contains the DNS name of the Federation Service or appropriate wild card. For example: sso.contoso.com or *.contoso.com</li></ol></li><li>Install the new TLS/SSL certificate on each server in the local machine certificate store.</li><li>Ensure that the AD FS Service Account has read access to the certificate's Private Key</li></ol></p><p><b>For AD FS 2.0 in Windows Server 2008R2:</b><ul><li>Bind the new TLS/SSL certificate to the web site in IIS, which hosts the Federation Service. Note that you must perform this step on each Federation Server and Federation Server proxy.</li></ul></p><p><b>For AD FS in Windows Server 2012 R2 and later versions:</b> <li>  Refer to <a href="/windows-server/identity/ad-fs/operations/manage-ssl-certificates-ad-fs-wap">Managing SSL Certificates in AD FS and WAP </a> </li> | 
 | AD FS service isn't running on the server | Active Directory Federation Service (Windows Service) isn't running on this server. Any requests targeted to this server will fail. | To start the Active Directory Federation Service (Windows Service):<ol><li>Log on to the server as an administrator.</li><li> Open services.msc</li><li>Find "Active Directory Federation Services". </li><li>Right-click and select "Start". | 

articles/active-directory/hybrid/plan-connect-design-concepts.md

@@ -55,7 +55,7 @@ If you've a single forest on-premises, then the attribute you should use is **ob
 
 If you've multiple forests and don't move users between forests and domains, then **objectGUID** is a good attribute to use even in this case.
 
-If you move users between forests and domains, then you must find an attribute that doesn't change or can be moved with the users during the move. A recommended approach is to introduce a synthetic attribute. An attribute that could hold something that looks like a GUID would be suitable. During object creation, a new GUID is created and stamped on the user. A custom sync rule can be created in the sync engine server to create this value based on the **objectGUID** and update the selected attribute in ADDS. When you move the object, make sure to also copy the content of this value.
+If you move users between forests and domains, then you must find an attribute that doesn't change or can be moved with the users during the move. A recommended approach is to introduce a synthetic attribute. An attribute that could hold something that looks like a GUID would be suitable. During object creation, a new GUID is created and stamped on the user. A custom sync rule can be created in the sync engine server to create this value based on the **objectGUID** and update the selected attribute in AD DS. When you move the object, make sure to also copy the content of this value.
 
 Another solution is to pick an existing attribute you know doesn't change. Commonly used attributes include **employeeID**. If you consider an attribute that contains letters, make sure there's no chance the case (upper case vs. lower case) can change for the attribute's value. Bad attributes that shouldn't be used include those attributes with the name of the user. In a marriage or divorce, the name is expected to change, which isn't allowed for this attribute. This is also one reason why attributes such as **userPrincipalName**, **mail**, and **targetAddress** aren't even possible to select in the Azure AD Connect installation wizard. Those attributes also contain the "\@" character, which isn't allowed in the sourceAnchor.
 

articles/active-directory/hybrid/plan-hybrid-identity-design-considerations-identity-adoption-strategy.md

@@ -94,7 +94,7 @@ You must also be aware of what capabilities won't be available:
 This task defines the tools that will be used to synchronize the organization’s on-premises data to the cloud and what topology you should use.  Because, most organizations use Active Directory, information on using Azure AD Connect to address the questions above is provided in some detail.  For environments that don't have Active Directory, there's information about using FIM 2010 R2 or MIM 2016 to help plan this strategy.  However, future releases of Azure AD Connect will support LDAP directories, so depending on your timeline, this information may be able to assist.
 
 ### Synchronization tools
-Over the years, several synchronization tools have existed and used for various scenarios.  Currently Azure AD Connect is the go to tool of choice for all supported scenarios.  AAD Sync and DirSync are also still around and may even be present in your environment now. 
+Over the years, several synchronization tools have existed and used for various scenarios.  Currently Azure AD Connect is the go to tool of choice for all supported scenarios.  Azure AD Sync and DirSync are also still around and may even be present in your environment now. 
 
 > [!NOTE]
 > For the latest information regarding the supported capabilities of each tool, read [Directory integration tools comparison](plan-hybrid-identity-design-considerations-tools-comparison.md) article.  
@@ -122,7 +122,7 @@ The multi-forest single Azure AD topology should be considered if the following
 
 * Users have only 1 identity across all forests – the uniquely identifying users section below describes this scenario in more detail.
 * The user authenticates to the forest in which their identity is located
-* UPN and Source Anchor (immutable id) will come from this forest
+* UPN and Source Anchor (immutable ID) will come from this forest
 * All forests are accessible by Azure AD Connect – meaning it does not need to be domain joined and can be placed in a DMZ.
 * Users have only one mailbox
 * The forest that hosts a user’s mailbox has the best data quality for attributes visible in the Exchange Global Address List (GAL)