P2v...Domain controller to hyper V

  • Thread starter Deleted member 12106
  • Start date
D

Deleted member 12106

Guest
I have a physical machine that is a domain controller/exchange server. It has been moved to a VMware esxi machine, however, we need to get it onto our hyper-v server and eliminate some more hardware.

My question is, can MSVMM workgroup edition do this? Looks like they have a trial available, and I am not finding an answer as to weather or not this would work.
 
Yes SCVMM can do P2V. I've personally haven't done it from a VM, but it can be done. That being said, I'd like to highly stress that having the DC on a Hyper-V box is a very very very bad idea.
 
Keiichi said:
Yes SCVMM can do P2V. I've personally haven't done it from a VM, but it can be done. That being said, I'd like to highly stress that having the DC on a Hyper-V box is a very very very bad idea.
Click to expand...

Why is it bad? The host is not a member of the domain.
 
I wouldn't P2V a DC anyways. Its much easier and cleaner to build a new one and promote.
 
oakfan52 said:
I wouldn't P2V a DC anyways. Its much easier and cleaner to build a new one and promote.
Click to expand...

We still need to get the old one into hyper-v, that maching runs sql/iis which in turn go with our shop management software.
 
Nadda eh?

We are prob going to have to divide the server that we want to p2v and rebuild the roles out on a separate machine. Going to put ad/exchange on 1 machine and iis/sql for our shop management software onto another.
 
As you mention, SCVMM is definately what you're looking for, however I'd class what you want to do as a V2V instead of a P2V (it doesn't matter to SCVMM that the source is also virtual so it's the same wizard and everything).

