[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 2054
  • Last Modified:

Hyper-V Server and DC

Hi,

Should a Hyper-V host server be a domain member when the DC is a VM on the Hyper-V server? The Hyper-V Server also acts as a file server for the domain because it has a directly attached RAID array, so somehow I need to have domain permissions on the Hyper-V server.

Will this cause any problems (since the DC will obviously not be available when the host restarts)?

Thanks!
0
Pugglewuggle
Asked:
Pugglewuggle
  • 17
  • 14
  • 2
3 Solutions
 
OriNetworksCommented:
This will cause problems since no domain controller will be available at startup. To work around this problem, I would have a separate physical box as a second domain controller that will be available when the hyperv server starts up. This additional server does not have to have really powerful hardware since it will only be running as a DC unless your domain is very large. This will also give you some failover in case you have to restart your virtual DC for updates or whatever.
0
 
PugglewuggleAuthor Commented:
Hmm... This is the only physical server at this customer's location other than the web server in the DMZ...
I've heard Hyper-V doesn't like anything else to be on the same box... would adding ADDS to the Hyper-V host installation as a backup DC cause any issues? That should provide the Hyper-V box with directory services when starting up, correct?
0
 
OriNetworksCommented:
That would be correct but i'm not sure if this is a support method or not.  In the past I have added Virtual Server to a domain controller and the problem I had was SPNs. I just had to recreate the SPNs for virtual server using setspn utility on the domain controller and it worked. I'm not sure if this changes with Hyper-V or not.
0
NEW Veeam Backup for Microsoft Office 365 1.5

With Office 365, it’s your data and your responsibility to protect it. NEW Veeam Backup for Microsoft Office 365 eliminates the risk of losing access to your Office 365 data.

 
tigermattCommented:

Hey Pugglewuggle,

Microsoft highly recommend that the only role you run in the Host OS is the Hyper-V role. Obviously all the other roles should be placed onto the Virtual Machines, running under the Hyper-V Server. There is no harm in placing the AD DS role on the Hyper-V host (it is supported, even in Server Core). However, it would not be recommended, since unlike a VM it is virtually impossible to restrict and limit the system resource usage of roles running in the Host, so should the AD DS role become a problem, it could eat into the Hyper-V Resources, severely restricting the operation of your VMs.

It is highly unlikely this would be a problem and it should be OK setting the Host OS as an Additional DC, but I wouldn't risk it, just in case.

Back to the original question, the Hyper-V Server can be a member of the domain, but whenever you restart it, you would be logging in with cached credentials, rather than the server communicating with the unstarted DC VM. This is again not a problem, since you could log in with a local user account instead, but I would suggest you evaluate whether the Hyper-V Server really needs to be a member of the domain and what benefits you will get from doing so before you make it a member.

-Matt
-tigermatt
0
 
PugglewuggleAuthor Commented:
Well, like I said, this server has the customer's DAS RAID array on it, so in order to have domain permissions done right the Hyper-V machine needs to be a domain member. Is this right? Methinks it is so. :-P
Would it cause a problem if the PDC is on a VM and the Hyper-V machine provides backup ADDS even though the VM is the operations master on all AD services? I suppose those services would failover onto the Hyper-V DC? And with DNS - just put DNS on both the Hyper-V server and the VM PDC? Then specify both DNS servers in DHCP options and in statically configured hosts?
Also, I suppose that if I convert the Hyper-V machine to a DC, I can no longer have 2 NICs in it? I guess I should disable one before promoting the BDC?
0
 
tigermattCommented:

Remember there is no longer the terms 'PDC' and 'BDC'. Updates can be made at every domain controller (so Active Directory is multimaster), with the exception of the 5 FSMO roles which dictate 5 update routines which can only be performed on a certain server. I know what you mean, though :-)...

>> Would it cause a problem if the PDC is on a VM and the Hyper-V machine provides backup ADDS even though the VM is the operations master on all AD services? I suppose those services would failover onto the Hyper-V DC? And with DNS - just put DNS on both the Hyper-V server and the VM PDC? Then specify both DNS servers in DHCP options and in statically configured hosts?

Technically it doesn't matter. It's not recommended, but at the same time it IS supported and CAN work. When the Hyper-V machine starts, it would be just like starting a DC while it is disconnected from the network, say in a Branch Office which has no network connectivity elsewhere. Be sure the Hyper-V Host also runs DNS and the DC has the GC role installed, and this should work.

Even though it is slightly more risky, I'd probably go down the route of making the host a DC rather than a Domain Member. If it is simply a Member Server, you will get all sorts of domain connectivity problems when it boots, whereas having it as a DC means you can still login using that DC for authentication.

