Cloud Levels

// Exploring all things IT one level at a time…

Tag: Microsoft Azure

  • Entra ID Hybrid Identity – ADDS multi-forest

    Entra ID Hybrid Identity – ADDS multi-forest

    An interesting challenge came my way recently, this was for a global firm with locations in 15 different countries, whilst during an exciting period of growth and aquisition for them.

    This article is going to focus on the challenge I faced with regards to the businesses hybrid identity requirements, but first I’d like to provide a bit of background to the project.

    The first stage of the project was to merge two seperate firms and all of their offices based in the UK from an IT infrastructure perspective (identity, on-premise servers, cloud resources & networking), both these firms had different specialities however, once merged these two firms would become the firms UK division.

    The second stage of the project was to bring the UK division into the global businesses Azure & Entra ID tenant, including users hybrid identities, Intune mobile device management (MDM), Autopilot & Azure IaaS resources.

    Due to the nature of the global business, my remit was only in relation to the UK division, divisions located outside of the UK are managed by their own respective IT teams. Therefore, every element delivered as part of this project, could only affect the UK division, whilst allowing other divisions to replicate the behaviour and functionality in the near future.

    The challenge: how to use a hybrid identity model for a specific on-premises ADDS forest, with an Entra ID tenant which in the future will require other ADDS forests to also sync, all whilst not having any trusts or connectivity between these multiple ADDS forests.

    Over the years the Entra ID Connect (EIDC) sync service installed on a Windows Server, has generally been the go to option for hybrid identity sync between ADDS and Entra ID, however Entra ID has a limitiation whereby it cannot connect to and use multiple Entra ID Connect servers. Which meant this was not a suitable option in this scenario due to the lack of connectivity and trusts between ADDS forests across the globe.

    The solution: Entra ID Connect cloud sync.

    The primary difference between the Entra ID Connect Cloud Sync service and an on-premises Entra ID Connect server is the sync process is offloaded to the cloud. As the synchronisation process is handled directly within the Entra ID tenant, this method essentially supports multiple forests without the need for line of sight connectivity and trusts between the individual ADDS forests, which suited this scenario perfectly.

    To be able to sync multiple forests in this way, a light weight Entra ID Connect Cloud sync agent needs to be installed onto a domain member server within each forest, which is needed to be synced with the Entra ID tenant.

    The Entra ID Connect Cloud sync service is more limited when compared to the Entra ID Connect. Although in my opinion the main features are all there, for example the service still allows you to have a two-way sync (AD to Entra ID and Entra ID to AD) including password writeback functionality, as well as OU filtering so you can control which objects are synced. For reference, if you want users to be able to change their ADDS passwords from the cloud, each user will require a Microsoft Entra ID P2 license to be able to change their password via self-service password reset.

    The agent installer can be found within the Entra ID portal: login to Entra ID, open the ‘Microsoft Entra Connect’ blade, open the ‘cloud sync blade’, then select ‘New configuration’. Select the ‘AD to Microsoft Entra ID sync’ sync direction, then finally select ‘click here’ next to ‘For a list of active agents,’ this will open a new blade where you can select the option to download the agent installer.

    For reference this same blade will also show all provisioning agents registered to the tenant along with their status: 

    Inserting image...

    Further information on how to install an Entra ID Connect Cloud Sync agent is available here: https://learn.microsoft.com/en-us/entra/identity/hybrid/install

    Hope this helps and thanks for reading!

  • Azure reservations

    Azure reservations

    Azure Reservations, also known as Reserved Instances (RI) are essentially a savings plan, which are available to purchase up-front for specific Azure resources.

    Reservations work by allowing you to commit to an Azure resource by purchasing a reservation for a term of one or three years, in an exchange for a significant discount on the resources compute cost, when a reservation is purchased you have the option to either pay for the term entirely up-front or you can spread the cost of the reservation monthly. If the intention is to keep the resource long-term the goal is usually to cover each resource in its entirety by a RI to reduce the cost of the resource for its entire serviceable life.

    Microsoft offer reservations for many services including:

    • Virtual Machines (VMs)
    • SQL Databases
    • Azure Cosmos DB
    • App Service plans
    • Storage capacity

    This post is going to specifically focus on reservations for an Azure Virtual Machine (VM).

    For example (pricing correct at the time of writing), a standard D2 v3 VM SKU (2vCPUs and 8GB RAM) on a pay as you go (PaYG) pricing model in the UK South region costs £61.30 per month, whereas the monthly compute cost is £26.37 per month with a three year reservation. Including the required reservation on a basis of three years, costs £949.20 up-front, or paid monthly is £26.36. Meaning this VM SKU example could save £8.57 per month with a three year RI commitment versus the standard PaYG model.

    Every reservation available to purchase is a part of a specific flexibility group. Each reservation SKU within the same flexibility group can be used interchangeably for all of the different VM SKUs these reservations apply to. However, each reservation has a ratio, this is essentially a limit which determines how much of the VM compute can actually be discounted.

    It helps if you think of the ratios published as a VM’s cores. I’m going to use the “FSv2 Series” flexibility group as an example. The details of each reservation have been outlined in the below table:

    Flexibility GroupVM SKURatio
    FSv2 SeriesStandard_F2s_v22
    FSv2 SeriesStandard_F4s_v24
    FSv2 SeriesStandard_F8s_v28
    FSv2 SeriesStandard_F16s_v216
    FSv2 SeriesStandard_F32s_v232
    FSv2 SeriesStandard_F48s_v248
    FSv2 SeriesStandard_F64s_v264
    FSv2 SeriesStandard_F72fs_v272
    FSv2 SeriesStandard_F72s_v272

    All of the Azure ratio information is available from Microsoft in the CSV file here: https://aka.ms/isf

    In most scenarios a reservation SKU matches the VM’s SKU exactly, this means the VM’s cores and the reservations ratio matches exactly, meaning the RI will be utilised fully by the respective VM.

    However, there are various scenarios where you may want to utilise a different RI type versus the VM SKU, for example, there may not be an RI SKU that matches the VM’s SKU, or you may want to upgrade your VM and continue to use the RIs you’ve already purchased.

    If you are in this situation then you can purchase multiple reservations that total up to the total ratio required to cover the respective VM.

    For example if you have a standard F16s v2 VM with 16 cores, but you want to use an F4s v2 reservation with a ratio of 4, you would need four of these reservations to cover the 16 cores provided by the F16s v2 VM.

    As a reservation ratio essentially translates to cores you can also work this out the opposite way, let’s say you have ten F8s v2 reservations, each reservation has a ratio of 8 and you have 10 reservations in total. This means you can spin up a combination of VM’s with different SKUs (as long as they are in the same flexibility group), for example you can spin up either ten F8s v2 VM’s, 20 F4s v2 VMs or five F8s v2 and ten F4s v2 VMs, and the entire compute will be discounted up to a maximum of 80 cores.

    Please note if you have a mixture of VM’s and reservation SKUs which are all a part of the same flexibility group, you may notice the VM’s utilise different or even multiple reservations, this is perfectly normal as Azure automatically applies the compute discount to a matching resource.

    Reservations are also regional and cannot be used by a resource located in a different region. For example, if you have a F8s v2 VM located in the UK South, this resource cannot use a reservation purchased for the West Europe region.

    Hope this helps and thanks for reading!

  • Entra ID tenant deletion

    Entra ID tenant deletion

    Hello and thankyou for reading my first post!

    I have put this post together to outline the additional steps that I had to recently complete to successfully delete an Azure / Entra ID tenant. This task came about after a recent aquisition which mean the tenant in question was redundant after the resources had been migrated.

    The additional steps were not mentioned in the Microsoft Learn article which in most circumstances successfully guides you through how to delete an Entra tenant. For reference, the guide I am referring to can be found here: https://learn.microsoft.com/en-us/entra/identity/users/directory-delete-howto.

    Before being able to proceed to delete an Entra tenant, you will need to complete (as outlined in the above guide) all of the pre-requisites, once complete they should all have a green status as shown in the below screenshot:

    This status page is available in the Entra Admin Centre (entra.microsoft.com).

    To note, for the License-based subscriptions status to pass it took around 120 days, this was due to the licenses in my tenant being provided by a reseller meaning it took longer for the licenses to move through each stage before being finally deleted from the tenant.

    However, although the pre-requisites passed as shown above, I still could not delete the tenant in question, I kept receiving the below error suggesting it was due to left-over Enterprise Applications:

    There were no Enterprise Applications left-over, the only ones I could find via Microsoft Graph were ‘Microsoft Internal’ Enterprise Applications, but I ended up spending a chunk of time trying to remove these as per the guidance here: https://learn.microsoft.com/en-gb/entra/identity/users/directory-delete-howto#remove-enterprise-apps-that-you-cant-delete. However, this did not achieve anything as it turns out deleting ‘Microsoft Internal’ Enterprise Applications has been blocked (naturally).

    In the end I conceded and ended up raising a ticket with Microsoft Azure support.

    To my surprise I was advised that the problem stopping me from deleting the tenant, was due to some legacy Microsoft partnership relationships still being registered in the tenant, despite licenses being fully deleted at this stage and the error message above suggesting otherwise.

    So I got in touch with the three Microsoft partners and distributors in question and requested they removed the partner relationship, once they had been successfully removed, a few days later the Entra tenant was able to be deleted successfully.

    So if you’re ever in a similar situation and can’t delete an Entra tenant, I would certainly recommend you checking to see if there are any legacy relationships left over, you can check this here: Microsoft 365 Admin Centre -> Settings -> Partner Relationships (https://admin.microsoft.com/#/partners).

    Hope this helps and thanks for reading!