Category: Azure

Happy Retirement SCOM GSM (Global Service Monitor)

Earlier this month, Microsoft announced that the SCOM’s (Operations Manager) GSM (Global Service Monitor) will officially call it quits and retire the service, effectively, November 7th, 2018. As it is a sad day for us, long-time SCOM administrators, the future remains bright, as Microsoft makes way for Application Insights. Over the last year or so, I have done numerous presentations and conferences on Azure’s Application Insights (App Insights), and demonstrating the natural evolution from SCOM APM to Azure App Insights. However, before we start talking about Azure’s App Insights, we need to start thinking about migrate away from GSM.

If you don’t know, GSM, Global Service Monitor in System Center Operations Manager provides the ability to monitor the availability of external web-based applications from multiple locations throughout the world. Microsoft Azure has this feature already within App Insights, called, “Availability“. Creative, I know.. But it does exactly that, measures the availability of your application.

Fellow MVP, Kevin Greene wrote an amazing, and in-depth article on how to migrate your application and GSM to Azure App Insights, so please have a read here. Over the next few blog posts, I would like to provide some detailed demos on Application Insights and how you can start taking advantage of this service to start monitoring your applications.

Advertisements

Step-by-Step – Deploying Azure Site Recovery (ASR) OVF Template (VMware On-Premises)

In the following tutorial, I will go through a step-by-step walk-through on deploying the Azure Site Recovery (ASR) VMware OVF template. This OVF template is a critical step as it bridges the connection between your On-Premises datacenter and the Azure Site Recovery Vault. Obviously there are a handful of prerequisites, as we need to prepare our VMware environment in addition, prepare our Azure workspace. I have created similar posts for Hyper-V and Azure to Azure (A2A) ASR Migrations, please visit the following link for the detailed setups of the Azure Recovery Services Vault HERE.

Let’s begin…  The first step is to download and install the VMware OVF template. The VMware OVF template can be found at the Microsoft Download Center.

Next, we need to deploy the OVF template within vCenter.

Note, this template will consuming about 1.5TB of space. This is a result of Microsoft consolidating the Configuration server and Process server into one workload.

Once the template is deployed, start the appliance and let’s begin registering our vCenter with ASR vault.

Note, the licence provided with OVF template is an evaluation licence valid for 180 days. You as the customer need to activate the windows with a procured licence.

Now we need to provide the server with some local administrative credentials.

Once you have given it some credentials, the server will auto login. The ASR wizard should launch on its own, if not, you can launch it manually — the icon should be on the desktop.

Once the ASR wizard starts, we will now need to complete the setup for this server following by registering the server with ASR.

Give the server some name, ie. VMwareASR01

Next, we need to validate the server can go over the Internet, ie. Azure and communicate as needed. If you are using a proxy, here is the time to set that up.

One thing to note, having the proxy settings configured within Internet Explorer should be removed.

Once an Internet connection has been established, we can then sign into the Azure Portal.

Now we need to sign into Azure with some credentials, ideally with a privileged/Global Administrator account.

Once you have logged into Azure successfully, you will need to reboot the server.

Once the server is back online, the next steps is to configure the Configuration server. 🙂 This step we will register this server/vCenter appliance with our Recovery Services vault. Let’s begin!

The server will auto-launch the ASR wizard, if not, launch it from the desktop icon.

Now that we have established an internet connection, we can configure our Network Interface Card(s) (NICs). Note, you can add as many as NICs needed, however, this needs to be done at the vSphere level. Once the server has been configured, you cannot add and/or remove those NICs. So, make sure you have it configured exactly as you need it. In my case, we will only need one, so, we will configure the NIC here.

Next, we need to sign into our Azure account, and select the corresponding subscription, resource group and select the appropriate recovery services vault. All of these should be available, and should have been created well before we began configure this server, as per the prerequisites…

Next, our server will download, install and configure MySQL on the server, along with the vSphere PowerCLI tools.

