Has anyone else seen this problem:
If you try to create a scheduled task on Windows 2003 virtual server built from a image, you cannot use a local security account as the account for which the tasks runs. It lets you create the task, but it never runs and if you edit the task it generates an error. NT AUTHORITY\SYSTEM is an example account.
My thoughts (could be wrong):
In a normal system, when you schedule tasks, you can use System Accounts as the authority to run tasks. For example, using NT AUTHORITY\SYSTEM to schedule a task on a server normally works fine. This eliminates the need to use domain accounts and having to reset passwords for scheduled tasks frequently. An example of this is when you enable VSS on a server volume, the scheduled tasks automatically created use NT AUTHORITY\SYSTEM to run the shadow copy jobs.
The bug exists on VM images such that it removes or corrupts these local accounts from being seen by Scheduled Tasks. For example, if you enable VSS on a virtual machine disk, the tasks will fail as the accounts used to run them do not exist. I believe this is caused by the SYSPREP process the VMware uses; it must corrupt the local security files (see below) used by tasks.
1. Go to C:\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\S-1-5-18 on the VM with the problem
2. Delete all files that start with d42*
This problem NORMALLY happens on servers after a DC promo (in my case, these are just normal member servers not domain controllers) as discussed in the KB article:
So - has anyone else seen this. Is the VMware SYSPREP process killing this, or am I way off on that theor?
Did you ever sort this out? I am having similar issues on different servers. Fresh build VM and fresh build physical.
My problem is that when the task runs it just shows as running, it never does the task I assign it.
No I have not; just the fix I described in my original post.
I believe this is because the SID is changed when you sysprep, clone, or deploy from template and choose to change the SID of the machine. While having the same name, the local accounts actually have different SIDs.