SCVMM has two methods of collecting the source - online and offline. As you're talking about a database (active directory) I'd ensure that you do the conversion offline. This removes any chance of data corruption or different versions of the same machine existing (SCVMM isn't as intelligent as VMware converter, which allows a resync after the main conversion has competed). Doing an offline conversion does complicate matters slightly in that you must provide SCVMM drivers it can use to when it boots into the WinPE environment to do the conversion - you can either copy the drivers from the guest ahead of time, or just switch the NIC on the VMware guest to be an e1000 (these drivers are already included).

Also, ensure you remove VMware Tools from the source before you proceed with conversion. I've had a lot of trouble trying to get rid of VMware Tools on a Hyper-V guest.
 
Keiichi said:
Yes SCVMM can do P2V. I've personally haven't done it from a VM, but it can be done. That being said, I'd like to highly stress that having the DC on a Hyper-V box is a very very very bad idea.
Click to expand...

I think you are grossly misinformed.
 
4saken said:
I think you are grossly misinformed.
Click to expand...

Not exactly, there are a multitude of reasons to be concerned about virtual DCs. if you are a small environment with very limited captital, or setting up a test environment, it makes lots of sense.

If you are a major corporation with large numbers of administrators, there are much larger issues. Especially, if you are deploying virtual hosts running hardware with variable speed CPU cores (i5/i7 based hardware) and Hyper-V.

MS came within a hair of issuing an official recommendation realted to this, but Intel browbeat them. The lack of real access to a hardware clock on variably clocked host CPUs is a major issue with DCs. MS coded a really ugly kludge and released a hotfix to addresss the problems this can cause, but its really only about an 80% solution.

If you are virtualizing DCs, you want to virtualize them on host machines or clusters that are running DCs, and nothing else. Access to these hosts should be more locked down than access to the DCs themselves. Anyone who has enough rights to copy the VHD files holding the DCs owns your security environment. If the host machine is compromised, that party has access to own your entire security database.

Using shadowcopy functionality, they can get an intact copy of the entire machine without taking it off-line.

Now you have a full working DC without even needing to know the AD recovery mode password for the DC you've pilfered.

You could even stand it back up and have it running without having admin access to the AD controller itself.

If there is another host compromised on the same netowrk and you do have an AD domain admin account, you could shut the real DC, bring up the DC on another host, and run your fully compromised DC at the heart of the compromised network. If switched out smoothly enough, you wouldn't even necessarily trip any remote montioring software like MOM.

Now you OWN the company.

You could still do some of this kind of thing with physical boxes, but its a lot harder and leaves a lot more traces during the process.
 
nessus said:
Not exactly, there are a multitude of reasons to be concerned about virtual DCs. if you are a small environment with very limited captital, or setting up a test environment, it makes lots of sense.

If you are a major corporation with large numbers of administrators, there are much larger issues. Especially, if you are deploying virtual hosts running hardware with variable speed CPU cores (i5/i7 based hardware) and Hyper-V.

MS came within a hair of issuing an official recommendation realted to this, but Intel browbeat them. The lack of real access to a hardware clock on variably clocked host CPUs is a major issue with DCs. MS coded a really ugly kludge and released a hotfix to addresss the problems this can cause, but its really only about an 80% solution.

If you are virtualizing DCs, you want to virtualize them on host machines or clusters that are running DCs, and nothing else. Access to these hosts should be more locked down than access to the DCs themselves. Anyone who has enough rights to copy the VHD files holding the DCs owns your security environment. If the host machine is compromised, that party has access to own your entire security database.

Using shadowcopy functionality, they can get an intact copy of the entire machine without taking it off-line.

Now you have a full working DC without even needing to know the AD recovery mode password for the DC you've pilfered.

You could even stand it back up and have it running without having admin access to the AD controller itself.

If there is another host compromised on the same netowrk and you do have an AD domain admin account, you could shut the real DC, bring up the DC on another host, and run your fully compromised DC at the heart of the compromised network. If switched out smoothly enough, you wouldn't even necessarily trip any remote montioring software like MOM.

Now you OWN the company.

You could still do some of this kind of thing with physical boxes, but its a lot harder and leaves a lot more traces during the process.
Click to expand...


Noted. I got about 50 users, we are on a budget, which is why I am considering a virtual DC.

The hyper v host is currently admin only acess, it is not joined to the domain, and will never be. This machine also hosts a handful of other machines.
 
sc0tty8 said:
Noted. I got about 50 users, we are on a budget, which is why I am considering a virtual DC.

The hyper v host is currently admin only acess, it is not joined to the domain, and will never be. This machine also hosts a handful of other machines.
Click to expand...

I'm running very similar setup. I have a DC VM on a little AMD based 2008 R2 server along with separate web, email, and remote access server VMs for my wife's small business.
 
nessus said:
I'm running very similar setup. I have a DC VM on a little AMD based 2008 R2 server along with separate web, email, and remote access server VMs for my wife's small business.
Click to expand...

We run Hyper-V and Xen with about 7,000 users at over 300 remote locations. We have all of our DCs virtualized, without issue. We understood the time sync issue, and security concerns, however, so it has not been an issue for us. I still stick by the statement that a blanket statement concerning the validity of DCs on hyper-v to be null, wrong.
 
To add my 2 cents to this, I have been running virtualized DCs since late 2003.

The only issue that I have found has to do with restoring the DC from backups.
The first thing most do (and I did it too) is to restore the DC from a Ghost image, old virtual image file, or similar.
This is where the problem lies.
MS has strict guidelines for backing up and restoring DCs, which tools like Ghost and others violate.
Further, DC backups have a short shelf life (unless you want to deal with a messy clean up afterward).

The issue is even more pronounced when you have BDCs in the mix as an improperly restored DC will reject other DCs, and they in turn will reject it because of object versioning differences.

To avoid most issues:
1. Take a base image of all your DCs at once (power them off all at once and then image them offline)
2. Take a daily system state of your DCs.
3. When restoring, restore such that the system states are not more than 72 hours apart
 
spectrumbx said:
To add my 2 cents to this, I have been running virtualized DCs since late 2003.

The only issue that I have found has to do with restoring the DC from backups.
The first thing most do (and I did it too) is to restore the DC from a Ghost image, old virtual image file, or similar.
This is where the problem lies.
MS has strict guidelines for backing up and restoring DCs, which tools like Ghost and others violate.
Further, DC backups have a short shelf life (unless you want to deal with a messy clean up afterward).

The issue is even more pronounced when you have BDCs in the mix as an improperly restored DC will reject other DCs, and they in turn will reject it because of object versioning differences.

To avoid most issues:
1. Take a base image of all your DCs at once (power them off all at once and then image them offline)
2. Take a daily system state of your DCs.
3. When restoring, restore such that the system states are not more than 72 hours apart
Click to expand...

If i have a DC die, i just force all the roles to another and kill the old one. Then rebuild it from scratch later. But i suppose if you have specific apps running on a DC you may have to restore from backup. I havent ever restored a DC from backup due to redundancy in our AD infrastructure.

But what you say is pretty much true regardless if its virtualized or nto and you need to restore.
 
Ahhhhhhh! TEH HORROR! I've had to do a DC restore and had NO clue of the nightmare I was walking into. I've had to do a DSN Rollback and it was a freaking NIGHTMARE. That's the only issue I've had with virtual DC's. Restoring from backup can be a VERY touchy issue!
 
You must log in or register to reply here.
Back
Top