![Adding N:N Relationships in Sub-grids correctly in Dynamics 365 CRM | [Quick Tip]](https://www.drware.com/wp-content/uploads/2021/03/cropped-cropped-21688204_10213848566435612_2978963762468624084_o.jpg)
Here’s how you can correctly show the N:N relationships in sub-grids on the entity forms.
Brought to you by Dr. Ware, Microsoft Office 365 Silver Partner, Charleston SC.
This article is contributed. See the original author and article here.
Hi,
Azure networking can sometimes give headaches. Here are a few tips which may make your life easier.
When enabling Azure Private Link for a given resource, say a Storage Account, you may end up with the following configuration
where you have routed all traffic to Azure Firewall (or an NVA) and noticed that the VM (or anything else) is directly connecting to the private endpoint, bypassing the firewall…This might come as a surprise to you but this is due to the fact that whenever you enable private link for a given resource, a direct (more specific) route is propagated to the underlying NICs. In the above example, Azure will write the 10.1.5.4/32 route to the NIC(s) of the VM pointing directly to the InterfaceEndpoint of the resource. Because this route is more specific than 0.0.0.0/0, the firewall will be bypassed. To overcome this, you have to write a /32 route to the subnet’s route table to overwrite the one written by Azure, which can be itself challenging because of the 400 routes limit per route table. Microsoft wrote a good guidance on that topic.
Ok, now you think you understood private link routing, right? So what about this?
You thought Azure was pushing a route to underlying NICs but you realize that the VM in VNET 3 does not have such a route…Why is that? Well, it makes sense but you do not especially think about it. The reason why VNET 3’s VM does not get the route is because VNET 3 is not peered with VNET 1. Because peering is non-transitive, writing such a route would anyway lead to a dead-end. So, if you had a 0.0.0.0/0 UDR on VNET 3’s subnet, this would this time be correctly routed to the firewall…So as you guessed it, if you put a private endpoint in an intermediate VNET:
this time, the /32 route is propagated to all peered VNETs. Long story short, putting private endpoints into the hub, would propagate into every spoke, and thus, you’d better follow the guidance if you want to route that to the firewall.
Ok great, that’s for routing but fortunately, we don’t have to worry about NSGs. Well…
How come VM2 is able to connect to my private endpoint??? My deny all rule should have kicked in..What’s going on here? Well, for the same reason as before, the InterfaceEndpoint is non-sensitive to NSGs. So, you must make sure to route things correctly to make sure, the InterfaceEndpoint is not used.
Well, I’m sorry for you if you read the first 3 episodes because all of that is *almost* part of the past…but you will surely still likely see this for quite a while. Microsoft has revamped the way private link works, and there is a preview (UDR) and preview (NSG) available (not in all regions), which allows you to deal with private link traffic, like with any other type of traffic, but meanwhile, you’d better still understand how it currently works :).
Repeat after me:
– Private link is inbound traffic only
– Private link is inbound traffic only
– Private…(well you got it, right?)
I still see a huge confusion with many folks about private link, where people think that enabling private link for an app service, APIM, etc. will give them access to the resources sitting in a given VNET. That is wrong, to gain access to such resources, you have to focus on outbound traffic, not inbound!
Remember one rule of thumb: private link does not automatically deny public traffic for all services. It does for some but not for all. So, remember to always double-check that public traffic is indeed correctly denied.
Whenever you establish private connectivity between your datacenter and Azure, you will use the hub vnet to bridge both worlds. You’re likely going to have (not mandatory) a VPN Gateway to establish a S2S and/or Expressroute connection. From there on, each spoke VNET should be able to connect to your on-premises systems and vice-versa. You, of course, want to make sure, traffic is routed through your firewall. If you encounter a different behavior (traffic directly flying from on-prem to spoke and vice versa), you’re likely forgot to deactivate the “propagate gateway routes” property of the route table.
So, make sure to turn it off :).
Many companies struggle to decide whether they want to implement Azure CNI (now BYO CNI is available) or Kubenet for their AKS clusters. The main reason is the shortage of IP addresses. Kubenet is IP-friendly because it only allocates IPs to nodes, while CNI allocates one IP per pod, which results in many more consumed IPs. You can use Kubenet if you’re willing to fully embrace a programmable network approach such as the use of Service Meshes and internet Network Policies (Calico for ex. which also works with Kubenet). However, if you plan to rely on Azure networking capabilities, such as using NSGs and the likes, then you’d better switch to CNI. Consider the following scenario:
where you want to share the same cluster for multiple tenants but you want to isolate tenants in their own node pool. So, in the above scenario, you only want system to be able to connect to tenants but tenant 1 and tenant 2 cannot talk together. You do not trust logical isolation (K8s network policies & service meshes) and want to rule this with Network Security Groups instead, or even combine both. Easy, you simply add the following inbound rules to tenant 1 & tenant 2’s NSGs:
– Priority: 100 – source IP: 10.0.0.0/28 destination: * – ALLOW (let’s skip the ports for sake of simplicity)
– Priority: 110 – source IP: * destination: * – DENY
So, that way, this should fly…Well, it appears that this won’t fly at all. Why is that? Because Kubenet makes use of network address translation (NAT) to allocate POD CIDRs dynamically, and what the NSGs see are not the subnet ranges but the POD CIDRs…, which can change at any time. Indeed, Azure constantly rewrites the route table associated to the subnets to map POD CIDRs with nodes, whenever the cluster restarts or whenever a node gets added/removed to/from a node pool. Therefore, you can’t predict how this allocation will be done, which defeats the use of NSGs to rule internal traffic. Of course, you could still use them to rule what comes from outside.
Did you know that you can use the keyword localhost in APIM policies? If you have a set of APIs and want APIM to let them call each other while never leaving the boundaries of APIM itself (not resolve again the IP through the DNS), you can use localhost…
Whenever you encounter a network issue in Azure, I recommend you to use Network Watcher and more specifically, its next hop feature. It helped me already a few times figure out what was misconfigured.
This article is contributed. See the original author and article here.
Hello hello, MTC! The first week of August is in the books, so let’s see what went down in the Community.
MTC Moments of the Week
We had a great AMA in the Community this week that focused on Azure Deployments, featuring @Mark Gray, @adotfrank, @stephanieyen, and @stevenjma with @Eric Starker moderating. As a quick reminder, an AMA is a live text-based online event similar to a “YamJam” on Yammer or an “Ask Me Anything” on Reddit, and there is no audio or video component at this time.
Over on the blogs, @lucyhitz announced the general availability of Microsoft Viva Goals, “a goal-setting and management solution that aligns teams to your organization’s strategic priorities, driving results and a thriving business.” Head over to the post to watch an overview and learn more!
We also want to give a shoutout this week to @ScottLamond, a new MTC’er, for providing several helpful responses in the Excel Community! Welcome and keep being awesome! :)
Unanswered Questions – Can you help them out?
Every week, users come to the MTC seeking guidance or technical support for their Microsoft solutions, and we want to help highlight a few of these each week in the hopes of getting these questions answered by our amazing community!
@Jenny_Bruce is seeking advice from the Community about compliance policies and document version history limits in SharePoint Online.
Meanwhile, @JohnHogan20224k is encountering an error in the Microsoft 365 admin center having to do with Teams for Organization, so maybe you can help figure out what’s causing it.
Next Week – Mark your calendars!
Lastly, we have no events next week, but check back soon for updates!
Have a great weekend, everyone!
This article is contributed. See the original author and article here.
This is a follow-up post on a recently published article on sharing data in near real-time with Microsoft Purview in-place data sharing for Azure Storage. I highly encourage you to read Share data near real-time with Microsoft Purview in-place data sharing for Azure Storage first before you pore over this article on how to share Azure storage solutions such as Azure Blob Storage and Azure Data Lake Gen2 with VNET traffic restrictions or even with no public endpoints i.e. private endpoints only.
Now, using Microsoft Purview in place data share you can also create shares that can connect to Azure storage PaaS such as blob storage and data lake storage with VNET restrictions and to further up the ante – even with storage accounts with no public endpoints.
This is a critical feature that has been made available only in Microsoft Purview data share and is not part of the standalone Azure data share services.
In this article, I will present a few quick pointers and considerations that you have to know before you get started with Purview data sharing using restricted Azure storage accounts.
Premise – Share data with Microsoft Purview for Azure storage with private endpoints or VNET restrictions.
Solution – In a nutshell, with Purview private endpoints i.e. account, ingestion, and portal (being optional) you can deliver new data shares while connecting to storage accounts with VNET restrictions and/or no public endpoint i.e. private endpoints only. This assumes that the private endpoint for the storage account and purview are created in the same VNET or, this is created in a networking landing zone in case you follow the learnings of the enterprise scale landing zone.
Here’s a quick overview of key steps which will help you set up a data share with restricted storage accounts –
Step 1 – Create purview private endpoints i.e. account, ingestion, and portal (being optional). This is required for private connectivity between Purview and target storage accounts. This is a required step regardless of how the storage account is configured i.e. with VNET restrictions or with no public endpoint.
You can create the private endpoints in the same VNET i.e. of storage account or in a dedicated VNET which may be part of your networking scaffold in the enterprise scale landing zone. Make sure the different networks i.e. Purview VNET and storage account VNET is peered if you were to follow this topology.
You can also learn more about this configuration here – Connect to your Microsoft Purview to data sources privately and securely
Here’s a quick overview of a typical Purview deployment with private endpoints enabled.
Step 2 – Depending on the storage account networking configuration, let’s break this section into 2 sub parts –
#1 Deliver data share from a storage account with VNET restrictions
This setup assumes that you have storage accounts with VNET restrictions and in-bound traffic from only selected VNET’s are permitted. In this case, you can create Purview endpoints in the same VNET as of storage account or in a separate VNET as long as both are peered.
You can read more about this configuration here – Configure Azure Storage firewalls and virtual networks
#2 Deliver data share from a storage account with private endpoints only
This setup assumes that you have storage accounts with no public endpoints and the only way an application can communicate is via private endpoints only. In this case, you will have to create private endpoints for the storage account in a VNET which is accessible by Purview via ingestion private endpoints. So, this can be done in the same VNET as Purview ingestion private endpoints or in a VNET that is accessible and peered to Purview private endpoints in case of enterprise scale landing zone.
If you create a private endpoint for the Data Lake Storage Gen2 storage resource, then you should also create one for the Blob storage resource. That’s because operations that target the Data Lake Storage Gen2 endpoint might be redirected to the Blob endpoint. By creating a private endpoint for both resources, you ensure that operations can complete successfully.
You can read more about this configuration here – Use private endpoints – Azure Storage
Step 3 (optional) – I always recommend running nslookup for querying the Domain Name System (DNS) records to obtain the mapping between domain name and IP address. The expectation here is that the name resolution for the storage account and Purview endpoints should return their respective private IP addresses.
If you have followed these steps, with appropriate permissions on the storage account via RBAC’s you can then deliver new data shares with your consumer groups with restricted storage accounts which earlier was not possible using Azure data share.
My objective for this post was to introduce you to how you can connect and deliver share with storage accounts that have network restrictions such as VNET restrictions and private endpoints only. Hence, I would not talk about the user journey or customer experience regarding how to create and manage a share. I encourage you to read our post on this subject at How to share data – Microsoft Purview.
Here’s how you read a value from Array variable based on Index value
Brought to you by Dr. Ware, Microsoft Office 365 Silver Partner, Charleston SC.
Recent Comments