Gotcha, here, the appliance did not provide the vSphere PowerCLI tools, so we had to manually download, and install it.

Once we downloaded VMware’s vSphere PowerCLI toolset, we were able to continue. As mentioned, this was not provided, although it should have been. If we continued forward, the wizard would have thrown an error at the end of validation.

Next, we need to now provide the credentials and information with regards to our vCenter server(s).

Please read the prerequisites with regards to the needed permissions to allow our ASR Configuration server to communicate with the vCenter server(s).

Next we need to provide Windows and Linux based credentials to deploy install the ASR Mobility Service to all machines that will need to be replicated to Azure.

For this exercise, we are not replicating Linux machines to Azure, however if we were, similar to the Windows Mobility Service, we would need to provide some credentials that have elevated access to each of the Linux machines.

Once we have provided all the information above, we should now be able to validate some of the settings we have provided, and register our server with Azure and the Recovery Services vault. Give this a few minutes, as it took about 5 minutes to establish the communication/trust.

Once the registration of the server is complete, and the ASR appliance is officially configured with our Azure Recovery Services vault, we should now be able to see the vCenter/Configuration Server within our Azure Recovery Services vault.

If we click on the server, we can get some additional information, such as the server’s health, configuration, heartbeat, and so on…

We can also now click on the Process Server and get some additional information as well.

Now we are able to select the VMs we want to begin replicating to Azure and start testing failovers, either real, or simulated.

I hope this was helpful! Thanks, and until next time…

Log Analytics (OMS) AD Assessment – “No Data Found”

So, you deployed the OMS/Log Analytics AD (Active Directory) Assessment solution, and let it sit for a few hours, or maybe even a few days now.. Yet, the AD Assessment tile is still shows, “No Data Found“….

Well that is frustrating! Below is the series of steps I took to get this working, and ultimately what the actual solution was to get this OMS/Log Analytics solution pack working.

First things first,  did the basics… Check to ensure the Microsoft Monitoring Agent is deployed, and installed correctly. Also checked to see the service was running.

Confirmed the AD Assessment prerequisites were all satisfied:

  • The Active Directory Health Check solution requires a supported version of .NET Framework 4.5.2 or above installed on each computer that has the Microsoft Monitoring Agent (MMA) installed. The MMA agent is used by System Center 2016 – Operations Manager and Operations Manager 2012 R2, and the Log Analytics service.
  • The solution supports domain controllers running Windows Server 2008 and 2008 R2, Windows Server 2012 and 2012 R2, and Windows Server 2016.
  • A Log Analytics workspace to add the Active Directory Health Check solution from the Azure marketplace in the Azure portal. There is no further configuration required.

After all that, I decided to execute the following query within Log Analytics, I got the following results:

Operation | where Solution == "ADAssessment" | sort by OperationStatus asc

Okay, so I ensured .NET 4.0 was installed, fully. For safe measures, I enabled all of the .NET 4.6 sub-features, and for kicks, installed .NET 3.5 as well. Yet.. still nothing!

Next, I decided to take a look at the registry…

If we navigate to the following Registry Key, “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HealthService\Parameters\Management Groups\<YOUR Management Group Name>\Solutions\ADAssessment

I decided to delete the “LastExecuted” key, and then decided to reboot the server….

After a few minutes, I went back to the OMS/Log Analytics portal, and there it is!!!!

I ran the same query again, and verified the AD Assessment solution was working as expected:

Operation | where Solution == "ADAssessment" | sort by OperationStatus asc

Great! Now, if I click within the tile, I get the following AD Health Checks.

I hope this helped! Cheers! For more information on the OMS Active Directory Assessment Solution, please visit: https://docs.microsoft.com/en-us/azure/log-analytics/log-analytics-ad-assessment

 

MVPDays – Azure Application Insights

This May, MVPDays will be hosting their May installment of MVPDays Conferences. On May 23rd, I will be speaking on Azure Application Insights.

