There are three concerns as I see them: Changes to the physical workspace, changes to computer-specific properties, and changes to user-specific properties.
I would tend to err on the side of treading lightly re: changes to the workspace. Common sense says that making any changes to the physical workspace is a bad idea, IMO. That would include changing chair settings, moving items not directly related to the work being performed, rifling through papers on the desk, etc. That strikes me as rude.
Altering ergonomic settings for a short visit is probably a bad idea, too. Changing monitor brightness / contrast settings, for example, would be ill advised (unless the settings are so far off that you can't see to work).
Religious dogma aside, the axiom "Do unto others..." rings true here for me. I wouldn't do anything to someone else's workspace that I wouldn't want them to do to mine.
A robust remote control solution would take care of a lot of this. Sometimes you have to go out and lay hands on a computer. A user should be prepared to have the computer they use pulled out of their workspace, if necessary. It's not their computer-- it's the company's computer. It's not their workspace-- it's the company's workspace. Your example didn't have such a scenario in it, but users should be expected to understand that some failures could result in the computer in their workspace being removed and replaced and they should deal with that.
If I did have to pull a computer from a workspace I'd try very hard to inform the user before I did it. If I couldn't, I'd leave a large note w/ contact information and details on what work was done.
I'm less likely to tread lightly re: changes to computer-speciifc properties. It might disorient somebody to have their monitor turned off, but I think assuming basic computer familiarity re: turning on a monitor is well within the expectations of a computer user. Likewise, the last logon name (a personal peeve of mine, and one of the reasons why I have the "Don't show last logged-on user name" group policy setting deployed at all of my Customer sites) isn't a showstopper that a computer literate person should be unable to handle. The guiding principle re: computer-specific properties should be something like "Can a computer-literate person be expected to deal with this change w/o asking for help?"
Making changes to a user-specific properties is like making changes to their physical workspace, to me. You should tread as lightly as possible here, too. Think about what changes you'd want someone else making to your user-specific settings w/o your knowledge, and apply that judgement.
In short, you can't. If you have gold support, you can open a ticket and sometimes they will give you a little bit more information, but otherwise all you can do is terminate the instance and start a new one.
We experience failures like this from time to time with EC2. We just keep instances on standby ready to take over should this arise.
Best Answer
I'm not an expert with Xeons these days, but don't Nehalem based Xeons require RAM in pairs of 3 not 2? The newer Nehalem based boards require memory to be installed in a very specific order with specific requirements (registered, ECC, etc. etc.). I would check the arrangement of your DIMMs in accordance with how many CPUs you have installed with the manual. Just my first guess.