Having 2 NICs isn't a problem; it's having two NICs which show as two separate network interfaces in the system which will do the damage. What I mean by this is you can keep the 2 NICs and team them, for example, so the OS thinks they are one NIC (and the teaming software does the rest), but don't have the 2 NICs enabled separately so they have separate IP addresses. That is recipe for disaster on a DC.

-Matt
-tigermatt
0
 
tigermattCommented:

Pugglewuggle, by the way, I'll get back to the other Q as soon as I can.
0
 
PugglewuggleAuthor Commented:
Lol, I know, but it still makes logical since when explaining since one DC is the operations master for all roles it effectively is the "primary" domain controller, as the other would only become the OM in a failover (thus "backup")situation where the "primary" one goes offline.
I figured it would work but thanks for the opinion! Much appreciated! I think I'll make the Hyper-V machine a DC... the problems have already begun with it just being a member server... for example since it's also the file server, it takes a bit for the files to be come accessible to domain members because permissions are set for domain accounts.
With regard to 2 NICs on the Hyper-V server... I've used a DC with 2 NICs before and it caused several issues... I know MS and just about everybody will only recommend using 1 NIC on a DC... I suppose this is because ADDS registers all IPs on the server in DNS. What I'm currently doing is using one NIC dedicated for client access and one on a management VLAN. Are you saying it's okay to use this? I would prefer that no AD traffic goes across the management interface and that DNS and ADDS doesn't register that NIC if possible. If that won't work what are my options? Just manually remove that NIC's IP from DNS and replicate it?
No prob about the wait! I appreciate the help so far!
0
 
tigermattCommented:

If you just try to remove that NIC from DNS it will quickly come back again. What you're probably going to have to do is to actually change the bindings for DNS and DHCP so that they are only listening on the client access NIC, and try again. Provided that doesn't cause any rogue entries to be registered in DNS, there shouldn't be a problem.

> Lol, I know, but it still makes logical since when explaining since one DC is the operations master for all roles it effectively is the "primary" domain controller, as the other would only become the OM in a failover (thus "backup")situation where the "primary" one goes offline.

With regards to this, actually the Hyper-V Server wouldn't become the Operations master when the holder of all FSMOs is offline. It will just boot without contacting the FSMO role holder, and then attempt to contact it later.

Cheers,
-Matt
0
 
PugglewuggleAuthor Commented:
Okay, gotcha on the NIC. I'm pretty sure I tried this before several times and was greeted with the 2nd NIC just being repopulated in DNS anyways even though it wasn't bound to any services. This, of course, gives you the well known DC loop errors resulting from the "rogue" NIC(s).
Regarding DHCP, an interesting thing about Hyper-V (that I and several others on the web have discovered and verified through MS) is that you cannot run DHCP on a Hyper-V server - it must be run on another server or on a VM. It has something to do with the MS Virtual Switch that Hyper-V installs. I suspect they'll fix that in WS 2008 R2.
Hmmm... so the Hyper-V server (or any non-OM DC) could still provide full logon/ADDS services/etc. without the infrastructure master and other FSMOs?
Again, thanks and cheers!
 
0
 
tigermattCommented:

I thought all along that it was DHCP in a VM which didn't work, and that you had to install it on a host! http://forums.microsoft.com/TechNet/ShowPost.aspx?PostID=3380939&SiteID=17 is good clarification.

You're most welcome anyway, thanks!

-Matt
0
 
PugglewuggleAuthor Commented:
No prob! Hyper-V is new and we're all still getting used to it. The fact is that it doesn't work on a Hyper-V host system at all. I probably spent 15 hours trying to figure that out the first time I installed Hyper-V in our test lab. :-P
Regarding my last comment though -
Hmmm... so the Hyper-V server (or any non-OM DC) could still provide full logon/ADDS services/etc. without the infrastructure master and other FSMOs?
Or are the services limited since those aren't MMR services?
Cheers!
0
 
tigermattCommented:

> Hmmm... so the Hyper-V server (or any non-OM DC) could still provide full logon/ADDS services/etc. without the infrastructure master and other FSMOs?

Sorry, overlooked that one a bit! Correct, but only providing that the Hyper-V Host DC is also a Global Catalog Server, and most definitely a DNS Server. If it is not, then clients would still be unable to login, since without a Global Catalog at login time, Universal Group Membership cannot be established and would definitely cause login issues, and obviously no DNS = no communication with Active Directory.

> Or are the services limited since those aren't MMR services?

You would obviously not be able to do things like Update the Schema, generate a new RID pool or use a legacy Windows 9x client on the domain (they need the PDCe) or anything like that, unless you were in active communication with the DC holding each of those FSMO roles as appropriate. However, you can do basic logins to the DC provided it is a GC, which would then make you on the network to start the Hyper-V DC VM and get the whole network rolling. As I think I said before, this is a common scenario in Branch Offices where connections to the far end where the FSMO role holder(s) are limited, and it all ticks along nicely there with proper setup :-)