This event is free, and open for everyone and anyone that has an interest in technology, is eager to learn, and wants to meet other like minded individuals. This conference is not just for Microsoft MVP’s, it is for anyone in the IT Community!

To find out more and to register for MVPDays, please visit, https://www.eventbrite.ca/e/mvpdays-virtual-conference-may-23-2018-tickets-45274909473?aff=es2.

Restricting RDP (Remote Desktop) Access to Azure Virtual Machines

By default, every Azure virtual machine has RDP (Remote Desktop Protocol), port 3389 enabled, and allows any RDP connection from any IP in the world. As great as that is, this can be a (huge) security risk.  So, what if we want to change this, and limit who has RDP access to the VM? What if we want only a select range of IPs, or a specific IP to only have access to the VM(s)? For example, your branch office has a static public IP, and we only want RDP access from this IP/location. How can we achieve this?

Restricting RDP access your VMs in Azure isn’t difficult, but does require some knowledge of Azure Network Security. The solution can be achieved by making use of Azure NSG’s (Network Security Groups). Every VM will have an NSG when it is deployed. If you create an NSG beforehand, you can simply apply the same NSG to new VM deployments.

In the example below, we will need to create 2 NSG’s.

  1. Allowing RDP from a specific IP/CIDR
  2. Denying all RDP traffic

Let’s begin, if you go into the property settings of the VM, and select the Networking Settings, and select, “Add inbound port rule“. Click on the wrench, to switch from Basic to Advanced.

The Inbound Security Rule properties, as follows:

Wait, what do all of these fields mean?

  • Source: The source can by any IP Address, or CIDR Range, or a default-service tag.
  • Source IP Address/CIDR Ranges: Any IP Address, or CIDR Range.
  • Source Service Tag: There are a series of options here, but in short:
    • Load Balancer: Any probes in the Azure Load Balancer
    • Virtual Network: The Virtual Network the VM is connected to
    • Internet: All network traffic in the public virtual network, (including all Azure services, such as Azure Traffic Manager, Storage and SQL)
    • Azure Traffic Manager: Denotes the IP address from where the Azure Load Balancer health probes will origiante.
    • Storage.*:  Access to Azure storage services and/or specific Azure regions
    • SQL.*: Access to Azure SQL Database and Warehouse services, and/or specific Azure regions
  • Source Port Ranges: You can use either a range of ports, or use a Wildcard (*) for all ranges.
  • Destination: The source can by any IP Address, or CIDR Range, or the Virtual Network.
  • Destination Port Ranges: You can use either a range of ports, or use a Wildcard (*) for all ranges.
  • Protocol: TCP or UDP, or Any, which includes both TCP and UDP, and ICMP.
  • Action: Allow, or Deny access.
  • Priority: A number between 100-4096. The lowest is 100, and the highest we can input is 4096. Lower the number, higher the priority.
  • Name: The name of the rule. Note, once created, it cannot be changed!

So, these are the values/settings I implemented for the Allow Inbound Rule:

  • Source: IP Addresses
  • Source IP Addresses/CIDR Ranges: xxx.xxx.xxx.xxx
  • Source Port Ranges: *
  • Destination: Any
  • Destination Port Ranges: 3389
  • Protocol: TCP
  • Action: Allow
  • Priority: 4095
  • Name: default-allow-rdp

Next are the values/settings I implemented for the Deny all RDP Inbound Rule:

  • Source: ServiceTag
  • Source Service Tag: Intenert
  • Source Port Ranges: *
  • Destination: Virtual Network
  • Destination Port Ranges: 3389
  • Protocol: Any
  • Action: Deny
  • Priority: 4096
  • Name: Deny-RDP-Access

 

The Outbound Port Rules should look something like this now. Why we set Priority the way we did… Well, Rules are checked in the order of priority. Once a rule applies, no more rules are tested for matching.

 

