Don’t Let Your Jobs Get Burned By Domain Changes On Windows Servers Control-M Touches

Hey Control-m users and followers. I would like to discuss how to handle control-m system accounts on Windows servers that have unexpected or planned domain changes on Windows servers that are a part of jobs in your distributed production control-m job environment. 

Recently in my environment we have had a number of domain changes which have caused a number of my jobs to fail. This primarily being because the changes were not communicated all the way across the board. 

To solve this issue for Control-m I had to  troubleshoot a few of the problematic jobs. This led me to realize what the issue was. Our traditional domain name was slowly being phased out on a few servers at a time. It was making the jobs fail because the traditional domain control-m system account was not of any use in the new domain. I knew I had a new domain control-m system account created just did  not have to use it yet.  To fix this I placed a request to the Active Directory admin to add the new domain control-m system account to the servers involved with my failed jobs that had the domain change, and also to give it read, write and delete rights. Once the admin completed my request, I also added the new system account in the actual job itself where it says runas. Then I re-ran all my jobs that failed because of this reason and they began working again. 

To be proactive I plan on adding the the new domain control-m system account to all of the servers my jobs touch that still have the traditional domain name. That way as they’re migrated to the new domain the domain system account will be on the server. That way access and rights will not be effected and none of my customers will be impacted.