Category: Azure

Adding VMs to an Availability Set after they are created

Adding VMs to an Availability Set after they are created

Availability Set Tips and Tricks

An Availability set in Azure is a way of logically grouping virtual machines in order to protect them from a Unplanned Hardware Maintenance Event, An Unexpected Downtime, Planned Maintenance events When virtual machines are part of an availability set they are separated across multiple update and fault domains.

Fault domains define the group of virtual machines that share a common power source and network switch.

Update domains indicate groups of virtual machines and underlying physical hardware that can be rebooted at the same time. Microsoft will reboot one update domain at a time with a wait time of 30 minutes before the next update domain is restarted.

However in order to add a machine to an an availability set it must be added at the time of creation. Now this is easily overseen and you could end up in a position where you have installed your required applications and configurations and not added your new VM to an availability set. So does this mean you have to start from scratch?

Well…No is the answer, remember the configurations you made are applied to the OS/DATA disks and not he VM itself. What we can do in this scenario is redeploy the VM using the same OS/DATA disks and add it to the required Availability Set.

In order to do this we will need to install the Availability Set PowerShell Module from GitHub. Run the below command to complete this:

Install-Module AzureRm.AvailabilitySetManagement

Once you have installed the module we will now run the below command changing the parameters to your required environment:

Add-AzureRmAvSetVmToAvailabilitySet -ResourceGroupName "MyResourceGroup" -VMName "KAM-VM1" -OsType windows -AvailabilitySet "myAvailabilitySet"

This will now delete your VM (your VM OS/data disks will remain intact). Your VM will be re-created with the original OS/DATA disks attached. This is accomplished by creating an ARM template with the current configurations and redeploying your VM via a new ARM template, this time with the availability set.

Important to note:

  1. Any VM extensions will not be re-created and will therefore need to be added on manually.
  2. Accelerated Networking must be in a disabled state

That’s all for now folks, let me know how you get on in the comments below!

Learn more about Availability Sets here

Intune MDM Azure Portal Explained

Intune MDM Azure Portal Explained

MS Intune

Managing Windows 10 with Intune MDM

I am hoping this helps with the understanding of Intune (Azure Portal) and MDM.

 

There are 3 types of configurations for devices when connected to Intune (Azure Portal):

Intro:

Azure AD Registered devices: this allows a device to come into the realm of MDM. This is focused on BYOD. End users can bring their devices and Register them with Azure where they can be managed by adding a work/school account. Admins can push out policies. But nevertheless the end user can remove themselves from the MDM management, because this is their personal device.

Types of Azure AD Domain Joins:

Azure AD joined devices: this allows a device to join a Azure AD domain. Targeted for workplace devices that do not have an on-premise AD infrastructure or a cloud first/only approach. Benefits include:

  • Single-Sign-On (SSO) to your Azure managed SaaS apps and services. Your users don’t see additional authentication prompts when accessing work resources. The SSO functionality is even when they are not connected to the domain network available.
  • Enterprise compliant roaming of user settings across joined devices. Users don’t need to connect a Microsoft account (for example, Hotmail) to see settings across devices.
  • Access to Windows Store for Business using AD account. Your users can choose from an inventory of applications pre-selected by the organization.
  • Windows Hello support for secure and convenient access to work resources.
  • Restriction of access to apps from only devices that meet compliance policy.

 

Hybrid Azure AD Joined devices: this is for organisation who also have a on-premise footprint as well as cloud. Devices are joined to a local AD. These organisation would require the need for group policies or imaging devices or NTLM/Kerberos hence why they are not fully in Azure.

Rule of thumb:

A rule of a thumb, you should use:

  • Azure AD registered devices:
    • For personal devices
    • To manually register devices with Azure AD
  • Azure AD joined devices:
    • For devices that are owned by your organization
    • For devices that are not joined to an on-premises AD
    • To manually register devices with Azure AD
    • To change the local state of a device
  • Hybrid Azure AD joined devices for devices that are joined to an on-premises AD
    • For devices that are owned by your organization
    • For devices that are joined to an on-premises AD
    • To automatically register devices with Azure AD
    • To change the local state of a device

 

So what does this mean:

Well in a nutshell, you don’t need to use the old classic Intune portal!!! We can configure a on-premise domain joined machine to be managed by Azure Intune MDM (agentless MDM). The trouble you will find is that there is no clear documentation on how to configure this. My next post will discuss how to configure local AD domain joined device to be managed via Intune MDM using the Hybrid Azure AD Domain Join option.