Active Directory Unable to reset user passwords
I am managing a Windows Server 2025 Active Directory environment with client machines. I created a test user and enabled the option “User must change password at next logon.” I then provided a temporary password to the user, expecting them to get the prompt to change it on first login. However, when the user attempts to change the password, they receive the error: “The user must change password before signing in.” My goal is that when I provide a temporary password to a user: They get the prompt to change the password at next logon. When they change it, it should not throw the “user must change password before signing in” error. I need guidance on how to achieve this so users can reset their passwords successfully.Add Passkey support to Active Directory
Everyone, Please go to the feedback hub and upvote my suggestion to add passkey support to Active Directory Domain Services: https://aka.ms/AAw8z54 The reason I am recommending this is because there needs to be a standard way to use passkeys in an AD environment.
Arquivos .tmp sendo criados no servidor
Bom dia. Estou tempo um problema e ja esgotei minhas tentativas de correção. O meu servidor de arquivos esta criando arquivos temporarios conforme a manipulação e criação dos arquivos salvos no servidor. Estes arquivos ficam impossibilitados de serem deletados ate proximo restart do servidor, e em seguida voltam a ser criados novamente. Gostaria de saber se alguem ja presencial um acontecimento deste e se sim, como foi corrigido. Segue a imagem com os arquivos criados. OBS. As pastas do servidor tem sincronismo com o GoogleDrivefeature Installation Error
I am facing this issue in Windows Server 2019 STD. i am also tried to solve this issue to select sources\sxs path from the OS media but still i am getting the same error. Mistakenly i have removed .Net framework from this server and after that i am facing this issue. please help me to solve this issue.
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/”Force a specific default lock screen and logon image
Dear, I currently have a DC deployed on Windows Server 2019. i want to configure a specific default image on lock screens on Windows 10 pro clients via group policy. Is this possible or is it only compatible with Enterprise or Education editions? Thanks in advance,
