In this post we will be going through the steps required to create and use group managed services account (gMSA) with a scheduled task.
gMSA are a managed domain account that provides automatic password management. These accounts provide a single identity to use on multiple servers.
By using a gMSA account, we can configure services / scheduled tasks with the gMSA principal and Active Directory handles the password management.
gMSAs where introduced since Windows Server 2012.
There are pre-requests to use gMSA that most domain should already meet, this is AD Schema of 52 (2012) and at least one 2012 DC.
Once we meet the minimum scheme the second part is that we have to create the Key Distribution Services Root Key.
This involves running a command in PowerShell, we can the below command to confirm that a kds root key doesn’t exist already.
Get-KdsRootKey
To create the KDS run
Add-KdsRootKey –EffectiveImmediately
Now when we check KDS again we can see the root key.
Now that we have the KDS root key we can create the gMSA
We can add the host either individually or using a security group, we will be using a group in this post as it will be easier to mange and just need to add any additional servers to the group to allow access.
I have create a group called tskgmsa_access to use and added some server computer accounts.
The below command is used to create the gMSA account (The DNS is required by the command but not needed for running scheduled task so you can use whatever name as it doesn’t need to be resolvable)
New-ADServiceAccount -name gMSAName -DNSHostName DNSName -PrincipalsAllowedToRetrieveManagedPassword "Group or Hosts"
The accounts are create under the Managed Services Accounts OU.
We can add the account to a security group to give more rights, this could be used if the account needs admin right to do a specific tasks.
The Microsoft documentation says that you need to install RSAT tools and run Install-ADServiceAccount but I didn’t have to do this for scheduled task to run.
To allow the account to run a script we need to add the account to the logon as a batch job under user rights assignment. This can either be done using group policy or using secpol.msc.
I used secpol as i only have two servers to configure.
To test we will create a scheduled task that will out put text to a log file.
Below is the script file that will be run.
To use the gMSA account we have to create the task using PowerShell as the GUI can’t find the account.
Below is the command I used.
$arg = "-ExecutionPolicy Bypass -NoProfile -File C:\scriptpath\script.ps1"
$ta = New-ScheduledTaskAction -Execute C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -Argument $arg
$tt = New-ScheduledTaskTrigger -At "Time to Run"
$ap = New-ScheduledTaskPrincipal -UserID Domain\gMSA_AccountName -LogonType Password
Register-ScheduledTask gMSA_Test_Task –Action $ta –Trigger $tt –Principal $ap
If you get incorrect users or password and only recently added the computer account to the security group, the server will need a reboot to pickup the membership.
Next we need to run the task and confirm data is written to the log. From the task events we can see the account used is gmsa_tsksch$.
We can also see the authentication on the domain controller.
When we check the logs folders we can see the text files are created.
This has been a overview of creating and using a Group Managed Service Account for running scheduled tasks.
To read an XML report in PowerShell you can use the typecast to XML by using [xml] in front of the variable which should make querying the content easier. 
This is what the export will look like.
Copy the code and click on the enter code hyperlink and enter the code
We can also now connect to the VM using integrated RDP console in WAC
Accept the terms.
To add a server click Add. 
Click search active directory and put in the server name. 
When connecting to servers, to allow single sign on there is an additional command that need’s to be run. If this is not done you will see the below warning when connecting.
The above command adds the admin server to the below attribute. 
Once this has been done when you click connect it should now use SSO. 
Once the script has completed there will be a result csv and if there are any non responding devices there will be a second csv. 
The export result will look like the below. 
To remove the WINS IP and set NetBios option, we will use the set method in the WMI class.
Once the script has run WINS should be removed and NetBios over Tcpip should be disabled this can be checked under the advanced properties on the NIC.
Once we have the list we can either remove manually or the better option use the CSV and remove the profiles using the invokeset method.
TheSleepyAdmins 