Following up on a previous post for Azure Virtual WAN, one of the key items I brought up was that lack of integration for 3rd Party Network Virtual Appliances (NVA) and how you are encouraged to use Azure’s Firewall service. Well, as of today, July 21, 2020, you can now deploy NVA’s within the vWAN. This is great news, as many customers prefer 3rd party firewalls, ie. Palo Alto, CheckPoint, etc.
Looking forward to testing this out.
For more information, read up on the following post HERE.
Over the past few years I have been promoting customers to adopt the Microsoft/Azure’s Hub-Spoke (Hub and Spoke) network topology and its architecture. Not too long ago (Ignite 2019), Azure has made some significant improvements with their architecture and best practices by introducing “Virtual WAN“. I like to call this new service and evaluation as the new Hub-Spoke architecture version 2.0.
Azure Virtual WAN, or vWAN is a networking solution/service that allows you to integrate key functionalities such as networking, routing and security within a single pane. Azure vWAN is really a software-defined (SD) solution of WAN based technologies, and similar to service endpoints, and private links, Azure vWAN leverages the Microsoft network backbone to build a highly-available and high-speed global transit network. These functionalities include branch connectivity such as Site to Site VPNs, Point to Site VPN, ExpressRoute and intra-cloud/transitive networks, Azure Firewall and encrypted private connectivity.
Microsoft has made it simple with the options you get with Azure vWAN, either basic or standard. Once you deploy Azure vWAN, you can get started with one of the use cases (as mentioned above) and add functionalities as your network evolves.
With Basic, you can only leverage vWAN for a Site to Site VPN connection. However once you go to the Standard SKU, you can now leverage all of the functionalities mentioned above, ie. Site to Site, Point to Site, ExpressRoute and Inter-Hub and VNet to VNet transiting via the vHUB.
The image below depicts a high level but comprehensive with its capabilities on how Azure Virtual WAN can be integrated for various scenarios. With the “Any to Any” connectivity model, the Global transit network enables to connect your branch offices, remote users, datacenters, Azure VNets to one another. The image and model below, a spoke can be your Azure VNet, or a branch office, or a remote user, or perhaps the Internet. This architecture enables logical one-hop transit connectivity between the networking endpoints.
The Azure vWAN architecture is a hub and spoke architecture that incorporates scalability, resilience and performance built in for branches (VPN/SD-WAN devices), users (Azure VPN/OpenVPN/IKEv2), ExpressRoute circuits, and Azure virtual networks (VNets). There are some excellent benefits of using Azure Virtual WAN within your architecture as it simplifies the overall network topology and provides a handful of opportunities to integrate your on-premises datacenters, branch offices, remote users into a global transit network architecture. There are some limitations I can already see today, and that being not being able to leverage 3rd party network virtual appliances (NVA) such as Palo Alto, Checkpoint, etc., however I am sure that is already within the roadmap.
Recently a lot of folks have been asking about Azure Service Endpoints and Azure Private Links — what’s the difference? when to use which? and why?
For starters, let’s review what is a Service Endpoint, and what is a Private Link? Followed by which solution is better to use, and why….
With any Azure Virtual Network (VNet) you can leverage a ‘service endpoint’ that provides a secure connection and a direct connection to Microsoft Azure’s service over Microsoft’s backbone network infrastructure. The service endpoints allow you to run services/resources over the VNet and enables private IP Address within the VNet to communicate with the Azure service without the requirement of having a public IP on the VNet. Service Endpoints work by enabling your VNet or subnet(s) to support the Service Endpoint, and once enabled, you can configure which PaaS resource(s) can accept traffic from those subnet(s)/VNets. There is no requirement to do any IP filtering and/or NAT translation, all you need to tell is the PaaS resource(s) which VNet/Subnet to allow traffic from. When Service Endpoints are enabled, the PaaS resource sees traffic coming from your VNet private IP, not the public IP.
Azure Private Link allows you to access Azure (PaaS) services, like Key Vault, Storage, Log Analytics, etc., over a private endpoint within your Azure VNet. The communication between the Private Link (endpoint) and your VNet continue to travel over the Microsoft’s backbone network, however your service is no longer exposed over the Internet. One drawback with Private Link is that to support resolution of the PaaS resources using the same name, you do need to implement DNS to resolve the private link zone for that resource. There is integration with Azure Private DNS to set this up for you, but this can be problematic if you have your DNS service already running, or do not want to use Azure Private DNS with your VNet. Once enabled, you have now granted access to a specific PaaS resource within your VNet. Meaning, you can control the egress to the PaaS resource. Unlike Service Endpoints, Private Link allows access from your on-premises infrastructure to Azure resources over an ExpressRoute circuit, or Site to Site VPN tunnel, or via its peered VNets.
Ultimately, if you are considering either solution, Private Link versus Service Endpoint, then you are probably concerned with security and with that said, Private Link is superior to Service Endpoints. The services available to Private Link will continue to grow like Service Endpoints, but based on my observation, it appears Private Link has a much deeper portfolio with Azure services integration.
My personal notes, SCOM 2012 R2 Update Rollup 11 (UR11) has a lot of networking monitoring fixes, Linux/UNIX support and security fixes, along with more OMS integration. What is OMS, please go HERE. It is highly recommended to upgrade your lab/Dev environments first before upgrading your Production environment(s). The step by step procedures below are the steps I took and in no way shape or form do I accept responsibility for any data loss, and/or issues within your environment. It is advised to always take a backup of your SQL databases and/or snapshots of your SCOM environment(s). Please take these notes as suggestions. Always refer to Microsoft’s KB (posted above) for full documentation steps.
Here are the key updates for UR11 (source Microsoft):
Issues that are fixed in this update rollup can be found here, https://support.microsoft.com/en-us/kb/3183990
Once you are ready to begin your upgrade, it is recommend you do the following server/roles in the order below:
Once you have downloaded the rollup files, I like to extract and only keep the language I need, in this case, ENU (English). You will need to install these with Administrative rights, I like to use PowerShell as Local Administrator. It really does frustrate me, as there is no indication that the rollup installed correctly, (other than looking at the file version number change via File Explorer).
Personally, I prefer to execute the MSP files via PowerShell (RunAs Administrator) console.
Again, the order needs to be:
Once the rollups are installed, you will now need to apply the SQL scripts. First update the Data Warehouse, then followed by the OpsMgr DB.
The scripts can be found here, “%SystemDrive%\Program Files\System Center 2012 R2\Operations Manager\Server\SQL Script for Update Rollups”
Please note, the user executing these scripts needs to have read and write permissions to the database(s).
Once you have successfully executed the SQL scripts, you will now need to import the updated Management Packs (MP). These MPs can be found here, “%SystemDrive%\Program Files\System Center 2012 R2\Operations Manager\Server\Management Packs for Update Rollups“.
You will need to import the following MPs, please see below:
Once the MPs have been imported, you should now go back to your Pending Management view, under the Administrations pane, and update all servers.
And that is that! You are now on the latest and greatest System Center release for SCOM 2012 R2.
So you’ve spun up a Windows 2012R2 machine with Hyper-V installed and ready to go. However, now you’re stuck and not sure which type of Network Virtual Switch (vSwitch) applies to your environment(s)…
In Windows 2012R2, Hyper-V’s network virtual switch runs at Layer 2 (Data Link layer). If you are unfamiliar with this, or either terms, I suggest good old Wikipedia. 🙂 Layer 2 maintains a MAC address table contains the MAC addresses of all the virtual machines (VMs) connected to it. The switch determines where to direct/redirect the packets to based on MAC addresses. It should be noted, in Hyper-V, you can have an unlimited amount of VMs connected to this vSwitch.
In Hyper-V you have three types of Network Virtual Switches: External, Internal and Private. All have similar functions but are disgustingly different.
Without the use of SCVMM (System Center Virtual Machine Manager), I have found there are two ways to go about creating a vSwitch, one via Hyper-V GUI and second via PowerShell.
Let’s start with the GUI:
Launch the Hyper-V console, and right-click on the Hypervisor’s Virtual Switch Manager. Now selecting New virtual network switch, you can specify your properties here. Name your vSwitch, associate to the correct vNIC, tag to the appropriate VLAN ID, etc.
You can now specify which vSwitch for your guest VM to use. Within the VMs properties, you will have the option to chose within the Virtual Switch (you will need to create a Network Adapter if not already done). Once selected you can specify your VLAN ID here. (I am finding you cannot specify the VLAN within the Management vSwitch, but it must be done on the client VM’s end) *Again, this is without the use of SCVMM..yet*
The same process above can be automated via PowerShell. If you’re like me and need to provision a few dozen Hyper-V hosts, creating vSwitches via the GUI is rather tedious. This can be automated with PowerShell (and SCVMM). Please see the code below:
First you will need to get a list of all the Network Adapters your Hyper-V host has to offer. Hopefully you have named them, if you have not, I highly suggest doing this, and considering this best practice and keeping your sanity.
Once you have the list of vNICs and their names, you can go ahead and start creating vSwitches.
If the code below worked (note only Line 6 is needed to create the External vSwitch) your Hyper-V host should have the vSwitch, or something similar:
SCOM & Other Geeky Stuff 
