Troubleshooting Upgrade and CU Batch jobs stuck in a waiting status in Dynamics AX 2012

There may be circumstances when you are testing a Full version upgrade, in place upgrade, or applying a Cumulative Update (CU) in Dynamics AX 2012 where the batch jobs never start and appear to be stuck in a waiting status.

Normally we see problems when the Dynamics AX databases is restored to a different environment and the batch framework settings have not been corrected.  See this blog for a
larger discussion of this http://blogs.msdn.com/b/axsupport/archive/2011/11/07/moving-between-microsoft-dynamics-ax-2012-environments.aspx

I have compiled a list of things to check to make sure the setup of the batch framework is correct:

1. As always make sure you can get through a Full X++ compile and Full CIL generation without errors in the developer workspace before moving on to any of the other Checklist items.

2. Make sure the user account logging into the Dynamics AX client to run the checklist is the Dynamics AX admin account and NOT just a member of the system administrator security role.

• To make sure you are logged in as the “admin” account go to Tools | Options | Status Bar and mark the checkbox to Show user ID.  Close the Options form and then when you check the lower right hand corner of the Main Dynamics AX window it will show the account you are logged in with.  This must be “admin”
• Check the batch form directly in the client by going to System Administration | Batch Jobs | Batch Jobs and check the Createdby fields and if the DataUpdate job has already scheduled as an account other than admin, you need to start the upgrade over by logging in as the admin account or you may be able to change the records in the batch and batchjob tables to be the admin account. 
• Check the userinfo table in SQL: select * from userinfo where ID = ‘admin’  to make sure a record for the “admin” ID has  a valid SID, networkdomain, and networkalias for each partition in the environment. 

Important: You should be very careful about updating the records in the SQL backend make sure to use a where clause in the SQL statement to only update those records you intend to, also make a SQL backup of the Dynamics database, and that you are testing the steps in an environment such as test or development.

The SQL statement you could use would be to set the EXECUTEDBY and CREATEDBY fields to the “admin” user id for the dataUpdate job.

 3. Remove any records in the SysServerSessions table that are not valid in this environment, you should do this while the AOS servers are stopped and make sure to have a SQL backup first.

4. Check the setup under system administration | setup | system | Server configuration

• Delete any AOS instances here that are not valid in this environment
• Make sure the remaining AOS instance is marked “is batch server”
• Make sure batch server schedule is setup with proper start/end time i.e. Start time 12:00:00 am end time 11:59:59, so there are no gaps in the scheduled time.

5. Under system administration | setup | batch group

• Make sure that the remaining valid AOS server that is also marked for batch has the blank batch group and dataUpdate batch group assigned to it.

Note: The blank batch group is used to process any runtime batch tasks that are spawned as separate batch threads so this batch group is critical.

6. Check system administration | Batch Jobs | Batch Jobs

• • Change the status of any other batch jobs from waiting to withheld so they don’t interfere with the Data Upgrade batch jobs.  To change the status highlight the jobs you want to change and select Functions | Change Status and choose Withhold
  • Check for any previously running batch jobs that are stuck in a status of Executing.  You may need to change the status to cancelled or remove the Job from the Batch and Batchjob table from the SQL backup.

转载于:https://www.cnblogs.com/xiangliqi/p/6204703.html