When running playbooks remotely against Windows 10 hosts, it creates a profile entry in C:\Users for the sys admin user who ran the playbook.
We have a Linux ansible controller from which we run the playbooks against Windows 10 hosts.
In Powershell, I found its possible to run the following command to not create the profile :
-NoProfile
However, not all of our ansible playbooks are running powershell scripts on the remote Windows 10 machines, some playbooks are simply copying files across or installing software remotely.
The reason I’d like no profiles to be created in C:\Users after running a playbook is so that the C:\Users directory doesn’t get filled up with random profiles that essentially are never going to be logged into and therefore just stay there.
Wondering if there is a variable I can run alongside the playbook which will mean no user profile is created on the remote host.
-NoProfile on PowerShell just runs the PowerShell executable without it’s profile file (like ~/.bashrc). It doesn’t have anything to do with the actual user profile. You’ll have to see if the connection plugin you are using has any options around connecting without a profile. Unfortunately it doesn’t look like we expose the option in the winrm or psrp connections and IIRC it didn’t even work anymore on newer versions of Windows for WinRM based connections.
Hi Kevin, unfortunately when trying to delete the profile after its been used to deploy a script, windows somehow still has it in use (perhaps a lock on one its files), and so can’t delete it.
Hi Jordan, I see what you mean. Here is the connection method we’re using;
The reason I’d like to remove the stale profiles is because our vulnerability scanning tools picks up on these, and as these stale profiles aren’t logged into, various windows group policies etc do not get applied to them, and therefore they flag up.
Any other ideas would be appreciated if there are any. Thanks
Unfortunately that GPO doesn’t work too well (also seen similar comments on forums stating the same)
This is because the ntuser.dat file within a users profile in c:\users gets updated anytime the machine is patched with windows updates. This is because for some reason, windows updates touches the ntuser.dat file within each profile in c:\users, and so the last modified time of the profile gets updated, and so the GPO doesn’t delete the profile as it doesn’t recognize it as old.
Oh yeah! It’s been a while since I’ve been a Windows SysAdmin, so I forgot about that. I don’t think we encountered that problem that much my last job, though. Maybe we didn’t set the days high enough to matter? We also did nightly reboots where possible, which might have helped trigger cleanups between patching.
We did however suffer from the 1709 upgrade bug that made this GPO delete all users on the system instead. Fortunately, we had solid user backups for the sites that were impacted before we paused further updates.