Idea ID: 2809072

Azure Discovery - Gaps in basic compute

Status : Delivered
11 months ago

I have been working with a few our of Azure SME's, testing the Azure discovery and we have identified some gaps at the basic compute level.

Please note we are on UCMDB 2019.02/CP 2019.08, some of these may already be done in a later CP, I have tried to filter this list using the CP docs

  • Network Security Groups (NSG) should be related to the Network interface of the VM and related to the Resource group.
  • Currently Private IP’s are linked to the Interface on from host discovery, but the Interface can also have a public IP, we should relate all IP’s to their corresponding interface and IP’s can be linked to the interface via the Azure API.
  • Virtual Network (VNET) should be related to Network interface of the VM and related to the Resource group. This will solve this problem: If you have two virtual networks with the same subnet then you end up with two Virtual Networks connected to one subnet, then you cannot differentiate which VNET the VM is linked to. Also, you only seem to relate subnets when they already exist in UCMDB.
  • VNET’s information needed:
    • DNS Servers or Default
    • Peering
    • Service Endpoints
    • Private Endpoints
    • Connected Devices, such as Virtual Network Gateway, Local Network Gateway, Network Interface
  • Subnet information needed:
    • Route table
    • Network Security Group relationship
    • NAT Gateway
    • Service Endpoints
    • Subnet Delegation
  • All the properties from Virtual Machine page such as:
    • SKU
    • Agent Status
    • Agent Version
    • Host ID
    • Proximity placement group
    • Colocation status
    • Availability Zone
    • IP’s should be marked as public or private
  • On IP Address CI’s:
    • You are setting IpAddressProperty to “dhcp”. You should instead of/as well as be setting IP Lease Time as this is needed for reconciliation.
    • We need to know the “IP Type”
  • On the disk discovery level, you should pull Disk state, Location, Time Created, Disk Configuration, Availability Zone, Provisioned IOPS and throughput, Encryption type, Storage Account Type.
  • On the storage account level we need the performance, replication, status and location
  • Discovery of the Virtual Machine type (whether it is classic or Virtual Machine)
  • Populate the memory size on Node CI’s from Azure API.
  • List the azure directory against the Azure Subscription CI
  • Discovery of the Availability Zone of VM’s.


In addition to this, you have moved away from the AWS model of discovery, using an AWS Protocol to store the information, to using HTTP Protocol and Manual URI Endpoints.

I think you should keep consistency and introduce Azure protocol where we can enter the endpoint, client id, secret and we can simplify the workflow of discovery.

  • This idea has been implemented in CP2021.02. Check out the release notes for details. Thanks to all of our contributors for helping us continue to improve our products!

  • Great news, this idea has been accepted on our product roadmap. Subscribe to receive updates. (This is not a formal commitment, and subject to change)



    When you are at it, maybe align below attributes so they dont "flip/flop" between normal Discovery and Azure Discovery, you have the information using the API, and utilizing normalization rules it can be easily solved.

            host_osh.setAttribute("discovered_vendor", "Azure")
            host_osh.setAttribute("os_description", self.osDescription)
            host_osh.setAttribute("discovered_location", self.location)
            host_osh.setAttribute("discovered_description", self.discoveredDescription)
            host_osh.setAttribute("discovered_os_version", self.discoveredOSVersion)
            host_osh.setAttribute("discovered_os_vendor", self.type)
            host_osh.setAttribute("node_model", self.model)
            host_osh.setAttribute("discovered_model", self.discoveredModel)

    In addition, we would have huge issues with merge on IP's due to the number of subskriptions we have, many are running on same private IP, for public IP i think it would great i we could choose to put them to a separate IP CIT, that are not discoverable.

    Please add support for MT, this is really a pre. req with all the new data regulations laws implemented across the world.


  • Excellent feedback.  I have collected it and sent to our content owners to review.  Thank you so much for this information and your analysis!

  • Thank you for sharing your idea! It’s open for comments and kudos, and we’re looking forward to input from the community. Once there is enough community traction, it will be further reviewed by the product team