Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

To change a managed service account, first identify whether it is a standalone MSA (sMSA), group MSA (gMSA), or delegated MSA (dMSA), then choose an action that matches the account type and the scope of the change. Use Set-ADServiceAccount for supported property changes; use Uninstall-ADServiceAccount to remove an installation or cached entry from a host, not to delete the Active Directory object. A gMSA password interval cannot be edited in place: changing it requires creating and validating a replacement.

Identify the account before changing it

sMSAs and gMSAs are different Active Directory object classes, and their password-management operations are not interchangeable. You can enumerate accounts and inspect their object classes with:

Get-ADServiceAccount -Filter * | Select-Object Name, ObjectClass
  • msDS-ManagedServiceAccount identifies a standalone MSA (sMSA).
  • msDS-GroupManagedServiceAccount identifies a group MSA (gMSA).

A dMSA is associated with the delegated managed service account migration process in Windows Server 2025. Treat a dMSA migration as its own rollback case rather than applying sMSA or gMSA password procedures to it.

Change supported account properties

Microsoft documents Set-ADServiceAccount for modifying supported MSA properties, including settings that govern which principals can retrieve a managed password. Use the narrowest applicable parameter set. For example, to change a gMSA’s display name:

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
Set-ADServiceAccount -Identity "<gMSAName>" -DisplayName "<NewDisplayName>"

After a property change, inspect the object and test password retrieval from the intended hosts:

Get-ADServiceAccount -Identity "<gMSAName>" | Select-Object *
Test-ADServiceAccount -Identity "<gMSAName>"

When changing password-retrieval permissions, update the relevant security group or principal list, allow the directory change to replicate, and run Test-ADServiceAccount on each target host. A successful test checks host password retrieval; it does not by itself confirm that the consuming service is healthy or authenticating as intended.

Use a controlled change and verification sequence

  1. Record the starting state. Note the account identity and object class, authorized hosts, consuming service configuration, SPNs, delegation settings, and the person responsible for recovery.
  2. Make the smallest supported change. Use Set-ADServiceAccount for the property being changed; avoid combining unrelated edits into one untracked change.
  3. Verify the directory object. Run Get-ADServiceAccount for the account and confirm the intended values.
  4. Check host readiness. For a change to password-retrieval authorization, test each target host with Test-ADServiceAccount after replication.
  5. Apply the service’s change procedure. Restart or recycle the consuming service only when its operational procedure calls for it, then verify service health and authentication logs.

Change a gMSA password interval by replacing the account

The password-change interval is set when a gMSA is created and cannot be changed in place. Microsoft Learn’s Manage Group Managed Service Accounts documentation says that an interval change requires creating a new gMSA with the desired interval.

  1. Create a replacement gMSA with the required -ManagedPasswordIntervalInDays value.
  2. Authorize the intended hosts to retrieve its managed password.
  3. Install the replacement on the target hosts with Install-ADServiceAccount, then test it there with Test-ADServiceAccount.
  4. Configure the consuming service to use the replacement identity and verify operation, including authentication.
  5. Retire the old account only after the replacement is proven and all consumers have been migrated.

This is a migration, not a rollback of the existing interval: the old account remains a separate directory object until you decide it is safe to retire.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Choose the rollback action by scope

Uninstalling and removing an MSA do different things. Uninstalling cleans up the local host; removing deletes the directory object. Neither operation automatically changes the consuming service’s configuration.

Situation Action Scope and caution
Undo a local sMSA installation or cached gMSA entry Uninstall-ADServiceAccount -Identity <name> on the host Local cleanup; it does not delete the Active Directory object. [Microsoft Learn, “Uninstall-ADServiceAccount”]
Delete an obsolete account after migration and retirement Remove-ADServiceAccount -Identity <name> Deletes the directory object. Microsoft documents that this cmdlet does not change computers that use the account, so migrate consumers and update their configurations separately. [Microsoft Learn, “Remove-ADServiceAccount”]
A dMSA migration was applied to the wrong account Use Undo-ADServiceAccountMigration or Reset-ADServiceAccountMigration, as appropriate to the migration state These are dMSA migration operations, not general-purpose gMSA rollback commands. Reset returns the dMSA to an inactive or unlinked state. Preserve the original service account while rollback may still be needed. [Microsoft Learn, “Setting up delegated Managed Service Accounts (dMSA) in Windows Server 2025”]
A standalone MSA has a password issue Run Reset-ADServiceAccountPassword on the computer where that sMSA is installed Supported for sMSAs, not gMSAs. [Microsoft Learn, “Reset-ADServiceAccountPassword”]
A gMSA’s password interval must change Create and validate a replacement gMSA The interval is creation-time only; an in-place edit is not supported. [Microsoft Learn, “Manage Group Managed Service Accounts”]
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

Roll back a dMSA migration without discarding the recovery path

Microsoft’s Windows Server 2025 dMSA migration guidance warns administrators not to delete the original service account when finalizing migration, in case a later reversion is required. If the wrong account was migrated, choose between Undo-ADServiceAccountMigration and Reset-ADServiceAccountMigration according to the migration state and desired result. Do not delete the original account as a shortcut: preserving it keeps the documented recovery option available.

What each operation does—and does not do

  • Set-ADServiceAccount: changes supported properties on the directory object. Verify the changed object and any host-level effect.
  • Uninstall-ADServiceAccount: removes the local installation or cached gMSA entry. It leaves the directory object in place.
  • Remove-ADServiceAccount: deletes the directory object. It does not reconfigure computers or services still using the account.
  • Reset-ADServiceAccountPassword: resets an sMSA password from the computer where the sMSA is installed; it is not a gMSA password-reset method.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.