Experience with Automanage Machine Configuration
Hi, I am experimenting with Automanage Machine Configuration and find the overall experience and documentation very poor. I am wondering if there are others who have experience with automanage and can point me towards additional documentation. I have built an example implementation which I am using as my lab setup: https://github.com/JelleBroekhuijsen/azure-automanage-example What I am experiencing is that the compliance-state reporting seems to be very inconsistent. Sometimes these sample configurations reports everything being compliant while maybe 30 minutes later the same configuration is marked as incompliant (while the VM is observably in a compliant state). Additionally, there seems to be no option to get support or report issues with the GuestConfiguration-extension (for Windows) or the GuestConfiguration PowerShell module. For instance, in my experimenting with the module I found that calling the PackageManagement DSC resource from within a configuration leads to a conflict with the embedded PackageManagement module in the windows extension. I found a workaround for this, but I have no way to report this issue.
Azure Function to unzip blob to specific blob folder
If this is not the right group to post this, please let me know. I am not much of a developer but have a need to extract a ZIP file that resides in a Blob Container into the same container in a specific folder, I would like that folder to be named the same of the zip filename. I have found several Azure Function blobs that use the new file blob trigger but all of them simply extract all the files in a specific container. I cannot for the life of me figure out how to tell it to save it in a specific folder and how to get it to pull the name of the file to name that folder. Does anyone have a template or code they would be willing to share with me? The reason I need this is due to the fact that Power Automate's "extract to ***" connectors have a limit of 100 files in the zip. Of course my zip files have just over 100 files in them......
Determining sizing requirements for GPU enabled Azure VM
Greetings, We are trying to determine the correct VM sizing requirement for our AI workload, which is used for NLP processing. This workload does not require any training, but will only be used for inference. We have the following software configuration: a C# application that is heavily multithreaded using a lot of socket I/O. The application has concentrated bursts where 10-20 threads are fired concurrently to perform tasks (mostly socket I/O). This app communicates via dedicated sockets to: a Python application which performs various NLP tasks. This app is also multithreaded to handle multiple incoming requests from the .NET app. This app sends queries to a local LLM (model size will vary based on query type). We estimate we will need to support sub-second performance (at the very least) on a 7B parameter model. Ultimately, we may need to go to larger model sizes if accuracy is insufficient. The amount of text passed to the LLM will range from 300-3000 tokens. In short, we need: a) a CPU with sufficient cores to handle multiple concurrent threads on the .NET side. The app will have 5 or 6 background threads running continuously, and sudden bursts of activity which will require a minimum of 10-20 threads to run shorter-lived tasks. b) a GPU with sufficient VRAM to handle at the very least, a 7B parameter model. Ultimately, we may need to support larger models to perform the same task due to insufficient accuracy. We need the ideal configuration of GPU/VRAM and CPU/RAM to handle these tasks, and also, potentially, larger LLM sizes of up to 14B or 70B parameters. We are looking at the NC-series VMs, with a budget of about $1,000/month (see https://learn.microsoft.com/en-us/answers/questions/2150959/determining-sizing-requirements-for-gpu-enabled-az?comment=question). Any feedback on the optimal configuration in terms of CPU/GPU would be greatly appreciated. Thank you in advance.
Adding VM Instance View Details, e.g. osName, to the VM Resource Object JSON (for Custom Policy Use)
I'm requesting to add more details to the JSON of the VM resource object, particularly from the VM instance view data. This is to include operating system information, such as the name and version (osName and osVersion), for use in a custom Policy. Although these details are visible in the portal, they're not present in the VM's resource object, which is necessary for our custom policy.
Azure IMDS (Instance Metadata Service) calls to 168.63.129.16 blocked after July 1st, 2025
[ACTION REQUIRED] After 1 July 2025, it will no longer be possible to query Azure IMDS endpoints at the IP address 168.63.129.16. Please begin using 169.254.169.254 to communicate with Azure IMDS as soon as possible. Officially, IMDS APIs can only be queried at 169.254.169.254. However, due to the internal design of Azure, IMDS endpoints can also be queried at the IP address 168.63.129.16 from within a virtual machine. Some customers are using this unofficial pathway to communicate with IMDS. An upcoming change in Azure will permanently block IMDS requests on 168.63.129.16. After 1 July 2025, you won’t be able to access Azure IMDS endpoints with that IP. You can continue to use 168.63.129.16 to call into IMDS APIs until up until that date, but we recommend you begin your transition now. HOW TO CHECK IF YOU ARE IMPACTED Code analysis in your application. IMDS has a reserved IP address of “169.254.169.254" VM’s Private communication channel has reserved IP address of "168.63.129.16". Use code search to evaluate that your client is not using IP address “168.63.129.16” for making metadata requests. All IMDS REST requests starts with “/metadata” and all endpoints can be found at IMDS Public endpoints. REQUIRED ACTION Fix all URLs using 168.63.129.16 to prepare for its decoupling from IMDS. For example, this IMDS token endpoint URL would soon be blocked: curl -s -H Metadata:true --noproxy "*" "http://168.63.129.16/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://management.azure.com/" To avoid service disruptions, fix URLs to include 169.254.169.254., as in this example: curl -s -H Metadata:true --noproxy "*" "http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://management.azure.com/”XXX virtual machines should enable Azure Disk Encryption or EncryptionAtHost.
Hello everyone, I'm facing issues related to a policy: Linux virtual machines should enable Azure Disk Encryption or EncryptionAtHost. Windows virtual machines should enable Azure Disk Encryption or EncryptionAtHost. After enabling EncryptionAtHost, it appears as encrypted in the portal. However, the policy does not recognize that it is encrypted and shows it as non-compliant. The same happens when enabling Azure Disk Encryption (ADE): the policy still indicates that it is non-compliant. Has anyone else experienced this?
Power Management of Client Machines VM: Credential Handling and Solutions
We handle the power on/off operations of client machines as needed. To perform these tasks, we collect AD-APP credentials from clients, as the AD-APP has the necessary permissions to manage the VMs. Problem: We need to gather and securely store AD-APP details from multiple clients. Managing these credentials for each VM individually is becoming a significant overhead. Looking for a Solution: Can we solve this problem with a multi-tenant AD-APP, where we use a single multi-tenant app and request clients to grant access to their VMs? Considerations: Clients will have different accounts with no relation to our subscription. Questions: If a multi-tenant AD-APP is a viable solution, what configurations are required on our side and the client's side? Please share in detail. If it's not possible, is there an alternative way to achieve this?
