ExpressRoute Direct VS FastPath VS Global Reach

ExpressRoute Direct

ExpressRoute Direct gives you the ability to connect directly into Microsoft’s global network at peering locations strategically distributed around the world. ExpressRoute Direct provides dual 100 Gbps or 10-Gbps connectivity, which supports Active/Active connectivity at scale. You can work with any service provider for ER Direct.

ExpressRoute FastPath

ExpressRoute virtual network gateway is designed to exchange network routes and route network traffic. FastPath is designed to improve the data path performance between your on-premises network and your virtual network. When enabled, FastPath sends network traffic directly to virtual machines in the virtual network, bypassing the gateway.

ExpressRoute Global Reach

ExpressRoute Global Reach is designed to complement your service provider’s WAN implementation and connect your branch offices across the world. For example, if your service provider primarily operates in the United States and has linked all of your branches in the U.S., but the service provider doesn’t operate in Japan and Hong Kong, with ExpressRoute Global Reach you can work with a local service provider and Microsoft will connect your branches there to the ones in the U.S. using ExpressRoute and our global network.

ExpressRoute Private Peering VS Microsoft Peering in Azure

 

Azure Private Peering

Azure compute services, namely virtual machines (IaaS) and cloud services (PaaS), that are deployed within a virtual network can be connected through the private peering domain. The private peering domain is considered to be a trusted extension of your core network into Microsoft Azure. You can set up bi-directional connectivity between your core network and Azure virtual networks (VNets). This peering lets you connect to virtual machines and cloud services directly on their private IP addresses. You can connect more than one virtual network to the private peering domain.

Microsoft Peering

Connectivity to Microsoft online services (Microsoft 365 and Azure PaaS services) occurs through Microsoft peering. We enable bi-directional connectivity between your WAN and Microsoft cloud services through the Microsoft peering routing domain. You must connect to Microsoft cloud services only over public IP addresses that are owned by you or your connectivity provider and you must adhere to all the defined rules.

The recommended configuration is that private peering is connected directly to the core network, and the public and Microsoft peering links are connected to your DMZ.

Availability Sets VS Availability Zones in Azure

Availability Sets

Availability Sets is for virtual machine only. When you configure virtual machine with availability sets, it will make a copy of your virtual machine in isolated separate physical server, compute rack, storage units and network switches within a single datacentre within an Azure Region.

Availability Zones

Availability Zones can be use by many Azure Services including virtual machine. With Availably Zones, your workload will be spread out across the different zones that make up an Azure region. An Azure region is made up of multiple datacentres and each zone is made up of one or more datacentres.  Each datacentre is equipped with independent power, cooling and networking.

Availability Zone has better SLA compare to Availability Sets

Azure AD Connect account usage

Azure AD Connect uses 3 accounts in order to synchronize information from on-premises or Windows Server Active Directory to Azure Active Directory. These accounts are:

• AD DS Connector account: used to read/write information to Windows Server Active Directory

• ADSync service account: used to run the synchronization service and access the SQL database

• Azure AD Connector account: used to write information to Azure AD

In addition to these three accounts used to run Azure AD Connect, you will also need the following additional accounts to install Azure AD Connect. These are:

• Local Administrator account: The administrator who is installing Azure AD Connect and who has local Administrator permissions on the machine.

• AD DS Enterprise Administrator account: Optionally used to create the “AD DS Connector account” above.

• Azure AD Global Administrator account: used to create the Azure AD Connector account and configure Azure AD. 

• SQL SA account (optional): used to create the ADSync database when using the full version of SQL Server. This SQL Server may be local or remote to the Azure AD Connect installation. This account may be the same account as the Enterprise Administrator. Provisioning the database can now be performed out of band by the SQL administrator and then installed by the Azure AD Connect administrator with database owner rights.

Cannot Start Azure ATP or Defender for Identity Services when using gMSA

Description:

You are deploying Azure Advanced Threat Protection (AATP) or Microsoft Defender for Identity (MDI) in your Multi-Domain Single-Forest IT environment. You plan to use gMSA account for the Defender for Identity services account when communicating to Active Directory. 

You have created a new universal group or domain local group and add all of the Domain Controllers in the Forest to that group. You also have created the gMSA account and configured that group to be able to retrieve password and use the gMSA account.

However when you configure MDI to use the gMSA account, the Sensor Services on the Domain Controllers cannot be start.

Resolution:

Make sure you have Restarted the Domain Controllers that you put inside the new universal or domain local group. After the Domain Controller restart, try to login and notice that Azure ATP Sensor Services will be able to start properly. Delayed start is expected for Azure ATP services.