Exam AZ-104 topic 1 question 21 discussion

Ans: A After Windows is installed but before the logon screen appears, Windows Setup searches for the SetupComplete.cmd file in the %WINDIR%\Setup\Scripts\ directory

GPOs aren't a thing in Azure AD. Just putting a Script inside the VHD doesn't make it run on boot. Configuring a "SetupComplete.cmd" in the "%windir%\setup\scripts" directory is the correct approach:

Los startup scripts se ejecutan antes de que cualquier usuario inicie sesión, asegurando que la configuración se aplique correctamente a todas las nuevas VMs cuando se inicien. Además, este enfoque se administra centralmente desde Active Directory, lo que facilita la aplicación en múltiples máquinas.

You have created some PowerShell scripts to automate the configuration of newly created VMs. You need a solution that ensures the scripts are run on the new VMs. There is nothing to imply that the script needs to be run on every startup. Therefore there is no reason to use a GPO. SetupComplete.cmd would be the appropriate answer.

Nowhere in the question is written that the new VMs will be domain joined. So GPO may not be an option at all.

The best solution is C. Configure a Group Policy Object (GPO) to run the scripts as startup scripts. This ensures that the PowerShell scripts are executed when the VMs start up, automating the configuration process effectively

I think A because here: https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/add-a-custom-script-to-windows-setup?view=windows-11 you could find this: "If the computer joins a domain during installation, the Group Policy that is defined in the domain is not applied to the computer until Setupcomplete.cmd is finished. This is to make sure that the Group Policy configuration activity does not interfere with the script."

Microsoft Entra ID does not support traditional Group Policy Objects (GPOs) like Active Directory Domain Services (AD DS). GPOs are a legacy feature of on-premises Active Directory environments,

Para asegurarse de que los scripts de PowerShell se ejecuten automáticamente en las nuevas VM y configuren el sistema correctamente, la mejor opción es usar un GPO configurado para ejecutar los scripts como scripts de inicio. ✅ Opción correcta: C. Configure un objeto de política de grupo (GPO) para ejecutar los scripts como scripts de inicio.

The SetupComplete.cmd mechanism is executed during Windows Setup after installation completes. This is useful for initial image configuration but is less flexible if you plan to use an already prepared image or if the VMs are deployed in various scenarios over time. Since your environment is domain-joined (as indicated by the hybrid coexistence with on-premises Active Directory) and you’re creating multiple new VMs, using a GPO with startup scripts is a centralized and scalable way to ensure your configuration scripts run automatically on each new VM.

The best solution in this scenario is to configure a Group Policy Object (GPO) to run the scripts as startup scripts. This ensures that the PowerShell scripts are executed when the virtual machines start up, automating the configuration process. So the correct answer is C. Configure a Group Policy Object (GPO) to run the scripts as startup scripts.

he best solution is C. Configure a Group Policy Object (GPO) to run the scripts as startup scripts. Configuring a GPO to run the scripts as startup scripts ensures that the scripts are executed when the VMs start up, which is ideal for automating the configuration of newly created VMs. This method is reliable and integrates well with the existing Active Directory environment. Option A, configuring a SetupComplete.cmd batch file in the %windir%\setup\scripts directory, is a valid method for running scripts during the setup process of Windows. However, it is typically used for tasks that need to be executed once during the final stages of the Windows setup process, rather than for ongoing configuration tasks.

C. Configure a Group Policy Object (GPO) to run the scripts as startup scripts. Here’s why: Startup scripts run when the computer starts, before any user logs on. This ensures that the scripts are executed as soon as the VM is powered on and before any user interaction. Logon scripts (option B) run when a user logs on, which means the scripts would only execute after a user logs in, potentially delaying the configuration. SetupComplete.cmd (option A) is used during the Windows setup process, but it is not as flexible or manageable as GPOs for ongoing VM management. Placing scripts in a new VHD (option D) is not a standard method for ensuring scripts run automatically on new VMs.

Rationale: The SetupComplete.cmd file is executed immediately after the operating system setup is complete, ensuring that the scripts are run on the new virtual machines as part of their initial configuration. This solution is both direct and efficient for automating the configuration of freshly created VMs. Why not the others? B: Logon scripts via GPO: These run only when a user logs in. For automating initial configurations on new VMs, this is neither timely nor appropriate. C: Startup scripts via GPO: While they run during the computer's startup, GPOs require the machine to already be part of the Active Directory domain, which is not guaranteed for new VMs during initial setup. D: Scripts in a new VHD: While theoretically possible, this approach is cumbersome and lacks the streamlined execution of the SetupComplete.cmd method.

Given the options, the best solution to ensure your PowerShell scripts run on the newly created VMs is: C. Configure a Group Policy Object (GPO) to run the scripts as startup scripts. Here's why: Startup Scripts: Configuring the scripts as startup scripts ensures they run when the VM boots up, before any user logs in. This is ideal for initial configuration tasks that need to be completed before the VM is fully operational. Group Policy: Using GPOs allows you to centrally manage and enforce the execution of these scripts across all new VMs in your domain, ensuring consistency and reducing manual effort.

If any script is running in the startup, it slows down the booting time. Startup script should contain only those tems which cannot stay in static state.

Configure a SetupComplete.cmd batch file in the %windir%\setup\scripts directory is another valid solution, but it is typically used for very specific scenarios during the initial setup phase of Windows deployment.