Once the rules has been submitted, and accepted, and if we try to RDP into the VM we should now only be allowed from the IP Range, or IP! Success!!

 

To learn more on Azure NSG (Network Security Groups), visit: https://docs.microsoft.com/en-us/azure/virtual-network/security-overview

Global Azure Bootcamp 2018 – Azure Application Insights

On April 21st, 2018, all (Microsoft user groups) communities throughout the world, will be participating in the Global Azure Bootcamp. This year, I will be speaking on Azure Application Insights, at the Mississauga (GTA) Azure Bootcamp.  This event is free, and open for everyone and anyone to join!

All around the world user groups and communities want to learn about Azure and Cloud Computing!

On April 21, 2018, all communities will come together once again in the sixth great Global Azure Bootcamp event! Each user group will organize their own one day deep dive class on Azure the way they see fit and how it works for their members. The result is that thousands of people get to learn about Azure and join together online under the social hashtag #GlobalAzure!

To find out if Azure Bootcamp is in your area, please visit, https://global.azurebootcamp.net/.

Blocking Internet Access for Azure Virtual Machines

By default, every Azure virtual machine (VM) has access to the Internet. Sometimes this is great, but in most enterprise environments, server’s have Internet access restricted. So, how to restrict Azure VMs gaining access to the Internet?

Restricting Internet access to your VMs in Azure isn’t difficult, but does require some baseline knowledge of Network Security. The solution can be achieved by making use of Azure NSG’s (Network Security Groups). Every VM will have an NSG when it is deployed. If you create an NSG beforehand, you can simply apply the same NSG to new VM deployments.

In the example below, I am going to update the NSG for a specific VM. Of course, once the NSG has been modified, you can apply this NSG to other VMs too and/or future VMs.

Let’s begin, if you go into the property settings of the VM, and select the Networking Settings, and select, “Add outbound port rule“. Click on the wrench, to switch from Basic to Advanced.

The Outbound Security Rule properties, as follows:

Wait, what do all of these fields mean?

  • Source: The source can by any IP Address, or Range, or a default-service tag. CIDR ranges are also accepted.
  • Source Port Ranges: You can use either a range of ports, or use a Wildcard (*) for all ranges.
  • Destination: The destination can by any IP Address, or Range, or a default-service tag. CIDR ranges are also accepted.
  • Destination Service Tag: There are a series of options here, but in short:
    • Load Balancer: Any probes in the Azure Load Balancer
    • Virtual Network: The Virtual Network the VM is connected to
    • Internet: All network traffic in the public virtual network, (including all Azure services, such as Azure Traffic Manager, Storage and SQL)
    • Azure Traffic Manager: Denotes the IP address from where the Azure Load Balancer health probes will origiante.
    • Storage.*:  Access to Azure storage services and/or specific Azure regions
    • SQL.*: Access to Azure SQL Database and Warehouse services, and/or specific Azure regions
  • Destination Port Ranges: You can use either a range of ports, or use a Wildcard (*) for all ranges.
  • Protocol: TCP or UDP, or Any, which includes both TCP and UDP, and ICMP.
  • Action: Allow, or Deny access.
  • Priority: A number between 100-4096. The lowest is 100, and the highest we can input is 4096. Lower the number, higher the priority.
  • Name: The name of the rule. Note, once created, it cannot be changed!

So, these are the values/settings I implemented as a result:

  • Source: VirtualNetwork
  • Source Port Ranges: *
  • Destination: Service Tag
  • Destination Service Tag: Internet
  • Destination Port Ranges: *
  • Protocol: Any
  • Action: Deny
  • Priority: 4096
  • Name: Deny-Internet-Access

The Outbound Port Rules should look something like this now:

Once the rule has been submitted, and accepted, if we go to our VM, we will now most definitely be denied Internet access! Success!!

 

To learn more on Azure NSG (Network Security Groups), visit: https://docs.microsoft.com/en-us/azure/virtual-network/security-overview