When it comes to system imaging, the most important aspect is to be methodical. If there is an error, the last thing you want to do is try 3-4 different things to see if one fixes the problem. Bust out the scientific method and find out exactly what the problem is. Because you’re about to make a change, en masse, that is going to have a resounding impact on the ecosystem that is your environment. And the smaller the change, or the light the touch, that you make then the less likely you will be to introduce a support nightmare in some other part of the enterprise.
Many environments have long since moved into a change controlled environment. Post imaging, when desktops are deployed to users, any changes often need to be approved. Then those changes often need to move through stages, such as change management, release management, etc. The lighter the touch of these changes then the quicker it should be able to progress through stages because the impact that the change will have is typically easier to quantify.
So then you might ask what constitutes whether a touch is “light.” Look at it this way: one of the lightest touches is to not introduce change anywhere. Assuming that you have mobile homes, network redirects or roaming profiles, simply test logging into a different machine as the same user. Isolate whether the problem is with a user profile. Then check managed preferences, or GPOs. Verify that the problem is not with a policy. Remove policies from the equation (keeping in mind that there are policies for users, groups, computers, various groupings of computers, OUs, etc. Assuming that an issue (incident) is not policy nor profile, only then look to introduce change, or maybe instead of introducing change, consider simply re-imaging a host. That can, at times, be the lightest touch of all, because you are just reverting to a known good state.
But if you want to be more scientific, and isolate the issue down to exactly what the problem might be, then you might just be kinda’ like me. You need your users to have maximum uptime, which means you need to strike a balance here. Maybe swap machines so that you can isolate the error while allowing the user to continue working… If the issue persists after re-imaging then you have a fun one. At this point don’t do more than one thing at a time, and consider rebooting between tasks. Once you isolate your error down to a specific task that resulted in a fix then find a way to complete that task programatically. If you can complete a task using WMI, PowerShell, shell scripting, python, whatever then you can wrap it into an installer and easily push it out to other systems on either an as-needed basis or en masse.
But the lighter touch philosophy isn’t just for imaging and mass deployment/integration. It is a resounding philosophy across all things that need troubleshooting: isolate the problem by being methodical, down to the exact file, registry key, property list or whatever (thus and then find a way to accomplish the task that resolved the issue programatically). That will enable you to make the lightest touches possible and especially when troubleshooting en masse, result in the least amount of labor to be spent on problem management.