Thursday 29 March 2012

The security database on the server does not have a computer account for this workstation trust relationship

I needed to test some IIS shared config changes; I knew I'd break our live environment so I needed to set up a couple of VMs to simulate the two physical machines we have.

Building VMs is always a pain; well, the initial build is pretty easy, but once the machine's up and running, getting all the patching done is a right chore...especially when you've never been able to successfully install the MSDN Windows 2008R2 SP1 ISO... (but that's another story)

So I thought, "aha! I'll get one machine set up, then it'll be a simple matter of using the clever 'Export' feature in Hyper-V and I can quickly duplicate my machine, rename it, and off we go!"

So I did just that, the export and import worked fine (once I realised I needed to wait for the export to complete before trying to start the import), and pretty soon, I had two identical VMs, all nicely patched up.

I fired up the new machine first, so that I could change its IP address and rename it (we don't want IP/domain name conflicts, do we?) and that was all fine and dandy.  I started up the original VM, logged in and saw:

'The security database on the server does not have a computer account for this workstation trust relationship.'

Wait...what?

This is the original machine though, surely if any machine should have an issue, it'd be the new one, wouldn't it? I searched the web and didn't find a great deal of useful help, stuff about cross-domain trusts and hacking AD to make things work.

In the spirit of 'try switching it off and back on again first' I thought that maybe the new VM had taken on the computer account in AD, and retained it even with its new name.  The solution might be to just take the original VM out of the domain and add it back in.

And sure enough it was.  So if you're duplicating VMs within a domain (I suppose the same applies for ghosting physical machines too) make sure you either a) add the machines to the domain after they've been duplicated, or b) if the original machine is already in the domain, remember that whichever one you start up first will take the machine account in AD, and all the others will need individually adding back into the domain so they can get their own machine accounts.

4 comments:

  1. Always run a sysprep before cloning a computer. :-)

    ReplyDelete
  2. To protect business data from all employees, use an authentication tool that prevents users from logging into sensitive assets from a mobile device. If no employees can log into the central database from a mobile device, none can steal database information.
    data room providers

    ReplyDelete
  3. I really loved reading your blog. It was very well authored and easy to undertand. Unlike additional blogs I have read which are really not tht good. I also found your posts very interesting. In fact after reading, I had to go show it to my friend and he ejoyed it as well! security company

    ReplyDelete