-tigermatt
0
 
PugglewuggleAuthor Commented:
Gotcha! Let me give this a shot and I'll let you know how it works out.
Cheers!
0
 
PugglewuggleAuthor Commented:
Okay, so I added the Hyper-V machine as a DC. BEFORE DOING THAT, I made it so the DNS server only listens on the main NIC and not the management one. However, the rogue NIC is there to haunt my DNS anyways. Any ideas short of disabling it?
0
 
tigermattCommented:

Only possibility I can think of is to uncheck the 'Register in DNS' checkbox on that NIC's TCP/IP > Advanced > DNS property page. That should help.

-Matt
0
 
PugglewuggleAuthor Commented:
kk, I'll try that and let you know - but I think that's for when a NIC pulls a DHCP address and determines whether the hostname is registered on the DNS server...
0
 
tigermattCommented:

Let me know, but I think you might be correct. If you can't get it going, let me know, because we can always go down a different route which involves stopping the server registering any DNS, and then we create the records manually. This is something I do quite often; on multi-NIC DCs and on any server running RRAS.

-Matt
0
 
PugglewuggleAuthor Commented:
Hi Matt - it didn't work - the rogue IP is still in DNS. Can you please tell me the other method?
0
 
tigermattCommented:

Hey,

Follow this article and make the registry changes 'PublishDnsARecords' and 'PublishAddresses' as detailed. The article is for a completely different issue with Windows but the technique described is the one to apply to this situation.

In the PublishAddresses value, obviously you enter the IP of the correct NIC (which should be registered in DNS).

Once you set the registry settings and have promoted the server, you need to ensure you do the 'Manually add A records to DNS' step. Also do the WINS section if necessary.

Let me know how you get on!

-Matt
0
 
PugglewuggleAuthor Commented:
Which article? :-)
0
 
tigermattCommented:

Sorry! Article is http://support.microsoft.com/kb/292822, should be able to follow instructions above :-)

-Matt
0
 
PugglewuggleAuthor Commented:
No prob! I'll let you know!
0
 
PugglewuggleAuthor Commented:
Hi Matt,
I still am having issues getting rid of this ghost NIC! For now I just took ADDS off the host machine and am running the DC on a guest.
Any suggestions?
Cheers!
0
 
tigermattCommented:

So, so far, you've attempted to block the IP of the NIC from being registered in DNS, and that's failing, but leaving the NIC enabled? Am I correct?
0
 
PugglewuggleAuthor Commented:
Yes.
0
 
tigermattCommented:

When you install DNS on the server, it looks like DNS will automatically register the IP of all NICs it is bound to on the server where it is installed. Thus, even though we have unchecked the box on the NIC properties to stop DNS registration and tried this other approach, the NIC is still registering due to this DNS feature.

So I'd say first of all, revert the changes you made as per the article I supplied above, so that none of those registry entries exist any more. Then, when you re-promote the server and install DNS, open the DNS console, right-click the Server Object at the top of the tree, Properties and then on the first screen you see, you can change the DNS service's NIC bindings. Change it so it only binds to particular IPs (rather than all of them), and then set the IP it binds to so it only registers as the IP on the main NIC (not the admin NIC). See if that helps.

The reasoning behind it seems plausible!
0
 
PugglewuggleAuthor Commented:
Hi Matt,
I had actually done that already in testing... the IP still shows up in the _msdcs.
0
 
tigermattCommented:

Did you take the bindings out AND make sure the 'Register in DNS' checkbox on the admin NIC was unchecked? I guess you did, but...

-Matt
0
 
PugglewuggleAuthor Commented:
Yes I did both... why must MS make it so complicate to exempt a NIC!?
:-P
0
 
tigermattCommented:

Well, I'm kinda at a loss then as to what exactly is going on. Short of recommending you take a look over http://support.microsoft.com/?kbid=246804 (it's a bit long, I know) I can't think of what else would cause that rogue IP to be displayed there.

Give the KB article a go and let me know.
0
 
PugglewuggleAuthor Commented:
Well, I suppose MS would say "it's not supported - deal with it!" so calling them would be a waste of time... I'll look it over and see if I can get it working.
Cheers!
0
 
PugglewuggleAuthor Commented:
Well, I just ended up disabling the other NIC. :-/
0

Featured Post

Concerto's Cloud Advisory Services

Want to avoid the missteps to gaining all the benefits of the cloud? Learn more about the different assessment options from our Cloud Advisory team.

  • 17
  • 14
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now