Has anyone else seen this problem:
Background:
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.
Fix:
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*
Example file:
“d42cc0c3858a58db2db37658219e6400_47ff545c-a31f-47d1-90b8-833e1e473b7d”
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:
http://support.microsoft.com/default.aspx?scid=kb;en-us;822904
So - has anyone else seen this. Is the VMware SYSPREP process killing this, or am I way off on that theor?
SlickBag
